1、 目的
统一测试用例编写的规范，为测试设计人员提供测试用例编写的指导，提高编写的测试用例的可读性，可执行性、合理性。为测试执行人员更好执行测
试，提高测试效率，最终提高公司整个产品的质量。
2、 范围
适用于集成测试用例和系统测试用例的编写，现在编写用例的辅助工具为TestDirector 8.0。
3、 术语解释
集成测试：
集成测试是在软件系统集成过程中所进行的测试，其主要目的是检查软件单位之间的接口是否正确。
系统测试 ：
系统测试是对已经集成好的软件系统进行彻底的测试，以验证软件系统的正确性和性能等满足其规约所指定的要求，检查软件的行为和输出是否正确并
非一项简单的任务，它被称为测试的“先知者问题”。
4、 测试用例原则
4.1 系统性
1. 对于系统业务流程要能够完整说明整个系统的业务需求、系统由几个子系统组成以及它们之间的关系；
2. 对于模块业务流程要能够说明清楚子系统内部功能、重要功能点以及它们之间的关系；
4.2 连贯性
1. 对于系统业务流程来说，各个子系统之间是如何连接在一起，如果需要接口，各个子系统之间是否有正确的接口；如果是依靠页面链接，页面链接
是否正确；
2. 对于模块业务流程来说，同级模块以及上下级模块是如何构成一个子系统，其内部功能接口是否连贯；
4.3 全面性
1. 应尽可能覆盖程序的各种路径
2. 应尽可能覆盖系统的各个业务
3. 应考虑存在跨年、跨月的数据
4. 大量数据并发测试的准备
4.4 正确性
1. 输入界面后的数据应与测试文档所记录的数据一致
2. 预期结果应与测试数据发生的业务吻合
4.5 符合正常业务惯例
1. 测试数据应符合用户实际工作业务流程
2. 兼顾各种业务变化的可能
3. 要符合当前业务行业法律，法规。
4.6 仿真性
人名、地名、电话号码等应具有模拟功能，符合一般的命名惯例；不允许出现与知名人士、小说中人物名等雷同情况。
4.7 可操作性
测试用例中应写清测试的操作步骤，不同的操作步骤相对应的操作结果。
5、 测试用例主要元素
标准规范中包含的主要元素如下：
测试名称(Test Name)：测试用例编号和测试用例名称。
创建日期(Creation Date)：测试用例创建时间，系统自动产生。
设计人员(Designer)：测试用例设计人员
状态(Status)：测试用例状态
描述（Descrīption）：测试用例详细描述
步骤名称（Step Name）：测试步骤名称
步骤描述（Step Descrīption）：测试步骤详细描述。
预期结果（Expected Result）：测试预期结果。
6、 测试用例编写规范
1. 对于每个功能，从类型1至类型N依次撰写相应用例
2. 对于不满足要求的非常规类型，可以不写相应的用例
3. 对于边界、空值、格式错误、溢出这几个类型，一个功能如有多个数据项测试类型相同，则可以放在一个用例里
4. 测试用例均为最小的用例覆盖要求；对于没有提及的用例类型，视业务需求情况，撰写相应用例
5. 在测试过程中，输入数据可在测试用例规定的范围内做一定变化
6.1 常规的测试用例：
1. 对于一个功能一个模块（页面），每个数据项输入或选中典型的取值，生成一个用例
2. 对于一个功能多个模块（页面），多个模块（页面）一起生成一个用例
3. 对于多个功能一个模块（页面），每个功能生成一个用例
4. 每个功能操作需覆盖，如删除对话框点击确定、取消分别生成2个用例步骤。
5. 输入框测试，在允许范围内尽可能覆盖多的字符类别，如中文、英文、数字等
6. 对于每个功能点，必须通过一组（一个或多个）用例满足其业务覆盖：对于某条记录的每个状态，对于能进行的每个操作，都生成一个用例（即对
业务功能流程中的每个角色，每个功能操作，生成一个用例）
6.2 初始化的测试用例：
进入功能模块（页面）后，某些控件会初始化填入数据，生成一个用例确保所有的初始数据正确
文章来源于领测软件测试网 https://www.ltesting.net/