软件测试中的杀虫剂悖论

在软件测试中有一种称为杀虫剂悖论(pesticide paradox)的现象,即对软件进行越多的测试,那么该软件对软件测试人员的测试就越具有免疫力。

首先,我们先来看下什么是杀虫剂悖论,每年各种各样的害处袭击田野和农作物,农业专家们要找到正确的对抗方法,用改良的配方设计出杀虫剂。但是害虫适应了新的杀虫剂,产生了免疫力,使新杀虫剂失效。随后的几年里,老的杀虫剂只能用来杀死没有免疫力的害虫,同时还必须引入一些新的改良配方,同更顽强的新编译害虫作斗争。新旧杀虫剂的结合有时阻碍了旧杀虫剂效能的发挥。随着时间的流逝,旧的杀虫剂变得毫无用处。于是,害虫和杀虫剂不停的战斗,看最终谁占上风。有时杀虫剂赢,但是,有时害虫又可以成功的战胜最新的杀虫剂。这场斗争的结果是大自然和杀虫剂的不断发展变化。

在软件测试中,为了克服“杀虫剂悖论”,测试用例需要经常的评审和修改,不断增加新的不同的测试用例来测试软件或系统的不同部分,保证测试用例永远是最新的,即包含着最后一次程序代码或说明文档的更新信息。这样软件中未被测试过的部分或者先前没有被使用过的输入组合就会重新执行,从而发现更多的缺陷。软件测试人员必须不断地编写新的不同的测试来检验程序的不同部分从而找出更多的bug。让其他的人来测试你的程序将有助于打破”杀虫剂悖论”。

软件测试中的杀虫剂悖论

时间: 2024-10-17 09:39:16

软件测试中的杀虫剂悖论的相关文章

论测试用例的有效更新及杀虫剂悖论

论测试用例的有效更新及杀虫剂悖论 在2014年,我们团队试图推动一件事情--把产品后端(客户.客服.生产制造等等)出现的问题,反向增补为测试用例,扩充到测试用例库中,避免后续重复的出现问题--早些年柳传志在创业类的节目问一个选手,作为老板,你每天第一件要处理什么事情.选手按照自己的优先级和重要性说了一堆.柳传志说:你应该优先处理反复出现的问题. 复盘论是联想的看家本领,这也仅借用一下这个意思. 尝试这么做了一段时间,把已经形成的反向增补测试用例,推广到相关测试用例库,然后在实际中执行和检查,一段

测试中的杀虫剂困境

第一次听到"杀虫剂困境"这个词来源于<微软的软件测试之道>中讲述的一个小故事.其中对于杀虫剂困境的原文表述是:"任何你用以防止或发现缺陷的方法都会留下一些残余的.更为微妙的缺陷,而对于这些缺陷而言,前面那些方法会统统失效."意思就是说,测试中单一的测试技术.手段.方法.策略往往是不足以全部覆盖潜在的缺陷范围的.因此,在测试过程中,包括测试策略的制定.测试案例设计.测试执行的方式和方法等,都要保持方法的多样性,尝试从更多的角度去审视和观察被测软件的行为表现

软件测试中的那些不可遗忘的基础知识

软件测试是一项批判性的工作,目的就是找出软件中的缺陷.这里暂时不去深究为什么要进行软件测试,以及软件测试带来的好处.只介绍软件测试中一些基本的测试方法.根据是否查看代码程序分为黑盒测试和白盒测试:根据是否运行软件又可分为静态测试和动态测试. 黑盒测试:又叫功能测试或行为测试,只需考虑各个功能,不需要考虑整个软件的内部结构及代码. 白盒测试:访问代码,通过检查代码的线索来协助测试. 静态测试:测试软件不运行的部分,只是检查和审核. 动态测试:使用和运行软件进行测试. 1.静态黑盒测试:检查产品说明

软件测试作业2 — 软件测试中的错误Failure, Error, Fault的区别

软件测试中的错误Failure, Error, Fault的区别: Failure: External, incorrect behavior with respect to the requirements or other description of the expected behavior(预期行为出错或与其他的外部行为描述不符).指软件在运行时出现的功能的丧失,类似于看病时病人发病的症状. Fault: A static defect in the software(软件中的静态缺陷

软件测试中常见测试流程

测试的流程: 需求阶段流程图: 单元/集成测试阶段流程图 系统测试阶段流程图 压力测试流程图 性能测试流程图 仅仅了解就够复杂的了,实际操作过程中的问题肯定更多.像压力测试.性能测试,一般的情况下我哪里用得上啊.虽然也知道些什么分布式应用.海量存储之类的,但是我连1T的数据都没见过.光说说那是是空话=.= 第二个问题:软件测试的常规方法. 软件测试中常见测试流程,布布扣,bubuko.com

软件测试中的八大浪费现象

在测试书籍中有一句这样的话:软件测试目的是用最少的人力.物力.财力发现最多的软件缺陷,提高软件的质量.为达到此目的,除想方设法提高测试的效率,同样对测试过程中出现的各种浪费现象的关注也是不可缺少的,在测试过程中最容易出现以下八大浪费现象. 1.过多的执行 我们都在担心测试不够全面,测试覆盖不全.因为我们知道过少的测试是犯罪,但同样过多的测试是浪费.设计测试用例本意是为了规避测试的随意性,让我们测试时既不多测也没有少测. 很多测试同行都提到在总结测试的时候认为在测试过程中有些功能可以不需要测试得那

软件测试中LoadRunner函数中的几个陷阱

软件测试 中 LoadRunner 函数中的几个陷阱 1.atof 在 loadrunner 中如果直接用 float f; f=atof("123.00"); lr _output_message("%f",f); 输出的结果会是1244128.00,根本不是我们想要的. 因为float,double型在不同的平台下长度不一样,所以在loadrunner 软件测试中LoadRunner函数中的几个陷阱 1.atof 在loadrunner中如果直接用 float

软件测试中遇到的常见问题及沟通方法

1.这个bug我这边重现不了 解决办法 Bug应该简明扼要,重点突出.如果描述存在歧义,一定要总结并尽快改进.有时会遇到概率性的bug,要告诉开发概率是多少,尽可能多的提供重现的条件. 在复现问题时,希望能大致判断几个问题点,然后和测试人员沟通下,需要如何捕获信息,捕获那类信息?是不是提供debug版本进行复现,或者根据预判的点增加打印信息版本进行复现? 2.这个不是代码问题,需求这么定义的 解决办法 需求也是人定的,如果觉得有异议,可以找需求人员询问清楚,为什么这样定义,把自己的想法告诉他们,

软件测试中排错的基本方法

软件测试中,排错(即调试)与成功的测试形影相随.测试成功的标志是发现了错误.根据错误迹象确定错误的原因和准确位置,并加以改正的主要依靠排错技术. 1.排错过程 如下图所示,排错过程开始于一个测试用例的执行,若测试结果与期望结果有出入,即出现了错误征兆,排错过程首先要找出错误原因,然后对错误进行修正.因此排错过程有两种可能,一是找到了错误原因并纠正了错误,另一种可能是错误原因不明,排错人员只得做某种推测,然后再设计测试用例证实这种推测,若一次推测失败,再做第二次推测,直到发现并纠正了错误. 排错是