测试基本理论

软件测武基率理跄

二00三年十月

软件测试基本知识

提纲

♦软件测试基本概念

。软件测试方法

♦:♦软件测试阶段

♦:♦软件测试过程

当前软件测试面临的挑战

如何适应由于软件新技术、新架构的应用导致

测试工作量增大

如何进行软件测试工作的分工

如何提高开发团队的进行组件测试的质量

如何提高系统测试团队的士气

♦如何评价系统测试过程的进度

如何评价系统测试的完备性

如何评价软件质量

引起软件缺陷的因素

♦:♦交流不够、交流上有误解或者根本不进行交流

♦:♦软件复杂性

。程序设计错误

♦:♦需求变化

❖时间压力

♦:♦开发人员的过分自信

♦:♦代码文档贫乏

软件缺陷的定义

♦:♦软件未达到产品说明书表明的功能

软件出现了产品说明书指明不会出现的错误

♦:♦软件功能超出产品说明书指明范围

软件未达到产品说明书虽未指出但应达到的目

标

♦:♦软件测试人员认为软件难以理解、不易使用、

运行速度缓慢，或者最终用户认为不好

软件测试的目的

♦尽可能早的发现软件缺陷,并确保其得以修复

软件测试是为了发现错误而执行程序的过程

。测试是为了证明程序有错，而不是证明程序无

错误

❖一个好的测试用例是在于它能发现至今未发现

的错误

一个成功的测试是发现了至今未发现的错误的

测试

软件测试的重要性（一）

100%

项目持续时间

软件测试的重要性（二）

软件测试的重要性（三）

软件测试的重要性U!)

风险

况代软件的测试方法|

，越早叫的测试

软件测试的一些观点

♦:♦完全测试程序是不可能的

软件测试是有风险的行为

测试无法显示潜伏的软件缺陷

♦:♦找到的软件缺陷越多，说明软件缺陷越多

♦:♦并非所有的软件缺陷都能修复

测试原则

所有的测试都应追溯到用户需求

♦:♦在测试工作真正开始的前较长时间内就进行测

试计划

♦:♦测试应从“小规模”开始，逐步转向“大规模”

❖Good-Enough原则（穷举测试是不可能的）

♦:♦木桶原理

♦:.Pareto原则（80-20原贝|）

提纲

♦:♦软件测试基本概念

♦:♦软件测试方法

♦软件测试阶段

♦软件测试过程

软件测试方法

软件测试方法和技术是多种多样的，可以从不

同的角度加以分类

♦从测试是否针对系统的内部结构和具体实现算

法的角度来看，可分为黑盒测试和白盒测试

♦:♦从是否需要执行被测软件的角度，可分为静态

测试和动态测试

测试方法-黑盒与白盒

两种测试方法从不同的角度出发，反映了软件

的不同侧面，也适用于不同的开发环境

中黑盒测试：基于软件设计规范设计测试用例

♦:♦白盒测试：基于代码覆盖情况设计测试用例

测试方法一黑盒测试

♦黑盒测试也称功能测试、数据驱动测试

♦:♦把程序看作一个不能打开的黑盆子，在完全不

考虑程序内部结构和内部特性的情况下，针对

软件界面和软件功能进行测试，只检查程序功

能是否按照需求规格说明书的规定正常使用

。黑盒测试方法主要有等价类划分、边值分析、

因-果图、错误推测等，主要用于软件确认测

试

测试方法-白盒测试

白盒测试也称结构测试或逻辑驱动测试

。了解产品内部工作过程，从检查程序的逻辑着

手，检验程序中的每条通路是否都有能按预定

要求正确工作，通过测试来检测产品内部动作

是否按照规格说明书的规定正常进行

♦:♦白盒测试的主要方法有逻辑驱动、基路测试等,

主要用于软件验证

测试方法-静态与动态（一）

♦:♦静态测试：只测试不运行的部分-只是检查和

审阅

♦:♦常见的静态测试:

■需求评审

■设计评审

■代码走查

■代码检查

测试方法-静态与动态（二）

♦:♦动态测试：实际运行被测程序，输入相应的测

试用例，判定执行结果是否符合要求，从而检

验程序的正确性、可靠性和有效性

♦:♦常见的动态测试：

■单元测试

■集成测试

■系统测试

■用户的验收测试

■回归测试

测试方法的具体使用

♦:♦静态黑盒测试-检查产品说明书

♦:♦动态黑盒测试

♦:♦静态白盒测试-检查设计和代码

♦动态白盒测试-单元测试

以！J试策略

♦:♦测试策略描述测试工程的总体方法和目标

寺描述目前在进行哪一阶段的测试（单元测试、

集成测试、系统测试）以及每个阶段内在进行

的测试种类（功能测试、性能测试、压力测试

等）

♦:♦任何测试策略者口必须和测试计划、测试用例设

计、测试执行、测试结果数据的收集与分析结

合在一'起

测试策略内容

♦:♦确定目前的测试阶段

♦:♦确定要使用的测试技术和工具

♦:♦确定测试完成标准

♦:♦确定影响资源分配的特殊考虑例如测试与外部

接口或者模拟物理损坏、安全性威胁

提纲

♦:♦软件测试基本概念

♦:♦软件测试方法

♦软件测试阶段

♦软件测试过程

软件测试阶段

♦:♦单元测试

。集成测试

♦:♦系统测试

♦:♦验收测试

单元测试-基本概念

单元测试是在软件开发过程中要进行的最低级

别的测试活动

♦:♦名单元测试活动中，软件的独立单元将在与程

序的其他部分相隔离的情况下进行测试

♦:♦目的：发现该模块的实际功能与功能定义说明

不符合的情况，查找独立模块中的逻辑错误、

数据错误和算法错误

♦:♦执行者：软件工程师

单元测试-其它活动

♦:♦经常与单元测试联系起来的另外一些开发活动

包括：代码走读、静态分析和动态分析

♦:♦静态分析：对软件的源代码进行研读，查找错

误或收集一些度量数据，并不需要对代码进行

编译和执行

♦:♦动态分析：通过观察软件运行时的动作，来提

供执行跟踪，时间分析，以及测试覆盖度方面

的信息

单元测试用例检查要点

♦:♦算法和逻辑

♦:♦数据结构

♦:♦接口

♦:♦独立路径

边界条件

错误处理

单元测试的误解

♦:♦它浪费了太多的时间

它仅仅是证明这些代码做了什么

♦:♦我是个很棒的程序员，我可不可以不进行单

元测试

♦:♦不管怎样，集成测试将会抓住所有的Bug

♦:♦它的成本效率不高

单元测试的成本效率（一）

一个尽责的单元测试将会在软件开发的某个阶段发现

很多的Bug,并且修改它们的成本也很低

♦:♦在软件开发的后期阶段，Bug的发现并修改将会变得

更加困难，并要消耗大量的时间和开发费用

♦:♦经过了单元测试的系统集成过程将大大地简化。开发

人员可以将精力集中在单元之间的交互作用和全局的

功能实现上，而不是陷入充满很多Bug的单元之中

使测试工作的效力发挥到最大化的关键在于选择正确

的测试策略

单元测试的成本效率（二）

单元测试的成本效率大约是集成测试的两倍,

系统测试的三倍！

摘自〈〈实用软件度量》〉

集成测试-基本概念

集成测试是将模块按照设计要求组装起来同时

进行测试，也叫组装测试

。目的：发现模块间接口的错误

♦:♦执行者：软件工程师

♦:♦测试方法：一次性组装法、增量集成测试法

一个常见的问题

。〃如果所有的模块都进行了单元测试，为什么还要进

行集成测试？〃

❖一个模块可能对另一个模块产生不利的影响

♦:♦将子功能合成时，不一定产生期望的主功能

♦:♦独立的可以接受的误差，组装后这些误差可能会超过

可以接受的限度

可能会发现单元测试中未发现的接口错误

♦:♦在单元测试中无法发现的时序问题（实时系统中）

在单元测试中无法发现的资源竞争问题

集成测试的实现

♦:♦集成测试覆盖面很广：从几个模块的测试到整

个系统的测试

♦:♦集成测试一般使用增量集成测试法来实现

❖增量集成测试指依据模块在模块层次中位置，

将组成产品的各个部分逐步自顶向下或自底向

上组装模块并测试

♦:♦好处：利于发现、隔离和修改程序问题

自顶向下组装法

。主控模块作驱动，所有与主控模块直接联系的模块作

为下级模块（桩模块）

♦:♦根据选定的组装方法（深度或广度优先），每次用一

个模块替换从属的下级模块（桩模块）

❖每个独立的模块组装后都要进行测试

♦:♦成功完成整套测试后，用实际的模块替代另一个桩模

块

♦:♦进行回归测试以确定新模块组装后，没有引入错误

♦:♦从第二步后反复进行，直到完成整个系统的组装

自底向上组装法

。组装从最底层模块开始，组合成一个簇或构件,

用以完成指定的软件子功能

♦编制驱动程序，协调测试用例的输入和输出

♦测试组装后的构件

♦:♦测试后的构件按照程序结构，向上层组装，同

时去掉驱动程序

存在问题

♦:♦自顶向下组装法

■许多情况下，计算是在位于层次结构底部的模块中完成

■通常需要组装多个底层模块才能测试

■开发可以向上传递数据的模块的工作量与开发实际模块的工

作量相当

自底向上组装法

■直到组装最后一个模块后，整个程序才存在

■只有到测试过程底后期，才能发现时序问题和资源竞争问题

♦:♦一种策略的优点差不多就是另一■种策略的缺点,

一'般采用组合策略

集成测试应该注意的问题

♦:♦许多组织很少关注甚至忽略集成测试

♦:♦软件开发人员经常一下将所有模块组装后就进

行测试

♦:♦开发人员经常对单元测试与集成测试概念模糊、

混为一谈

系统测试-基本概念

系统测试是从系统的角度对软件功能进行测试,

验证软件实现的正确性

♦:♦目的：确认软件是否满足需求规格说明中的所

有需求

♦:♦执行者：测试工程师

♦:♦测试方法：主要以检测系统的功能为主，一般

用黑盒测试方式

其它方面的系统测试

。恢复测试：通过系统的修复能力，检测重新初始化，

数据恢复，重新启动，检验点设置机构是否正确，以

及人工干预的平均恢复时间是否在允许范围内

。安全测试：突破软件安全保护的机构安全保密措施，

检验系统是否安全保密的漏洞

强度测试：检验系统的能力最高能达到什么实际的限

度，让系统处于资源的异常数量、异常频率、异常批

量的条件下运行测试系统的承受能力。一般取比平常

限度高5—10倍的限度做测试用例

♦:♦性能测试：设计测试用例测试并记录软件运行性能，

与性能要求比较，看是否达到性能要求规格。这项测

试常常与强度测试相结合进行

验收泱J试

♦:♦验收测试也称合格测试、确认测试

♦:♦主要由用户参加测试，检查软件能否按合同要

求进行工作，即是否满足软件需求说明书中的

确认标准，是保证软件质量的最后关键环节

。执行者：用户、测试工程师和项目组

♦:♦测试环境：通常是用户现场

♦:♦测试方法：功能测试

提纲

♦:♦软件测试基本概念

♦:♦软件测试方法

♦软件测试阶段

♦软件测试过程

软件测试过程

♦:♦测试计划

♦:♦测试设计

♦:♦测试开发

♦:♦测试执行

♦:♦测试评估

软件测试过程一测试计划

输入：软件需求书

1、测试需求

2、测试策略

3、测试资源

4、测试进度

缺陷跟踪

软件测试过程一测试设计

I~~I.Irvr

输入：软件测试计划书L

1、测试描述

2、前置条件

3、测试步骤

4、验证点

5、后置条件

6、测试通过条件

良好的测试设计是测试自动化

的重要保证！

软件测试过程一测试开发

缺陷跟踪

测试脚本

手工测试脚本

自动化测试脚本

软件测试过程一测试执行

测试执行

进行测试执行管理

运行测试

♦:♦记录测试结果，包括缺陷报告和测试日志

软件测试过程一测试评估

测试评估

统计和分析测试结果，确定是否达到软件发布的标准

软件测试过程一缺陷跟踪

缺陷跟踪

缺陷跟踪

♦:♦记录测试发现的缺陷或用户问题，并且跟踪、管理缺

陷的状态变更

测试计划的问题

♦:♦测试计划经常是等到开发周期后期才开始实行,

使得没有时间有效的执行计划

♦:♦测试计划的组织者可能缺乏测试经验，无法对

测试进行准确的评估，导致测试计划难以落到

实处

♦:♦测试的量度和复杂性可能太大，没有自动化工

具，很难计划和控制

关于测试计划

♦:♦目的：描述所有要进行的测试、必要的资源和

进度

♦可能引起测试失败的因素

■管理层对测试的理解和支持不够

■开发人员与测试人员想法不一致，容易引起对立

■开发人员过度依赖测试而略过代码回顾、控制分析和单元测试

■设计和代码没有变更管理控制，随时变化

■缺少必要的测试工具和环境

■对测试人员的培训不足,测试时间不足

■用户参与不够

测试需求

♦:♦根据用户需求定制完整的测试需求，以此做为

整个测试的标准

■测试需求是测试设计和开发测试用例的基础，分成单元可以

更好地进行设计

■详细的测试需求是用来衡量测试覆盖率的重要指标

■根据测试需求来定义测试是否成功的标准

♦:♦测试需求需要包含软件功能需求和软件性能需

求

测试计划过程

♦:♦确定测试要素，编写可检验的测试需求

♦:♦评估风险

♦:♦制定测试策略，测试方法

♦:♦确定测试资源

♦:♦创建时间表

♦:♦生成测试计划

♦:♦审查测试计划

■由开发、测试、用户三方会议审核

■考虑可能的测试推迟

■执行测试计划可能的阻力

■检查项目需求说明、软件维护手册、技术更新资料、用户手

册

测试设计的问题

♦:♦不做测试设计，测试过程也是胡乱建立的

♦:♦测试设计不详细，不是基于可量度的测试策略

。测试过程没有采用最好的技术来检验Windows

C/S结构的测试需求

频（J试设计

。定义自动化测试过程

♦:♦选择适当的测试用例

♦:♦组织测试过程，并且将之传递给测试开发人员

测试用例的设计

。来源：根据需求说明书、开发设计文档、测试

需求等资料，编写测试用例

♦确定每个用例执行的条件

*设定一系列的测试步骤

♦:♦按照一定策略设计测试输入数据（边界条件、

等价类划分、非法数值等）

♦:♦确定预期的测试输出，做为测试用例成功的依

据,

为每一个测试用例确定测试验证点

测试开发

♦:♦输入：被测软件、基于测试需求的测试设计

。输出：测试过程和测试用例

目标

■创建可以重用的自动化测试过程

■维护测试对于测试需求的可跟踪性

测试开发的问题

♦:♦测试开发很乱，与测试需求或测试策略没有对

应性

。测试用例、测试过程不可重用

♦:♦测试过程被作为一个编程任务来执行，导致脚

本太长，不能满足软件移植性的要求

测