验收测试驱动开发实战笔记--验收测试设计（一）（9）

验收测试设计

传统的测试设计的一个case是这样的：

传统测试设计虽然很全面，但存在诸多缺陷：

1.    测试case很详细，导致测设设计文档特别长；

2.    测试case间，测试步骤可能存在大量冗余和重复；

3.    测试case无结构，某些case之间有先后顺序或者依赖，不能直观地表现出来；

4.    编写、评审、阅读和修改这些测试case需要大量时间；

使用这种测试设计，理论上虽然很保险，不容易造成二义性，但现象往往是这样的：RD不按测试设计自测，bug一大堆。

问题：RD为什么不按测试设计自测？

思考：真的是RD太懒？

调研：

a、文档太长，每次评审的时候都要睡着，别说按它自测了；

b、case不清晰，很难一眼看明白；

c、没有时间；

总结：看来，除了客观原因c外，需要从QA自己身上找原因了。

改进：

1、以story为粒度编写测试设计（每个story一个文件）；

特点：每次自测量小，不易烦。

2、以树形结构组织case，story编号和名字为根，依次是功能块、子功能块、功能点。每个从根到叶子节点的路径为一个测试case；

特点：逻辑清晰，RD看起来简单明了。

3、每个case执行时可标记；

特点：不遗漏、不走冤枉路；

先举例说明前面两点：

需求 :

用户输入用户名、密码和验证码，登录系统。
具体执行步骤如下：
步骤一：在浏览器的地址栏中输入地址 http://xxx.xxxx.com，浏览器打开系统的用户登录页面如图所示。用户名称、密码、验证码为空，验证码提示区域自动生成验证码。

步骤二：录入用户名、密码和验证码，点击“登录”按钮，系统按顺序验证用户名、密码和验证码。如果用户名称错位，提示“用户名错误”；如果密码错 误、提示“用户密码错误”；如果验证码错误，提示“验证码错误”。验证错误后保留用户名，其他项目清空。如果验证通过，则登入系统。密码栏采用暗码显示方式。

Case:

试想一下，上面这个case，如果用传统方式来写，case之间的关系很难一眼看明白，会产生很多重复的输入步骤，15个case，大概需要5+页word，而这仅仅是一个登陆。

注意：此测试设计不再只是为自己的测试执行时提供思路，需要完整、细致清晰、无二义性，以保证RD能正确地按照测试设计者的设想来完成代码实现、自动化，以及case的执行，否则存在风险。

弊端：

1.    文字太少，没有具体的输入输出，容易产生二义性；

2.    没有特别精确的输出，通过的标准可能仁者见仁；

但是传统方式写出的case，RD真的愿意一个字一个字地去看么？以上两个问题可以通过不断磨合（尽量按RD舒适的方式写）和必要的沟通（遇到问题及时沟通）来解决。

验收测试驱动开发实战笔记--验收测试设计（一）（9）

原文：http://blog.csdn.net/kaka1121/article/details/19125605