测试的有效性
本文作者：姜越
我们通常遵循测试流程，进行需求澄清、评审、测试需求分析、测试用例设计……、测试执行、缺陷验证、产品发布。以保证产品质量在标准化测试流程下得到保障。
但，不妨，我们倒着再看下这个流程，是否上线取决于已知缺陷是否修复，已知缺陷的取决于测试发现，测试发现取决于测试设计，测试设计取决于人，不同的人。
因此我们很容易发现整个测试流程存在一个BUG，那就是如果测试设计的人，在测试设计方面的能力偏低时，仍不会影响流程的连贯性，产品仍然可以经过一系列环节，最终上线。
因此，我们有了测试设计评审这个环节，以完善补充测试设计，但这个环节是否解决了这BUG，在不讨论评审环节有效性的前提下，其实也并没有解决，只是一定程度降低了这个BUG的影响程度。
这种情况下，我们通常又会采取另一种策略，以反补测试设计 —— 线上问题（漏测问题）分析。如果线上问题较多，单从这次项目测试的角度来说，测试有效性很低，甚至是无效的。只不过这个就比较滞后了，已经影响到用户了。
# 为什么我们对测试有效性的思考并不多？
往往在没有感知到外因的情况下，是难以触发对内在的思考或反思。
关于测试有效性，同样如此，我们很少去思考这个问题。
一方面，经过标准化的测试流程，产品发布上线。实现由内到外的转变，可现阶段我们难以感知转变过后的情况，即由于线上问题反馈渠道不统一，问题记录渠道也不统一，使得对 “外” 的感知力较弱。
另一方面，还有一个重要的因素 —— 活跃用户数量，即活跃用户数量与产品质量要求之间的关系。
这个因素，其实很少被关注到。因为，往往一个产品发布，面向的用户是数以万计，甚至是百万、千万的。但由于我司产品的用户群体的特殊性，这种用户体量几乎是不存在，通常只有几十或几百活跃用户数量。
按照二八原则，80%的常规使用场景，20%的特殊使用场景。随着用户的不断增多，在常规场景的覆盖越来越多，直至不断的覆盖到20%的特殊场景（特殊场景是不可枚举的）。用户越多，触发的使用（场景）轨迹越多，“意想不到” 的使用轨迹也就越多。
因此，在我司产品的活跃用户数量下，生产环境中，80%的常规场景可能都没覆盖完，更不用说20%的特殊场景了。
这也从侧面告诉我们，即使通过 "线上问题" 这个外因，可能也不足以引起对测试有效性的关注。
那么，在这种活跃用户数少的情况下，测试有效性是否需要达到一个较高的水平？
这是一个值得讨论，甚至是争论的问题，透过表面看本质：
- 【表面】从项目的角度：如果活跃用户将一直保持在这个极低的水平，此时测试有效性较低，并不影响产品发布后的用户体验。但当活跃用户数量不断增高时，线上缺陷数量也会呈增多趋势，这个趋势受测试有效性的影响，当有效性低时，趋势将更加明显，这是必然的。
- 【本质】从人的角度：测试有效性归根到底，是测试设计的能力。如，某个团队长期处于一个低测试有效性的测试设计水平时，当因外部压力较大，比如用户群体、用户数量发生变化，不得以要提升测试有效性时，我们短时间内，难以达到这个要求，这个”短时间“如果悲观一点统计那将是数以年计的。
# 关于测试有效性的讨论
按以往，测试用例编写完成，发起测试评审，以一定程度解决上述的那个BUG，因此测试用例评审 这个环节至关重要，整个流程中只有这个环节是在有效的评估、保障测试有效性。
2021年度，测试活动中心，其中一项运营数据，就是测试评审环节的评审意见数。
从质量属性的角度来说，可以划分为功能性、可靠性、性能、易用性等等。总体来说，测试活动保障的核心内容大概分为以下几点：
- 验证功能实现的正确性
- 验证功能实现的完整性
- 验证功能实现的可靠性
除了通过用例评审的方式，是否存在更客观的评估方式？—— 代码覆盖率。
通过首轮测试用例执行的代码覆盖率，来反映测试设计的有效性，试想：
- 首轮用例执行完成后，代码覆盖率20%，其中新增或变更代码覆盖80%。
- 首轮用例执行完成后，代码覆盖率80%，其中新增或变更代码覆盖20%
上面两种场景，都是影响测试有效性，进而引发质量风险的场景。代码覆盖率可以很客观、直接的反应出依据测试进行测试的覆盖度、即测试设计的有效性。
通过代码覆盖率，可以客观、全面的评估测试有效性，将线上问题从根源上减少到最少。
# 再进一步，我们做了多少有用的测试 还有多少无用的测试？
相信很多人，在每次迭代回归测试中都有这种疑问，这是黑盒测试本身的局限性导致的，由于黑盒测试的执行更多的从“用户视角”进行端端测试，使得我们难以精确的感知，本次迭代除了新增功能，历史功能哪些受到影响，进而就没办法精确的进行有效覆盖，自然测试成本投入无法做到收敛和动态调整。
如果，我们能够感知每一条用例覆盖到的代码级方法、类、接口，每次迭代通过diff两个版本的差异，自动的推荐出需要覆盖的用例，那么就实现了我们所说的精准测试的核心部分。也就解决了我们的这个疑问，少做或者不做无用测试。
这是一个值得尝试的思路，重要但不紧急。
# 代码覆盖率
# 配套
如何提高或者保障测试有效性保持在一定的水平之上，避免陷入某一种被动中。
因此，发现问题只是开始，如何解决问题才是关键。
从技术的角度，实现释放基础测试设计成本，已有初步的想法，呆梳理后 ，预研可行性。