测试用例是执行测试工作的依据，不仅能有效的保障知识传递和测试的管理；更重要的是能确保测试的系统性和全面性。我们写测试用例是为了在测试中尽可能多的发现软件存在的问题，尽可能的减少缺陷的遗漏，通过事前预防保障软件的质量。

　　该规范的目的是为用例设计人员提供测试用例编写的指导，提高编写的测试用例的可读性、合理性，及可执行性。使测试人员可以更好的执行测试，进而提高软件的质量。

　　1、用例分类

　　用例计划分为三类：业务流程用例、单功能用例、集成测试用例。

　　业务流程用例

　　业务流程用例是为了测试软件是否能完成用户正常的业务处理流程，及对异常业务流程的控制处理是否完善而设计的用例。

　　此类用例要求覆盖到用户所有可能的业务流程，并且需要尽可能多的设计一些实际中因为误操作或不熟悉业务而出现的异常的业务流程。梳理出流程后，为每个流程编写一个测试用例。一个业务的所有流程构成该业务的流程测试用例文档。

　　单功能用例

　　单功能用例针对某一个单独的功能编写，是为了测试功能对正常数据、异常数据、空数据的处理控制存储是否正确而设计的用例。

　　此类用例是根据等价类划分法、边界值分析法、错误推测法等方法确认出测试数据，进而设计出相对完备的测试用例的过程。此类用例的测试数据要求覆盖正常数据范围、异常数据范围、及空数据；每个单独的功能都要编写一个测试用例。一个页面所有功能构成一个单独的功能测试用例文档。

　　集成测试用例

　　集成测试用例是为了测试不同开发组提交的程序之间模块接口及数据传输处理是否正确而设计的测试用例。

　　此类用例主要用来测试维护数据的模块对被主功能模块使用的数据的维护控制是否正确，同时测试主功能模块对基础模块准备的数据的调用处理是否正确。此类用例要求覆盖所有的调用接口，及所有的基础数据状态。每个需要集成测试的功能单独构成一个集成测试用例文档。

　　2、用例编写原则

　　A、功能或流程划分时，一定要简单、清晰，一个测试用例只检查一个功能点或一个流程；否则我们的测试用例会比较混乱，降低了可读性。

　　B、测试用例要有一个简单直观的名字，有助于读者对测试用例的理解。

　　C、测试用例的步骤描述要简单、清晰，一步是一步。比如：第一步，用户登陆；第二步，用户点击“用户信息”；第三步，用户修改姓名为“张&三”；第四步，用户点击保存。这有利于提高用例的可操作性。