软件生命周期中的测试

第二章 软件生命周期中的测试

1.开发模型

1.1开发模型和测试

• 软件测试不是孤立存在的，测试活动与开发活动息息相关

• 软件测试活动不仅仅包括测试执行，它应该贯穿于整个软件的生命周期中

• 不同的开发生命周期模型需要对应不同的测试阶段、测试活动和测试方法

1.2瀑布模型

用户需求-->需求分析-->概要设计-->详细设计-->编码和实现-->测试-->运行维护

• 软件测试作为整个软件生命周期中的一个阶段！

瀑布模型的阶段

• 用户需求：用户需求一般由用户提出，系统人员或者产品市场人员从客户或将来的系统中收集原始的项目信息

• 需求分析：对用户需求进行可行性分析，并对用户需求和要求进行详细买书，并最终得到管理层和客户的批准。通过需求分析，定义了开发系统的目的和需要实现的特性和功能

• 概要设计：明确系统的架构、系统的模块数量，以及各个模块之间的接口、数据结构，以及可能的网络环境支持和后台数据库。简单地说，就是将需求映射到新系统的功能和框图上，从而可以对每个子系统进行独立的开发。

• 详细设计：细化概要设计的框架，定义每个子系统的任务、行为、内部结构以及与其他子系统的接口

• 编码和实现：通过编程语言实现所有已经定义的单元，比如模块、单元和类

• 测试：作为开发周期的一个阶段，主要是指测试执行活动

• 运行维护：软件系统或者产品发布，在用户中使用，以及根据反馈进行必要的维护活动

瀑布模型的特点

• 软件测试是开发过程中的一个阶段，对产品质量进行的最后检查

• 在客户需求明确，以及开发过程中没有平凡的需求变更，比较适合瀑布开发模型

• 假如需求不明确或者需求经常发生变更，采用瀑布模型是非常不适合的

1.2 V模型

V模型阶段

• 除了前面瀑布模型中介绍的用户需求、需求分析、详细设计、概要设计、编码和实现几个阶段之外，还强调了不同的测试级别概念

单元测试：验证软件单元是否按照单元规格说明（详细设计说明）正确实行，即保证每个最小的单元能够正常运行。单元测试一般由开发人员来执行，首先设定最小的测试单元，然后通过设计相应的测试用例来验证各个单元功能的正确性

集成测试：检查读个单元是否按照系统概要设计描述的方式协同工作。集成测试的主要关注点是系统能够成功编译，实现了主要的业务功能，系统各个模块

集成测试：验证整个系统是否满足需求规格说明

验收测试：从用户的角度检查系统是否满足合同中定义的需求或者用户需求

V模型的特点

• V模型体现的主要思想是开发和测试同等重要，左侧代表的是开发活动，而右侧代表的是测试活动

• V模型针对每个开发阶段，都有一个测试级别与之想对应

• 测试依旧是开发生命周期中的阶段，与瀑布模型不同的是，有多个测试级别与开发阶段对应

• V模型适用于需求明确和需求变更不频繁的情形

V模型的验证和确认

验证：通过检查和提供客观证据来证实指定的需求是否满足。也就是说，输入与输出之间的比较（是否正确地构建了系统？）

确认：通过检查和提供客观证据来证实特定目的的功能或应用是否已经实现。在确认是，应考虑使用和应用的条件范围要远远大于输入是确定的范围（是否构建了正确的系统？）

• 实际上每个测试都包括确认测试和验证测试这两个方面。而确认测试的内容。而确认测试的内容随着测试级别的不断提高而增加。

• 瀑布模型和V模型，都是属于线性模型的范畴，他们的重要特点就是线性的，即前置条件是软件系统具有比较明确的需求，且没有频繁的需求变更

1.3非线性模型

• 需求是可变的：某些应用软件的需求，与外部环境、公司经营策略或经营内容等密切相关，这些都是经常调整和变化的，因此需求也是变化的。

• 需求是模糊的：许多用户对他们的需求最初只是模糊的概念，想要求一个对需求只有初步设想的人准确无误的说出全部的需求，显然是不切实际的

• 用户和开发者难于沟通：大多数户和领域专家不熟悉计算机和软件技术，而软件开发人员也往往不熟悉用户的专业领域，开发人员和用户之间很能做到完全沟通和相互理解，在需求分析阶段做出的用户需求常常是不完整、不正确的

增量模型

• 增量模型在每个阶段交付满足客户需求的一个子集的可运行产品。因此可以较好的适应变化，以及控制风险。

• 增量的一个缺点是后面并入的构建不能破坏已构造好的系统部分，这需要软件具备开放式的体系结构

• 在开发过程中，需求的变化是不可避免的。增量模型的灵活性可以使其适应这种变化的能力大大优于线性模型，但也很容易退化为边做边改模型，从而使软件过程的控制失去整体性

1.4迭代模型

测试活动贯穿于整个软件生命周期

• 单元测试

• 集成测试

• 系统测试

• 验收测试

针对不同得的测试级别，我们应该明确

• 不同的测试的对象

• 每个测试级别的测试目的

• 测试用例参考的工作产品：测试依据

• 发现的典型缺陷和失效

• 测试工具的需求和支持

• 不同的测试技术和方法

2.2单元测试

基本含义

• 单元测试的对象可以是模块、类、函数和对象等，不同的软件语言来决定

• 单元测试的主要目的是验证单元是否满足了详细设计规格说明，发现需求和设计中的作物

• 单元测试设计的主要输入是详细设计规格说明、软件测试和数据模型等

• 单元测试主要采用白盒测试技术，黑盒测试技术作为单元你测试的辅助

• 单元测试应该覆盖功能需求和非功能需求

• 单元测试经常会使用测试驱动的方法（测试驱动开发）

测试环境

• 单元测试处理的对象直接来自开发人员，通常由开发人员来展开测试

• 单元测试可能并不能形成完成的系统，因此需要驱动模块和桩模块的支持； 桩模块：用以模拟被测工作过程中所调用的模块工作过程中所调用的模块，他们一般只有进行很少的数据处理，例如打印入口和返回 驱动模块：用以模拟被测模块的上级模块，它接受测试数据，把相关的数据传送给被测数据模块，启动被测模块，并打印相关的结果

• 驱动模块和桩模块是测试使用的软件，而不是软件产品的组成部分，但它需要一定的开发费用

单元测试关注点

• 单元测试关注点： 实际参数和形式参数的个数是否相同； 实际参数和形式参数的属性是否匹配； 调用函数的参数顺序、个数和属性是否正确；

• 单元模块局部数据结构： 不适合或者不相容的类型说明； 变量没有初始化； 不正确的变量名；

• 单元模块的独立路径测试： 误解或者用错了算符优先级； 混合类型运算；

• 与控制流相关的的测试： 错误的修改了循环变量； 循环中止条件不可能出现

• 与异常处理相关的测试： 输出的错误信息难以理解； 错误的信息和实际的错误不符

2.3集成测试

基本含义

• 集成测试，又叫组装测试、联合测试等

• 集成测试是对组件之间的接口进行测试，以及和系统其它部分的相互作用

• 最简单的形式的两个已经测试的单元组合成一个组件，来测试它们之间的接口和数据

• 集成测试的主要工作：把单元测试通过的各个模块逐步集成在一起，来测试数据是否能够正确传递和调用，以及各个模块是否能正确的协同工作

• 集成测试可以应用在不同的测试等级，比如单元集成测试、系统集成测试等。

集成测试的关注点

• 单元模块是否传输了错误的数据，或者没有传输数据

• 接受数据的单元不能操作或者崩溃，比如单元功能缺陷、接口格式不兼容、协议不兼容等

• 单元之间通讯正常，但是使用不同的方法来解析收到的数据，比如规格说明矛盾、理解错误等

• 数据能正常传输，但是传输时间错误，比如时序问题，或者传输的时间间隔太短，比如吞吐量、负荷、容量问题。

2.4集成测试策略

自底向上集成测试步骤

• 明确被测模块并进行先后顺序分层

• 按照时间线序关系，将不同单元进行集成

• 将不同的模块集成为子系统，或者分系统

• 将子系统集成为系统

自底向上集成测试特点

• 不需要桩

• 需要构造不同的驱动模块

自顶向下集成测试步骤

• 以主控模块作为测试驱动，把对主控模块进行单元测试时引入的所有桩模块用实际模块替代。

• 依据所选的集成策略（深度优先或广度优先），每一个

• 每集成一个模块立即测试一遍

• 只有每组测试完成之后，才着手替换下一个桩模块

• 为避免引入新的错误，须不断地进行回归测试（即全部或部分地重复已做过的测试）

自顶向下集成测试特点

• 优点：不需要测试驱动器，或者只需要简单的测试驱动，这是因为经过测试的较高级别单元组成了测试环境的主要部分

• 还没有集成的较低级别的单元必须用桩代替，成本很高

核心系统优先集成测试步骤

• 对核心系统中的模块进行单独的、充分的测试

• 核心系统的所有模块一次性集合到被测系统中，在规模相对较大的情况下，也可以按照自底向上的步骤，集成核心系统的各组成模

• 按照各外围软件部件的重要程度以及模块见得相互制约关系，拟定外围软件部件集成到核心系统中的顺序方案

• 完成外围软件部件内部的集成测试

• 按顺序不断加入外围软件部件到核心系统

随意测试的步骤

• 按照单元的完成时间进行集成

随意集成测试特点

• 优点：节省时间，因为每个单元可以最快的集成到环境中来

• 缺点：桩和测试驱动都需要

大爆炸集成策略：避免

• 本来可以用作测试的时间浪费在等待大爆炸集成上了。由于王总是缺乏用于测试的时间，所以不应该浪费可以用于测试的任何时间

• 所有的失效将会同时发生。有时集成后的系统根本无法运行起来。此外，定位和修正缺陷会很困难，并且消耗很多时间

2.5系统测试

测试目标

• 系统测试的目标是确认整个系统是否满足了规格说明中的功能和非功能需求，以及满足的程度

• 系统测试应该发现由于需求不正确、不完整或实现和需求不一致二引起的失效，并识别没有文档化或被忘记的需求

• 常见的系统测试包括压力测试、容量测试、性能测试、安全测试、容错测试等

为什么系统测试

• 在较低的测试级别，测试主要是针对技术规格说明，即从软件开发者的技术观点角度加以考虑。而系统测试从客户或用户的观点来考虑整个系统。测试人员确认是否完全正确地满足了需求

• 许多功能和系统属性是从系统的所有组件相互协调的过程中得到的，因为只能字啊整个系统级别才能看到，也只能在这个时候才能够法进行观察并测试。

2.6验收测试

基本含义

• 验收测试通常是由使用系统的用户来进行，同时系统的其他利益相关者也可以参与其中。

• 验收测试目的是通过验收测试，对系统功能、系统特定部分或特定的系统非工能特征进行测试

• 发现缺陷不是验收测试的主要目标，验收测试也可以用来评估系统是否可以在市场部署、用户使用系统的准备情况等

验收测试类型

• 合同验收测试

• 规范验收测试

• Alpha和Beta测试

• 用户验收测试

• 运行验收测试

3.测试类型

3.1功能测试

基本含义

• 功能测试指的是软件系统“做什么”

• 功能测试的测试依据包括：需求规格说明、用例、功能对个说明。他们描述了系统必须完成的功能

• 功能测试主要考虑的是系统的外部表现，即一般才用的黑盒测试的技术

• 功能测试可以应用在各个测试级别

功能测试包括

• 合适性

• 准确性

• 互操作性

• 安全性

3.2非功能测试

基本含义

• 非功能性指的是系统工作的“怎么样”，比如系统有多容易使用等

• 非功能测试不是功能的测试，二十对功能行为的测试，或作为整体系统能力的测试

• 非功能测试可以应用在任何测试级别上

非功能测试包括

• 可靠性

• 易用性

• 可维护性

• 可移植性

非功能测试例子

• 负载测试：增加系统负载来测量系统的行为（如并发用户数、事物数）

• 性能测试：测量特定用例的处理速度和响应时间，通常依赖于不断增加的负载

• 容量测试：再打容量数据下系统行为额观察（如处理非常大的文件）

• 压力测试：观察超负荷下系统行为

• 安全性测试：针对未授权的访问攻击等。

• 稳定性：或可靠性测试：在长时间运行中测试（如事项的平均时间或指定用户配置的失效率）

• 健壮性测试：测量在系统对于错误操作、错误编程、硬件故障的相应，以及检查系统异常处理和恢复的能力

• 金融新和数据转换测试：检查给定系统的兼容性，导入/导出数据等

• 系统不同配置的测试：例如：操作系统的不同版本，用户接口语言，硬件平台等等（比对测试（back-to-back testing））

• 可用性测试：检查客户学习系统的容易醒、操作性和效率、系统输出的可理解性等，经常与特定用户组的需求相关

3.3结构测试

基本含义

• 结构测试，或者白盒测试，使用测试对象的内部代码结构和架构信息（语句或判断、递归调用、菜单结构），也可能使用软件的抽象模型（例如：过程流模型或状态转换模型）等作为输入；

• 结构测试可以在任何测试级别上进行

• 结构测试技术通常通过评估结构类型测试的覆盖性，来测量测试的完整性

• 结构测试通常应用在低级别的测试上，比如单元测试和集成测试，但它同样使用其他级别的测试

覆盖类型

• 语句覆盖

• 判定覆盖

• 条件组合覆盖

• 判定/条件覆盖

• 路径覆盖

4.维护测试

维护测试

• 系统在未预料的和没有计划过德行的运行环境中运行

• 客户表达了新的愿望

• 需要处理不可预见的很少发生的情况

• 出现很少发生或只在运行时间很长后才发生程序崩溃

为什么回归测试

• 通过重新进行测试以确定原来的缺陷已经成功的修改、或者新增的功能已经正确实现

• 通过测试，确认系统的变更比如新增功能或者缺陷修改，没有影响原来的功能和操作

如何回归测试

• 维护测试的范围取决于变更的风险、现有系统规模和变更的大小

• 确定变更如何影响现有系统的过程，称之为影响分析，它有助于决定实施回归测试的广度和深度

回归测试步骤

• 软件变更分析

• 变更影响分析

• 定义回归测试策略

• 定义回归测试套件

• 执行回归测试套件

• 报告测试结果

版本开发和维护测试