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-veryhigh、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中使用calltotest来实现。
3）多态：在TD中被calltotest的测试用例对象中，通过设置参数，达到输入或验证项名称的虚拟化，当其它测试用例对象调用它时，才输入真实的输入或验证项名称，也可根据需要不输入或少输入。
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的DesignSteps标签页的“calltotest”按钮或Ctrl+L来选择所需调用的测试用例对象，如图四。
本文内容不用于商业目的，如涉及知识产权问题，请权利人联系51Testing小编(021-64471599-8017)，我们将立即处理
