测试左移体系

文章目录

一、测试左移简介
- [1. 为什么要做测试左移？](#1. 为什么要做测试左移？)
- [2. 成本与效益分析](#2. 成本与效益分析)
- [3. 测试左移的主要内容](#3. 测试左移的主要内容)
[二、代码审查（Code Review）](#二、代码审查（Code Review）)
- [1. 定义与目的](#1. 定义与目的)
- [2. 开发人员收益](#2. 开发人员收益)
- [3. 审查维度](#3. 审查维度)
三、代码审查平台实践
- [1. Gerrit Code Review](#1. Gerrit Code Review)
- [2. GitLab Merge Request](#2. GitLab Merge Request)
四、代码审计平台：SonarQube
- [1. 质量保障闭环流程](#1. 质量保障闭环流程)
- [2. 项目质量仪表盘](#2. 项目质量仪表盘)
- [3. 覆盖率集成与缺陷案例](#3. 覆盖率集成与缺陷案例)
- - 覆盖率分析
  - [典型 Bug 案例](#典型 Bug 案例)
- [4. 扫描示例](#4. 扫描示例)

一、测试左移简介

"测试左移 "（Shift-Left Testing）是现代软件开发中非常核心的质量保障理念。

在传统的软件开发中，测试往往被安排在开发完成之后（相当于软件生命周期的"右侧"），就像等病人病倒了再去医院做全面检查。测试左移，就是把"检查"的动作提前到"生病"之前 。它主张在软件开发生命周期的早期阶段（如需求分析、架构设计、编码初期）就引入测试活动。它的本质思想是：越早发现不合理的地方，出问题的几率就越低。

1. 为什么要做测试左移？

做测试左移的核心驱动力主要有两点：
- 大幅降低修复成本：软件工程有一个著名的"缺陷成本放大效应"。在需求或设计阶段发现并修复一个Bug的成本，可能只有上线后修复成本的十分之一甚至更少。越往后拖，修复代价呈指数级上升。
- 加速交付与提升质量：在早期就把模糊的需求和架构缺陷解决掉，能避免开发后期的"推倒重来"和大规模返工，从而让软件更快速、更流畅地发布。

总结：测试左移通过在研发早期发现并修复缺陷，能够有效保障产品质量，降低项目沟通成本，并显著提高研发效率。

2. 成本与效益分析

根据 Capers Jones 在《Applied Software Measurement》（1996）中的研究数据，软件缺陷的修复成本随着开发阶段的推进呈指数级上升

缺陷修复成本的指数级增长
- 编码阶段（Coding）：修复成本为$25。
- 单元测试（Unit Test）：修复成本为$100。
- 功能测试（Function Test）：修复成本为$250。
- 系统测试（System Test）：修复成本为$1000。
- 发布后（After Release）：修复成本飙升至$16,000。
缺陷引入与发现的错位
- 通过上述研究数据可以看出
  - 引入高峰：85% 的缺陷是在编码阶段引入的。
  - 发现滞后：在编码阶段发现的缺陷比例极低，大部分缺陷直到系统测试阶段才被发现。
- 结论：尽早发现缺陷具有巨大的经济性优势。

3. 测试左移的主要内容

需求分析与评审
代码评审（Code Review）
代码审计与代码静态分析
自动化测试左移
- 单元测试
  - 为什么是单元测试？
    *
    
    因为 UI 自动化测试的执行效率和维护成本要远远大于单元测试，所以要把质量保障的重心从"依赖少数昂贵、缓慢的UI测试"，转移到"依靠大量快速、精准的单元测试"上来。
- 覆盖率统计
应用监控
测试用例生成

一句话总结：测试左移的实践，就是把质量活动从"测试阶段"分散到"需求、开发、评审"等每一个上游环节，通过"人防"（评审）和"技防"（自动化工具）相结合，尽早地发现和解决问题。

二、代码审查（Code Review）

1. 定义与目的

代码审查是指对计算机源代码系统化地审查，常用软件同行评审的方式进行，其目的是在找出及修正在软件开发初期未发现的错误，提升软件质量及开发者的技术。代码审查常以不同的形式进行，例如结对编程、非正式的看过整个代码，或是正式的软件检查。

2. 开发人员收益

保持工作专注度与一致性。
学习最佳实践与新技术。
实现代码库风格与质量的统一。

3. 审查维度

设计：代码设计是否合理，是否适合代码库。
功能：是否按预期执行，是否对用户有益。
复杂性：代码是否易于理解和使用。
命名：变量、类、方法命名是否清晰。
注释：注释是否具体且完整。

三、代码审查平台实践

1. Gerrit Code Review

界面特征：展示变更集（Change Set）元数据，包括状态、ID、所有者、审阅者及提交要求（如 Code-Review, Verified）。
核心功能 ：
- 差异对比：文件列表展示增删行数（Delta），支持查看具体差异（View Diff）。
- 评审流程：支持打分（+1/-1）、评论、解决冲突。
- 关联变更：展示依赖关系链（Relation chain）。

2. GitLab Merge Request

界面特征：展示合并请求（MR）详情，包括源分支与目标分支、提交时间。
核心功能 ：
- 审批机制：显示赞成票数，支持"批准（Approve）"操作。
- 合并选项：提供删除源分支、压缩提交（Squash commits）等选项。
- 代码差异：高亮显示新增（绿色）与删除（红色）代码行，支持行级评论。

四、代码审计平台：SonarQube

1. 质量保障闭环流程

实时分析：开发者使用 SonarLint（IDE 插件）进行实时代码分析。
代码提交：代码推送至版本控制系统（Git/SVN 等）。
CI 构建：CI 服务器（Jenkins/Bamboo 等）触发自动构建与代码分析。
报告发布：SonarQube Scanner 将分析报告发布至 SonarQube 服务器。
数据存储：分析结果存储于数据库（MySQL/PostgreSQL 等）。
问题管理：开发者在平台管理问题，形成闭环。
外部集成：通过 API/JMX 对接其他监控系统。

2. 项目质量仪表盘

质量门禁（Quality Gate）：显示项目是否通过质量检查（Passed/Failed）。
缺陷与漏洞：展示 Bugs（缺陷）和 Vulnerabilities（漏洞）的数量及评级（A-E）。
代码异味：统计技术债务（Debt）天数及代码异味数量。
测试覆盖率：显示整体覆盖率（如 87.0%）及新代码覆盖率。

3. 覆盖率集成与缺陷案例

覆盖率分析

指标：行覆盖率（Line Coverage）、条件覆盖率（Condition Coverage）。
案例：OwnerController.java 文件显示 100% 覆盖，绿色高亮表示已覆盖，灰色表示未覆盖。

典型 Bug 案例

问题：条件判断逻辑错误，导致表达式恒为假。
提示：工具提示"Change this condition so that it does not always evaluate to 'false'"，标记为"Major"级别的 Bug。

4. 扫描示例

litmall-core：Bugs 8 个（E 级），覆盖率 0.0%（红色），存在严重质量风险。
petclinic：Bugs 0 个（A 级），覆盖率 94.8%（绿色），质量健康。