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