再谈一下UI自动化吧

本来不想再谈这些内容了，因为太基本，简单了。可是最近竟然发现一直不屑于UI自动化的我，仿佛都成为一个UI自动化专家了。我发现很多人，包括论坛上的网友，还有很多身边的同事都对UI自动化充满了一些恐惧感，从而不敢触及它。当然也有一定的原因是觉得UI自动化没太深的技术含量，这也是我讨厌UI自动化的唯一原因。但是，一旦让这些人去做UI自动化的话，是很难做好的，因为UI自动化需要一定的经验，而我个人认为一年的经验，一个正规的项目应该都能具备编写良好UI自动化测试的能力。因此，对于后来的人，我想把UI自动化关键的几条再谈一谈，UI自动化确实没什么技术含量，你掌握了以下几点也能成为一个小专家了。

1. 用高级语言编写自动化程序，在UI的部分调用UI自动化工具。我反对纯用UI自动化工具去写自动化，因为那样就太死板了，而且功能不强大，不灵活。我推荐学好一门高级语言，把大多数的自动化都用这门高级语言实现，只在需要UI操作的时候才调用UI工具。
2. 只在你测试的UI模块上进行自动化的测试，其他地方避免用UI去操作，使用高级语言去实现。这样你需要用UI的地方就进行了最小化，从而使得只有在真正需要UI的地方才自动化UI，因此测试程序会相对更稳定。
3. UI自动化最基本的操作就是发现控件和操作控件。尽量避免用text来发现控件，而使用一些固定的控件属性来发现，比如Control ID等等。这样的话，测试程序会更稳定，开发改变文本不会影响到你，而你也不用担心localization的问题。
4. 操作控件分为模拟用户操作和事件驱动。简单的例子就是，模拟用户操作就是鼠标真的去点一下，而事件驱动则是跳过点击直接引发点击的事件。我以前用过具有这种功能的工具，但是最近几年用的工具不具备这个功能。
5. 解决好同步问题。UI自动化最不稳定的地方就是同步问题了，你不能连续点击，而需要等待到一定的情况才能进行下一次点击。各种情况都不太一样，需要一些经验进行良好的程序设计。但是，简单来讲，要做到等待的情况发生能立刻返回到程序，不能空等。
6. 减少其他UI对你自动化程序的影响，比如关闭Windows balloon，等等。一般来说是发现了有其他UI影响你的情况，就想一下workaround, 不会有什么大问题。

从我的经验上来看，一般UI自动化有问题都能归结于以上几点，而一旦你解决了以上几点的话，UI自动化就变成了一个熟练工的工作了，没什么挑战性。我本人的有些模块的UI自动化基本可以达到100%的通过率，而所有模块的自动化也能达到95%以上的通过率。不过我基本已经脱离UI自动化了，因为太没有技术含量了，不过我还是认为如果你刚刚进入测试的工作，或者从来没有接触过UI自动化，或者从来都没有做好过UI自动化的话，在这上边工作个2，3年会有一定的收获的。

Code Review, Debugging, Windows Internals, WDM小结 （一）

学完Silverlight之后，最近两三个星期集中在了code review, debugging, 以及Windows Internals和WDM的学习上。现在是时候做个小结了。

逛了一些关于debug，windows内核，驱动等的论坛，发现大家主要集中在了加密/解密，逆向，系统漏洞和反病毒等等专业领域，和我所学习他们的目的并不相同。所以，文章和我所关注的知识点也不很match。对于我来说，我学习他们的主要目的集中在了Debug和Security Test上。在学习的过程中有种知识零散的感觉，昨晚才把他们互相联系起来，因此也就有个立体的感觉（请看下图)。下面想简单地谈谈。

首先，Debug是一项软件人员应该掌握的既基本，又高级的技能。它并不属于开发人员的专利，测试人员拥有这项技能也如虎添翼。说它基本是因为在你大学学习计算机语言的时候都会或多或少用到debug的技术，是编程中一项必用的技术。说它高级是因为很多疑难杂症都需要高超的debug能力才能去解决，debug的能力很大程度上体现了一个人的软件开发测试的水平。大家debug的目的各不相同，而对于测试人员来说就是在发现一个bug的时候能够通过debug找到root cause。在debug的学习与实践中，我认为以下知识非常重要：

1. Debugging tools: 微软提供了一套tools，而我们最常用的就是windbg了。windbg使用起来还不算麻烦，学习起来也不难，但是各项命令实在是太多了，需要时间和经验去慢慢积累。
2. Code review：或者你做专门的code review，或者你在debug的时候做code review。总之，你对代码不熟悉是很难进行debug的。因此，code review也是debug中非常重要的一个方面，你应该熟悉你所测试产品的代码。很多时候，你甚至不用去debug，想想代码流程，或者简单地review一下就能定位bug。而对于code review方面，你需要了解Win32 API （User mode code），以及WDM,WDF （driver）。
3. Assembly： 如果你没有源代码的访问权利，你就需要逆向的能力了，这个就对汇编的要求很高了。但是，一般来说我们都是测试自己的产品，理所当然具有源代码的访问权利。但是，即使这样，我们仍然在某些时候需要汇编的知识去debug，比如有时windbg的命令不能正确显示结果，或者调试optimized code的时候。不过这些要求不会太高，一般来讲你学习几个小时的汇编就应该够用了。
4. Windows internals：其实Windows internals是里边最难学的，但又是比较基础的东西。比如，windbg的很多命令的使用需要你了解内核的工作原理及数据结构。而你在调试driver的时候当然需要内核的很多知识。你如果把内核学通了，其他知识都不成什么问题了，所以对内核的掌握程度也直接决定了你的debug水平。这本书我从开始看断断续续的也快三年了，最近才有了立体的感觉，一想能知道这本书都说了些什么，虽然我不确定我到底看懂了多少，但是基本上在debug需要的时候我能够直接找到相应的章节去看，也应该可以短时间内看懂。由于先看了这本书，所以在看WDM的时候就感觉很简单了，虽然作者说话很罗嗦，但是不用太多的推敲都能很快理解。有种感觉，好象是精通了C/C++以后再去学习其他语言的时候的那种感觉。

Debugging Tools for Windows 学习使用心得

其实我的主要工作一直是UI test， UI automation, manual test 等等。曾经跟领导提过想做些深入点的测试，领导则反问 “你Kernel debugging 怎样？”。这是一个非常有趣的问题，你因为不具备良好的kernel debugging的能力，所以不给你做深入的测试工作，而因为你没有做深入的测试使你也不可能具备kernel debugging的能力。很多时候事情就是如此矛盾的，而我也曾经说过，一切最终还得靠自己。

前几天发现一个奇怪的bug，分给这里的一个seniro dev他也没太多的办法。我在一个高手的指导下自己debug and figure out了root cause。在和这个高手的交流中，也基本明确了一下步的学习目标。以前的我主要是靠自己摸索，我想多跟高手接触，交流还是非常非常有帮助的，当然机会也不是很多。那么我的下一步的目标就是“code review, debugging, windows internal and WDM”。Debugging可以说贯穿了其他的三个，因此我今天先谈谈我对debugging tools的感受。

我们基本都是用微软提供的几个debuggers，ntsd, cdb, kd, windbg。ntsd和cbd是user mode debugger, kd是kernel mode debugger, 他们都是command line的，而windbg是UI的debugger, 可以调试both user and kernel mode。大多数情况，我都是用windbg，但是在一些特殊的情况下，我还是需要其他的tools。今天我主要是谈windbg，我想学习windbg大概分这么几个阶段：

1. windbg的命令，共三种命令，普通命令，加'.'的命令和加'!'的命令。Debugging tools自带的那个教程学习一下就应该差不多了，以后就靠经验积累了。
2. 如何开始debug, 这要根据你所debug的目标和要debug的问题来决定了。你应该决定是使用user debugger 还是 kernel debugger, 是 local debugging 还是 remote debugging, 是用windbg还是ntsd, 等等。通常都有几种方式去debug，你要能够准确选择一个最合适的。
3. 怎样进行debug。对于一个需要debug的问题，你需要有你的策略。比如，在哪里设置断点，如何设置断点，等等技巧。
4. 利用一些tools。有些情况下只有debugger还是很难debug，你需要使用其他的tools去辅助。比如，有的时候在问题显露的时候已经太晚了，你很难追踪问题发生时的情况。这里，你可以用一些tool使得在事情发生的时候跳到debugger上去。
5. Code review非常重要。当你发现一个bug的时候，如果你代码熟悉，你可能直接就能想到问题出在哪里，或者你稍微读读代码就能发现问题所在，根本就不需要debugger。而在你debugging的时候，常常你也需要review相关的代码来理解这个问题。
6. 汇编语言。当你在调试optimized code的时候，你常常不能通过dv, dt等命令正确地看参数，变量等等，或者变量根本就没得显示。这就需要你具备汇编语言的阅读能力，了解calling convention, 不同cpu的汇编，以及在disassembly模式去调试。
7. Kernel debugging。如果你具备了以上的技能以后，user mode debugging应该不成什么问题了。但是对于调试kenrel mode还是需要一些附加的知识与技能。首先，kernel debugger的命令很多跟user mode的就不一样了，你需要学习。其次，你需要了解Windows internal的知识和数据结构，以及Windows driver model。这也是为什么我把Windows internal 和 WDM作为两个学习要点。

最后引用高手的两句话，“debug一两年，你就没什么问题debug不了了”，“只要能repro，你总能找到办法去debug”。

我要反省自己

一直觉得我的测试能力也算是很不错了，应该多在开发上下功夫，没想到是大错而特错。测试领域还是有很多东西可以做的其实。前天下午听了一个presentation，介绍一个tool。其实这个tool早知道，早就在用，只是有一个选项从来没用过，那人就介绍这个选项。当时就感觉不太对劲，回到office赶紧试了试。没想到的是在10分钟之内就发现了3个严重的security bug。这三个bug都可以造成远程的DOS攻击，使Server crash掉。产品发布在即领导也决定要马上fix。我告诉同事这个选项以后，结果几乎每一个人的模块都发现了或大或小，这样那样的问题。而我由于还没有继续进行我的测试，还不敢说最后到底能发现多少这么严重的bug。

所以，测试其实真是有很多东西可以去开拓的。简单一个tool的某个option都可能让你的测试效果大不相同。

高级测试人才应该掌握的六类知识

经常遇到测试人员不知道学什么，或者学一个东西不知道有没有用。其实我也经常会遇到类似的问题，因此我自己也想把我学到的知识归归类。我想只要是这几类的知识，你学习都没什么错，总是会有用的。

1. 产品知识：对于你所测试的产品，你一定要非常熟悉。小到你所测试的模块，大到整个产品的架构，内部实现，代码，等等。
2. 测试知识：黑盒测试，白盒测试，手工测试，自动化测试，性能测试，安全测试等等。
3. 开发知识：编程，数据结构，算法，调试等等。
4. 专业知识：以上2，3是基本的知识，你还应该精通一些你从事的更专的技术知识。比如，如果你的产品是基于.net的，你应该精通.net, 或者类似的J2ee等。（例如这方面我应该掌握的Win32系统编程，Windows内核，WDM等等）
5. 领域知识：你应该精通你所工作的领域的知识，比如手机领域，数据库领域等等。
6. 行业知识：你要对计算机行业的整体状态，新技术，动态，发展趋势有一个明确认识。（比如我除了自己从事的领域还关注Web2.0，云计算等等）

要记住，你首先是一个计算机人才，其次是一个软件人才，再次是一个测试人才，最后你才是一个SQAA, SQAE, STE, SDET等等。要想做一个高级测试人才，这一条线的知识都需要掌握。

召集志愿测试员

听到很多测试人员抱怨没有机会去进行自动化测试，白盒测试这些相对手工，黑盒测试技术要求比较高的工作。我一直提倡应该自己去创造机会，但是我发现很少有人能够做到。因此，我准备启动一个开源的项目TwitterBEIS，给大家创造一些这样的机会，希望有能力和想法的测试人员参加。

Qualifications:

• Good English writing skills: we will be developing a software using some kinds of new techniques. We need to communicate with foreign communities. So English is very important. Also all documents, code comments and communication will be in English.
• Coding skills: you have to be able to write code since you will work on automation, code review, debugging etc.
• Quick learner: some techniques are new, you must ramp up quickly.
• Willing to learn advanced testing technologies.

Advantages:

• Development will deploy the second model I mentioned in my blog. That means you will do lots of code review and debugging.
• Other than that, you will be working on unit test, white box, automation so on and so forth. They all help to build your professional resume.
• Possibly change to a dev role once your coding skills are good enough.
• Use modern Web2.0 technology to work together as a startup.
• Directed by me in real project rather than articles.

Disadvantages:

• No payment: everything is volunteered and completely depends on fun, interests and learning.
• It will take you bunch of spare time.

For all details, visit http://code.google.com/p/twitterbeis/.

考虑把你自己变得unique

经常有人跟我提起“我们公司的测试就是这个样子”，“中国的测试就是这个样子”等等。我昨天收到一个recruiter的来信，深有一些感触。我想问“为什么你不想把你自己变得unique呢？”为什么目前的测试环境如此你就随波逐流呢？

记得上大学和刚刚工作不久自己心中总是有一句话“不一样的人要过不一样的生活”。是的，我从小不喜欢随大流，别人都喜欢的东西我往往不喜欢，而我自己喜欢的东西其他人也常常不喜欢。简单来说，我算比较独特一些吧。这也在很大程度上使我自己的工作态度和大家有所区别。

我觉得一个人发展到一定程度是一定要有自己特点的，总是跟在被人后边是很难会有很大发展的。现在我的有些东西，我都觉得是只可意会而不可言传的。所以我希望大家能够开始思考这个问题。

附录recruiter的部分来信，请大家注意particular, unique, hard to find这几个词。我建议每个人都应该朝这几个方向发展。

I realize you work at XXX, so a contract opportunity wouldn't be too enticing for you! Rather, I'd like to tap into your network. I'm looking for a particular skill set and background like yours, which is unique and hard to find. :)

Work smartly or 偷懒

在我发表了Code Review+Debugging的文章之后，看到了一个很典型的comment，我想简单回应一下。

很赞同你的看法，但是目前绝大多数的test都是第一种模式（包括Microsoft的大部分team），因为tester要负责automation，test case。

如果我没有理解错的话，意思是tester要负责automation, test cases, 因此没有时间去搞code review和debugging。不巧的是，我的工作也主要在test cases和automation上，甚至很多manual tests, 但是我还是有时间去搞code review和debugging。那是为什么？

其实我也面对类似的问题。在我要往下一阶段发展的情况下，领导对我的要求是要proactively地工作，要看到别人看不到的，别人没想到的，要做一些创造性地工作，要做一些对整个team有帮助的工作。而具体做什么？怎么做？则完全要靠自己。我就问了类似的问题，我说工作太忙，没那么多时间去想这些问题。领导的回答是要work smartly。是的，我后来分析自己可能一直也算是work smartly, 只是自己形容自己的行为是“偷懒”。虽然我对于自己下一阶段的发展也还处于摸索阶段，但是我想我还是可以回答这个comment, 因为我已经通过work smartly or 偷懒经过了这个阶段。

首先我想说一下公司的工作和个人的发展很多情况下是互相矛盾的。很多人总是想依赖公司去发展，我觉得这是个误区，真正地，起决定性作用的还是要靠自己。比如comments里的这个问题：tester要搞test cases, automation, 怎么去搞code review和debugging呢？那么我的答案就是偷懒，有原则地偷懒。

对于测试来说，我们的目的是用户使用产品的过程中不会遇到问题，而实现这个目的的手段就是找bug，而具体怎么找bug确是非常灵活的，这就是测试工作最大的魅力之一。你从事测试的工作千万不要拘泥于什么测试理论，测试方法等等，一定要有自己的主张和特点。比如有些人的工作是黑盒测试，他就认定了自己不能用白盒测试方法。有些人是手工测试，就认定了不能采用自动化。非得要跳槽找一个白盒，或者自动化的工作才能够开始从事。这是不对的，对于你所负责的模块，只要能找到bug，你应该可以采取任何的测试方法，而即使是专门的白盒测试人员也不能拒绝使用黑盒测试方法，专门从事自动化测试的人员也不能排斥使用手工测试的方法。因为，每种方法自然有它的特点，优势和擅长的地方。只有最适合的测试方法，并不存在最好的测试方法。

由于测试工作是如此地灵活，因此我就可以进行偷懒了，当然我是有bottom line的，那就是一定要保证自己负责的模块不出大问题，就算出大问题一定要有一个合理的理由。而我偷懒也不是真正的偷懒，我是要用省出的时间去进行自我提升以及从事更高技术含量的工作。比如，我在test cases和automation上省出来的时间可以进行code review和debugging, 以及pentest等等。这样的话就发生了很多有趣的现象。有的人追求100% automation, 而我只实现60-70%; 有的人test tool 要写的perfect, 连help都写进去，而我只写最核心的代码；有的人test code 写的很fancy，好像水平很高，而我则认为他是把简单东西搞复杂了，而我更喜欢把复杂的东西简单化。总而言之，在他们尽心尽力做好本职工作的时候，我却把一些精力放在了其他地方。这样长期下来，大家的差别可能就会显现出来。

以上只是个人理解，也许这不是领导所指的work smartly，只是给大家点建议，以及回应这个comment。最后说一下，code review+debugging刚开始是需要花些额外的时间，因为毕竟有learning curve在里边，但是以后的话，这种模式以我自己的经验来看并不比传统的模式更花时间，甚至可能更省时间。这个我可以以后再谈。

我的测试发展路程

大概两年前在51testing上发表了文章《个人测试发展轨迹》，没想到引起了同行很大的反应。原文由于某些原因已经看不到了，而且今天又是自己测试发展的又一个里程碑，因此再把我个人的测试发展路程简单叙述一下，给那些看不到前一篇文章的朋友。

1. 大学本科是一所重点大学，但不是名校。毕业后进入北京一所公司做开发工作，起薪1100月薪。半年试用期后涨到1700。
2. 一年后跳槽到国内一家著名的通信公司做开发，年薪都算上大概10万。
3. 工作半年左右辞职考研。研究生毕业后偶然进入测试行业，年薪跟以前相当。
4. 试用期后提升为team lead，一直工作了大概20个月的样子，工资都有涨动。自己设计实现了一套自动化测试平台。
5. 被美国一家著名软件公司邀请面试，并且成功得到offer，开始全职自动化测试的工作。
6. 工作两年之后开始向高级测试的方向发展。

安全测试系列二：缓冲区溢出(Buffer Overflow/Overrun)

说到安全问题就不得不提BO。BO是安全中最大，最重要的问题，也是最最经典的安全漏洞，它可以使黑客执行任意代码，从而引发EOP的攻击。很多黑客并不太在乎其他的安全漏洞，他们就是想发现BO，从而拥有对机器的控制权。

由于BO这个问题太经典了，耳朵里不知道听过多少遍，因此在面试现在这家公司的时候还专门对BO进行了一些学习与研究，好像明白是怎么回事了。可是到了面试的时候，被别人一问就露馅了。同样，不久前面试了一个即将毕业的硕士生，是个印度小女孩。由于她做过BO相关的项目，因此也对此特意提问，没想到她对BO的理解跟我当年面试的时候也没什么两样，只是知道一点皮毛而已。

四年之前立志投身于安全或者游戏领域，最终是进入了安全领域。在这几年的时间里，我花了不少的时间去研究Web2.0, Mobile等等，并没有花多少时间在安全领域方面。虽然自己测试的是安全的产品，但是跟测试其他的非安全产品并没有太大的不同，只是多些安全的表面知识而已，没有什么深刻的理解。自己也几次问自己，“为什么自己花那么多时间在自己的领域之外，而不把这些时间用于研究自己的领域呢？”其实我心里还是很清楚答案的，那是因为安全对我的水平来说还是太难了，强行去研究它没有兴趣，只有痛苦。而Web2.0, Mobile这些东西就要容易很多，我研究起来也轻松很多，不用花什么时间学习就可以做一些成果出来。

是的，安全领域确实比较难，即使这个BO的理解我也是经过了两年多才觉得算真正的理解了，当然这也完全归于我各种技术的熟悉与提高，综合水平达到了能够理解BO的程度了。总的来说，理解BO也是分很多个层次的，各个层次要求的技术水平也不一样。要想真正理解BO，需要C语言，C语言编译，内存管理，汇编，Debugging，甚至机器码的知识。BO的形式也是各式各样，没有深厚的计算机功底是很难进行分析和利用的。今天我主要回答三个问题：什么是BO，为什么BO是一个安全问题？黑客为什么可以利用BO执行任意代码进而夺取机器的控制权？其他问题我在最后也会列出，留待感兴趣的朋友自己去探索。

1.什么是BO？

BO的概念很容易理解，只需要你有C语言的基本知识就足够了。就是你申请了一段内存，而你填入的数据大于这块内存，这样的话你填入的数据就覆盖掉了这段内存之外的内存了。比如，

void foo(char* input)

{

char buf[100];

strcpy(buf, input);

}

如果input的长度大于100，就会产生buffer overflow了。

2.为什么BO是一个安全问题？

因为黑客可以利用BO执行恶意代码从而控制计算机。我们有这个概念是因为我们常常听到有病毒利用缓冲区溢出的漏洞进行浸入或攻击，这已经成为我们头脑的一个公理似的东西呢。但是如果我问到第三个问题，可能就很少有人能回答上来了？或者是一知半解。

3. 黑客问什么可以执行任意代码？

要理解这个问题就不仅仅需要C语言的知识了，还需要懂得C语言的编译，内存管理和汇编等相关知识。我简单的来解释一下：

在C语言中，当我们调用一个函数的时候，在汇编或者机器码的level是如何实现的呢？假设我们调上边的函数foo的时候，程序的stack将会是下边图表的样子。首先，输入参数会放到栈中去，然后是这个函数执行完的下一个指令的地址，也就是return address, 然后是EBP（这个我现在不解释），再然后就是这个函数的本地变量的内存空间。比如这个函数申请了100个字节的空间。当BO发生的时候，数据就会覆盖掉buf之后的内存，关键的部分是return address可以被覆盖。那么一个黑客就可以把return address的值修改成这个buf的一个地址，比如起始地址buf[0]的地址，而这个buf里边填入黑客自己的代码。这样当这个函数退出的时候，程序会执行return address所指定的代码，也就是黑客的代码了。

 

buf[0]

…

buf[99]

EBP

return address

input

 

既然已经理解了上边的三个问题，如果有兴趣的话可以去思考以下的后续问题：

1. 怎样得到放return address的内存地址?
2. 怎样决定用什么地址来覆盖return address?
3. 什么样的代码应该放入缓冲区，这段代码做什么用，这段代码怎么编写？
4. 有什么措施可以防止缓冲区溢出？也就是说即使发生缓冲区溢出，黑客也不能或者难以利用？
5. 如果对方系统使用这些措施，有什么相应的办法去绕过？

安全测试系列一：用实例来解释安全威胁分类 (STRIDE)

安全测试跟通常的测试工作还是有很大不同的。我认为安全测试是在技术上超越开发人员的一个主要途径。一个合格的开发人员去做测试的工作，无论是黑盒，还是白盒，手工，还是自动化，都不需要他花很多的时间就可以进入工作状态。而对于安全测试，即使一个很有经验的开发人员不经过专门的学习也很难进行有效的工作。另外，一个安全测试人员的水平一般来说应该比开发人员高才对，如果低的话，很难想象你能够容易的发现什么安全漏洞（假设这个开发人员没有低级失误），更不要说什么更深层次的漏洞了。一个安全测试人员应该具备普通开发人员想不到的知识与经验，这样才能通过这些知识与经验去发现这些开发人员犯下的安全错误。我个人在通常的测试工作上已经找不到什么进步的感觉了，更多的是感到重复的劳动，因此我接下来会在安全测试的领域进行一些实践与探索，写一些文章。我不知道有多少人对安全测试感兴趣，不过至少我可以作为一个自我知识的总结与归纳。

黑客大多是凭借自己的兴趣来发现漏洞和实现攻击的，而对于安全测试人员来说是应该有一些系统的概念的，比如到底有什么样的安全威胁，怎么去分类，每类有什么特点，等等。今天我就用几年前我个人的一些经验来解释一些安全的分类。

大概6，7年前，我在一个论坛混，由于一些矛盾使我受到了不公正的对待，比如删贴，封ID等等。我并不是一个喜欢做坏事的人，因此对于黑客的技术从来没有感兴趣过，但是心中还是很不服气。我想作为一个计算机技术人员怎么能让别人这么欺负呢？因此实现了自己一系列的攻击。没想到的是，6，7年之后，在自己学习安全测试的时候，才意识到自己的那次攻击行为竟然几乎涉及了所有的安全威胁。起初的想法很简单，就是编一个程序自动发帖子。OK，这个很容易就实现了，论坛上滚滚都是我发的帖子，当然我用了不同的ID去发，论坛的排行榜经过了多年的积累，在几分钟之后排名靠前的全是我注册的新ID了。用户当然也就无法去正常的访问和使用这个论坛了。然后和他们开发人员的对抗就开始了，他们先是要求发帖的时候根据图片输入一串数字，可惜他们图片的文件名和数字是对应的，我可以轻易的先发一个请求包得到回应包，search里边的图片文件名，然后再发发帖请求。他们的这个办法失效了，并且由于他们自己有bug，使得正常的用户即使输入了正确的数字也常常发帖失败。他们则取消了这个验证系统，转而控制每个IP每个小时只能发帖5次了。虽然很多用户并不满意这个规则，但是还是有效地限制了我的自动程序。我的对应有三种办法，一是使用多台机器，可是我手中没有这么多资源。二是程序控制每小时只发5个帖子，这样一晚上下来也会让论坛看上去很难看。三是动态的去修改自己的IP。Search了一下，但是并没有找到修改IP的有效资料，因此停止了这个方案。当然还有另外一个原因让我停止就是，我发现了他们的一个bug，我可以用任何人的ID去发言。这个bug用起来就很有趣了，我可以以管理员的名字在论坛上发虚假信息，用一个人的ID去攻击其他人引起公愤等等。这个bug他们的开发人员没办法了，他们不知道怎么回事也没有应对的措施了，他们还以为我攻破他们的数据库了呢。后来网站的老总也出面讲话了，他们也没人敢惹我了，这事就算了。另外，我只能使用其他人的ID发言，我也尝试过找出他们的漏洞去使用管理员的权限去做些事情，比如删贴子，封ID，IP等等，不过没有成功。

话说回来，安全威胁分类的英文缩写是STRIDE, 代表了六种安全威胁，分别为Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Services, and Elevation of Privileges.

1. Spoofing 就是伪装，比如我用别人的ID发言就是Identity Spoofing, 我想到用变化IP的办法就是IP Spoofing.

2. Tampering 就是篡改，比如我用别人ID发言的手段就是篡改了合法包，而他们的server端没有相应的检查措施。

3. Repudiation 就是拒绝承认，比如我进行了这些攻击，他们并不知道是我做的，也没有证据是我做的，我就可以不承认。

4. Information Disclosure 就是信息的泄漏，比如他们的那串数字图片就没有任何保护，图片上的信息轻易的就被别人得到了。

5. Denial of Services 就是拒绝服务，比如我的自动发帖使得正常用户无法使用就是这种攻击。

6. Elevation of Privileges 就是权限的提升，比如我尝试用管理员的权限去做事情，就是属于这种。

一般来说，EOP的威胁是最大的，这也是为什么Vista下要加入UAC的功能了，就是为了防御这种攻击。而Buffer Overflow则是可以被利用进行这种攻击的常见安全漏洞，这个问题可以以后再谈。DOS攻击可能是最容易发现的安全漏洞，比如一个AV就可以导致这种攻击。当然DOS攻击也分为两种，一种是导致服务突然崩溃，另一种则是使服务逐渐失去能力，比如在大客户量的时候。第二种就要比第一种更难测试一些了。这些威胁都不是独立存在的，很多时候是互相关联的，比如我是通过Tampering的手段，达到了Spoofing的目的。再比如，你如果成功进行了EOP的攻击，Spoofing, Tampering, Information Disclosure 这些问题也就自然出现了。对于我们安全测试来说,我们一般是对照一个软件模块,通过安全分析,列出各种可能的威胁,并且设计出各种安全的test case去进行测试.

我的测试观点与经验

本书收录了我一年多所写的关于软件测试的文章，内容包含初中级测试工程师工作所涉及到的内容。测试总的来说还是比较简单，我认为作为初中级tester来说，这些文章基本涵盖了应该掌握的知识点，和一定的职业指导与规划。今后我写文章可能不会再涉及这些方面，而会从更高的角度去讨论测试技术与发展，因此把这些文章编辑成册，以方便大家的阅读。

下载doc：《我的测试观点与经验》

下载pdf：《我的测试观点与经验》

Online(Office Live): 《我的测试观点与经验》

Online(Google Docs): 《我的测试观点与经验1》

Online(Google Docs): 《我的测试观点与经验2》