软件测试的基本知识.ppt

第 2 章 软件测试的基本知识 2.1 软件测试贯穿于整个的软件开发生命周期 2.2 测 试 模 型 2.3 软件测试的分类 2.4 软件测试的原则 2.5 软 件 测 试 策 略 2.6 软 件 测 试 流 程 2.7 测试的成功经验 2.1 软件测试贯穿于整个的软 件开发生命周期 2.1.1 软件测试中使用的各种术语 软件错误 软件缺陷 软件故障 软件失效 2.1.2 软件测试贯穿于整个的软件 开发生命周期 20世纪70年代中期以来，形成了软件开 发生命周期的概念。 测试工作应该着眼于整个软件开发生命 周期，特别是着眼于编码以前各开发阶段的 工作来保证软件的质量。也就是说，测试应 该从软件开发生命周期的第一个阶段开始， 并贯穿于整个的软件开发生命周期。 谈到测试，首先是为什么要进行测试 的问题。所有的测试都是为了发现和消除 软件的缺陷。 明确为什么要进行软件测试的问题之 后，就需要明确测试什么的问题。 软件的开发有其自己的生命周期，在 整个软件生命周期中，软件都有各自的相 对于各生命周期的阶段性的输出结果，其 中也包括需求分析、概要设计、详细设计 及程序编码等各阶段所产生的文档，包括 需求规格说明、概要设计规格说明、详细 设计规格说明以及源程序，而所有这些输 出结果都应成为被测试的对象。 随着人们对软件工程化的重视以及软 件规模的日益扩大，软件分析、设计的作 用越来越突出，而且有资料表明，60%以 上的软件错误并不是程序错误，而是分析 和设计错误。因此，做好软件需求和设计 阶段的测试工作就显得非常重要。这就是 传统的测试概念的扩大化，从而提出了软 件全生命周期测试的概念。 测试过程包括了软件开发生命周期的 每个阶段。在需求阶段，重点要确认需求 定义是否符合用户的需要；在设计和编程 阶段，重点要确定设计和编程是否符合需 求定义；在测试和安装阶段，重点是审查 系统执行是否符合系统规格说明；在维护 阶段，要重新测试系统，以确定更改的部 分和没有更改的部分是否都正常工作。 2.1.3 软件测试的手段 1验证和确认 通常在测试中，使用验证来检查中间可 交付的结果，使用确认来评估可执行代码 的性能。一般来说，验证回答这样的问题 ：“是否建立了正确的系统？”，而确认回 答的问题是：“建立的系统是否正确？”。 所谓验证，是指如何决定软件开发的每 个阶段、每个步骤的产品是否正确无误， 并与其前面的开发阶段和开发步骤的产品 相一致。验证工作意味着在软件开发过程 中开展一系列活动，旨在确保软件能够正 确无误地实现软件的需求。 所谓确认，是指如何决定最后的软件 产品是否正确无误。 2功能和结构测试 当测试人员测试项目小组的解决方案 时，将利用验证和确认技术完成功能和结 构测试。功能测试通常也被称为黑盒测试 ，因为测试案例中都不涉及系统的内部逻 辑。 相反，结构测试通常被称为白盒测试 ，因为系统的内部逻辑常被用于假想的测 试案例。结构测试主要使用验证技术。 如上所述，测试人员用验证技术，通 过评审系统的结构和逻辑来确认系统的合 理性。而确认要严格应用于物理测试，来 确定是否产生了预期的结果。执行结构测 试将主要使用验证技术，而执行功能测试 则主要使用确认技术。 2.2 测 试 模 型 就像软件开发有过程模型一样，测试 也有测试模型。 描述以上测试过程的就是测试模型。 最具有代表意义的测试模型称为V模型 。V模型如图2-1所示。 图2-1 V模型示意图 在开发过程中，从需求阶段到编码阶段， 主要是采用验证手段进行测试，如需求评审 、设计评审、代码走查以及代码审查等，从 而完成对开发的中间结果的正确性的评估。 编码完成并经过代码审查等测试之后，此时 的测试主要在软件的可执行模式下进行，即 利用确认手段进行测试，确认测试包括单元 测试、集成测试、系统测试以及用户验收测 试等，其相应的关系如图2-2所示。 图2-2 V模型中的测试 2.3 软件测试的分类 按照不同的分类方法，软件测试可分 为以下几种类型。 1按照开发阶段划分 按照开发阶段划分，软件测试可分为单元 测试、集成测试、系统测试和验收测试。 2按照测试实施组织划分 按照测试实施组织划分，软件测试可分 为开发方测试、用户测试（测试）和第三 方测试。 3按照测试技术划分 按照测试技术划分，软件测试可分为 白盒测试和黑盒测试，也可分为静态测试 和动态测试。 2.4 软件测试的原则 软件测试的原则尚没有标准的说法， 大多是经验之谈，一般有下面几条可作为 测试的基本原则。 （1）所有的测试都应追溯到用户需求。 （2）应当把“尽早地和不断地进行软件测 试”作为软件测试者的座右铭。 （3）设计时应完成测试计划，详细的测试 用例定义可在设计模型确定后开始，测试可 在代码产生之前进行计划和设计。 （4）pareto原则：测试发现的错误中80%很 可能起源于20%的模块中。应孤立这些疑点 模块，进行重点测试。 （5）完全测试是不可能的，测试需要终止 。 （6）应由独立的第三方来构造测试。 （7）充分注意测试中的群集现象。 （8）要尽量避免测试的随意性。 （9）兼顾合理的输入和不合理的输入数据。 （10）程序修改后要回归测试 （11）应长期保留测试用例，直至系统废弃。 2.5 软 件 测 试 策 略 软件测试策略描述软件测试活动的总 体方法和目标。 为了检验开发的软件能否符合规格说明 书的要求，测试活动可以采用各种不同的 策略。这些策略的区别在于它们表明了不 同的出发点、不同的思路以及采用不同的 手段和方法。具体地说，包括要使用的测 试技术和工具；测试完成标准；影响资源 分配的特殊考虑等。 通常，制定软件测试策略要考虑如下的内容。 （1）要使用的测试方法。 （2）确定质量风险。 （3）测试完成和测试成功所采用的评价标准。 （4）有关资源要求或涉及进度的特殊考虑。 （5）测试类型、评估标准以及测试方法。 （6）确定资源。 在软件测试策略所包含的内容中最主要 的部分有两个，一是要进行的测试过程， 另外一个就是要执行的测试类型。 1测试过程 共分为以下4个过程。 单元测试 集成测试 系统测试 验收测试 2测试类型 对于测试类型的说法多种多样，最多的 能有30多种测试类型。而实际工作中很多 测试是互相包含的。按照企业中实际工作 需要，测试主要包含下面的类型。 功能测试 健壮性测试 接口测试 强度测试 压力测试 性能测试 用户界面测试 安全测试 可靠性测试 安装/反安装测试 11.文档测试 12.恢复测试 13.兼容性测试 14.测试 15.测试 2.6 软 件 测 试 流 程 软件测试工作必须要通过制定测试计划 、设计测试、实施测试、执行测试、评估 测试几个阶段来完成。其流程如图2-4所示 。 图2-4 软件测试流程 2.6.1 制定测试计划 测试计划是对每个产品，或是对各个 开发阶段的产品开展测试的策略。 计划的目的是用来识别任务、分析风险 、规划资源和确定进度。计划并不是一张 时间进度表，而是一个动态的过程，最终 以系列文档的形式确定下来。拟定软件测 试计划需要测试项目管理人员的积极参与 ，这是因为主项目计划已经确定了整体项 目的一个时间框架，软件测试作为阶段工 作必须服从计划和资源上的约定。 一般来说，一个完整的测试计划应该包 含以下几个方面。 （1）对测试范围（即测试活动需 要覆盖的范围）的界定 （2）风险的确定 （3）资源的规划 （4）时间表的制定 2.6.2 设计测试 设计测试阶段要设计测试用例和测试过 程，要保证测试用例完全覆盖测试需求。 设计测试阶段最重要的是如何将测试需求 分解，如何设计测试用例。 1如何对测试需求进行分解 对测试需求进行分解需要反复检查并理 解各种信息，和用户交流，理解他们的要 求。可以按照以下步骤执行。 （1）确定软件提供的主要任务。 （2）对每个任务，确定完成该任务所要进 行的工作。 （3）确定从数据库信息引出的计算结果。 （4）对于对时间有要求的交易，确定 所要的时间和条件。 （5）确定会产生重大意外的压力测试 ，包括内存、硬盘空间、高的交易率。 （6）确定应用需要处理的数据量。 （7）确定需要的软件和硬件配置。 （8）确定其他与应用软件没有直接关 系的商业交易。 （9）确定安装过程。 （10）确定没有隐含在功能测试中的用 户界面要求。 2如何设计测试用例 测试用例一般指对一项特定的软件产品 进行测试任务的描述，体现测试方案、方 法、技术和策略。值得提出的是，测试数 据都是从数量极大的可用测试数据中精心 挑选出具有代表性或特殊性的。测试用例 是软件测试系统化、工程化的产物，而测 试用例的设计一直是软件测试工作的重点 和难点。 设计测试用例即设计针对特定功能或 组合功能的测试方案，并编写成文档。测 试用例应该体现软件工程的思想和原则。 传统的测试用例文档编写有两种方式。 一种是填写操作步骤列表：将在软件上 进行的操作步骤一步一步详细记录下来， 包括所有被操作的项目和相应的值。 另一种是填写测试矩阵：将被操作项作 为矩阵中的一个字段，而矩阵中的一条条 记录，则是这些字段的值。 评价测试用例的好坏有以下两个标准。 是否可以发现尚未发现的软件缺陷？ 是否可以覆盖全部的测试需求？ 2.6.3 实施测试 实施测试是指准备测试环境、获得测试 数据、开发测试规程，以及为该过程挑选 和准备辅助测试工具的过程。 1准备测试环境 （1）测试技术准备 （2）配置软件、硬件环境 （3）人员 2获得测试数据 需要测试的常见情形如下。 （1）正常事务的测试 （2）使用无效数据的测试 创建测试数据时主要考虑如下步骤。 识别测试资源 识别测试情形 排序测试情形 确定正确的处理结果 创建测试事务 确定实际的测试数据时，必须说明处理 测试数据的以下4个属性。 （1）深度 （2）宽度 （3）范围 （4）结构 3测试脚本概要 所谓脚本，是完整的一系列相关终端的 活动。一般测试脚本有5个级别，分别是： 单元脚本，用于测试特定单元/模块的脚本 ；并发脚本，用于当两个或多个用户同时 访问同一文件时测试的脚本；集成脚本， 用于确定各模块是否可以前当连接；回归 脚本，用于确定系统未改变的部分在系统 改变时是否改变；强度/性能脚本，用于验 证系统在被施加大量事务时的性能。 （1）测试脚本的结构 为了提高测试脚本的可维护性和可复用性 ，必须在执行测试脚本之前对它们进行构建。 （2）记录技术 为使测试脚本获得更高的可维护性，应该 以最不易受测试对象变化影响的方式来记录测 试脚本。 （3）数据驱动的测试 许多测试过程包括在给定的数据输入 屏幕内输入几组字段数据，检查字段确认 功能、错误处理等。 （4）测试脚本同步和时间安排 当进行重点测试时，通常需要同步测 试脚本以便它们在预先确定的时间启动。 （5）测试和调试测试脚本 在记录测试脚本的同一测试软件上执 行这些最近记录的测试脚本时，不应该发 生任何错误。 4辅助测试工具 为了实施高效的测试工作，还需要有高 效、好用的辅助工具，做软件测试通常需 要以下一些基本工具。 优秀的办公处理软件 秒表 错误跟踪系统 自动测试工具 软件分析工具 好的操作系统 多样化平台 2.6.4 执行测试 执行测试是执行所有的或选定的一些测 试用例，并观察其测试结果的过程。尽管 为执行测试所做的准备和计划工作会贯穿 于软件开发生命周期之中，但是执行测试 往往都会在软件开发生命周期的末期，或 者接近末期进行，即在编码完成之后进行 。由于测试过程一般分成代码审查、单元 测试、集成测试、系统测试和验收测试几 个阶段，尽管这些阶段在实现细节方面都 不相同，但其工作流程方面却是一致的。 执行测试的过程由以下4个部分组成。 输入。要完成工作所必须的入口标 准或可交付的结果。 执行过程。从输入到输出的过程或 工作任务。 检查过程。确定输出是否满足标准 的处理过程。 输出。推出标准或工作流程产生的 可交付的结果。 执行测试过程如图2-5所示。 图2-5 执行测试过程 2.6.5 评估测试 软件测试的主要评测方法包括测试覆盖 和质量评测。测试覆盖是对测试完全程度 的评测，它是由测试需求和测试用例的覆 盖或已执行代码的覆盖表示的。质量评测 是对测试对象（系统或测试的应用程序） 的可靠性、稳定性以及性能的评测，它建 立在对测试结果的评估和对测试过程中确 定的变更请求（缺陷）分析的基础上。 1覆盖评测 覆盖指标提供了“测试的完全程度如何” 这一问题的答案。最常用的覆盖评测是基 于需求的测试覆盖和基于代码的测试覆盖 。简而言之，测试覆盖是就需求（基于需 求的）或代码的设计/实施标准（基于代码 的）而言的完全程度的任意评测，如用例 的核实（基于需求的）或所有代码行的执 行（基于代码的）。 2质量评测 测试覆盖的评估提供对测试完全程度 的评测，在测试过程中已发现缺陷的评估 提供了最佳的软件质量指标。 3性能评测 评估测试对象的性能行为时，可以使 用多种评测，这些评测侧重于获取与行为 相关的数据，如响应时间、计时配置文件 、执行流、操作可靠性和限制。 2.7 测试的成功经验 为了减少系统的开发费用，越早测试 越好，这是多年来软件行业的一个成功经 验，即在整个软件开