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