希望这篇文章会对大家有所启示。

软件测试中7个看透不说透的真理

真相1：测试并不能找出所有的bug
真相2：测试覆盖率与测试的效果几乎没有相关性
真相3：测试工作量呈指数增加
真相4：开发者偏差
真相5：晚期发现的缺陷可能不会花费更多来修复
真相6：探索性测试需要流程和文档
真相7：改进流程中的非质量保证活动可以提高产品质量
奖励关（有趣的事实）：百慕大计划

1，当你是一个项目的的测试负责人的时候，你有没有过质问过项目成员为什么没测试出某个具体的bug，或者因为某人没有测出bug而直接责备他？

2，当你提升了测试覆盖率的时候你有没有发现产品的bug数量其实没有发生变化？

3，你有没有在发布之前花费了大量的时间去进行测试却最终发现一无所获，而发布之后bug却不期而至？

4，开发可以测试他们自己的代码吗？

5，bug真的是发现的越晚修复成本就越高吗？

6，你有没有过以不按套路出牌的方式来进行软件的测试，并称之为“探索性测试”？

7，你是否需要通过QA活动来提升产品质量？

真相1：测试并不能找出所有的bug

很不幸这是真的，没有任何一种测试方式可以保证找出所有的bug。

一些测试活动跟直接上手点点点相比确实效率要低一些，所以我们可以不用那么关注测试的类型，相反我们要做的是选择合适的测试类型并综合使用，从而以最少的工作量打到较好的效果。（比如ui的自动化测试如果要做到非常复杂那么将花费相当大的开发和维护成本，但没有ui的自动化，每轮测试都靠人肉点来点去也不现实，所以比较合适的做法是一些稳定的核心路径可以用ui自动化去实现，平衡投入产出比，用较少的工作量达到效率最大化）

当有人抱怨为什么测试没有发现某些问题的时候麻烦提醒他们：测试确实没有办法保证一定会发现某些特定的缺陷。

我们会经常复盘测试的漏测情况，很不幸，这是落后的想法，这就像是在魔术揭秘了之后再马后炮的说其实这个戏法很简单，很容易被识破一样。事后做漏测复盘并不是一个有效的分析手段。

永远不要责备测试工程师，他们并没有写出bug，相反，他们一直在努力找出开发过程中引入的缺陷。没有什么是完美的，测试同学在接受现实的同时也需要记住千万别立flag，因为测试不可能发现所有的bug。

真相2：测试覆盖率与测试的效果几乎没有相关性

是的，你没有看错。我们已经有足够的科学证据表明，增加单元测试覆盖率不一定会提高我们测试套件发现bug的效率！也许是时候关注与测试相关的内容而不是正在测试的代码量了。（这里作者的原话是We already have enough scientific evidence to say that increasing unit test coverage may not necessarily increase your test suite effectiveness in finding defects!直译过来就是单元覆盖率的提升并不会提升测试套件发现缺陷的效率，说实话，我觉得单元测试覆盖率跟测试中发现bug的效率本来就没有什么关系，覆盖率代表的是代码被测试的程度，而发现bug的效率指的是时间和产出的关系，发现bug的效率高并不代表着产品的质量就好，反之亦然。不过看下文引用资料时的描述，我们可以看到作者的举证基本上都透露了一个信息，那就是单元测试覆盖率与bug的数量之前没有太多的关联，换句话说就是并不是单元测试覆盖率越高，产品的质量就越好，因为产品的质量好一般意味着可被观察到的bug相对少，而bug又跟单元测试覆盖率无关。这里为了严谨，作者的引用我就不做翻译了。）

*A. Mockus, N. Nagappan, and T.T. Dinh-Trong, “Test Coverage and Post-verification Defects: A Multiple Case Study,” Proc. 3rd Int’l Symp. Empirical Software Eng. and Measurement (ESEM 09), 2009, pp. 291–301.*The correlation between coverage and defects was none or very weak. Moreover, the effort required to increase the coverage from a certain level to 100% increased exponentially.
*M.R. Lyu, J. Horgan, and S. London, “A Coverage Analysis Tool for the Effectiveness of Software Testing,” IEEE Trans. Reliability, vol. 43, no. 4, 1994, pp. 527–535.*Qualitative analysis found no association between the defects and coverage.
*B. Smith and L.A. Williams, A Survey on Code Coverage as a Stopping Criterion for Unit Testing, tech. report TR-2008–22, Dept. of Computer Science, North Carolina State Univ., 2008, pp. 1–6.*The results did not support the hypothesis of a causal dependency between test coverage and the number of defects when testing intensity was controlled for.
*L. Briand and D. Pfahl, “Using Simulation for Assessing the Real Impact of Test Coverage on Defect Coverage,” Proc. 10th Int’l Symp. Software Reliability Eng., 1999, pp. 148–157.*The results did not support the hypothesis of a causal dependency between test coverage and the number of defects when testing intensity was controlled for.
*P.S. Kochhar, F. Thung, and D. Lo, “Code Coverage and Test Suite Effectiveness: Empirical Study with Real Bugs in Large Systems,” Proc. IEEE 22nd Int’l Conf. Software Analysis, Evolution, and Reengineering (SANER 15), 2015, pp. 560–564.*A moderate to strong correlation was found between coverage and defects. However, the coverage was manipulated and calculated manually.
*L. Inozemtseva and R. Holmes, “Coverage Is Not Strongly Correlated with Test Suite Effectiveness,” Proc. 36th Int’l Conf. Software Eng. (ICSE 14), 2014, pp. 435–445.*A weak to moderate correlation was found between coverage and defects. The type of coverage did not have an impact on the results.
*X. Cai and M.R. Lyu, “The Effect of Code Coverage on Fault Detection under Different Testing Profiles,” ACM SIGSOFT Software Eng. Notes, vol. 30, no. 4, 2005, pp. 1–7.*A moderate correlation was found between coverage and defects, but the defects were artificially introduced. The correlation was different for different testing profiles.
*G. Gay et al., “The Risks of Coverage-Directed Test Case Generation,” IEEE Trans. Software Eng., vol. 41, no. 8, 2015, pp. 803–819.*Coverage measures were weak indicators for test suite adequacy. High coverage did not necessarily mean effective testing.

真相3：测试工作量呈指数增加

许多消息来源指出，测试人员会在测试活动开始时发现更多缺陷，而在结束时发现缺陷则更少。有迹象表明，为了找到下一个缺陷，增加覆盖率和执行测试的工作量呈指数增长。

在论文“Test Coverage and Post-verification Defects: A Multiple Case Study,” (A. Mockus, N. Nagappan, and T.T. Dinh-Trong, Proc. 3rd Int’l Symp. Empirical Software Eng. and Measurement (ESEM 09), 2009, pp. 291–301.)中透露：将覆盖率从某个水平增加到 100% 所需的努力呈指数增长。

根据“Implementing automated software testing: How to save time and lower costs while raising quality.” (Dustin, E., Garrett, T., & Gauf, B. (2009). Pearson Education.),的阐述：软件可靠性模型表明，随着在测试中投入更多时间，每单位时间发现的缺陷数量呈指数减少。

真相4：开发者偏差

如果开发人员在开发阶段直接把一个需求理解错了，那么他写出来的代码就是错的，对于测试人员来说情况也一样。

如果开发同学直接忘记在代码中处理某些情况，比如特定的条件验证，那么他也很可能不会记得对这种场景进行测试。

为了避免这种情况，开发人员可以互相测试彼此的代码，但他们最好不要测试自己的代码，这就是所谓的交叉测试。

在没有设计任何测试用例的情况下，开发同学还是可以测试自己的代码的，这样就可以尽可能的避免一些先入为主的偏差。

测试驱动开发可能会降低开发忘记做某事概率，但不会减少误解某些需求的概率。

真相5：晚期发现的缺陷可能不会花费更多来修复

这是非常反直觉的，因为人们可能习惯于看到这样的图片：

这上面的数字可能是有水分的，Laurent Bossavit 是巴黎软件咨询公司 CodeWorks 的敏捷方法论专家和技术顾问，他在github上的文章“Degrees of intellectual dishonesty”就透露了这些信息可能是被捏造出来的。

在一篇名为“Are delayed issues harder to resolve? Revisiting cost-to-fix of defects throughout the lifecycle” (Menzies, T., Nichols, W., Shull, F. et al. Empir Software Eng 22, 1903–1935 (2017) https://doi.org/10.1007/s10664-016-9469-x)的论文指出：没有发现任何证据表明在代码投入生产后进行缺陷的修复需要花费更长的时间。

论文“What We Have Learned About Fighting Defects” (Forrest Shull, Vic Basili, Barry Boehm, et al., Proceedings of the 8th International Symposium on Software Metrics (METRICS ‘02). IEEE Computer Society, USA, 249. 2002.)中，作者指出：修复某些非关键bug的成本在整个生命周期阶段几乎保持不变（项目早期平均 1.2 小时，项目后期平均 1.5 小时）。

不过很多的研究都在度量定位错误和修复bug的工作量，那么他们忽略了什么？

回归测试：在发布之前我们要进行频繁的回归，为了验证某些重要的bug已经被修复了，我们就需要一次又一次的对主流程甚至是大部分的逻辑进行回归测试，这显然是很巨大的工作量；
机会成本：在项目的晚期发现问题的时候，很多人往往会将bug排到下一个版本或项目，这很可能导致项目延期交付；
企业商誉成本：企业可能会被罚款，客户可能会亏钱，用户体验自然也就不好。2020 年 12 月，游戏《赛博朋克 2077》因发售时出现诸多技术问题而从索尼商店下架。索尼提供全额退款。随后，开发商CD Projekt Red宣布对PS4和Xbox玩家进行退款。在投资者电话会议上，CD Projekt Red 表示“与恢复公司声誉相比，《赛博朋克 2077》修复的成本“无关紧要”。该公司的股票已从 2020 年 12 月的每股 31 美元跌至 2021 年 6 月的每股 10 美元。
bug并不是在代码中引入的。比如在项目的初期做技术设计的时候就存在缺陷，或者需求本身就是个bug，那么越晚发现灾难就越大。
因此，虽然发布后修复代码错误的工作量可能不会增加那么多，但早期修复bug可以节省大量精力、金钱和麻烦。

真相6：探索性测试需要流程和文档

很多人认为如果他们对产品做一些无法预料结果的操作，比如在表单胡乱输入并且提交，那么他们就是在做探索性测试。

其实探索性测试并不意味着你要对系统或者产品做一些特别的事情，它往往意味着我们需要了解系统是如何真正工作的，并且与普通的功能测试同时进行。

换句话说探索性测试可以（并且最好应该）得到现有文档的支持，例如需求文档和设计文档。这里的区别在于探索性测试的测试用例不是预先编写好的。

探索性测试可以脚本化，一旦发现问题就可以把bug记录在案，然后可重复执行的脚本又可以在后面的测试过程中反复使用。（比如探索测试时可以使用浏览器自带的录制功能，发现bug之后就把录制好的脚本保存下来，给后面的回归测试使用，chrome现在已经自带了录制能力了）。

测试用例仍然应该使用边界值分析、等价类划分等技术来设计。我们没有理由设计一些随机的测试用例，因为它们在检测缺陷方面可能不具有成本优势或有效性。

真相7：改进流程中的非质量保证活动可以提高产品质量

（这里原文的论述我实在是没弄明白并且找不到合适的数据支持，所以就简单的粘贴英文版本了）

A 2009 study in Brazil (in Portuguese) involving 135 software development organizations had their capacity to identify and fix defects increased by improving their processes. These companies were part of a Brazilian software process improvement program called “MPS.Br,” where they should adhere to a software process improvement model (the MPS Model).

This model has stages, and 58 of these companies were in the first stage, where they were required to improve their Project Management and Requirements Management processes.

While it’s unclear why this happened, we can reasonably expect that projects that identify the right people to participate in the team, training needs, and proper budget and schedule will likely have the people, the time, and other resources to improve quality.

奖励关（有趣的事实）：百慕大计划

好吧，这是一个有趣的，但没有解释的事实，它可能真的不起作用。

百慕大计划是更快完成项目的战略名称。将团队的一部分派往百慕大（即，将他们从项目中移除），项目会更快完成。

它被认为是对布鲁克斯定律（Brooks’s law）的回应（对软件项目管理的一种观察，根据该定律，“在延期的软件项目中增加人力会让项目交付的更慢一些”）。那么，如果您移除人员，项目是否应该进行的更加迅速？

根据我的经验，加入团队的每个新人都会占用一个老人工作时间的 1/3 左右，直到新人们逐渐提高生产力。

因此，踢走最近加入的人可能真的会提高工作效率。

如果团队中有太多冲突，它可以起作用的其他原因是：移除与团队目标不一致的人可能会对团队有所帮助。

如果团队中有太多人，那么沟通开销可能会大到足以阻碍生产力。在这种情况下，拆分团队可能效果很好（这在技术上与从项目中移除人员不同）。

否则，移除人员只会降低团队在短期内的输出。

无论如何，我只是在分享百慕大计划，因为谈论它总是很有趣。

基础巩固

软件测试入门到项目实战，7小时从小白到白领的软件测试快速入门课程

软件测试实战教程《学车不》APP实战软件测试

首次公开丨黑马头条软件测试实战项目完整版

软件测试基础手把手带你Excel实现管理接口用例

软件测试基础-手把手教你搞懂测试环境项目部署

软件测试教程Charles抓包工具测试实战

软件测试工程师必备MySQL数据库，mysql系统精讲+课后练习

软件测试进阶教程微信小程序测试实战—全网首发

软件测试中7个看透不说透的真理相关推荐

功能点算法及在软件测试中的应用
--划分逻辑事务在前一篇文章我们讲到,"逻辑事务"是统计功能点指数的最小单元,所以进行科学的划分,对统计的正确性非常重要.另外,划分逻辑事务其实也是一个需求分解的过程,测试工程师 ...
软件测试中的风险管理
项目风险管理是PMP中的一个主要章节,小编在这里主要针对风险管理在软件测试中的应用场景进行描述说明,让测试同学能够更全面的把控项目风险,确保项目按期完成交付. 什么是风险管理软件测试是保证软件质量的 ...
软件测试中排错的基本方法
软件测试中,排错(即调试)与成功的测试形影相随.测试成功的标志是发现了错误.根据错误迹象确定错误的原因和准确位置,并加以改正的主要依靠排错技术. 1.排错过程如下图所示,排错过程开始于一个测试用例的 ...
阿里研究员：软件测试中的18个难题
简介:对于软件测试来说,怎么样才算测够了?如何评价测试的有效性?那么多测试用例,以后怎么删?在软件测试中会遇到非常多的问题,阿里研究员郑子颖分享了18个他总结出的难题以及相关看法,希望对同学们有所启发 ...
软件测试中条件覆盖，路径覆盖，语句覆盖，分支覆盖的区别
转:软件测试中条件覆盖,路径覆盖,语句覆盖,分支覆盖的区别举个例子吧 if A and B then Action1 if C or D then ...
无法定位程序输入点 except_软件测试中的功能测试点(三)
testkuaibao|软件测试自学公众号 26.输入法半角全角检查再输入信息中,输入一个或连串空格,查看系统如何处理,如对于要求输入符点型数据的项中,输入全角的小数点("."或 ...
软件测试除了边界值还有什么,在软件测试中,假定 X 为整数,10≤X≤100,用边界值分析法,那么 X 在测试中应该取（）边界值...
北方猎人(cnitpm.com) 10:58:42 在软件测试中,假定 X 为整数,10≤X≤100,用边界值分析法,那么 X 在测试中应该取( )边界值. A．X=9,X=10,X=100,X=1 ...
心理软件测试自学,软件测试中的心理学
能做一名软件测试人员不容易,要做一个名合格的软件测试人员更是不容易,因为软件测试人员要运用的知识很广,当然心理学也不例外. 测试执行得差,其中一个主要的原因在于大多数的程序员一开始就把这个术语的定义搞 ...
什么是软件测试中的黑天鹅
1,黑天鹅以及软件测试中的黑天鹅在发现澳大利亚的黑天鹅之前,欧洲人认为天鹅都是白色的.所以说"黑天鹅"代表了一个小概率事件,它罕有发生,但一旦出现,就具有很大的影响力." ...

软件测试中7个看透不说透的真理

软件测试中7个看透不说透的真理

真相1：测试并不能找出所有的bug

真相2：测试覆盖率与测试的效果几乎没有相关性

真相3：测试工作量呈指数增加

真相4：开发者偏差

真相5：晚期发现的缺陷可能不会花费更多来修复

真相6：探索性测试需要流程和文档

真相7：改进流程中的非质量保证活动可以提高产品质量

奖励关（有趣的事实）：百慕大计划

软件测试中7个看透不说透的真理相关推荐

最新文章

热门文章