1 目的

本规范的目的是为了明确软件测试用例的设计原则，活动和方法，提高软件测试用例的可读性、可执行、可维护性、覆盖程度、以及测试的灵活性，使软件测试用例真正能够指导测试的实施和执行，并成为评估测试结果的度量基准。

2 规范内容

2.1 设计原则

2.1.1 可执行性

1） 每一个测试用例步骤的输入描述必须是一个，或一组明确的、无需进一步说明的测试操作行为；

2） 每一个测试用例步骤的期望结果是由此步骤的一个，或一组输入操作产生的，并且必须具有唯一性。

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

2.1.2 可维护性

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

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

2.1.3 可代表性

1） 能够覆盖系统用例主事件、备选事件及异常事件的处理

2） 能够覆盖核心数据和业务规则的有效和无效等价类、边界条件和值输入的校验，这些输入项主要包括限额、金额、支付信息，以及决定主事件流程的订单、离港、排班等重要信息。

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

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

2.1.4 可判定性

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

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

2.2 必要元素

2.2.1 用例包和用例对象名命

1） 测试用例包的命名：
一级包名以测试类型命名，即功能测试、性能测试等；
二级包名，功能测试包下以SRS中的模块名命名，其它测试类型则以实际需求命名，另增加
公共用例包；
三级包名一般存在于功能测试，主要以SRS具体系统用例名称命名。
2） 测试用例对象命名，命名前部为编号，后为以下分类的具体名称：
仅对功能测试类型的测试用例进行分类，它们是迭代用例、基本流用例、备选流用例、异常
流用例、规则用例和公共用例；
一个测试项目下编号必须唯一，编号长度5位；
功能测试用例编号首位用F表示，第2位分别用I、M、O、E、R和P表示上述不同分类，第
3至5位为序号，从001开始；
性能测试用例编号首位用P表示，第2位分别用P、L、S表示性能测试、负载测试、压力测
试，第3至5位为序号，从001开始；
功能测试用例名命举例：
基本流用例：FM001基本流，或FM001+系统用例名称+“基本流”
备选流用例：FO001+备选流名称+“备选流”
异常流用例：FE001+异常流名称+“异常流”
规则用例： FR001+规则名称+“规则”
公共用例： FP001+公共用例名称
迭代用例： FI001+迭代说明

2.2.2 测试目的

每个测试用例对象，须详细说明测试对象执行的结果所能覆盖的主要的测试需求目标。

2.2.3 测试优先级

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

2.2.4 测试环境

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

2.2.5 前提条件

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

2.2.6 后置关联

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

2.2.7 用例状态

1） Design：处于正在设计状态
2） Ready：处于设计任务完成状态
3） Approved：处于设计已经批准状态
4） Repair：处于须修正状态

2.3 综合策略

2.3.1 必要的边界值分析

1） 金额的输入或对金额有影响的输入或导入，必须采用边界值或边界条件分析的测试方法；

2） 限额的输入或对限额有影响的输入或导入，必须采用边界值或边界条件分析的测试方法；

3） 订购、支付、结算有影响的证件和银行卡号的输入或导入，必须采用边界值或边界条件分析的测试方法；

4） 业务规则，必须采用边界值或边界条件分析的测试方法来验证执行业务规则的有效性；

2.3.2 必要的等价类划分

1） 航班时刻、酒店、线路等资源的查询输入，必须首先设置有效和无效等价类的资源数据来验证查询结果的有效性。
2） 业务规则算法，必须首先设置有效和无效等价类的条件数据来验证计算结果的有效性。

3） 订购、支付、结算记录的查询或导入，必须首先设置有效和无效等价类的条件数据来验证查询或导入结果的有效性

2.3.3 必要的因果图方法

业务规则中存在组合规则，即输入条件的各种组合决定不同结果，或输入条件之间存在相互制约关系，则采用因果图法是必要的。

2.3.4 必要的性能测试方法

1） 若系统的某个事务存在最少时间范围内必须满足最大用户数量访问的需求，则必须对此项事务进行负载测试。
2） 若系统的某个事务的系统处理技术复杂或存在不可确定性，则必须对此项事务进行性能测试。

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

2.3.5 面向对象设计方法

所谓面向对象的测试用例设计方法指采用面向对象的基本特征：封装、继承、多态，以进行有效的复用和度量。
1） 封装：将一个用例场景的测试用例分解成独立、单一测试职能的测试用例对象，即分解成一个基本流、N个备选流、N个异常流、N个独立业务规则的测试用例对象。
2） 继承：抽取各测试用例中共性的测试用例步骤，组成具有独立测试目的的公共测试用例对象，以在其它测试用例对象需要的时候，作为其测试用例步骤的一部分。在TD中使用call to test来实现。
3） 多态：在TD中被call to test的测试用例对象中，通过设置参数，达到输入或验证项名称的虚拟化，当其它测试用例对象调用它时，才输入真实的输入或验证项名称，也可根据需要不输入或少输入。

2.4 设计活动

2.4.1 分析和建立测试用例包

1） 根据5.1.3的第4）条、5.2.1的第1）条，建立图一左侧的测试用例包；

2） 在功能测试包的Attachments中，插入测试用例编号记录表，用于登记测试用例编号的使用，每次修改测试用例编号记录文件保存后，须点击Upload更新到TD服务器，如图二。

图一
图二

2.4.2 分解并建立测试用例对象

1） 根据5.1.2的第1）条、5.1.3、5.2.1的第2）条、5.3.4、5.3.5的第1）和第2）条进行分解并建立测试用例对象，应首先分解公共用例，这些公共用例一般包含的测试项如：标题、标签内容、风格布局、控件功能、静态控件数据、动态控件数据、必填项等，然后依次分解基本流、备选流、异常流和规则用例。
2） 在TD中新增测试用例对象时，系统会在Description中自动生成测试目的、测试环境、前提条件和后置管理的输入要求，须根据5.2.2至5.2.7的要求在TD中进行设置，如图三。

图三

2.4.3 建立测试用例对象间关系

1） 根据5.1.2和5.3.5 ，公共用例、基本流用例、备选流用例、异常流用例、规则用例和迭代用例之间存在调用和被调用关系。一般情况下，基本流用例应该并且只能调用公共用例和规则用例；备选流和异常流用例可能并且只能调用公共用例和规则用例；迭代用例应该并且只能调用基本流、备选流和异常流用例；公共用例和规则用例只能被调用。
2） 测试用例对象的每个测试用例步骤，均可通过TD的Design Steps标签页的“call to test”按钮或Ctrl+L来选择所需调用的测试用例对象，如图四。

图四

2.4.4 设计测试用例

1） 须严格遵守5.1.1的第1）和第2）条，确保每个测试用例步骤是可执行的。
2） 须严格遵守5.1.4 ，确保测试结果的正确性是可判定的，再现的。
3） 如果仅在测试用例对象内出现的同类性质的各输入项或界面的测试，如各标签内容、各项风格布局、各控件功能、各必填项等的测试输入和期望结果，应合并成一条测试用例步骤。
4） 在设计测试用例时，仍可发现其它测试用例对象中存在同类性质的测试项，如session检查、数据保存验证等，应将这些测试用例步骤抽取到公共用例中。
5） 公共用例中测试输入或期望结果中的输入项和验证项（显示的控件、数据库表和字段）名称必须以参数变量保存，而不是直接输入某个名称，这是因为调用公共用例的各对象的实际输入项和验证项名称是不同的，参数变量的名称以输入项和验证项的特性命名。如需要检查在某个数据表中检查符合某个条件的某个字段数据是否与页面显示的相同，测试输入则应该这样编写：
“1在xxx页面中输入查询条件<<<condition_name>>>，选择查询；2使用sql查询语句：select
<<<vfield_name>>> from <<<table_name>>> where <<<cfield_name>>>=<<<condition_name>>>”
，<<< >>>是TD申明参数变量的命名符，括号内的字符便成为该测试用例对象的私有参数变量。
公共用例参数变量的设置应涵盖所有调用者对象需要的变量，是“与”的概念。为保持软件一贯
的命名习惯及可读性，参数变量名不应使用中文字符。
6） 当公共用例设置了参数表量，调用其的用例对象所对应的测试用例步骤中，Call<公共用例名>后会自动增加“with the following parameters:参数变量名=?”。鼠标移至此step，通过点击右键，弹出选择菜单，如图五，选择called test parameters后，可通过TD弹出的输入框，如图六，输入调用者对象实际的输入项或验证项的名称。调用者对象不需要的公共用例参数变量，可以不输，这体现了调用者对象输入项或验证项、及其数量的虚拟化，即体现了5.3.5第3）条的多态特征。
7） 根据5.1.3的第2）条，及5.3.1和5.3.2，应该增加与之相关边界条件或值、无效等价类的测试用例步骤。
8） 根据5.3.3，使用因果图法生成决策表，决策表的每个规则就是一个测试用例步骤，这类的一组规则应该生成独立的规则用例。
9） 在设计备选流用例对象时，起始步骤的测试输入中，应首先说明由哪个基本流用例的Step Name触发的，我们可以规范为：“在基本流step 9中输入无效的用户名或密码，系统显示登录信息错误的提示。”
10）根据5.1.3第3）条、及5.3.4，设计性能测试、负载测试和压力测试的测试用例。

图五

图六

2.4.5 测试实施

1） 设计执行测试的流程：
建立测试执行包：如图七，左侧一级包按测试类型命名，二级包根据迭代计划，或集成构建计划的版本命名，三级包按SRS中的模块命名，也可按业务流程命名；
建立测试布置（test set）：三级包下建立test set，它可以是一组覆盖一个系统用例的测试用例对象，也可以是一组覆盖一个业务流程的测试用例对象。将图七右侧一组相关测试用例对象拖至test set的execution flow标签页中，全选右键弹出图七所示的菜单，选择Arrange tests sequentially后，TD弹出如图八的Order tests,在Order tests框中，通过上下按钮选择测试执行的顺序。
2） 设计测试数据：
建立测试数据文件：建立如图九的Excel文件，用于保存测试用例对象的测试数据，必须并且仅在每个基本流用例、备选流用例、异常流用例中保存各自的测试数据。每条测试数据必须注明步骤编号，由于上述三种测试用例对象可能Call公共用例和规则用例，因此该步骤编号必须是执行的测试用例对象编号加其测试用例步骤编号，如图九左上侧所示；
上传测试数据文件：在基本流、备选流和异常流测试用例对象的Attachments标签页中，将属于各自的测试数据文件上传到TD服务器，如图十。修改时，需打开修改，保存后选择该Attachments标签页中的upload进行更新。

图七

图八

图九

图十