情况可能的原因是：
· 新需求或需求变化的部分比较多，引入了缺陷。
· 新需求的质量可能不高，引入了缺陷。
· 产品设计的质量可能不高，导致设计需要频繁更改，从而引入缺陷。
对软件测试架构师来说，可以采取的措施有：
· 对这些缺陷进行分析，由此更新测试策略，增加探索或测试。
· 增加或加强和需求澄清相关的活动。
· 增加或加强和开发人员与测试人员之间针对产品设计进行的沟通活动。
· 增加一些功能交互测试和场景测试。
但想从根本上改善上述问题，还是需要研发经理、系统架构师和开发者一起来回溯总结，做好变更控制，提高变更内容（需求或设计）的质量。
5）缺陷修改引入的缺陷过多
在进行缺陷年龄分析时，如果出现了很多因为缺陷修改引入的缺陷，说明开发修改缺陷的质量不高，对软件测试架构师而言，可以采取的措施有：
· 验证缺陷时，除了验证缺陷本身是否被正确修复外，还需要围绕缺陷展开探索式测试。
· 加大对基本功能进行回归测试的比例。
· 增加或加强和开发人员与测试人员之间对缺陷修改的内容、影响的沟通，尤其是针对重点或修改较大的缺陷。
· 可以和开发人员约定一些有利于缺陷修改质量提升的措施，如对修改的代码要进行review后才能合入，每个修复的缺陷开发都需要提供自验报告，等等。
缺陷修改引入缺陷还会带来的另外一个影响，就是缺陷不会收敛。也就是说，我们可以通过控制提高缺陷修复的质量，来促进缺陷的快速收敛，这点对软件测试架构师制定、更新测试策略来说尤为重要。
6.6.5 缺陷触发因素分析
缺陷的触发因素就是测试者发现缺陷的测试方法。缺陷触发因素分析，就是对测试中使用的测试方法进行分析。
对缺陷触发因素进行分析，能够帮助我们确认产品测试是否已经进行得足够全面和深入——缺陷触发因素越全面，说明测试中使用的测试方法越多，测试得也越深入；反之意味着测试方法可能比较单一，测试得比较浅，产品可能还存在一些缺陷未能被有效去除。
和缺陷年龄分析方法类似，我们也可以通过下面3个步骤来进行缺陷触发因素分析。
第一步：确定缺陷的测试方法和测试类型。
如果你的项目有缺陷的管理工具（如bugzilla），可以增加测试方法和测试类型的选项，在测试发现缺陷的时候来记录相关的信息。
如果没有缺陷管理工具也没有关系，你可以使用类似表6-14的形式，来确定该缺陷的测试方法和测试类型。
第二步：统计出各种测试方法发现的缺陷数目，绘制缺陷触发因素分析图。
接下来我们需要统计出各类测试方法的数量，见表6-15。
并根据表中的数据绘出缺陷触发因素分析图，如图6-25所示。
第三步：进行缺陷触发因素分析
在理想情况下，我们希望做出的缺陷触发因素图和测试策略是吻合的。例如，当前版本我们的测试策略是：
对功能首先进行配置的遍历测试，需要保证新提交的命令行和以前已有的Web页面功能具有一致性；再进行基本功能测试，能够覆盖业务流程的基本路径；最后进行满规格的测试。
按照上述测试策略，我们希望的缺陷触发因素图包含的测试方法和对应的测试内容大致为：
· 功能测试——单运行正常输入：进行基本功能测试，覆盖业务流程的基本路径测试时发现的问题。
· 功能测试——单运行边界值测试：进行配置测试时发现的问题。
· 功能测试——多运行相互作用：进行基本功能测试，覆盖业务流程的基本路径和配置测试时发现的问题。
· 性能测试：进行满规格测试时发现的问题。
如果我们持续对产品进行缺陷触发因素分析，参考历史数据，结合自身的经验，我们还可以得到“不同的测试方法发现缺陷的大致比值和分布”。当然，这个比值可能不是很准，但是也可以作为软件测试架构师对数据进行分析时的参考。
很多时候，我们都会发现，根据实际测试结果绘出的缺陷触发因素图可能会和之前预期的缺陷触发因素图存在一定的偏差，可能的情况有如下两种。
1）有些测试方法没能发现缺陷或者发现的缺陷很少
出现这种情况，可以按照如下思路来进行分析：
确认测试团队是否按照测试策略的要求使用了这种测试方法进行测试？
如果答案是“否定”的，需要我们进一步确认原因。常见的原因有：
· 存在测试阻塞（如缺陷），无法使用该方法进行测试。
· 测试投入（如人、时间）不足，来不及使用该方法进行测试。
· 没有掌握该项测试方法。
然后我们再根据具体原因对症下药，更新测试策略即可。
如果答案是“肯定”的，即团队遵循了测试策略使用该测试方法进行了测试，测试投入和测试方法都没有问题，但是确实没有发现问题，或者发现的问题较少，这说明当前这种测试方法确实不能发现产品的缺陷，这样的结果应该是合理的。
对软件测试架构师来说，还需要意识到的一点就是，这样的数据结果可能暗示了产品在这方面的质量不错，和其他地方相比风险较低，我们可以考虑调整测试策略，降低这方面的测试投入，减少对该测试方法的使用，等等。
2）有些测试方法发现的缺陷特别多
如果我们发现有些测试方法发现的缺陷特别多，说明这种测试方法比较能够有效去除产品的缺陷，产品在这方面的质量可能不高，相对其他方面的风险较高，此时也需要我们调整测试策略，如增加这部分的测试投入，增加对这部分测试的方法的使用，等等。
本文选自《测试架构师修炼之道:从测试工程师到测试架构师》第六章，本站经机械工业出版社和作者的授权。
版权声明：51Testing软件测试网获机械工业出版社和作者授权连载本书部分章节。任何个人或单位未获得明确的书面许可，不得对本文内容复制、转载或进行镜像，否则将追究法律责任。
