这篇文章我主要想记录学习一下在软件测试行业中的一些常见理论效应以做基本了解。

一、杀虫剂效应

1、杀虫剂效应介绍

　　杀虫剂效应原本指农业中随着农药的普及使用，害虫对农药的抗药性就越来越强，农药就越来越难杀死害虫。在农场里为了对付破坏农作物的害虫，农业专家开发出了对应的杀虫剂，刚开始效果很好，但是随着时间的流逝，害虫适应了杀虫剂，产生了抗药性，这些原有的农药就越来越难杀死害虫，必须设计新型的杀虫剂来对付害虫。

　　在软件测试中这个理论是由《软件测试技术》一书的作者Boris Beizer在30年前提出的。在软件测试中杀虫剂效应指的是：如果你不断重复相同的测试，那么软件会对你的测试产生免疫，多个版本迭代下来，最终这些相同的测试用例将不再能发现新的bug。

　　这是因为几轮下来，在这些用例覆盖的领域，bug已经被修复的差不多了，而且在测试人员发现bug的地方，开发人员也会格外关注和小心，这样最终软件对这些测试产生了免疫，就很难再发现新的bug了。

　　我们把软件测试的杀虫剂效应放到农业中解释下：农药：软件测试员  ——  害虫：bug   ——   农作物：被测软件

　　现状：随着被测软件的规模越来越大，功能越来越复杂，越来越多的缺陷开始出现，我们的测试工程师对其进行不断的进行测试、不断的回归，但仍然发现每次测试仍然会发现很多的缺陷（测试无穷尽）。

　　原因：（1）被测软件越来越大，功能越来越复杂（害虫抵抗力越来越强）；（2）测试人员思维定势，使用测试技术和方法单一（长期使用同一款农药）。

2、从农业回归到IT测试行业：

　　只要做过软件测试的测试人员都会发现一个有趣的现象：开发刚转测当天，测试人员是一个bug接一个bug的提，但随着测试进度的推进，每天发现在的缺陷会越来越少，到最后简直就是不能够发现缺陷了。

　　但是能说这个软件中不存在缺陷么?我相信哪个测试人员都没有这样的自信保证自己测试的软件中没有bug了，那为什么存在中明明不存在缺陷，而测试人员就是发现不了呢?

　　这是因为测试人员对缺陷产生了免疫能力，就算是一个bug放在测试人员面前，测试人员也不一定能发现。这就像害虫对杀虫剂产生了免疫，杀不死一样的。那应该怎么解决这个问题呢，我相信这是所有测试人员都关注的一个问题。

3、解决方法：

（1）内部测试人员交叉测试，测试团队成员对被测系统交叉模块测试。（使用不同品牌的农药）

（2）测试用例常用常更新，在测试过程中根据软件的特性修改测试用例。

（3）不断地变化测试方法，不要使用单一的测试方法去测试软件，根据软件内容使用不同的测试手段、测试方法。

　　测试人员提升自己能力，掌握新技能，新思想，新方案，用更多测试技术提高测试覆盖率。（修改农药配方，提升配方质量）

（4）引入更高级测试人员，同时对现有技术人员进行技能培训。（提高使用农药浓度）

　　根据上面四种方法交叉执行，从而发现更多的缺陷，保证软件质量，降低风险。

　　所以永远不要停止测试，永远不要停止思考，永远不要相信某一种方法或者工具可以帮助你解决所有问题！在这岗位上就不要停止学习新的技术和方法！

4、那如何防止杀虫剂效应呢？

（1）根据产品变更，持续维护和更新你的测试用例

　　不管是大的变更还是琐碎的变更，都要及时增加相应的新用例；并分析对已有功能的影响，修改受影响的现有用例。

（2）改变原有测试数据

　　在实际工作中，我们会发现，有很多生产环境的bug都是和具体数据相关的缺陷，所以在原有测试数据发现缺陷越来越少甚至发现不了缺陷的情况下，应该尝试去增加或者更新一下旧的测试数据。

（3）同行测试

　　让同行，可以是测试同行、也可以是产品经理、运维人员、甚至是新人等，参与进来进行测试，他们会从一些新的视角，尝试一些新测试场景，发现一些新的bug。

（4）减少已经有杀虫剂效应的测试用例或者降低它们的优先级

　　比如对于一些用例来说，他们在10次回归测试中都没有发现bug，这个时候就要review评审一下这些用例，说明系统已经对它们产生了杀虫剂效应，除了冒烟测试级别的用例外，就要适当减少这些用例的数量，或者降低这些用例的执行优先级。

　　因为随着时间推移，系统逐渐变的庞大，这些用例的数量也将越积累越多，他们在每次回归中可能都会占用很大比例的执行时间，一般来说如果这些用例在5次回归执行中都没有发现缺陷，就要考虑减少他们的数量或者降低它们的执行优先级，以提升测试执行的效率，同时保证测试质量。

二、金字塔模型：

1、金字塔模型介绍

　　在敏捷方法中，持续集成是其基石，持续集成的核心是自动化测试。关于测试金字塔，来自Martin Fowler。在他的书《Succeeding With Agile》中详细描述着：“测试金字塔最底层是单元测试，然后是业务逻辑测试，最后是端到端的测试（GUI或CLI）。”模型如下图：

　　金字塔模型大约是在10年前，随着敏捷流程的出现，由敏捷专家Mike Cohn提出的。金字塔模型是对整个软件开发过程中所有测试工作的一个理想指导模型，不仅涉及测试工程师的测试工作，同样涉及开发人员的测试相关工作，尤其适用于当前敏捷模式中的自动化测试。

　　金字塔模型把整个开发流程中的所有测试由底到上分成了三大类型：

（1）最底层的单元测试（unit testing）：单元测试是基于代码层面的测试，重点在于验证某个代码单元的功能是否正确，属于白盒测试范畴，一般由开发人员自己进行。

（2）中间层的集成测试（integration testing）：集成测试的重点是测试组件与组件之间，模块与模块之间，或者更大的系统与系统之间的集成情况，属于灰盒测试的范畴，根据情况一部分可以由开发人员进行，一部分可以由测试人员进行。

（3）最上层的UI层测试（User interface testing）：UI测试的重点在于在UI层模仿用户使用系统，验证系统是否符合用户需求，属于黑盒测试的范畴，一般由测试人员进行。

2、金字塔模型原则

　　金字塔模型给出了在整个项目开发中，这三大测试类型的理想占比：单元测试的比重应该占70%以上，集成测试的比重占20%左右，UI层测试的比重小于10%。

　　这种占比的金字塔模型体现了两个原则：

（1）缺陷越早被发现，解决的成本越低

　　有一个不同阶段发现缺陷解决成本的统计：如果单元测试阶段发现缺陷解决成本为1的话，那么集成测试阶段发现缺陷的解决成本就是10，到了UI层解决成本就是100。所以从成本考虑，应该更多的进行单元测试和集成测试。

（2）越底层的测试执行效率越高

　　执行一个单元测试，需要的时间可能是毫秒级别，而执行一个UI层的测试，连最简单的登录验证都需要几秒钟的时间，一个下单流程需要几分钟的时间，而一个复杂的End 2 End的流程可能需要几个小时的时间。

　　而在当前的敏捷模式下，频繁的版本发布需要配合频繁的测试验证工作，如果UI层测试的占比很大，每次验证就会花很多的时间，势必影响测试执行和项目发布的效率。所以从这个层面考虑，也应该更多的进行单元测试和集成测试。

3、理解总结

　　我的理解是自动化测试金字塔模型中最底层是单元测试，中间层是集成/接口测试，最顶端是端到端的GUI测试。其实自动化测试金字塔模型并不是什么新鲜内容，比较类似我们大家了解的MVC模型，有异曲同工之处。

　　自动化测试金字塔模型给我们带来的启示如下：

1、unit单元测试，速度快，且成本低（当然这里的成本低，是指可以前移测试早发现问题，缺陷修复代价来讲，但从目前如果开发要强制单元测试，成本其实并不低，影响因素也众多）

2、ui端到端测试，速度慢，且成本高（与上面解释类似）

3、Service集成和接口测试，处于二者中间，其实这块我认为是测试收益最大，且最容易有成果和成效的部分；

4、自动化测试金字塔模型还给我们的启示是，如果在进行ui测试时，发现缺陷，有可能是你的中间service层或是unit层有缺陷，我们应追朔本源，解决问题根据原因所在。

三、缺陷集群性 (2/8原则)

　　世界上万事万物都符合二八原则，比如著名的财富理论：世界20%的人掌握了世界上80%的财富。还有成长理论：判断一个人是否成功，主要看他20%的业余时间做什么事情。

　　软件测试也符合二八原则:

1、功能：一个软件20%为主要功能，会花费软件测试人员80%的时间。

2、缺陷：一个功能模块发现的缺陷越高，那存在的未被发现的缺陷也越高，故：发现的缺陷与未发现的缺陷成正比。

　　软件测试工作的分配比例应该与预期的和后期观察到的缺陷分布模块相适应。少数模块通常包含大部分在软件测试版本中发现的缺陷或失效。这个符合80-20原则，即80%的缺陷发生在20%的模块中。

　　造成这种现象的可能性如下：（1）该模块功能比较复杂；（2）实现该功能模块的开发工程师水平比较低；

　　James Whittaker等著的《探索式软件测试》书中提到对软件灾难区进行重点测试也是基于这点考虑的。

四、软件测试活动依赖于软件测试背景

　　在面试过程中有时总会遇到面试官问“做软件测试什么最重要”，想来做过测试的都知道“需求”最重要，对测试人员来说是需求，对公司来说就是业务。

　　根据业务的不同，软件测试内部也分不同的行业，比如游戏行业，金融行业，电商行业等等。不同的行业，测试活动的开展都有所有不同，比如工具的选择，测试流程都不尽相同，所以软件测试活动的开展依赖于所测试的内容。

五、软件测试的7大基本原则

1、测试尽早介入

　　从分析不同的测试模型来看，测试介入的越早越好。为什么测试要尽早介入呢？这要先弄清楚软件测试的目的是什么？简单的来说就是保证软件质量，降低成本。

　　测试人员一般都在需求阶段就开始介入，这时测试的对象就是需求。

　　软件测试的目的是保证质量，预防风险，降低成本，其中成本包括缺陷的修复成本，缺陷有一个特点就是越早发现的缺陷，修复成本越低，这也是为什么测试要尽早介入，就是为了能够在需求阶段就能找出需求与设计方面的缺陷，降低后期的修复成本。

2、穷尽软件测试是不可行的

　　理论上我们希望在软件投入使用之前能够通过软件测试，把各种输入和前提条件的组合都测试一遍。但在实际上这种穷尽的软件测试是不可能实现的。一方面这种穷尽的软件测试所消耗的工作量巨大，软件的收益和成本不成比例；另一方面软件中存在。一些无关紧要的缺陷，并不会影响软件的使用。所以软件通常会遵循一个 good enough原则——通过衡量测试的投入产出比，测试既不能太少，也不能太过。

3、软件测试能够发现软件存在缺陷，但不能证明软件没有缺陷

4、缺陷集群性（2/8原则)

5、杀虫剂悖论

6、测试活动依赖于测试内容

　　不同领域的软件测试都有它自己的特殊的测试策略。比如，军用软件会重视可靠性和安全性的测试，信息化系统软件则会强调压力测试等性能的测试。

7、无法使用的软件不需要测试

　　如果一个软件根本无法正常使用，或者他最主要的软件功能都不能正常使用这样的软件是完全没有必要进行测试的。