软件测试全册配套精品完整课件.ppt

1、软件测试全册配套精品完整软件测试全册配套精品完整 课件课件 软件测试历史、现状及展望软件测试历史、现状及展望 课程内容课程内容 1. 软件危机 2. 软件测试现状分析 3. 软件测试发展展望 4. 软件测试从业人员职业规划 1.1.软件危机软件危机 软件危机指的是在计算机软件的开发和维护过 程中所遇到的一系列严重问题。 1968年北大西洋公约组织的计算机科学家在 联邦德国召开的国际学术会议上第一次提出了 “软件危机”(software crisis)这个名词。 概括来说，软件危机包含两方面问题：一、如 何开发软件，以满足不断增长，日趋复杂的需 求；二、如何维护数量不断膨胀的软件产品。 软件危机

2、的主要表现 1、对软件开发成本和进度的估计常常不准确。开发成本 超出预算，实际进度比预定计划一再拖延的现象并不 罕见。 2、用户对“已完成”系统不满意的现象经常发生。 3、软件产品的质量往往靠不住。Bug一大堆，Patch一 个接一个。 4、软件的可维护程度非常之低。 5、软件通常没有适当的文档资料。 6、软件的成本不断提高。 7、软件开发生产率的提高赶不上硬件的发展和人们需求 的增长。 软件工程 1968年秋季，NATO（北约）的科技委员会召集了 近50名一流的编程人员、计算机科学家和工业界巨头， 讨论和制定摆脱“软件危机”的对策。在那次会议上 第一次提出了软件工程（software eng

3、ineering）这 个概念。 软件工程是一门研究如何用系统化、规范化、数量化 等工程原则和方法去进行软件的开发和维护的学科。 软件工程包括两方面内容：软件开发技术和软件项目 管理。 2.2.软件测试现状分析软件测试现状分析 软件测试行业起步较低 行业发展地域差异大 从业人员技能差异大 当前软件测试高速发展 软件测试百花齐放，百家争鸣 3.3.软件测试发展展望软件测试发展展望 地域差异将逐渐缩小 软件测试体系将不断完善 软件测试仍将高速发展 软件测试行业将逐渐细分与融合 4.4.软件测试从业人员职业规划软件测试从业人员职业规划 技术路线 管理路线 问题和讨论问题和讨论 谢谢谢谢 大家大家 软件

4、测试基础软件测试基础 陈大卫 2021年10月25日 1. 软件测试的目的和价值软件测试的目的和价值 2. 对软件测试的理解对软件测试的理解 3. 软件测试的原则软件测试的原则 4. 软件测试内容和类型软件测试内容和类型 5. 软件测试人员职责软件测试人员职责 6. 软件测试人员要求软件测试人员要求 1.软件测试的价值软件测试的价值 防止质量灾难的发生 确保软件满足用户的需求（功能性，非 功能性) 确保软件符合质量标准(国家,行业,企 业) 证程序的正确性除非仅处理有限种情况。（实实 际上是不可能的际上是不可能的） 发现程序错误（BUG）直接目标。 检查软件（系统）是否满足需求期望目标。 Gl

5、en Myers提出关于测试目标的规则： 测试是一个为了寻找错误而运行程序的过程。 一个好的测试用例是指很可能找到迄今为止尚未发现 的错误的用例。 一个成功的测试是指揭示了迄今为止尚未发现的错误 的测试。 使用人工或自动手段来进行或测定某个系 统的过程，其目的在于检验它是否满足规定的需求或 是弄清预期结果与实际结果之间的差别。“软件测试 以检验是否满足需求为目标”。 对测试的正确理解： 贯穿在整个开发各阶段的复查、评估与检验活动，远 远超出了程序测试的范围，可以统称为确认、验证与 测试活动（V，V 可靠程度如何; 效率如何; 使用是否方便; 环境开放的程度如何(即对环境、平台的限制，与 其他软

6、件连接的限制)。 开发者更关心的是，软件产品开发相关 的一些属性，而非单纯的软件使应用。 软件是否易于维护 软件是否易于移植 软件组件等是否易于重用 软件产品是否易于测试 软件质量特性与子特性软件质量特性与子特性 质量特性的定义：一个与质量有关的面向管理 的软件属性。 软件子特性：质量特性分解出来的技术组件。 软件质量特性的分解，不同的组织对软件质量 特性的具体做法是不一样的。如McCall质量模 型（1977年）、Boehm模型（1978年）和 ISO（1993年）等软件质量评价模型。 为通过某些定量方法来评价产品质量，就要求有一组描 述产品且构成评价基础的质量特性。 软件质量特性是用于评价

7、软件产品并对之进行质量测量 的重要维度。 国标国标ISOIEC9126：1991信息技术信息技术 软件产品评价软件产品评价 质量特性及其使质量特性及其使 用指南用指南 定义的质量特性包括 6个质量特性，进一步细化为21个质量 子特性. 在随后的9126-2,9126-3中又修正为27个子特性. 软件质量特性与子特性软件质量特性与子特性 国标ISOIEC9126：1991 信息技术 软件产品评价 质量特性及其使用指南 软件质量特性之间的关系软件质量特性之间的关系 功能性功能性可靠性可靠性易用性易用性效率效率可维护性可维护性 可移植性可移植性 功能性功能性 可靠性可靠性 易用性易用性 效率效率 可

8、维护性可维护性 可移植性可移植性 A2.1 功能性功能性(functionality) 是与一组功能及其指定的性质有关的一组属性 A2.1.1A2.1.1适合性 Suitability 与规定任务能否提供一组功能以及这组功能的适合程度有关的软 件属性。 A2.1.2A2.1.2准确性 accuracy 与能否得到正确或相符的结果或效果有关的软件属性。 A2.1.3A2.1.3互操作性；互用性 interoperability 与同其他指定系统进行交互的能力有关的软件属性。 A2.1.4A2.1.4依从性 compliance 使软件遵循有关的标准、约定、法规及类似规定的软件属性。 A2.1.5

9、A2.1.5安全性 security 与防止对程序及数据的非授权的故意或意外访问的能力有关的软 件属性。 A2.2 可靠性（可靠性（reliability） 是与在规定的一段时间和条件下，软件维持其性能水平的能力有 关的一组属性 A2.2.1 成熟性 maturity 与由软件故障引起失效的频度有关的软件属性。 A2.2.2 容错性 tolerance 与在软件故障或违反指定接口的情况下，维持规定的性能水平的 能力有关的软件属性。 A2.2.3 易恢复性 recoverability 与在失效发生后，重建其性能水平并恢复直接受影响数据的能力 以及为达此目的所需的时间和努力有关的软件属性。 A2

10、.2.4 依从性 compliance 软件产品遵循与可靠性相关的标准、协定或规章的能力 A2.3易用性（易用性（usability） 是与一组规定或潜在用户为使用软件所需作的努力和对这样的使用所作 的评价有关的一组属性 A2.3.1 易理解性 understandability 与用户为认识逻辑概念及其应用范围所花的努力有关的软件属性。 A2.3.2 易学习性 learnability 与用户为学习软件应用（例如运行控制、输入、输出）所花的努力有关 的软件属性。 A2.3.3 易操作性 operability 与用户为操作和运行控制所花努力有关的软件属性。 A2.3.4 吸引性 attrac

11、tiveness 软件产品吸引用户的能力。（颜色、图片等） A2.3.5 依从性 compliance 软件产品遵循与易用性相关的标准、协定、风格指南或规章的能力 A2.4 A2.4 效率效率 （efficiencyefficiency） 是在规定的条件下，软件性能水平与所使用资源量之 间关系有关的一组属性 A2.4.1 时间特性 time behaviour 与软件执行其功能时响应和处理时间以及吞吐量有关 的软件属性。 A2.4.2 资源特性 resource behaviour 与在软件执行其功能时所使用的资源数量及其使用时 间有关的软件属性。 A2.4.2 依从性 compliance

12、软件产品遵循与效率相关的标准、协定的能力 A2.5 易维护性易维护性（ maintainability） 是与进行指定的修改所需的努力有关的一组属性 A2.5.1 易分析性 analysability 与为诊断缺陷或失效原因及为判定待修改的部分所需努力有关的 软件属性。 A2.5.2 易改变性 changeability 与进行修改、排除错误或适应环境变化所需努力有关的软件属性。 A2.5.3稳定性 stability 与修改所造成的未预料结果的风险有关的软件属性。 A2.5.4易测试性 testability 与确认已修改软件所需的努力有关的软件属性。 A2.5.5依从性 complianc

13、e 软件产品遵循与可维护性相关的标准、协定的能力 A2.6可移植性（可移植性（ portability） 是与软件可从某一环境转移到另一环境的能力有关的一组属性 A2.6.1适应性 adaptability 与软件无需采用有别于为该软件准备的活动或手段就可能适应不 同的规定环境有关的软件属性。 A2.6.2易安装性 installability 与应指定环境下安装软件所需努力有关的软件属性。 A2.6.3共存性 co-existence 软件产品在公共环境中同与其分享公共资源的其他独立软件共存 的能力。 A2.6.4易替换性 replaceability 与软件在该软件环境中用来替代指定的其他

14、软件的机会和努力有 关的软件属性 A2.6.5依从性 compliance 软件产品遵循与可移植性相关的标准或协定的能力 软件的内部特性软件的内部特性 外部特性外部特性 子特性子特性 使用质量的质量模型：使用质量的质量模型： 包括效果、生产率、安全、满意。包括效果、生产率、安全、满意。 软件质量特性的实践意义软件质量特性的实践意义 软件质量体系通过特性和子特性的定义构架了一 个完整的软件质量描述框架 在整个软件项目的各个阶段都具有指导意义 测试实践中我们需要根据软件质量体系 在测试计划中确定项目质量标准 在测试设计中按照特性分布设计测试用例，决 定测试策略 在测试执行中确定执行策略 在测试报告

15、中全面总结评价软件的最终特性 软件质量度量软件质量度量 在实践中对软件产品质量评价还需要除 目前掌握的特性外的其他特性，并需要 有对于每一特性的度量度量 -可以量化的质量评价 特特 性性 子子 特特 性性 度量项度量项度量的目的度量的目的度量值度量值 易易 用用 性性 易易 学学 性性 功能点的易学 性 用户学习某一功能点的时 间。 用户学会一个功能点的平 均学习时间。 执行任务的易 学性 用户执行某一任务的时间。 用户能够尽快完成某一任 务的时间和。 操作过程的简 化 为方便起见，用户是否容 易简化操作过程。 自定义减少的操作步骤数 /自定义前的操作步骤数。 生理可接受性 对于有生理缺陷时能

16、否正 常使用功能。 能够正常使用的功能点数 /总功能点数。 吸吸 引引 性性 UI吸引性UI对用户的吸引程度。采用调查问卷形式。 界面自定义 能够自定义为用户喜好的 界面元素比例。 满足用户喜好的自定义界 面元素数量/用户希望自 定义的界面元素数量。 问题和讨论问题和讨论 谢谢谢谢 大家大家 软件测试设计介绍软件测试设计介绍 陈大卫 2021年10月25日 课程内容课程内容 1. 测试设计概述 2. 系统整体架构确定 3. 测试策略确定 4. 功能性测试设计 5. 其他测试设计 测试设计概述测试设计概述 通过2个重要的文档测试计划和测 试说明，测试设计人员确定了项目测 试的工作范围，测试策略，

17、测试方案， 测试重点分布等关键内容，以及具体的 测试用例。测试设计最终决定了测试执 行的效果如何，是软件项目测试过程中 的核心内容。 测试计划和测试说明中前言部分可以从 其他项目文档中引入 项目名称/项目代号/产品版本-项 目计划 背景备注- 项目计划/需求文档 参考资料- 项目计划/需求文档 测试对象-项目包含的模块,子系统, 接口,流程 测试阶段-测试人员决定 测试工具-可以在测试设计方案产 生后最终决定 系统整体架构确定系统整体架构确定 来自需求规格说明书，提供了总体 业务流程或者整体系统架构的图示 如果是多个模块或子系统,要汇总形成整 体的系统结构图表.包含系统全部模块,数据流, 控制

18、关系的图示等 测试策略确定测试策略确定 按照两条轴线展开思考，这两条轴线就 是基于需求规格说明书的软件功能分解 和基于质量特性体系的软件质量子特性 分解。这2条轴线综合考虑的结果将形成 一个完整的软件测试布局 确定测试点的重点与非重点分布.-哪 些质量特性最重要,那些模块和功能点最关键, 哪些需求优先级最高,哪些部分最复杂,风险最 大 确定测试执行的顺序-存在逻辑关系吗? 确定测试环境配置清单以及对应关系 记录上述测试设计与测试执行中采用的 技术,方法-采用黑盒还是白盒,具体的 测试技术方法 功能性测试设计功能性测试设计 根据需求文档逐条业务流程设计用例 业务流程包括逻辑流和数据流； 根据需求

19、文档逐个功能点设计用例 其他测试设计其他测试设计 v可靠性 v易用性 v效率 v可维护性 v可移植性 v其他的专项测试 一些专项测试类型一些专项测试类型 v配置测试 v本地化测试 v易用性测试 v网站测试 v安全测试 v自动测试-测试工具选择 配置测试 建立一份完备且合理的配置清单建立一份完备且合理的配置清单 v 确定硬件类型-主机,组件,外设,接口,内存,驱动 v 确定硬件型号和驱动程序 v 确定硬件特性,模式,选项和参数 v 确定操作系统,应用软件和相关的其他 v 缩减范围到资源可承受,建立一份实际使用的清单 v 不要在每种配置中完全测试软件-明确使用硬件配置的软件 唯一特性 v 设计每种

20、配置中执行的测试用例 v 在每种配置中执行测试 本地化测试 v 代码级问题检查 v 语言和界面检查 v 内容检查 v 数据格式和数据兼容性检查 v 地域特定操作系统和硬件设备的配置兼容性检查 v 其他 易用性测试 v UI界面静态测试 v UI交互信息测试 v UI逻辑流程测试 v 帮助设施测试 安全测试 v 权限授权测试 v 数据加/解密测试 v 抗攻击渗透能力测试 网站测试 v WEB页面测试（标题，文字，图片，链接，脚本，表单，表格) v 多用户测试 v 性能测试 v 压力测试 v WEB事物处理能力测试 v WEB安全测试 v 产品交互测试 v 产品输入输出测试 测试工具选择 v确定测

21、试工具应用范围 回归测试 压力测试 v确定使用工具 v编写有关脚本 参考资料参考资料 软件测试（美 RON PATTON著） 联想软件设计中心有关资料 谢谢谢谢 大家大家 第第10讲讲 因果图法因果图法 徐浙君 主要内容主要内容 因果图法 案例分析 因果图法的简介因果图法的简介 等价类划分方法和边界值分析法都是着重考虑输入条 件，并没有考虑到输入情况的各种组合，也没考虑到 各个输入情况之间的相互制约关系。 因果图方法的思路是：从用自然语言书写的程序规格 说明的描述中找出因（输入条件）和果（输出或程序 状态的改变），通过因果图转换为决策表。 因果图法因果图法 使用因果图法的优点： （1）考虑到了

22、输入情况的各种组合以及各个输入情况之间 的相互制约关系。 （2）能够帮助测试人员按照一定的步骤，高效率的开发测 试用例。 （3）因果图法是将自然语言规格说明转化成形式语言规格 说明的一种严格的方法，可以指出规格说明存在的不完 整性和二义性。 因果图因果图 因果图中有4种因果关系的基本符号,通常在因果 图中，用ci表示原因，ei表示结果，各结点表示 状态，可取值“0”或“1”。“0”表示某状态 不出现，“1”表示某状态出现。 因果图因果图 恒等 非 或 与 因果图因果图 恒等：若原因出现，则结果出现；若原因不出现，则结果 也不出现。 非()：若原因出现，则结果不出现；若原因不出现，结 果反而出现

23、。 或()：若几个原因中有1个出现，则结果出现；若几个 原因都不出现，则结果不出现。 与()：若几个原因都出现，结果才出现。若其中有1个 原因不出现，则结果不出现。 因果图中的约束因果图中的约束 因果图中的约束 在实际问题中输入状态相互之间、输出状态相互 之间可能存在某些依赖关系，称为“约束”。对 于输入条件的约束有E、I、O、R四种约束，对 于输出条件的约束只有M约束。 因果图中的约束因果图中的约束 异（ 互斥 ） E E约束(异)：a和b中最多有一个可能为1，即a 和b不能同时为1。 因果图中的约束因果图中的约束 I 约束(或)：a、b、c中至少有一个必须 为1，即 a、b、c不能同时为0

24、。 或（ 包含 ） I 因果图中的约束因果图中的约束 O约束(唯一)：a和b必须有一个且仅有一 个为1。 唯一 O 因果图中的约束因果图中的约束 R约束(要求)：a是1时，b必须是1，即a 为1时，b不能为0。 R 要求 因果图中的约束因果图中的约束 M约束(强制)：若结果a为1，则结果b强 制为0。 M 强制 因果图用法的因果图用法的4个步骤个步骤 1)分析程序规格说明的描述中哪些是原因，哪些是结 果。原因常常是输入条件或是输入条件的等价类， 而结果是输出条件。 2)找出原因与结果之间的因果关系、原因与原因之间 的约束关系，画出因果图。（在因果图中可以引入 一些中间节点） 3)将得到的因果图

25、转换为决策表。 4)为决策表中每一列所表示的情况设计一个测试用例。 因果图法测试举例因果图法测试举例 例例1 1：程序的规格说明要求：输入的第一个字符必 须是#或*，第二个字符必须是一个数字，此情况 下进行文件的修改；如果第一个字符不是#或*， 则给出信息N；如果第二个字符不是数字，则给出 信息M。 因果图法测试举例因果图法测试举例 （1）分析程序规格说明中的原因和结果： （2）画出因果图（编号为10的中间结点是 导出结果的进一步原因）： 原因结果 c1：第一个字符是# e1：给出信息N c2：第一个字符是* e2：修改文件 c3：第二个字符是一个数字 e3：给出信息M c 1 c 2 c 3

26、 e 1 1 0 e 2 e 3 E 因果图法测试举例因果图法测试举例 （3）将因果图转换成如下所示的决策表： 12345678 条件：条件： C1 C2 C3 10 1 1 1 1 1 0 1 0 1 1 1 0 0 1 0 1 1 1 0 1 0 1 0 0 1 0 0 0 0 0 动作：动作： e1 e2 e3 不可能不可能 测试用例测试用例#3#A*6*BA1GT 规规 则则 选选 项项 因果图法测试举例因果图法测试举例 （4）根据决策表中的每一列设计测试用例： 测试用例编号输入数据预期输出 1#3修改文件 2#A给出信息M 3*6修改文件 4*B给出信息M 5A1给出信息N 6GT给

27、出信息N和信息M 案例分析（中国象棋走马下法）案例分析（中国象棋走马下法） 例2：以中国象棋中马的走法为例，请绘制出因果 图和判定表。 案例分析（中国象棋走马下法）案例分析（中国象棋走马下法） 马的走法说明： 1、如果落点在棋盘外，则不移动棋子； 2、如果落点与起点不构成日字型，则不移动棋子； 3、如果落点处有自己方棋子，则不移动棋子； 4、如果在落点方向的邻近交叉点有棋子（绊马腿）， 则不移动棋子； 5、如果不属于1-4条，且落点处无棋子，则移动棋 子； 6、如果不属于1-4条，且落点处为对方棋子 (非老 将) ，则移动棋子并除去对方棋子； 7、如果不属于1-4条，且落点处为对方老将，则移

28、动棋子，并提示战胜对方，游戏结束。 案例分析（中国象棋走马下法）案例分析（中国象棋走马下法） 第一步：分析原因和结果 原因： 1、落点在棋盘外； 2、不构成日字； 3、落点有自方棋子； 4、绊马腿； 5、落点无棋子； 6、落点为对方棋子； 7、落点为对方老将。 结果： 21、不移动； 22、移动； 23、移动己方棋子消除对方棋子； 24、移动并战胜对方。 案例分析（中国象棋跳马下法）案例分析（中国象棋跳马下法） 第二步：画出因果图 案例分析（中国象棋走马下法）案例分析（中国象棋走马下法） 第三步：转换成判定表 案例分析（自动售货机）案例分析（自动售货机） 有一个处理单价为5角钱的饮料的自动售货

29、 机，其规格说明如下： （1）若投入5角钱或1元钱的硬币，押下 橙汁或啤酒的按钮，则相应的饮 料就送出来。 （2）若售货机没有零钱找，则一个显示 零钱找完的红灯亮，这时在投入1元硬 币并押下按钮后，饮料不送出来而且1元硬 币也退出来； （3）若有零钱找，则显示零钱找完的 红灯灭，在送出饮料的同时退还5角硬币。 请绘制出因果图和判定表。 案例分析（自动售货机）案例分析（自动售货机） 第一步：分析原因和结果 原因： 1、售货机有零钱找 2、投入1元硬币 3、投入5角硬币 4、押下橙汁按钮 5、押下啤酒按钮 结果： 21、售货机零钱找完灯亮 22、退还1元硬币 23、退还5角硬币 24、送出橙汁饮料

30、 25、送出啤酒饮料 案例分析（自动售货机）案例分析（自动售货机） 第二步：画出因果图 所有原因结点列在左边，所有结果结点列在右边。 建立中间结点，表示处理的中间状态。 中间结点： 11、投入1元硬币且押下饮料按钮 12、押下橙汁或啤酒的按钮 13、应当找5角零钱并且售货机有零钱找 14、钱已付清 案例分析（自动售货机）案例分析（自动售货机） 第二步：画出因果图 案例分析（自动售货机）案例分析（自动售货机）第三步：转换成判定表 因果图法总结因果图法总结 优点优点 1、因果图法能够帮助我们按照一定步骤，高效的选择测试用例，设 计多个输入条件组合用例。 2、因果图分析还能为我们指出，软件规格说明描

31、述中存在的问题。 3、可以依据因果图检验需求的逻辑和程序未来应包含的函数或方法。 缺点缺点 1、输入条件与输出结果的因果关系，有时难以从软件需求规格说明 书得到。 2、即使得到了这些因果关系，也会因为因果关系复杂导致因果图非 常庞大，测试用例数目极其庞大（需要使用正交表法简化需要使用正交表法简化）。 测试方法的选择 为了最大程度地减少测试遗留的缺陷，同时也 为了最大限度地发现存在的缺陷，在测试实施 之前，测试工程师必须确定将要采用的测试策 略和测试方法，并以此为依据制定详细的测试 方案。通常，一个好的测试策略和测试方法必 将给整个测试工作带来事半功倍的效果。 测试方法的选择 如何才能确定好的测

32、试策略和测试方法呢？通如何才能确定好的测试策略和测试方法呢？通 常，在确定测试方法时，应该遵循以下原则：常，在确定测试方法时，应该遵循以下原则： 根据程序的重要性和一旦发生故障将造成的损失来 确定测试等级和测试重点。 认真选择测试策略，以便能尽可能少地使用测试用 例，发现尽可能多的程序错误。因为一次完整的软 件测试过后，如果程序中遗留的错误过多并且严重， 则表明该次测试是不足的，而测试不足则意味着让 用户承担隐藏错误带来的危险，但测试过度又会带 来资源的浪费。因此，测试需要找到一个平衡点。 测试方法的选择 以下是各种测试方法选择的综合策略，可在实 际应用过程中参考。 首先进行等价类划分，包括输

33、入条件和输出条件的 等价划分，将无限测试变成有限测试，这是减少工 作量和提高测试效率的最有效方法。 在任何情况下都必须使用边界值分析方法。经验表 明用这种方法设计出测试用例发现程序错误的能力 最强。 对照程序逻辑，检查已设计出的测试用例的逻辑覆 盖程度。如果没有达到要求的覆盖标准，应当再补 充足够的测试用例。 如果程序的功能说明中含有输入条件的组合情况， 则应在一开始就选用因果图法。 Q & AQ & A 陈大卫 2021年10月25日 软件集成测试软件集成测试 一、集成测试及其目的 二、集成测试设计及准备工作 三、集成测试策略的选择 四、集成测试相关质量特性 五、集成测试的实施 六、面向对象

34、的集成测试 集成测试：是一个应用系统的各个部件的 联合测试，用以决定他们能否在一起共同 工作，部件可以是代码块、对象、独立应 用、网络上的客户端或服务器端程序。 目的：保证每一个功能模块的功能正确和 性能良好，以至于这些模块组装在一起时 他们可以很好地协调工作，保证整个系统 功能和性能的良好。 1. 集成测试的入口准则与输入： 前一阶段测试完成，测试报告被批准； 测试计划被批准 概要设计说明书被批准； 需求和需求规格说明书一致。 软件概要设计说明书 2. 通过概要设计，了解整个系统的组 织结构和开发顺序，选择适当的集成策 略，并根据接口描述和主要功能描述制 定集成测试计划、设计和用例。 3.

35、人员安排：集成测试既要求参与人熟悉 单元的内部细节，又要求他们能够从足够高 的层次上观察整个系统，因此一般由主要的 软件开发者协助测试人员来完成集成测试的 设计。 l 软件集成测试分单元级别，功能配置级别， 系统级别进行集成，过程比较复杂。 l 将集成测试设计转变为简明易懂的集成测试 用例。 l 定义集成测试环境。 l 建立测试通过和失败的准则。 l 估计人力和其他资源。 l 检查接口规格，功能流程在测试用例中的分 布。 l 由测试小组和开发小组对测试设计和用例 （即测试说明）进行评审。 4. 设计准备文档: 集成测试计划集成测试说明 l 非增量测试 l 增量测试 l 非增量测试 局部大爆炸：

36、在被组合成子系统之前， 对每个软件单元模块进行的测试，然 后对整个系统进行测试。 这种大爆炸的测试方法适用于那种测 试时间较短，结构不很复杂的系统的 集成测试。 l 增量测试 自顶向下：从最具控制力的软件单位 （主模块）开始，按控制层次减弱的 顺序向系统中增加模块，直至实现整 个系统。 l 增量测试 自底向上：从原子模块开始进行构造 和测试。一次向上提高一个级别，采 用驱动程序（一个供测试用的控制程 序）来驱动测试执行。从控制力最弱 的模块（程序结构的最底层模块）开 始，按控制层次增强的顺序向系统中 增加模块，直至实现整个系统。 l 增量测试 基于线程的测试：根据功能集成模块。 从一个功能开始

37、，用桩来替换这个功 能的相应的模块，直到这个功能的所 有模块被测试，然后再加入另外一种 功能，继续进行直到系统被测试完毕。 这种测试方法提供了更好的可见性并 能跟踪集成活动。 l 增量测试 自顶向下集成适用于几乎所有 范围或体系结构；自底向上集成在面 向结构的开发中非常有用，首先应确 保“低层模块组合能够实现软件特定 的子功能”，这种集成策略对小型到 中型系统比较有效；基于线程的测试 适用于那些功能流程较为清晰的系统。 练习：基于结构化的设计 (A)(C)(B) 上面三种结构中，哪种设计较好？ 上述系统应选择何种策略上述系统应选择何种策略 如果测试对象像图(A)那种比较理想的情 况，采用自底向

38、上或自顶向下、功能线 （Function Thread）和大爆炸（Big Bang）的测试策略均可。 如果出现像图(B)和(C)那样的情况，一 般来说采用两种方法来对付： 采用大爆炸的测试策略，先测试所有的单个 的集成测试粒度，然后组合起来进行总的测 试即可； 增粗测试粒度：把其中个别比较混乱的那部 分函数当作一个整体来进行测试，这样可能 比死抠单个函数测试效果要更好，遇到这种 情况要灵活应付。 集成测试阶段能够测试的质量特性有： 功能性、可靠性、效率、易维护性、 可移植性 可靠性（成熟性、容错性、易恢复性） 工具：BoundsCheck，检查程序是否 有资源、内存泄漏等，还可以检查测 试的代

39、码覆盖率。 效率（时间特性、资源特性）工具： Developepartner，可以检查每个函 数的运行效率。 l 集成测试环境的搭建 l 桩或驱动的制造 l 集成测试的测试点 l 集成测试的操作步骤 l 需要注意的问题 l 集成测试环境的搭建 搭建集成测试的运行环境，包括操 作系统、数据库、开发软件和所需的 测试工具。 设置系统运行所需的参数、数据初 始化工作。 l 桩或驱动的制造 在集成测试中，我们需要根据集 成测试策略的选取决定是否在测 试中制造桩或驱动，然后输入测 试数据进行测试并查看测试结果。 针对不同的代码版本，驱动和桩 一般不需要改变，但是测试用例 可能需要完善。 l 制造桩的目的

40、 模拟待测系统运行的实际环境， 为其提供可用来调用的模块。如 果为一个类制造桩，所要关心的 是该类中定义使用的其他类的实 例（对象）。即要搞清该类都使 用了哪些外部的资源。然后我们 以最简单的方式来提供这些资源。 l 制造驱动的目的 模拟待测系统运行的实际环境， 提供调用待测系统的模块。如果 为一个类制造驱动，所要关心的 是该类提供了哪些供调用的公有 函数。然后在驱动模块中对这些 函数进行调用，观察这些函数的 工作情况。这时就需要对函数的 调用参数，调用方式等方面设计 测试用例。 l 集成测试的测试点 接口测试：测试模块间的接口是否 吻合。 数据传递测试：各模块连接时，穿 越模块接口的数据是否

41、会丢失。例 如调用函数获得返回值、不同的模 块使用同一个数据。 l 集成测试的测试点 误差积累测试 ：由于原来可接受的误差 的积累可能导 致结果不可以接受，所有在测试方案中要 考虑那些模块 会产生误差，误差是否会积累，误差以什 么方式增长。 全局数据测试：考虑全局数据的有效期， 在有效期内对 其的操作是否合理，是否存在使用过期数 据的情况。 l 集成测试的测试点 负作用测试：测试某一个模块的功能是否 会对另一个模 块的功能产生不利的影响。如抢占资源、 破坏数据、安 全漏洞、性能瓶颈等。 组装功能测试：子功能组合是否能达到父 功能的预期要 求。 回归测试：在问题修改后，要对所有相关 模块再进行一

42、 轮测试，验证本次修改没有产生负作用。 l 集成测试的操作步骤 假定开发的软件系统按自底向上集成的方 式进行测试。 a.将最底层的功能模块进行分组，原则是 将那些与上层某个功能模块相关联的模 块分为一组。 b.对每一组分别进行测试，各组测试可并 行展开，这样可以加快测试的进程。 c.沿软件的结构，逐级向上集成，直到所 有的单元都组合到一起，这样就完成了 集成测试的任务。 l 集成测试的操作步骤 集成测试阶段是以黑盒测试为主，在自底 向上集成的早 期，白盒法测试占一定的比例，随着集成 测试的不断深 入，这种比例在测试过程中将越来越少， 渐渐地，黑盒 测试占据主导地位。 l 需要注意的问题 1.

43、类内部使用全局变量。 2. 类内部使用全局函数。 3. 类内部使用库函数。 4. 使用宏定义。 l 对于面向对象程序，相互调用的功能 是散布在程序的不同类中，类通过消 息相互作用申请和提供服务。类的行 为与它的状态密切相关，状态不仅仅 是体现在类数据成员的值，也许还包 括其他类中的状态信息，类相互依赖 极其紧密。 l 面向对象的集成测试能够检测出相对 独立的单元测试无法检测出的那些类 相互作用时才会产生的错误。基于单 元测试对成员函数行为正确性的保证， 集成测试只关注于系统的结构和内部 的相互作用。面向对象的集成测试可 以分成两步进行：先进行静态测试， 再进行动态测试。 l 静态测试:静态测试

44、主要针对程序的结构进 行，检测程序结构是否符合设计要求。这 种方法的主要特性是不利用计算机运行被 测试的程序，而是采用其他手段达到检测 的目的。 l 动态测试 :实际运行被测程序，输入相应 的测试用例，判定执行结果是否符合要求， 从而检验程序的正确性、可靠性和有效性。 具体设计测试用例，可参考下列步骤： 1. 先选定检测的类，仔细找出类的 状态和相应的行为，类或成员函数间 传递的消息，输入或输出的界定等。 2.确定覆盖标准。 3. 利用结构关系图确定待测类的所 有关联。 4.根据程序中类的对象构造测试用 例，确认使用什么输入激发类的状态、 使用类的服务和期望产生什么行为等。 值得注意，设计测试

45、用例时，不但 要设计确认类功能满足的输入，还应 该有意识的设计一些被禁止的例子， 确认类是否有不合法的行为产生，如 发送与类状态不相适应的消息，要求 不相适应的服务等。根据具体情况， 动态的集成测试，有时也可以通过系 统测试完成。 值得注意，设计测试用例时，不但 要设计确认类功能满足的输入，还应 该有意识的设计一些被禁止的例子， 确认类是否有不合法的行为产生，如 发送与类状态不相适应的消息，要求 不相适应的服务等。根据具体情况， 动态的集成测试，有时也可以通过系 统测试完成。 以C+语言和测试粒度定为类的情况 为例，一般来说因为考虑到类的重用 和继承，类之间的关系可能会比较复 杂，建议采用大爆

46、炸(Big Bang)或功 能线(Function Thread)的测试策略 比较好。 谢谢 大家 系统测试介绍系统测试介绍 陈大卫 2021年10月25日 培训内容培训内容 1、总体介绍 2、系统测试过程 附录：测试环境配置 1.总体介绍总体介绍 系统测试（系统测试（system test）：是将通过确认测试 的软件，作为整个基于计算机系统的一个元素， 与计算机硬件、外设、某些支持软件、数据和 人员等其他系统元素结合在一起，在实际运行 （使用）环境下，对计算机系统进行一系列的 集成测试和确认测试。 系统测试技术系统测试技术 系统测试支持技术 网络及编程技术； 数据库技术； 系统测试技术 系统

47、测试指南、方法、技巧 2.系统测试过程系统测试过程 测试计划与准备 测试设计与开发 测试实施 测试总结与评估 测试计划与准备测试计划与准备 测试环境准备和搭建 技能培训 测试小组的建立 风险估计 测试设计与开发测试设计与开发 测试策略 测试用例总体设计 测试用例详细设计 测试用例编写 测试实施测试实施 安装测试 功能确认测试 并发/强度测试 恢复性测试 安全测试 测试实施测试实施 性能测试 配置测试 帮助系统检查 辅助功能测试 测试总结与评估测试总结与评估 参考资料参考资料 软件工程-实践者的研究方法（美 ROGER S PRESSMAN著） 软件测试中心技术架构-系统测试 附录：测试环境配置

48、附录：测试环境配置 配置测试环境工作量可能非常巨大，因 为测试环境要考虑各种软硬件配置，做 到完整全面的配置测试，检查所有可能 的制造者和型号组合实际上是不可行的。 所以，测试环境的配置工作具有一定的 难度和挑战，关键在于如何选取这些配 置 。 测试环境配置的步骤测试环境配置的步骤 1. 确定所需的软硬件类型。 2. 确定软硬件配置具体品牌和型号。 3. 将明确后的软硬件配置缩减为可控制范围。 4. 明确使用软硬件配置的特性、模式或选项。 5. 设计测试环境配置的组合，并对应到测试说 明中。 6. 在各种配置中执行测试。 7. 对存在问题的环境配置进行修改并做回归测 试。 测试环境配置的原则测

49、试环境配置的原则 符合软件运行的最低要求。测试环境首先要保 证能支撑软件正常运行。 选用比较普及的操作系统和软件平台。 营造相对简单、独立的测试环境。除了操作系 统，测试机上只安装软件运行和测试必需的软 件，以免不相关的软件影响测试实施。 无毒的环境。利用有效的正版杀毒软件检测软 件环境，保证测试环境中没有病毒。 其他测试环境配置原则其他测试环境配置原则 兼容性测试原则兼容性测试原则：在满足软件运行要求 的范围内，可选择一些典型的操作系统 和常用应用软件对其安装卸载和主要功 能进行验证。 数据共享测试原则数据共享测试原则：选择一些可能会与 被测软件有数据接口或公用数据的软件 环境，并针对这种数

50、据共享特性进行测 试。 模拟真实环境测试原则模拟真实环境测试原则：有些软件，特 别是面向大众的商品化软件，在测试时 常常需要考察在真实环境中的表现。如 测试杀毒软件的扫描速度时，硬盘上布 置的不同类型文件的比例要尽量接近真 实环境，这样测试出来的数据才有实际 意义。 纵向配置原则纵向配置原则：各个辅测试环境的关键 计算机配置完全不同，以尽可能多地覆 盖软硬件环境配置。 谢谢 大家 白盒测试技术 陈大卫 2021年10月25日 目录目录 语句覆盖 分支覆盖（判定覆盖） 条件覆盖 分支-条件覆盖 多重条件覆盖 路径覆盖 逻辑测试比较 被测试程序结构被测试程序结构 语句覆盖语句覆盖 语句覆盖就是设计