例如某些缺陷是可通过多种方法解决的，但每种方法对代码架构的影响、对测试成本的影响和对客户的影响都不尽相同。需要平衡时间、成本及客户接受程度等要素来决定此时最佳解决方案。

　　缺陷修改对当前代码架构的影响，会影响到哪些测试团队。

　　例如有些代码改动可能需要功能测试团队，性能测试团队和安装测试团队重新运行一些测试案例。

　　受影响的测试团队需要多少时间和人力来完成由于代码修改而必须运行的测试案例包括回归测试案例。

　　通过测试成本计算，能够清晰地知道是否能有足够时间和人力在产品交付时间之前完成缺陷修复。

　　如果此缺陷不在当前版本里修改，会对客户和客户技术支持团队造成什么影响。

　　客户影响是非常重要的一个要素。有些缺陷被叫做“禁止交付”缺陷，顾名思义就是如果产品存在这些缺陷，则产品不能交付给客户。因此所有“禁止交付”缺陷一定要在产品交付前有解决方案。

　　另外，客户技术支持团队需要衡量一下，如果某缺陷不在当前版本修复，在当前产品版本推向市场后如果客户遇到相同问题，客户技术支持团队会需要额外付出多少人力资源来和客户沟通并解决客户问题。

　　客户对此产品缺陷的最大容忍时间大约多久。

　　通过分析客户对修复此缺陷的紧迫性来决定是在当前产品版本修复还是将缺陷修复推延到以后的产品新版本包括补丁版本、小版本或产品下一升级版本。

　　根据缺陷分析结果，一般会有以下解决方案：

　　在当前产品版本里修改缺陷，并按时交付客户。

　　例如：某些缺陷对客户影响大且缺陷修改对代码构架影响较小，测试团队能按期完成测试任务。

　　在成品测试阶段，所有缺陷修改必须经过项目经理同意并通过案例测试和回归测试后才能集成到下一个成品测试候选驱动上。

　　在当前产品版本里不修订缺陷，尽快在产品补丁版本或小版本里修改缺陷，并尽快交付客户。

　　例如一些产品功能客户在产品上线初期不会用到，和此功能有关的一些缺陷可以在随后发布的补丁版本里修复。

　　在当前产品版本里不修复缺陷，在下一个产品升级版本里修改缺陷。

　　例如有些缺陷对客户业务影响不是很大，只是在应用上需要一些改进而使客户应用起来更方便，对于此类缺陷，如果是在测试前期当然是尽可能修复。但在测试后期，尤其是成品测试阶段，就尽量不要因为此类缺陷改代码而引起不必要的回归问题。

　　在当前产品版本里修改缺陷，但需要推迟交付客户。

　　这种情况很少见。原因可能是前期测试存在重大漏洞，而存在的缺陷是客户不能接受的，但产品开发团队又无法在原定交付时间完成缺陷修复和相关测试。当然这种情况是每个产品项目都要想方设法避免的。

　　注意：如果缺陷修复需要推延到以后的产品新版本包括补丁版本、小版本或产品下一升级版本，除了需要得到开发团队、测试团队和项目经理的同意外，还需要得到客户技术支持团队的同意和支持，以便客户遇到相同问题时，可以和客户沟通。如果对此问题有临时解决方案，也需要第一时间通知客户支持团队以便在客户需要时提供给客户。

　　小艾在姚圳的详尽介绍中受益匪浅，他开始考虑或许这些缺陷综合分析方法不只在成品测试阶段需要，也可借鉴到整个测试阶段，尤其是测试后期。