2、评估测试代价

　　● 测试的消耗有多大？我们能承受的测试代价是多大？

　　● 我们能否从测试覆盖中消除不必要的冗余？

　　● 是什么让测试执行困难（代价高）？

　　● 产品的可测性能否再提高？

　　● 是否有工具或技术可以使测试过程更加高效？

　　● 早点测试好还是迟点测试好?哪种情况下测试的整体成本低一些？

　　3、检查测试对决策的作用

　　● 测试过程是否清楚管理者、开发人员或其它客户需要做的决定？

　　● 测试过程是否关注潜在产品和项目风险？

　　● 测试过程是否依赖变更控制过程和项目管理？

　　● 测试报告是否及时递交？

　　● 测试报告是否用易于理解的方式沟通？

　　● 测试过程和测试结果一样被传达吗？我们是否报告评估的基础以及融入我们的信心在里面？

　　● 测试过程是否对技术支持、发行、市场或其它需要使用质量评估的任何业务过程提供服务？

　　4、是否及时

　　以上三方面都是时间驱动的。所以带来了问题：我们永远也没有足够的时间去做每一件事，所以我们要做的每一件事都是与时间赛跑。

　　整合分析

　　1、我们的测试有多好？

　　● 综合前面的几个问题，考虑我们现在的测试过程中是否存在紧迫的问题？

　　● 我们的测试流程是否充分，是否能在产品质量未能达到预期目标时对项目管理提出预警？

　　● 是否存在某些潜在类型的问题是不可忍受的，如果有，我们是否有有信心我们的测试流程能发现定位这些问题？

　　2、是否值得改进？

　　● 我们能用什么策略改进测试？

　　● 我们有能力应用这些测试策略吗？我们知道怎样应用吗？

　　● 改进测试会消耗多大？会有多麻烦？是否是利用资源的佳方式？

　　● 能否暂时不改进？能否在一个可接受的时间范围内达到改进？

　　● 改进是否会造成反效果，引入新的bug，对士气造成影响？

　　● 改进会带来明显的不同吗？

　　测试经理不愿意面对“毫无遗漏的测试是不可能的”这一事实的话，他会选择一个不可能完成的测试。

　　Good Enough Testing 的目的是帮助软件测试工程师摆脱测试的条条框框、主观性、被动的局面，把结构化的、合理的方法应用到复杂的、多维的问题集合中去。