典型测试错误英中文对照

第第页典型测试错误(英中文对照）典型测试错误(英中文对照）

发表于：2023-06-02来源：：点击数：标签：典型中文

It'seasytomakemistakeswhentestingsoftwareorplanningatestingeffort.Somemistakesaremadesooften,sorepeatedly,bysomanydifferentpeople,thattheydeservethelabelClassicMistake.在测试软件或制订测试工作计划时很容易犯一

It'seasytomakemistakeswhentestingsoftwareorplanningatestingeffort.Somemistakesaremadesooften,sorepeatedly,bysomanydifferentpeople,thattheydeservethelabelClassicMistake.

在测试软件或制订测试工作计划时很容易犯一些错误。有些错误经常被许多不同的人一而再、再而三地犯，应该被列为典型错误。

Classicmistakesclusterusefullyintofivegroups,whichI'vecalled"themes":

典型错误可以有效地分为五组，我把这些组称为“主题”。

·TheRoleofTesting:whodoesthetestingteamserve,andhowdoesitdothat?

·测试的作用：谁承担测试小组的责任，如何做？

·PlanningtheTestingEffort:howshouldthewholeteam'sworkbeorganized?

·制订测试工作计划：应该如何组织整个小组的工作？

·PersonnelIssues:whoshouldtest?

·人员问题：谁应该做测试？

·TheTesteratWork:designing,writing,andmaintainingindividualtests.

·工作中的测试员：设计、编写和维护各测试。

·TechnologyRampant:quicktechnologicalfixesforhardproblems.

·过度使用技术：艰难问题的快速技术修复

Ihavetwogoalsforthispaper.First,itshouldidentifythemistakes,putthemincontext,describewhythey'remistakes,andsuggestalternatives.Becausethecontextofonemistakeisusuallypriormistakes,thepaperiswritteninanarrativestyleratherthanasalistthatcanbereadinanyorder.Second,thepapershouldbeahandychecklistofmistakes.Forthatreason,theclassicmistakesareprintedinalargerboldfontwhentheyappearinthetext,andthey'realsosummarizedattheend.

本文有两个目标。第一，应当识别错误，将它们放到具体环境中，描述它们为什么是错误，并给出替代方法的建议。因为一个错误的具体环境通常是先决错误，所以本文将以叙事的方式而不是以可以按任意顺序阅读的列表方式来描述。第二，本文应该是一个便于查看的错误列表。因为这个原因，文章中出现的典型错误都以大号粗体字印刷，并在文章的结尾处汇总。

Althoughmanyofthesemistakesapplytoalltypesofsoftwareprojects,myspecificfocusisthetestingofcommercialsoftwareproducts,notcustomsoftwareorsoftwarethatissafetycriticalormissioncritical.

虽然这些错误很多都适用于所有类型的软件项目，但我的重点将放在商用软件产品的测试上，而不是定制软件或者是高度安全或关键任务的软件测试上。

Thispaperisessentiallyaseriesofbugreportsforthetestingprocess.Youmaythinksomeofthemarefeatures,notbugs.YoumaydisagreewiththeseveritiesIassign.Youmaywantmoreinformationtohelpindebugging,orwanttovolunteerinformationofyourown.Anydecentbugreportingsystemwilltreattheoriginalbugreportasthefirstpartofaconversation.Soshoulditbewiththispaper.Therefore,followthislinkforanongoingdiscussionofthistopic.

本文主要是测试过程的一系列错误报告。你可能认为它们中的部分属于特性问题而不是bug。你可能不赞成我设定的严重性级别。你可能需要更多的信息以用于帮助排除错误，或者希望提供你自己的信息。任何设计良好的错误报告系统都将原始的错误报告当作是对话的起始部分。本文也是这样，所以，可以按照链接参加这个主题的讨论。

ThemeOne:TheRoleofTesting

主题一：测试的作用

Afirstmajormistakepeoplemakeisthinkingthatthetestingteamisresponsibleforassuringquality.Thisrole,oftenassignedtothefirsttestingteaminanorganization,makesitthelastdefense,thebarrierbetweenthedevelopmentteam(accusedofproducingbadquality)andthecustomer(whomustbeprotectedfromthem).It'scharacterizedbyatestingteam(oftencalledthe"QualityAssuranceGroup")thathasformalauthoritytopreventshipmentoftheproduct.Thatinitselfisadishearteningtask:thetestingteamcan'timprovequality,onlyenforceaminimallevel.Worse,thatauthorityisusuallymoreapparentthanreal.Discoveringthat,togetherwiththeperverseincentivesoftellingdevelopersthatqualityissomeoneelse'sjob,leadstotestingteamsandtesterswhoaredisillusioned,cynical,andviewthemselvesasvictims.We'velearnedfromDemingandothersthatproductsarebetterandcheapertoproducewheneveryone,ateverystageindevelopment,isresponsibleforthequalityoftheirwork([Deming86],[Ishikawa85]).

人们犯的第一个主要错误是认为测试小组应当负责质量保证。这个角色常常分配给组织中的第一测试小组，将它作为最后的防御，成为开发小组（被指责为产生低劣质量）和客户（必须受到保护以远离低劣质量）的一个屏障。它的特征是测试小组（常称为“质量保证组”）表面上具有阻止产品发货的权力。这本身是一个令人沮丧的任务：测试小组不能提高质量，只能强制一个最低水平。更糟糕的是，这种权力常常是看上去比实际的重要。如果发现这一点，再加上有违常理地暗示开发人员质量是别人的事情，导致测试小组和测试员感到失望、愤事嫉俗、感觉自己是受害者。我们从Deming和其他人的工作可以得知：如果每个人都在开发的各个阶段对他们的工作质量负责，则产品会又好又便宜（[Deming86]，[Ishikawa85]）。

Inpractice,whatevertheformalrole,mostorganizationsbelievethatthepurposeoftestingistofindbugs.Thisisalessperniciousdefinitionthanthepreviousone,butit'smissingakeyword.WhenItalktoprogrammersanddevelopmentmanagersabouttesters,onekeysentencekeepscomingup:"Testersaren'tfindingtheimportantbugs."Sometimesthat'sjustgriping,sometimesit'sbecausetheprogrammershaveaskewedsenseofwhat'simportant,butIregrettosaythatalltoooftenit'svalidcriticism.Toomanybugreportsfromtestersareminororirrelevant,andtoomanyimportantbugsaremissed.

实际上，不管表面上的作用是什么，大多数组织都相信测试的目的是发现bug。这个定义的危害比前一个定义的危害要小，但是忽略了一个关键词。当我同程序员和开发经理谈到测试员的时候，不时听到一个关键的句子：测试员找不到重要的bug。有时候这种说法只是一种抱怨，有时候是因为程序员对于什么是正确的感觉不对，但我很遗憾地说，它们经常是有效的批评。测试员的太多的bug报告是微小的、不相关的，而有太多重要的错误都被遗漏了。

What'sanimportantbug?Importanttowhom?Toafirstapproximation,theanswermustbe"tocustomers".Almosteveryonewillnodtheirheaduponhearingthisdefinition,butdotheymeanit?Here'satestofyourorganization'smaturity.Supposeyourproductisasystemthatacceptsemailrequestsforservice.Assoonasarequestisreceived,itsendsareplythatsays"yourrequestof5/12/97wasacceptedanditsreferenceIDisNIC-051297-3".AtesterwhosendsinmanyrequestsperdayfindsshehasdifficultykeepingtrackofwhichrequestgoeswithwhichID.Shewishesthattheoriginalrequestwereappendedtotheacknowledgement.Furthermore,sherealizesthatsomecustomerswillalsogeneratemanyrequestsperday,sowouldalsoappreciatethisfeature.Wouldshe:

什么是重要的bug？对谁而言是重要的？直观的估计，答案肯定是“对于客户”。听到这个定义，几乎每个人都会点头称是，但他们确实这样认为吗？这里要测试一下你们组织的成熟度。假设你们的产品是一个接受电子邮件请求服务的系统。当收到请求时，它马上发送一个“您在97年5月12日发送的请求已经受理，参考ID是NIC-051297-3”的答复。一个每天发送很多请求的测试员发现要分清楚哪个请求与哪个ID对应是非常困难的。她希望最初的请求能够附加在确认邮件的后面。并且，她意识到某些可户可能每天也会产生很多请求，所以会高度评价这个功能的。那么她将：

1.fileabugreportdocumentingausabilityproblem,withtheexpectationthatitwillbeassignedareasonablyhighpriority(becausethefixisclearlyusefultoeveryone,importanttosomeusers,andeasytodo)?

写一个bug报告，记录一个可用性问题，希望能够分配一个合理的高优先级（因为这个修复很明显对每个人都很用，对有部分用户来说还非常重要，并且也容易修改）？

2.fileabugreportwiththeexpectationthatitwillbeassigned"enhancementrequest"priorityanddisappearforeverintothebugdatabase?

写一个bug报告，希望它被分配为“功能提升请求”优先级并永远从bug数据库中消失？

3.fileabugreportthatyieldsa"worksasdesigned"resolutioncode,perhapswithanemail"nastygram"fromaprogrammerorthedevelopmentmanager?

写一个bug报告，产生一个“按设计工作”解决码，可能还加上一个来自程序员或开发经理的“不同意”电子邮件?

4.notbotherwithabugreportbecauseitwouldendupincases(2)or(3)?

不打算费事去写bug报告，因为它将以情况(2)或(3)结束？

Ifusabilityproblemsarenotconsideredvalidbugs,yourprojectdefinesthetestingtasktoonarrowly.Testersarerestrictedtocheckingwhethertheproductdoeswhatwasintended,notwhetherwhatwasintendedisuseful.Customersdonotcareaboutthedistinction,andtestersshouldn'teither.

如果可用性问题不认为是有效的bug，那么你们的项目将测试任务定义得太狭窄了。测试员严格限制为检查产品是否按预期工作，而不管这种预期是否有效。客户不关心这个区别，测试员也不应该关心。

Testersareoftentheonlypeopleintheorganizationwhousethesystemasheavilyasanexpert.Theynoticeusabilityproblemsthatexpertswillsee.(Formalusabilitytestingalmostinvariablyconcentratesonnoviceusers.)Expertcustomersoftendon'treportusabilityproblems,becausethey'vebeentrainedtoknowit'snotworththeirtime.Instead,theywait(invain,perhaps)foramoreusableproductandswitchtoit.Testerscanpreventthatlostrevenue.

测试员经常是组织中唯一像专家一样大量使用系统的人。他们会注意到专家会看到的可用性问题。（形式上的可用性测试几乎不可避免地集中于没有经验的用户。）专家客户常常不会报告可用性问题，因为他们已经被训练的知道不值得花时间去这样做。相反，他们（也许是徒劳地）等待下一个可用的产品然后切换过去。测试员可以避免这个损失。

Whiledefiningthepurposeoftestingas"findingbugsimportanttocustomers"isastepforward,it'smorerestrictivethanIlike.Itmeansthatthereisnofocusonanestimateofquality(andonthequalityofthatestimate).Considerthesetwosituationsforaproductwithfivesubsystems.

将测试的目的定义为“找到对用户重要的bug”是向前进了一步，但与我所喜欢定义相比仍有限制。这意味着没有集中于质量评估（以及这种评估的质量）。考虑一下测试含有五个子系统的产品的两种情况。

1.100bugsarefoundinsubsystem1beforerelease.(Forsimplicity,assumethatallbugsareofthehighestpriority.)Nobugsarefoundintheothersubsystems.Afterrelease,nobugsarereportedinsubsystem1,but12bugsarefoundineachoftheothersubsystems.

在发布前，在子系统1中找到了100个bug。（为了简单起见，假设所有的bug都是最高级别的。）在其他子系统中没有发现bug。在发布后，在子系统1中没有报告bug，但在其他每个子系统中都报告了12个bug。

2.Beforerelease,50bugsarefoundinsubsystem1.6bugsarefoundineachoftheothersubsystems.Afterrelease,50bugsarefoundinsubsystem1and6bugsineachoftheothersubsystems.

在发布前，在子系统1中找到了50个bug。在其他每个子系统中都找到了6个bug。在发布后，在子系统1中报告了50个bug，在其他每个子系统中都报告了6个bug。

Fromthe"findimportantbugs"standpoint,thefirsttestingeffortwassuperior.Itfound100bugsbeforerelease,whereasthesecondfoundonly74.ButIthinkyoucanmakeastrongcasethatthesecondeffortismoreusefulinpracticalterms.Letmerestatethetwosituationsintermsofwhatatestmanagermightsaybeforerelease:

从“找到重要bug”的观点看，第1种测试情况较为理想。在发布前找到了100个bug，但是第2种情况中只找到74个。但我想你们可能会提出一个有力的理由认为第2中测试在实际中更有用。让我以产品发版前测试经理可能说些什么来重新描述一下两种测试情况：

1."Wehavetestedsubsystem1verythoroughly,andwebelievewe'vefoundalmostallofthepriority1bugs.Unfortunately,wedon'tknowanythingaboutthebugginessoftheremainingfivesubsystems."

“我们全面测试了子系统1，我们相信已经找出了几乎所有优先级为1的bug。不幸的是，我们对其他五个子系统的的bug一无所知。”

2."We'vetestedallsubsystemsmoderatelythoroughly.Subsystem1isstillverybuggy.Theothersubsystemsareabout1/10thasbuggy,thoughwe'resurebugsremain."

“我们比较全面地测试了所有的子系统。子系统1仍旧有不少bug。其他子系统虽然还有bug，但只有子系统1的bug的十分之一。”

Thisis,admittedly,anextremeexample,butitdemonstratesanimportantpoint.Theprojectmanagerhasatoughdecision:woulditbebettertoholdontotheproductformorework,orshoulditbeshippednow?Manyfactors-allroughestimatesofpossiblefutures-havetobeweighed:Willacompetitorbeat