V字形测试用例设计理念及框架

一、        V字形测试用例设计理念

Ø      以用户为第一人称，测试人员既是普通用户。

Ø      多层次由浅入深、由简到繁、由主体到细节设计测试用例。

Ø      优先级由高到低设计测试用例，再由低到高完善测试用例。

Ø      层次由主体到细节，优先级由高到低模仿V字形测试流程模型与开发进度进行对应的同步（见模型图）。

Ø      当阶段测试完成后，层次由细节到主体，优先级由低到高对先前设计的用例进行修正、完善。

二、        测试用例框架

Ø      用户场景用例

Ø      系统级用例

Ø      功能点用例

三、        框架具体说明与个人见解

<——用户场景用例——>层次（主体）优先级（高）

1、完全以用户的角度构思，将用户真实的可发生行为反应在测试用例中，描述语言接近真实，追求生动和形象化。

例：模拟用户A在前台培训网站注册、在线购买课程、学习、考试、查询分数等的一连串真实的操作。

2、贯穿整个项目的所有系统，真实反映系统与系统之间的业务交互。

例：模拟用户A前台学习某门课程时发觉该门课程对自己的帮助不大，于是致电客服中心要求换课或者直接退款，客服中心工作人员通过管理平台（后台）对用户提出的要求进行分析和操作。

3、只关心整个流程能否走通，不关心细节（即如何走通或者非正常操作的情况下能否走通）。

构思说明及见解：不必细节化，但是需要覆盖所有用户所需要做的事情，通过一连串用户可能会发生的真实操作来设计用例，保证【用户需求】的基本流程走通，是当测试时间很少的情况下，首先执行的用例。同时，用例的可读性必须简易、直观到让用户都能轻松看懂，也是提交给用户的测试产物之一。

<——系统级用例——>层次（较细化）优先级（普通）

1、只针对整个项目中某个独立的系统，真实反映该系统下的业务操作以及同一个系统下业务与业务之间的关联操作。

例：模拟集体用户A在集体前台网站在线购买课程的业务或者购买后查询订单支付情况和生成学员账号的信息的交互操作，但不去和其它系统进行交互（如：不通过账号登录前台学习课程）。

2、系统级用例是对用户场景用例的补强、逐步细化，开始关心该系统下业务的各种可发生情况（正常流程、分支流程、异常流程）的操作及系统所回馈的反应。

例1（正常流程）：模拟用户A前台注册成功、支付成功、考试通过，检查系统回馈的反应。

例2（分支流程）：模拟用户A前台购买课程时，模拟支付失败，检查系统回馈的反应。

例3（异常流程）：模拟用户A注册，填写完所有的信息，却点击了取消按钮，检查系统回馈的反应

     3、描述语言接近真实，追求生动和形象化，只反映系统的业务逻辑，不细化业务操作。

例：模拟用户A前台注册，只关心注册成功、失败后系统的反应，不关心如何成功或者失败（即不针对注册业务的输入项，如：输入身份证号码错误等）。

构思说明及见解：直接针对【概要设计】 ，是对【需求分析】时所设计的用户场景用例的细化、补强，尽可能模拟业务各种可发生的情况，但不关心具体的细节。用例的描述做到连贯、直观，必须让没有测试过该系统的测试人员也能流畅的执行用例，就像看产品说明书一样，指引测试人员一步步进行操作。

<——功能点用例——>层次（细节）优先级（低）

1、针对系统下所有的模块，模块下的每一个功能点，功能点下的每一个输入项进行各种可能的模拟

例：模拟用户A前台注册，注册页面下的所有输入项都逐一进行各种数据的驱动，输入正常的情况，异常的情况，检查系统的回馈反应。

2、抛弃常规的基本流，备选流、异常流分开编写的用例设计方法，采用将单独功能点所有情况（正常、异常）反映在一条用例（或者最不超过5条，实际证明，完全够了）的方法，以连贯的描述手法进行全局的贯穿，引导测试人员有顺序地由正常情况到非正常情况来执行该功能点的测试用例。

例：假设检测身份证这一输入项，示例只叙述步骤编号和“描述”的内容，不显示预期和实际结果了。

Step n：输入正常且与出生年月对应的身份证号XXXXXX点击下一个输入框。

预期结果：身份证项通过，右边出现绿色的小勾标记。

Step n+1：输入带有非法字符，如@#得身份证号码 点击下一个输入框 预期结果：略。

在检测好非正常情况后继续引导测试用例执行者做下去，则添加步骤

Step n+2：重新恢复输入正常且与出生年月对应的身份证号XXXXXX，点击下一个输入框。

该步骤不需要预期与实际结果了，纯粹是一个引导步骤，或者直接可以在Step n+1步骤的实际结果中最后面直接添加引导句，如：验证后恢复输入正常且与出生年月对应的身份证号XXXXXX，点击下一个输入框。

3、仍然是描述语言接近真实，追求生动和形象化，这样做能够帮助其他同行更轻松的执行你的用例，用例不只是写给自己来执行的！

例：见上述。

构思说明及见解：抛弃了常规的基本流、备选流。。。而采用这种方法，主要的好处在于增加了测试用例对于他人的可执行性，如果采取老办法，一个新接手项目完全不了解这个项目的测试执行这些用例将直接完全无从下手，新方法有产品说明书的功效，引导他人去执行测试用例。还有一个好处就是，同一个功能点就要分那么多条目来，个人感觉非常的眼花，不方便管理！测试用例不是条目数越多越好的，应该精简，可观性强，又不漏掉任何一个细节点！