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

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

　　例：见上述。

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

版权声明：本文出自yujie6832的51Testing软件测试博客：http://www.51testing.com/?121033

原创作品，转载时请务必以超链接形式标明本文原始出处、作者信息和本声明，否则将追究法律责任。