测试用例是执行测试工作的依据，不仅能有效的保障知识传递和测试的管理；更重要的是能确保测试的系统性和全面性。我们写测试用例就是为了在测试中尽可能多的发现软件存在的问题，尽可能的减少缺陷的遗漏，通过事前预防保障软件的质量。
该规范的目的是为用例设计人员提供测试用例编写的指导，提高编写的测试用例的可读性、合理性，及可执行性。使测试人员可以更好的执行测试，进而提高软件的质量。
1、用例分类
用例计划分为三类：业务流程用例、单功能用例、集成测试用例。
业务流程用例
业务流程用例是为了测试软件是否能完成用户正常的业务处理流程，及对异常业务流程的控制处理是否完善而设计的用例。
此类用例要求覆盖到用户所有可能的业务流程，并且需要尽可能多的设计一些实际中因为误操作或不熟悉业务而出现的异常的业务流程。梳理出流程后，为每个流程编写一个测试用例。一个业务的所有流程构成该业务的流程测试用例文档。
单功能用例
单功能用例针对某一个单独的功能编写，是为了测试功能对正常数据、异常数据、空数据的处理控制存储是否正确而设计的用例。
此类用例是根据等价类划分法、边界值分析法、错误推测法等方法确认出测试数据，进而设计出相对完备的测试用例的过程。此类用例的测试数据要求覆盖正常数据范围、异常数据范围、及空数据；每个单独的功能都要编写一个测试用例。一个页面所有功能构成一个单独的功能测试用例文档。
集成测试用例
集成测试用例是为了测试不同开发组提交的程序之间模块接口及数据传输处理是否正确而设计的测试用例。
此类用例主要用来测试维护数据的模块对被主功能模块使用的数据的维护控制是否正确，同时测试主功能模块对基础模块准备的数据的调用处理是否正确。此类用例要求覆盖所有的调用接口，及所有的基础数据状态。每个需要集成测试的功能单独构成一个集成测试用例文档。
2、用例编写原则
A、功能或流程划分时，一定要简单、清晰，一个测试用例只检查一个功能点或一个流程；否则我们的测试用例会比较混乱，降低了可读性。
B、测试用例要有一个简单直观的名字，有助于读者对测试用例的理解。
C、测试用例的步骤描述要简单、清晰，一步就是一步。比如：第一步，用户登陆；第二步，用户点击“用户信息”；第三步，用户修改姓名为“张&三”；第四步，用户点击保存。这有利于提高用例的可操作性。
D、测试用例的数据要明确，特别是输入数据和期望结果。比如，测试准备数据：用户：张三，李四，王二。在排序后用例的预期结果为：李四，王二，张三。这样，用例在执行时，很清晰，有很高的可操作性，执行者对于执行结果是否正确也非常清楚。
E、测试用例需要保障唯一性，即功能用例之间不存在重叠，流程用例不存在包含关系。没有重复、冗余的测试用例，满足相应的行业标准。
F、描述要清晰、包括特定的场合、对象和术语，没有含糊的概念和一般性的描述。应尽量避免不确定的用词，如：如果、若、否则、大概、可能等。
G、测试用例中需要有充分的异常测试数据，考虑大数据量测试时的数据准备。
H、测试用例应确保覆盖详细设计中的所有功能。单功能用例要覆盖所有数据操作处理的功能点；流程用例要尽可能的覆盖程序的各种路径,考虑存在跨年、跨月的数据，兼顾各种业务变化的可能。
I、对于无输入的操作,应该详细描述其具体的操作步骤和结果.。
J、测试用例需要保障数据的正确性和操作的正确性.首先保证测试用例的数据正确,其次预期的输出结果应该与测试数据发生的业务吻合.操作的预期结果应该与程序发生的结果吻合。
3、用例命名规范
测试用例目前有功能用例和流程用例两种。
功能用例的命名规范为：
项目名称缩写的每个字的第一个字母大写+CSYL+GN+具体功能模块页面的汉字名称。例如产品化系统中每日一题维护模块的功能测试用例命名为：CPH_CSYL_GN_每日一题维护.XLS。
流程用例的命名规范为：
项目名称缩写的每个字的第一个字母大写+CSYL+LC+具体功能流程的汉字名称。例如产品化系统中班前会功能的流程测试用例命名为：CPH_CSYL_LC_班前会.XLS。
集成用例的命名规范为：
项目名称缩写的每个字的第一个字母大写+CSYL+JC+具体功能流程的汉字名称。例如产品化系统中班前会功能的集成测试用例命名为：CPH_CSYL_JC_班前会.XLS。
