??xml version="1.0" encoding="utf-8" standalone="yes"?> 本文中所q的试主要指Y仉域的试Q与核武器的试无关?span lang="EN-US"> 试q个行业的从业h员是保证软g实现的完整性和正确性。当Ӟ虽然患者的w体健康与否取决于患者自己,但一个优U的医生除了有_湛的医术外Q也会用各种Ҏ渠道让患者明白如何预防疾病发生。虽然学生的成长也是取决于学生自己,但一个优U的教师除了有_湛的教书能力外Q也会用各种Ҏ渠道让学生明白做人的道理。所以,虽然软g质量的好坏取决于实现软g的hQ但是一个优U的测试h员除了优_湛的测试技能外Q还会用各种Ҏ渠道让实现者明白如何做Z个高质量的Y件品?span lang="EN-US"> TL如同MQȝ或者硕士生导师Q他不仅在某个领域内有很q造诣同时也非常有热情l箋在这个领域中深入Qƈ且也愿意带领部分h一h探烦、研I、创新。套用前面的故事Q即如同扁鹊三兄弟的父亲。据说他自q行医之道ȝ?span lang="EN-US">2本秘c,一本是《医道》、一本是《防道》,Ҏ扁鹊三兄弟的天资Q分别传授了l他们。扁鹊三兄弟的功力也是长q跟着L高明的父亲看病实践及理论教导而日益增长的。所?span lang="EN-US">TL不仅自己能够独立做战Q也能够带领人共同做战的leader?span lang="EN-US"> 以上是对P路线的阐?span lang="EN-US"> 前面说了试工作本n是ؓ了保证Y件品的正确性完整性。但在研发体p运作中Q测试团队或者测试部门的建立则是Z提升研发效率?span lang="EN-US"> ?span lang="EN-US">1 前提假设都不变的情况下,如果变成如图2的话,那么q个研发体系实在不咋地?span lang="EN-US"> ?span lang="EN-US">2 前提假设都不变的情况下,如果变成?span lang="EN-US">3的话Q那么这个研发体pd比较优秀Q因Z仅开发和试本n的工期都得到了羃短,d期也得到了大大羃短,q且q降低了Mh力成本?span lang="EN-US"> ?span lang="EN-US">3 以上几种体系的徏立实施都M开理者,x我们所说的M。下面我们就来说说作为测试部门的M应该做哪些事?span lang="EN-US"> 《大学》中有谈C个h从内在修d外发事业的完成是q样8个顺序:格物、致知、诚意、正心、修w、齐家、治国、^天下?span lang="EN-US"> 大致意思是了解事物原来才能拥有知识Q心意才会真诚,思想才会端正Q然后才能提高自w的品d修养Q自w品德修养高了才能管理好家庭、治理好国家、天下太^?span lang="EN-US"> 所以说难,M真的很难Q要懂的知识很多Q要想的事很多。说Ҏ也容易,其实只要诚意正心Q心无旁骛,真心为客户好、ؓ员工好、ؓ公司好,用心工作内容做好就好?span lang="EN-US"> —————————————————————————————————————– 很多同学格物致知CP6?span lang="EN-US">P7后就会犹豫自己是该l走Pq是改走MQ也有的同学转了M后,也还U结Q要么感觉没变化Q要么感觉不?span lang="EN-US">P的事Q心里没底?span lang="EN-US"> …… 只要C会在发展、公司在发展Q楼L需要越高的Q而h才L来稀~的。所以我们每个h除了要有自己的目标自q梦想外,也都得接受现实的不完。h生短暂,让我们一起n受在实现目标和梦惌E中的种U挑战吧Q一起ؓ高楼的徏设而努力吧Q?span lang="EN-US"> 本文与在试行业道\上孜孜不倦追求卓的同行们共勉?span lang="EN-US">
试是什么?它如同医学、教学一h个独立的、专业的行业。测试h员之于Y件系l犹如医生之于患者,教师之于学生。医生的职责是治病救人,教师的职责是教书育h?span lang="EN-US">
现在a归正传,一个测试h员之路是什么?前面说了Q测试是一个行业,所谓行行出状元Q测试行业的状元是什么样的呢Ql细分,如同ȝ行业有内U、外U、脑U、心血科{等各种专业领域Q测试行业本w也有各U专业领域:功能、性能、安全、可用性等{。每个专业领域的状元一定是在这个专业领域上有精湛造诣的h?span lang="EN-US">
到这里,大家一定会有疑问,做到什么样才叫有精湛造诣呢?现在讲个大家耳熟能详的故?span lang="EN-US">: 文王问名医扁鹊_“你们家兄弟三人,都精于医术,到底哪一位最好呢Q?#8221; 扁鹊{说Q?#8220;长兄最好,中兄ơ之Q我最差?#8221; 文王再问Q?#8220;那么Z么你最出名呢? 扁鹊{说Q?#8220;我长兄治病,是治病于病情发作之前。由于一般h不知道他事先能铲除病因,所以他的名气无法传出去Q只有我们家的h才知道。我中兄ȝQ是ȝ于病情初起之时。一般h以ؓ他只能治d的小病,所以他的名气只及于本乡里。而我扁鹊ȝQ是ȝ于病情严重之时。一般h都看到我在经脉上IK来放血、在皮肤上敷药等大手术,所以以为我的医术高明,名气因此响遍全国?#8221;
首先Q若x为某个测试领域的专家Q个为应具备如扁鹊之力,除了要精通于自n领域内的知识Q对pȝ也了如指掌,快速看到问题现象,同时也能够快速通过现象扑ֈ问题本质Q最后用最单最有效的解x案来Ҏ问题。比如在l脉上针灸、在皮肤上敷药。如果要大动q戈、开肠破肚解决问题,那是普通水q뀂如果是头痛d脚痛医脚Q那是庸医;呵呵?span lang="EN-US">
其次Q小隐隐于野。若x为某个测试领域的大师的话Q则需具备扁鹊二哥的能力,当系l还在设计的时候,p够找到致病因素,用简单高效的手段铲除病因。也是要具备系l分析师的能力,对设计的功能、性能、易用性、可靠性、可l护性、可UL性、安全性、可性等各方面能够v到指g用。知易行难,要做到如此很考验人的毅力?span lang="EN-US">
最后:大隐隐于市。若x为测试领域的隐士的话Q则需具备扁鹊大哥的能力,能够在Y件系l创造前期,将问题防范于未然。要做到q样Q除了需要有_湛的技术外Q还需具备的是对这个行业的热爱Q具备帮助他人成功的心态。ƈ且要有甘于寂寞、E泊名利的心境Q因为几乎没有h知道你的存在Q更h懂你?span lang="EN-US">
接下来我们再讲讲TLQ?span lang="EN-US">TechleadQ,
—————————————————————————————————————–
以下是对M路线的阐?span lang="EN-US">
先阐释下Q如何来理解它是个效率部门。这里做一个简单的模型Q模型的前提是:1、先把需求设计阶D|开Q单从开发和试来说Q?span lang="EN-US">2、量和质量是相当的。假设一个场景:如果1个h?span lang="EN-US">1个品需?span lang="EN-US">15天, 2个h做的话,p原先串行的工作变成q行Q这栯够羃短系l上U工期。变化如下图1所C?span lang="EN-US">
一?span lang="EN-US"> M得具备如上面模型中谈到的试体系及研发体pd讄能力。要有系分或者架构师的视角来优化试体系和研发体pR?span lang="EN-US">
二?span lang="EN-US"> M得有Loadbalance的功能。测试部门作为研发部门中的公p源部门,需要v到削峰填L作用Q合理得分配和调度测试资源是M的基本职责?span lang="EN-US">
三?span lang="EN-US"> M得是个优U?span lang="EN-US">HR。招聘策略、培训体pR员工关怀、员工成长体pM至离职管理都得搞定。这也是基本职责?span lang="EN-US">
四?span lang="EN-US"> M得是个指挥家。需要指挥协调团队中各种专家为同一首交响曲而合作共同演奏?span lang="EN-US">
五?span lang="EN-US"> M得是个司令官。战略可大可,时刻得记得给团队一个方向和目标?span lang="EN-US">
六?span lang="EN-US"> M得是个队ѝ战术的落地Q跟t执行、W?span lang="EN-US">review{。就公司来说Q这对保证公怸l完成是非常重要的内?span lang="EN-US">
七?span lang="EN-US"> M得是个外交官。要获得客户、员工、老板、同事等的支持和合作Q没点外交能力还真搞不定?span lang="EN-US">
八?span lang="EN-US"> M得是个销售员。要自q产品、思想销售给有需要的人,甚至那些q未意识到自己有需要的人。必要时q得盗梦I间下?span lang="EN-US">
另外Q?span lang="EN-US">Mq得懂点心理学、经学、社会学、哲学等{,M各种学科都略懂肯定没错啦?span lang="EN-US">
以下内容献给?span lang="EN-US">P?span lang="EN-US">M中纠l徘徊的同学?span lang="EN-US">
q里我将我的理解分nl大Ӟ仅供参考。我认ؓ打造一个团队如同打造一座房子,P是房子的梁柱,?span lang="EN-US">M是房子的横梁。如下图所C,图中?span lang="EN-US">P?span lang="EN-US">M的数字只是ؓ了D例方便,千万不要生搬套?span lang="EN-US">
……
……
……
……
?span lang="EN-US">4
?span lang="EN-US">4中可以看出,如果要更上一层楼Q就要有更高?span lang="EN-US">P和更高的M。那么做为已有的P?span lang="EN-US">M应该怎么到更高的数字呢?以图4中的数字ZQ?span lang="EN-US">P6若要晋升?span lang="EN-US">P7Q那么做的事一定是能够让团队的技术能力或工作产出上一个台阶的。你可以选择做其?span lang="EN-US">P7正在做的事,但实际上因ؓ每个人的工作Z和成长\UK不尽相同Q所以很隑֎模仿他hQ因此更多的时候还是要触类旁通,自己创新?span lang="EN-US">P8?span lang="EN-US">P9{等以此cL?span lang="EN-US">
同理Q?span lang="EN-US">M要从M2晋升?span lang="EN-US">M3Q则是要让团队在更高的一层楼上高效得q作。每层楼的h数ƈ不是晋升的关键,但是?span lang="EN-US">2D作还是在3D作则是关键?span lang="EN-US">
看到q里Q大家肯定有疑问了,说的单啊Q可真实情况咋那么纠l呢。这个说Q?#8220;我是PQ可是做了一?span lang="EN-US">M的事?#8221;另外一个又_“我是MQ可也做了一?span lang="EN-US">P的事?#8221;到底怎么回事呢?其实q就对了Q纠l说明你又上q又有责L。ؓ什么这么说呢?所谓世上不如意事十有八九。现实中很难?span lang="EN-US">M?span lang="EN-US">P都匹配得非常完美的情c仍旧用?span lang="EN-US">4举例Q如果你?span lang="EN-US">P7Q可是团队中又没?span lang="EN-US">M3Q你又希望团队进步,希望其他成员用你的思想、方法、理论在3D作,怎么办?要招聘,更要承担M3的很多责仅R同P如果你是M2Q你非常希望你的团队能够更上一层楼Q但是又没有P7Q怎么办?在招聘未果的情况下,你就不得不承担很?span lang="EN-US">P7应该做的事了。以此类推?span lang="EN-US">
]]>
在中国这样一个现?大部分的试工程师基本上很难涉及C?但有很多公司都要求你试工程师不但能够找到Y件的~陷,而且能够扑ֈ~陷产生的原?如果在Y件公司带q测试项目的?你可能就会知道找到缺陷生的原因是一个什么样的分量的工作.可能开发h员经q了几天几夜的眉思苦想都不知道Y仉块出问题?一般情况下,开发h员解决不了的问题,首先问项目经?如果目l理解决不了,问题只能搁置.而作Z个不怎么了解代码的测试h?能够很快的找到Y件中的缺?q相当于什么呢?相当于你是解决了开发h员未解决的问?你是开发h员的指导?呵呵,q个时?估计月薪1万也不是梦了!!
试人员能够扑ֈ问题产生的原?我能惛_的一般是下面两种情况:
1.以前作过开?而且很牛.q且_N测?
2.对Y件的业务程非常熟悉而且了解开发的实现机制,q且_N测?
作ؓ前?我们没个几年的开发经验基本上不可能作刎ͼ都是开发和试里面的大?Ҏ们现在来说有点不W合实际Q而后者应该是我们努力的方?l过1-2q的试基本上就能够非常熟悉公司的Y件?在我们实际的试q程?不要满与只是Y件表面的业务程,而且要多和开发h员交?多多了解软g的实现机?
软g的实现机?无非是通过各个开发技术来实现?所以当我们学到相应开发的时?重点x的应该开发语a实现某一功能的实现机?比如说你学到了XML,你要x的不是简单的几十行代?你要从整个XML的实现机制上来了解XML?br />
在说q个图之前你需要知道XML中主要包括1QXML文档声明Q.关于文档的类型定义.Q即验证自定义标{、元素之间关pȝ合法性)Q.用XML标签创徏的数据内容.Q这个就是下面我们所说的数据Q?/font>
在IE中用XMLQ有一个好处就是实现数据和昄分离QXML中存储数据,而HTML利用DOM对象调用XML中的数据来显C.q样实现个过E是q样的:XML中存储数据,而CSS呢是对XML中的数据q行格式排版昄Q通过JavaScript对XML数据元素的操作不能够直接q行Q他要用到系l提供很多编E接口,也就是DOM模型QDOM模型实现XML数据和Javascript之间交流的^収ͼ最l在IE中显C的是HTML调用XML中的数据和JavascriptҎ据操作后的结果.
理解了XML整个实现的机制后Q如果程序不能实现把King Leer变成U色Q你说这个缺h哪个模块产生的?q个肯定是Javascript的问题.
呵呵Q这是了解了开发技术实现机制的一个最大的好处Q公司的软g的实现机Ӟ是现有的各U开发技术实现机制的一个合体Q各U开发技术我们肯定不能都_N,但如果我们知道它们的实现机制Q这个时候对于找到缺陷生的原因是莫大的好处Q?/font>
从一月䆾到现在,面试了二十个左右的研I生Q满意的很少Q我开始去思考,到底是自q要求q高Q还是自q面试Ҏ有问题,抑或真的是现在的研究生的素质来低了?
我理想的人选,首先Q我希望他对试感兴,有测试的感觉Q测试ƈ不是一件很有创造性的工作Q但其中的乐,是很?/span>coding高手所无法体会的,但需要发现其乐趣Q必要喜欢上测试,才会更有效地发现软g存在的隐藏问题。其ơ,我希望他有一定的技术基Q对于在校的研究生的技术水qI我的要求不高Q只需要掌握最基本?/span>SQL语句Q会单得Linux命oQ懂得用Java?/span>C写一个简单的E序Q这些知识,是需要在目中用到的技术,同时也是学校的基评上的东西。最后,是他的态度和性格Q我希望他是一个责d很强、具有良好沟通能力和团队_的hQ测试根软g开发最大的不同是,开发工E师可以只关心自己所负责的模块或功能Q而测试则要把握全局Q需要跟不同的hL通,发现问题需要协助不同的人去定位和解冻I试是一个团队的工作Q我希望招聘q来的hQ能够很快地融进我们的团队中Q谦虚地学习Q踏实地工作?/span>
我的q三个要求,g真的很高Q因为当我以q三个标准去衡量我的candidate的时候,我L满怀希望地开始跟他们交谈Q而又失望C他们告别。首先是W试的题目,臛_有一半hQ最基本?/span>SQL?/span>Linux命o都是没有把握地写q卷子的?#8220;q䆾题目你觉得怎样啊?”我笑着问他们?#8220;都是在学校学q的Q不q忘CQ只要给我时_我很快就会学会的?#8221;果然都是名牌大学的研I生Q那L自信?#8220;我们的工作要求有一定的JAVA/Oracle/Linux技术基Q如果给你时_你要多长旉可以掌握呢?”“一两周可以了?#8221;“我们的招聘要求里面有些清楚这些要求吗Q?#8221;“有?#8221;“你从发简历到面试Q大U多长时间了呢?”“两周左右?#8221;“那你Z么不利用q两周把招聘要求中的技术都好好温习一下呢Q?#8221;我仍然笑着问,只是接下来大多都是沉默。我发觉q个问题Q真的能问倒所有h。其实,我不是想为难他们Q只是,他们都是名牌大学研一或研二的学生啊,q些基础我当q大学三q已l可以灵z运用了Q这些命令我也经怼忘记Q但是,每次自己去面试之前,都会׃旉认真地复习一下招聘要求中的技术,有备而战。其实,我想看的是这个来面试的hQ是否在来之前有认真地准备,我只是想看他对这个机会的态度。插一条记录到数据库中Q居然有人用addQ真叫我心疼Q同事批评我_别L态度来作要求Q只要你l他培训两个月,什么技术不会??/span>addq是?/span>insert into有什么关p?只要他够聪明就可以了。态度真的不重要吗Q我真的不需要他们有技术基吗?他们真的可以没有M基础p来,q些技术,我两周的培训可以让他们掌握Q只是,他们的态度Q我没信心让他们在两周之内扭转。当他们可以很高效地q活的时候,恐怕他们又要马上回学校M。如果我培训的成本,已经q远高于我自己做的成本,那么Q我宁愿自己辛苦一些。不要怪我以态度作ؓ评判的准则?/span>
历,是用人单位初步刷选的一份资料,有些历看上去像一份草E,或者是所展示的资料ƈ不符合我们的要求Q通常我们都会攑ּq一步去了解。有些h的简历做得很漂亮Q好像什么都会,而且q有很多的项目经验,看上M乎很有吸引力Q但历给人的印象未必是真实的。每个公叔R希望招聘q来的h可以有一定的目l验Q因意味着他们一q来可以给公司q活了,可以节省很多的培训成本。我也喜Ƣ有目l验的hQ我q很喜欢跟他们聊他们曑ցq的一两个目Q因为在在这个互动的q程中,你可以看Z的思维、表辑֒技术。简历中的项目经验可以是假的Q但在面试的时候就不能假了Q在面试q程中的交流以让我们判断出q个人的技术水q_思维能力。很多hQ在历中写着正在做的目或一两个月之前做的项目,当我们问他有关系l的框架或某个功能的程Ӟ表达h却是不够清晰Q再深入一些去q问Q回{就差强人意了。我在想Q是因ؓ他们不善于表达,q是他们本n没有深入理解q自己所做的目Q甚x自己Ҏ上就没有q些目l验Q企业或者也应该思考一下,是否应该l没有项目经验的Z些^{的ZQ以免他们投其所好,简历粉饰得很漂亮,但事实上又没有那L真实。我可以理解他们Q因为简历写上如果连目l验都没有,可能他们p面试的机会也没有了,只是Q有了面试机会,但如果没有把握这个机会的实力或者没有做好把握机会的准备Q有了也是白有?/span>
我最看重的,是这个h是否h试的感觉以及兴,我希望他对自q发展和选择是清晰的Q我希望他能清楚自己Z么来应聘Q如果他来只是纯_的找一个工作机会,或是冲着公司的名气而来Q而对于测试是什么,自己所选择的这个测试机会是否有利于自己的长q发展都不清楚,只是Z工作而工作,是否能够他的潜力挖掘出来呢Q我没把握。而这LcandidateQ偏偏又不少?/span>
生软g的最l目的是Z满客户需求,我们以客户需求作判Y件质量的标准Q认Y件缺P Software Bug Q的具体含义包括下面几个因素Q?SPAN lang=EN-US>
?SPAN lang=EN-US> 软g未达到客户需求的功能和性能Q?SPAN lang=EN-US>
?SPAN lang=EN-US> 软g出客户需求的范围Q?SPAN lang=EN-US>
?SPAN lang=EN-US> 软g出现客户需求不能容忍的错误Q?SPAN lang=EN-US>
?SPAN lang=EN-US> 软g的用未能符合客L习惯和工作环境?SPAN lang=EN-US>
考虑到设计等斚w的因素,我们q可以认Y件缺陯可以包括软g设计不符合规范,未能在特定的条gQ资金、范围等Q达到最佳等。可惜的是,我们中的很多人更們于把软g~陷看成q行时出现问题上来,认ؓ软g试仅限于程序提交之后?SPAN lang=EN-US>
在目前的国内环境下,我们几乎看不到完整准的客户需求说明书Q加以客L需求时时在变,q求完美的测试变得不太可能。因此作Z个优异的试人员Q追求Y件质量的完美固然是我们的宗旨Q但是明Y件测试现实与理想的差距,在Y件测试中学会取舍和让步,对Y件测试是有百益而无一弊的?SPAN lang=EN-US>
下面是一些Y件测试的常识Q对q些常识的理解和q用有助于我们在进行Y件测试时能够更好的把握Y件测试的度?SPAN lang=EN-US>
?SPAN lang=EN-US> 试是不完全的(试不完全)
很显Ӟ׃软g需求的不完整性、Y仉辑路径的组合性、输入数据的大量性及l果多样性等因素Q哪怕是一个极其简单的E序Q要想穷所有逻辑路径Q所有输入数据和验证所有结果是非常困难的一件事情。我们D一个简单的例子Q比如说求两个整数的最大公U数。其输入信息Z个正整数。但是如果我们将整个正整数域的数字进行一番测试的话,从其数目的无限性我们便可证明是q样的测试在实际生活中是行不通的Q即便某一天我们能够穷该E序Q只怕我们乃x们的子孙都早已作古了。ؓ此作Y件测试,我们一般采用等L和边界值分析等措施来进行实际的软g试Q寻找最用例集合成为我们精试复杂性的一条必l之道?SPAN lang=EN-US>
?SPAN lang=EN-US> 试h免疫性(软g~陷免疫性)
软g~陷与病毒一样具有可怕的 ?SPAN lang=EN-US> 免疫?SPAN lang=EN-US> ?SPAN lang=EN-US> Q测试h员对光用的试多Q其免疫能力p强,L更多软g~陷更加困难。由数学上的概率论我们可以推一l论。假设一?SPAN lang=EN-US> 50000 行的E序中有 500 个Y件缺陷ƈ且这些Y仉误分布时均匀的,则每 100 行可以找C个Y件缺陗我们假设测试h员用某种Ҏ花在查找软g~陷的精力ؓ X 时 /100 行。照此推,软g存在 500 个缺hQ我们查找一个Y件缺陷需?SPAN lang=EN-US> X 时Q当软g只存?SPAN lang=EN-US> 5 个错误时Q我们每查找一个Y件缺陷需?SPAN lang=EN-US> 100X 时。实践证明,实际的测试过E比上面的假设更刻,为此我们必须更换不同的测试方式和试数据。该例子q说明了在Y件测试中采用单一的方法不能高效和完全的针Ҏ有Y件缺P因此软g试应该可能的多采用多U途径q行试?SPAN lang=EN-US>
?SPAN lang=EN-US> 试?SPAN lang=EN-US> ?SPAN lang=EN-US> 泛型概念 ?SPAN lang=EN-US> Q全E测试)
我一直反对Y件测试仅存在于程序完成之后。如果单U的只将E序设计阶段后的阶段UCY件测试的话,需求阶D和设计阶段的缺陷生的攑֤效应会加大。这非常不利于保证Y件质量。需求缺陗设计缺陷也是Y件缺PC ?SPAN lang=EN-US> 软g~陷h生育能力 ?SPAN lang=EN-US> 。Y件测试应该跨整个Y件开发流E。需求验证(自检Q和设计验证Q自Q也可以作软g试Q徏议称为:需求测试和设计试Q的一U。Y件测试应该是一个泛型概念,늛整个软g生命周期Q这h能确保周期的每个阶段得赯验。同时测试本w也需要有W三者进行评伎ͼ信息pȝ审计和Y件工E监理)Q即试本n也应当被试Q从而确保测试自w的可靠性和高效性。否则自w不正,难以服h?SPAN lang=EN-US>
另外q需指出的是软g试是提高Y件品质量的必要条g而非充分条gQY件测试是提高产品质量最直接、最快捷的手D,但决不是一个根本手Dc?SPAN lang=EN-US>
?SPAN lang=EN-US> 80-20 原则
80% 的Y件缺陷常常生存在软g 20% 的空间里。这个原则告诉我们,如果你想使Y件测试有效地话,C常常光光危多?SPAN lang=EN-US> ?SPAN lang=EN-US> 地段 ?SPAN lang=EN-US> 。在那里发现软g~陷的可能性会大的多。这一原则对于软g试人员提高试效率及缺陷发现率有着重大的意义。聪明的试人员会根据这个原则很快找多的~陷而愚蠢的试人员却仍在O无目的地到处搜寻?SPAN lang=EN-US>
80-20 原则的另外一U情冉|Q我们在pȝ分析、系l设计、系l实现阶D늚复审Q测试工作中能够发现和避?SPAN lang=EN-US> 80% 的Y件缺P此后的系l测试能够帮助我们找出剩余缺陷中?SPAN lang=EN-US> 80% Q最后的 5% 的Y件缺陷可能只有在pȝ交付使用后用Lq大范围、长旉使用后才会曝露出来。因Y件测试只能够保证可能多地发现Y件缺P却无法保证能够发现所有的软g~陷?SPAN lang=EN-US>
80-20 原则q能反映到Y件测试的自动化方面上来,实践证明 80% 的Y件缺陷可以借助人工试而发玎ͼ 20% 的Y件缺陷可以借助自动化测试能够得以发现。由于这二者间h交叉的部分,因此有 5% 左右的Y件缺陷需要通过其他方式q行发现和修正?SPAN lang=EN-US>
?SPAN lang=EN-US> 为效益而测?SPAN lang=EN-US>
Z么我们要实施软g试Q是Z提高目的质量效益最l以提高目的M效益。ؓ此我们不隑־出我们在实施软g试应该掌握的度。Y件测试应该在软g试成本和Y件质量效益两者间扑ֈ一个^衡点。这个^衡点是我们在实施Y件测试时应该遵守的度。单斚w的追求都必然损害软g试存在的h值和意义。一般说来,在Y件测试中我们应该量C持Y件测试简单性,切勿Y件测试过度复杂化Q拿物理学家爱因斯坦的话说就是: Keep it simple but not too simple ?SPAN lang=EN-US>
?SPAN lang=EN-US> ~陷的必然?SPAN lang=EN-US>
软g试中,׃错误的关联性,q不是所有的软g~陷都能够得以修复。某些Y件缺陯然能够得以修复但在修复的q程中我们会隑օ引入新的软g~陷。很多Y件缺陷之间是怺矛盾的,一个矛盄消失必然会引发另外一个矛盄产生。比如我们在解决通用性的~陷后往往会带来执行效率上的缺陗更何况在缺L修复q程中,我们常常q会受时间、成本等斚w的限制因此无法有效、完整地修复所有的软g~陷。因此评估Y件缺L重要度、媄响范_选择一个折中的Ҏ或是从非软g的因素(比如提升g性能Q考虑软g~陷成ؓ我们在面对Y件缺h一个必ȝ面的事实?SPAN lang=EN-US>
?SPAN lang=EN-US> 软g试必须有预期结?SPAN lang=EN-US>
没有预期l果的测试是不可理喻的。Y件缺hl过Ҏ而得出来的。这正如没有标准无法q行度量一栗如果我们事先不知道或是无法肯定预期的结果,我们必然无法了解试正确性。这很容易然人感觉如盲h摸象一般,不少试人员常常凭借自w的感觉去评判Y件缺L发生Q其l果往往是把似是而非的东西作为正的l果来判断,因此常常出现误测的现象?SPAN lang=EN-US>
?SPAN lang=EN-US> 软g试的意?SPAN lang=EN-US> - 事后分析
软g试的目的单单是发现~陷q么单吗Q如果是 ?SPAN lang=EN-US> ?SPAN lang=EN-US> ?SPAN lang=EN-US> 的话Q我敢保证,cM的Y件缺陷在下一ơ新目的Y件测试中q会发生。古语说得好Q?SPAN lang=EN-US> ?SPAN lang=EN-US> 不知道历史的人必然会重蹈覆辙 ?SPAN lang=EN-US> 。没有对软g试l果q行认真的分析,我们无法了解缺陷发生的原因和应Ҏ施,l果是我们不得不耗费的大量的人力和物力来再次查找软g~陷。很可惜Q目前大多测试团队都没有意识到这一点,试报告中缺乏测试结果分析这一环节?SPAN lang=EN-US>
l论Q?SPAN lang=EN-US>
软g试是一个需?SPAN lang=EN-US> ?SPAN lang=EN-US> 自觉 ?SPAN lang=EN-US> 的过E,作ؓ一个测试h员,遇事沉着Q把持尺度,从根本上应对软g试有着正确的认识,希望本文对读者对软g试的认识有所帮助?SPAN lang=EN-US>