学完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++以后再去学习其他语言的时候的那种感觉。

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

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

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

说到安全问题就不得不提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所指定的代码，也就是黑客的代码了。

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

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

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

大概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去进行测试.

几个月前我还在谈论黑盒测试不一定比白盒测试技术含量低，现在我却可以比较肯定地说，黑盒测试比白盒测试更难，技术要求更高。道理其实非常简单，黑盒，白盒测试的本质区别在于源代码的访问权利，白盒测试具有这种权利，因此也就具有更多的资源和信息进行测试，当然事情就会变得容易很多，而黑盒测试由于不能看到源代码，就使得对于白盒测试人员发现的bug，你要花更多的时间，并且具有更高的技术才有可能发现。

我做黑盒测试已经4年多了，是一个地地道道的黑盒测试人员，可是我具有源代码访问的权利，也就是说，虽然我是做黑盒测试的，但是我所拥有的信息并不比白盒测试人员少。随着我黑盒测试经验和技术的提高，我突然发现我已经完全依赖与源代码提供的信息了，如果没有源代码，我的黑盒测试的工作将会变得复杂很多，困难很多，甚者无法实现。这也让我有了一个强烈的感觉，就是黑盒测试比白盒测试更难。

在Symantec出版的一本书《The Art of Software Security Test》里边就有这个说法。这本书我觉得一般般，但是里边体现着这个道理，就是，“对于白盒测试，一个公司可以组成一个测试队伍来进行，而对于黑盒测试，可能就很少有公司有这个能力了，只能去外边聘请专业的公司来作，这个成本是很高的，但是是值得的”。

经常听到有人抱怨“我在公司是做黑盒测试的，没什么技术含量，我的目标就是转到白盒测试”，我一直觉得这个说法是可以质疑的，也希望看了我的这篇文章以后，不要再出现这种声音，更不要再拿它当成自己不去提高测试技术的一个冠冕堂皇的借口了。

为什么我们大多数人，包括以前我自己都会认为黑盒测试比白盒测试的技术含量低呢？那是因为，我们绝大多数人都是在做低端黑盒测试的。很早以前我就曾想过，黑客都是通过黑盒测试的方法来寻找安全漏洞的，我们怎么能说黑盒测试技术含量低呢？随着自己的水平向黑客的方向接近，自己也越来越有更深，更丰富的理解和体会了。

如果我们把刚进入黑盒测试领域的新人的技术打分为0，而黑客的技术打分为5的话，那么根据技术水平我有这样一个列表：

0.测试新手

1.黑盒手工测试

2.黑盒自动化测试

3.具有白盒测试能力

4.安全测试

5.黑客

大家注意，很多人把自己的测试技术的提高依赖于公司，依赖于team，依赖于project，这是不对的。我本人在公司的工作内容不过就是黑盒自动化测试，可是这并不影响我可以向更高的方向发展，现在internet这么发达，什么资料不能找到呢？各种各样的计算机书籍，网上各种各样的计算机技术交流探讨的论坛，博客等等。很多人觉得跳槽，换个工作自己就能更好的发展测试技术，这也是有误区的。说句实话，个人发展本质上还是个人的问题，并不是公司的问题，或者你的lead，你的manager的问题，一个公司既然要你了，就说明你自己的能力和水平跟公司对你的要求还是比较接近的，公司对你已经有一个期望值了，也就是说你能胜任这份工作了，而再往上的发展并不属于公司对你的期望了，绝大多数的情况还是要靠个人的。因此，我个人认为，无论在任何的工作环境，工作内容的情况，你都是有技术提高余地的，但是这事情要由你自己来drive，而不要太多地依赖外部环境。我从小到大的学习，主要是靠自学，我很少能集中精力地去听完老师的一堂课。包括现在，我很多training都是没听完就走人了，或者有些签个到就溜。我的这个性格造就了我很独立的学习能力，自己为自己规划学习，不知道对大家是否有借鉴作用。

话说回来，因为大家对0，1，2级别应该都是比较熟悉的，我想谈谈3，4，5级别。

3. 作为一个黑盒测试人员，没有人会要求你不具备白盒测试能力，如果你有源代码访问的权利，那很好，你完全可以利用这个优势，把通过查看源代码得到的信息应用到你的黑盒测试中去。如果你没有源代码访问的能力，这也并不能阻碍你在这个领域进行探索和实践。如果你的项目是Java，.NET这种，你可以反编译，如果你的项目是C, C++这种，你可以反汇编。总而言之，所谓具有白盒测试能力的意思是，发现一个bug能够定位到代码里，是什么代码，为什么产生这个bug？可以进行代码级的测试用例的设计。一般来说，这个级别的要求是具备良好的代码读写的能力。

4. 安全测试与白盒测试的根本区别在于安全意识，黑客的思维。有一本书《Writing Secure Code》里面提到“你可以培训一个人具有测试安全feature的能力，你很难培训一个人具有黑客的思维方式，如果你发现了这样一个人，你就Hire他”。在这个级别的人要具有良好的安全意识，知道各种各样的攻击方式，当发现一个bug的时候要就有安全方面的判断，比如“是否一个安全漏洞”，“是否能够被黑客利用”，“严重程度如何”，等等。同样，自己的测试内容里要包含大量的安全测试用例。

5. 黑客级别要求就更高了。对于安全测试来说，只是分析到“是否能够被黑客利用”，而黑客就要分析“如何利用”以及写出攻击代码进行攻击。至少对我而言，他们要具备非常熟练的汇编编程能力。

以前我认为，要想进行安全测试，或者说做高端测试，多年的开发经验必不可少，实践证明也未必。同理，要想进行高端测试，你也未必要先转向白盒测试。从我个人的经历来说，只要你自己有心，只要你自己用心，你总能发展和提高的，外部环境固然重要，但是起决定因素的还是自己。安全测试完全不属于我的工作内容与职责，可是在一个月的时间里，我已经连续发现4个安全漏洞了。如果你在工作中也能够发现你项目的安全漏洞，公司还能如何不重视你？

进入测试领域已经满四年了，最近感觉自己可能有点里程碑似的改变了，因此回顾一下四年的测试技术发展轨迹供大家分享。

有个网友说的很好，从测试的难度上来讲应该是自动化测试<性能测试<安全测试。我从来都是忽略性能测试的，原因也很简单，因为我基本没有从事过跟性能测试相关的工作，谈不上什么理解与感受。但是，我还是能感觉到性能测试的难度确实要大于自动化测试。一两年前还在热烈地跟大家讨论自动化测试的重要性，如何自动化测试等等，现在已经觉得没什么意思了。手工测试，自动化测试，黑盒测试，白盒测试，等等不过都是一种种测试方法而已，我们的目标很简单，就是要发现bug。而在发现bug的过程中，你是不可避免的要用到任何可能的测试方法和测试工具，包括自己编写测试工具。单纯地讨论他们孰优孰劣，哪个更高级并没有根本的意义。下面回顾一下自己的四年测试发展路径。

• 第一个半年忙于手工黑盒测试 （很枯燥）
• 第二个半年开始考虑自动化测试 （很迷惘和无奈）
• 一年之后有一些自动化的ideas， 学习C#, .NET, TestComplete 等等，把自己设计的自动化平台实现 （自己对自动化有一些自己的理解和实践）
• 一年半之后在以前的基础之上开始寻找更高端的测试职位，实际就是寻找专门的自动化测试的职位 （选择面很小，适合自己的也没几家公司，尤其是在国内,被迫出国发展）
• 将近两年的时候如愿以偿，入职自动化测试的职位 （开始把自己对自动化的理解和新的公司和同事交流，发现还是match的）
• 入职之后的一年内，也就是进入测试的第三年，在自动化测试方面有了大量的工作经验 （觉得自动化测试还是比较简单的工作）
• 进入测试的第四年开始按照老板的要求进行debugging 和 code review 的工作 （在自己的feature上做到了测试支柱）
• 四年之后也就是现在忽然发现自己有了比较大的进步，把以前零零散散的东西都能够联系起来了，感觉自己真正的走入了right path。最近一两个月的提升好像顶以前半年的，debugging技术已经比较熟练，code review也觉得比较轻松，并且在debuging和code review的过程中任何不明白的东西都会尽力去搞明白，这样在C语言，Win32，Windows Kernal，汇编，编译，还有Security方面都有了一个突然提升，在脑海里这些东西变得立体起来。也是最近才明白为什么以前director给我的建议是“短期学好C语言，长期也是学好C语言了”。

以前也曾经hack过一个网站，并且在与那个网站的developer的较量中明显占据了上风。以前也曾经发现过security的bug，但是基本属于瞎猫碰倒死耗子的情况。周六晚上突然有点idea,由于太晚就没有回公司。周日早上5点多睡醒脸也没洗就去了公司，一直工作到12点多，file上了bug。其实大概工作了一两个小时就攻击成功，可以远程把一个server crash掉。但是为了弄明白里边的一些情况以及这个漏洞的范围和黑客攻击的难易程度，又花了大量的时间。

终于有了一些安全测试的感觉了，而回想起来也完全是由于前几年测试工作中知识，技术和经验的积累所成就的。以前一直觉得没有多年开发经验的不太可能做到安全测试，现在自己证明也未必，虽然确实不容易。最近两年由于英文的障碍使得自己的发展慢了不少,虽然也是average的速度，有些遗憾。更大的遗憾在于我30岁之前浪费了太多的光阴了，不说大学之前，就是大学之后到30岁的这段工作时间也基本上是浪费，没有真正地去深入过任何领域。30岁之后才寻找到了自己正确的道路，是有些悲哀，但总比没有找到强。我知道很多测试同行都像我以前那样迷惑，迷惘。希望大家在黄金年龄的朋友不要让青春太快的流走，抓紧时间去寻找自己的道路吧。

不久前写了一篇文章<<微软的Principle SDET到底是什么样的牛人？>>. 有个网友问了一个问题,我觉得非常的好,这里想简单解答一下. 这个问题是

“够牛。不过。为什么非要做测试呢。Principle SDET相当于什么职位（与管理职位对比）当了Principle SDET还要受一个小teamleader领导，受得了吗？”

首先，Principle是一个级别，很难跟管理职位相对比，级别主要决定了工资水平。从管理的职位上分，有Principle Team Lead, Principle Manager, Principle Director等等。级别是不会降的，比如如果一个Principle SDET想做Team Lead，那就会是Principle Team Lead，如果想做Manager，那就是Principle Manager。因此对应的是级别，而不是职位。当然各个职位的侧重点不同，比如Principle SDET当然侧重于技术了，未必能一下子转成Principle Manager。但是，可以先转Principle Lead, 再转Manager，从而在管理的发展上能够循序渐进。从我个人的理解上，Principle SDET是不可能转成Senior Lead, 或Senior Manager的，因为这样就降级了。微软的发展一般在早期就会确立路线，技术或管理，因此一般某人会在一条路线上坚持下去的。在高级别的技术和管理来回转的情况应该很少，但不排除有全才在两方面都很出色，当然就可以转来转去了。

由于Principle SDET的级别已经很高了，他们不可能被小team leader领导，至少也得是Principle Team Lead领导。我查了一下这四个人，其中两个是被Principle Test Manager领导，一个是被Partner Test Manager领导，一个是被Test Director领导。因此不存在受不了的问题。

对于为什么要做测试的问题，牛人TV曾经做过一些解释，我个人很赞同他的观点，当然只有牛人才能从这么高的角度去看待测试。

¨Why move from development to test?

• Hardest problems for Microsoft right now are in test
• Test is wide open and needs leaders
• Breaking code is as much fun as building it
• You get to write more code in test (10:1)
• Continuous ship cycle
• Really know the product from the customer perspective
• Get to solve more complex issues earlier in career

我根本不算牛人，我也觉得测试技术含量还是比开发低（从我的层次上看），但是经过了3年多的测试经历，我相对更喜欢测试一些，其中主要的原因如下：

1. 测试的工作非常的灵活：开发相对来说压力太大，PM，TEST都盯着他，程序不能按进度完成就必须要加班，程序的编写一定要按照各式各样的规范，更多的时间是fix bug而不是write code。而测试人员的工作就没有太多固定的模式，完全可以按照自己的想法去进行，比如自己安排自己的时间，进度，自己决定什么case手工，什么case自动化。自己可以选择自己喜欢的测试工具，编程语言等等。
2. 测试的生命周期更长：开发一般专注于某种技术，或者某类技术。一旦市场上淘汰这种技术，他们就存在很大的转型的痛苦。并且，想跨行业跳槽也相对来说很困难。而测试一般不需要对某种技术做非常深刻的研究，因此有大量的时间去接触其他的技术，加上测试工作对技术的深度要求不算太高，转行相对要容易很多。因此，测试人员搞技术的生命周期更长，职业发展也更灵活。
3. 测试行业还很不成熟，里边有大量潜在的机会。
4. 测试人才相对来说比开发水平要低，因此更容易上位。

测试的缺点：

1. 毕竟工作技术含量有限，在公司的重视程度不如开发
2. 职位的晋升和工资的水平相对开发还是有差距
3. 测试行业的普遍环境还不是很好，仅仅几个大公司才能给你充分发展的机会

我个人的想法是要测试，开发两手抓，两手都要硬。在大公司搞测试挺好，万一因为什么原因离开大公司，去小公司就要做开发了，因为我不相信小公司能给我提供发挥我测试技术的平台。

如果你要问起微软的测试人员关于Senior SDET的话，可能很多人都会说没见过，或者很少见。如果你要问起微软的测试人员关于Principle SDET的话，可能立即就会有人指出微软不存在这样的人。可见，在微软Senior SDET都是凤毛麟角，就更不要说Principle SDET了。那么微软到底是否存在Principle SDET呢？如果存在，他们又会是什么样的人呢？这是很多人心里的一个很大的疑问，尤其是对于想在技术这条路上（区别于管理的路）提升自己的测试工程师。本人有幸接触到几个这样的牛人，这里我想分别从他们的教育背景，工作经历以及他们对于测试人员的建议来归纳总结一下。里边有些人的背景可能离我们很远，我基本上是由远及近的顺序来介绍。

• TV

教育：本科三学位：计算机，数学和物理 （是不是很牛呢？）研究生：计算机硕士

Before MS: 第一家公司做操作系统开发，第二家公司做应用科学家，研究领域包括图像处理，编译器以及模拟器，第三家公司做卫星分析工具的开发

MS: 2001年加入微软做开发lead， 创新一种高速远程文件系统，并且获得操作系统和数据库方面的专利无数，后转行做Principal SDET。

建议：

1.Deep product and scenario knowledge (personal knowledge, customer interactions)

2.Strong analysis skills (RCA, Debugger, cause-effect)

3.3P’s – Persistence, Passion, Positive Attitude

4.Leadership skills (vs management skills)

5.Fast learner and willing to share that knowledge with others

总结：

这位无论从教育背景还是开发背景都是牛的不得了。本科的计算机，数学和物理的三学位就可见他的个人能力是多么的突出了，加入微软之前的开发经验也不是闹着玩的，因此进入微软就是team lead。在微软的成就也不是一般人所能比拟的。这种人想做什么不行呢？

• JM

教育：本科

Before MS: 一年开发

MS: 1996年加入微软做测试，然后lead，中间曾经做过测试经理，然后又回到测试lead, 一共在五个不同的team做lead/manager之后，做Test Architect，最后做到Principle SDET

建议：

1.Dependable

2.Productive

3.Persistent

¤“Relentless individual contributor” – a prev. mgr.

4.Pragmatic / Analytical

5.Maleable / Adaptive

总结：

这位测试和管理的经验都极其丰富，在微软这么多team都混过，这么多职位都混过自然很不简单。都已经做过测试经理了，虽然跟上边那位好像还有差距，不过做Principle SDET也是顺利成章了吧？

• BK

教育：本科双学位：计算机和机械

Before MS: 在三家公司做过，包括医疗，网络设备等等。具体工作内容不详。

MS: 加入微软９年，一直工作在一个team

建议：

1.Ensures tests owned are highly reliable and stable

2.Possesses in-depth component/feature knowledge

3.Possesses strong debugging skills (can narrow down issues)

4.Works towards continuous self-improvement

5.Provides critical feedback during Spec / Design reviews

总结：

这位在微软一个team一做就是９年，真是兢兢业业呀。从我对他的接触来看他，他在技术以外的东西也非常厉害。有时间我好好整理一下他的语录研究一下。

• LV

教育：计算机本科

Before MS: 罗马尼亚计算机研究所工作１３年，具体工作内容不详

MS: １９９７年加入微软做测试，其间换过三个ｔｅａｍ

建议：

1.Possesses in-depth product knowledge AND is big picture expert as well

2.Most of the time works in pro-active mode (anticipates rather than reacts)

3.Able to generate support from others in order to achieve the desired outcome (impact and influence)

4.Understands the business

5.Demonstrates strong leadership skills

别的不说，他加入微软之前就已经在研究所工作１３年了，加入微软也已经１１年了，２４年的工作经验做Principle SDET是不是会水到渠成？请问中国有人踏踏实实搞技术这么多年的人物吗？

最后说一下，好好看看他们的建议吧。有几点都是好几个人不约而同提到的，对我们会有很大帮助的。

经常听到有人说"我现在做手工测试,技术含量低,想转到自动化测试",也有人说"我现在做黑盒测试,技术含量低,想转到白盒测试".手工测试或者黑盒测试就一定技术含量低吗?其实并不见得.自动化测试或者白盒测试就一定技术含量高吗?其实也不见得.这里我想简单谈谈我的看法.

测试的分类目前我感觉并不成熟.比如,你分为黑盒,白盒就不是非常科学,也不能适用于所有的情况,因此出来一个模糊的灰盒的概念.灰盒介于黑盒,白盒之前,但是具体一个人从事灰盒工作到底有多少是白盒内容,有多少是黑盒内容,里边的差别可就大了.把测试简单地分为手工和自动化也并不是非常科学,与黑盒白盒类似,有很多测试也是很难归于手工或者自动化,实际上应该是介于手工和自动化之间的测试也是很多的.因此,与灰盒的概念类似,还应该存在一种测试,我暂且叫做半自动化测试.以上我想说明的是,测试目前很难简单地被分类,而你所从事的测试工作也不应该简单地就归于哪类.下面就谈谈我觉得怎样分类可能更科学,更能体现实际的情况.为了说明方便,我就暂且不谈灰盒和半自动化测试.

请看下表，我把测试分为了４大类。其实我们所谓的技术含量低的测试主要指的是“黑盒手工测试”。为什么说他技术含量低呢？因为黑盒测试不需要懂代码，手工测试不需要会编程。总的来说就是不需要编程能力。当然做黑盒手工测试的人未必就水平低，黑盒手工测试也未必就代表技术含量低。请注意，我先前所说的是不需要编程能力，不代表编程能力甚至软件开发的高级能力不能在黑盒手工测试中派上用场。也就是说，如果一个人软件开发能力很强，他即使只用黑盒手工测试也照样可以做出高技术含量的工作，或者说找到高难度的ｂｕｇ。最显著的例子就是黑客了，那些具有高水准的黑客高手很多情况下都是在没有源代码的情况下通过工具的使用来发现那些安全漏洞。区别在哪里？区别就在于他们的技术比我们一般的黑盒手工测试人员的技术不知道要高多少倍。因此，我的意思是，在测试的工作中采用什么测试方法并不能决定这个工作技术含量的高低，高水平的人无论用什么方法都能做出高质量的工作出来。通常我们都会选用最适当的测试方法来进行工作，而我所强调的是不要把注意力过多地花费在测试方法上，而更应该注重提高自己的个人能力，尤其是编程，软件开发的能力。

另外我想说的是，做手工测试的人也未必一定要转到自动化，你也可以向白盒手工的方向发展，而做黑盒测试的人也未必一定要转到白盒，你可以向黑盒自动化的方向发展。当然了，一个黑盒手工测试人员无论是从横向（黑盒自动化），还是纵向（白盒手工），又或是垂直（高级黑盒手工测试）发展，都是离不开软件开发能力的，这也是为什么我一直强调编程能力的原因。没有良好的编程水平，就只能限制在了低级黑盒手工测试这个范畴了（管理发展路线除外）。

当你具备了比较强的开发能力之后，你再回头看这些测试方法的时候，你应该会头脑清晰很多。正像很多人说的“白盒代替不了黑盒”，或者“自动化代替不了手工”那样。是的，每种测试方法都有自身的优势，都是不可替代的，一个测试人员没有必要去强求只在一种测试方向去发展。一个高级测试人员应该是所有的方法都会，而且能够选择最恰当的方法去进行测试。而一些黑盒手工测试人员也不应该由于黑盒不可替代，手工不可替代，就不去学习与了解自动化或者白盒测试技术，更不应该去贬低自动化测试。

总而言之，测试的方法是多样的，测试的发展也是多姿多彩的，敞开你的胸怀去了解与学习更多的测试技术吧。了解的越多越好，理解的越深越好，这样才能使你在测试的工作中如鱼得水，胸有成竹。测试没有最好的测试方法，只有最恰当的测试方法，多了解一种测试方法，你就多增添一份工作能力。

常常碰到有人做黑盒测试，觉得技术含量低，想向白盒测试的方向转。这里我想谈一谈是否白盒测试就比黑盒测试技术含量高呢？我的看法是未必。前几天参加了一个黑客会议，发现几乎100%的黑客都是通过黑盒测试的方法发现系统漏洞的。道理其实很简单，软件厂商不可能给黑客看源代码，因此黑客只能进行黑盒测试。那么问题就来了，既然黑客基本都是做黑盒测试的，那么我们怎么能说黑盒测试的含量低呢？

其实不论黑盒测试，还是白盒测试只是一种测试方法而已。而测试水平的高低往往不是用使用什么测试方法而区分的，更主要的是要看测试人员自身的水平如何。所谓水平，不仅仅是测试水平，而是对整个计算机技术的一个综合水平，包括了方方面面。诚然，白盒测试的门槛要比黑盒测试要高，可是如果想在测试行业发展，想向更高的水平迈进，未必一定要转向白盒测试。并且，白盒测试也是分水平的，如果你在黑盒测试不能达到一个高水平，你又怎么能说到了白盒测试就会达到一个高水平呢？何况，白盒测试也未必就比黑盒测试更有意思。

测试的意义在于在现有资源的情况下，能够找出更多，更深入的bug。如果我们有察看代码的权利或可能，白盒测试是一个非常有效而重要的方法，如果我们没有查看代码的权利和可能，我们只能进行黑盒测试，可是我们还是能有很多东西可做的，最简单的就是自动化测试。更深入的我们可以采取黑客常用的测试方法进行测试，比如fuzzing。据统计，70%的安全漏洞都是通过fuzzing test发现的。

最后说一下个人的建议。还是那句话，想做好测试，想做测试牛人，是需要计算机技术综合能力的，不仅仅是什么黑盒测试，白盒测试，自动化测试这些测试方法的掌握，更重要的是开发的功力，系统内核，等等更深入技术的精通。那么对于测试人员来说，不要以为转去搞白盒自己就能一步登天了，抓好计算机的基本功，学习更多，更深入的计算机知识才是关键问题。

希望做黑盒测试的同仁不要弃垒，继续努力，黑盒测试做好也是很有前途的．

不久前参加了一个座谈会。这个座谈会邀请了公司里在测试领域发展非常出色的华人，基本都是test manager，来给大家解析一些测试发展的问题。由于可能公司没有华人做到test director的职位，因此他们可能已经达到了华人在测试发展的最高点了。他们应该是很牛的人，为什么呢？举个例子，我知道两个普通的测试人员回国就是两个大公司的测试director。而这两个人跟他们的差距还是很大的，可见他们如果在国内应该是多么牛的地位。当然了，他们在世界的测试领域来说也应该是佼佼者了。座谈会的焦点没有任何意外地集中在了开发与测试的比较上边来了，这个话题也是多人曾经探讨过，我个人也发表过一些自己的看法的。这次想总结一下从他们的观点中透露出来的信息以及个人的一些自己理解。

首先说明的是，测试发展的两条路还是管理和技术，由于真正能在管理上发展的像他们那样成功的人实在是太少了，尤其是在公司的内部，因此焦点还是放在了技术发展上。其次，与绝大多数公司不同的是，这里的工资是按照级别而不是按照工种来区分的。简单地说就是，同一个级别的开发与测试的工资是相当的，因此在技术发展的焦点上就放在了级别的提升上。下边是个人的一些总结：

1. 他们承认测试发展的ceiling是比开发要低的，比如VP测试出身的只有一个，还说了个什么我没听明白，测试的一个没有。当然这个对个人来说没有什么问题，我想基本没人能够发展到reach到这个ceiling。
2. 测试的senior比例是比开发要低。
3. 测试senior比例低的主要原因是很多人没有达到senior就转成开发了。
4. 测试通过自己的提高是有机会达到senior的
5. 测试从junior发展到中级跟开发是没什么区别的
6. 测试从中级发展到高级的时间是一年半到never
7. 他们见到很多人在中级呆了很长时间，比如10年，还是停留在这个级别，因为自己不努力了。

从以上的简单总结我们可以看出，首先测试的发展跟开发相比是处于劣势的，其次，通过个人的努力测试是可能跟开发平起平坐的。这里边就牵扯到一个问题：怎样通过努力去达到senior？这里边又牵扯到了另外一个问题，为什么很多人测试没有达到senior就转成开发了？他们如果不转成开发是否就能达到senior测试呢？因为他们说很多人10年都到不了senior。

他们的解释是可以做安全测试呀，可以考虑客户的需求呀，等等，等等，去往senior发展。我想说说自己的理解：

1. 我见过的senior确实很少，因此可能理解不够全面，可是我感觉他们应该是具有多年的开发经验的。也就是说，他们今天能够到达senior这个级别是和他们多年的开发功力密不可分的。
2. 由于公司是按照级别来给工资，里边的现实是，如果你想达到senior的级别，你的水平要和senior的开发相当才行。一个做测试的人，怎么才能达到与senior开发水平相当呢？除了以前有过多年的开发经验，否则是一件非常困难的事情。困难的地方就在于，测试相对开发来说还是一个比较简单的工作，在每天做这种相对简单的工作中是不可能像开发人员得到同样的水平进步的。
3. 确实测试里边也有很多高端的测试工作或技术，比如安全测试。可是测试总体来说还是比较简单的，你的老板不太可能会给你时间去学习和分配高端测试的工作给你，否则那些简单的测试谁来做呢？因此，在工作任务的压迫下，使你转向做高端测试的机会变得比较渺小。
4. 当然你自己可以去努力，花大量的业余时间去提高。可是这里边还有两个问题，一个是你是否能长期坚持，因为这不是工作驱动的，人很容易偷懒或者放弃。第二是谁来指导你？如果你身边很少senior的测试，你被指导的机会就会远远小于开发人员。
5. 这也就算解释了为什么测试人员要转到开发，很大程度上是不得已而为之，如果想继续往上发展的话。即使一个人非常的热爱测试工作，他如果想往上继续发展，走向开发，或者走向开发再转回来都变得是一条更现实的路。

因此，我还是鼓励大家，如果有机会做开发，或者转开发就不要犹豫，如果没机会，也要尽量地去学习一些开发知识。这些对测试的长期发展是很有好处的，我本人也是得益于以前有两年的开发经验。

常常听到有人抱怨说公司不重视测试，不重视测试人员。没错，这个在小公司是非常常见的现象。其实，即使工作在大公司，虽然测试和测试人员的地位得到了很大程度的提高，可是相对开发和PM的地位还是有一定的差距，也就是说测试在公司中的地位还是比较低的，这个其实是不争的事实。道理也很简单，测试人员的技术水平，测试工作的难易度和测试在产品开发过程中的相对地位都决定了这个现实。由于测试的性质造成了相对的地位低下，那么如果想使得自己作为一个测试人员在公司或者项目组的地位得到提高，一个行之有效的办法就是超越测试的工作范围。简单来说，一个测试人员在工作中的重要性的大小不是仅仅由测试的工作范围来决定的，更重要的是你能够在多大程度上去cover开发和PM的工作。我知道在很多很多公司，包括很多大公司，都不需要你这样去做，我也不期望很多测试人员会这样去做。可是我最近理解到，去take开发和PM的responsibility对于个人的发展是多么的重要。由于各个公司的测试情况千差万别，个人的测试发展之路也是各式各样，这里主要是谈个人的理解，很可能只适合少数测试人员。这里先讲一些事例：

1。本人以前在一个世界前几软件公司中担任team lead, title是senior SQAE，来到现在的公司是按照最低级别录用的，也就是entry level。为什么差别这么大？主要是各个公司对测试人员的要求差别太大了，这里如果只是满足测试的工作内容的话，都很难升入中级，我可见到不少水平不错，工作好几年的员工连个中级都不是呢。可是这样的员工跳到国内的公司就有做director的。

2。以前也给大家介绍过我问director测试应该如何发展，他的回答是“短期要学好C，长期还是学好C”。可见他的回答完全跟测试没关系，应该是完全是开发的范畴。

3。在一次会议上有人问director的老板，测试senior的实在太少了，如何才能发展成senior。他的回答主要是强调测试人员要更加的贴近客户，从客户的需求去考虑问题，不能局限于技术。可见他强调的又是PM的范畴。

4。自己的老板对自己提出的要求也是完全超出了测试的范畴，基本点如下：

• Debugging: find root cause of a bug （开发）
• Code review （开发）
• Answer customers' questions (PM)
• Researching competitors' products and showing options in functional spec (PM)
• Don't only focus on my components, responsible for whole feature

5。一个印度PM同事就很牛，工作就是超出PM的范畴，开发的东西他知道底下具体是如何实现的，出了什么问题他都能估计出可能是什么问题。测试的设计他也能提出很多好的建议，很多测试的case也得请教他。他就升的特别快，几乎一年至少一级的往上升，最近发现都senior了。

以上的例子只是想说明作为一个真正出类拔萃的测试人员各方面的功力都不能少。很多人还在争测试，开发的地位高低，水平高低。其实对于高级的测试人员和高级的开发人员来说，他们的技术视野都应该是比较一致的。因此，如果作为一个测试人员真的想提高自己的地位，就不要把、开发和测试对立起来，要把他们融合在一起才对。最后想说的是，能够把这些都做好的人不会太多，那个印度PM也算是很少见的了，他是真的很努力，负责。我本人以前也习惯性的局限在自己的任务范围之内，看到是其他人的工作就不管了，幸亏得到老板的指点，最近无论是什么问题，只要是跟自己产品相关的都积极主动地去关心，思考和处理，感觉进步很大。也希望能尽快的达到老板的要求，就是“只要是这个产品的问题，别人第一时间就会想到去问你”。我想这个时候，自己的重要性也无需争辩了。

以上是一些个人心得，不知道是否对大家有帮助。

最近父母来美国访问，大部分时间都陪他们到处游玩，因此也没有写任何新的文章出来，今天还是老声常谈。从写测试文章以来就陷于自动化测试话题的漩涡中，虽然我觉得这个话题对我来说已经没有任何讨论的意义，可是还是怕很多反对自动化的文章对大家产生误导作用。以前的文章我主要是从技术的角度来讨论，而且从这个角度我认为我已经基本表达了所有我对自动化测试的理解，那么今天我就从业内实际的产品测试的范例来谈自动化测试的重要性。

众所周知，微软的Windows Vista投入了6000工程师，花费了5年的时间来进行开发，不夸张的说，这是人类历史上规模最大的一次软件产品的开发。因此，对于Windows的测试流程是非常值得拿来进行研究的。今天我也想从我自己了解的一些情况来简单的谈一谈。

首先，微软没有专门的手工测试人员，基本全部是自动化测试人员。微软的一个测试人员的测试用例大概是其他公司3，4个人的数量。我们知道测试量不能仅仅用测试用例的数量来衡量，还有一个测试周期的问题。而Windows的测试周期是一天，甚至有的时候不到一天。其他公司的测试周期一般至少要一个星期。那么微软一个测试人员一天的时间要完成其他公司3，4个人一个星期的测试任务，听起来是不现实的。那么他们是怎样完成的呢？下面我从纵向和横向来分析。

纵向来看，由于Windows开发团队的规模宏大，使得他们的组织一定要分层，分级的。最高层的build就是在市面上发布的build，而每一个部门都会有自己单独的build。平时的开发和bug fix都是在自己的build中来进行的，经过测试人员的sign off才能传送到上一级的build。而一般来说，都是分3或4级的。也就是说，每一级的build你都需要进行测试，而每一级一般每天都会出一个新的build。那么最多每天你需要测试4个build，大家想想，如果不采用自动化，只是纯手工的方式，如何能够完成呢？而实际上，Windows聘用了大量的外包人员，他们专门安装每天出的新build，并且运行测试人员的自动化测试程序，然后把测试报告发布出去。而测试人员得到报告以后，要分析任何的测试错误，进行相应的处理。一般来说，错误分三种，测试环境的问题，测试程序的问题，产品的问题。测试环境的问题要外包人员来负责，测试程序的问题要报测试的bug，自己解决。产品的问题，当然就要报产品的bug由开发人员来解决了。这种模式就使得测试人员能够把测试的开发和运行分离开来，使得测试人员能够专注于测试的开发工作，也就是说测试人员大部分的时候是在coding中。这也是为什么微软的测试人员title是SDET(software development engineer in test), 也就是说微软的测试人员本质上就是开发人员。

横向来看，Windows的测试根据时间的长短和重要性分成很多种。以上所说的是测试每天的build，在自己部门的build往上一级传送之前的测试又是一种，还有一种是要测试一个build使得质量可以使得微软的员工进行内部的使用，还有就是每个milestone的测试，以及release之前的beta, rc阶段的各种测试。因此，测试用例的优先级在这里就显得十分的重要。由于各种原因，往往不能100%的进行测试用例的自动化，因此手工测试还是必不可少的。如果我们把测试用例按照优先级分为P0-P3。那么一般来说，P0和P1的test case是一定要实现自动化的。那么对于P2和P3的手工测试，就只在非常重要的测试阶段来进行。在每天的测试，和不太重要的测试阶段，也没有要求保证全部的测试用例要通过。这样的安排，就使得SDET能够尽量少的去执行手工测试，从而能够专注自动化测试的开发和对产品进行更加深入的测试，以及安全测试等等。一般来讲，需要进行手工测试的情况的发生周期要大于一个月，而因为SDET平时尽量的能自动化更多的测试（包括P2和P3），手工测试往往需要2天的时间就能完成。

从以上纵向和横向的分析来看，Windows的测试任务是十分浩大的，纯手工测试也是无法想像的。可是，由于微软大量的采用自动化测试技术和人才，使得不可能变为可能，实在是做了一个自动化测试软件工程的典范，值得任何公司和个人去思考。

SYSTEM帐户是系统中的“太上皇”，其权力甚至凌驾于管理员之上，很多操作系统的组件（例如SMSS、winlogon等），还有许多服务，都以SYSTEM身份来运行。在我们登录系统之前，SYSTEM帐户就已经存在于系统上。在命令提示符下运行PsLoggedOn命令，可以看到SYSTEM帐户已经在本地登录，如下图所示。
本文将介绍以SYSTEM身份运行应用程序的方法，在讲述之前，先说说为什么要这样做，原因有二：
⑴ 不少系统资源只有SYSTEM帐户才有权限访问，例如HKLM\SAM注册表项和系统还原的工作目录C:\System Volume Information等。如果能够获得SYSTEM权限，就可以访问这些原本只向SYSTEM帐户“特供”的系统资源。
⑵ 如果应用程序可以运行在SYSTEM上下文，则该程序可以在注销以后继续运行，方便我们执行一些特别任务。
本文介绍三种提升进程运行特权的方法，以帮助读者更好地利用SYSTEM帐户（本文假设在Windows XP Professional上进行操作，并假设所涉及的命令工具都安装在默认路径）。
1．PsExec命令提升进程特权
我们可以借助PsExec命令工具以SYSTEM身份运行进程。我们已经知道只有SYSTEM帐户才能访问C:\System Volume Information文件夹，所以这里可以借助PsExec命令打开CMD命令提示符窗口，然后在命令提示符下运行DIR命令查看该文件下的内容，步骤如下：
⑴ 以管理员身份登录系统，打开CMD命令提示符窗口。
⑵ 在命令提示符下运行以下命令，以SYSTEM帐户身份打开另一个CMD窗口。
PsExec -i -d -s CMD
⑶ 在新打开的命令提示符窗口下运行以下命令：
DIR /a "C:\System Volume Information"
即可查看C:\System Volume Information文件夹下的内容，如下图所示。这说明当前的命令以SYSTEM帐户身份运行。
提示 如果对以上结果有所怀疑，可以打开任务管理器，然后在“进程”标签页查看CMD进程的用户是否为SYSTEM。
2．AT命令提升进程特权
由AT命令启动的计划任务，默认以SYSTEM特权运行。这里举个例子，借助AT命令以SYSTEM特权启动注册表编辑器，以便查看HKLM\SAM注册表项。
⑴ 以管理员身份登录系统，打开CMD命令提示符窗口。
⑵ 假设当前系统时间是13:19。
⑶ 然后运行以下命令，让系统在13:24时自动启动注册表编辑器：
at 13:24 /interactive C:\WINDOWS\regedit.exe
命令参数/interactive表示以交互模式启动注册表编辑器，必须加上该命令参数，否则将无法看到启动的注册表编辑器。
⑷ 到了下午13:24，就会自动用LocalSystem帐户的身份启动注册表编辑器，然后尝试访问HKLM\SAM注册表项，现在应该可以看到其下的内容。
提示
  ⑴ Internet上的某些脚本文件声称可以提升系统权限，其实质就是运用AT命令。
  ⑵ 尽管可以用“Schtasks /ru SYSTEM”命令以SYSTEM特权运行某个进程，但是这时候无法以交互模式访问进程，也就是说我们无法看到以SYSTEM特权运行的进程。
3．把应用程序安装为服务
由于服务可以运行在SYSTEM特权下，所以我们可以将应用程序安装为服务，并且使服务以SYSTEM帐户的身份运行。举个例子，我们可以将注册表编辑器安装为服务，以SYSTEM帐户身份运行。

很多人理解的自动化就是把手工测试case用脚本和工具转变成自动化测试。也就是说把手工测试的每一个步骤用脚本来模拟，从而执行test case。那么自动化的所有问题就归结于，如何用工具和脚本来转化手工操作步骤了。还有很多非常senior的，但是不会coding的手工测试工程师强调case的design能力是如何如何重要，自动化相对来说不是那么重要。我这里可以肯定的说，没有好的编程功底，你也不可能涉及出非常好的test case, 自动化的开发也不应该是仅仅把手工操作用脚本来模拟，而是应该大幅度的改变test case，使得能够用最好的方式来进行自动化。那些手工测试人员所谓的设计case的重要性，和他们设计case的高水平，实际上只是在他们的知识范围之内产生的观点。下边我用一个小例子来说明，编程能力在自动化过程中起的作用到底有多大。基本上来讲，有多强的开发水平，就有多强的自动化设计，实现水平。自动化开发和产品的开发实际上都是一样的，都是有需求，你来实现。当然，不同水平的人，实现起来的效果是千差万别的。这也就是为什么开发有高手，有低手，自动化测试的开发也同样有低手，有高手。自动化测试水平没有上限，你要学会发挥自己的无穷潜力。

不多说了，现在说一下我们要自动化什么问题。我们有两个计算机帐号，A和B。我们需要用B帐号进行系统的设置，也就是测试的准备工作，然后用A帐号来进行测试。下边来说一下不同水平的人是如何进行自动化的。

1. 手工测试人员

• Log on B
• Configure
• Log out
• Log on A
• Test

2. 初级自动化人员（直接把手工case转成自动化）

• Set autologon B
• Set autorun
• Record test status: 0
• Logout
• Check status

if(status==0)
{
    Configure
    Set autologon A
    Record test status:1
    Logout
}

if(status==1)
{
    Test
}

这个级别的人，需要懂得脚本编程，需要懂得系统设置，autologon and autorun。

3. 有一定经验的自动化人员（改变手工测试case以利于自动化的更简单，可靠的实现）

• 不需要log out and log on
• 利用Windows命令Runas
• 用高级语言调用Runas
• 利用重定向来输入Password

这个级别的人，需要懂得高级语言，重定向，Windows系统命令Runas

4. 中级自动化人员（具有更丰富的开发经验，可以用程序代替UI和系统命令）

• 不需要Runas命令
• 利用.NET的Process对象
• 用B的身份生成一个Process来进行配置工作

这个级别的人，要比较熟悉高级语言，比较熟悉高级语言的类库，懂得操作系统的内核基本概念

5. 高级自动化人员（精通高级语言，精通操作系统内核）

• 不需要多生成一个进程
• 用本线程impersonate用户B
• 利用.NET WindowsIdentity 对象
• 必须要调用Windows API，LogonUser

这个级别的人，要精通C/C++和Java，C#等高级语言，精通Windows内核的知识和Windows API

从以上的例子可以看到，针对同一个test case，不同的测试人员，从手工到高级自动化，由于自己知识面的原因，会设计出非常不同的case出来。越高级的自动化越灵活，稳定，可靠，也更需要掌握更多的开发和内核的知识。因此，我们看到很多人在强烈的否定自动化，你先看看他到底在哪个层次中。越下边层次的自动化人员，由于技术的原因，碰到的问题会越多，能解决的问题却越少，因此对自动化的抱怨也就越大了。这些都是可以理解的，不过以此来否定自动化，我觉得还是不太应该，毕竟自己技术还不过关。

随便用一个小例子来解释一下ＵＩ自动化的开发吧．

我先现在有一个Ｂｕｔｔｏｎ是ｄｉｓａｂｌｅ的状态，一旦Ｂｕｔｔｏｎ　ｅｎａｂｌｅ，我们就Ｃｌｉｃｋ弹出一个窗口．

我们使用的测试工具就有同步的功能．

1．自动化工具生成的程序（发现和操作控件，不能真正运行）

button=FindButton();　

ClickButton(button);

2．傻瓜的自动化程序（通过加入ｓｌｅｅｐ变成可以运行的程序）

button=FindButton();　

Sleep(10);

ClickButton(button);

Sleep(10);

window=FindWindow();

3．简单的自动化程序（加入同步，使得更可靠和有效率）

button=FindButton();　

WaitButtonEnable(button);

ClickButton(button);

window=WaitWindowOpen();

4．完整的自动化程序（保证１００％可靠,没有测试程序ｂｕｇ,简单写了一下，没有包含exception的控制，时间急，可能也会有错误，不过就是这个意思）

Button button=null;
for(int i=0;button==null&&i<3;i++) //如果FindButton不稳定，调用三次in case
{
    button=FindButton();
    if(button==null)
    {
        Log.Error("Tryout{0}:Can not find button",i); //测试工具不稳定
    }
    else
    {
        break;
    }
}

if(button==null)
{
    Log.Error("Cannot find button. Quit"); //测试工具找不到button，或者产品问题
    Log.Screen();//截图,只是为了示例,以后不再单独写
    return;
}

if(！WaitButtonEnable(button))
{
    if(button.Enabled==true) //测试工具问题，没有得到enable的消息
    {
        Log.Error("enabled, but tool didn't detect");
    }
    else//测试工具问题，不能成功检测button的状态，或者产品问题没有enable
    {
        Log.Error("don't enable");                      return;                                                                                                                                                                                                                                                                                                                
    }
}

Window window=null;

for(i=0;window==null&i<3;i++)//ClickButton不稳定，或者没有得到open event，或者产品问题
{
    ClickButton(button);
    window=WaitWindowOpen();
    if(window==null)//没有click或者没有得到消息，或者产品问题
    {
        int count=0;
findwindow://FindWindow不稳定，重试3次
        window=FindWindow();
        if(window!=null) //没有得到消息,但是窗口弹出
        {
            Log.Error("didn't get event");
            break;
        }
        else //没有click，或者产品问题, 或者FindWindow不稳定
        {
            Log.Error("Tryout{0}:didn't get window",i);
            count++;
            if(count>3)
            {
            }
            else //FindWindow不稳定，workaround
            {
                Log.Error("goto{0}",count);
                goto findwindow;
            }
        }
    }
    else //成功
    {
        break；
    }
}

if(window==null)
{
    Log.Error("didn't get window, maybe tool or product problem.");
    return;
}

最近还是发现有一些文章，个人对于自动化测试报有很大的怀疑态度，本人也对相关的文章给与了驳斥。我个人和公司对自动化测试都是报有很积极的态度的。这里我想再次的写一篇文章来阐述到底UI自动化测试可以做什么，作为一个优秀的UI自动化测试工程师应该具备有什么方面的技能，以及本人对UI自动化的一些经验和体会。

首先还是要强调一点，API和command line程序都是非常适合用自动化来进行测试的。我想这个观点，即使那些反对自动化测试的人也不应该否认吧？至少我觉得他们应该有这个意识。因此，对于他们反对自动化就集中在了UI自动化方面，我这里也完全站在UI自动化测试的角度来写这篇文章，后边就不再强调了。

再次套用朋友的一句话，＂自动化测试听起来很神秘，学起来很简单，用起来很麻烦＂。我想有过自动化测试经验的人，可能大多都有这个体会吧？前边的过程我就不提了，以后主要探讨为什么用起来会麻烦和怎样简单化自动化测试。总而言之，想搞好自动化测试，还是需要测试人员比较高的技术水平，尤其是编程能力和解决问题，分析问题的能力。

首先，我要谈谈自动化测试工具和编程语言的关系。作为一个优秀的自动化测试人员，他的最基本的能力就是编程水平了。所谓编程就是至少要精通一门高级语言，比如Ｊａｖａ，Ｃ＃等等，脚本语言不计算在内。请记住，不是熟悉，是精通。高级编程语言给我们提供很强的能力来实现一些东西。你所精通的语言能力越强，你在自动化测试可以做的事情就越多，越好。简单来讲，论程序的能力来排序是这样的，测试工具－〉脚本语言－〉高级语言（Ｊａｖａ，Ｃ＃）－〉Ｃ／Ｃ＋＋－〉Ｃ＋＋／ＣＬＩ。根据这个语言能力的排序，结合你自己的语言能力，你可以想想你到底具备多少自动化测试能力。我所强调的是，如果你想优秀，你至少要精通一门高级语言，这是必不可少的。如果很多人还只是用测试工具，脚本语言工作而抱怨自动化，我要强烈的建议他们好好去学习一下编程能力先了。他们的问题在于，由于编程能力的不足，使得自动化测试的很多问题没有能力和办法去解决。再谈一下自动化测试工具，无论哪种测试工具，无论他们设计的多么强大，从编程语言来讲，他们最多能够达到脚本语言的能力。也就是说，如果你完全用测试工具来进行自动化的开发，很多问题你还是无法解决的。因此，我推荐的自动化开发方法是高级语言结合测试工具。我的自动化测试逻辑是，用测试工具只是完成ＵＩ操作，其他部分完全用高级语言来实现。我们不能否认高级语言所具有的能力，他们创造出了世界上这么多丰富多彩，这么多优秀的软件，难道开发测试程序会有问题吗？因此，我们的焦点就落在了测试工具的ＵＩ操作部分。

第二，关于测试工具。开发语言重要，选择一个合适的测试工具也同样的重要。一个灵活，强大的测试工具可以使你的自动化开发起到事半功倍的作用。结合不同的项目，不同的语言，你可能会有不同的选择。不过，这里我想解释的是，具有了高级语言的开发能力之后，我们期望测试工具来为我们做什么。我前边也说过了，我们所要求自动化测试工具所做的就是ＵＩ的操作。这里边比较重要的是三个方面，一是找到ＵＩ对象，二是操作ＵＩ对象，三是同步。如果一个工具能够让你找到所有的ＵＩ对象，并且能成功操作这些对象，就完全满足我们的自动化开发需要了。如果，工具能够提供同步的功能，就使你能够如虎添翼，不然的话要自己去实现，会麻烦不少。到了这里，你已经具有了所有ＵＩ的操作能力（测试工具提供），并且具有了高级语言的实现能力（高级语言提供），你才有了基本的能力去做一个优秀的自动化开发。没有这些能力的人，我严重怀疑能否做出好的自动化测试。

第三，怎样自动化。我的自动化的原则是，尽量少的进行ＵＩ的操作，除非是你本身要测试的ＵＩ。道理很简单，ＵＩ操作由于可能受各种问题的干扰，很容易失败。通过非ＵＩ的方法去实现是更加可靠和快速的。这也是我为什么要强调对于高级语言的精通，具有高级语言的开发能力，你就能过把大量的任务从ＵＩ操作转向了程序操作，使得你的自动化程序的可靠性大大的增强。这里还需要强调的一点能力就是系统应用的能力，比如Ｗｉｎｄｏｗｓ使用的能力。Ｗｉｎｄｏｗｓ的很多的操作是有相关的命令来实现的，不一定非得通过大家熟悉的ＵＩ。记住这个原则：除非是你要测试的ＵＩ，否则尽可能的通过高级语言来实现。我想大家对于高级语言来实现的工作应该还是有信心吧？因此，下边我要谈的内容就完全的与你要测试的界面相关了。

第四，怎样进行ＵＩ测试。首先要尽量的减少ＵＩ操作，除非是你必须要测试的操作。比如简洁快速的启动你要测试的界面，用快捷键代替鼠标操作等等。总而言之，理想状态下我们进行的每一次ＵＩ操作，都是我们需要测试的，其他操作尽量避免，不能避免用最可靠的方式去实现。那么我们现在的焦点就变成了，怎样来处理我们真正要测试的ＵＩ了。ＵＩ测试的开发基本上就三个问题：发现对象，操作对象和同步。简单解释一下同步，同步就是有一个机制告诉你何时可以执行一个ＵＩ操作。很多人是用ｓｌｅｅｐ的方式，等待一定的时间去执行下一个操作，这是我非常反对的。我的原则是，尽量少用ｓｌｅｅｐ，就算要用每次最多不要超过一秒。滥用ｓｌｅｅｐ会严重影响测试程序的性能（具体的ＵＩ自动化过程，大家可以参考我的其他文章）。

第五，ＵＩ测试错误／异常的解决和Ｄｅｂｕｇ。通过以上的解释，我们只是在自己需要测试的ＵＩ操作才进行ＵＩ操作，否则通过高级语言或者系统命令来实现。是不是我们的ＵＩ自动化就完美了呢？绝对不是，这只是一个基础，还远远没有达到完美。我们在自动化开发和应用的过程中，大部分的时间其实是花费在了异常／错误处理和Ｄｅｂｕｇ上面。这跟真正的程序开发非常的类似，你如果去看代码的话，大量的是在进行返回值得检验和异常的处理。如果我们的程序在运行过程中出了问题怎么办，或者如果没有出现我们期望的结果怎么办？一般来说有三种问题，第一是产品的问题，我们可以报ｂｕｇ了，第二是你测试程序的ｂｕｇ，你需要ｆｉｘ。第三是其他的问题，比如测试工具，甚至高级语言本身的问题，你需要ｗｏｒｋａｒｏｕｎｄ。总而言之，优秀的测试程序最终的目的是，一旦程序的运行发现了问题，就是产品的问题，就是可以报ｂｕｇ的。能够达到这种境界才能算自动化测试的完美，才能算是一个真正优秀的测试人员。（当然了，正如软件产品不可能没有ｂｕｇ，你的测试程序也不可能完全没有ｂｕｇ。但是，由于软件产品是有大量的用户来使用，而你的测试程序只是很小范围内来使用，使得你消除影响测试过程的ｂｕｇ成为完全可能）

综上所述，一个优秀的自动化测试工程师必须要具备高级语言的开发能力，自动化工具的灵活应用能力，系统命令和使用的熟练能力等这些基本功，还更要具备优秀的Ｄｅｂｕｇ，Ｆｉｘｂｕｇ的能力，和保持程序稳定性能力。换句话讲，一个优秀的自动化测试工程师必定也是一个优秀的软件开发工程师。

最后谈一下我为什么要转向Ｃ＋＋／ＣＬＩ？从上边的排序大家可以看到，Ｃ＋＋／ＣＬＩ是目前Ｗｉｎｄｏｗｓ平台最强大的编程语言。在我的自动化开发的过程中，我需要高级语言和系统命令都不能完成的功能。如果没有Ｃ＋＋／ＣＬＩ我就必须要通过ＵＩ来实现，从而降低我程序的可靠性。而有了Ｃ＋＋／ＣＬＩ的功能，我就可以绕过ＵＩ操作了。总之，能够绕过ＵＩ操作的能力也体现出一个自动化测试人员的能力。从这个角度讲，测试人员有很多东西要学的。最后说一下，我自动化工作的要求是１００％可靠，我还不能完全满足，因为使用我程序的人是那些手工测试的人，他们的使用环境的变化有可能引起一些问题的产生，基本上还不是我程序的问题，而是测试工具，或者其他模块的问题，我需要想办法去ｗｏｒｋａｒｏｕｎｄ。不过，随着一定时间问题的积累和解决，如果环境不变，应该可以达到１００％可靠。（可是环境的变化是不会停止的，因此实际上很难达到永久的可靠，不过一段时间的可靠还是应该可以达到的，或者说我们的测试开发必须有这样一个目标，就如同软件开发的目标一样）

今天查了一下开发与测试的工资水平，一些数据应该能说明一些问题。我们以硅谷的Mountain View为代表（Google总部所在地）。

开发：

Junior Software Engineer: $62K

Software Engineer: $98K

Senior Software Engineer: $110K

Principal Software Engineer: $110K

Lead Software Engineer: $113K

测试：

Junior QA Analyst: $53K

Junior QA Engineer: $61K

QA Test Engineer: $76K

Software QA Engineer: $86K

QA Team Lead: $88K

Senior Software QA Engineer: $93K

SQAE Manager: $100K

Junior SDET: $95K

Software Development Enginner in Test: $102K

Senior SDET: $108K

Lead SDET: $108K

可见，SDET是测试工资最高的职位了，比一般的Software Engineer还高一些。不过到了Senior就比开发低一些了，而且根本没有Principle的职位。即使SDET Lead工资也没有高出去。能够跟开发的工资水平相提并论的测试职位就是SDET了。

最近总是有一些网友问我一个问题“现在有机会转开发，应不应该转?”。我想我也需要单独发表一篇文章来表达一下自己的看法了。我会从一个新入行的测试人员一直往上发展大概会是一个怎样的情况入手，来表达我的观点“开发技术是测试人员发展的基础，也是测试人员发展的归宿”。当然了，我现在表达的是测试人员一直往上发展，如果你已经对自己的发展感到很满意了，则不在这里的讨论范畴。（相信会有不少这样的人来提出自己的疑义）

从你刚入行开始，你面前基本上是有两条路可以发展。一是技术，二是管理。先说管理，很多人做了很短的时间就走向了管理，team lead，甚至manager。他们的工作已经很少用到技术了，更多的是学习和运用管理的知识。这样的人不在少数，我当时做测试3个月一转正就是team lead了，老板也非常希望我专注在管理方面。可是下一步怎么办？一般出现这种情况的都是在中小公司，而不是大而正规的外企．下一步你的发展会由于技术不够扎实而出现了瓶颈．第一，你不可能回头去搞技术了，因为你管理的地位，工资都高于技术人员，而且还有年龄的问题，这些因素造成了你只能继续管理。第二，如果你想跳槽到大的外企搞管理，可能性几乎为零，因为你没有大外企的经验又没有出众的技术。第三，如果你想在本公司或类似公司往上爬，比如做director,很可惜，这些公司往往不配备test director的职位，并且其他director的职位也很难由一个做测试的人来承担。（可能会有特例，但是应该很少）。因此，刚入行不久，没有扎实的技术沉淀，就走向了管理，很快就会发展到头了。

再说技术，我们知道测试的最高title就是SDET和SET了。实际上都是一个东西，微软叫SDET,Google叫SET。说白了，这种职位本质上就是开发，只不过不是产品的开发，而是测试的开发。需要很强的开发背景。因此，一个普通测试人员想要得到这种工作机会，开发的经验是必不可少的。另外，微软，Google这种最top的公司，基本上已经没有STE, SQAE这种职位了。而我们大多数人做的测试工作恰好正是这种职位。顶尖大公司的这种职位都外包了。因此，你想通过普通的STE, SQAE这种职位进入顶尖公司，可能性基本为零。因此，如果从技术上来讲发展，无论从title上还是公司上往往上走，开发的功夫都是必须的。

因为我说的是一直往上发展，因此到了SDET后怎么发展？基本上三条路，第一管理，第二开发，第三继续测试。先说管理，你从技术上一路走过来再走向管理跟前面讲到的那种管理是天壤之别了。首先，你已经是在顶尖公司了，其次，你已经具备了高深的技术水准了。放眼望去，整个测试行业还能有几个适合你的位子呢？还能有多少人能跟你相提并论呢？这条路可以lead->manager->director->vp->senior vp往上发展。那么发展到了最后还怎么发展呢？这个时候，我估计应该年纪很大了吧？钱很多了吧？享受生活吧。

再说转开发，因为SDET具备了比较强的开发水平（比一般公司的开发人员的水平要高），因此可以比较容易的转向开发。转向开发之后就属于开发的发展之路了，就不多说了。

最后说继续测试，一直以来都有个疑惑，为什么我从来没见过senior SDET？本来SDET可以向senior, principle这条路走下去。我以前也想过自己发展成test architect。可是，为什么没见过？依我现在的感觉来说，测试的技术很快就学到头了，开发的技术由于一直是在做测试程序，而不是真正的产品，因此提高的程度也受到了很大的限制。因此，在技术上来讲，一直工作下去就会维持在一种不是很高技术水平的状态。这种状态达不到senior的要求。这也是为什么周围很多SDET不知道工作了多少年，还是SDET。目前来看，想发展的话，维持在SDET不算现实。必须走向管理，或者转向开发了。这也是为什么director在回答我的问题“我在测试方面应该怎么发展？”。回答竟然是“短期来看要学好Ｃ，长期来看还是Ｃ，转向开发”。根本就没有提到测试。

以上是我自己的分析与理解。

大概几个发展路径

1.QA->management

2.QA->SDET->management

3.QA->SDET->Dev

当然还有其他的可能，比如

4.Dev->QA......

5.QA->Dev......

6.QA->Dev->SDET......

7.Dev->SDET......

8.SDET......

我想大家可以分析一下自己以前的发展之路，看看以后应该如何发展？当然了，如果自己已经满意了就算了。我的发展之路是这样的

Dev->QA->Management->SDET->(Lead/Dev/Senior if possible)

总而言之，在整个的发展路径中，如果你缺少Dev,都会限制你更好的往上发展。还有就是发展的高低，一要看title,二要看公司。很多小公司的manager可能根本都进不了大公司。很多大公司的普通员工一旦跳槽到小公司很容易就能升职。比如一个朋友在国内做了６年的外包经理，面试大公司总是失败，因为技术不行。还有朋友在顶尖公司只是SDET,跳到盛大就是director.

这里我想破除很多测试人员的一个幻想，我强调的一点是“不懂开发的测试没有太大的前途”。