软件测试用例设计规范.docVIP

软件测试用例设计规范 Software Test Case Design Specification 文件状态： [ ] 草稿 [√] 正式发布 [ ] 正在修改 文件编号： 当前版本： A1 编制 审核 批准 生效日期 老三 老三  版本历史 版本/版次 作者 参与者 日期 摘要 A1 老三 老三 新颁布 版权信息 本文件内容由XX集团信息技术部负责解释 本文件的版权属于XX集团 任何形式的散发都必须先得到XX集团信息技术部的许可 http://www.XXXXX.com/  【目录】 TOC \o 1-3 \h \z 1 目的 4 2 范围 4 3 名词定义 4 4 工件 4 4.1 输入 4 4.2 输出 5 5 规范内容 5 5.1 设计原则 5 5.1.1 可执行性 5 5.1.2 可维护性 5 5.1.3 可代表性 5 5.1.4 可判定性 6 5.2 必要元素 6 5.2.1 用例包和用例对象名命 6 5.2.2 测试目的 6 5.2.3 测试优先级 6 5.2.4 测试环境 7 5.2.5 前提条件 7 5.2.6 后置关联 7 5.2.7 用例状态 7 5.3 综合策略 7 5.3.1 必要的边界值分析 7 5.3.2 必要的等价类划分 7 5.3.3 必要的因果图方法 8 5.3.4 必要的性能测试方法 8 5.3.5 面向对象设计方法 8 5.4 设计活动 8 5.4.1 分析和建立测试用例包 8 5.4.2 分解并建立测试用例对象 10 5.4.3 建立测试用例对象间关系 10 5.4.4 设计测试用例 11 5.4.5 测试实施 13 5.5 检查点 16 目的 本规范的目的是为了明确软件测试用例的设计原则，活动和方法，提高软件测试用例的可读性、可执行、可维护性、覆盖程度、以及测试的灵活性，使软件测试用例真正能够指导测试的实施和执行，并成为评估测试结果的度量基准。 范围 本规范适用于春秋信息技术部所有软件开发项目和产品集成测试和系统测试用例的设计。 名词定义 术语和缩写 解释 备注 TD 测试管理工具Testdirector的缩写 测试用例对象 具有特定测试目的、独立的、低耦合的一组测试操作和预期结果，它具有面向对象的基本特征。 迭代用例 指系统某次迭代或构建时，对某个系统用例功能的测试覆盖，它包含基本流用例，部分的备选流、异常流和规则用例。 工件 输入 工件名称 备注 软件需求规格说明 通过评审并确认。 概要设计 通过评审并确认。 输出 工件名称 备注 测试用例 保存在Testdirector相关项目的Test Plan中。 规范内容 设计原则 可执行性 每一个测试用例步骤的输入描述必须是一个，或一组明确的、无需进一步说明的测试操作行为； 每一个测试用例步骤的期望结果是由此步骤的一个，或一组输入操作产生的，并且必须具有唯一性。 每一个测试用例步骤的输入数据必须在执行测试前完成设计，并且必须满足真实的业务数据要求。 可维护性 须使测试用例对象的分解符合高内聚和低耦合的特征。 须使测试用例对象每个步骤的结构和描述合理，简洁、清晰。 可代表性 能够覆盖系统用例主事件、备选事件及异常事件的处理 能够覆盖核心数据和业务规则的有效和无效等价类、边界条件和值输入的校验，这些输入项主要包括限额、金额、支付信息，以及决定主事件流程的订单、离港、排班等重要信息。 能够覆盖边界和极限的核心操作和环境设置的处理能力的测试，它们包括用户核心操作的性能和压力的处理能力。 测试用例从系统用例中生成，须覆盖软件需求规格说明，而不是业务流程或操作流程。 可判定性 测试执行结果的正确性必须是可判定的，每一个测试用例步骤都应有相应的期望结果。 每次执行同一个测试用例的测试，测试执行结果应当是相同的。 必要元素 用例包和用例对象名命 测试用例包的命名： 一级包名以测试类型命名，即功能测试、性能测试等； 二级包名，功能测试包下以SRS中的模块名命名，其它测试类型则以实际需求命名，另增加 公共用例包； 三级包名一般存在于功能测试，主要以SRS具体系统用例名称命名。 测试用例对象命名，命名前部为编号，后为以下分类的具体名称： 仅对功能测试类型的测试用例进行分类，它们是迭代用例、基本流用例、备选流用例、异常 流用例、规则用例和公共用例； 一个测试项目下编号必须唯一，编号长度5位； 功能测试用例编号首位用F表示，第2位分别用I、M、O、E、R和P表示上述不同分类，第 3至5位为序号，从001开始； 性能测试用例编号首位用P表示，第2位分别