软件测试期末（自用）

part1软测基础

软件危机

​ 落后的软件生产方式无法满足迅速增长的计算机软件需求，导致开发和维护中出现一系列严重问题

原因和解决

​ 一方面与软件本身有关，另一方面与软件开发和维护方法不正确有关

​ 解决：软件工程

软件工程

​ 研究软件生产的客观规律性，建立系统化软件生产有关的概念、原则、方法等。以达到减低软件生产成本、改进质量等目标

软件生存周期

​ 计划-需求分析-设计-编码-测试-运行维护

软件

​ 程序（完成预订功能和性能的集合）+数据（依照某种数据模型组织并存储的数据集合）+文档（文字和图像集合）+服务（以某种方式满足需求的方式）

软件测试

IEEE1983

​ 通过人工和自动手段运行或测试某个系统的过程，目的在于检验被测软件系统是否满足规定的需求，或搞清预期结果与实际结果的差别

​ 为什么要做软件测试？

​ 确保产品满足规定的需求

​ 目的是什么？

​ 通过设计和运行测试用例来衡量产品的预期结果与实际结果是否有差别

​ 软件测试以需求为中心，开发过程中围绕：定义需求-分析需求-实现需求-校验需求

​ 软件测试的方式和手段？

​ 方式：动态测试，通过运行被测程序，检查运行结果与预期结果的差异（黑盒、白盒测试）和静态测试，不运行被测程序，仅通过分析和检查源程序的语法和结构等检查程序的正确性（代码检查、静态结构分析）

​ 手段：人工测试/自动化，

基本流程

1.需求分析

​ 包括软件功能需求分析（最基本）、测试环境需求分析、测试资源需求分析等

2.制定测试计划

​ 输入：需求规格说明书、总体计划

​ 输出：测试计划

​ 目的：识别任务、分析风险、规划资源和确定进度

3.设计测试用例

​ 输入：不同阶段确定的测试需求：概要设计、详细设计等文档和测试计划

​ 输出：设计测试用例和测试过程

​ 目的：确保测试用例完全覆盖测试需求

4.执行测试

​ 输入：测试用例、测试过程、测试计划、测试需求

​ 输出：测试驱动模块、测试脚本、缺陷报告

​ 过程：搭建环境、执行测试用例、检查结果、编写缺陷报告、提交缺陷报告

5.测试评估

​ 输入：测试用例、缺陷报告、测试标准

​ 输出：测试评估报告

6.测试总结

7.测试维护

软件缺陷

​ 软件出现了需求规格说明书中指明不会出现的错误（运行出现错误，无论是否有用，都算软件缺陷）

​ 软件功能超出需求规格说明书中指明的部分

​ 软件未达到需求规格说明书虽未指出但应该达到的目标（断网等）

​ 正式定义：产品内部来看，缺陷是软件产品开发或维护过程中存在的错误等各种问题；从产品外部来看是系统所需要实现的某种功能的失效或者违背

测试用例

​ 一组测试输入、执行条件和预期结果，目的是满足一个特定的目标，比如执行一条特定程序路径或检验是否符合一个特定的需求用例

基本属性

​ 典型性、可测试性、可重现性、独立性

软件质量

​ 反综合

​ 软件测试不能提高软件质量（预防产生质量，检验不能提高质量）

软件测试分类

​ 按测试方式和被执行对象：动态测试和静态测试

​ 是否人工干预：手工测试和自动化测试

​ 测试方法和测试技术：黑盒、白盒、灰盒测试

​ 测试过程或开发阶段：单元测试（测试某个特定功能）、集成测试（测试软件 单元是否能进行正常交互）、系统测试（将通过其他测试的软件与系统其他部分结合起来通过测试发现其潜在问题）和验收测试（确定系统是否符合其验收标准）

​ 测试目的：功能测试、接口测试、用户界面测试、健壮性测试（注重对程序容错率的测试）等

part2白盒测试

基本原理

​ 侧重系统或部件内部的测试，类型分为分支测试、路径测试、语句测试

关注对象

​ 源代码：阅读代码，检查规范性，找出逻辑缺陷、内存管理缺陷等

​ 程序结构：使用程序设计的相关图表等找到其设计缺陷，利于程序的结构优化

优劣

​ 优：针对性强，可以可以快速定位，效率较高

​ 在函数级别开始工作，缺陷修复成本低

​ 有助于代码优化和缺陷预防

​ 缺：对测试人员的技术要求高

​ 成本高，准备时间较长

控制流分析

​ 一类用于分析程序控制流的静态分析技术

​ 控制流图也叫流程图

​ 分为动态白盒测试（结构化测试，在使用和运行程序的条件下，测试人员通过查看代码来决定哪些需要测试）和静态白盒测试（结构分析，不执行软件的条件下找出软件缺陷的过程）

逻辑覆盖测试

​ 以程序内部的逻辑结构为基础的用例设计方法，通过对程序的逻辑结构的遍历，实现对程序的覆盖

​ 分为：语句覆盖、判定覆盖、条件覆盖、判定-条件覆盖、条件组合覆盖、路径覆盖

​ 覆盖率=至少被执行一次的item总数/item总数

​ 以程序内部的逻辑结构为基础的用例测试方法，通过对程序的逻辑结构的遍历实现测试对程序的覆盖

​ 基本原则：对所有逻辑值，都要测试其真假

语句覆盖

​ 设计测试用例时保证程序每条执行语句至少执行一次

​ 不能发现所有的错误（如与或等）

判定覆盖

​ 保证程序的每一个判定节点取得的每种可能结果至少执行一次或真假分支至少执行一次

​ 不能发现所有的错误（如与或等）

条件覆盖

​ 保证程序中每个符复合判定表达式中，每个简单的判定条件真假各取一次

​ 不能发现所有的错误（不会对判定节点的整体完全覆盖）

判定-条件覆盖

​ 满足判定节点取真假至少一次，且每个自条件的真假情况也应执行一次

条件组合覆盖

​ 满足每个判定节点中所有简单的判定条件的所有可能的取值组合至少取一次

​ 满足上述4条覆盖，但是冗余严重

路径覆盖

​ 覆盖程序中所有可能组合的路径

基本路径测试

基本路径

​ 在程序控制流程图中，基本的、可执行的独立路径集合

环复杂度

直接观察法：内环个数+外环个数（大部分为1）

公式计算法：1.V=e-n+2 e为边数，n为节点数 单入口单出口

​ 2.V=e-n+1 程序图中无孤立节点，为强连通图（任意两个节点都存在路径），否则加辅助线

判定节点法：V=P+1 P为两分支判定节点数

流程

1.生成路径地图（控制流图）

2.确定独立路径集合的规模，即环复杂度

3.找出一组独立路径：确定主路径（最长的）–根据主路径选取其他独立路径

静态白盒测试

跳过！

part3黑盒测试

​ 以用户角度，从输入与输出数据的对应关系出发进行的测试

​ 1.检查功能是否遗漏，特性要求是否满足

​ 2.检测人机交互、数据结构、外部数据库访问是否错误等

​ 3.检测程序初始化和终止方面是否有误

优劣

​ 优：简单有效，可以整体测试系统行为，对测试人员技术要求较低

​ 劣：代码得不到测试、测试不充分、自动化测试复用性较低、结果准确性取决于用例的设计

等价类划分

​ 把所有可能的输入数据（互不相交的子集），称为等价类，所有的子集并集构成整个输入域，再从每个子集中选取少量有代表性的数据作为测试用例

等价类分类

​ 有效等价类：合理、有意义的输入数据

​ 无效等价类

​ 若某个输入条件指定一个连续的有效取值范围，则可以定义一个有效等价类和两个无效等价类

可以有多个有效等价类，如是否合格（是、否均为有效等价类）

​ 1.分析并确定等价类

​ 2.建立等价类表，列出所有划分出的等价类

​ 3①为每个等价类规定一个唯一的编号

​ ②对于有效等价类设计一个新的测试用例，使其尽可能覆盖尚未被覆盖的有效等价类，重复直到所有有效等价类被覆盖

​ ③对于无效等价类设计一个新的测试用例，使其只覆盖尚一个未被覆盖的无效等价类，重复直到所有有效等价类被覆盖

覆盖标准

​ 弱覆盖：覆盖所有有效等价类

​ 强覆盖：覆盖所有有效等价类的所有组合

边界值测试

​ 1.确定输入条件

​ 2.确定每个输入条件的边界点

​ 3.划定边界邻域delta

​ 4.每个边界对应三个测试数据

​ 5.单边界设计测试用例

标准边界值测试

​ 只考虑有效数据范围内的边界值

​ 对一个有n个变量的程序，保留其中一个，取：

​ 1.最小值 2.略高于最小值 3.正常值 4略低于正常值 5.最大值

​ 让其他变量取正常值，则本程序会产生4n+1个测试用例

健壮边界值测试

​ 考虑有效和无效数据范围内的边界值

​ 取：

​ 1.略低于最小值 2.最小值 3.略高于最小值 4.正常值 5.略低于最大值 6.最大值 7.略高于最大值

​ 产生6n+1个测试用例

若规格说明书的输入域或输出域是有序集合，则选择第一个和最后一个元素作为测试样例

闭外开内原则

​ 当输入是一个范围，可以根据闭区间或开区间的情况，选择合适的边界点、邻域点作为边界值进行测试

特殊边界值

​ 屏幕上光标左上和右下

​ 报表第一行和最后一行

​ 数组的第一个和最后一个

​ 循环的第0.1次、倒数第二次、最后一次

基于场景测试

​ 以事件流为核心（包括基本事件流和备选流），围绕事件流和场景进行测试

定义基本流和备选流

​ 基本流：从某个初始状态开始，经过一系列状态后到达终止状态的一个业务流程。是从初始状态到终止状态最主要的业务流程。确保基本流执行完全正确（往往考虑容易出错、出错后导致后果严重的风险事件）

​ 备选流：以基本流为基础，在基本流所经过的每个判定节点处满足不同的触发条件而导致的其他事件流（起点和终点可以不和基本流一样）

定义场景

​ 看做基本流和备选流的有序集合：至少包含一条基本流和0-多条备选流

从场景设计测试用例

​ 字面意思

适用于业务逻辑性强、业务流程多的测试

场景进行测试

定义基本流和备选流

​ 基本流：从某个初始状态开始，经过一系列状态后到达终止状态的一个业务流程。是从初始状态到终止状态最主要的业务流程。确保基本流执行完全正确（往往考虑容易出错、出错后导致后果严重的风险事件）

​ 备选流：以基本流为基础，在基本流所经过的每个判定节点处满足不同的触发条件而导致的其他事件流（起点和终点可以不和基本流一样）

[外链图片转存中…(img-2R6MbFp2-1705412220055)]

定义场景

​ 看做基本流和备选流的有序集合：至少包含一条基本流和0-多条备选流

从场景设计测试用例

​ 字面意思

适用于业务逻辑性强、业务流程多的测试