ST-第3章测试用例设计分析.ppt

软件测试 第3章 测试用例设计 测试那些事儿 测试与开发的比例 与产品大小、复杂度、质量要求相关 目前国内比例平均为1:1.6 2000年MS全球52000人，利润$300亿，10000开发人员，15000测试人员，测试费用占研发费用的60% Exchange2000 程序经理25人；开发人员140人；测试人员350人 Windows2000：$50亿 程序经理250人；开发人员1700人；测试人员3200人 IE4.0 开发时间6个月，测试时间8个月 问题 本章内容 本章内容 什么是测试用例 测试用例要描述什么？ 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 测试用例的维护 测试用例的创建 建立合适的、可扩展的测试用例框架，从而借助这个框架能有效地组织众多的测试用例，包括对测试用例的分类、清晰的层次结构等 实例 测试用例的创建 对于每个模块的测试用例，既可以根据功能细分，也可以根据优先级来设定。测试用例的优先级是由下列3个方面决定的。 测试用例套件（Test Suite） 测试套