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

第一章·软件工程概述：

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

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

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

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

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

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

2、过程模型

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

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

1、计划项目

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

2、管理项目

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

第四章·需求分析：

了解需求：需求是什么（需求是用户对软件系统期望行为的综合描述）、需求的类型（功能性需求、非功能性需求）、需求的特征（一致性、正确性、无二义性、完备性、可行性等）、需求的表示（UML图）
引出需求：风险承担者、引出需求的方式（会谈、特别关注、观察、查看文档）
需求前期处理：优先级划分、需求规范化（正式名字、唯一定义、量化描述）
需求下的约束：设计约束（之前的设计决策对现在决策的约束）、过程约束（现在技术和资源对决策的限制）
需求分析全过程：原始需求获取、问题分析、规格说明草稿、需求核准、软件规格说明书（SRS）

第五章·系统体系结构：

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

第六章·考虑对象：

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

第七章·编写程序：

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

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

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

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 配置计划的必要性

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

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 因果图法产生的背景

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

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

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