如何保证测试用例的广度？（10-8-2）（获奖名单已公布）

Jackc

利润是企业的最终追求目标。如果把企业比作创造利润发动机，研发部门就是汽油，测试部门则是润滑油。

所以，测试的最终目标是提高产品质量，降低产品生产成本。而用例设计作为测试中的一环，也就不能跳出这个范围。

几乎所有的测试人员都明白一个简单的道理：测试用例是无穷无尽的……
这也是引入用例设计方法的初始点。使用科学的统计概率方法将无穷无尽的数据整理成具有实际操作意义的专业测试数据。

那么如何合理的分布测试数据，设计出效率更高的用例呢？

大家都玩过扑克吧？其实用例覆盖率策略设计过程和玩扑克是一样的。
（下面以设计测试覆盖率策略为中心的描述，对实际测试用例设计方法描述较少。如需实际用例设计方法，请百度“黑盒用例设计白皮书”和“白盒测试用例设计”）

1、基本能力
玩牌玩的好的人，要求的基本能力就是熟悉玩牌的规则和各种牌组的作用。
而设计用例覆盖策略的测试员，要求的基本也是熟悉测试流程/标准和各种测试资源的属性。

2、确定目标
开始一场新的牌局前，期望值通常是“赢”。
而在开始一轮新的测试前，用例设计的期望值通常是“更有效的覆盖率”。（请仔细思考“更有效”与“更高”的区别）

3、整理资源
当开始牌局，拿到一手牌后，你会直接就开始出牌吗？肯定不会！通常都会先提牌，将各个类型的牌组分类整理。
而在定义用例覆盖率之前，也同样需要先收集整理测试资源：时间、人力、硬/软件……

4、定义策略
提牌结束后，你通常就会思考出牌的策略。怎样将手里不同组合的牌组，以什么方式，什么时间打出去，并期望得到怎么样的结果等等。这就是出牌策略。
而测试用例覆盖率策略也是一样的。参考之前整理的资源清单，根据需求的要求，将手中的测试资源分布到整个测试周期中。
这一过程中，注意根据需求提及的各种优先级，对测试资源作对应调整。需求优先级高的功能或模块，测试资源分配相对较多，反之也然。
而测试用例覆盖率则与资源分布率一致。资源越多的测试点，覆盖率越高。

5、实际用例设计
出牌过程中，拽着手中有限的牌组，挣扎于“普通出牌”（出计划中的牌寻求上手机会）、“过”（时机不对，放弃出牌权）和“押宝”（针对关键的上手机会，出大牌进行赌博）这三者中。

而测试整个过程中，覆盖率也同样在这三种状态中循环。
优先级的低功能，用例覆盖率低，甚至在极端情况下会“放弃”此功能的测试。
优先级高的功能，用例覆盖率很高，极端情况下会将当前阶段的所有测试资源都压在这个功能的测试上。

而控制用例覆盖的最直接手段有两个：测试资源和测试用例
测试资源足够多，即使是Monkey Testing也能达到很好的测试效果。 微软热衷于区域性的用户体验测试正是源于此。
测试用例指导性够强，能有计划的分布测试资源和监控测试过程。

而用例设计目前主要分为白盒和黑盒两类，分别都有很清晰的标准文档，而控制手段其实也就在这些用例设计方法中。有希望深入了解的朋友，可以认真学学概率统计学的内容。
比如黑盒测试中，等价法的等价类分为强/弱等价类，这就是用例覆盖率控制的开关。
而黑盒的其他方法则往往使用等价法和边界值法提供的覆盖率开关，达到控制覆盖率的目的。比如，判定表法在生成判定表后，需要做一次“无效类”用例的删除，而其删除原理与等价法挂钩，变相实现了对覆盖率的控制。

综上，用玩牌的心态对待测试，就能实现测试用例广度的有效性覆盖。也能在有限资源中，最大程度的保证测试用例的广度。

[ 本帖最后由 Jackc 于 2010-8-4 12:00 编辑 ]