软件测试用例设计规范Software Test Case Design Specification
【目录】
1目的 (3)
2范围 (3)
3名词定义 (3)
4工件 .................................................................................................................................... 错误!未定义书签。

4.1 输入 (3)
4.2 输出 (3)
5规范内容 (4)
5.1 设计原则 (4)
5.1.1可执行性 (4)
5.1.2可维护性 (4)
5.1.3可代表性 (4)
5.1.4可判定性 (4)
5.2 必要元素 (5)
5.2.1用例包和用例对象名命 (5)
5.2.2测试目的 (5)
5.2.3测试优先级 (5)
5.2.4测试环境 (5)
5.2.5前提条件 (5)
5.2.6后置关联 (5)
5.2.7用例状态 (5)
5.3 综合策略 (6)
5.3.1必要的边界值分析 (6)
5.3.2必要的等价类划分 (6)
5.3.3必要的因果图方法 (6)
5.3.4必要的性能测试方法 (6)
5.3.5面向对象设计方法 (7)
5.4 设计活动 (7)
5.4.1分析和建立测试用例包 .................................................................................... 错误!未定义书签。

5.4.2分解并建立测试用例对象 ................................................................................ 错误!未定义书签。

5.4.3建立测试用例对象间关系 ................................................................................ 错误!未定义书签。

5.4.4设计测试用例 .................................................................................................... 错误!未定义书签。

5.4.5测试实施 ............................................................................................................ 错误!未定义书签。

5.5 检查点 ........................................................................................................................ 错误!未定义书签。

1目的
本规范的目的是为了测试工作的有理有据有序开展，坚定的贯彻质量原则，保证运行程序的稳定操作，可执行，以及长远来看的可维护，可扩展，在保证软件质量的前提下，提高产品的灵活性。

该规范用于指导测试人员的测试工作，明确测试方法，测试范围，测试交付物基本规范。

2范围
本规范适用于**公司所有科技开发条线之产品测试。

3名词定义
4前置条件
4.1 输入
4.2 输出
5规范内容
5.1 设计原则
5.1.1 可执行性
1）每一个测试用例步骤的输入描述必须是一个，或一组明确的、无需进一步说明的测试操作行为；
2）每一个测试用例步骤的期望结果是由此步骤的一个，或一组输入操作产生的，并且必须具有唯一性。

3）每一个测试用例步骤的输入数据必须在执行测试前完成设计，并且必须满足真实的业务数据要求。

5.1.2 可维护性
1）须使测试用例对象的分解符合高内聚和低耦合的特征。

2）须使测试用例对象每个步骤的结构和描述合理，简洁、清晰。

5.1.3 可代表性
1）能够覆盖系统用例主事件、备选事件及异常事件的处理
2）能够覆盖核心数据和业务规则的有效和无效等价类、边界条件和值输入的校验，这些输入项主要包括但不限于数字信息，以及决定主事件流程操作等重要信息。

3）能够覆盖边界和极限的核心操作和环境设置的处理能力的测试，它们包括用户核心操作的性能和压力的处理能力。

4）测试用例从系统用例中生成，须覆盖软件需求规格说明，而不是业务流程或操作流程。

5.1.4 可判定性
1）测试执行结果的正确性必须是可判定的，每一个测试用例步骤都应有相应的期望结果。

2）每次执行同一个测试用例的测试，测试执行结果应当是相同的。

5.2 必要元素
5.2.1 用例包和用例对象名命
1）测试用例包的命名：
一级包名以测试类型命名，即功能测试、性能测试等；
二级包名，功能测试包下以SYS中的模块名命名，其它测试类型则以实际需求命名，另增加
公共用例包；
三级包名一般存在于功能测试，主要以SYS具体系统用例名称命名。

2）测试用例对象命名，命名前部为编号，后为以下分类的具体名称
5.2.2 测试目的
每个测试用例对象，须详细说明测试对象执行的结果所能覆盖的主要的测试需求目标。

5.2.3 测试优先级
测试优先级以5-urgent、4-very high、3-high、2-medium、1-low划分，每个测试用例对象须根据测试设计和执行的进度和质量要求的重要和紧急程度进行设置。

5.2.4 测试环境
测试计划中描述了整体的测试环境，但若测试用例对象具有特定的测试环境要求，如外部接口、业务数据、信用卡、程序配置、性能测试等，则须详细说明。

5.2.5 前提条件
每个测试用例对象须说明其执行前，系统须存储的数据或状态，测试角色权限，修改代码或程序配置等要求。

5.2.6 后置关联
功能测试类型的测试用例对象，须注明所测试的系统功能变更所引起的其它测试需求相关的测试用例对象名称。

5.2.7 用例状态
1）Design：处于正在设计状态
2）Ready：处于设计任务完成状态
3）Approved：处于设计已经批准状态
4）Repair：处于须修正状态
5.3 综合策略
5.3.1 必要的边界值分析
1）金额的输入或对金额有影响的输入或导入，必须采用边界值或边界条件分析的测试方法；
2）限额的输入或对限额有影响的输入或导入，必须采用边界值或边界条件分析的测试方法；
3）订购、支付、结算有影响的证件和银行卡号的输入或导入，必须采用边界值或边界条件分析的测试方法；
4）业务规则，必须采用边界值或边界条件分析的测试方法来验证执行业务规则的有效性；
5.3.2 必要的等价类划分
1）航班时刻、酒店、线路等资源的查询输入，必须首先设置有效和无效等价类的资源数据来验证查询结果的有效性。

2）业务规则算法，必须首先设置有效和无效等价类的条件数据来验证计算结果的有效性。

3）订购、支付、结算记录的查询或导入，必须首先设置有效和无效等价类的条件数据来验证查询或导入结果的有效性
5.3.3 必要的因果图方法
业务规则中存在组合规则，即输入条件的各种组合决定不同结果，或输入条件之间存在相互制约关系，则采用因果图法是必要的。

5.3.4 必要的性能测试方法
1）若系统的某个事务存在最少时间范围内必须满足最大用户数量访问的需求，则必须对此项事务进行负载测试。

2）若系统的某个事务的系统处理技术复杂或存在不可确定性，则必须对此项事务进行性能测试。

3）若系统的某个事务关系到核心业务的运行和利润，并且须满足多客户端和用户的访问，则必须对此项事务进行压力测试。

5.3.5 面向对象设计方法
所谓面向对象的测试用例设计方法指采用面向对象的基本特征：封装、继承、多态，以进行有效的复用和度量。

1）封装：将一个用例场景的测试用例分解成独立、单一测试职能的测试用例对象，即分解成一个基本流、N个备选流、N个异常流、N个独立业务规则的测试用例对象。

2）继承：抽取各测试用例中共性的测试用例步骤，组成具有独立测试目的的公共测试用例对象，以在其它测试用例对象需要的时候，作为其测试用例步骤的一部分。

在TD中使用call to test来实现。

3）多态：在TD中被call to test的测试用例对象中，通过设置参数，达到输入或验证项名称的虚拟化，当其它测试用例对象调用它时，才输入真实的输入或验证项名称，也可根据需要不输入或少输入。

5.4 设计活动
需基于实际项目补充。

5.5 基于测试用例出具测试报告
可以出统计图，测试用例执行率，一次通过率等。