51Testing软件测试论坛

标题: (驳斥）迷信自动化是测试人员的误区（1） [打印本页]

作者: cleverman 时间: 2007-7-17 00:51
标题: (驳斥）迷信自动化是测试人员的误区（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的不同版本呢。手工测试得需要多少人呢？

[ 本帖最后由 cleverman 于 2007-7-17 09:40 编辑 ]

作者: cleverman 时间: 2007-7-17 04:17
标题: (驳斥）迷信自动化是测试人员的误区（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万美金的年薪？你真有那么多吗？如果是的话，也不代表普遍的测试人员的工资。不知道你这个数字从何而来？如果你拿着这么高的年薪而不能搞定自动化的一些基本问题，那么我还有点为你担心了。

[ 本帖最后由 cleverman 于 2007-7-17 09:40 编辑 ]

作者: cleverman 时间: 2007-7-17 04:53
标题: (驳斥）迷信自动化是测试人员的误区（３）
第一，不要指望自动化能帮你找bug. 软件bug和生物的bug很像，测试的规律是bug少的地方bug越少，bug多地方越找越多。做测试自动化，往往在开发自动化的时候，该发现的bug就发现了。自动化开发完成，再想发现更多bug就很难了。这是无论你怎样跑你的自动化，也不会发现新的bug.

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

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

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

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

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

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

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

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

[ 本帖最后由 cleverman 于 2007-7-17 09:41 编辑 ]

作者: cleverman 时间: 2007-7-17 05:16
标题: (驳斥）迷信自动化是测试人员的误区（４）
第一，测试人员的自信心可以建立在读程序的能力上。在一个项目中，开发人员的工作是研究新技术，写出最好的程序。测试人员应该在开发人员研究的基础之上，更好的理解新技术，读懂程序。看懂程序可以使测试工作非常高效。不懂内部程序的人，可能会设计三十个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]不想多说了，自己自动化不行，别说脏话。你要是参与了设计，怎么还出现了第三里面的问题呢？

最后想说的是，这个作者的观点绝对不代表着微软的观点。作为前辈传授经验是好事，不过千万不要误导。作为晚辈学习前辈的经验也不要全盘接受，要学会思考，有自己的理解和ｉｄｅａ。

[ 本帖最后由 cleverman 于 2007-7-17 09:42 编辑 ]

作者: 刘洪鹏 时间: 2007-7-17 08:13
支持一下

作者: luming 时间: 2007-7-17 09:10
看着很乱，最好给出原帖地址，或者把格式整理一下。

作者: shanxi 时间: 2007-7-17 09:19
作者说的还是有道理的。
只不过观点有些偏激，有些以偏盖全，以他自己所做的项目得出自动化效果不大的结论，自动化带来效果的好坏跟项目背景有很大关系，不是所有项目做自动化都能做出很好的效果。

他其实并没有否认自动化的好处，只是在着重强调不要“迷信自动化”。

微软的项目有时确实会出现这样的问题，因为面大组织有些官僚化有时会导致投入不够。

微软某些项目的自动化发现不了Issue是有的：比如某个做了两年多的项目只发现了1个Bug。

作者: cleverman 时间: 2007-7-17 09:30

原帖由 luming 于 2007-7-17 09:10 发表
看着很乱，最好给出原帖地址，或者把格式整理一下。

http://peking2toronto.spaces.live.com/

这里看着会好些。我是直接copy过来的。

作者: cleverman 时间: 2007-7-17 09:33
他其实并没有否认自动化的好处，只是在着重强调不要“迷信自动化”。

我到没看出来。他说自动化是bullshit。原话是

下次有谁建议搞什么测试自动化构架，告诉他"That is bullshit".

作者: wuyuzimu 时间: 2007-7-17 10:32
感觉有那么点震撼。。。。呵呵

作者: luffy2095 时间: 2007-7-17 10:38
没有全部看完，没有站在同一位置的探讨，没有火花，只有摩擦。

作者: zgslhyh 时间: 2007-7-17 15:39
最近刚听了MS的培训自动化测试最大价值是预防缺陷测试的最高境界就是不让BUG出现

在程序员写代码时提供白盒测试工具使得程序员无法写出简单的BUG

在程序员提交代码时提供功能测试工具使得程序员无法提交有功能错误的BUG

所以MS的缺陷管理系统里已经大部分都是UI 易用性兼容性性能方面的BUG

一般的BUG根本无法到达产品库中

当然这一切都建立在详细详尽的需求文档上，只有这样才能在代码完成前，就由测试开发人员写好测试工具。

作者: cleverman 时间: 2007-7-17 16:33
标题: 我不太同意
自动化测试怎么能预防缺陷呢？自动化的开发一般是在产品基本成型或者已经成型之后才开始进行的。这个阶段bug已经存在与产品中了。
测试的最高境界是不让bug出现？这好像是开发的最高境界吧？测试的最高境界应该是在产品release之前找到所有的bug。
程序员写代码的阶段测试人员是involve不进去的。开发人员写的代码每天都在变动，而且根本就不check in。你要想得到要单独去程程序员要，而且，这个时期代码的变动极大，根本不值得去进行白盒测试。再说了，就算你去进行白盒测试，就能让程序员无法写出简单的bug？只能说发现程序员写出的简单bug吧？毕竟程序不是测试人员写的。
程序员提交代码时提供功能测试工具，使得无法提交有功能错误的bug？提交的时候，bug都已经在那里了，你在怎么提供测试工具，在怎么测试，怎么能说无法提交有功能错误的bug呢？
一般的bug根本无法到达产品库？什么算是一般的bug呢？Service Pack fix的那些算不算是一般的呢？我想现在你如果认真点，在windows里找到点一般的bug也不是太难吧？

作者: cleverman 时间: 2007-7-17 16:41
还有就是MS的培训也不是很大不了的事情，没有必要全盘接受。
我的工作被要求参加MS的培训不少，我都是签个到就走人。培训因为是针对大家的，因此都会讲得比较泛泛。
工作中能够用到的有能有多少呢？

作者: zgslhyh 时间: 2007-7-17 17:21
。。。没说完全避免啊，能避免掉大部分低级错误已经很了不起了

这里说的不出现BUG是指BUG不出现在缺陷库里，保证在Checkin之后没有一般性的BUG

BUG在Checkin后被测试人员发现，再到缺陷系统，1套走下来，改BUG的成本，远远高于在CheckIn之前。

听起来这样预防缺陷，好象很不可思意，但是MS确实办到了

连UI都是自动化测试的，并且不是一般自动化测试工具那样慢慢等界面然后1个1个点，而是深入程序内部的直接发送消息事件，UI的图象生成速度都不及测试工具处理速度。

这就是顶尖软件公司的实力

PS：MS 测试开发工程师待遇是开发工程师的2倍

[ 本帖最后由 zgslhyh 于 2007-7-17 17:30 编辑 ]

作者: shanxi 时间: 2007-7-17 18:10

原帖由 zgslhyh 于 2007-7-17 17:21 发表
MS 测试开发工程师待遇是开发工程师的2倍

这话不正确，得看项目。

作者: cleverman 时间: 2007-7-18 03:02

原帖由 zgslhyh 于 2007-7-17 17:21 发表
。。。没说完全避免啊，能避免掉大部分低级错误已经很了不起了

这里说的不出现BUG是指BUG不出现在缺陷库里，保证在Checkin之后没有一般性的BUG

BUG在Checkin后被测试人员发现，再到缺陷系统，1套走下来， ...

我觉得你被忽悠了。
微软的测试是很强，可也并不是神话。

作者: cleverman 时间: 2007-7-18 03:19

原帖由 shanxi 于 2007-7-17 18:10 发表

这话不正确，得看项目。

有项目，测试是开发工资的两倍吗？
虽然微软很重视测试，可是总的来说，测试的地位还是比不上开发。这也是为什么有人从测试转到开发（而且是很多人），没人从开发转到测试（能力差者除外）。
待遇来说，都是看级别的。同级别应该差不多，不过开发可以发展到的级别要超过了测试。也就是说，最终开发的待遇应该更高。
不过，测试发展的速度相对来说会快些，也就是说同样毕业的，过两年测试的可能比开发的工资高，可是过五年，或者更长来看，开发就超过测试了。
这也是为什么测试发展到一定程度，如果不往管理走，就要往开发走了。因为，测试发展很快就倒头了。当然也有能力一般者，在测试这个位子多年都还没倒头的。

微软的职位从好坏来分是PM〉Dev〉Test。这也是为什么，PM主要是白人，Dev主要是印度人，Test主要是中国人的原因了。当然了，印度人每种职位人都不少，test也不少，PM也有一些。可是中国人PM明显就没几个，大部分都是Test。如果Test好，白人干吗不抢着做呢？工资还是两倍？

我们从事测试行业也要承认事实和现状，不要一味的听到有利于测试的消息就无条件的吸收。总是用各种信息来证明测试比开发不差，甚至好是不对的。如果硬要比较，肯定是开发比测试地位高，待遇好。可是特例也总是有的。比如，微软的测试，确实比一般公司的开发水平要高。你如果横向比，也可以比较出微软的测试工资是一些公司开发人员的两倍。可是，这没有什么意义。

作者: zgslhyh 时间: 2007-7-18 09:12
我说的是中国微软工程院的情况，是做EXCHANGE2007的项目组

当然EXCHANGE相对MS其他的产品要简单一些，所以自动化测试可以达到99.9%

我不认为WINDOWS也可以这样搞但是OFFICE也是可以的

作者: shanxi 时间: 2007-7-18 10:40
微软的PM中中国人也相当多，特别是Redmond的中国人不少

但印度做英语版本的开发测试是已经形成的事实。

EXCHANGE和OFFICE这些MS自己产品Team的测试确实已经完全能覆盖所有功能

Windows的Sub Team也应该实现了完全的覆盖。

作者: cleverman 时间: 2007-7-18 13:14

原帖由 zgslhyh 于 2007-7-18 09:12 发表
我说的是中国微软工程院的情况，是做EXCHANGE2007的项目组

当然EXCHANGE相对MS其他的产品要简单一些，所以自动化测试可以达到99.9%

我不认为WINDOWS也可以这样搞但是OFFICE也是可以的

微软工程院，测试是开发工资的两倍？

作者: cleverman 时间: 2007-7-18 13:24
[quote]原帖由 shanxi 于 2007-7-18 10:40 发表

微软的PM中中国人也相当多，特别是Redmond的中国人不少

多看怎么说了？不可否认中国的PM是有的，从某种角度也可以说不少。可是，占总数的百分比是多少呢？核心项目里的PM又是多少呢？大陆来的有占多少呢？很多是香港，台湾，美国长大的呀。
Redmond中国人是不少，可是PM的比例并不大。Office是否能完全覆盖我不敢说。不过我比较强烈的怀疑。即使zgslhyh讲的北京研究院的例子也不是100%。不过我认识一些office工作的人，我可以打听一下。我想这个完全覆盖也是要看从那个角度去说吧？如果真的完全覆盖了，是不是就代表Office没有bug了？如果还有bug，怎么能证明是完全覆盖呢？我想我们大家都装过office的patch吧？
Windows的Sub Team是什么意思呢？Windows我还是比较熟悉的，绝对没有达到100%覆盖。这个我很自信的说。只是不知道你讲的sub team是什么team。

作者: mojinde 时间: 2007-7-18 14:13
其实,不管是什么的软件,不管你如何测试,BUG总会有的,你是测试不完全的,世界没有十全十美的东西.

作者: cleverman 时间: 2007-7-18 14:17

原帖由 mojinde 于 2007-7-18 14:13 发表
其实,不管是什么的软件,不管你如何测试,BUG总会有的,你是测试不完全的,世界没有十全十美的东西.

这个我同意。一般只要东西一绝对就变成错的了，物极必反。比如，100%自动化，完全避免bug等等。

作者: shanxi 时间: 2007-7-18 14:23
我也并没说Windows是100%覆盖了，只是说从sub的角度讲已经能够达到这个比例。

美国公司核心的都是美国主流人种的人，相比中国人来说印度人总体来说比较高。

另外，原帖的那个人留言了。Explosive Test是微软比较推崇的做法。

[ 本帖最后由 shanxi 于 2007-7-18 14:26 编辑 ]

作者: cleverman 时间: 2007-7-18 16:17
你说过“Windows的Sub Team也应该实现了完全的覆盖。”，给我的理解就是100%覆盖呀。完全还不等于100%吗？不是100%还算是完全？
还有就是sub的角度到底是什么意思呢，这个我也有点疑惑？
我看了他的留言，那个人也说了，他不代表微软。
我等一会儿回他。

作者: cleverman 时间: 2007-7-18 17:00
标题: 这是作者的回帖
写了这篇文章，惹得有些人很生气，后果很严重。所以再写一些，阐明我的一些观点。首先要说的就是欢迎大家的争论，其次我当然不代表微软的观点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。然后动手写一些测试程序，测试程序的原则一定要简单灵活但自动化程度不高。测试程序的主要目的是探索，手工探索，目测探索软件那里会出错。之所以要做探索测试，就是因为自动化要求对输入输出都要很准确的定义。输入好控制，可是没有探索测试，很难准确知道输出是否正确。自动化必须建立在探索测试的基础之上。就像用一只单发的步枪，一发一发精确打击敌人防御的弱点，不是用机关枪盲目扫射。单发的好处是，每打一枪你都要目测效果，然后调整子弹大小，射击的远近。如果像机关枪打出一百多发子弹，你会视觉疲劳，无所适从。自动化就像一只机关枪。

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

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

作者: cleverman 时间: 2007-7-18 17:01
标题: 这是我的回复
我也并没有什么生气，最近根据一些微软的员工写出的文章，感觉到对普通的测试人员产生了比较大的误导作用。因为是微软的员工，使得大家看文章的时候误认为代表了微

软的测试观点，从而把一些个人的经验当成了微软的真理来看待。这种误导作用我个人认为不是很妥当的，因此我也想说点什么，提醒大家不要全盘吸收。我想如果我们把范

围缩小到只是个人的观点，我可能不会花时间来讨论这些问题。因此，你的这篇文章我认为跟以前的相比有了很大的改善，可能以前由于没有表达全面产生的误解，这里也作

出了很详细的解释。而且，我也很欣赏你对于技术讨论的态度。因此，这里还是有些问题想向你请教或探讨。
1。因为您在微软已经做了六年的SDET，能不能介绍一下你这六年在微软的发展轨迹呢？还有就是今后计划如何的发展，SDET在微软发展到最后又会是什么样子呢？
2。关于测试人员和PM，Dev的关系部分：我想你说的不错。可是，测试人员最直接打交道的难道仅仅是PM和Dev吗？我不知道你有没有team lead，有没有manager？team

lead, manager关心什么呢？难道你的team lead，manager不关心自动化测试吗？我不清楚你到底是在做什么项目，难道你不了解自动化在Windows，Office都非常重要吗？

Windows每天都要出一个，甚至几个build，没有自动化，怎么能完成测试任务呢？
3。关于什么是自动化部分：首先你自己定义了自动化的含义，那就是较大框架的自动化。这和大家普遍理解的自动化就有了一定的歧异。当然我们这里可以姑且就按照你的

定义来讨论。你说的自动化在测试中的地位下降有没有什么具体的根据呢？比如在微软，是不是Office，Windows越来越少的进行自动化了？据我所知，他们对自动化的要求

是越来越高。这里，我感觉好像是自动化只是在你的心中地位下降了。你说的测试人员的大忌，我同意。可是，不把自动化作为首要目标就推出来不要自动化，是不是就太牵

强了？难道我不可以把自动化作为次要目标，第三目标，甚至不作为目标，只是作为实现目标的一个方式？还有就是，有没有时间做自动化还是要看测试人员水平的。比如说

，不久前，有人说要3个月实现的自动化，我花了一个月就实现了。再比如说，windows的周期一般至少两年，后来的维护工作至少五年，难道我们没有时间做自动化？还有就

是一般手工测试完成以后，产品就发布了。这个观点从何而来？难道Windows，office发布的时候没有做自动化？
4。关于测什么不测什么。你说设计阶段测试人员没有发言权，可能符合大多数的情况。可是对于技术背景非常强的测试人员是有足够的能力在这个阶段监督PM的工作的。不

知道你是否知道PM的spec需要测试人员review和sign off的。也就是说测试人员在产品的流程中，这个阶段是有权利监督的，并且判定spec是否合格。这个阶段当然可以讨价

还价了。你甚至可以指出某个feature,由于不能进行很好的测试，把它cut掉。spec中有什么没有什么，不是PM一个人说了算的。是要经过大家的review的，不合理的东西肯

定不应该存在进去。而且，他的老板在这方面也会进行监督的。我知道大多数测试人员没有水平在这个阶段去跟PM协商，可是资深测试人员是需要有这个能力的。
5。关于WhiteBox Test+Explorator Test: 请问没有自动化，你怎么实现在各种不同操作系统，不同cpu上，不同的Windows版本上,不同的SP进行测试呢？比如，操作系统，

Windows2000， XP，2003，Vista，2008， CPU，x86, amd64, IA64, 版本，Ultimate, Home Premium, Home Basic, Enterprise, Business, Starter, SP, XP SP1, SP2,

2003 SP1, SP2, 等等。难道你要每种组合都手工跑一遍？还有就是不知道你的产品多长时间出一个build，如果一天一个，你每天都要在不同的环境下跑一遍？

以上疑惑，还望得到你的解答。

作者: cleverman 时间: 2007-7-18 17:08
这个作者很黑呀。在CSDN上删除了我的留言。
算了，这种人我也不跟他讨论什么了。
大家别受误导就可以了。

作者: zgslhyh 时间: 2007-7-19 09:28
代码覆盖率没有100%

EXCHANGE 自动化测试用例的代码覆盖率每个模块都在85%以上，有的比较好的可以达到98%，整体大约90%

至于功能覆盖率。。。这个数据好象没什么用吧。。。猜想MS应该是100%的

据我所知 SETUP UNINSTALL 配置域都能自动化还有什么不能呢。。。

99.9%我是指自动化用例占总用例数99.9%

[ 本帖最后由 zgslhyh 于 2007-7-19 09:33 编辑 ]

作者: cleverman 时间: 2007-7-19 10:17

原帖由 zgslhyh 于 2007-7-19 09:28 发表
代码覆盖率没有100%

EXCHANGE 自动化测试用例的代码覆盖率每个模块都在85%以上，有的比较好的可以达到98%，整体大约90%

至于功能覆盖率。。。这个数据好象没什么用吧。。。猜想MS应该是100%的

据我所知 ...

UI软件的代码覆盖率整体达到90%并不是很困难的一件事情。代码覆盖最容易的就是测试UI程序了。你说的数据是可信，也是合理的。
理论上来讲，可能任何东西都可以自动化。能自动化不代表一定要自动化。正像这个文章的作者极力反对自动化一样，你是极力的夸大自动化。我个人认为你们都走了极端。我们应该理性地看待自动化。自动化不是万能的，自动化也不是bullshit,什么应该自动化，什么不应该自动化，应该如何自动化，里边都是有学问的。你所追求的90%的代码覆盖率，99.9%的自动化，正好是典型的文章作者所阐述的“迷信自动化”。我认为，作者的这篇文章正好适合你对自动化的这种看法。不知道你有没有仔细看作者的文章？

作者: zgslhyh 时间: 2007-7-19 10:28
手工的优势在哪呢？省钱省事嘛

自动化都能了想手工测测我还不能了吗？工具也是人手写的

追求是追求实际是实际何为迷信

作者: cleverman 时间: 2007-7-19 10:39
虽然我写了长篇来反对文章的作者。其实我主要反对的是作者拿自动化当作bullshit。
关于你提到的几个问题，好好看看这个作者的原文，里面都有很好的解释。
我不知道你自动化经验有多少，我可以稍微给你解释一下。
手工测试和自动化测试各有优缺点。根据不同的情况，我们应该合理的选择测试的方法。有些bug一眼就可以看出来，你要是非得编程序自动化那可麻烦大了。比如，你要是验证一个软件的所有text是否正确，所有帮助文件是否正确。你手工一会儿就测完了，自动化你要开发多长时间呢？
自动化都能了，想手工我还不能吗？这个思想也大错而特错了。比如，你要在word里面输入几十万的字符，如果编个程序，很快就实现了。如果你手工，不得把你累死？
总而言之，做测试一定不要教条。灵活掌握和运用才能成为资深。

作者: cleverman 时间: 2007-7-23 13:50
标题: 看到了一些高手对这篇文章的回答，感觉比较长见识，大家有兴趣也看看。
13 楼：omomo
看起来这个帖子里,楼主是微软的

peking2torento是前微软的, 目前在Google. 呵呵.



楼主,  你公布内部网站的内容,请小心!  这是Standard business contact不允许做的. 我觉得你应该删掉那部分引用和内部链接. 以避免给你自己带来麻烦



我读了peking2torento的反驳,觉得多数是在理的,可能语言有些激烈. 在楼主的后一篇回复中,于是变得讨论的理性些. 这个标题之下其实可以做很多理性的讨论,只是楼主的第一帖,为了证明这个标题,说的有些言过其实了.



楼主上面又说了.有个新来的,写了个自动化测试,但是没有找到那个bug. 还是回到我之前的看法,我认为测试人员的素质,我把深刻理解产品和产品的目标用户为第一,自动化为第二. 那个新人是因为没有做好第一条,所以自然工作做不好. 但这不能抹杀自动化的意思. 如果要我来说,那是test lead培养新人的失败. 我认为正确的ramp up策略是让新人先手工测试,读spec,读dev design和尽可能的玩他要测得产品. 这样搞几个月以后,再叫他开始做自动化测试,如果按照这个顺序,我想新人的成长就会不错了. 这不是自动化测试的错. 不要把项目中的失误总是归结到自动化测试浪费了你们的时间. 说到底那是你们自己分析的问题. 不经过分析就执行的自动化策略,我也反对.

发表时间：2007-07-20 16:40:17 14 楼：omomo
我希望当测试人员来试图说服大家做一个自动化测试方案都要明确地告诉我收益/付出的比例有多大. (ROI)

能力不同的测试人员,分析出来的ROI基本上就可以看出他的水平了.有些人我听听他的分析,就知道这事情有没有谱.也可以看出他的技术水平到底怎么样.当然这也要求我们自己与时俱进,不断地追求技术进步.



做自动化测试计划,我们无非就是在quality/schedule/ROI中间平衡.





发表时间：2007-07-20 18:13:32 15 楼：papercrane
抄抄底，挑挑刺，原文就不贴了，说说个人见解而已：



有些做测试的人因为不正确的动因去做自动化，不能推断出做自动化的测试人员都有不正确的动因，哪怕这个比例是1-1.0e-100。很多人献血是为了卖钱，但不能说献血者都是不崇高的。这个立论会导致以偏概全。



后来接手项目的人喜欢重来，不管在测试还是开发领域都是普遍存在的“坏”现象，如果因此否定测试自动化的作用，估计大量的development framework也都难逃一劫了。



找bug只是测试工作的其中一个任务，哪怕再重要（当然是很重要），也不是唯一的令产品开发失败的风险。请注意“唯一”和“风险”：风险就是，搞不定就完蛋，不管其它方面做得多好，所以就是要做好！唯一就是，只弄好就行，其他别管。好了，解决了找bug的风险，其他的风险呢？如果有项目因为过于着重其他风险而没有处理好找bug的风险，似乎是时间管理或者风险管理没有搞好的原因居多喔。



分析变动影响（impact factor）也是需要代价的，从纯粹代码分析到纯粹回归测试之间，显然是有机可乘的。代码分析随代码覆盖量增长区分效果急剧下降；回归测试随代码覆盖量增长执行时间延长。那么作初步代码分析，定出范围后自动化回归测试，结果如何？



开发过程和工具都针对Agile Development做了大量改进和适应，自动化测试的实践跟不上是自动化测试的错呢？还是不思进取的错？从管理、设计到工具，开发人员不断降低行为粒度；自动化测试是天生就不能这么做还是没想到可以这样做呢？



找到很多的bug和找到难以重现的bug，使用的方法是不一样的。重负荷下处理特定序列的bug，race condition，dead lock，很多时只有依赖自动化才能容易重现。产品发布以后暴露的问题，很多也属于这一类。自动化测试除了发现这些bug，还能高效的确认修复是否成功。否则想象一下，修复之前折腾一次，修复之后又折腾一次，每次regression折腾两次......



功能设计freeze了才说有些功能不测？计划阶段和设计阶段复核的时候测试人员不参加的吗？早就应该跳起来啦。Test is the guard of the product！

发表时间：2007-07-20 19:52:11 16 楼：goldcattle
我觉得楼主的观点有点以偏概全。

自动化测试的目的一般有几个：

1、防止regression.

2、替代简单而重复的手工测试。

3、手工测试无法做到的测试。

如果你的项目有这样的需求，那么自动化测试是必要的。当然到底才用不采用自动化测试，自动化到什么程度和项目的预算和时间相关。



楼主主要在的测试是在“涉及网络安全认证与授权，是公认相当复杂的项目”

我想如果楼主接触的是嵌入式底层开发或者直接和电路打交道的话，那么楼主可能大声说，自动化测试根本是不必要的。

对于微软来说，很多组是提供一些二次开发的平台。这些平台往往会提供一堆API。这些API肯能会内部使用也可能会外部使用。有的team最后的产品就是一堆API和binary。这些东西根本没办法手工测试。这些项目组的测试压力是相当大的。他们必须要理解每个API究竟是干什么的，才能设计出好的case。然后还有设计一些黑盒的例子去测这些case.





对于有UI的产品来说，楼主很大程度上忽略了回归测试。

从接触到大的项目而言，很多人成百上千个人在开发一个产品。每个team可能会依赖好多个team。如果某个team新加的代码影响到你依赖的一个模块。如过没有回归测试来保证，我想测试team 根本没有时间来做ADhoc testing。



你用Adhoc 发现了一堆错误，不能把功劳完全归功于Adhoc testing。你应该看到，是因为有自动化测试在保证着产品的区ality让测试人员在防止regression bug的战斗的解放出来。

不能吃到第九个馒头饱了，就说前面8个馒头是没有用的。

本回复于：
2007-07-20 19:53:20 被【goldcattle】修改

发表时间：2007-07-20 23:22:57 17 楼：Skyfire1201
看了这篇文章以及回复之后深有感触，觉得真是不能用片面的例子否决全部。读过离散数学的人都知道，如果A是B的子集，而A是错误的，这并不能表明B全部是错误的。楼主根据自己对一种自动化测试失败的经历就否认了所有的自动化测试，而推理出“自动化测试无用”的理论，正是犯了基于一点否定全部的错误。其实自动化测试分很多种，有为了防止regression做的功能性自动化测试，有压力自动化测试，有为本地化做的自动化测试，更有exploratory自动化测试。就算automated regression在某些产品上作用不大（比方说生命周期只有1-2年甚至几个月的游戏），不能因此就否定所有的自动化测试。



发表时间：2007-07-22 18:00:04 18 楼：papercrane
关于API测试:



上次去总部出差遇到一老员工在庆祝二十年微软生涯。问及其经历，答曰基本上是测试两个Windows API；再问test case数量，答曰三千左右；最后问执行耗时，答曰全部平台的组合约需两天，幸好win98已不支持，否则无法按时完成。翻看其blog，原来是timer相关的API。归来后对三千之数不得要领，苦思冥想之下释然，此事牵涉甚广：

- 内核重入

- 与Windows Message Pump交互

- 与debugger交互

- 与Windows Time service交互

- 时间/时区变动

- 以往版本的regression

作者: yt1985cncn 时间: 2007-7-23 21:46
楼上有人说从开发转到测试的人员很少，能力差的除外。我对这点很不赞同，一个良好的测试人员可以没有做过开发，那他要的是敏锐的直觉。如果他做过开发，则更有利于他对整个系统的把握。再着，测试往往看全局，而开发可能专注于一点。所以从职业的发展来看，也是先开发，后测试的，再管理，然后咨询的。

作者: cleverman 时间: 2007-7-24 01:18

原帖由 yt1985cncn 于 2007-7-23 21:46 发表
楼上有人说从开发转到测试的人员很少，能力差的除外。我对这点很不赞同，一个良好的测试人员可以没有做过开发，那他要的是敏锐的直觉。如果他做过开发，则更有利于他对整个系统的把握。再着，测试往往看全局，而 ...

你去大公司看一下，大部分做测试的是因为面试开发没有成功才去做的。包括这篇文章的作者。
很多人本来是应该做开发的，要放到测试锻炼一两年，再转回去。做了测试再去开发更能保证coding的质量。
开发的路可以发展很久，测试则不同，很快就发展到头了，发展到头还是得转开发，或者管理。可是，管理毕竟是少数人才能做的。因此大部分如果想往上发展还是要转开发。
当然我说的是测试发展到头，很多人还不是很明白测试怎样算发展到头，也有很多人根本就发展不到头。
还有就是我说的是目前的情况，不代表以后也这样，而且我说的是大公司的情况，国外的情况，不代表国内，国外小公司的情况。
个人来讲，我觉得测试发展两年多就到头了，不能说完全到头吧，但是工作基本上就是重复了，不能学到什么新东西了。不只我自己，连我的几个老板都让我在开发上下功夫。（对我在测试上已经没什么要求了）

作者: cleverman 时间: 2007-7-24 01:28
对了，我自己也是无奈才开始做测试的。要不是年纪大，我早就转开发去了。
另外，我做测试将近两年的时间都十分的郁闷。一直想要脱离这种状态。现在其实已经不是纯测试了，可以说一半测试，一半开发。而且我的工作跟纯的开发是非常接近的。可以这样说，我们这里的测试要懂很多开发知识，比一般公司的开发人员水平还高。现在自己觉得转去开发还没有ready，各种原因吧。如果以后学习了很多开发知识以后，现在的工作用不到多少，那也很有可能去搞开发了。幸好这里的测试可做的东西很多，要是一般的公司，非得把我郁闷坏了。还有就是要是跳槽的话，很可能就直接申请开发职位了，因为其他公司很少有这种测试职位的。

作者: smz_198181 时间: 2007-7-24 09:53
我想cleverman的意思不是说测试做到多少岁就做不下去了，而是指你能力达到一定程度，测试这个行业已经没有和你能力非常match的职位了，再想往上提升只能去开发这个范围找合适的位置，绝大多数测试工程师不要担心这个问题，因为很多人能力可能也达不到这个程度， cleverman都在google美国总部当上了team leader，年薪10W美元＋，还要再过一段时间再转开发，咱们还没到担心这个的时候，而且即使真的能达到cleverman那个位置，有了哪种能力转开发也是非常简单的事情！

作者: dypku 时间: 2008-4-24 11:48
标题: 从开发转测试，并不都是应为能力差！
cleverman，你好！
你的高见：“可是总的来说，测试的地位还是比不上开发。这也是为什么有人从测试转到开发（而且是很多人），没人从开发转到测试（能力差者除外）。”
难道从开发转到测试，就是因为能力差么？我认为有点偏颇，呵呵~
从开发转测试，和个人的兴趣也是有关系的！

[ 本帖最后由 dypku 于 2008-4-24 11:50 编辑 ]

作者: cleverman 时间: 2008-4-24 12:12
我这句话是指的在微软吧?
如果要是从整个情况来说,不是某个公司的话,当然不是这么绝对.
关于兴趣,这个可值得讨论,我感觉很多人从开发转到测试是拿兴趣作为一个借口,或者说作为自己安慰自己的一个理由.
当然我不排除有些人是真的不喜欢开发而喜欢测试.可是一般能力强的人还是觉得在开发上更能体现自己的价值.我觉得真的能力很强的人是很罕见去转测试的.当然有些因为钱,或者晋升的因素,我指得是纯技术.至少我是没见过.

作者: afeng 时间: 2008-4-24 13:46
测试的能力一定比开发差,我不敢同意罗
起码学习能力是差不多的吧,至少我没觉得,开发会的东西,我会学不会,即使你是硕士,博士,我觉得在能力上我和你也没什么区别,而我转作测试,主要是看幸福度,我感觉作开发的幸福度远不及测试,人活着不能光为了工作,为了钱,也不可能为了证明自己是强者,就一味给自己加压,人活着最重要的还是开心,有些企业家,家资数亿,比开发强多了吧,到了30几岁,一命呜呼,这样的人生又有什么意义呢,所以讨论开发,测试谁更强,本身就没意义,所谓人各有志,不能强求,

作者: cleverman 时间: 2008-4-24 14:04
标题: 回复 41# 的帖子
测试和开发是广泛的概念，如果直接广泛的比是没有什么意义。比如，微软，google，IBM的测试那是比一般公司的开发要强得。很多公司的开发人员跳到大公司也只能做测试，甚至是从junior做起。如果广泛的比，当然是不现实的。但是，在一个公司，一个team，或者自己跟自己比，开发工作的难度是要大于测试的难度的，开发能学得东西也是比测试要深一些的。这是为什么很多测试的有机会就转开发，而很少开发转测试，这里我指的是成熟的公司，成熟的工程师。我不知道你为什么认为你的学习能力跟别人差不多呢？你认为普通学校毕业生跟清华，中科大能是一种学习能力？如果是的话，怎么当时没上清华，科大呢？如果你觉得你能力跟硕士，博士差不多的话，那他们多读那么多年就是白读了？对于你说企业家30岁一命呜呼，我还真是基本没见过，做工程师的倒是不少。当然人各有志，如果你感觉到做测试幸福当然很不错。可是我的观点是，在社会上，在你的一生中，你不可能总是幸福着。一般来说，对于一般人来说，苦恼的时间可能更多。现在世界人口这么多，尤其是在中国这么竞争激烈的环境，如果自己不想证明自己是强者的话，可能幸福也会是短暂的。没有白来的幸福，幸福的背后往往伴随着巨大的痛苦。如果年轻的时候不吃苦，以后也未必能避免吃苦，而且年纪大了吃苦有可能都没机会回头了。这是我的个人观点，我是个悲观主义者。我同意开心最重要，希望我的心态不要影响到你。

作者: stilldeeppool 时间: 2008-4-24 14:05
不可否认测试行业存在这样的一种浮躁的现状,不管是自动化测试或是手工测试,抑或是黑盒测试,白盒测试
任何一种测试方式只是作为测试人员发现缺陷的工具
举个简单的例子,用一把刀可以杀死一个ZD份子.另一人用一把枪杀死一个ZD份子.
他们之间因使用的武器不一样,难道爱国热情会有高低吗?
目的是一样的,只要达到了,用刀,用枪又有什么区别呢?

只要能发现缺陷,自动化测试难道会比手工测试高人一等?编程序的人一定比不会编程序的人高人一等?
归根到底,还是一个心态在作祟,担忧的是这个心态开始流行起来,在刚刚进入这个行业的地方

不管是黑猫或是白猫,或是机器猫,宠物猫,只要能捉到老鼠,就是好猫

作者: cleverman 时间: 2008-4-24 14:13
标题: 回复 43# 的帖子
事实上，如果你去看公司的招聘要求，会自动化测试和编程的会很有优势。有些公司招聘测试必须会自动化和编程，并且要有实际开发经验。当然了，从大多数公司的测试情况来看，我同意你的看法，不过这些也是会改变的。

作者: afeng 时间: 2008-4-24 14:24
读书只不过是读书的能力,硕士也好,博士也好不等于他们书读的好,工作就一定好,在我看来中专生在微软作个开发也未尝不可,说不定还比那些硕士,博士作的好,你认为开发高人一等,我觉得有些开发象白痴一样,企业家30多岁死的多的是了(王均摇知道吧),就是50几岁翘掉又有什么区别呢,作软件的,也就这么几道菜,谁来作都一样,你可以学的比别人多,但在一个公司里以就老板一个人可以觉得自己高人一等,要是有个什么作技术的,觉得自己会的比别人多,就高人一等,那我觉得和sb没什么区别.

作者: cleverman 时间: 2008-4-24 14:54
好像你并不清楚硕士，博士是搞研究的，不算是读书的。他们当然也会读书，但是主要还是以研究为主。他们研究的成果可以申请专利，或者开发成产品，有些博士甚至直接开公司了，比如Google就是这么起来的。当然搞研究好，也未必就一定会工作好，可是也没有道理说他们一定工作的不好吧？我想总的来说工作还是要比一般人出色吧？至少是有些工作一般人做不了，只有他们能做，比如做教授，就非常要求学历。还有做研究工作的，一般都是要求博士学历的。你认为中专生在微软做个开发也未尝不可？这也仅仅是你个人的观点，如果bill说出这个话还会有人听，你说的话，里边并没有什么论据所支持呀？比如，做开发需要的一些基本功，都是中专生所不能学得到的，不知道怎么去工作？那个王均瑶我还真不知道，算我孤陋寡闻了。另外就是别人会的多，自己感觉比别人强也不需要称他们SB吧？你心目中的SB是怎样的定义呢？而且说别人SB也并不能证明自己比他们强吧？顶多是自我安慰一下吧？

作者: yil1 时间: 2008-4-24 15:01
我觉得你心里压力过大了！该休息了！

作者: afeng 时间: 2008-4-24 15:48
搞研究是说得好听了,其实也就是这么回事,我觉得天下就两种人,读的进书的和不想读书的人,其实你可以说他们在读书方面有差距,但在作其他事上也许就没什么差距了,难道你觉得硕士,博士只要读书好,什么事都作的比别人好,你去看看现在作老板的,有几个是真正的硕士,博士,读书也和作其他事情一样是有目的的,我为什么要读硕士,为什么要读博士,不是为了读书,而读书,否则也不用说,职场上情商大于智商了,至于sb么,我的定义就是情商非常低的人,不晓得你同意不同意,不过凡是那种喜欢出风头的人,喜欢装老大的人,下场都不怎么好.

作者: yil1 时间: 2008-4-24 16:20
51testing卧虎藏龙，看来以后要多来逛了！

作者: cleverman 时间: 2008-4-24 17:02
你说的没错，我指的是普遍，而你指的是没有绝对。其他的就不想解释了，不过情商低就是SB，这个我不太同意，因为很多天才确实是情商很低，很多人生活都不能自理，甚至根本没有情商，我觉得我们还是应该很尊敬他们。你说的喜欢出风头的人，喜欢装老大的，我觉得要看实际情况，如果他们真的是水平高，我就无所谓，我会向他们学习，如果水平一般还这样，我也看不惯。当然，我个人认为一般来说高手都不是喜欢卖弄的人。对于他们的下场，我不是很关心，我个人还是希望大家都好，即使自己看不惯。我同意情商很重要，在很多地方都是大于智商，但是在特定的情况下智商要起决定性作用了，比如科学研究，就像爱因斯坦，他的研究成果没有智商是万万不能的。我们最初的话题是开发与测试水平高低的问题，现在已经扯远了。无论你怎么想，我个人还是觉得我跟开发的水平相差还是比较大的，我预计是要花2年的时候来弥补。当然我指的是我们公司的开发。时间不早了，要睡觉了。明天再聊吧，最后想说的是我的话也主要是从个人的经验和感受来谈的，有错误也难免，肯定不是100%正确，我们都可以保留各自的观点，如果不能达成一致的话。其实我也一直在改变自己的观点。

作者: afeng 时间: 2008-4-24 17:34
埃,多说无益,个人看着办吧,很多人都是不发言的,我也不想多说,也许理解有误,得罪得地方还多多包涵

作者: cleverman 时间: 2008-4-24 17:50
没有什么得罪不得罪的。要说得罪，我的话可能更会伤测试人员的心。不过任何事情有不同的声音都是很正常的。你说的很对，很多人不说话，可是其实心里很反对我的观点。我想这个是非常正常的。每个人都有自己的理解，我想我的理解应该能帮助一些人，也许是很少的一部分人，可是毕竟能帮助一些。而不同意我观点的人，我的话应该也损害不到他们什么的，所以我觉得还是有必要说出来。如果不同意我观点的人认为我真的伤害到了他们的话，我可以把我的发言删除，跟需要的人私下交流。已经有一些人因为我的发言转向了开发的道路，我也希望自己没有误导别人。

作者: afeng 时间: 2008-4-24 20:56
可我始终觉得人的发展是要顺其自然的,如果一味强求,也许结果并不美妙,反而失掉了很多原本应有的东西

作者: cleverman 时间: 2008-4-25 01:29
这个主要是看性格，有些人喜欢顺其自然，包括我自己在内。有些人喜欢给自己压力，制定很高的目标。当然确实像你所说，很多结果并不美妙，有些很糟糕。我们自己的性格很难改变，但是对于职业发展的规划，甚至人生的规划还是应该有的，能够看清楚行业的实际情况也是很重要的。当然每个人都会有不同的规划和对行业的理解，未必谁就正确，谁就错误。随着时间的推移，行业的发展，自己的经历，大家的理解都可能发生变化，甚至是巨大的，颠覆性质的变化。更有很多时候整个情况的发展可能完全超出自己的预料，使自己很难顺其自然，必须被迫地去做出改变。举几个例子：比如国内的下岗工人，比如微软以前手工测试的那些工程师。还有一个很典型的例子，因为国内近20年的高速发展使得国内人很难有这些体会，在加拿大一个朋友的同事搞开发的，在IT泡沫的时候被裁员了，当时根本找不到工作，他就去森林做伐木工人做了两年，等经济好转的时候才又回到原来的公司。你说你怎么能保证自己一直顺其自然的发展呢？你只能控制自己，而不能控制社会的现实，很多时候是需要强迫或者被迫做出转变的，为了适应社会的发展。否则真的到了那一天，后悔也来不及了。

欢迎光临 51Testing软件测试论坛 (http://bbs.51testing.com/)