软件测试学习笔记

博主：酱油瓶
发布时间：2023 年 04 月 18 日
1627 次浏览
暂无评论
29483字数
分类：学习软件工程

# 1 软件测试的基本概念

## 1.1 软件测试概述

### 1.1.1 软件测试的对象

1. 需求规格说明书
2. 概要设计规格说明书
3. 详细设计规格说明书
4. 源程序
5. 系统
6. 用户手册
7. 帮助文档

其中1-3为阶段性文档；6-7为最终产品文档

### 1.1.2 软件测试的定义 [重要]

软件测试是为了**尽快尽早地发现**在软件产品中所存在的**各种软件缺陷**而展开的贯穿整个**软件开发生命周期**、对软件产品(包括阶段性产品)进行验证和确认的活动过程。

### 1.1.3 软件开发生命周期 *

- 软件生命周期

SDLC, Systems Development Life Cycle
  又称为软件生存周期或系统开发生命周期，就是软件的产生直到报废的整个周期。
- 软件生命周期被划分成了若干个阶段:

可行性分析与项目计划、需求分析、系统设计、编码、调试、测试(执行)、维护升级到废弃等阶段。

### 1.1.4 软件测试的目的 [重要]

1. 发现系统的错误
2. 验证系统是否满足需求
3. 为产品放行提供依据
4. 改进开发流程

### 1.1.5 软件质量

软件的一些质量特性的组合，反映了软件满足用户需求的程度。(规定或隐含的需求)

软件质量模型 P16

### 1.1.6 软件测试的原则 [重要]

1. **所有的软件测试都应追溯到用户需求**
2. **尽早地、不断地**进行测试
3. 严格执行测试计划
4. **注重测试用例的设计**
5. 程序员应该避免测试自己的程序
6. **增量测试**，由小到大
7. 注意**集群现象**(二八定理)
8. 完全测试是不可能的
9. 测试维护

## 1.2 软件测试的分类 [重要]

### 1.2.1 按测试技术分类

1. 黑盒测试

在程序接口进行测试，它只是检查程序功能是否按照规格说明书的规定正常使用。
   也被称为功能测试或数据驱动测试。
2. 白盒测试

要完全了解程序结构和处理过程，它按照程序内部逻辑测试程序，检验程序中每条通路是否按预定要求正确工作。
   也被称为结构测试或逻辑驱动测试。
3. 灰盒测试

介于黑盒测试与白盒测试之间的测试，即要像黑盒测试那样关注输出对于输入的正确性;同时也关注内容表现，但这种关注不像白盒测试那样详细、完整，只是通过一些表征性的现象、事件、标志判断内部的运行状态。

### 1.2.2 按测试方法分类

1. **静态测试**

是指不运行程序，对程序和文档进行分析与检查;静态测试技术又称为静态分析技术。
2. **动态测试**

通过运行程序进行检查、分析程序的执行状态和程序逻辑的外部表现
3. 手动测试

绝大多数公司用的较多的一-种测试，提升人的主观能动性，但耗时，例如游戏类的测试
4. 自动化测试

重复性工作采用该测试方便，但无法发现新的缺陷，例如每秒点击100次

### 1.2.3 按测试阶段分类

1. 单元测试(能发现80%的问题)

单元测试是对软件设计的最小单元- --模块进行正确性检验的测试工作。(如自行车组装，先进行单元测试)

目的: 主要是测试模块在语法、格式和逻辑.上的错误。
2. 集成测试

集成测试也称为组装测试，集成测试按设计要求把通过单元测试的各个模块组装在- - 起之后所进行的测试。(一般分为函数间集成，模块间集成，子系统间集成)

目的: 检查模块间的接口关系，以便发现与接口有关的各种错误
3. 系统测试 **(重点关注)**

系统测试是将已经集成好的软件系统置于实际运行环境中所进行的测试。(一般指用户真实运行环境模拟测试)

目的: 根据需求分析时确定的标准检验软件是否满足功能、行为、性能和系统协调性等方面的要求。
4. 验收测试

是软件开发结束后，用户对软件产品投入实际应用前进行的最后--次质量检验活动。它要回答开发的软件产品是否符合预期的各项要求，以及用户能否接受的问题。 (旨在提高用户对软件质量的信心)

目的: 验证软件功能的正确性和需求的符合性。

### 1.2.4 按软件质量特性分类

- **功能测试**
- **安全测试**
- **性能测试**
- 可靠性测试
- 压力测试
- 安装测试
- 用户界面测试
- **兼容性测试**

## 1.3 软件测试3个重要概念

### 1.3.1 测试用例 (Test case)

测试用例是一组测试输入、执行条件和预期结果的集合。

其目的是要满足一个特定的目标，比如执行一条特定的程序路径或检验是否符合一个特定的需求。

### 1.3.2 测试环境

软件运行的平台，即软件、硬件、网络和历史数据的集合

### 1.3.3 软件缺陷

- 从产品内部看:

缺陷是软件产品开发或维护过程中存在的错误、毛病等各种问题。
- 从产品外部看:

缺陷是系统所需要实现的某种功能的失效或违背。

# 2 黑盒测试

## 2.1 等价类

### 2.1.1 什么是等价类

等价类是指某个输入域的子集合。

在该子集合中，各个输入数据对于**揭露程序中的错误都是等效的**。
测试某等价类的代表值就等价于对这一类其它值的测试。
对于某个被测试对象的测试输入而言，某个个体能够被接受或拒绝，则该个体所在的集合中的任何一个个体都应该被接收或拒绝。(班级上课，A上B，则全部都是B)

### 2.1.2 有效等价类与无效等价类

设计测试用例时，要同时考虑有效等价类和无效等价类的设计。软件不能只接收合理的数据，还要经受意外的考验，接受无效的或不合理的数据，这样软件才能具有较高的可靠性。

- 对于程序的规格说明来说，是输入数据构成的集合。
-  | 等价类     | 输入               | 关注点     |
  | ------------ | -------------------- | ------------ |
  | 有效等价类 | 合理的、有意义的   | 功能和性能 |
  | 无效等价类 | 不合理的、无意义的 | 异常处理   |

## 2.2 等价类划分法

### 2.2.1 定义

把所有可能的输入数据划分成若干部分(子集)，然后从每一个子集中选取少数具有代表性的数据作为测试用例。

这是一种典型的，常用的黑盒测试法

### 2.2.2 划分方法

1. 按双边区间划分

如果输入条件规定了取值范围，或值的个数，则可以确立一个有效等价类和两个无效等价类。
2. 按取值划分

如果规定了输入数据的一组值(假定$n$个)，且程序要对每一个输入值分别进行处理的情况下，可确定$n$个有效等价类(每个值确定一个有效等价类)和一个无效等价类(所有不允许的输入值的集合)。
3. 按单边区间划分

如果输入条件规定了输入值的集合，这时可确立一个有效等价类和一个无效等价类。
4. 按限制条件/规划划分

如果规定了输入数据必须遵守的规则或限制条件，可确定一个有效等价类(符合规则)和若干个无效等价类(从不同角度违反规则)

### 2.2.3 等价类测试的类型

根据测试用例的完整性划分

1. 弱等价类测试
   - 弱一般等价类测试
     - 定义：单缺陷假设，不讨论异常区域
     - 测试用例策略：
       1. 对于有效输入，取每个有效等价类的一个值
       2. 对于无效数据，不考虑(不取无效等价类)
   - 弱健壮等价类测试 (传统的等价类测试)
     - 定义：单缺陷假设，要考虑异常区域
     - 测试用例策略：
       1. 对于有效输入，取每个有效等价类的一个值
       2. 对于无效输入，测试用例将拥有一个无效值，并保持其余的值是有效的。
2. 强等价类测试
   - 强一般等价类测试
     - 定义：多缺陷假设，不考虑异常区域 (即有效等价类的笛卡尔乘积)
     - 测试用例策略：
       1. 对于有效输入，考虑有效等价类之间的组合
       2. 对于无效输入，不考虑
   - 强健壮等价类测试
     - 定义：多缺陷假设，要考虑异常区域 (即一个全笛卡尔乘积)
     - 测试用例策略：
       1. 测试用例从所有等价类(包括有效和无效等价类)笛卡儿乘积中选取(组合)

名词解释：

- 弱

是指从各个等价类中选取值时只考虑等价类自身，查出的缺陷属于“单缺陷”，即单一因素造成的缺陷。

即单缺陷假设，**不考虑**取值**组合**
- 强

是指考虑了等价类之间的相互影响，查出的缺陷属于多种因素造成的“多缺陷”。

即多缺陷假设，**考虑**取值**组合**的情况
- 一般

不考虑**无效值**(异常区域)
- 健壮

考虑**无效值**(异常区域)

![等价类测试的类型](http://storage.live.com/items/FECD80CE4F909A96!44948:/image-20230418224002463.png?authkey=AKpqV245EC2xOuk)

## 2.3 边界值分析法

### 2.3.1 定义

对输入或输出的边界值进行测试的一种黑盒测试方法。
是作为对等价类划分法的补充，这种情况下其测试用例来自等价类的边界。
任何等价区间都有边界，有边界就有等价区间。

### 2.3.2 名词解释

- 边界：指相对于输入等价类和输出等价类而言，稍高于、稍低于其边界值的一些特定情况。
- 边界点：分为上点，内点，离点

![image-20230419150415727](http://storage.live.com/items/FECD80CE4F909A96!44958:/image-20230419150415727.png?authkey=AKpqV245EC2xOuk)

注：不管是闭区间还是开区间，上点都是其边界点，只是上点是否在域内有所区别

### 2.3.3 边界值分析法与等价类划分法的区别

![image-20230419151010680](http://storage.live.com/items/FECD80CE4F909A96!44959:/image-20230419151010680.png?authkey=AKpqV245EC2xOuk)

### 2.3.4 选取数据的原则

1. 如果输入条件规定了值的范围

则应取刚达到这个范围的边界的值，以及刚刚超越这个范围边界的值作为测试输入数据。
2. 如果输入条件规定了值的个数
   则用最大个数,最小个数，比最小个数少一,比最大个数多一的数作为测试数据。
3. 如果输出条件规定了值的范围

则应取刚达到这个范围的边界的值，以及刚刚超越这个范围边界的值作为测试输入数据。
4. 如果输出条件规定了值的个数

则用最大个数，最小个数，比最小个数少一,比最大个数多一的数作为测试数据。
5. 分析规格说明，找出其他可能的边界条件

### 2.3.5 边界条件测试用例设计法

1. 一般边界条件测试用例设计法

- 方法
     1. 每次保留程序中一个变量，让其余的变量取正常值，被保留的变量依次取min、min+、 nom、max和max。
     2. 对程序中的每个变量重复(1)
   - 特点
     1. 一般边界值测试分析采用了可靠性理论的单缺陷假设。
     2. 优点:简便易行;生成测试数据的成本很低;
     3. 局限性:测试用例不充分;不能发现测试变量之间的依赖关系;
     4. 对于一个$n$变量函数，该方法生成的测试用例数为$4n+1$
   - 结论：只能作为初步测试用例使用
2. 健壮性边界条件测试用例设计法

- 方法

1. 每次保留程序中一-个变量，让其余的变量取正常值，被保留的变量依次取min-、min、 min+、 nom、max- 、max和max+。
     2. 对程序中的每个变量重复(1)
   - 特点

对于一个$n$变量函数，该方法生成的测试用例数为$6n+1$
3. 最坏边界条件测试用例设计法

- 方法

1. 所有变量均可取min、min+、 nom、max- 和max这五个边界值中的任何一个，
     2. 测试用例为五个集合的笛卡儿乘积。
   - 特点

对于一个$n$变量函数，该方法生成的测试用例数为$5^n$
   - 与基本边界条件的区别

1. 基本边界值分析测试用例是最坏情况测试用例的真子集;
     2. 最坏情况测试显然更彻底;
     3. 最坏情况测试工作量大得多，变量函数的最坏情况测试会产生$5^n$个测试用例，边界值分析只产生$4n+1$个测试用例。
4. 健壮最坏边界条件测试用例设计法

- 方法

1. 所有变量均可取min-1、min、 min+、nom、max- 、max和max+1这七个边界值中的任何一个。
     2. 测试用例为七个集合的笛卡儿乘积。
   - 特点

对于一个$n$变量函数，该方法生成的测试用例数为$7^n$

## 2.4 判定表法

### 2.4.1 定义

1. **判定表**(也称决策表)是一个用来表示条件和行动的二维表，是分析和表达多逻辑条件下执行不同操作的情况的工具。
2. **判定表驱动法**(或决策表法)是根据需求描述建立判定表(决策表)后，导出测试用例的方法。
3. 在所有的黑盒测试方法中，基于判定表的测试是最为严格、最具有逻辑性的测试方法

### 2.4.2 名词解释

- 将任何一个条件组合的特定取值及相应要执行的动作称为一条规则。
- 在判定表中贯穿条件项和动作项的一列就是一条规则。
- 条件桩：需求规格说明书定义的被测试对象的所有输入。
- 条件项：针对条件桩所有可能的输入数据的真假值。
- 动作桩：针对条件被测对象可能采取的所有操作
- 动作项：针对动作桩，被测对象响应的可能取值。

### 2.4.3 一个例子

问题描述： “……对于功率大于50马力的机器，并且维修记录不全或已运行10年以上的机器，应给予优先的维修处理……”

|        |                     | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 |
| -------- | --------------------- | --- | --- | --- | --- | --- | --- | --- | --- |
| 条件桩 | C1:功率大于50马力?  | Y | Y | Y | Y | N | N | N | N |
|        | C2:维修记录不全吗？ | Y | Y | N | N | Y | Y | N | N |
|        | C3:运行超过10年吗？ | Y | N | Y | N | Y | N | Y | N |
| 动作桩 | A1:进行优先处理     | Y | Y | Y |   | Y |   | Y |   |
|        | A2:做其他处理       |   |   |   | Y |   | Y |   | Y |

### 2.4.4 两种判定表

1. 有限条目判定表
   - 特点:所有条件都是二值条件(真/假)
2. 扩展条目判定表
   - 特点:条件可以有多个值

### 2.4.5 判定表的简化

- 实际使用决策表时，常常先将它简化，简化是以合并相似规则为目标的。
- 判定表的简化主要包含:**规则合并**与**规则包含**

1. 规则合并

若两条或多条规则的动作项相同，条件项只有一项不同，则可将该项合并，合并后的条件项用符号`-`表示，说明执行的动作与该条件的取值无关，称为无关条件。
  2. 规则包含

无关条件项在逻辑上又可包含其他的条件项取值，具有相同动作的规则还可进一步合并。

例如：将上一节问题的判定表进行简化

|        |                     | 1 | 2 | 3 | 4 | 5 |
| -------- | --------------------- | --- | --- | --- | --- | --- |
| 条件桩 | C1:功率大于50马力?  | Y | - | N | Y | N |
|        | C2:维修记录不全吗？ | Y | N | - | N | Y |
|        | C3:运行超过10年吗？ | - | Y | N | N | Y |
| 动作桩 | A1:进行优先处理     | Y | Y |   |   | Y |
|        | A2:做其他处理       |   |   | Y | Y |   |

## 2.5 因果图法

### 2.5.1 定义

- 因果图法(Cause-Effect Graphics)

是一种利用图解法分析输入的各种组合情况，从而设计测试用例的方法。
- 因果图提供了一个把需求转化为判定表的系统化方法
- 因果图法最终生成的就是判定表，它适合于**检查**程序输入条件的各种组合情况。(因果图是判定表前置条件，类似等价与边界关系)
- 原因:输入条件

结果:输出

### 2.5.2 因果图的关系符号

- 有四种关系符号：恒等、非、或、与
- $c_i$表示原因，通常在图的左部；$e_i$表示结果，通常在图的右部。$c_i,e_i$均可取值0或1，0表示某状态不存在，1表示某状态出现
- 四种关系符号

1. 恒等

```mermaid
     flowchart
     	subgraph 恒等
         A[c1] --- B[e1]
         end
     ```

表示原因与结果之间一对一的对应关系。若原因出现，则结果出现;若原因不出现，则结果也不出现。

例如：

| $c_1$ | $e_1$ |
     | ------- | ------- |
     | 1     | 1     |
     | 0     | 0     |
  2. 非

```mermaid
     flowchart
     	subgraph 非
         A[c1] x--x B[e1]
         end
     ```

表示原因与结果之间的一种否定关系。若原因出现，则结果不出现;若原因不出现反而结果出现。

例如：

| $c_1$ | $e_1$ |
     | ------- | ------- |
     | 0     | 1     |
     | 1     | 0     |
  3. 或

```mermaid
     flowchart
         subgraph V
         A[c1] --- B[e1]
         C[c2] --- B
         D[c3] --- B
         end
     ```

表示若几个原因中有一个出现，则结果出现;只有当这几个原因都不出现时，结果才不出现。(可以有任意个输入)

例如：

| $c_1$ | $c_2$ | $c_3$ | $e_1$ |
     | ------- | ------- | ------- | ------- |
     | 1     | 1     | 0     | 1     |
     | 1     | 0     | 0     | 1     |
     | 0     | 0     | 0     | 0     |
  4. 与

```mermaid
     flowchart
         subgraph ^
         A[c1] --- B[e1]
         C[c2] --- B

end
     ```

表示若几个原因都出现，结果才出现;若几个原因中有一个不出现，结果就不出现。

例如：

| $c_1$ | $c_2$ | $e_1$ |
     | ------- | ------- | ------- |
     | 1     | 1     | 1     |
     | 1     | 0     | 0     |
     | 0     | 1     | 0     |

### 2.5.3 因果图的约束符号

- 约束：在实际问题当中，输入状态相互之间还可能存在某些依赖关系，称为约束。例如，某些输入条件本身不可能同时出现。输出状态之间也往往存在约束。在因果图中，用特定的符号标明这些约束。(输入与输入之间关系)
- 输入4种约束

1. E(Exclusive)约束 （异/互斥）

```mermaid
     flowchart LR
         A(E) -.- a[a]
         A -.- b[b]
     ```

表示几个原因不会同时成立;可能他们都不成立，但最多有一个成立。
  2. I(Include)约束（或/包含）

```mermaid
     flowchart LR
         A(I) -.- a[a]
         A -.- b[b]
         A -.- c[c]
     ```

表示几个原因中至少有一个必须成立，当然也可能都成立。
  3. O(Only)约束（唯一）

```mermaid
     flowchart LR
         A(O) -.- a[a]
         A -.- b[b]
     ```

表示几个原因中必须有且仅有一个成立。
  4. R(Request)约束（要求）

```mermaid
     flowchart TB
         subgraph R
         a[a] -.-> b[b]
         end
     ```

表示当a出现时，b必须也出现。
- 输入条件的约束类型 [了解]

M(Mandate)约束（屏蔽）

```mermaid
  flowchart TB
  	subgraph M
      a[a] -.-> b[b]
      end
  ```

表示当a是1时，b必须是0;而当a为0时，b的值不一定
- 总结

| 约束类型 | | 英文解释 | 约束说明 |
 | ---------------------------- | ------ | ----------------- | -------------------------------------------------------- |
 | E | 互斥 | Exclusive排外的 | 原因a和b中至多有一个可能为1，即a和b不能同时为1。 |
 | I | 包含 | Include包含 | 原因a、b和c中至少有一个必须是1，即a、b和c不能同时为0。 |
 | O | 唯一 | Only唯一 | 原因a和b必须有一个，且仅有1个为1。 |
 | R | 要求 | Request要求 | 原因a是1时，b必须是1，即不可能a是1时b是0。 |
 | M | 屏蔽 | Mandate授权 | 结果a是1，则结果b强制为0。 |

### 2.5.4 因果图法设计用例步骤

| 步骤 | 说明                     |
| ------ | -------------------------- |
| 需求 | 1.找出输入输出并进行标识 |
| 分析 | 2.分析输入输出的关系     |
| 关联 | 3.画出因果图             |
| 转换 | 4.因果图转换为判定表     |
| 输出 | 5.生成测试用例           |

### 2.5.5 特点 [重要]

- 优点

能把复杂的问题按各种可能的情况一一列举出来，简明而易于理解，也可避免遗漏。
  可以指出需求规格说明书的不完整性和不明确之处。
- 缺点

不能表达重复执行的动作，例如**循环结构**
- 因果图与判定表的选择

- 条件和动作关系不明确：先使用因果图
  - 如果需求是以判定表形式给出的、项目在设计阶段就采用了判定表：直接用判定表:设计测试用例

# 3 白盒测试

## 3.1 概念

### 3.1.1 白盒测试的特点

不仅因为黑盒测试存在一定的缺陷，还因为进行白盒测试能够更全面地发现软件缺陷和问题，有助于提高软件质量和可靠性。具体原因如下:

- 定位问题更精确:

白盒测试可以在源代码级别检查软件的内部逻辑，可以更精确地定位问题，减少排查问题的时间和成本。
- 发现隐藏问题:

白盒测试可以查看软件内部代码，发现开发人员可能遗漏的特殊情况而导致的问题，这些问题在黑盒测试中很难被发现。
- 提高测试的有效性:

通过白盒测试可以检查代码中的逻辑错误和潜在的安全漏洞，可以更好地确保测试覆盖全面。
- 确保软件的质量:

白盒测试能够发现软件的各种问题，包括性能问题、可维护性问题、可扩展性问题等，确保软件的质量达到目标要求。

### 3.1.2 定义与目的

- 白盒测试(White-box testing)

是通过对程序内部结构的分析、检测来寻找问题，又称透明盒测试和逻辑驱动测试
- 目的

- 保证程序中所有关键路径的测试，防止由于没有执行的路径，在实际投入运行后执行到发生意外的情况
  - 衡量测试完整性
  - 程序内部所有的逻辑值真、假两个分支的覆盖
  - 检查内存泄漏
  - 异常处理的分支语句的执行
  - 解决实验条件下很难搭建真实测试环境的问题
  - 检查代码符合一定的编码规范，减少由于编码不规范而引入错误

## 3.2 静态白盒测试

### 3.2.1 名词解释

静态白盒测试：

- **不运行**被测程序本身，仅通过**分析**或**检查**源程序的语法、结构、过程、接口等来检查程序的正确性，对需求文档、设计文档、源程序做结构分析、流程图分析、符号执行来找错。
- 进行静态白盒测试的首要原因是尽早发现软件缺陷，以找出动态黑盒测试难以发现或隔离的软件缺陷。另一个好处是给黑盒测试人员提供思路。
- 静态测试错误类型

不匹配的参数、不适当的循环嵌套和分支嵌套、不允许的递归、未使用过的变量、空指针的引|用和可疑的计算等。
- 代码走查(walkthrough)
  开发组内部进行的，采用讲解、讨论和模拟运行的方式进行的查找错误的活动
- 代码审查(Inspection)
  开发组内部进行的，采用讲解、提问并使用Checklist方式进行的查找错误的活动。一般有正式的计划、流程和结果报告
- 技术评审(Review)
  开发组、测试组和相关人员(QA、产品经理等)联合进行的，采用讲解、提问并使用Checklist方式进行的查找错误的活动。一般有正式的计划、流程和结果报告
- 正式审查(Formal review)

就是进行静态白盒测试的过程。正式审查的含义很广，从两个程序员的交谈,到软件设计和代码的详细,严格检查均属于此过程.
- 代码审查单

用于把代码与标准或规范进行对照补充，并确保代码符合项目的设计要求。

### 3.2.2 正式审查(Formal review)

正式审查的4个基本要素

1. **确定问题**。审查的目标是找出软件的问题，不仅是出错的项目，还包括遗漏的项目。全部的批评应直指代码，而不是其创建者。合作者不应该互相指责。个人情绪化感觉要保留。
2. **遵守规则**。 审查要遵守一套固定的规则，规则可能设定要审查的代码量、花费多少时间、哪些内容要做备注等等。其重要性在于合作者了解自己的作用和目标，这有助于使审查进展的更加顺利。
3. **准备**。每个合作者需要了解自己的责任和义务，并积极参与审查。在审查过程中找出问题大部分的缺陷是在准备期间发现的，而不是实际审查期间。
4. **编写报告**。审查小组必须做出总结审查结果的书面报告，并使报告便于开发小组使用。审查结果必须尽快告诉别人，比如发现多少问题，在哪发现的。

### 3.2.3 静态测试

- 静态测试不实际运行软件，主要是对软件的编程格式、结构等方面进行评估
- 静态测试包括代码检查、程序结构分析、代码质量度量等。它可以由，人工进行，也可以借助软件工具自动进行
- 代码检查比动态测试更有效率，能快速找到缺陷，发现30%~70%的逻辑设计和编码缺陷

### 3.2.4 静态分析

- 静态分析是指在不执行的情况下进行评估的过程
- 包括
  - 类型检查
  - 风格检查
    - 风格检查更加注重空格、缩减、命名、注释、程序结构这些表名的东西
    - 风格检查程序所展示的错误往往都是影响代码的可读性和可维护性的问题
    - 常用工具:
      - C/C++: PCLint
      - JAVA: PMD
      - .NET: StyleCop
  - 程序理解
  - Bug查找
  - 安全审查

## 3.3 动态白盒测试

- 动态白盒测试：
- 由于是动态的，就一定是测试运行中的程序，由于是白盒，就一定要洞察盒子里面，检查代码并观察运行状况。

生成测试数据、分析测试结果的工作量大，使开展测试工作费时、费力、费人。
- 动态白盒测试的两种常用技术:

- 路径测试:
    从流程图上讲，程序的一次执行对应于从入口到出口的一条路径，**针对路径的测试**即为路径测试。从广义的角度讲，任何有关路径分析的测试都可以被称为路径测试。
  - 覆盖测试:
    在测试过程中，以**覆盖某些程序元素**为测试目标的测试。

### 3.3.1 路径测试

- 基本路径测试方法

在不能做到所有路径覆盖的前提下，如果某一程序的每一个独立路径都被测试过，那么可以认为程序中的每个语句都已经检验过了，即达到了语句覆盖。这种测试方法就是通常所说的基本路径测试方法。
- 控制流图

可简称流图，是对程序流程图进行简化后得到的，它可以更加突出的表示程序控制流的结构。
- 控制流图中包括两种图形符号：**节点**和**控制流线**

- **节点**由带标号的圆圈表示，可代表一个或多个语句、一个处理框序列和一个条件判定框。
  - **控制**流线由带箭头的弧或线表示，可称为边。它代表程序中的控制流。

![image-20230423233128657](http://storage.live.com/items/FECD80CE4F909A96!44995:/image-20230423233128657.png?authkey=AKpqV245EC2xOuk)
- 判定节点和区域

包含条件的节点被称为**判定节点**，由判定根节点发出的边必须终止于某一个节点由边和节点所限定的范围被称为**区域**
- 图矩阵

- 图矩阵是控制流图的矩阵表示形式。
  - 图矩阵是一个方形矩阵,其维数等于控制流图的节点数。矩阵中的每列和每行都对应于标识的节点，矩阵元素对应于节点间的边。
  - 通常，控制流图中的结点用数字标识，边则用字母标识。如果在控制流图中从第$i$个结点到第$j$个结点有一个标识为$x$的边相连接，则在对应图矩阵的第$i$行第$j$列有一个非空的元素$x$。

![image-20230425225544745](http://storage.live.com/items/FECD80CE4F909A96!45007:/image-20230425225544745.png?authkey=AKpqV245EC2xOuk)
- 环形复杂度

- 环形复杂度又称为圈复杂度,以图论为基础,为我们提供了非常有用的软件度量。
  - 两种计算方法：

1. 其中，E是控制流图中边的数量, N是控制流图中的节点数量。

$$
       V(G)= E-N+2

$$
    2. 其中, P是控制流图G中判定节点的数量。

$$
       V(G)= P+1

$$
- 独立路径以及确定方法

- 独立路径是指程序中至少引入了一个新的处理语句集合或一个新条件的程序通路。
  - 采用流图的术语,即独立路径必须至少包含一条在本次定义路径之前不曾用过的边。
  - **程序基本路径集**是指由若干条独立路径组成的集合,其数量**由环形复杂度确定**。
  - McCabe开发了一种算法,用于确定程序的基本路径集合，方法如下:

1. 选择一个基线路径。
    2. 沿基线路径后退,碰到**判定节点后翻转**,将翻转后的路径作为基线路径,重复本步骤,直到所有的节点都被翻转。

注意:为遵循先易后难的原则, 对于循环，一般先让路径跳过循环,然后考虑进入循环。基本路径集通常并**不唯一**。
  - 一个样例

![image-20230425230321085](http://storage.live.com/items/FECD80CE4F909A96!45008:/image-20230425230321085.png?authkey=AKpqV245EC2xOuk)

![image-20230425230329867](http://storage.live.com/items/FECD80CE4F909A96!45009:/image-20230425230329867.png?authkey=AKpqV245EC2xOuk)
- 基本路径测试法的测试步骤

1. 画出程序的控制流图
  2. 计算流图G的环路复杂性V(G)
  3. 确定只包含独立路径的基本路径集
  4. 根据_上面的独立路径,设计测试用例，使程序分别沿上面的独立路径执行。

### 3.3.2 覆盖测试法

依据覆盖源程序语句的详细程度不同和覆盖目标的不同，逻辑覆盖主要可分为:

1. 语句覆盖
2. 判定覆盖
3. 条件覆盖
4. 判定/条件覆盖
5. 条件组合覆盖

下面是一个样例的代码和流程图

```javascript
func(int x,int y,int Z)
{
    if((y>1)&&(z==0))
		x=x/y;
	if((y==2)||(x>1))
		X=x+1;
}

```

![image-20230425231243892](http://storage.live.com/items/FECD80CE4F909A96!45010:/image-20230425231243892.png?authkey=AKpqV245EC2xOuk)

以下是几种覆盖的具体含义：

1. 语句覆盖

通过选择足够的测试用例，使被测程序的**每个语句至少被执行一次**

**优点**: 可以很直观地从源代码得到测试用例，无须细分每条判定表达式。

**缺点**: 由于这种测试方法仅仅针对程序逻辑中显式存在的语句，但对于隐藏的条件是无法测试的。

| 测试用例 | 输入        | 预期输出 | 被测路径 |
   | ---------- | ------------- | ---------- | ---------- |
   | CASE     | x=4,y=2,z=0 | x=3      | sacbed   |
2. 判定覆盖

又称为分支覆盖,判定覆盖比语句覆盖的标准稍强一些,它是指通过设计足够的测试用例，使得程序中的**每一个判定至少都获得一次“真值”和“假值”**,或者说使得程序中的**每一个分支都至少通过一次**。

**优点**: 判定覆盖具有比语句覆盖强的测试能力。同样判定覆盖也具有和语句覆盖一样的简单性，无须细分每个判定就可以得到测试用例。

**缺点**: 往往大部分的判定语句是由多个逻辑条件组合而成，若仅仅判断其整个最终结果，而**忽略每个条件的取值情况**，必然会遗漏部分测试路径。判定覆盖仍是**弱的逻辑覆盖**。

| 测试用例 | 输入        | 预期输出 | 覆盖分支 | 被测路径 |
   | ---------- | ------------- | ---------- | ---------- | ---------- |
   | CASE2    | x=1,y=3,z=0 | x=1/3    | ac,bd    | sacbd    |
   | CASE3    | x=3,y=2,z=1 | x=4      | ab,be    | sabed    |
3. 条件覆盖

是指对于每个判定中所包含的若干个条件，应设计足够多的测试用例，使得判定中的**每个条件都至少取到一次“真值”和“假值”的机会**,也就是说,判定中的**每个条件的所有可能结果至少出现一次**。

特点：条件覆盖并不能包含判定覆盖,对于下述测试用例，分支bd并未出现。

- 判定1：`(y>1)&&(z==0)`
     - 条件`y>1`取真、假分别记为T1,-T1
     - 条件`z==O`取真、假分别记为T2,-T2
   - 判定2：`(y==2)||(x>1)`
     - 条件y==2取真、 假分别记为T3 , -T3
     - 条件x>1取真、假分别记为T4 , -T4

| 测试用例 | 输入        | 预期输出 | 覆盖条件       | 覆盖分支 | 被测路径 |
   | ---------- | ------------- | ---------- | ---------------- | ---------- | ---------- |
   | CASE4    | x=0,y=2,z=0 | x=1      | T1,T2,T3,-T4   | ac,be    | sacbed   |
   | CASE5    | x=2,y=1,z=1 | x=3      | -T1,-T2,-T3,T4 | ab,be    | sabed    |
4. 判定/条件覆盖

是指通过设计足够多的测试用例，使得运行这些测试用例时，判定中的**每个条件的所有可能结果至少出现一次**，并且**每个判定本身的所有可能结果也至少出现一次**

**优点**：能同时满足判定、条件两种覆盖标准。

**缺点**：判定/条件覆盖准则的缺点是未考虑条件的组合情况.

| 测试用例 | 输入        | 预期输出 | 覆盖条件        | 覆盖分支 | 被测路径 |
   | ---------- | ------------- | ---------- | ----------------- | ---------- | ---------- |
   | CASE6    | x=4,y=2,z=0 | x=3      | T1,T2,T3,T4     | ac,be    | sacbed   |
   | CASE7    | x=1,y=1,z=1 | x=1      | -T1,-T2,-T3,-T4 | ab,bd    | sabed    |
5. 条件组合覆盖

是指通过设计足够多的测试用例，使得运行这些测试用例时，每个判定中**条件结果的所有可能组合至少出现一次**

基本思想是:设计所有的测试用例,来覆盖程序中的所有可能的执行路径。

**优点**: 这种测试方法可以对程序进行彻底的路径测试。

**缺点**: 需要设计大量、复杂的测试用例,使得工作量呈指数级增长。

| 编号 | 判定1各条件组合 | 编号 | 判定2条件组合 |
   | ------ | ----------------- | ------ | --------------- |
   | 1    | y>1,z==0        | 5    | y==2,x>1      |
   | 2    | y>1,z!=0        | 6    | y==2,x≤1     |
   | 3    | y≤1,z==0       | 7    | y!=2,x>1      |
   | 4    | y≤1,z!=0       | 8    | y!=2,x≤1     |

| 测试用例 | 输入        | 预期输出 | 覆盖条件组合 | 被测路径 |
   | ---------- | ------------- | ---------- | -------------- | ---------- |
   | CASE8    | x=4,y=2,z=0 | x=3      | 1,5          | sacbed   |
   | CASE9    | x=1,y=2,z=1 | x=2      | 2,6          | sabed    |
   | CASE10   | x=2,y=1,z=0 | x=3      | 3,7          | sabed    |
   | CASE11   | x=1,y=1,z=1 | x=1      | 4,8          | sabd     |
6. 总结

| 发现错误能力 | 标准          | 含义                                                               |
   | -------------- | --------------- | -------------------------------------------------------------------- |
   | 1(弱)        | 语句覆盖      | 每条语句至少执行一-次                                              |
   | 2            | 判定覆盖      | 每一判定的每个分支至少执行一-次                                    |
   | 3            | 条件覆盖      | 每一判定中的每个条件，分别按“真”，                               |
   | 4            | 判定/条件覆盖 | 同时满足判定覆盖和条件覆盖的要求                                   |
   | 5(强)        | 判定/条件覆盖 | 求出判定中所有条件的各种可能组合值，每一可能的条件组合至少执行一次 |

# 4 软件测试流程

## 4.1 概念

### 4.1.1 基本流程与阶段

| 内容         | 阶段            |
| -------------- | ----------------- |
| 需求分析     | 1. 测试计划阶段 |
| 指定测试计划 |                 |
| 指定测试方案 | 2. 测试设计阶段 |
| 设计测试用例 |                 |
| 编写测试用例 | 3.测试实现阶段  |
| 搭建测试环境 | 4. 测试执行阶段 |
| 执行测试用例 |                 |
| Bug跟踪处理  |                 |
| 测试报告输出 |                 |

### 4.1.2 主要的测试文档

| 测试输出 | 内容                                                                 |
| ---------- | ---------------------------------------------------------------------- |
| 测试计划 | 指明测试范围、方法、资源，以及相应测试活动的时间进度安排表的文档。   |
| 测试方案 | 指明为完成软件或软件集成特性的测试而进行的设计测试方法的细节文档。   |
| 测试用例 | 指明为完成一个测试项的测试输入、预期结果、测试执行条件等因素的文档。 |
| 缺陷报告 | 指明软件缺陷的现象和复现条件                                         |
| 测试报告 | 指明执行测试结果的文档。                                             |
| 工作日报 | 每天测试执行情况的记录和总结。                                       |

### 4.1.3 需求分析

- 目的：从源头把握软件质量,确保开发结果与实际需求相一致角色与职责
- 角色与职责：

- 需求人员：《需求规格说明书》的编写， 以及软件开发过程中《需求规格说明书》的修正
  - 评审人员：《评审需求规格说明书》,从全面性、完整性、正确性、一致性等方面检查,将需求缺陷提交给需求人员并跟踪需求缺陷直至需求缺陷验证关闭。
- 启动标准

《需求规格说明书》编写完成
- 输入/输出

输入:《需求规格说明书》
  输出: 需求缺陷

### 4.1.4 制定测试计划

- 测试计划描述所有要完成的测试工作

- 一个叙述了预定的测试活动范围、途径、资源及进度安排的文档。
  - 它确定了测试项、被测特征、测试任务、人员安排以及与计划相关的风险。
- 目的
  明确测试内容、测试任务安排、测试进度、测试资源、风险控制保持测试过程的顺畅, 有效控制和跟踪测试进度,应对测试过程中的各种变更。
- 角色与职责

- 测试负责人:根据《项目整体计划》《需求规格说明书》编制《测试计划》，以便测试工作正常开展。
- 启动标准

需求评审完成
- 输入/输出

输入:《需求规格说明书》《项目整体计划》
  输出:《测试计划》

### 4.1.5 制定测试方案

- 测试方案描述需要 **[重点]**

1. 测试的特性
  2. 测试的方法
  3. 测试环境的规划
  4. 测试工具的设计和选择
  5. 测试用例的设计方法
  6. 测试代码的设计方案。
- 目的

从技术上对要测试的系统进行分析和测试设计，来保证测试的覆盖度。
- 角色与职责

- 经验丰富的测试人员:

根据测试计划中的测试范围、类型来确定测试采用的技术、方法和测试用例的目录大纲。
  - 组内测试人员评审与讨论
- 启动标准.

测试计划编写完成, 任务分配完成
- 输入/输出

输入:《需求规格说明书》《测试计划》
  输出:《测试方案》

### 4.1.6 设计测试用例

- 测试用例需要 **[重点]**
  1. 用例编号
  2. 用例标题
  3. 用例级别
  4. 预置条件
  5. 操作步骤
  6. 预期结果
- 目的
  以最少的测试用例,实现最大的测试覆盖保证软件功能的正确性,从而提升软件质量。
- 角色与职责
  - 测试人员:
    采用多种测试方法编写有效的测试用例，并对遗漏/错误的测试用例进行修正。
  - 评审人员
    相关的开发和测试人员，对测试人员编写的测试用例进行评审, 提出遗漏/错误/冗余的用例缺陷，并跟踪直至用例缺陷的验证关闭。
- 启动标准
  测试方案编写完成,任务分配完成
- 输入/输出
  输入:《需求规格说明书》《测试方案》
  输出:《测试用例》

### 4.1.7 搭建测试环境

一般来说，软件产品提交测试后，开发人员应该提交一份产品安装指导书，在指导书中详细指明软件产品运行的软硬件环境。

### 4.1.8 执行测试用例

- 目的验证软件功能和性能与需求的实际匹配程度。
- 角色与职责
  - 测试人员:
    按照测试用例对软件功能进行测试。对于发现的缺陷必须记录,并且跟踪缺陷的状态，直至缺陷的验证关闭。在测试执行过程中发现的遗漏测试用例必须补充至测试用例,保证测试用例与实际测试的一致性。
  - 开发人员: 对于测试人员提交的缺陷进行确认、修复。
  - 项目经理: 对测试人员与实际开发人员意见不一的问题进行裁决。
- 启动标准.
  测试用例编写、测试环境搭建完成,,程序准测
- 输入/输出
  输入:《测试用例》、程序
  输出:《问题单》

### 4.1.9 编写测试报告

- 测试报告，是对测试的过程和结果的汇总描述

其核心内容为：

1. 测试结果的汇总：针对所测软件本身的一个客观真实的评价
  2. 测试过程的汇总：针对过程更改，总结改进
- 目的
  真实客观地对测试过程中各测试阶段、测试项的情况;版本发布的依据。
- 角色与职责

- 测试负责人:
    把测试的过程和结果写成文档,并对发现的问题和缺陷进行分析,为纠正软件的存在的质量问题提供依据,同时为软件验收和交付打下基础。
- 启动标准
  各阶段测试完成
- 输入/输出
  输入:各测试阶段、测试项实际测试情况
  输出:《测试报告》

## 4.2 软件测试计划

### 4.2.1 概念 [重要]

测试计划：

- 个叙述了预定的测试活动范围、途径、资源及进度安排的文档。
- 它确定了测试项、测试任务、人员安排以及与计划相关的风险。
- 三要素
  1. 时间
  2. 资源
  3. 范围

测试计划的内容：

1. 确定测试的目标、进度、人力、环境、工具等
2. 为达到测试目标采用测试类型
3. 功能性需求
4. 非功能性需求
5. 针对测试需求采用的测试方法

### 4.2.2 测试计划的设计与实现

需要涵盖以下几个方面

1. 资源

- 人力资源
   - 硬件和软件资源
   - 其他资源
2. 时间表

- 某项工作开始的时间？
   - 某项工作需要多少时间完成？

评估工作量+测试效率评估=确定测试用时间
   - 某项工作需要多长时间完成？
3. 测试环境

- 从软件的编码、测试到用户实际使用，存在着:**开发环境**、**测试环境**和**用户环境**。
   - “环境”，指的是被测试软件所运行的软件环境和硬件环境。
   - 测试环境是测试人员为进行软件测试而搭建的环境，一般情况下,将包括多种典型的用户环境。
4. 定义工作进度

- 确认工作任务
   - 工作任务分为两类：1. 可以直接和需求文档对应起来 2. 不和需求文档直接对应
   - 在需求文档中,对需求中的每一个条目,都应该有相应的测试工作与之对应起来。
   - 确认好测试任务后,还应该排列这些任务的优先级。
   - 估算工作量
   - 工作量可以使用“人`*`日”、“人`*`月”、 “人`*`年”这样的单位。
   - 测试工作量的估算可以采用以下方法:
     - 建立详细的工作分解结构
     - 分析以往项目, 寻找历史数据

## 4.3 软件测试用例

### 4.3.1 测试用例的基本概念和目的

- 什么是测试用例

测试用例是指在实施测试时,向被测系统提供**输入的数据，操作**或**各种系统设置**以及**预期结果**的一个集合
- 测试用例就是一个**文档**，描述输入、动作、或者时间和一个期望的结果，其期的是确定应用程序的某个特性是否正常的工作。
- 测试用例是软件测试的**核心**!

### 4.3.2 测试用例的基本要素

- 基本要素包括

| 名称     |
  | ---------- |
  | 用例编号 |
  | 用例标题 |
  | 用例级别 |
  | 预置条件 |
  | 操作步骤 |
  | 预期结果 |

下面是一些规范

1. 用例编号

测试用例的编号有一定的规则，比如系统测试用例的编号这样定义规则: `PROJECT1-ST-001` ，命名规则是**项目名称+测试阶段类型(系统测试阶段) +编号**。定义测试用例编号，便于查找测试用例,便于测试用例的跟踪。
2. 重要级别

定义测试用例的优先级别，可以笼统的分为“高”和”低“两个级别。一般来说，如果软件需求的优先级为“高“那么针对该需求的测试用例优先级也为“高”反之亦然。
3. 用例标题

对测试用例的描述测试用例标题应该清楚表达测试用例的用途。比如“测试用户登录时输入错误密码时,软件的响应情况”
4. 预置条件

提供测试执行中的各种输入条件。**根据需求中的输入条件,确定测试用例的输入**。测试用例的输入对软件需求当中的输入有很大的依赖性，如果软件需求中没有很好的定，义需求的输入，那么测试用例设计中会遇到很大的障碍。
5. 操作步骤:
   提供测试执行过程的步骤。对于复杂的测试用例,测试用例的输入需要分为几个步骤完成,这部分内容在操作步骤中详细列出
6. 预期结果:
   提供测试执行的预期结果,预期结果应该根据软件需求中的输出得出。如果在实际测试过程中, 得到的实际测试结果与预期结果不符，那么测试不通过;反之则测试通过。
7. 测试用例的格式

公司目前常用的用例模板主要是Word和Excel

### 4.3.3 测试用例设计的基本原则

基本原则：

1. 用成熟测试用例设计方法来指导设计
2. 测试用例的正确性
3. 测试用例的代表性
4. 测试结果的可判定性
5. 测试结果的可再现性
6. 足够详细、准确和清晰的步骤

容易犯的错误：

1. 把测试用例设计等同于测试输入数据的设计
2. 强调测试用例设计得越详细越好
3. 追求测试用例设计“一步到位”
4. 将多个测试用例混在一个用例中
5. 让没有测试经验的人员设计测试用例

### 4.3.4 测试用例的分类

可以分为5大类

1. **白盒测试**用例
2. 软件各项**功能**的测试用例
3. 用户界面测试用例
4. 软件的各项**非功能**测试用例
5. 对软件**缺陷修正所确认**的测试用例

**测试阶段与测试类型关系表**

| 测试阶段 | 测试类型                                                                                        |                     执行人员                     |
| ---------- | :------------------------------------------------------------------------------------------------ | :------------------------------------------------: |
| 单元测试 | 模块功能测试，包含部分接口测试、路径测试                                                        |                     开发人员                     |
| 集成测试 | 接口测试、路径测试，含部分功能测试                                                              | 开发人员，如果测试人员水平较高可以由测试人员执行 |
| 系统测试 | 功能测试、健壮性测试、性能测试、用户界面测试、安全性测试、压力测试、可靠性测试、安装/反安装测试 |                     测试人员                     |
| 验收测试 | 对于实际项目基本同上，并包含文档测试;对于软件产品主要测试相关技术文档                           |              测试人员，可能包含用户              |

### 4.3.5 测试用例的编写依据

- 测试用例的设计必须建立在**需求**的基础之上，根据用户的需求设计,用于检测系统的行为是否与需求所指定的一致。
- 在编写测试用例前，应当了解被测试的软件, 理想条件下需要有可测试的、详细的完 整需求说明书。
- 依据和参考的文档和资料

- 《软件需求说明》及相关文档;
  - 相关的设计说明(概要设计,详细设计等)
  - 与开发组交流对需求理解的记录;
  - 已经基本成型的、成熟的测试用例等。
- 测试与开发的对应关系

| 开发阶段           | 依据文档           | 编写的用例         |
  | -------------------- | -------------------- | -------------------- |
  | 需求分析结束后     | 需求文档           | 系统测试对应的用例 |
  | 概要设计阶段结束后 | 概要设计、体系设计 | 集成测试对应的用例 |
  | 详细设计阶段       | 详细设计文档       | 单元测试对应的用例 |

### 4.3.6 测试用例的评审

- 测试用例的评审能够使用例的结构更清晰，**覆盖的用户场景**更全面;
- 评审的内容
  - 用例设计的**结构安排**是否清晰、合理, 是否利于高效对需求进行覆盖。
  - **优先级安排**是否合理。
  - 是否覆盖测试需求上的**所有功能点**。
  - 用例是否具有很好**可执行性**。如用例的前提条件、执行步骤、输入数据和期待结果是否清晰、正确;期待结果是否有明显的验证方法。
  - 是否已经**删除了冗余的用例**。
  - 是否从**用户层面**来设计用户使用场景和使用流程的测试用例。
  - 是否**简洁，复用性强**。例如，可将重复度高的步骤或过程抽取出来定义为一些可复用标准步骤。(测试用例至少要通过前5个标准。)

## 4.4 软件缺陷跟踪

### 4.4.1 软件缺陷概念与类型

IEEE729-1983对缺陷有一个标准的定义:

- 从产品内部看:
  缺陷是软件产品开发或维护过程中存在的错误、毛病等各种问题。
- 从产品外部看:
  缺陷是系统所需要实现的某种功能的失效或违背。
- 缺陷的存在会导致软件产品在某种程度上不能满足用户的需要。
- 缺陷的表现形式不仅体现在**功能**的失效方面，还体现在其他方面。

以下5个规则之一，均为软件缺陷：

1. 软件未达到产品说明中已标明的功能。
2. 软件出现了产品说明书中指明不会出现的错误。
3. 软件功能超出了产品说明书指明的范围。
4. 软件未达到(超出)产品说明书应达到的目标。
5. 软件测试员认为软件难以理解，不易使用，运行速度慢,或者最终用户认为该软件使用效果不好。

软件缺陷在不同阶段的修复费用:

- 软件从需求、设计、编码、测试一直到交付用户公开使用后的过程中,都可能产生和发现缺陷。
- 随着的时间推移,修复缺陷的费用呈几何级数增长

### 4.4.2 软件缺陷的主要属性

主要属性有三个：1. 缺陷的严重性 2. 缺陷的优先级 3. 缺陷的状态

- 一旦发现软件缺陷，就要设法找到引起这个缺陷的**原因**，分析对产品质量的**影**响，然后确定软件缺陷的**严重性**和处理这个缺陷的**优先级**。
- 各种缺陷所造成的后果是不一样的，有的仅仅是不方便，有的可能是灾难性的。一般问题越严重，其处理优先级就越高

1. 严重性(Severity )是软件缺陷对软件质量的破坏程度

| 标识 | 严重级别              | 严重程度                                                                           |
   | ------ | ----------------------- | ------------------------------------------------------------------------------------ |
   | 1    | 致命的(Fatal)         | 主要功能完全丧失，造成系统崩溃、死机，或造成数据丢失等。                           |
   | 2    | 严重的(Critical)      | 主要功能部分丧失，次要功能全部丧失，功能模块或特性没有实现，或致命的错误声明。     |
   | 3    | 一般的(Major)         | 不太严重的错误，如次要功能模块丧失、提示信息不够准确、用户界面差和操作时间长等。   |
   | 4    | 微小的(Minor)         | 一些小问题如有个别错别字、文字排版不整齐等，对功能几乎没有影响，软件产品仍可使用。 |
   | 5    | 建议的(Enhancemental) | 由问题提出人对测试对象的改进意见或测试人员提的建议、质疑。                         |
2. 优先级(Priority)是处理软件缺陷的先后顺序的指标

| 标识 | 优先级     | 描述                                                                       |
   | ------ | ------------ | ---------------------------------------------------------------------------- |
   | 1    | 高优先级   | 缺陷必须被立即解决。软件的主要功能错误或者造成软件崩溃，数据丢失的缺陷。   |
   | 2    | 一般优先级 | 缺陷需要正常排队等待修复或列入软件发布清单。影响软件功能和性能的一般缺陷。 |
   | 3    | 低优先级   | 缺陷可以在方便时被纠正。                                                   |
3. 软件缺陷的状态

| 缺陷状态        | 描述                                                       |
   | ----------------- | ------------------------------------------------------------ |
   | New(Submitted)  | 已提交的缺陷                                               |
   | Open(Active)    | 确认“最后的提交”，等待处理，或者验证后缺陷仍然存在       |
   | Rejected        | 拒绝“提交的缺陷”，不需要修复或不是缺陷                   |
   | Resolved(Fixed) | 缺陷被修复(开发人员针对缺陷修正后已解决问题或通过单元测试) |
   | Closed          | 测试人员经过验证后，确认被修复的缺陷，将其关闭             |

### 4.4.3 缺陷的生命周期

![image-20230426010222951](http://storage.live.com/items/FECD80CE4F909A96!45013:/image-20230426010222951.png?authkey=AKpqV245EC2xOuk)

### 4.4.4 软件缺陷报告

- 缺陷报告是描述软件缺陷现象和重现步骤的集合。
  软件缺陷报告Software Bug Report(SBR)，通常也称为问题报告单或缺陷记录。
- 缺陷报告是软件测试人员的工作成果之一，
  可以衡量测试人员的工作能力，体现测试的价值。
- 缺陷报告一般由以下几个部分组成

![image-20230426010646479](http://storage.live.com/items/FECD80CE4F909A96!45014:/image-20230426010646479.png?authkey=AKpqV245EC2xOuk)
- 编写缺陷报告需要遵守"5C"准则

- Correct (准确) : 每个组成部分的描述准确，不会引起误解
  - Clear (清晰) : 每个组成部分的描述清晰，易于理解
  - Concise (简洁) :只包含必不可少的信息，不包括任何多余的内容
  - Complete (完整) : 包含复现该缺陷的完整步骤和其他本质信息
  - Consistent (一致) : 按照一致的格式书写全部缺陷报告
- 编写缺陷报告时的注意事项

- 保证重现缺陷
  - 分析故障，使用**最少的步骤**重现缺陷
  - 包含所有重现缺陷的必要步骤
  - 方便阅读
  - 一个缺陷一个报告
  - 使用中性的语言(不做评价)

最后修改：2023 年 04 月 26 日

如果觉得我的文章对你有用，请随意赞赏

发表评论取消回复
使用cookie技术保留您的个人信息以便您下次快速评论，继续评论表示您已同意该条款

评论 *

私密评论

名称 *

🎲

邮箱 *

地址

软件测试学习笔记

酱油瓶 • 2023 年 04 月 18 日

# 1 软件测试的基本概念

## 1.1 软件测试概述

### 1.1.1 软件测试的对象

1. 需求规格说明书
2. 概要设计规格说明书
3. 详细设计规格说明书
4. 源程序
5. 系统
6. 用户手册
7. 帮助文档

其中1-3为阶段性文档；6-7为最终产品文档

### 1.1.2 软件测试的定义 [重要]

### 1.1.3 软件开发生命周期 *

- 软件生命周期

SDLC, Systems Development Life Cycle
  又称为软件生存周期或系统开发生命周期，就是软件的产生直到报废的整个周期。
- 软件生命周期被划分成了若干个阶段:

可行性分析与项目计划、需求分析、系统设计、编码、调试、测试(执行)、维护升级到废弃等阶段。

### 1.1.4 软件测试的目的 [重要]

1. 发现系统的错误
2. 验证系统是否满足需求
3. 为产品放行提供依据
4. 改进开发流程

### 1.1.5 软件质量

软件的一些质量特性的组合，反映了软件满足用户需求的程度。(规定或隐含的需求)

软件质量模型 P16

### 1.1.6 软件测试的原则 [重要]

## 1.2 软件测试的分类 [重要]

### 1.2.1 按测试技术分类

1. 黑盒测试

在程序接口进行测试，它只是检查程序功能是否按照规格说明书的规定正常使用。
   也被称为功能测试或数据驱动测试。
2. 白盒测试

### 1.2.2 按测试方法分类

1. **静态测试**

是指不运行程序，对程序和文档进行分析与检查;静态测试技术又称为静态分析技术。
2. **动态测试**

通过运行程序进行检查、分析程序的执行状态和程序逻辑的外部表现
3. 手动测试

绝大多数公司用的较多的一-种测试，提升人的主观能动性，但耗时，例如游戏类的测试
4. 自动化测试

重复性工作采用该测试方便，但无法发现新的缺陷，例如每秒点击100次

### 1.2.3 按测试阶段分类

1. 单元测试(能发现80%的问题)

单元测试是对软件设计的最小单元- --模块进行正确性检验的测试工作。(如自行车组装，先进行单元测试)

目的: 主要是测试模块在语法、格式和逻辑.上的错误。
2. 集成测试

目的: 检查模块间的接口关系，以便发现与接口有关的各种错误
3. 系统测试 **(重点关注)**

系统测试是将已经集成好的软件系统置于实际运行环境中所进行的测试。(一般指用户真实运行环境模拟测试)

目的: 根据需求分析时确定的标准检验软件是否满足功能、行为、性能和系统协调性等方面的要求。
4. 验收测试

目的: 验证软件功能的正确性和需求的符合性。

### 1.2.4 按软件质量特性分类

- **功能测试**
- **安全测试**
- **性能测试**
- 可靠性测试
- 压力测试
- 安装测试
- 用户界面测试
- **兼容性测试**

## 1.3 软件测试3个重要概念

### 1.3.1 测试用例 (Test case)

测试用例是一组测试输入、执行条件和预期结果的集合。

其目的是要满足一个特定的目标，比如执行一条特定的程序路径或检验是否符合一个特定的需求。

### 1.3.2 测试环境

软件运行的平台，即软件、硬件、网络和历史数据的集合

### 1.3.3 软件缺陷

- 从产品内部看:

缺陷是软件产品开发或维护过程中存在的错误、毛病等各种问题。
- 从产品外部看:

缺陷是系统所需要实现的某种功能的失效或违背。

# 2 黑盒测试

## 2.1 等价类

### 2.1.1 什么是等价类

等价类是指某个输入域的子集合。

### 2.1.2 有效等价类与无效等价类

## 2.2 等价类划分法

### 2.2.1 定义

把所有可能的输入数据划分成若干部分(子集)，然后从每一个子集中选取少数具有代表性的数据作为测试用例。

这是一种典型的，常用的黑盒测试法

### 2.2.2 划分方法

1. 按双边区间划分

如果输入条件规定了取值范围，或值的个数，则可以确立一个有效等价类和两个无效等价类。
2. 按取值划分

如果输入条件规定了输入值的集合，这时可确立一个有效等价类和一个无效等价类。
4. 按限制条件/规划划分

如果规定了输入数据必须遵守的规则或限制条件，可确定一个有效等价类(符合规则)和若干个无效等价类(从不同角度违反规则)

### 2.2.3 等价类测试的类型

根据测试用例的完整性划分

名词解释：

- 弱

是指从各个等价类中选取值时只考虑等价类自身，查出的缺陷属于“单缺陷”，即单一因素造成的缺陷。

即单缺陷假设，**不考虑**取值**组合**
- 强

是指考虑了等价类之间的相互影响，查出的缺陷属于多种因素造成的“多缺陷”。

即多缺陷假设，**考虑**取值**组合**的情况
- 一般

不考虑**无效值**(异常区域)
- 健壮

考虑**无效值**(异常区域)

![等价类测试的类型](http://storage.live.com/items/FECD80CE4F909A96!44948:/image-20230418224002463.png?authkey=AKpqV245EC2xOuk)

## 2.3 边界值分析法

### 2.3.1 定义

### 2.3.2 名词解释

- 边界：指相对于输入等价类和输出等价类而言，稍高于、稍低于其边界值的一些特定情况。
- 边界点：分为上点，内点，离点

![image-20230419150415727](http://storage.live.com/items/FECD80CE4F909A96!44958:/image-20230419150415727.png?authkey=AKpqV245EC2xOuk)

注：不管是闭区间还是开区间，上点都是其边界点，只是上点是否在域内有所区别

### 2.3.3 边界值分析法与等价类划分法的区别

![image-20230419151010680](http://storage.live.com/items/FECD80CE4F909A96!44959:/image-20230419151010680.png?authkey=AKpqV245EC2xOuk)

### 2.3.4 选取数据的原则

1. 如果输入条件规定了值的范围

则应取刚达到这个范围的边界的值，以及刚刚超越这个范围边界的值作为测试输入数据。
4. 如果输出条件规定了值的个数

则用最大个数，最小个数，比最小个数少一,比最大个数多一的数作为测试数据。
5. 分析规格说明，找出其他可能的边界条件

### 2.3.5 边界条件测试用例设计法

1. 一般边界条件测试用例设计法

- 方法

对于一个$n$变量函数，该方法生成的测试用例数为$6n+1$
3. 最坏边界条件测试用例设计法

- 方法

1. 所有变量均可取min、min+、 nom、max- 和max这五个边界值中的任何一个，
     2. 测试用例为五个集合的笛卡儿乘积。
   - 特点

对于一个$n$变量函数，该方法生成的测试用例数为$5^n$
   - 与基本边界条件的区别

- 方法

1. 所有变量均可取min-1、min、 min+、nom、max- 、max和max+1这七个边界值中的任何一个。
     2. 测试用例为七个集合的笛卡儿乘积。
   - 特点

对于一个$n$变量函数，该方法生成的测试用例数为$7^n$

## 2.4 判定表法

### 2.4.1 定义

### 2.4.2 名词解释

### 2.4.3 一个例子

问题描述： “……对于功率大于50马力的机器，并且维修记录不全或已运行10年以上的机器，应给予优先的维修处理……”

### 2.4.4 两种判定表

1. 有限条目判定表
   - 特点:所有条件都是二值条件(真/假)
2. 扩展条目判定表
   - 特点:条件可以有多个值

### 2.4.5 判定表的简化

- 实际使用决策表时，常常先将它简化，简化是以合并相似规则为目标的。
- 判定表的简化主要包含:**规则合并**与**规则包含**

1. 规则合并

无关条件项在逻辑上又可包含其他的条件项取值，具有相同动作的规则还可进一步合并。

例如：将上一节问题的判定表进行简化

## 2.5 因果图法

### 2.5.1 定义

- 因果图法(Cause-Effect Graphics)

结果:输出

### 2.5.2 因果图的关系符号

1. 恒等

```mermaid
     flowchart
     	subgraph 恒等
         A[c1] --- B[e1]
         end
     ```

表示原因与结果之间一对一的对应关系。若原因出现，则结果出现;若原因不出现，则结果也不出现。

例如：

| $c_1$ | $e_1$ |
     | ------- | ------- |
     | 1     | 1     |
     | 0     | 0     |
  2. 非

```mermaid
     flowchart
     	subgraph 非
         A[c1] x--x B[e1]
         end
     ```

表示原因与结果之间的一种否定关系。若原因出现，则结果不出现;若原因不出现反而结果出现。

例如：

| $c_1$ | $e_1$ |
     | ------- | ------- |
     | 0     | 1     |
     | 1     | 0     |
  3. 或

```mermaid
     flowchart
         subgraph V
         A[c1] --- B[e1]
         C[c2] --- B
         D[c3] --- B
         end
     ```

表示若几个原因中有一个出现，则结果出现;只有当这几个原因都不出现时，结果才不出现。(可以有任意个输入)

例如：

```mermaid
     flowchart
         subgraph ^
         A[c1] --- B[e1]
         C[c2] --- B

end
     ```

表示若几个原因都出现，结果才出现;若几个原因中有一个不出现，结果就不出现。

例如：

| $c_1$ | $c_2$ | $e_1$ |
     | ------- | ------- | ------- |
     | 1     | 1     | 1     |
     | 1     | 0     | 0     |
     | 0     | 1     | 0     |

### 2.5.3 因果图的约束符号

1. E(Exclusive)约束 （异/互斥）

```mermaid
     flowchart LR
         A(E) -.- a[a]
         A -.- b[b]
     ```

表示几个原因不会同时成立;可能他们都不成立，但最多有一个成立。
  2. I(Include)约束（或/包含）

```mermaid
     flowchart LR
         A(I) -.- a[a]
         A -.- b[b]
         A -.- c[c]
     ```

表示几个原因中至少有一个必须成立，当然也可能都成立。
  3. O(Only)约束（唯一）

```mermaid
     flowchart LR
         A(O) -.- a[a]
         A -.- b[b]
     ```

表示几个原因中必须有且仅有一个成立。
  4. R(Request)约束（要求）

```mermaid
     flowchart TB
         subgraph R
         a[a] -.-> b[b]
         end
     ```

表示当a出现时，b必须也出现。
- 输入条件的约束类型 [了解]

M(Mandate)约束（屏蔽）

```mermaid
  flowchart TB
  	subgraph M
      a[a] -.-> b[b]
      end
  ```

表示当a是1时，b必须是0;而当a为0时，b的值不一定
- 总结

### 2.5.4 因果图法设计用例步骤

### 2.5.5 特点 [重要]

- 优点

能把复杂的问题按各种可能的情况一一列举出来，简明而易于理解，也可避免遗漏。
  可以指出需求规格说明书的不完整性和不明确之处。
- 缺点

不能表达重复执行的动作，例如**循环结构**
- 因果图与判定表的选择

- 条件和动作关系不明确：先使用因果图
  - 如果需求是以判定表形式给出的、项目在设计阶段就采用了判定表：直接用判定表:设计测试用例

# 3 白盒测试

## 3.1 概念

### 3.1.1 白盒测试的特点

不仅因为黑盒测试存在一定的缺陷，还因为进行白盒测试能够更全面地发现软件缺陷和问题，有助于提高软件质量和可靠性。具体原因如下:

- 定位问题更精确:

白盒测试可以在源代码级别检查软件的内部逻辑，可以更精确地定位问题，减少排查问题的时间和成本。
- 发现隐藏问题:

白盒测试可以查看软件内部代码，发现开发人员可能遗漏的特殊情况而导致的问题，这些问题在黑盒测试中很难被发现。
- 提高测试的有效性:

通过白盒测试可以检查代码中的逻辑错误和潜在的安全漏洞，可以更好地确保测试覆盖全面。
- 确保软件的质量:

白盒测试能够发现软件的各种问题，包括性能问题、可维护性问题、可扩展性问题等，确保软件的质量达到目标要求。

### 3.1.2 定义与目的

- 白盒测试(White-box testing)

是通过对程序内部结构的分析、检测来寻找问题，又称透明盒测试和逻辑驱动测试
- 目的

## 3.2 静态白盒测试

### 3.2.1 名词解释

静态白盒测试：

就是进行静态白盒测试的过程。正式审查的含义很广，从两个程序员的交谈,到软件设计和代码的详细,严格检查均属于此过程.
- 代码审查单

用于把代码与标准或规范进行对照补充，并确保代码符合项目的设计要求。

### 3.2.2 正式审查(Formal review)

正式审查的4个基本要素

### 3.2.3 静态测试

### 3.2.4 静态分析

## 3.3 动态白盒测试

- 动态白盒测试：
- 由于是动态的，就一定是测试运行中的程序，由于是白盒，就一定要洞察盒子里面，检查代码并观察运行状况。

生成测试数据、分析测试结果的工作量大，使开展测试工作费时、费力、费人。
- 动态白盒测试的两种常用技术:

### 3.3.1 路径测试

- 基本路径测试方法

可简称流图，是对程序流程图进行简化后得到的，它可以更加突出的表示程序控制流的结构。
- 控制流图中包括两种图形符号：**节点**和**控制流线**

![image-20230423233128657](http://storage.live.com/items/FECD80CE4F909A96!44995:/image-20230423233128657.png?authkey=AKpqV245EC2xOuk)
- 判定节点和区域

包含条件的节点被称为**判定节点**，由判定根节点发出的边必须终止于某一个节点由边和节点所限定的范围被称为**区域**
- 图矩阵

![image-20230425225544745](http://storage.live.com/items/FECD80CE4F909A96!45007:/image-20230425225544745.png?authkey=AKpqV245EC2xOuk)
- 环形复杂度

- 环形复杂度又称为圈复杂度,以图论为基础,为我们提供了非常有用的软件度量。
  - 两种计算方法：

1. 其中，E是控制流图中边的数量, N是控制流图中的节点数量。

$$
       V(G)= E-N+2

$$
    2. 其中, P是控制流图G中判定节点的数量。

$$
       V(G)= P+1

$$
- 独立路径以及确定方法

1. 选择一个基线路径。
    2. 沿基线路径后退,碰到**判定节点后翻转**,将翻转后的路径作为基线路径,重复本步骤,直到所有的节点都被翻转。

注意:为遵循先易后难的原则, 对于循环，一般先让路径跳过循环,然后考虑进入循环。基本路径集通常并**不唯一**。
  - 一个样例

![image-20230425230321085](http://storage.live.com/items/FECD80CE4F909A96!45008:/image-20230425230321085.png?authkey=AKpqV245EC2xOuk)

![image-20230425230329867](http://storage.live.com/items/FECD80CE4F909A96!45009:/image-20230425230329867.png?authkey=AKpqV245EC2xOuk)
- 基本路径测试法的测试步骤

### 3.3.2 覆盖测试法

依据覆盖源程序语句的详细程度不同和覆盖目标的不同，逻辑覆盖主要可分为:

1. 语句覆盖
2. 判定覆盖
3. 条件覆盖
4. 判定/条件覆盖
5. 条件组合覆盖

下面是一个样例的代码和流程图

```javascript
func(int x,int y,int Z)
{
    if((y>1)&&(z==0))
		x=x/y;
	if((y==2)||(x>1))
		X=x+1;
}

```

![image-20230425231243892](http://storage.live.com/items/FECD80CE4F909A96!45010:/image-20230425231243892.png?authkey=AKpqV245EC2xOuk)

以下是几种覆盖的具体含义：

1. 语句覆盖

通过选择足够的测试用例，使被测程序的**每个语句至少被执行一次**

**优点**: 可以很直观地从源代码得到测试用例，无须细分每条判定表达式。

**缺点**: 由于这种测试方法仅仅针对程序逻辑中显式存在的语句，但对于隐藏的条件是无法测试的。

| 测试用例 | 输入        | 预期输出 | 被测路径 |
   | ---------- | ------------- | ---------- | ---------- |
   | CASE     | x=4,y=2,z=0 | x=3      | sacbed   |
2. 判定覆盖

**优点**: 判定覆盖具有比语句覆盖强的测试能力。同样判定覆盖也具有和语句覆盖一样的简单性，无须细分每个判定就可以得到测试用例。

特点：条件覆盖并不能包含判定覆盖,对于下述测试用例，分支bd并未出现。

**优点**：能同时满足判定、条件两种覆盖标准。

**缺点**：判定/条件覆盖准则的缺点是未考虑条件的组合情况.

是指通过设计足够多的测试用例，使得运行这些测试用例时，每个判定中**条件结果的所有可能组合至少出现一次**

基本思想是:设计所有的测试用例,来覆盖程序中的所有可能的执行路径。

**优点**: 这种测试方法可以对程序进行彻底的路径测试。

**缺点**: 需要设计大量、复杂的测试用例,使得工作量呈指数级增长。

# 4 软件测试流程

## 4.1 概念

### 4.1.1 基本流程与阶段

### 4.1.2 主要的测试文档

### 4.1.3 需求分析

- 目的：从源头把握软件质量,确保开发结果与实际需求相一致角色与职责
- 角色与职责：

《需求规格说明书》编写完成
- 输入/输出

输入:《需求规格说明书》
  输出: 需求缺陷

### 4.1.4 制定测试计划

- 测试计划描述所有要完成的测试工作

- 测试负责人:根据《项目整体计划》《需求规格说明书》编制《测试计划》，以便测试工作正常开展。
- 启动标准

需求评审完成
- 输入/输出

输入:《需求规格说明书》《项目整体计划》
  输出:《测试计划》

### 4.1.5 制定测试方案

- 测试方案描述需要 **[重点]**

1. 测试的特性
  2. 测试的方法
  3. 测试环境的规划
  4. 测试工具的设计和选择
  5. 测试用例的设计方法
  6. 测试代码的设计方案。
- 目的

从技术上对要测试的系统进行分析和测试设计，来保证测试的覆盖度。
- 角色与职责

- 经验丰富的测试人员:

根据测试计划中的测试范围、类型来确定测试采用的技术、方法和测试用例的目录大纲。
  - 组内测试人员评审与讨论
- 启动标准.

测试计划编写完成, 任务分配完成
- 输入/输出

输入:《需求规格说明书》《测试计划》
  输出:《测试方案》

### 4.1.6 设计测试用例

### 4.1.7 搭建测试环境

一般来说，软件产品提交测试后，开发人员应该提交一份产品安装指导书，在指导书中详细指明软件产品运行的软硬件环境。

### 4.1.8 执行测试用例

### 4.1.9 编写测试报告

- 测试报告，是对测试的过程和结果的汇总描述

其核心内容为：

## 4.2 软件测试计划

### 4.2.1 概念 [重要]

测试计划：

测试计划的内容：

1. 确定测试的目标、进度、人力、环境、工具等
2. 为达到测试目标采用测试类型
3. 功能性需求
4. 非功能性需求
5. 针对测试需求采用的测试方法

### 4.2.2 测试计划的设计与实现

需要涵盖以下几个方面

1. 资源

- 人力资源
   - 硬件和软件资源
   - 其他资源
2. 时间表

- 某项工作开始的时间？
   - 某项工作需要多少时间完成？

评估工作量+测试效率评估=确定测试用时间
   - 某项工作需要多长时间完成？
3. 测试环境

## 4.3 软件测试用例

### 4.3.1 测试用例的基本概念和目的

- 什么是测试用例

### 4.3.2 测试用例的基本要素

- 基本要素包括

| 名称     |
  | ---------- |
  | 用例编号 |
  | 用例标题 |
  | 用例级别 |
  | 预置条件 |
  | 操作步骤 |
  | 预期结果 |

下面是一些规范

1. 用例编号

对测试用例的描述测试用例标题应该清楚表达测试用例的用途。比如“测试用户登录时输入错误密码时,软件的响应情况”
4. 预置条件

公司目前常用的用例模板主要是Word和Excel

### 4.3.3 测试用例设计的基本原则

基本原则：

容易犯的错误：

### 4.3.4 测试用例的分类

可以分为5大类

1. **白盒测试**用例
2. 软件各项**功能**的测试用例
3. 用户界面测试用例
4. 软件的各项**非功能**测试用例
5. 对软件**缺陷修正所确认**的测试用例

**测试阶段与测试类型关系表**

### 4.3.5 测试用例的编写依据

### 4.3.6 测试用例的评审

## 4.4 软件缺陷跟踪

### 4.4.1 软件缺陷概念与类型

IEEE729-1983对缺陷有一个标准的定义:

以下5个规则之一，均为软件缺陷：

软件缺陷在不同阶段的修复费用:

- 软件从需求、设计、编码、测试一直到交付用户公开使用后的过程中,都可能产生和发现缺陷。
- 随着的时间推移,修复缺陷的费用呈几何级数增长

### 4.4.2 软件缺陷的主要属性

主要属性有三个：1. 缺陷的严重性 2. 缺陷的优先级 3. 缺陷的状态

1. 严重性(Severity )是软件缺陷对软件质量的破坏程度

### 4.4.3 缺陷的生命周期

![image-20230426010222951](http://storage.live.com/items/FECD80CE4F909A96!45013:/image-20230426010222951.png?authkey=AKpqV245EC2xOuk)

### 4.4.4 软件缺陷报告

![image-20230426010646479](http://storage.live.com/items/FECD80CE4F909A96!45014:/image-20230426010646479.png?authkey=AKpqV245EC2xOuk)
- 编写缺陷报告需要遵守"5C"准则

发表评论 取消回复 使用cookie技术保留您的个人信息以便您下次快速评论，继续评论表示您已同意该条款

软件测试 学习笔记

发表评论取消回复
使用cookie技术保留您的个人信息以便您下次快速评论，继续评论表示您已同意该条款

软件测试学习笔记