[comments] 作者自己在自动化中出现了很多问题之后,并不是积极地想办法去解决这些问题,而是消极地放弃了自动化测试,实在是令人感到可惜。要知道,发现问题是最能提高人的能力的时候,你把这些问题解决了,你的水平,能力,经验就相应的得到了提高。并且,作者从一个极端走到另一个极端以后,就想方设法找一些证据来支持自己的观点。比如,通过微软员工的blog。一个员工blog里的观点能证明什么呢?你有没有去问过windows 测试组对WTT的观点呢?别人一说,你就相信?可以看出作者不是一个严谨的人,吸收东西总是从自己的思想角度出发,而没有经过验证。作者在自动化过程受到挫折后,竟然与当今测试的发展背道而驰,实在是令人费解。
作者的问题是,一个复杂自动化框架值不值得去做?如果不做自动化,能不能达到同样效果。从这里我们又一次看到了作者走了极端。复杂的自动化不值得做,就要抛弃自动化。首先,我不想辩论到底什么是复杂的自动化,是它本身复杂,还是你自己给搞复杂了。这里我假设,它不值得做。可是,这样就抛弃自动化吗?我的问题是,如果复杂的自动化不值得做,那么相对简单的自动化值不值得做?合理的自动化值不值得做?是不是一定就要抛弃自动化?接下来,作者用自己的经历来说明,自动化没有必要,并且和其他的team进行了比较。从数据上看,好像自动化测试真的不如他的手工测试。我想这种比较意义不大,因为我可以给你举出更多的例子,自动化比手工测试效果好。并且,你hotfix少也不能说明什么,说不定你要用合理的自动化,都没有hotfix呢。别人如果不用自动化,hotfix更多呢。产品不一样,都很难进行公平比较。另外,既然公司给他们配备了更多的测试,本身就说明了其他组的项目复杂度比较高。你们少的测试,说明了复杂度比较低。最后质疑一下工资成本,12万美金的年薪?你真有那么多吗?如果是的话,也不代表普遍的测试人员的工资。不知道你这个数字从何而来?如果你拿着这么高的年薪而不能搞定自动化的一些基本问题,那么我还有点为你担心了。
发表时间:2007-07-17 16:47:24 6 楼:peking2toronto (驳斥)迷信自动化是测试人员的误区 (3)
第一,不要指望自动化能帮你找bug. 软件bug和生物的bug很像,测试的规律是bug少的地方bug越少,bug多地方越找越多。做测试自动化,往往在开发自动化的时候,该发现的bug就发现了。自动化开发完成,再想发现更多bug就很难了。这是无论你怎样跑你的自动化,也不会发现新的bug.
[comments]我承认大部分的bug都是通过手工测试来找到的,我也相信很少会有人把找bug完全依赖于自动化。可是,你也提到了,在开发自动化的过程中,该发现的bug就发现了。这也就是说,如果没有开发自动化,这些bug还未必能被发现。这里边的意思就是,自动化开发完了,可能找不到什么bug,可是在开发过程中还是对找bug做出了贡献。我们总是说要注重过程,因此从过程来说,自动化对找bug还是有它的必要性.对于作者后面的问题,我得先说说什么是自动化测试的目的了(在找bug方面).我们知道,很多模块是要跟其他模块来合作工作的,即使你自己的模块没有任何变动,也有可能因为其他模块的变动被fail掉。比如最近的Norton的问题。Windows的update引致了Norton的误报。因此,自动化测试的非常重要的一个目的就是保证没有regression的问题。也就是说,我们不指望automation找到新的bug,可是以前能够work的一定要保证继续work。我工作过不少公司,很多产品都是一天一个build,请问没有automation的话,你怎么能够手工的运行一遍你的case呢?而且,每天运行一遍的话,你烦不烦呢?
还有就是,作者说的不会发现新的bug还是太绝对了。我的自动化可是发现了不少新bug呢。有的是因为开发人员改动代码造成的,有的是因为其他team的模块发生变动造成的。有的是测试工具本身的bug造成的。总之这种各样,并且每种问题,我都是要报bug的。最后,无论对自己的team还是其他的team都做出了自动化测试的贡献。
第二,不要指望自动化对Regression Test的测试的贡献。软件的特点是如果一次做对了,以后永远不会出错。当程序出现变动时,只要针对变动的部分测试就可以了,以前测过的东西,如果和变动没有关联就不会出错。相反如果,程序出现很大变化,自动化可能完全不能用了。
[comments]我想这种观点也不需要我反驳了吧?任何有个有一定测试经验的人很难说出这种话来。这里边每一句话都是错的,如果有人提出不明白,我再来解释。这里我假设大家都清楚怎么回事。
第三,自动化不如测试工具加手工测试。我不建议测试人员作全面自动化,相反我建议测试人员多做小巧灵活的测试工具。自动化往往需要自动判Pass或Fail. 想想你如果测试用于生成www.microsoft.com的页面的产品,你如何判断页面框架生成的正确?很多东西是动态产生的,你很难确认所有的内容的正确性。如果你自己用这个产品手工做个页面,用肉眼很容易判断所有相关和不相关的内容生成的正确性。我就是用这个方法在工作中发现了网页上谁也想不到的bug, 如果用自动化很难在测试阶段发现这个bug.
[comments]又一次以一个例子引申到整体自动化。可能你的这个例子没有什么问题,可是根据这个例子,我实在不能得出自动化不如测试工具加手工测试的结论。还有就是多做小巧灵活的测试工具?这个最好能具体谈谈。什么是多做?什么是小巧?什么是灵活?作者从一个自动化工程师发展到现在用肉眼来测网页,还拿着12万美金的年薪,我实在是怀疑作者的测试发展轨迹了。这个工资应该是很senior的了,怎么还在肉眼测网页呢?这种工作在google是最低级的。都是合同工来做,根本不可能那么高人工。
第四,软件项目的生命周期就定了自动化的无用。现在很多网络应用项目的生命周期都很短,一个项目从生到死不过两三年。死的定义是项目进入Sustain Engineering维持状态。自动化原来的一个主要目的是使软件测试的未来阶段越来越容易,成本越来越低。可是当一个项目死掉了,自动化还有什么用。而且最新的敏捷开发,软件的要求,程序,接口,界面在不断变化,自动化怎么可能跟得上变化。与其去搞自动化,不如多理解变化,直接测试变化的东西。
[comments]又一次从网络应用的生命周期短,引申到了整个的软件项目。windows存活多少年了?Office多少年了?有没有死掉?就算是网络应用,Google Search多少年了?有没有死掉?Google的界面这么多年变化也不大吧?可能你做了一些项目很快死掉,但是不能代表整个的软件行业。软件的要求,程序,接口,界面在不断变化?我真怀疑当初是怎么设计的?如果这样的话,你手工也没法测。这个问题好像不是自动化测试的问题,而是产品设计的问题吧?
发表时间:2007-07-17 16:47:41 7 楼:peking2toronto (驳斥)迷信自动化是测试人员的误区 (4)
第一,测试人员的自信心可以建立在读程序的能力上。在一个项目中,开发人员的工作是研究新技术,写出最好的程序。测试人员应该在开发人员研究的基础之上,更好的理解新技术,读懂程序。看懂程序可以使测试工作非常高效。不懂内部程序的人,可能会设计三十个test cases, 才能找到一个bug. 懂程序的人每个test case都可能发现一个或多个bug. 我有30%的bug都是读程序读出来的。由于对开发人员的程序有很深的理解,即使release后出了问题,也能很快理解问题出在什么地方,是否是bug.
[comments]读程序也算是测试人员的一个基本技能了.可是没有任何理由说读程序就能代替自动化测试呀.我承认读程序是一个非常好的测试方法,可是我们更需要其他好的方法来对软件进行全面的测试.自动化测试难道不是其中一种吗?通过一种测试方法来贬低另外一种,不是很客观和有意义.
第二,测试人员写测试程序的时间应该尽量最小化。测试人员测试的时间分配应该是, 30%读程序,20%写测试程序,50%写Test Cases和运行Test Cases. 好的测试员的工作重点应该放在理解要求,理解客户需要,思考在什么条件下程序会出错,而不是思考如何去自动化。如果时间都放在设计自动化上了,必然会影响测试,分散测试资源。测试人员应该边读程序边测试,读程序帮助找到好的Test Case,测试帮助验证理解和猜测。
[comments]我们今天的主题本来是在讨论自动化测试方面,你现在却跳到了白盒测试方面。我想白盒测试可以单独作为一个topic来讨论。还是那句话,用一种测试方法来贬低另外一种,没有意义,也没有说服性。毕竟大家搞自动化大多数都是从黑盒测试的角度出发的。
第三,测试人员要学会讨价还价。很多时候项目经理,开发人员搞得东西不是客户马上需要的,或许是永远用不到的。测试人员可以和项目经理研究先测什么,后测什么,那些不测。比如,我做的一个项目,我发现30%的功能是现在用处不大,所以我直接告诉项目经理那些东西我不会去测的。事实证明,这样做节省了很多人力。
[comments]这不是偷工减料吗?用户不用为什么还要设计呢,还要实现呢?你应该在设计阶段就进行质疑。对用户的需求方面是项目经理的责任。你的目的是监督项目经理的工作。如果你认为这些东西没用,应该在设计阶段就cut掉。而不是等到测试阶段才发现,并且不进行测试。你现在没有节约成本,你浪费了很多pm和dev的时间,加大了他们的成本开销。你现在是拿PM的错误来跟他们讨价还价,他们也没办法。但是,作为一个优秀得测试人员,最好的办法还是应该在设计阶段发现这些问题。还有就是,既然已经实现了,如果你不进行测试,里边的风险是很大的,是绝对的不应该的。这里我不想多讲,因为道理还是很简单的。如果有人不明白我再解释?
第四,测试人员要多花时间参与设计。测试人员一定要紧跟项目经理和开发人员的要求变化和设计。理解每一个要求的影响。在每个项目周期中,去比较当前版本和以前版本的所有程序变化。重点测试变化。
总之,少做自动化,多写小工具,读懂程序,是高效省钱的测试方法,除非你钱多得没地方花。下次有谁建议搞什么测试自动化构架,告诉他"That is bullshit".
[comments]不想多说了,自己自动化不行,别说脏话。你要是参与了设计,怎么还出现了第三里面的问题呢?
最后想说的是,这个作者的观点绝对不代表着微软的观点。作为前辈传授经验是好事,不过千万不要误导。作为晚辈学习前辈的经验也不要全盘接受,要学会思考,有自己的理解和idea。
发表时间: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的测试工具,多做探索测试,我也可以很容易的帮他作些探索测试,问题可能早就发现了。