3）“累积发现的缺陷趋势”的拐点未出现
在实际项目中，还有一种情况是“累积发现的缺陷趋势”的“拐点”一直未出现，如图6-17所示（以“虚线”表示“理想”的情况，实线表示实际项目中的情况）。
这说明在这个测试阶段里，测试团队依然可以发现产品大量的问题。出现这种情况，可能的原因是：
· 测试团队未按照测试策略进行测试，可能使用了更多、更复杂的方法来发现产品缺陷。
· 版本质量太差，缺陷密度高于预期。
出现第一种情况，这个团队的测试者水平应该比较不错（至少掌握的测试方法比较多）；也应该比较有测试激情（不是按照软件测试架构师要求的任务测完就结束了，而是自己主动去发现系统更多的问题）；另外版本的质量可能也不错（至少还能够使用各种测试方法来“折腾”系统），没有严重的测试阻塞。但这依然需要软件测试架构师和测试者仔细核对测试计划，确认测试者是在保证了测试计划的前提下才进行发挥的——核对的过程可能会让人感到有些尴尬，但我们的核心理念是：通过测试策略来进行“刚刚好”的测试，而不仅是为了发现产品的缺陷。
所以，我们的测试内容会包含一些不太容易发现缺陷，但很重要的项目。我们必须保证对这部分内容的确认，尽管这可能影响我们发现的缺陷总数。
如果确认发现测试计划存在偏差，需要在下个版本中进行补充测试，并和测试者做好沟通。
出现第二种情况，软件测试架构师可以考虑从如下几个方面来更新后续的测试策略：
· 增加相关内容的测试用例执行次数。
· 加强相关内容的回归测试。
· 对发现的缺陷进行逆向分析，增加探索式测试。
3. 缺陷是否收敛
我们在判断缺陷趋势是否收敛时，需要具备以下两个条件，缺一不可（图6-18）：
· “累积发现的缺陷趋势”变为凸函数。
· “累积发现的缺陷趋势”和“累积解决的缺陷趋势”两条曲线越来越靠近，最后逐渐趋于一点。
缺陷收敛说明当前测试已经不能有效发现问题，并且发现的缺陷也已经被有效修复。每做完一个测试分层（如集成测试、系统测试）的测试，都需要进行一次缺陷收敛分析，以确认是否满足该阶段测试的出入口条件。此外，缺陷收敛还是我们最后判断测试是否能够退出的必要条件——即便按照计划，测试时间已经到了，如果缺陷不收敛，也不应该退出测试，发布产品。
下述几种缺陷趋势图，都不算缺陷收敛。
（1）两条曲线未出现越靠越近的趋势，如图6-19所示。
这时最主要的问题在于开发还有较多的缺陷需要修复，测试还有较多的缺陷需要验证。我们不应该忽视缺陷修复带来的代码改动或引入的新问题。缺陷验证、回归测试和基于缺陷的探索式测试都可能再发现一些新的缺陷，甚至迎来新一轮的“缺陷小高峰”，“累积发现的缺陷趋势”出现新的“拐点”。因此我们可以认为有限、可控的代码改动是缺陷收敛的必要条件。当我们发现缺陷不收敛时，做好代码改动方面的控制，是一个很好的
思路：
· 严格控制代码改动，非必要不改动。
· 做好代码的静态检查。
· 做好和修改相关的功能自测，避免因为缺陷修改而引入新的问题。
（2）累积发现的缺陷趋势为凹函数。如果累积发现的缺陷趋势为凹函数，即使累积发现的缺陷趋势和累积解决的缺陷趋势呈现出越靠越近的趋势，也不算缺陷收敛——但是能说明开发修改缺陷的速度还蛮快的，如图6-20所示。
此时最主要的问题是测试还能发现产品大量的缺陷。读者可以参考上一节中的分析来确定解决措施。
本文选自《测试架构师修炼之道:从测试工程师到测试架构师》第六章，本站经机械工业出版社和作者的授权。
版权声明：51Testing软件测试网获机械工业出版社和作者授权连载本书部分章节。任何个人或单位未获得明确的书面许可，不得对本文内容复制、转载或进行镜像，否则将追究法律责任。
