【软件工程】第九章·系统测试（因果图全解析）

1. 前言

在进入本篇文章前，大家可以按需求看看另几篇文章：

这几篇文章将让你对软件工程有一个整体的脉络，并在细节上有一定的把控🐮🐮

本文参考书籍：软件工程 第4版（ ）

2. 前景知识回顾

第一章·软件工程概述：

        1、软件工程是什么——定义、方法、作用。

        2、软件工程的前世今生——出现的问题（error、fault、failure）、应对方法（问题分析方法+系统化方法+工程化方法）。

        3、软件工程的未来——Wasserman 规范（抽象、分析设计方法和符号描述系统、软件过程、软件体系结构、重用和复用、用户界面原始模型、测试代码、工具和集成环境）

第二章·软件过程与生命周期：

        1、过程与生命周期是什么

• 过程是一系列有序的任务，涉及活动、资源和约束（过程不是步骤而是步骤的集合）。
• 生命周期是软件从概念、实现、交付到使用、维护的整个过程。软件开发全过程称为软件生命周期。

        2、过程模型

• 种类：瀑布模型、原型化瀑布模型、V模型、原型化模型、阶段化开发模型、螺旋模型、敏捷方法模型
• 联系：
  • 瀑布模型是基础。
  • 原型化瀑布模型结合原型化模型与瀑布模型（设计阶段产生原型化模型，在测试阶段考虑是否返回）。
  • V模型（将设计与测试之间都建立起通道）。
  • 原型化模型（不是具体模型，是一种思想，每一个步骤都可以产生原型去分析）。
  • 阶段化开发模型（开发版本和使用版本分离，分离导致需要选择迭代开发/增量开发/迭代进化开发/统一过程开发）。
  • 螺旋模型（是迭代思想和原型化思想的结合）。
  • 敏捷方法模型（撇弃原型化和迭代化带来的冗余，将目标转化为：快【尽早交付】、准【持续有价值的软件交付活动】、狠【直到客服满意】）（四大原则：个体和交互胜过过程和工具、可运行软件胜过面面俱到的文档、客户合作胜过合作谈判、响应变化胜过遵循计划）
• 核心思想：迭代思想、增量思想、原型化思想

第三章·计划和管理项目：

        1、计划项目

• 时间计划：项目进度、项目活动、里程碑、活动图、最早开始时间、最迟开始时间、冗余时间、关键路径。
• 工作量计划：估（专家估算：Delphi技术、乐观悲观法、Wol技术）、算（算式公式：（a+bSc）m（X）、COCOMO模型：aKLOC^b）

        2、管理项目

• 人员管理：人员技术、工作方式、项目组织安排（结构性与创造性、一个领导模式、忘我方法模式）
• 风险管理：什么是风险、风险管理活动（风险评价：风险识别、风险优先级、风险分析）（风险控制：风险降低、风险化解、风险管理计划）、风险降低（风险避免、假设风险、转移风险）、风险化解（6种风险的6种应对方式：产品过大、功能复杂、系统不支持、测试时间、产品控制、协同工作）

第四章·需求分析：

第五章·系统体系结构：

1. 系统体系结构设计相关概念：体系结构、设计、例程设计、创新设计、克隆、参考模型、体系结构风格、设计模式、设计原则、设计公约、模块化、概念/技术设计。
2. 系统体系结构设计全过程：建模、分析、文档化、复审、形成最终文档（SAD）。
3. 体系结构质量标准：可修改性、可维护性、性能、安全性、可靠性、健壮性等。
4. 建模核心——分解：分解是什么、分解的六大方法。
5. 分解目的——模块化：模块化是什么、模块化的目的——模块性（内聚与耦合）。
6. 体系结构的评估改进：故障树与割集树、错误语法与处理、复审（验证与确认）
7. 常见的体系结构：管道和过滤器、隐含调用、面向对象、CS、发布订阅、分层等。

第六章·考虑对象：

1. UML统一建模语言：几大类型的图（在不同层面反应软件系统的特点）
2. UML建模语言在软件开发中的应用：需求分析（用例图、概念类图、数据流图）、设计（对象图、类图、活动图、状态图、顺序图和协作图）、编码与测试（包图、部署图、构件图）
3. 面向对象的软件开发：什么是面向对象（含义、七大特征、优势、三个观点）、面向对象开发过程概述（需求分析：确定类、确定类的动态行为）（设计：系统设计、程序设计）（编码与测试）、面向对象开发过程详细（加入UML图更加详细说明每一个部分需要干的事情）

 第七章·编写程序：

1. 编程标准：编程包括（代码编写+文档书写）、编程标准对自身的作用（早期、中期与后期）、编程标准对他人的作用（重用、测试与维护）、最大的编程标准（设计与编程实现相匹配）
2. 编程指导原则：三个角度指导编程（数据结构、算法、控制结构）、通用编程策略（重用、设计包含伪代码、改动时重新开始不打补丁、局部化输入输出
3. 文档化：内部文档（头注释块、变量名和语句注释、过程注释）、外部文档
4. 编程过程：编程全过程（理解问题、制定计划、执行计划和回顾）、极限编程（交流、勇气、简单性以及反馈）、结对编程

第八章·单元/集成测试：

1. 为什么要测试：错误、故障和失效（彼此关系、故障分类、正交性）。
2. 测试的分类：单元测试、集成测试、系统测试（功能测试、性能测试、验收测试、安装测试）。
3. 测试的方法：黑盒测试、白盒测试。
4. 单元测试：检测代码（代码复审：代码走查和代码检查）、测试程序构件（运用黑盒/白盒测试方法都可以）。
5. 集成测试：自底向上的集成测试；自顶向下的集成测试、一次性集成、三明治集成
6. 面向对象系统的测试：增加对类、对象等额外步骤的测试与检查

3. 章节概述和章节框架

明确一个点：Wasserman 规范（抽象、分析设计方法和符号描述系统、软件过程、软件体系结构、重用和复用、用户界面原型、测试、工具和集成环境）贯穿软件开发全过程。

章节联系：本章节就是Wasserman规范中的一个。通过前面的学习，我们已经接触了软件过程（软件过程本身）、计划和管理软件项目（抽象）、需求分析（抽象）、软件体系结构（软件体系结构本身）、考虑对象（分析方法和符号描述系统）、编写程序（重用和复用、用户界面原型）【括号内为章节和Wasserman规范的对应】。接下来，我们学习测试，这也是Wasserman规范中重要的一部分。

思考：本章节和第八章·测试 严格来说是一个部分。测试分为：单元测试/集成测试与系统测试，第八章介绍了单元/集成测试，本章将专注于系统测试部分。

        系统测试与单元测试和集成测试的不同在于，系统测试需要与整个开发团队一起工作、协调你做的工作并且接受测试小组组长的指导；而单元测试时你可以完全控制测试过程——自己设计测试数据、测试样例、运行测试；集成构件时，虽然有时独自工作，但通常是测试小组或者开发团队的一些人合作。在本章内，我们将会讨论测试系统所包含的功能测试、性能测试、验收测试、安装测试。

系统测试将是一整个测试团队+开发团队的共同任务

4. 系统测试

来一张测试总图🎄🎄：

4.1 系统测试综述 

4.1.1 软件缺陷的来源

前言：

        第八章中，我们针对错误、故障和失效有了很详细的讨论。并且探讨了故障的类型，力求根据故障类型来判断造成故障出现的错误是什么。但是这一切的分析都是局限性的，是针对软件编写过程中出现的故障以及故障发生原因的分析。

        系统测试中的错误可能发生在软件开发的整个环境，而不仅仅是编码阶段，因此对于故障的讨论需要更大的范围。

软件缺陷可能存在于软件设计开发过程中的任何一个部分。其中：
        (1)需求分析：不正确、遗漏或者不清晰的需求；
        (2)系统设计：对需求设计的误读，不正确或不清晰的设计规格说明；

        (3)程序设计：对系统设计的误读，不正确或不清晰的设计规格说明；
        (4)程序实现：对程序设计的误读，不正确的文档，不正确的语法语义；

        (5)单元/集成测试：不完全的测试过程，改正已有故障时引入新故障；

        (6)系统测试：不完全的测试过程，改正已有故障时引入新故障；
        (7)维护：需求变化，错误的用户文档，负面的人为因素，改正已有故障时引入新故障。

4.1.2 系统测试的目的

        (1)测试过程应该有足够的完全性，如果测试过程是不全面的，故障扔可能检测不到，所以越早检测出故障越好，早期检测出的故障更容易改正；
        (2)测试过程应该使每一个人都对系统功能感到满意，包括用户、客户和开发人员，因为在大型系统中，必定会存在一些用户允许存在的，当时不必修复的缺陷存在。

4.1.3 系统测试的主要步骤及目标

        (1)功能测试——核查开发者的SRS（系统功能需求）
        (2)性能测试——核查开发者的SRS（其他软件需求）
        (3)验收测试——核查客户和开发者的SRS（用户需求定义）
        (4)安装测试——用户环境

4.2 系统配置

4.2.1 系统配置定义

        向特定客户交付的一系列部件的集合（产品）。

每一个系统配置都是一个针对特定用户的产品 

4.2.2 配置管理

        对系统不同软件配置的管理及控制方法（其中既有开发，也有测试）。通过控制系统差别以降低风险，减少错误。它的重要性在于它协调测试人员与开发人员之间的工作，从而获取有效配置。

4.2.3 配置管理计划

        SCM 流程旨在确保在任何时候产品的内容都是已知的、可用的，以及在设计到实施的过程中，产品的功能都是可跟踪的，可以完全控制和保护产品的内容。 

换句话说：就是通过文档等方式对软件开发全过程中发生的所有事情进行跟踪。 

制订配置管理计划的主要步骤如下：

        （1）建立并维护配置管理的组织方针

        （2）确定配置管理需使用的资源

        （3）分配责任

        （4）培训计划

        （5）确定“配置管理”的项目干系人，并确定其介入时机

        （6）制订识别配置项的准则

        （7）制订配置项管理表

        （8）确定配置管理软硬件资源

        （9）制订基线计划

        （10）制订配置库备份计划

        （11）制订变更控制流程

        （12）制订审批计划

4.2.4 配置计划的必要性

1. 如果不使用适当的配置管理计划，我们就经常无法知道哪一个模块是被确定、增强或测试过的。
2. 我们会开发出功能错误或是缺少功能的产品来，而且我们不知道哪些测试正在进行，哪些缺陷已被确定。
3. 我们不得不重新整理已经完成了的工作。

4.2.5 管理计划对系统测试的目标

        迅速准确地进行测试。

4.2.6 基线

        软件文档和其他资料的集合，它们代表了产品在某一时间点的情况(以及其他参考点)。

4.2.7 配置管理计划关键的功能

        (1)每个产品元素（部件）版本的复件；
        (2)对每一个基线修改的记录；（修改内容的说明：修改位置，修改时间，修改内容等）
        (3)他们什么时候改变的；
        (4)改变具体内容是什么；
        (5)为什么他们要进行改变。
        (6)可能涉及的其他功能等等(从涉及的基本文档开始统计)。

        (7)谁进行了这个改变

4.2.8 版本(version)与改进版本/发布(release)定义

        Version:针对特定系统的特定配置
        Release:针对旧版本的改进版本
        Version n.m=Version n and release m.

4.3 回归测试

4.3.1 回归测试定义

       回归测试是软件开发过程中验证最近更改或更新是否引入新错误或影响原有功能的质量控制过程。（新旧测试用例同时进行测试）

新版本/改进版本是否仍然和旧版本一样以同样方式执行同样功能

4.3.2 测试小组关注人群

        单元测试、集成测试：主要为开发者；
        功能测试、性能测试：主要为开发者；
        验收测试、安装测试：主要为用户；

（因此，程序员不能参与自己负责的模块相关的测试工作。）

4.3.3 测试小组组成

        (1)专业测试人员：集中于测试开发、方法和过程；

        (2)分析员：以需求创建者的立场参与测试；
        (3)系统设计人员：了解系统运作，可以使测试工作更有目的性；
        (4)配置管理代表：出现失效或变化请求时安排变动，使变动反映在文档、需求、设计、代码或者其他开发制品中。
        (5)用户：对所发布的软件进行评估。

4.4 功能测试

4.4.1 功能测试含义与作用

        测试功能性需求（SRS的）
        有很高的故障检测概率（因为一项功能测试只面向一小组组件）。

4.4.2 有效的功能测试指导原则

(1)高故障检测概率；
(2)使用于设计人员和程序员的测试小组；

(3)了解期望的动作和输出；
(4)既要测试合法输入，也要测试不合法输入；

(5)制定停止测试的标准。

4.5 因果图

4.5.1 因果图定义

• 因果图法是一种利用图解法分析输入的各种组合情况，从而设计测试用例的方法，它适合于检查程序输入条件的各种组合情况
• 特点：
  1.考虑输入条件的相互制约及组合关系
  2.考虑输出条件对输入条件的依赖关系

4.5.2 因果图法产生的背景

• 等价类划分法和边界值分析法都是着重考虑输入条件，但没有考虑输入条件的各种组合，输入条件之间的相互制约关系，这样虽然各种输入条件可能出错的情况已经测试到了，但多个输入条件组合起来可能出错的情况却被忽视了。
• 如果在测试时必须考虑输入条件的各种组合，则可能的组合数目将是天文数字，因此必须考虑采用一种适合于描述多种条件的组合，相应产生多个动作的形式来进行测试用例的设计，这就需要利用因果图（逻辑模型）。

如果你没有考虑多个输入条件的 组合效果，那么可能会出现一些组合条件下的潜在错误，例如：

• 用户选择了负数的商品数量，且选择了信用卡支付方式。这时，如果系统没有验证“商品数量”与“支付方式”之间的逻辑关系（比如“商品数量”过大可能无法支付，或者支付方式了最大购买数量），系统可能会出现支付失败或价格错误等问题。
• 用户输入了一个非常远的收货地址（如偏远地区），而且选择了 支付宝支付。如果系统没有处理某些支付方式和地区的约束（比如某些支付方式不支持该地区的支付），可能会导致支付流程出错，而不是只在支付阶段处理支付信息错误。

4.5.3  因果图的核心

        因果图法比较合适输入条件比较多的情况，测试所有的输入条件的排列组合，所谓的原因就是输入，所谓的结果就是输出。

• 因果图的“因“—输入条件
• 因果图的“果”—输出结果

因果图法要注意考虑：

• 所有输入/输出条件的相互制约关系以及组合关系
• 输入条件的依赖关系，也就是什么样的输入组合会产生怎么样的输出结果，即“因果关系”

4.5.4 因果图中的基本符号

        通常在因果图中用Ci表示原因，用Ei表示结果，各结点表示状态，可取值‘0’或‘1’。‘0’表示某状态不出现‘1‘表示某状态出现。

4.5.5 因果图构件步骤

利用因果图导出测试用例需要经过一下几个步骤：

1. 找出所有的原因，原因即输入条件或输入条件的等价类。
2. 找出所有的结果，结果即输出条件。
3. 明确所有输入条件之间的制约关系以及组合关系。（哪些条件不能组合到一起，哪些条件可以组合到一起）
4. 明确所有输出条件之间的制约关系以及组合关系。（哪些输出结果不能同时输出，哪些输出结果可以同时输出）
5. 找出什么样的输入条件组合会产生哪种输出结果。
6. 把因果图转换成判定表/决策表

4.5.6 小案例·交通一卡通自动充值软件系统需求

• 系统只接收50或100元纸币，一次只能使用一张纸币，一次虫子金额只能为50元或100元；
• 若输入50元纸币，并选择充值50元，完成充值后退卡，提示充值成功；
• 若输入50元纸币，并选择充值100元，提示输入金额不足，并退回50元；
• 若输入100元纸币，并选择充值50元，完成充值后退卡，提示充值成功，找零50元；
• 若输入100元纸币，并选择充值100元，完成充值后退卡，提示充值成功；
• 若输入纸币后在规定时间内不选择充值按钮，退回输入的纸币，并提示错误；
• 若选择充值按钮后不输入纸币，提示错误

构件因果图步骤如下：

1、找出输入输出，并确认其中的约束关系

2、分析输入输出之间 的因果关系（仅仅举两个例子）：

（这里的组合一次只展示一个测试用例）

3、根据因果图画出最后的表格（和2中对应，只有两个测试用例）：

4.6 性能测试

        性能测试与需求的质量有密切的关系，需求文档需要足够完备才能确保性能测试的成功进行。因此需求的质量通常可以反映在性能测试的容易度上。

核心思想：

        1、性能测试的容易程度和需求文档质量挂钩。

        2、因为性能部分是需求文档中相当容易被忽略的部分，如果这一部分仍然处理的很好就说明需求文档整体就是很好。

4.6.1 性能测试目的与职责

• 性能测试所针对的是非功能需求。它需要确保这个系统的可靠性、可用性与可维护性。
• 性能测试由测试小组进行设计和执行并将结果提供给客户。

4.6.2 性能测试种类

• 压力测试(短时间内加载极限负荷，验证系统能力)
• 容量测试(验证系统处理巨量数据的能力)
• 配置测试(测试各种软硬件配置(最小到最大))
• 兼容性测试(如果它与其他系统交互时)
• 回归测试(通过新旧两个测试用例同时进行)
• 安全性测试
• 计时测试
• 环境测试
• 质量测试
• 恢复测试
• 维护测试
• 文档测试
• 人为因素测试/可使用性测试

•  4.6.3 可靠性、可用性与可维护性定义(括号内为取值范围)

• 可靠性：一个系统对于给定时间间隔内、在给定条件下无失效运作的概率。(0~1)
• 可用性：在给定的时间点上，一个系统能够按照规格说明正确运作的概率。(0/1)
• 可维护性：在给定的使用条件下，在规定的时间间隔内，使用规定的过程和资源完成维护活动的概率。(0~1)

可靠性的关键：给定条件（是否可靠要看在极度恶劣条件下是不是仍然可以运行）

可用性的关键：按照SRS正确运作（只有正确运作才算可用）

可维护性的关键：使用规定过程和资源完成维护活动

4.7 验收测试

4.7.1 验收测试目的与职责

• 验收测试的目的是使客户和用户能确定我们构建的系统真正满足了他们的需要和期望。
• 验收测试的编写、执行和评估都是由客户来进行的。只有在请求某个技术问题的答案的时候才会需要开发人员。

4.7.2 验收测试的种类

(1)基准测试
        由用户准备典型测试用例，在实际安装后的系统运作并由用户对系统执行情况进行评估。
(2)引导测试
        在假设系统已经永久安装的前提下执行系统。它依赖系统的日常工作进行测试，相对基准测试不是非常的正式与结构化。
(3)并行测试

        并行测试是一种软件测试方法，通常应用于系统升级或版本切换的场景。在并行测试过程中，新旧版本的系统同时运行，并允许用户在一段时间内同时使用旧版和新版软件。这样可以逐步过渡到新系统，确保新版本的功能和性能不会影响到现有用户的操作，同时也帮助用户适应新版系统的变化。

4.7.3 α测试与β测试

        α测试：在向客户发布一个系统之前，先让来自己组织机构或公司的用户来测试这个系统。在客户进行实际的试验性测试前先试验这个系统。
        β测试：客户的试验成为β测试。

4.7.4 验收测试的结果

(1)让用户能够验证他的需求是怎样被实现的；

(2)让客户发现需求中模糊的定义。
(3)改需求
(4)如果配置管理人员，则可以记录软件所有的变更。

4.8 安装测试

4.8.1 安装测试定义

        在用户环境中配置系统，以测试可能因为开发环境与用户环境的不同而导致的问题。

4.8.2 安装测试目的

        安装系统的完备性，验证任何可能受场所条件影响的功能和非功能特性。

5. 总结

 本文到这里就结束啦~~

目前【软件工程】系列已经完成：

到这里【软件工程】系列的知识讲解就更新完毕🎢🎢🎢

如果觉得对你有帮助，友友们可以点个赞，收个藏呀~