测试用例设计指导原则之一：完备性 VS 执行高效性

ahhuang

你刚刚接手一个这样的项目：
    左手一份暴简单的需求说明（网站现在要变更整个sorting的缺省方式，让所有来访者（注册的，匿名的，曾来过的，首次来的），只要在此之前没有设置过sorting值，统统都变更为新的缺省sorting方式），右手是一份开发员写的相当详细的技术流程图（查cookie...查DB...查cookie的版本...查DB的时间戳...)。
    一句话，左边是少言寡语的鸡，右边是严谨高深的鸭，在同你讲同一个事儿，你却没法很好的核对两者的每句话。
－－针对这类项目，我们来如何完成一次高性价比的用例测试呢。

在我们通常的设计当中，有两个设计指导思路：
1. 基于需求说明，以客户需求（操作流程）为主线索，展开测试用例的设计。
2. 基于技术流程图，就按照这个流程，展开测试用例的设计。

若简单的采用#1或＃2，都会有问题：
. 前者的问题在于－－设计出来的case也可能太巨了：由于需求说明太简单，导致即使是依据经验进行等价类删剪，分析下来的case也很多。完备性能够保证，但执行很痛苦。
. 后者的问题在于－－有难同当：当QA和开发的思维方式一致时，可能是有漏洞，一块儿掉。另外如何将cookie，db变更之类的转换成具体的实际执行还得另花脑筋。

在实际的实施当中，尤其是对于开发转职QA的人员，会面临的诱惑通常是使用方案2；或者以#2为主，#2和#1交替思考设计cases。而这种思路危害性是比较大的。因为相对于＃1需多劳些力来说，遗漏了某个功能或场景，通常很可能意味这公司的资产的损失（至于自己，可能被点名批评，撤职查办之类的，又或是几个项目下来总是有这类问题，会被老大质疑你的责任心和能力）。

所以，建议按如下方案来糅合两者：
      以#1为主：先以客户需求（操作流程）为线索，case的设计展开以此为基础，先枚举出用户所有可能的使用途径，每个途径或场景，就是一个case。
    而#2，或者说技术流程图在case设计中当承担这样的责任。一是用来删剪合并等价类case，二是拆分演化出一些原以为是整体的case（实现中的一些边界等价类），三是通过设计一定的执行序列，来提高每一次执行的效率（多个cases的结果可以一次性检查掉）

[ 本帖最后由 ahhuang 于 2008-2-28 21:57 编辑 ]

tjj006

在我们通常的设计当中，有两个设计指导思路：
1. 基于需求说明，以客户需求（操作流程）为主线索，展开测试用例的设计。
2. 基于技术流程图，就按照这个流程，展开测试用例的设计。

我们基本都用#1，因为开发不愿意写文档，也没有什么流程图。。。

haohaoxuexi

同意