ch1测试用例设计-stmt.ppt

Zhu.Kerry@ Kerry Zhu 软件测试方法和技术 第2版第14章 测试用例的设计 本章要解决的问题 Zhu.Kerry@ 为什么我们要使用测试用例? 测试用例有哪些基本元素组成? 测试用例编写和设计时需要遵循哪些基本的原则? 白盒测试用例和黑盒测试用例设计的基本方法 测试用例设计，组织和测试过程组织之间的关系和实践过程。 跟踪和维护测试用例。 第14章 软件测试用例的设计 Zhu.Kerry@ 14.1 测试用例构成及其设计 14.2 测试用例的组织和跟踪 14.1 测试用例构成及其设计 Zhu.Kerry@ 14.1.1 测试用例的重要性 14.1.2 测试用例设计书写标准 14.1.3 测试用例设计考虑因素 14.1.4 测试用例设计的基本原则 什么是测试用例 测试用例可以独立进行测试执行的最小单元 测试内容的一系列情景和每个情景中必须依靠输入和输出，而对软件的正确性进行判断的测试文档，称为测试用例 测试用例就是将 软件测试的行为活 动转化为规范化 的文档 Zhu.Kerry@ 测试用例的元素 14.1.1 测试用例的重要性 如何以最少的人力、资源投入，在最短的时间内完成测试，发现软件系统的缺陷，保证软件的优良品质，则是软件公司探索和追求的目标。 软件测试是有组织性、步骤性和计划性的，为了能将软件测试的行为转换为可管理的、具体量化的模式，需要创建和维护测试用例 测试用例是测试工作的指导，是软件测试的必须遵守的准则，更是软件测试质量稳定的根本保障 Zhu.Kerry@ 测试用例的作用 有效性 可复用性 易组织性 客观性 可评估性和可管理性 知识传递 重要参考依据， 提高测试质量 14.1.2 测试用例设计书写标准 标志符（Identification） 测试项（Test Items） 测试环境要求 输入标准（Input Criteria） 输出标准（Output Criteria） 测试用例之间的关联 示例 良好测试用例的特征 可以最大程度地找出软件隐藏的缺陷 可以最高效率的找出软件缺陷 可以最大程度地满足测试覆盖要求 既不过分复杂、也不能过分简单 使软件缺陷的表现可以清楚的判定 测试用例包含期望的正确的结果 待查的输出结果或文件必须尽量简单明了 不包含重复的测试用例 测试用例内容清晰、格式一致、分类组织 Zhu.Kerry@ 14.1.3 测试用例设计考虑因素 Zhu.Kerry@ 具有代表性、典型性 寻求系统设计、功能设计的弱点 测试用例需要考虑到正确的输入，也需要考虑错误的或者异常的输入，以及需要分析怎样使得这样的错误或者异常能够发生 考虑用户实际的诸多使用场景 示例 Zhu.Kerry@ 示例1：P.313 示例2: P.315 14.1.4 测试用例设计的基本原则 Zhu.Kerry@ 尽量避免含糊的测试用例 尽量将具有相类似功能的测试用例抽象并归类 尽量避免冗长和复杂的测试用例 单个测试用例的质量要求 具有可操作性 具备所需的各项信息 各项信息描述准确、清楚 测试目标针对性强 验证点完备，而且没有太多的验证点 没有太多的操作步骤，例如不超过7步 符合正常业务惯例。 整体测试用例的质量要求 覆盖率。依据特定的测试目标的要求，尽可能覆盖所有的测试范围、功能特性和代码。 易用性。测试用例的设计思路清晰、组织结构层次合理，测试用例操作的连贯性好，使单个模块的测试用例执行顺畅。 易维护性。应该以很少的时间来完成测试测试用例的维护工作，包括添加、修改和删除测试用例。易用性和易读性，也有助于易维护性。 粒度适中。既能覆盖各个特定的场景，保证测试的效率；又能处理好不同数据输入的测试要求，提高测试用例的可维护性。 14.2 测试用例组织和维护 Zhu.Kerry@ 14.2.1 测试用例的属性 14.2.2 测试套件及其构成方法 14.2.3 跟踪测试用例 14.2.4 维护测试用例 14.2.5 测试用例的覆盖率 14.2.1 测试用例的属性 Zhu.Kerry@ 一些属性说明 Zhu.Kerry@ 目标性，包括功能性、性能、容错性、数据迁移等各方面的测试用例； 所属的范围，属于哪一个组件或模块 关联性，和软件产品特性相联系 阶段性，属于单元测试、集成测试、系统测试、验收测试中的某一个阶段 时效性，不同的版本所适用的测试用例可能不相同 14.2.2 测试套件及其构成方法 建立合适的、可扩展的测试用例框架，从而借助这个框架能有效地组织众多的测试用例，包括对测试用例的分类、清晰的层次结构等 实例 测试用例套件 测试套件是由一系列测试用例并与之关联的测试环境组合而构成的集合，已满足测试执行的特定要求。通过测试套件，将服务于同一个测试目标、特定阶段性测