浅析软件测试中的⼀些常见理论：杀⾍剂效应、⾦字塔模型、缺陷集性原则、软件测试活动依赖于软。。。
  这篇⽂章我主要想记录学习⼀下在软件测试⾏业中的⼀些常见理论效应以做基本了解。
⼀、杀⾍剂效应
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、⽆法使⽤的软件不需要测试
  如果⼀个软件根本⽆法正常使⽤，或者他最主要的软件功能都不能正常使⽤这样的软件是完全没有必要进⾏测试的。