对测试自动化的看法－来自微软讨论组的争论

今天七月四号美国国庆节，有时间坐下来总结一下过去几年在微软的测试经验，谈谈对测试自动化的看法。

先说说为什么做测试的人喜欢搞自动化。

第一，自尊心。计算机科班出身的人都喜欢作开发(Dev)。做测试工作经常是身不由己，可是测试工作很多时间不需要编程，于是做测试的人想方设法写些程序，以显示自己也会编程。结果往往是欲罢不能，测试自动化程序越写越多，越写越复杂。后面我会谈谈测试自动化框架复杂的代价。

第二，为了出成绩。很多测试组为了向管理层展示成绩，往往要拿出例如测试自动化达到80%，程序覆盖率达到90%。要我说，这些都是Bull Shit. 就象小平同志说的“实践是检验真理的唯一标准”，我认为在测试中“用户不出问题是检验质量的唯一标准”。自动化做的再多，用户出了问题，也是白搭。另外，一个人就可以做的测试，自动化往往需要两个，三个。倒是解决就业的好方法。

我对测试自动化的认识也有一个变化的过程。刚刚入行时也是很相信自动化，想方设法写一些从头到尾自动化的框架，觉得自动测试很过瘾。到微软的Portal Media Center组后也是和另外两个人做了一个相当复杂的用户界面的自动测试。其实现在想想，用自动测试发现的问题基本上可以一个人用手工测试完成，最多写些简单的测试辅助工具就可以完成。有些人可能会说自动化可以为产品的下一个版本节省测试时间。其实Portal Media Center 下一个版本出来时，所有户界面完全变了，80%以上的自动测试程序都需要改动。做完第一个版本，我们三个人全都走掉了。后面来的人往往宁可自己再写一套，也懒得改以前人的程序。自动化的浪费就是这样造成的。想说服别人用你开发的自动测试框架是很难的，所有人都想另搞一套。

下面分几点讲讲为什么要放弃对测试自动化的幻想，和怎样进行低成本的有效测试。如果你还不能同意我对测试自动化的看法，可以去这个微软员工的Blog http://minimsft.blogspot.com/2006/08/dev-vs-test-vs-pm.html 去看看为什么Windows测试组用的WTT测试框架被称作“Waste of Tester Time". 我最基本的观点不是说测试自动化不能测出bug，而是想问: 一个比较复杂的测试自动化框架所造成的人力浪费，值不值得最终的结果？如果不做测试自动化，能不能达到同样的效果。以我的亲身经历，去年我的测试组两个人对应开发组五个人，项目经理三个人的工作量，去年做了好几个Release，Hotfix只有两三个。我们旁边的测试组七八个人对应五六个Dev. 他们又是自动化，又是搞程序覆盖率，好不热闹，Hotfix 也不少。按一个人的人工成本12万美元，我们组省至少三个人的成本36万美元。

第一，不要指望自动化能帮你找bug. 软件bug和生物的bug很像，测试的规律是bug少的地方bug越少，bug多地方越找越多。做测试自动化，往往在开发自动化的时候，该发现的bug就发现了。自动化开发完成，再想发现更多bug就很难了。这是无论你怎样跑你的自动化，也不会发现新的bug.

第二，不要指望自动化对Regression Test的测试的贡献。软件的特点是如果一次做对了，以后永远不会出错。当程序出现变动时，只要针对变动的部分测试就可以了，以前测过的东西，如果和变动没有关联就不会出错。相反如果，程序出现很大变化，自动化可能完全不能用了。

第三，自动化不如测试工具加手工测试。我不建议测试人员作全面自动化，相反我建议测试人员多做小巧灵活的测试工具。自动化往往需要自动判Pass或Fail.  想想你如果测试用于生成www.microsoft.com的页面的产品，你如何判断页面框架生成的正确？很多东西是动态产生的，你很难确认所有的内容的正确性。如果你自己用这个产品手工做个页面，用肉眼很容易判断所有相关和不相关的内容生成的正确性。我就是用这个方法在工作中发现了网页上谁也想不到的bug, 如果用自动化很难在测试阶段发现这个bug.

第四，软件项目的生命周期就定了自动化的无用。现在很多网络应用项目的生命周期都很短，一个项目从生到死不过两三年。死的定义是项目进入Sustain Engineering维持状态。自动化原来的一个主要目的是使软件测试的未来阶段越来越容易，成本越来越低。可是当一个项目死掉了，自动化还有什么用。而且最新的敏捷开发，软件的要求，程序，接口，界面在不断变化，自动化怎么可能跟得上变化。与其去搞自动化，不如多理解变化，直接测试变化的东西。

如何进行有效测试？

第一，测试人员的自信心可以建立在读程序的能力上。在一个项目中，开发人员的工作是研究新技术，写出最好的程序。测试人员应该在开发人员研究的基础之上，更好的理解新技术，读懂程序。看懂程序可以使测试工作非常高效。不懂内部程序的人，可能会设计三十个test cases, 才能找到一个bug.  懂程序的人每个test case都可能发现一个或多个bug.  我有30%的bug都是读程序读出来的。由于对开发人员的程序有很深的理解，即使release后出了问题，也能很快理解问题出在什么地方，是否是bug.

第二，测试人员写测试程序的时间应该尽量最小化。测试人员测试的时间分配应该是, 30%读程序，20%写测试程序，50%写Test Cases和运行Test Cases. 好的测试员的工作重点应该放在理解要求，理解客户需要，思考在什么条件下程序会出错，而不是思考如何去自动化。如果时间都放在设计自动化上了，必然会影响测试，分散测试资源。测试人员应该边读程序边测试，读程序帮助找到好的Test Case，测试帮助验证理解和猜测。

第三，测试人员要学会讨价还价。很多时候项目经理，开发人员搞得东西不是客户马上需要的，或许是永远用不到的。测试人员可以和项目经理研究先测什么，后测什么，那些不测。比如，我做的一个项目，我发现30%的功能是现在用处不大，所以我直接告诉项目经理那些东西我不会去测的。事实证明，这样做节省了很多人力。

第四，测试人员要多花时间参与设计。测试人员一定要紧跟项目经理和开发人员的要求变化和设计。理解每一个要求的影响。在每个项目周期中，去比较当前版本和以前版本的所有程序变化。重点测试变化。

总之，少做自动化，多写小工具，读懂程序，是高效省钱的测试方法，除非你钱多得没地方花。下次有谁建议搞什么测试自动化构架，告诉他"That is bullshit".

  omomo

有需求才会有程序.测试自动化也是. 楼主是一个很有分析能力的测试人员,而且编程能力也不弱,所以才说出读程序+测试小工具+测试的经验.但你这样的牛人仍然只能保证你的模块的质量,如果我们需要让你保证更多的人的模块的质量,总归要从自动化测试上面来打主意了.否则你的这种测试经验没有办法容易的被人拷贝学习.而你的测试代码是很容易被人拷贝学习的.呵呵

所以一种情况是,你想出来的测试用例,可以利用自动化测试框架自动运用到各个模块中去.比如,你想出来界面上不能有重复的hotkey,那么一个好的自动化测试框架应该允许你迅速把这类测试用例运用到各个UI上去测试.

另外一种情况是,人没有办法做的,比如并发的压力测试,像gamerrob提到的那种.

其次说到,regression test,我觉得也是有用处的:"软件做对了一次,以后就永远不会错?", 这话说得太离谱,很多看似没有关联的改动,往往会导致隐藏的bug的出现,有一个完整的自动化测试集的好处是,至少当你的开发人员改动了基类或者基本底层API的时候,可以通过运行上层功能的自动化测试集保证改动没有破坏功能.否则,难道他的改动要求所有测试人员把所有功能手工的全部跑一便?光协调通知各个测试组,恐怕就得花一周时间.

自动化测试的分工本来就是慢慢将写自动化测试工具的人和手工测试的人分开,难道楼主以为写VS里面的webtest工具和code coverage不需要时间,不值得做?手工测试将慢慢外包,而公司培养的自动化测试工程师将通过积累和筛选,最终有些人会去主导那些重量级测试工具的开发. 这和程序员也没有什么区别. 微软的程序员,也有写简单的代码,基本属于把人家基类的接口实现一下的. 也有真正牛比的大师.只不过在不同的职业阶段.

楼主有一个观点,我非常认同:理解产品,找到缺陷才是测试人员的本质.任何时候,沉浸在自动化测试中的人,都不是合格的测试人员.所以在我的团队里,我把理解产品功能放在编程能力之上.只有一个非常理解产品功能知道用户会怎么用这个产品的人,才能写出有效的测试用例.楼主说的很好:不懂内部程序的人，可能会设计三十个test cases, 才能找到一个bug.  懂程序的人每个test case都可能发现一个或多个bug.  

发表时间：2007-07-17 16:46:29 4 楼：peking2toronto 驳斥）迷信自动化是测试人员的误区 （1）

今天七月四号美国国庆节，有时间坐下来总结一下过去几年在微软的测试经验，谈谈对测试自动化的看法。
  

[comments]今天看到这篇关于自动化测试的文章，有很大的误导作用，我也谈一下对自动化测试的看法。首先，作者是一个在微软工作了几年的一个测试人员，总结的是在微软的测试经验。可是他总结的并不是典型的微软公司的测试观点，而是自己个人的测试观点。因此，他的观点实际上是与微软公司没有太大关系的。这点，大家还是不要被误导。众所周知，微软在几年前对测试有一个大的改变。以前微软有两种职位，STE和SDET，前者是手工测试，后者是自动化测试。微软把STE基本cut掉了，因此STE要不走人，要不转SDET。转过来的，因为以前主要是手工测试，因此就对自动化测试产生很大的抵抗情绪。这种情绪是team lead很不愿意看到的。因此，STE的困境是比较大的。还有就是在微软里做几年如一日的测试人员大有人在，因为能力问题，级别得不到提升。因此，几年还是junior。所以，在微软做几年测试，也不代表就是一个级别很高的人。

另外要说明一点，从文章的title里可以看到，这篇文章是说给迷信自动化测试人员的。作者以前本身就是一个迷信自动化测试的人，可是后来从迷信变得不相信自动化测试了。可见作者是一个很容易走极端的人，从头到尾都没有用一个公平理性的态度去面对自动化测试。还有就是，这个文章如果给迷信自动化测试的人看，还是有一定意义的。可是，我们当中有几个人像作者以前那样迷信自动化呢？大部分看了可能会觉得是针对整个自动化来讲的，而且作者确实也偏离了他的title，因此我也需要澄清一下。


先说说为什么做测试的人喜欢搞自动化。
第一，自尊心。计算机科班出身的人都喜欢作开发(Dev)。做测试工作经常是身不由己，可是测试工作很多时间不需要编程，于是做测试的人想方设法写些程序，以显示自己也会编程。结果往往是欲罢不能，测试自动化程序越写越多，越写越复杂。后面我会谈谈测试自动化框架复杂的代价。
第二，为了出成绩。很多测试组为了向管理层展示成绩，往往要拿出例如测试自动化达到80%，程序覆盖率达到90%。要我说，这些都是Bull Shit. 就象小平同志说的“实践是检验真理的唯一标准”，我认为在测试中“用户不出问题是检验质量的唯一标准”。自动化做的再多，用户出了问题，也是白搭。另外，一个人就可以做的测试，自动化往往需要两个，三个。倒是解决就业的好方法。   

[comments]我想作者漏掉了一个最重要的方面，那就是自动化可以解决我们的测试问题。两个方面，一是自动化可以完成手工不能完成的任务，二是自动化可以替代手工重复的劳动。这才是我们搞自动化最重要的原因。关于自尊心的问题是有的。可是作者解释的好像都不在理。计算机科班出身的人都喜欢做开发？这个观点从何而来？计算机出身的人可以做开发，测试，dba，support，销售，市场，自己创业。各种工作都有可能，怎么能说都喜欢做开发呢？以我的个人经验来看，喜欢做开发的是少数。做测试经常是身不由己？我认为做开发也很多是身不由己。测试工作很多时间不需要编程？开发人员很多时间也不需要编程。后边的就不说了。总之，给人的感觉都是作者的心理。好像作者自己喜欢做开发，身不由己作了测试，发现不需要什么编程，然后就想方设法写程序，以显示自己也会编程，结果出了大问题了。这里可以提供两点信息，一是作者想做开发没有做成。可见作者的开发能力有限，老板不给提供这个机会，因为老板是要给产品负责的。还有就是，做了几年的程序，而且一直想转开发而转不过去的话，我真的不能suppose他水平有多高了。另外就是，把自己的心理，心态，引申到整体，不是很有道理。

用户不出问题是唯一标准？你可以认为它是一个标准，可是你怎么衡量？用户，半年不出问题，一年不出问题，还是五年不出问题，永远不出问题？还有就是，难道只能在用户的使用上才能衡量一个软件的质量吗？我们做测试的首要目的就是在用户拿到产品之前就要保证好产品的质量。难道，自动化测试，程序覆盖率不是实现这个目标的解决方法吗？一个人做的测试，自动化需要两，三个。这又是从何而来？以我的经验，三四个人的测试，我一个人做自动化就可以完成了。我前不久的工作成绩就是，本来需要3个星期手工测试的，经过我的自动化，变成1个星期完成了。也就是说，本来需要三个手工测试人员，现在只需要一个自动化测试人员了。还有就是，我们的软件需要在不同平台下，不同环境下测试，没有自动化怎么行？比如，我们要在2000，XP，XP+sp1,XP+sp2, 2003, 2003+sp1，2003+sp2,vista。这还不包括，这种cpu，windows的不同版本呢。手工测试得需要多少人呢？
发表时间：2007-07-17 16:46:59 5 楼：peking2toronto (驳斥）迷信自动化是测试人员的误区 （2）

[comments]在进行第二部分的时候，我想简单说一个问题。以我个人的看法，功能测试根据被测试对象主要可以分三种类型：UI测试，Command line测试和API测试。我认为后两部分是非常适合用自动化来作为主要方法进行测试的。作者只是提到了UI自动化，然后就推广到整个的自动化。我认为这不是很reasonable的。如果谁要是认为API和command line的测试不适合自动化，我们可以单独讨论。不过这里，我们就要把topic nail down了。我们只谈UI的自动化。如果我们要谈整个的自动化，作者的观点一下子就错了，没必要继续谈下去了。

  

我对测试自动化的认识也有一个变化的过程。刚刚入行时也是很相信自动化，想方设法写一些从头到尾自动化的框架，觉得自动测试很过瘾。到微软的Portal Media Center组后也是和另外两个人做了一个相当复杂的用户界面的自动测试。其实现在想想，用自动测试发现的问题基本上可以一个人用手工测试完成，最多写些简单的测试辅助工具就可以完成。有些人可能会说自动化可以为产品的下一个版本节省测试时间。其实Portal Media Center 下一个版本出来时，所有户界面完全变了，80%以上的自动测试程序都需要改动。做完第一个版本，我们三个人全都走掉了。后面来的人往往宁可自己再写一套，也懒得改以前人的程序。自动化的浪费就是这样造成的。想说服别人用你开发的自动测试框架是很难的，所有人都想另搞一套。   

[comments] 作者在自动化过程中发现的问题，和犯下的错误是初学自动化的人很容易出现的。刚开始的时候，很多人都想把自己的自动化做的多么fancy,想100%的automation.把目标定得很高，结果又相差很大。因此，就动摇了自动化的信心。我做自动化总是强调的一点是，“怎样合理的进行自动化？”。什么应该自动化，什么不应该自动化，怎样进行自动化，这都是有一定学问的，也是一个senior测试人员应该具备的基本能力。因为作者的能力问题，使得后来的测试人员不愿意用他们的代码，宁可另起炉灶。这完全不能说明自动化有什么不好的。你想想看，如果你设计，实现了一套非常好的，非常灵活的自动化系统，后来的人很轻松的能够上手，他为什么还要自己重新来过呢？以我个人的经验来看，想另起炉灶的最根本的原因是因为以前人留下的代码太滥了。这个不光测试有这个问题，开发中同样普遍。我设计的自动化框架，到我辞职后一年还没有替代品的出现，大家都是在我的基础上进行新的开发和利用，以及扩展。这又说明了什么？我从来没有试图去说服别人一定要用我的。好的东西，别人一定会看到的。


下面分几点讲讲为什么要放弃对测试自动化的幻想，和怎样进行低成本的有效测试。如果你还不能同意我对测试自动化的看法，可以去这个微软员工的Blog http://minimsft.blogspot.com/2006/08/dev-vs-test-vs-pm.html 去看看为什么Windows测试组用的WTT测试框架被称作“Waste of Tester Time". 我最基本的观点不是说测试自动化不能测出bug，而是想问: 一个比较复杂的测试自动化框架所造成的人力浪费，值不值得最终的结果？如果不做测试自动化，能不能达到同样的效果。以我的亲身经历，去年我的测试组两个人对应开发组五个人，项目经理三个人的工作量，去年做了好几个Release，Hotfix只有两三个。我们旁边的测试组七八个人对应五六个Dev. 他们又是自动化，又是搞程序覆盖率，好不热闹，Hotfix 也不少。按一个人的人工成本12万美元，我们组省至少三个人的成本36万美元。   

[comments] 作者自己在自动化中出现了很多问题之后，并不是积极地想办法去解决这些问题，而是消极地放弃了自动化测试，实在是令人感到可惜。要知道，发现问题是最能提高人的能力的时候，你把这些问题解决了，你的水平，能力，经验就相应的得到了提高。并且，作者从一个极端走到另一个极端以后，就想方设法找一些证据来支持自己的观点。比如，通过微软员工的blog。一个员工blog里的观点能证明什么呢？你有没有去问过windows 测试组对WTT的观点呢？别人一说，你就相信？可以看出作者不是一个严谨的人，吸收东西总是从自己的思想角度出发，而没有经过验证。作者在自动化过程受到挫折后，竟然与当今测试的发展背道而驰，实在是令人费解。

作者的问题是，一个复杂自动化框架值不值得去做？如果不做自动化，能不能达到同样效果。从这里我们又一次看到了作者走了极端。复杂的自动化不值得做，就要抛弃自动化。首先，我不想辩论到底什么是复杂的自动化，是它本身复杂，还是你自己给搞复杂了。这里我假设，它不值得做。可是，这样就抛弃自动化吗？我的问题是，如果复杂的自动化不值得做，那么相对简单的自动化值不值得做？合理的自动化值不值得做？是不是一定就要抛弃自动化？接下来，作者用自己的经历来说明，自动化没有必要，并且和其他的team进行了比较。从数据上看，好像自动化测试真的不如他的手工测试。我想这种比较意义不大，因为我可以给你举出更多的例子，自动化比手工测试效果好。并且，你hotfix少也不能说明什么，说不定你要用合理的自动化，都没有hotfix呢。别人如果不用自动化，hotfix更多呢。产品不一样，都很难进行公平比较。另外，既然公司给他们配备了更多的测试，本身就说明了其他组的项目复杂度比较高。你们少的测试，说明了复杂度比较低。最后质疑一下工资成本，12万美金的年薪？你真有那么多吗？如果是的话，也不代表普遍的测试人员的工资。不知道你这个数字从何而来？如果你拿着这么高的年薪而不能搞定自动化的一些基本问题，那么我还有点为你担心了。
发表时间：2007-07-17 16:47:24 6 楼：peking2toronto (驳斥）迷信自动化是测试人员的误区 （３）

第一，不要指望自动化能帮你找bug. 软件bug和生物的bug很像，测试的规律是bug少的地方bug越少，bug多地方越找越多。做测试自动化，往往在开发自动化的时候，该发现的bug就发现了。自动化开发完成，再想发现更多bug就很难了。这是无论你怎样跑你的自动化，也不会发现新的bug.   

[comments]我承认大部分的ｂｕｇ都是通过手工测试来找到的，我也相信很少会有人把找ｂｕｇ完全依赖于自动化。可是，你也提到了，在开发自动化的过程中，该发现的ｂｕｇ就发现了。这也就是说，如果没有开发自动化，这些ｂｕｇ还未必能被发现。这里边的意思就是，自动化开发完了，可能找不到什么ｂｕｇ，可是在开发过程中还是对找ｂｕｇ做出了贡献。我们总是说要注重过程，因此从过程来说，自动化对找ｂｕｇ还是有它的必要性．对于作者后面的问题，我得先说说什么是自动化测试的目的了（在找ｂｕｇ方面）．我们知道，很多模块是要跟其他模块来合作工作的，即使你自己的模块没有任何变动，也有可能因为其他模块的变动被ｆａｉｌ掉。比如最近的Ｎｏｒｔｏｎ的问题。Ｗｉｎｄｏｗｓ的ｕｐｄａｔｅ引致了Ｎｏｒｔｏｎ的误报。因此，自动化测试的非常重要的一个目的就是保证没有ｒｅｇｒｅｓｓｉｏｎ的问题。也就是说，我们不指望ａｕｔｏｍａｔｉｏｎ找到新的ｂｕｇ，可是以前能够ｗｏｒｋ的一定要保证继续ｗｏｒｋ。我工作过不少公司，很多产品都是一天一个ｂｕｉｌｄ，请问没有ａｕｔｏｍａｔｉｏｎ的话，你怎么能够手工的运行一遍你的ｃａｓｅ呢？而且，每天运行一遍的话，你烦不烦呢？

还有就是，作者说的不会发现新的ｂｕｇ还是太绝对了。我的自动化可是发现了不少新ｂｕｇ呢。有的是因为开发人员改动代码造成的，有的是因为其他ｔｅａｍ的模块发生变动造成的。有的是测试工具本身的ｂｕｇ造成的。总之这种各样，并且每种问题，我都是要报ｂｕｇ的。最后，无论对自己的ｔｅａｍ还是其他的ｔｅａｍ都做出了自动化测试的贡献。


第二，不要指望自动化对Regression Test的测试的贡献。软件的特点是如果一次做对了，以后永远不会出错。当程序出现变动时，只要针对变动的部分测试就可以了，以前测过的东西，如果和变动没有关联就不会出错。相反如果，程序出现很大变化，自动化可能完全不能用了。   

[comments]我想这种观点也不需要我反驳了吧？任何有个有一定测试经验的人很难说出这种话来。这里边每一句话都是错的，如果有人提出不明白，我再来解释。这里我假设大家都清楚怎么回事。


第三，自动化不如测试工具加手工测试。我不建议测试人员作全面自动化，相反我建议测试人员多做小巧灵活的测试工具。自动化往往需要自动判Pass或Fail.  想想你如果测试用于生成www.microsoft.com的页面的产品，你如何判断页面框架生成的正确？很多东西是动态产生的，你很难确认所有的内容的正确性。如果你自己用这个产品手工做个页面，用肉眼很容易判断所有相关和不相关的内容生成的正确性。我就是用这个方法在工作中发现了网页上谁也想不到的bug, 如果用自动化很难在测试阶段发现这个bug.   

[comments]又一次以一个例子引申到整体自动化。可能你的这个例子没有什么问题，可是根据这个例子，我实在不能得出自动化不如测试工具加手工测试的结论。还有就是多做小巧灵活的测试工具？这个最好能具体谈谈。什么是多做？什么是小巧？什么是灵活？作者从一个自动化工程师发展到现在用肉眼来测网页，还拿着１２万美金的年薪，我实在是怀疑作者的测试发展轨迹了。这个工资应该是很ｓｅｎｉｏｒ的了，怎么还在肉眼测网页呢？这种工作在ｇｏｏｇｌｅ是最低级的。都是合同工来做，根本不可能那么高人工。


第四，软件项目的生命周期就定了自动化的无用。现在很多网络应用项目的生命周期都很短，一个项目从生到死不过两三年。死的定义是项目进入Sustain Engineering维持状态。自动化原来的一个主要目的是使软件测试的未来阶段越来越容易，成本越来越低。可是当一个项目死掉了，自动化还有什么用。而且最新的敏捷开发，软件的要求，程序，接口，界面在不断变化，自动化怎么可能跟得上变化。与其去搞自动化，不如多理解变化，直接测试变化的东西。   

[comments]又一次从网络应用的生命周期短，引申到了整个的软件项目。ｗｉｎｄｏｗｓ存活多少年了？Ｏｆｆｉｃｅ多少年了？有没有死掉？就算是网络应用，Ｇｏｏｇｌｅ　Ｓｅａｒｃｈ多少年了？有没有死掉？Ｇｏｏｇｌｅ的界面这么多年变化也不大吧？可能你做了一些项目很快死掉，但是不能代表整个的软件行业。软件的要求，程序，接口，界面在不断变化？我真怀疑当初是怎么设计的？如果这样的话，你手工也没法测。这个问题好像不是自动化测试的问题，而是产品设计的问题吧？
发表时间：2007-07-17 16:47:41 7 楼：peking2toronto (驳斥）迷信自动化是测试人员的误区 （４）

第一，测试人员的自信心可以建立在读程序的能力上。在一个项目中，开发人员的工作是研究新技术，写出最好的程序。测试人员应该在开发人员研究的基础之上，更好的理解新技术，读懂程序。看懂程序可以使测试工作非常高效。不懂内部程序的人，可能会设计三十个test cases, 才能找到一个bug.  懂程序的人每个test case都可能发现一个或多个bug.  我有30%的bug都是读程序读出来的。由于对开发人员的程序有很深的理解，即使release后出了问题，也能很快理解问题出在什么地方，是否是bug.   

[comments]读程序也算是测试人员的一个基本技能了．可是没有任何理由说读程序就能代替自动化测试呀．我承认读程序是一个非常好的测试方法，可是我们更需要其他好的方法来对软件进行全面的测试．自动化测试难道不是其中一种吗？通过一种测试方法来贬低另外一种，不是很客观和有意义．


第二，测试人员写测试程序的时间应该尽量最小化。测试人员测试的时间分配应该是, 30%读程序，20%写测试程序，50%写Test Cases和运行Test Cases. 好的测试员的工作重点应该放在理解要求，理解客户需要，思考在什么条件下程序会出错，而不是思考如何去自动化。如果时间都放在设计自动化上了，必然会影响测试，分散测试资源。测试人员应该边读程序边测试，读程序帮助找到好的Test Case，测试帮助验证理解和猜测。   

[comments]我们今天的主题本来是在讨论自动化测试方面,你现在却跳到了白盒测试方面。我想白盒测试可以单独作为一个ｔｏｐｉｃ来讨论。还是那句话，用一种测试方法来贬低另外一种，没有意义，也没有说服性。毕竟大家搞自动化大多数都是从黑盒测试的角度出发的。


第三，测试人员要学会讨价还价。很多时候项目经理，开发人员搞得东西不是客户马上需要的，或许是永远用不到的。测试人员可以和项目经理研究先测什么，后测什么，那些不测。比如，我做的一个项目，我发现30%的功能是现在用处不大，所以我直接告诉项目经理那些东西我不会去测的。事实证明，这样做节省了很多人力。   

[comments]这不是偷工减料吗？用户不用为什么还要设计呢，还要实现呢？你应该在设计阶段就进行质疑。对用户的需求方面是项目经理的责任。你的目的是监督项目经理的工作。如果你认为这些东西没用，应该在设计阶段就ｃｕｔ掉。而不是等到测试阶段才发现，并且不进行测试。你现在没有节约成本，你浪费了很多ｐｍ和ｄｅｖ的时间，加大了他们的成本开销。你现在是拿ＰＭ的错误来跟他们讨价还价，他们也没办法。但是，作为一个优秀得测试人员，最好的办法还是应该在设计阶段发现这些问题。还有就是，既然已经实现了，如果你不进行测试，里边的风险是很大的，是绝对的不应该的。这里我不想多讲，因为道理还是很简单的。如果有人不明白我再解释？


第四，测试人员要多花时间参与设计。测试人员一定要紧跟项目经理和开发人员的要求变化和设计。理解每一个要求的影响。在每个项目周期中，去比较当前版本和以前版本的所有程序变化。重点测试变化。
总之，少做自动化，多写小工具，读懂程序，是高效省钱的测试方法，除非你钱多得没地方花。下次有谁建议搞什么测试自动化构架，告诉他"That is bullshit".   

[comments]不想多说了，自己自动化不行，别说脏话。你要是参与了设计，怎么还出现了第三里面的问题呢？

最后想说的是，这个作者的观点绝对不代表着微软的观点。作为前辈传授经验是好事，不过千万不要误导。作为晚辈学习前辈的经验也不要全盘接受，要学会思考，有自己的理解和ｉｄｅａ。
发表时间：2007-07-18 13:41:30 8 楼：dlele

写了这篇文章，惹得有些人很生气，后果很严重。所以再写一些，阐明我的一些观点。首先要说的就是欢迎大家的争论，其次我当然不代表微软的观点J 其实我想微软对我讨论的问题也没有什么官方观点。学术问题本来就是应该各抒己见。我只是想谈谈我个人对自动化的感觉，至于感觉是否科学，大家可以批评。但测试本身就是Art，还不是科学（这话不是我发明的，是书上说的。）

有人质疑我的能力和Credibility，首先我做SDET有六年了，之所以写这篇文章就是想总结一下有效测试的经验。反思一下为什么近三年自动化做得少了，反而工作成效大了。另外，我的工作涉及网络安全认证与授权，是公认相当复杂的项目。为什么我们可以较少的人力比较出色地完成项目。所谓出色，我认为我们做到了PM和Dev的双满意。

测试人员和PM, Dev的关系。

测试人员最直接的打交道的人是PM和Dev。相对而言，测试人员较少和客户直接打交道。当然，PM满意应该和客户满意是一致的。PM和Dev关心测试自动化吗。No！PM 最关心是进度，其次是质量。Dev有几类，有一类最高兴的就是测试的人别找他们麻烦，当然测试人员的工作就是找他们的麻烦。还有一类比较通情理，知道测试人员是在帮助他们把工作做好。当然，bug找得少，产品在用户出问题，Dev会觉得测试人员的工作不够。所以Dev首先讨厌测试人员做无用功，效率不高。其次，Dev最讨厌的就是测试人员乱挑毛病。就像针灸一样，如果扎得不是地方，只会惹人烦。如果一针扎到病灶，Dev会很满意。所以Dev关心的并不是测试人员否是搞了自动化，只要能找到问题。黑猫白猫，抓到耗子就是好猫。

什么是自动化

我定义的自动化是指较大的框架。举例说，如果你要测一个API，这个API的其中一个参数是C# String，如果有必要测很多不同的Unicode值，当然写个程序测最快，最可靠。另外Stree/Performance测试都要写程序。我觉得这个不叫自动化，这是SDET的基本功。我也反对没有必要的自动化。比如，有些测试要检验Event Log的内容，有些人把.NET中读Event Log的库函数再打包写个自动化库，认为这样把原来需要五行完成的动作一行完成很酷。其实，你想想自动化库带来的维护问题比解决的问题还多。本来，.NET的文档很清楚，你的自动化库文档又不全，出了问题还得找源程序，还得有人改自动化库。麻烦不知道是少了还是多了。另外，我所说的手工测试包括写测试程序，但测试程序侧重的不是自动化，而是探索测试Exploratory Test.

自动化在测试中的地位下降

另外我观察自动化在测试中的地位下降。测试人员的大忌就是在测试开始把自动化作为首要目标。一般来讲，过去我们把测试自动化作为目标之一，总是想完成手工测试后，在有时间要做自动化。可是实际情况是，项目进度太快，根本没有时间做自动化。一般手工测试完成后，产品就发布了。

测什么不测什么

和PM讨价还价不是偷工减料。一般讲，在项目开始阶段，测试人员的发言权最低。很多东西测试人员是没法控制的。PM总想多加功能，即使现在没用，想着将来会有用。有的项目，Dev有很大的支配权，Dev可以加入很多他喜欢的东西。（很吃惊吗，现实就是这样）。测试人员只有在测试阶段讨价还价的份儿。

有人认为我说“软件的特点是如果一次做对了，以后永远不会出错。”很荒谬。我承认有点极端。我的意思是，你在测试时肯定要假设有些东西是对的，不用测的。比如.NET的库。测试完成了投入使用了一段时间后，就可以假定当前的软件基本符合要求，不需要进一步测试了。必须学会画一条测与不测的线，否则测试会无休无止。我们大多数人接受的项目肯定是前人基础之上的项目，新的版本出来了，我们肯定要假定没有变动的，没有涉及程序不会出错，重点测试变动的部分，分析可能会涉及的部分。具体讲可以用Beyond Compare比较程序的变化。

当然，这个假定在一定程度上是错的。前人做得程序可能会出错，.NET库函数也有错，如果不在当前测试人员的工作范围，这种错误是可以接受的。如果你能找出前人的错误，发现.NET库函数的错，说明你确实出色。但从往往时间上讲，你能做到这步的机会有限。当然，我发现的最得意的bug就是在产品中隐藏了五年之久，我讲出来都替微软丢人的安全漏洞。我发现这个bug就是读程序偶然读出来的。读的时候，脑子里多打了几个问号，然后动手一测，果然如我所料。

WhiteBox Test + Exploratory Test

我的测试哲学是WhiteBox + Exploratory Test。测试开始阶段要读懂要求，理解设计。然后是读懂程序，在程序中找问题。这就是WhiteBox Test。然后动手写一些测试程序，测试程序的原则一定要简单灵活但自动化程度不高。测试程序的主要目的是探索，手工探索，目测探索软件那里会出错。之所以要做探索测试，就是因为自动化要求对输入输出都要很准确的定义。输入好控制，可是没有探索测试，很难准确知道输出是否正确。自动化必须建立在探索测试的基础之上。就像用一只单发的步枪，一发一发精确打击敌人防御的弱点，不是用机关枪盲目扫射。单发的好处是，每打一枪你都要目测效果，然后调整子弹大小，射击的远近。如果像机关枪打出一百多发子弹，你会视觉疲劳，无所适从。自动化就像一只机关枪。

我的观点只是一家经验之谈，不是理论，大家可以借鉴，不要照搬。

关于，美国软件业大公司的人工成本是公开的，新闻里可以查到，平均大概是十一到十五万，当然包括各种福利，和管理成本。

  本回复于：
2007-07-18 14:35:26 被【dlele】修改
发表时间：2007-07-18 14:12:09 9 楼：dlele

自动化是理想，手工测试是现实，我讲的是理想与现实的差距。这个差距不是我个人能力的差距，而是敏捷开发，产品周期加速，复杂度增加，相对人力资源有限所带来的现实造成的差距。

发表时间：2007-07-18 15:34:38 10 楼：dlele

说个具体的实例，最近在工作中遇到一个很头疼的bug。我们有个API，GetXXXURL(xxx, string locale, yyy)，locale 是语言的字符串代码，Dev搞成了GetXXXURL(xxx, int lcid, yyy).。Lcid 是语言的整数代码。比如，中文的字符串代码是 "zh-CN"，整数代码是2025。Web Service端只认字符串代码，结果2025被解释成为不支持的语言，URL返回默认英文1033. 由于系统设计是三层，每层都要改，很头疼。

这个测试是我们一个新来的员工测得，他是用VSTS写了一个自动测试，每次运行都通过了。原因就是他可能花太多时间搞自动化，没有认真理解要求，对要验证的返回值也不了解。自动化自然发现不了问题。如果他当初写了一个很简单灵活web based的测试工具，多做探索测试，我也可以很容易的帮他作些探索测试，问题可能早就发现了。

原文转自：http://www.ltesting.net