企业官网建设流程全解析

第 9 章 软件质量保证与过程改进

学习目标

• 区分 QA、QC、测试、审计各自的定位
• 掌握软件质量模型的组成(功能、性能、可靠性、可用性、可维护性、可移植性)
• 理解 ISO/IEC 25010 质量特性
• 掌握 CMMI 的五个等级及含义
• 了解六西格玛与 TQM 在软件中的应用
• 建立"度量驱动改进"的循环
• 掌握评审体系的设计要点

9.0 质量问题的本质

质量问题的表象在产品(缺陷、投诉),根因多在过程(过程有洞,产品缺陷只是结果流出)。这决定了质量工作的分层:

产品层: 测试(抓流出) —— 第 6 章 过程层: QA(堵源头) —— 本章 组织层: 过程改进(让过程自进化) —— 本章

只做产品层的工作 = 在河边捞鱼;过程层与组织层的工作 = 治理上游。三层都要做,但层级越高,杠杆越大。

9.1 QA、QC、测试、审计

核心区别:测试找的是产品缺陷,QA 找的是过程缺陷(过程有洞,产品缺陷只是结果)。

类比:测试是"检测出坏水果",QA 是"让果园不再长出坏水果"。

四者的产出对照

OOS 实例:QA 月度分析发现"集成缺陷占比连续两月 25%+“(产品层症状)→ 根因是"接口契约无人评审”(过程层漏洞)→ 改进项"契约变更强制评审 + 契约测试"(第 12 章)。这条链路就是 QA 区别于测试的地方:从缺陷分布倒推过程漏洞。

9.2 软件质量模型

ISO/IEC 25010 产品质量特性(7 大特性)

1. 功能适合性:完整性、正确性、合适性;
2. 性能效率:时间特性、资源利用率;
3. 兼容性:共存性、互操作性;
4. 可用性(易用性):易学、易操作、防错;
5. 可靠性:成熟性、可用性(不中断)、容错、可恢复性;
6. 安全性:保密性、完整性、抗抵赖、可核查;
7. 可维护性:模块化、可复用、可分析、可修改、可测试;
8. 可移植性:适应性、可安装、可替换、共存。

质量是多维的:一个系统可以"功能全对"但"不可维护"或"不安全"——质量 ≠ 无缺陷。

质量特性 → 验收手段映射(对照 SRS 用):

质量与过程的关系

• 质量是**内建(built-in)的,不是检出来(inspected)**的;
• 过程稳定 → 产品质量可预期;过程随机 → 质量靠运气;
• 因此 QA 的杠杆在过程:规范的活动、明确的工件、强制的评审、可量化的度量。

"质量内建"的落地机制(按阶段)

检验方法:随机抽一个上线缺陷,问"哪一层的内建机制本可以拦住它?"——答案的分布就是过程漏洞地图。

9.3 软件过程改进

改进循环(Plan-Do-Check-Act)

现状度量(基线) → 识别瓶颈 → 设定改进目标(可量化) → 试点 → 度量对比 → 推广/调整

纪律:

• 没有基线度量就不谈改进("感觉变好了"不算);
• 一次只改进 1–2 个过程,避免多线作战无法归因;
• 改进要有 Owner 与退出标准(达到目标或明确失败)。

改进项目书模板(一页):

改进项: 集成契约测试前置 基线: 集成缺陷占比 25%(近两月) 目标: 两季度内 ≤18% 试点: 订单-支付接口(1 个团队) 动作: 契约变更强制评审 + Pact 契约测试进 CI Owner: QA-李 期限: 2026-Q4 成功判据: 试点接口集成缺陷占比 ≤18% 退出条件: 两季度未达 → 复盘终止或调整

CMMI(能力成熟度模型集成)

CMMI 将组织过程成熟度分为 5 级:

要点:

• 等级是能力描述,不是"分数越高越好"——等级 2 的纪律可能比"名义 4 级但执行空心化"更有价值;
• CMMI 的价值不在认证,而在过程资产的显式化与可传承;
• 常见失败:为评估而评估,过程文档与实际执行"两张皮"。

各级的"可观察信号"(不靠评估报告):

• 1 级:换个人做同样项目,结果天差地别;
• 2 级:每个项目有自己的计划与变更记录,但做法不一;
• 3 级:组织有标准过程库,项目"裁剪"而非"自创";
• 4 级:过程指标有统计控制(如"缺陷密度均值 ± 控制限"),异常可预警;
• 5 级:改进由数据与实验驱动,有"为什么改"的证据链。

六西格玛(6σ)与 TQM

• 六西格玛:以 DMAIC(定义-测量-分析-改进-控制)框架追求过程缺陷率极低(3.4 缺陷/百万机会);软件中多用于过程分析(缺陷根因、变更失败率),而非字面追求 6σ 缺陷率;
• TQM(全面质量管理):质量是全员、全过程、全组织的责任,持续改进 + 客户导向;
• 共同内核:数据驱动、根因分析、持续循环。

DMAIC 在软件中的对应:

9.4 软件度量体系

度量三原则

1. 为决策而度量:每个指标绑定一个要回答的问题;
2. 相对趋势 > 绝对值:环比/同比比单点值有意义;
3. 不用于个人考核:防古德哈特定律(指标一旦成为目标,就不再是好指标)。

常用度量分组

反例:"代码行数"作为产出指标 → 催生冗长代码;"Bug 数"考核开发 → 催生互相甩锅与少报。

度量体系设计步骤(可复用)

1. 列决策:列出团队每月要做的 5–8 个决策(是否发布、是否加人、改进哪);
2. 配指标:每个决策配 1–2 个能回答它的指标(指标总数控制在 ~15 个);
3. 定口径:统一定义与数据来源(谁算、怎么算、哪来);
4. 建看板:自动采集优先,手工填报的指标 ≤1/3;
5. 定节奏:月度回顾看趋势,异常触发专项;
6. 季度清理:连续两个季度无人引用的指标下线(指标通胀是度量体系第一杀手)。

9.5 评审(Review)体系

评审纪律:

• 作者不主持;
• 对事不对人,产出问题清单并闭环;
• 规模控制:一次评审材料 ≤ 一人半天可消化;
• 缺陷发现率是评审有效性的天然度量(长期为 0 说明评审走过场)。

正式技术评审(FCR)流程(适用于需求/设计大工件)

1. 准备:评审目标 + 检查单 + 材料预发(提前 2 天);
2. 会前:各自预审并标注重疑点(会上不现场读材料);
3. 会中:主持人(非作者)引导,逐条过检查单,问题分级记录;
4. 会后:问题清单 48 小时内闭环计划;重大未决项升级;
5. 归档:评审记录(日期/参与人/问题/结论)进版本库,作为基线凭证。

检查单复用:第 3 章需求评审检查单、第 4 章设计评审检查维度、第 5 章代码评审清单——评审体系 = 流程 + 检查单 + 记录纪律,三者缺一不可。

9.6 OOS 的质量与改进实践

• 质量内建:每迭代 DoD 含"单测覆盖 ≥80%、无 S1/S2 开放、关键流程 E2E 通过";
• 过程资产:标准过程库(需求模板、评审检查单、发布检查单),新项目裁剪使用;
• 度量看板:速度、逃逸率、变更失败率、MTTR 四指标月度回顾;
• 一次改进试点:发现"集成阶段缺陷占比 45%" → 试点"契约测试 + 接口评审" → 两季度后集成缺陷占比降至 28%,推广全团队;
• 审计:每年一次内部过程审计,对照标准过程库,输出差距与整改计划。

OOS 度量看板示例(月度):

9.7 质量工作的反模式

9.8 本章 FAQ

Q1:小团队设专职 QA 吗?
<10 人不必专职,但 QA 职责(度量看板、评审组织、改进跟踪)必须有人轮值承担。QA 是职责不是岗位。

Q2:不追求 CMMI 认证,这套东西还有用吗?
有。把 CMMI 当过程资产清单用:对照 2–3 级实践逐项自查"我有没有显式的过程资产",缺什么补什么,认证不做。

Q3:缺陷密度高一定差吗?
不一定。高缺陷密度可能是"测试很有效"(发现了该发现的)。要看:同密度下是否逐月下降、缺陷集中在哪个阶段(左移指标)、同类缺陷是否复发(回归能力)。

Q4:如何启动第一次过程审计?
范围限定(1 个项目、3 个过程:需求/评审/发布)→ 抽执行痕迹(记录/工件/访谈)→ 对照标准过程库列差距 → 输出 Top3 整改项(带 Owner 与期限)。避免"全面审计"——第一次审计全面 = 没有审计。

Q5:"过程"和"流程"有什么区别?
过程是完整定义(活动 + 角色 + 工件 + 验证 + 度量,第 2 章六问);流程常只是活动序列。"有流程没过程"的问题:无工件标准、无度量、无人对验证负责——出了偏差不知道断在哪一环。落地建议:把团队现存的每个"流程"用六问检查一遍,缺"产出什么"和"怎么度量"两问的,补上。

Q6:如何让管理层支持质量投入?
用钱说话:用质量成本四分类(附录 A)呈现——“上季度返工成本 = X 人日 ≈ Y 万元,其中 60% 可由 2 人日的契约评审预防”。质量投入不是成本,是失败成本的对冲。呈现方式:成本结构转移曲线,而不是"质量很重要"的口号——前者是决策,后者是态度。

Q7:"质量门禁"和"拖慢速度"如何区分?
门禁增加的是"过程时间",减少的是"返工时间"。判断式:门禁平均耗时 < (拦截缺陷率 × 缺陷逃逸后的修复成本)。若某门禁连续三个季度从未拦下任何缺陷,它应被移除或改造——从不拦截的门禁是纯税收,团队的绕行冲动是理性的,堵不如疏(改门禁)。

附录 A:质量成本(Cost of Quality)模型

读法:典型的"质量有问题"的组织,成本结构是"高鉴定 + 高失败 + 低预防"。改进的目标是移动成本结构——把鉴定/失败侧的投入挪到预防侧。OOS"契约测试前置"改进(附录 B)正是:鉴定成本(集成阶段修缺陷)↓,预防成本(契约评审)↑,总成本↓。

估算实践:项目启动时对四项分别估(预防/鉴定占总工时百分比,失败项按"预期缺陷数 × 单缺陷成本"),项目结束实际对比——偏差最大的项,就是明年改进的起点。

附录 B:OOS 改进项目完整走查(“契约测试前置”)

走查三要点:① 目标用占比而非"缺陷总数"(总数可被压缩范围操纵,占比更诚实);② 试点范围只有一个接口对,归因可控;③ 推广后设"控制限"接管——改进结束,控制开始,这是 PDCA 与六西格玛 DMAIC 的衔接处,也是"改进疲劳"(9.7 反模式)的解药:每个改进项的终态都是"被监控的常态",而不是"又一个新的运动"。

9.9 小结

• 质量三层:产品(测试)/过程(QA)/组织(改进),层级越高等杆越大;
• 测试找产品缺陷,QA 找过程缺陷,审计查合规;
• 质量是多维的(25010 七特性),质量内建于过程而非检出来;
• 过程改进靠 PDCA:基线 → 瓶颈 → 量化目标 → 试点 → 推广;
• CMMI 五级描述过程能力,有"可观察信号",价值在资产显式化而非认证;
• 度量三原则:为决策、看趋势、不考核;度量体系六步设计 + 季度清理;
• 评审 = 流程 + 检查单 + 记录纪律,发现率是有效性度量。

思考题

1. 一个团队"单测覆盖 90% 但线上缺陷很多",从 QA 视角应检查哪些过程环节?
2. 为什么"代码行数"和"个人 Bug 数"都不适合作为考核指标?各给出一个行为扭曲例子。
3. CMMI 3 级与 4 级的本质区别是什么?为什么"4 级"必须建立在 3 级之上?
4. 设计 OOS 的"集成缺陷占比"改进项目:基线、目标、试点范围、成功判据、退出标准。
5. 按 9.4 六步法为你的团队设计度量体系:列出 5 个决策与对应指标,指出最可能"通胀"的一个。
6. 做一次"缺陷-过程漏洞"回溯:抽 3 个近期缺陷,各回答"哪层内建机制本可拦住"。
7. 你的团队上一次评审的发现率是多少?如果为零,设计一个让它"非零且真实"的机制(不鼓励凑数)。
8. 解释 DMAIC 五阶段与 PDCA 的对应关系,并说明为什么"Control"阶段最容易被省略。