质量取决于需求与使用情境
偏离明确或隐含需求才构成缺陷；同一行为在不同产品、用户与场景中可能有不同判断。
SECTION 01
先定义，后谈质量
质量不是抽象的“好”，而是产品满足需求、用户目标与风险约束的程度。
核心定义
Defect = 行为不符合需求；Quality = 产品在特定情境下适合其目的。
因此，“缺陷”具有情境性：若产品明确只面向桌面端，移动端显示不佳未必违反当前需求；若目标用户需要移动使用，它就成为质量问题。
SQA
Quality Assurance
组织与流程导向。通过规范、计划、角色和预防性活动，改善开发过程并减少错误产生。
SQC
Quality Control
产品与结果导向。通过检查与验证，确认交付物在发布前满足既定质量要求。
TEST
Testing
执行层活动。发现技术问题，并评估功能、可用性、性能、安全性与兼容性。
关键辨析
测试 ≠ 质量保证。测试告诉团队哪里存在问题；质量保证关注如何让问题更少发生。高质量来自完整生命周期，而非最后一道测试关卡。
| 概念 | 判断问题 | 管理含义 | 示例 |
|---|---|---|---|
| Severity 严重度 | 问题造成的影响有多大？ | 反映技术 / 业务后果；Sev 1 常指系统不可用且没有变通方案。 | 付款流程完全崩溃。 |
| Priority 优先级 | 多快需要处理？ | 综合严重度、紧迫性、用户可见性与业务时机安排修复顺序。 | 上线活动前修复首页品牌拼写。 |
| Acceptable defects | 剩余风险是否可接受？ | 普通系统可按风险权衡；安全 / 任务 / 业务关键系统应把可接受缺陷趋近于零。 | 航空控制故障不可用“稍后修复”接受。 |
缺陷目标：从 Six Sigma 到 Zero Defects
课程字幕以 Six Sigma 的约 3.4 defects per million opportunities 说明低缺陷目标，并以 Crosby 的 Zero Defects 表达“不要把缺陷视为必然”的预防取向。它们是质量目标，不等于所有项目都使用同一验收阈值。
Whole-system view
故障可能来自人（用户、团队）、流程（规则、交接、决策）或技术（代码、设备、基础设施）。有效改进必须定位系统原因，而不是只补表面 bug。
Safety-critical
失败可能导致死亡、重伤、重大财产损失或环境伤害，例如航空、化工、核电系统。
Mission-critical
失败会显著中断组织核心运营，甚至威胁组织生存，例如高度依赖供电的生产系统。
Business-critical
失败会造成极高业务成本，例如银行核心服务不可用、交易中断或大规模客户流失。
SECTION 02
把“好”变成可衡量
单看缺陷数不够。完整度量应同时覆盖内部结构、外部行为，以及用户在真实情境中的结果。
内部质量
不运行软件也可观察的内部结构属性，例如架构弱点、复杂度、可维护性与静态分析发现。
外部质量
软件运行时呈现的行为，例如错误、响应时间、资源使用、恢复能力与兼容性。
使用质量
用户完成目标时获得的效果：有效性、生产力、安全与满意度。最终回答“是否适合目的”。
功能性适合性、准确性、互操作性、安全性、合规性
可靠性成熟度、容错性、可恢复性、合规性
易用性可理解、可学习、可操作、吸引力
效率时间行为、资源利用、效率合规
可维护性可分析、可修改、稳定、可测试
可移植性适应、安装、共存、可替换
Quality in use
ISO 9126 的使用质量模型关注四项结果：Effectiveness 有效性、Productivity 生产力、Safety 安全、Satisfaction 满意度。这提醒团队：内部代码“漂亮”并不自动等于用户成功。
| 质量维度 | 要回答的问题 | 材料中的可用指标 / 方法 |
|---|---|---|
| Defects | 偏离需求的问题有多少、影响多大？ | 缺陷数量；按严重度与优先级分类；生产环境缺陷数。 |
| Reliability | 系统能稳定运行多久？变更是否破坏原功能？ | 生产缺陷、负载测试、回归测试、宕机表现。 |
| Performance efficiency | 在给定时间与资源下是否保持响应？ | 压力测试、浸泡测试、应用性能监控（APM）。 |
| Security | 信息与系统能否抵御未授权访问和漏洞利用？ | 漏洞数量、补丁部署比例、漏洞解决时间。 |
| Maintainability | 软件修改、理解、交接与扩展是否容易？ | 代码行数、圈复杂度、ISO 5055 结构弱点。 |
| Delivery | 团队能否持续、安全地把价值交付给用户？ | 发布次数 / 交付频率；测试反馈速度。 |
指标原则
指标必须连接到需求、风险和决策。孤立的数字容易制造“看起来可控”的错觉；先问它会改变什么行动，再决定是否收集。
SECTION 03
三套标准，各管一层
把标准看成互补视角：产品质量模型、源代码结构测量、组织级信息安全管理。
ISO/IEC 9126
给软件产品质量建立共同语言，分为质量模型、外部度量、内部度量、使用质量度量四部分。
- 六项产品特征
- 四项使用质量特征
- 2011 年由 ISO/IEC 25010 取代
ISO/IEC 5055
通过静态分析测量软件内部结构，提前识别会伤害业务运营或推高 IT 成本的严重弱点。
- 可靠性、安全性
- 性能效率、可维护性
- 单位级 + 系统级、覆盖技术栈连接
ISO/IEC 27001
规定信息安全管理体系（ISMS）的实施、维护与持续改进要求，保护信息的 CIA 三要素。
- Confidentiality 机密性
- Integrity 完整性
- Availability 可用性
| 标准 | 主要对象 | 核心用途 | 典型产出 |
|---|---|---|---|
| 9126 / 25010 | 软件产品与使用结果 | 定义“质量有哪些维度”，帮助提出质量需求与评价模型。 | 质量属性、子属性、内部 / 外部 / 使用指标。 |
| 5055 | 源代码内部结构 | 在运行事故发生前，自动发现架构与组件级危险弱点。 | 弱点计数 / 密度、质量目标、发布或供应商验收门槛。 |
| 27001 | 组织的信息安全管理体系 | 基于风险建立政策、控制、审计和持续改进闭环。 | ISMS 范围、风险处理、控制措施、内审与管理评审。 |
ISO 5055：为何重要
传统运行指标多是事故后的结果；5055 像检查房屋内部结构，在开发与验收阶段发现 SQL 注入、资源未释放、绕过认证路径等结构性弱点。可写进 RFP、SOW、合同、发布条件与技术债治理目标。
ISO 27001：PDCA 思维
Plan：识别范围与风险；Do：实施政策、流程与控制；Check：监控、审计与管理评审；Act：纠正并持续改进。2022 版 Annex A 将控制重组为组织、人员、物理、技术四组，共 93 项。
SECTION 04
质量要贯穿生命周期
Shift-left 的本质不是把所有测试机械地前移，而是让反馈、质疑和风险判断更早出现。
澄清需求
识别用户、问题、使用环境、成功指标、负载、安全与更新需求。
验证设计
原型、多方案比较、设计评审和可用性测试，避免把错误问题实现得很精致。
内建质量
TDD、结对编程、可测试代码、静态分析与小步集成。
分层验证
单元、集成、端到端、探索性测试、正式技术评审与 UAT。
运行学习
监控真实表现、用户反馈、缺陷趋势与补丁，并持续偿还技术债。
E2E / UI少量 · 慢 · 贵 · 易受界面变化影响
Integration验证服务、数据库、文件系统之间的协作
Unit tests大量 · 快 · 便宜 · 高频反馈
Strategic testing pyramid
自动化投资要有层次
底层单元测试数量多、运行快；中层集成测试验证组件协作；顶层端到端测试覆盖关键用户旅程，但编写与维护成本最高。
不要选边站：自动化适合稳定、重复、高频任务；人工探索适合未知风险、可用性、边界行为与需要判断的场景。
TDD · Red → Green → Refactor
先写失败测试，再写最少实现使其通过，最后重构并保持测试通过。优点是快速反馈、可执行文档、更清晰代码与较低后期调试成本。
Formal Technical Review
通过正式评审、walkthrough 或 inspection 尽早发现功能、逻辑与标准偏差；记录评审对象、参与者、发现与决定。
User Acceptance Testing
让合适的领域专家和最终用户验证软件是否满足合同、法规、运营和真实使用需求；同时测试用户文档与培训。
CI / CD
频繁集成并在每次变更时自动执行测试；只有通过质量门槛的变更才进入可持续发布流程，缩短反馈周期。
Exploratory / Ad hoc
探索性测试边学边设计，有一定范围；ad hoc 更随机、偏向错误猜测。两者可发现脚本化测试没有覆盖的异常行为。
Effective bug report
一单一问题，提供清晰摘要、环境、复现步骤、实际与预期结果、证据；先确认可复现，必要时说明出现频率。
V-model 启示
越靠前的错误越昂贵：错误需求会扩散到设计、代码与测试。Agile 并不会消除这个规律；每次迭代都应重新验证问题陈述、用户故事和设计假设。
SECTION 05
低质量不是“小 bug”
它会沿着技术、运营、客户与法律链路放大，并通过技术债把今天的速度转化为明天的阻力。
这些数字来自材料引用的 CISQ / Synopsys 估算，用来显示数量级与风险结构；不同成本类别可能存在交叉，不能简单相加。
需求误解→
浅层 / 延迟测试→
生产缺陷→
宕机 / 泄露 / 数据丢失→
收入与声誉损失→
投诉、监管与诉讼
Reputation
糟糕体验会迅速转化为商店评分与社交媒体口碑；它不仅伤害当前产品，也给未来产品建立负面预期。
Revenue & technical debt
省略单元测试和回归测试可能换来短期速度，却增加副作用、维护成本与现代化失败风险。
Legal & social impact
可访问性、安全漏洞、隐私、数据丢失与宕机都可能引发处罚或诉讼；软件已深度影响现实世界。
供应链第一步：SBOM
建立软件物料清单，持续掌握第三方与开源组件。当新漏洞出现时，团队才能快速定位受影响系统、评估风险并及时修补。
DevQualOps
在 Agile、DevOps 与 DevSecOps 的高速交付中加入明确质量活动与质量门槛；结合自动分析、运行监控和持续技术债治理。
SECTION 06
把原则变成团队行为
最有效的质量管理不是购买更多工具，而是让人员、流程、技术与决策方式相互支持。
DO · 应该做
- 先写可测试需求与代码，适合时采用 TDD。
- 自动化回归、冒烟、负载和跨环境重复测试。
- 用云测试环境扩大浏览器、设备与操作系统覆盖。
- 在真正有价值的地方使用低代码工具，复用测试资产。
- 制定测试策略并遵循分层测试投资。
- 让开发、QA、用户与业务共同承担质量责任。
DON'T · 避免做
- 在没有工程反馈的情况下单方面改变范围与期限。
- 把 bug 归咎于个人，忽略需求、流程与系统复杂性。
- 只因工具“免费”或流行就采用，不考虑团队技能与维护成本。
- 把开发与 QA 隔离，等到最后才移交测试。
- 把自动化与人工测试当作二选一。
- 让测试数据散落在互不连通的工具中，失去整体视图。
计划文档层级
Test policy 定义组织原则；quality management plan 定义项目质量目标与责任；test strategy 定义产品级方法；test plan 说明测什么、何时、如何、由谁执行。
健康的 QA 环境
明确角色，尊重测试人员，提供业务培训，鼓励开发与 QA 直接沟通，并用 retrospective 持续改善协作。
测试管理工具的目的
连接需求、测试用例、环境、执行结果、缺陷与 KPI，提升可追踪性和团队可见性；工具必须服务于流程，而非替代思考。
SECTION 07
用于 IE / 团队项目
把 Week 06 转换成一份从现在就能执行的质量路线图。
定义“适合目的”
- 目标用户是谁？客户与用户需求是否冲突？
- 产品解决什么问题？成功指标是什么？
- 用户在何时、何地、用什么设备使用？
- 失败属于普通、业务关键还是更高等级？
在实现前发现错误
- 写清用户故事与可验证 acceptance criteria。
- 用原型和多个方案验证关键流程。
- 邀请真实用户做可用性测试。
- 明确负载、授权、数据库攻击与更新策略。
建立持续反馈
- 先建设单元测试，再补关键集成与 E2E。
- 在 CI 中运行自动回归与静态分析。
- 用结对编程 / 评审处理高风险变更。
- 记录依赖与组件版本，维护 SBOM。
以证据决定发布
- 按 severity × priority 整理缺陷。
- 让用户执行关键任务并提供 UAT 证据。
- 测试用户文档、培训与恢复流程。
- 将指标、剩余风险与发布建议同步给利益相关者。
团队责任
质量决策也是专业责任：需要向非技术利益相关者清楚解释风险、证据、取舍和剩余不确定性，不能只说“测试通过了”。
SECTION 08
三组速记 + 八题自测
先记结构，再补细节。点击问题展开参考答案。
SQA 管过程与预防；SQC 管产品与符合性；Testing 负责发现与评估问题。
功能、可靠、易用、效率、维护、移植。口诀：功靠易效维护移。
可靠性、安全性、性能效率、可维护性——聚焦源代码的业务关键结构因素。
1. 为什么同一个软件行为在一个项目中是缺陷，在另一个项目中可能不是？
缺陷以需求和使用情境为参照。若行为不违反目标用户、功能或环境要求，就未必构成该产品的缺陷；需求变化后判断也会变化。
2. Severity 与 Priority 的区别是什么？
Severity 描述问题造成的影响；Priority 描述处理的紧迫程度。高严重度通常高优先级，但商业时机、可见性、规避方案等会改变优先顺序。
3. 为什么“增加测试”不能单独保证质量？
测试主要暴露已有问题。错误需求、糟糕设计、流程断点和人员沟通问题若已进入产品，仅靠末端测试只能发现并付出高额返工成本。
4. ISO 9126、ISO 5055、ISO 27001 分别解决什么问题？
9126 提供软件产品质量模型；5055 自动测量源代码的关键结构弱点；27001 建立组织级信息安全管理体系与持续改进闭环。
5. Shift-left 的核心不是“把所有测试搬到最前面”，那它是什么？
它让需求评审、风险识别、测试设计、自动反馈和跨职能协作更早发生，以预防问题并缩短发现—修复周期；运行中的 shift-right 反馈仍然重要。
6. 测试金字塔为什么建议大量单元测试、少量 E2E？
单元测试快、稳定、便宜，适合高频反馈；E2E 覆盖真实旅程但运行慢、维护贵且更易 flaky，因此应聚焦少数关键流程。
7. 为什么安全是可靠性的一部分？
未授权访问、数据库攻击、供应链漏洞和补丁失效都可能导致系统不可用、数据破坏或错误行为。系统无法抵御这些威胁，就不能称为可靠。
8. 低质量软件的成本为何会持续累积？
生产故障、网络犯罪、缺陷修复、遗留系统和失败开发直接产生损失；未偿还的技术债又降低后续变更速度并增加回归风险，形成正反馈。
SECTION 09
Own-time 材料索引
课程视觉与字幕链接指向本地副本，文章链接指向原始网页，便于回到来源核对。
- Quality Measurement and Management visual课程视觉汇总图
- Measuring and Managing quality14:11 自动字幕；本页已按语境修正明显转录错误
- What Determines Software Quality?来源状态记录：目标网页已被无关内容替换
- The $2t cost of poor software quality经济成本、供应链、技术债与 DevQualOps
- What Happens When Testing Goes Wrong?声誉、意外、收入、反馈延迟与诉讼
- Improve Software Testing11 项测试与 QA 改进实践
- Software Quality Management Best Practices5 Do's & Don'ts
- Software Quality Standards — ISO 5055源代码结构质量的自动测量
- ISO/IEC 9126 in Software Engineering产品质量模型、指标与历史
- Purpose of ISO 27001ISMS、CIA、实施阶段与控制
材料边界：课程列出的 Code Quality Podcast 本地没有音频字幕或文字稿，因此本页没有虚构其内容；“What Determines Software Quality?” 的目标网页也已失效。页面仅总结可核对的本地材料，并未混入 real-time 案例。
