Good Enough Testing（恰到好处的测试）

 

Good Enough Testing（恰到好处的测试）

陈能技

2007-8-16

 

原文：A Framework for Good enough testing – James Bach

 

Good Enough Testing 的定义

有些测试员会问：“我怎么知道我的测试做得足够了？”

很遗憾，对于这一样一个问题，没有很客观或严谨的答案。但是我们可以在尝试回答问题前识别出来那些因素应该加以考虑。我们至少可以建立一个围绕这个问题的启发模型。

 

首先，我们来定义一下什么是Good Enough Testing。

Good Enough Testing是形成一个充分的质量评估的过程，这个过程建立在合理的代价之上，用于支持对产品作出明智的、及时的决定。

 

把定义分解成4部分：

产品质量的评估：

产品的正确性和完整性如何？

测试的代价：

测试消耗的合理的程度如何？是否在项目限制范围内？对测试的投入是否有好的回报，例如，每次测试后，是否有额外的信息可提供？

决定：

产品质量的评估是否很好地服务于项目和业务？

及时性：

对评估、决定的及时性，是否足够快，从而发挥作用？

 

有些测试员会被告知他们所做的测试不会影响产品发布的决定。如果是这样的话，测试就应该停止了。

 

相反，如果继续测试会提供技术支持或为公司的某些其它类型的决定提供基础支持，那么就应该继续测试。因为测试与某些要作出的决定联系在一起，或为提供某些数据以备将来使用。

 

某些测试是在组织或某些所谓的权威人士要求下进行的，有些测试仅仅是因为测试计划制定了，所以执行。这与Good Enough Testing的原则是违背的，Good Enough Testing是有意识的、有目的的测试，不是迷信和仪式。其实很多制定的测试计划中提到的测试是可以抛弃的，因为它们对测试项目或对利益相关方完全没有什么影响。

 

很多时候，测试计划的编写是因为某些人说：“教科书上说我们应该有这种测试”。

 

评估的组成

1、 评估产品质量

我们是如何评估和报告产品质量的？

我们是否确定质量的评估是可被证实正确的？

我们是否清楚明示和暗示的产品需求？

我们能在产品创建出来后多快地找到产品中的重要的问题？

我们的测试是否覆盖了需要覆盖的产品的各个方面？

我们是否应用了足够的测试方法类型或采用了足够的关于质量信息的资料来源来消除测试覆盖的误差？

是否在产品中存在我们不知道的重大问题的可能性？

是否存在本应该是测试发现的问题而测试员未发现，而是被其它渠道发现并报告？

 

2、 评估测试代价

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

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

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

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

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

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

 

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

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

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

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

测试报告是否及时递交？

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

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

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

 

4、 是否及时

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

 

整合分析

1、 我们的测试有多好？

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

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

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

 

2、 是否值得改进？

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

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

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

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

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

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

 

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

 

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