st-第3章节测试用例设计.pptVIP

软件测试 第3章 测试用例设计 问题 本章内容 本章内容 什么是测试用例 测试用例要描述什么？ Why ——为什么而测？ What ——测什么？ Where ——在哪里测？ When ——什么时候开始测？ Which ——哪些输入数据？ How ——如何操作软件？ 测试用例的元素 本章内容 为什么需要测试用例（1） 如何以最少的人力、资源投入，在最短的时间内完成测试，发现软件系统的缺陷，保证软件的优良品质，则是软件公司探索和追求的目标。 测试用例是测试工作的指导，是软件测试的必须遵守的准则，更是软件测试质量稳定的根本保障。 软件测试是有组织性、步骤性和计划性的，为了能将软件测试的行为转换为可管理的、具体量化的模式，需要创建和维护测试用例 测试用例的作用 重要参考依据 提高测试质量 有效性 复用性 客观性 可评估性和可管理性 知识传递 本章内容 测试用例的质量 3.3.1 测试用例的质量要求 3.3.2 测试用例书写标准 3.3.3 如何设计出高质量的测试用例 3.3.4 测试用例的评审 单个测试用例的质量要求 具有可操作性 具备所需的各项信息 各项信息描述准确、清楚 测试目标针对性强 验证点完备，而且没有太多的验证点 没有太多的操作步骤，例如不超过7步 符合正常业务惯例。 整体测试用例的质量要求 覆盖率。依据特定的测试目标的要求，尽可能覆盖所有的测试范围、功能特性和代码。 易用性。测试用例的设计思路清晰、组织结构层次合理，测试用例操作的连贯性好，使单个模块的测试用例执行顺畅。 易维护性。应该以很少的时间来完成测试测试用例的维护工作，包括添加、修改和删除测试用例。易用性和易读性，也有助于易维护性。 粒度适中。既能覆盖各个特定的场景，保证测试的效率；又能处理好不同数据输入的测试要求，提高测试用例的可维护性。 测试用例书写标准 标志符（Identification） 测试项（Test Items） 测试环境要求 输入标准（Input Criteria） 输出标准（Output Criteria） 测试用例之间的关联 良好测试用例的特征 可以最大程度地找出软件隐藏的缺陷 可以最高效率的找出软件缺陷 可以最大程度地满足测试覆盖要求 既不过分复杂、也不能过分简单 使软件缺陷的表现可以清楚的判定 测试用例包含期望的正确的结果 待查的输出结果或文件必须尽量简单明了 不包含重复的测试用例 测试用例内容清晰、格式一致、分类组织 如何设计出高质量的测试用例 客户需求导向的设计思路 责任到人 灵活的设计方法 测试用例设计不能局限于输入数据 尽量避免含糊的、冗长的或复杂的测试用例 尽量将具有相类似功能的测试用例抽象并归类 测试用例设计步骤 测试用例的评审 分析其设计思路，是否符合业务逻辑、是否符合技术设计的逻辑、是否可以和系统架构、组件等建立起完全的映射关系？ 在局部上，应有重有轻，抓住一些测试的难点、系统的关键点，从不同的角度向测试用例的设计者提问。 在细节上，检查是否遵守测试用例编写的规范或模板，是否漏掉每一元素、每项元素是否描述清楚 检查表，提问 本章内容 3.4 测试用例的组织和使用 3.4.1 测试用例的创建 3.4.2 测试用例套件 3.4.3 测试用例的维护 测试用例的创建 建立合适的、可扩展的测试用例框架，从而借助这个框架能有效地组织众多的测试用例，包括对测试用例的分类、清晰的层次结构等 实例 测试用例套件 测试套件是由一系列测试用例并与之关联的测试环境组合而构成的集合，已满足测试执行的特定要求。通过测试套件，将服务于同一个测试目标、特定阶段性测试目标或某一运行环境下的一系列测试用例有机地组合起来 测试套件应用场合 只是部分功能模块发生了变化，就可以创建由这些改动模块的测试用例构成的测试套件 在修改的模块中，也不需要选择所有的测试用例，针对不同的优先级创建不同的测试套件 测试执行的第一阶段可以创建一个特定平台上的测试套件 有必要为自动化测试、手工测试分别建立测试套件。 还可以建立和测试人员相对应的、不同平台或不同模块的测试套件 回归测试中，可以先运行曾经发现缺陷的测试用例，然后再运行从来没有发现的缺陷的测试用例 测试套件的构成 有效地组织测试用例 测试用例的维护 随着产品版本的不断升级，软件测试用例也需要得到及时维护，有时还需要重构——对测试用例的结构进行调整，包括用例模块的合并和分解，确保每一个测试用例都是有效的 测试用例的维护是一项长期的工作，日积月累，测试用例的质量会得到很大的改善。 Q A Evaluation only. Created with Aspose.Slides for .NET 3.5 Client Profile . Copyright 2004-2011 Aspose