# 质量管理

## 测试基础理论

### 测试分类

```tree
 - 软件测试分类
  - 按项目流程阶段划分
    - 单元测试
      - 模块接口测试
      - 局部数据结构测试
      - 路径测试
      - 错误处理测试
      - 边界条件测试
    - 集成测试
      - 系统内单元间的集成测试
    - 系统测试
      - 功能测试
      - 性能测试
        - 空间性能
        - 时间性能
      - 负载测试
      - 安全测试
      - 兼容性测试
      - 本地化国际化测试
      - 安装卸载测试
    - 集成测试
      - 系统间的集成测试
    - 验收测试
      - 功能确认测试
      - 安全可靠性测试
      - 易用性测试
      - 可扩充性测试
      - 兼容性测试
      - 资源占用率测试
      - 用户文档资料测试
      - 非正式验收测试
        - α测试
        - β测试
     - 线上测试
      - 线上只读测试
      - A/B测试
  - 按代码可见度划分
    - 黑盒测试
    - 白盒测试
    - 灰盒测试
  - 按代码是否被运行划分
    - 静态测试
    - 动态测试
  - 按是否需要人工干预划分
    - 手工测试
    - 自动化测试
  - 按不同的测试目的划分
    - 端到端测试
    - 冒烟测试
    - 回归测试
    - 随机测试
    - 探索式测试
```

### 用例设计

```tree
- 用例设计
   - 方法
     - 等价类
     - 边界值
     - 因果图
     - 判定表
     - 正交表
     - 错误推测
     - 场景分析
   - 原则
     - 基于需求
     - 场景化
     - 原子化
     - 可判定
     - 正交
     - 独立
     - 可回归
```

#### 用例设计方法

- 等价类：某个输入域的子集合，集合内各值对于程序来说是等价的
- 边界值：等价类的边界值和边界附近值
- 因果图：各输入间有约束关系，列出输入和输出，得出因果图
- 判定表：有因果图得出判定表，精简判定表
- 正交表：将不同因素的水平组合列成表格
- 错误推测：根据经验进行错误推断来设计测试
- 场景分析：根据实际用户使用场景来设计测试

#### 用例设计原则

- 基于需求：用例设计是为了验证需求
- 场景化：基于场景设计测试用例
- 原子化：一个测试用例只验证一个测试点
- 可判定：应有预期结果，可判断通过或不通过
- 正交：用例验证部分需正交，不重叠验证
- 独立：用例之间相互独立
- 可回归：用例可回归，且多次回归应有稳定一致的结果

### 缺陷管理

```process-card
| 缺陷收集 | 缺陷分析 | 缺陷预防  |
|-|-|-|
| 缺陷模板 | 缺陷分类 | 可测性 |
| 生命周期| 缺陷统计 | 缺陷响应力 |
| 管理工具 | 缺陷分布 | 敏捷过程 |
| 缺陷扫除 | 缺陷报告 | 二八法则 |

config: {"colors": [{"bg":"#e55852","font":"#b71a09"},{"bg":"#e98832","font":"#c85113"},{"bg":"#f0d668","font":"#b88d0f"},{"bg":"#a4c9cf","font":"#598893"},{"bg":"#47c0af","font":"#175a54"},{"bg":"#387fd5","font":"#9ac9f5"},{"bg":"#7753df","font":"#cbb5f8"}]}
```

#### 缺陷分类

出自《软件之道：软件开发问题争议剖析》

 - 遗留。前一个版本未解决而遗留下的问题
 - 需求。在需求分析环节出现的问题
 - 设计。在构建和设计环节出现的问题
 - 代码编写。在代码编写环节出现的问题
 - 测试环境。在搭建或准备测试环境时出现的问题
 - 测试。测试中发生的问题（如运行故障等）
 - 重复。已经报告过的问题
 - 非问题。由于用户误触界面或者功能所产生的问题
 - 其他。其他无法分类的问题，例如硬件问题等。

示例：

| 类型    | 比例   |
|--------|-------|
| 遗留  | 4.0%     |
| 需求   | 4.9%    |
| 设计    | 10.6%  |
| 代码编写 | 18.2%  |
| 测试环境 | 19.1%  |
| 测试    | 5.7%   |
| 重复    |  13.9%  |
| 非问题  | 15.9%   |
| 其他    | 7.8%    |

#### 缺陷分类统计

```pie
 - 不同阶段引入缺陷数量占比
   - Design: 21
   - Dev: 19
   - QA: 4
   - UAT: 12
```

```pie
 - 缺陷不同状态停留时长占比
   - Ready for Dev: 15
   - In Dev: 19
   - Dev Done: 21
   - In QA: 12
```

```pie
 - 缺陷引入原因占比
   - 边界情况未覆盖: 25
   - 重构破坏原有功能: 23
   - 分支未覆盖: 19
   - 前端显示: 15
   - 业务需求缺失: 11
   - 开发新功能破坏原有功能: 8
   - 环境配置: 5
```

#### 提升缺陷响应力

```process-table
| 尽早发现 | 快速定位 | 及时响应  |
|-|-|-|
| 小步迭代 | 日志 | 灾备 |
| 测试覆盖率 | 监控 | 分级反馈机制 |
| 持续集成 | 工具 | |
```

#### 软件可测性

- 可操作性：运行的越好，被测试的效率越高
- 可观察性：所看见的，就是所测试的
- 可控制性：对软件的控制越好，测试越能够被自动执行与优化
- 可分解性：通过控制测试范围，能够更好地分解问题，执行更灵活的测试
- 简单性：需要测试的内容越少，测试的速度越快
- 稳定性：改变越少，对测试的破坏越小
- 易理解性：得到的信息越多，进行的测试越灵活

### 软件生命周期

## 测试相关主题

### 功能测试

### 自动化测试

### 性能测试

### 安全测试

### 大数据测试

### 微服务测试

### 精准测试

### AI 测试

### 探索式测试

### 本地化国际化测试

### 需求测试

## 测试工具及选型

## 测试管理

### 测试数据管理

### 测试环境管理

### 测试计划

### 测试策略

测试策略回答以下问题：

| 问题           | 示例                                                                                                     |
| -------------- | -------------------------------------------------------------------------------------------------------- |
| 测试对象       | ToC 的互金 APP，可进行小额借贷                                                                           |
| 测试范围       | 新增集成风控大数据平台的风险评估功能                                                                     |
| 测试目标       | 保证集成功能顺利上线，不影响系统已有其他功能和业务逻辑                                                   |
| 测试重点       | 集成风控大数据平台的功能，根据返回的风险等级实时生成推荐商品列表                                         |
| 测试难点       | 不同用户画像的测试用户数据的准备，与风控系统的集成                                                       |
| 测试深度和广度 | 深度-主流程的分支覆盖率达到 100%，非主流程 80%；广度-集成点需求覆盖率 100%，非集成点的功能回归覆盖率 70% |
| 测试活动安排   | 各类测试方法的占比、采用什么测试方式，工具选型，测试资源分配，测试流程等内容                             |
| 测试效果评价   | 需求覆盖率、上线后产生紧急修复缺陷数                                                                     |

### 缺陷预防

### 风险管理

### 质量成熟度评估

```radar
 - 质量成熟度评估模型
  - 质量内建: 3 -> 4
  - 优化业务价值: 2 -> 2
  - 质量统一，可视化: 1 -> 5
  - 全员参与: 3 -> 4
  - 快速交付: 4 -> 5
  - 测试作为资产: 2 -> 3
  - 快速反馈: 5 -> 5

config: {"legend": ["当前", "未来"], "areaColor": ["#F37C20", "#E9BD1E"]}
```

## 敏捷测试

### 敏捷测试宣言

- **全程的测试介入** over 孤立的测试阶段
- **团队整体对质量负责** over 测试人员独力把关质量
- **持续性的精准自动化测试** over 回归式的全量自动化测试
- **质量内建** over 质量检测

### 敏捷测试原则

1. 我们的目标在于和团队一起尽快地交付高质量软件。
1. 测试人员尽早参与软件早期阶段，与所有团队角色合作，通过实例化需求，确保对业务价值理解的一致性。
1. 测试人员关注生产环境状态，收集数据，指导和优化前期的分析、开发和测试。
1. 测试人员和开发人员同处一个产品项目团队，而不是独立的测试团队或部门。
1. 测试人员负责探索性测试，和开发人员结对，设计、实现和维护自动化测试。
1. 自动化测试在流水线中持续精准执行，快速发现每次代码提交对于已有功能的影响。
1. 测试数据对于自动化测试是充分的，并能按需获得。
1. 测试活文档化，和代码一起，作为知识资产进行版本化管理。
1. 自动化测试需要有效的分层。
1. 预防缺陷，而不是关注缺陷的数量。

### 质量内建

## 软技能

### QA 胜任力模型

### 测试发展方向

### 测试人员招聘

### 沟通与引导

### QA 读书雷达

```tech-radar
 - 实践/案例
   - 基础
     - 《持续交付：发布可靠软件的系统方法》
     - 《Google软件测试之道》
     - 《How We Test Software at Microsoft》
   - 启发
     - 《移动APP测试的22条军规》
     - 《Explore It!》
     - 《软件测试实践（微软技术专家经验总结）》
     - 《影响力》
 - 理论
   - 基础
     - 《敏捷软件测试：测试人员与敏捷团队的实践指南》
     - 《软件测试的经验与教训》
     - 《硝烟中的Scrum和XP》
     - 《The Art of Application Performance Testing》
     - 《软件测试》
     - 《软件测试的艺术》
     - 《高级软件测试.卷2：高级软件测试经理》
   - 启发
     - 《实例化需求》
     - 《人人都是产品经理》
     - 《咨询的奥秘》
     - 《金矿》
     - 《你的灯还亮着吗？》
     - 《测试之美》
     - 《重来》
     - 《大教堂与集市》
 - 工具
   - 基础
     - 《基础设施即代码：云服务器管理》
     - 《Cucumber: 行为驱动开发指南》
     - 《鸟哥的Linux私房菜》
     - 《看板方法》
   - 启发
     - 《The Cucumber Book》
     - 《数据挖掘概念与技术》
 - 技术
   - 基础
    - 《用户故事与敏捷方法》
    - 《探索式软件测试》
    - 《白帽子讲Web安全》
    - 《测试驱动开发》
   - 启发
    - 《探索吧！深入理解探索式软件测试》
    - 《探索式测试实践之路》
    - 《面向对象分析与设计》
    - 《测试驱动开发的艺术》
    - 《完美软件：对软件测试的各种幻想》
    - 《Fifty Quick Ideas on How to Improve Your Tests》
```
