### 【2.14】软件质量特征（ISO 9126）（3 分钟）

> **口播**：前面我们讨论的是"质量是什么"，这一页把它落到国际标准上：软件的质量到底由哪几个可检查的侧面组成。请大家记住这个标准号——ISO 9126，它是影响最大、被引用最多的软件质量模型之一，后面很多标准都是从它发展出来的。它把软件质量归纳成六大特征，我逐个讲。
> 第一，功能性。课件上的定义是"与一组功能及其指定性质有关的一组属性"，功能就是满足明确或隐含需求的能力。说人话：该做的事，做没做到、做得对不对。第二，可靠性，"在规定的一段时间和条件下，软件维持其性能水平的能力"——请注意"一段时间"和"规定条件"这两个限定，程序跑一次不崩不叫可靠，长期稳定运行才算。
> 第三，易用性，"规定或潜在的用户为使用软件所需付出的努力和所作的评价"。它有两半：一半是客观的努力，学多久、点几下；一半是主观的评价，用起来舒不舒服。第四，效率，"在规定条件下软件的性能水平与所使用资源量之间关系"，说白了就是同样的活儿，干得快不快、吃得少不少。
> 第五，可维护性，"与进行指定的修改所需的努力有关的属性"，改一个需求要动多少代码，这就是可维护性。第六，可移植性，"软件从一个环境转移到另一个环境的能力"，换操作系统、换数据库还能不能跑起来。
> 最后一句课件上的话很重要：每一个质量特征都分别与若干子特征相对应。也就是说，这六项还太粗，不能直接拿来测量，必须继续往下拆。拆下去长什么样？就是下一页那张三层模型。
> 这里我再提醒一句：这六大特征不是并列的口号，而是有优先级的。面对不同产品，团队必须根据用户场景给它们排序，否则所谓"质量"就成了没有重点的一团。

**板书**：写"ISO 9126 六大质量特征"，一边讲一边竖着写：**功能（做没做到）→ 可靠（稳不稳）→ 易用（好不好用）→ 效率（快不快·省不省）→ 可维护（好不好改）→ 可移植（好不好搬）**；下面补一句："**每一个特征往下还有若干子特征**"。

**提问**：如果让你给"学生选课系统"评质量，这六个特征里你会先盯住哪两个？为什么是这两个？

**预设回答**：
- 答"可靠性和效率"：✅ 很到位。点评并追问："选课系统为什么 reliability 重要？"引导到业务本质——**抢课高峰期系统崩了，学生和教务全部受影响，这是关键业务时间窗（如开学第一周）最不能出的问题**，所以可靠性优先级最高；紧接着就是效率，因为并发量决定选课能不能在几分钟内结束。
- 答"易用性，因为界面要好看"：⚠️ 只说到了外观。点评：易用性在标准里指的是"用户为使用软件所需付出的努力和评价"，**重点是任务完成成本（几步能选上课、会不会选错）**，不只是好看；界面美观只是其中一小部分。
- 答"六个都很重要，全部同等对待"：❌ 典型但错误的答案。点评：资源永远有限，**质量特征必须有优先级，依据是产品定位和用户场景**；教务内部系统的可移植性权重就很低，而面向公众的 App 则完全不同。

**易错点 / 考点**：①中英文对应必须记牢——功能性 functionality、可靠性 reliability、易用性 usability、效率 efficiency、可维护性 maintainability、可移植性 portability；②最常见的混淆是把"效率"和"性能"划等号，标准里效率＝性能水平与资源消耗的关系，**是"性价比"不是单纯的快**；③把"易用性"等同于"界面美观"；④考点形式：给一段场景描述让你判断属于六大特征中的哪一个（选择题），或者让你补全"特性—子特性"的对应关系。**判断三步法**：先问"这个属性管什么"→ 再对照六大特征的定语（功能实现/稳定运行/用户努力/资源效率/修改成本/环境迁移）→ 最后排除"性能就是效率"这个陷阱。

**过渡**：六大特征还要往下拆，ISO 9126 把它拆成了三层——我们看下一页这张结构图。

---

### 【2.15】ISO 9126 软件质量三层模型（2 分钟）

> **口播**：这一页是一张图，请大家把目光放到图上，它要你看出的就是一件事：软件质量不是一句话，而是一棵三层树。第一层在最上面，是总目标——软件质量本身；第二层是刚才讲的六大质量特性：功能性、可靠性、易用性、效率、可维护性、可移植性；第三层在每根枝条的末端，是质量子特性，以及再往下的度量指标。
> 为什么非要分三层？因为"质量好"这句话没法验证，"可靠性好"同样没法验证，必须一路拆到能测量的东西上。比如可靠性往下拆，可以拆出成熟性、容错性、易恢复性；成熟性还可以用平均无故障时间来度量，容错性可以用"注入故障后系统能否继续工作"来度量。再比如易用性往下拆，是易理解性、易学性、易操作性，可以用"新用户完成第一个任务要多久"来度量。这样一拆，质量就从一句形容词变成了可以打分、可以验收的东西。
> 这张图还有一个用途：它是后面所有质量模型的"母版"。无论是 Boehm 模型，还是 ISO 25000 系列，走的路子都是"总目标—特性—子特性—度量"这条主线，区别只在特性的划法和层数。
> 再补一句它和测试的直接关系：三层模型不是学术分类，它决定了测试设计的方法——你选定哪一个度量指标，就等于宣布了要设计哪一类测试项。

**板书**：画三层：**第一层 软件质量（总目标）／第二层 六大特性／第三层 子特性＋度量指标**；旁边写口诀"**一层看目标、二层看特性、三层看度量**"，再举一例：**可靠性 → 容错性 → 故障注入后能否继续服务**。

**提问**：为什么"软件质量好"这句话在验收会上没人能反驳，也没人能签字？这张图怎么解决这个问题？

**预设回答**：
- 答"因为太笼统，没有标准"：✅ 抓住要害。点评：所以三层模型的第二层把"好"拆成六个可讨论的维度，第三层再拆成可测量的指标，**质量评价从口水战变成数据对话**。
- 答"那就直接测第三层的指标，不用管前两层"：⚠️ 只见树木。点评：度量指标是手段，第二层的特性是目的；**只盯指标会出现"指标好看、产品难用"的情况**，例如启动时间达标但核心任务路径极长。
- 答"这张图是给开发看的，跟测试没关系"：❌ 需要纠正。点评：恰恰相反，**测试用例的设计就是从第三层的度量指标倒推出来的**——你打算怎么度量，就决定了要设计哪些用例。

**易错点 / 考点**：①三层的顺序不能颠倒（总目标→特性→子特性/度量）；②"特性"与"子特性"的层级容易混，记住**子特性是能落到测量上的那一层**；③考点形式：给出一个子特性让你归类到六大特性之下（如"易恢复性"归可靠性、"易学性"归易用性、"资源特性"归效率）；④记忆口诀：**一句形容词拆不成用例，拆到第三层才叫质量**。

**过渡**：ISO 9126 的三层结构讲完了，但质量模型不止这一个。在它之前还有一位前辈，提出了软件质量模型史上第一个层次化结构——我们看 Boehm 模型。

---

### 【2.16】Boehm 软件质量模型（3 分钟）

> **口播**：这一页是 Boehm 软件质量模型。Boehm 是软件工程领域的大家，他在 20 世纪 70 年代末提出这个模型，是软件质量模型里较早、也很有影响力的一套层次化结构。课件这一页是一张关键词地图，信息密度很大，我带大家按三条线索来读。
> 第一条线索是"产品操作"，也就是软件在运行时表现出来的质量。上面有正确性、可靠性、效率、完整性、可用性，还有容错性、执行效率、储存效率、存取控制、存取检查这些更细的条目。可以看出，这条线索回答的是"软件跑起来对不对、稳不稳、快不快、数据安不安全"。
> 第二条线索是"产品修改"，也就是将来要改它的时候，成本高不高。对应的关键词有可维护性、可测试性、灵活性、扩展性、模块性、一般性、简单性、连贯性。请注意 Boehm 模型的一个历史贡献：它把可测试性和可理解性这类"开发友好"的属性也纳入了质量，而不只盯着运行结果。
> 第三条线索是"产品维护"和迁移，也就是软件换环境、被别的系统接着用的时候行不行。关键词有可移植性、互用性、机器独立性、软件系统独立性、通讯公开性、数据公开性、重复性、阐述性。
> 另外还有一组偏人的属性：可训练、沟通良好、易操作的、自我操作性、工具——这就是人和软件打交道时的质量。大家抓一个总印象就够了：Boehm 模型第一次把质量从"代码对不对"扩展到了"好不好改、好不好测、好不好搬、好不好学"，这就是它比单纯的正确性检查高明的地方。
> 还有一个细节值得注意：这份模型里出现了"工具""可训练""沟通良好"这样的条目，说明早在几十年前，软件质量就已经被理解为"技术加人"的合力，而不只是纯粹的技术问题。

**板书**：黑板上横着画三条线：**产品操作（正确性·可靠性·效率·完整性·可用性）／产品修改（可维护性·可测试性·灵活性·扩展性·模块性）／产品维护与迁移（可移植性·互用性·机器独立性·软件系统独立性·通讯公开性）**；右侧补一列"**人机属性：可训练·沟通良好·易操作**"。

**提问**：Boehm 模型把"可测试性"写成一项质量属性。请问：一个软件"可测试性差"是什么意思？它会给项目带来什么实际后果？

**预设回答**：
- 答"就是很难测"：✅ 方向对，但要说透。点评：可测试性差的典型表现是——**模块之间耦合死、没有接口、没人能造出输入去观察输出**；后果是测试成本飙升、缺陷漏到生产环境，你在课程设计里也会遇到：写得越死，用例越难设计。
- 答"可测试性是测试人员的事，跟开发质量无关"：❌ 常见误解。点评：可测试性恰恰是**设计质量的体现**，它由架构和接口设计决定，测试人员只能被动承受。所以业界有句话：**测不动的东西，往往就是设计得不好的东西**。
- 答"把它当作一项功能需求写进规格书就行"：⚠️ 想法不错但落不了地。点评：可测试性不是一条功能，而是一组设计要求（接口可注入、状态可观察、依赖可替换），需要落实在**设计评审的检查项**里。

**易错点 / 考点**：①别把 Boehm 模型和 ISO 9126 记混——**Boehm 是层次化质量模型的早期代表，ISO 9126 是国际标准的六特性结构**；②Boehm 模型的特色在于同时覆盖"运行表现"和"修改/迁移成本"，并纳入可测试性、可理解性；③考点形式：判断"可测试性属于哪一类质量属性"（产品修改类）、或比较两个模型的异同（简答题）；④记忆口诀：**跑得好（操作）、改得动（修改）、搬得走（维护迁移）、学得会（人机）**。

**过渡**：Boehm 模型是"前辈"，ISO 9126 是"经典"，那么今天企业真正在用的是哪一套标准？我们看最新的一代——ISO 25000 系列。

---

### 【2.17】最新质量标准：ISO 25000 系列（3 分钟）

> **口播**：这一页叫"最新质量标准：ISO 25000 系列"，它的正式名字是 ISO/IEC 25000《软件产品质量要求和评定》，英文缩写 SQuaRE，全称 Software product Quality Requirements and Evaluation。请大家记住这几个字母，它是现在国际上评价软件质量的主干标准。
> 为什么要出这个新标准？因为老的 ISO 9126 只管"质量模型"，老的标准 ISO 14598 只管"质量评价"，两套标准各说各话；SQuaRE 把它们整合成一条链，从"定要求"一直走到"做评价"。SQuaRE 分成几个分部：2500n 是质量管理，2501n 是质量模型，2502n 是质量测量，2503n 是质量要求，2504n 是质量评价，后面还有 25050 到 25099 的扩展部分。大家不用背全编号，但要抓住它的逻辑顺序：**先定模型（测什么维度）→ 再定测量（怎么量）→ 再定要求（量到什么程度算合格）→ 最后做评价（按证据下结论）**。
> 在我们国家，这套标准被等同采用为 GB/T 25000 系列，下一页要讲的产品质量模型，对应的就是 GB/T 25000.10-2016。课件这一页给出的链接是 ISO 官方的在线浏览平台，感兴趣的同学可以课后去查标准原文，考试不会考那么细，但将来做测试方案时，引用标准号是很加分的。
> 为什么加分？因为笼统地说"我们按照行业标准做测试"，对方没法追问；而说出"我们的质量要求和评价依据 GB/T 25000 系列"，对方马上可以追问到具体分部，这就是专业与业余的差别。
> 一句话总结这一页：质量模型从"一家之言"变成了"国际通用语言"，好处是——当你说"这个系统可靠性不达标"时，所有人对"可靠性"的理解是一致的。

**板书**：写 **ISO/IEC 25000 SQuaRE**，下面竖排：**2500n 质量管理 → 2501n 质量模型 → 2502n 质量测量 → 2503n 质量要求 → 2504n 质量评价**；右侧写对应关系："**国内等同采用：GB/T 25000 系列（产品质量模型＝GB/T 25000.10-2016）**"；再写一句逻辑链："**定模型 → 定测量 → 定要求 → 做评价**"。

**提问**：如果换作你给一个课程设计项目写测试方案，为什么"先引用一个质量标准"比"直接开始设计用例"更稳妥？

**预设回答**：
- 答"因为有依据，别人不好反驳"：✅ 说到了要点。点评：标准提供的是**共同语义和可追溯的评价口径**——你说"性能不达标"，标准会追问"你测的是时间特性还是资源特性、在什么条件下、阈值多少"。
- 答"引用标准就是走形式，最后还是要自己测"：⚠️ 一半对。点评：标准不替你测，但它替你**定义验收的语言**；没有这层语言，需求方说"要流畅"，开发说"够快了"，测试夹在中间无法裁决。
- 答"越新的标准越好，老标准可以完全丢掉"：❌ 需要纠正。点评：**ISO 9126 的六特性思维今天仍然在用**，SQuaRE 是在它基础上升级整合；学习路径应该是"先懂 9126 的骨架，再看 25000 的整合"，而不是简单地新替旧。

**易错点 / 考点**：①标准号与名称对应：**ISO/IEC 25000＝SQuaRE＝软件产品质量要求和评定**；**GB/T 25000.10-2016 是我国等同采用的产品质量模型**；②别把 25000 与 9126 的关系说反——**9126 是前身，25000 是整合与升级**；③考点形式：给出标准编号让你说分部职责（如 2501n 管模型、2504n 管评价），或判断"ISO 25000 系列只包含质量模型"（错，它是一条从要求到评价的完整链）；④记忆口诀：**先模型、再测量、后要求、终评价**。

**过渡**：这页讲的是标准的"编号体系"，接下来的问题更本质：一个软件的质量，其实分层存在——内部质量、外部质量、使用质量。它们是层层影响的关系，我们看下一页那张链条图。

---

### 【2.18】内部质量→外部质量→使用质量（2 分钟）

> **口播**：这一页是一张关系图，讲的是质量的三层存在形态。请大家看图上从左到右的走向：内部质量、外部质量、使用质量，三者的箭头是"影响"——内部质量影响外部质量，外部质量影响使用质量；反过来看，箭头是"依赖于"——使用质量依赖于外部质量，外部质量依赖于内部质量。同时右边还有一个"使用语境"作用于使用质量。
> 怎么理解这三层？内部质量是"看不见的质量"，指的是代码、文档这些中间产品本身的属性，靠内部度量来看；外部质量是"看得见的质量"，指的是软件运行起来之后表现出来的行为，靠外部度量来看；使用质量是"用得着的质量"，指的是用户在他的真实使用语境下能不能顺利完成任务，靠在使用中度量。
> 举个我们身边的例子：一个登录模块，代码里密码是明文比较、没有失败次数限制，这是内部质量问题；用户实际登录时能被暴力破解、后台报错，这是外部质量问题的表现；而在真实业务里，用户因此被盗号、被投诉，这就是使用质量被破坏的结果。
> 所以这三层不是三种无关的质量，而是同一件事的三个观察距离：**离代码越近越早能发现，离用户越近越能说明危害**。测试的价值就在于把远处的危害，用近处的、早期可测的指标提前识别出来。
> 还要说清一点：这三层不是三张彼此独立的检查表，而是一条证据链——内部指标异常可以预测外部行为的风险，外部行为异常可以预测用户使用效果的损失。测试报告里如果能把这条链串起来，说服力会强得多。

**板书**：画一条横向链：**内部质量 —影响→ 外部质量 —影响→ 使用质量**；在下方画反向箭头，标注"**依赖于**"；右侧写"**使用语境 → 影响 → 使用质量**"；再补三层度量名：**内部度量｜外部度量｜在使用中度量**，旁注一句"**越靠内部越早可测，越靠使用越能说明危害**"。

**提问**：如果测试资源只够盯一层，你应该盯哪一层？请说出理由。

**预设回答**：
- 答"盯使用质量，因为用户只在乎这个"：⚠️ 重要但不可行。点评：使用质量最贴近价值，但它**只能在真实语境里长时间观察**，早期的课程设计项目根本没有真实用户；所以实践中要靠外部度量做替身。
- 答"盯内部质量，代码写好了自然没问题"：❌ 典型的"技术自负"。点评：内部干净不等于用户能用，**代码质量只是必要条件**；而且内部指标容易自己糊弄自己（注释率高不代表注释有用）。
- 答"三层都要有指标，但可以用内部和外部指标提前预测使用质量"：✅ 这是最专业的回答。点评：这正是模型画的"影响/依赖于"关系要表达的——**三层是层次递进、可传递的证据链**，早期用内部、中期用外部、上线后用实际使用度量。

**易错点 / 考点**：①箭头方向常考：**内部影响外部、外部影响使用；使用依赖外部、外部依赖内部**，别把"影响"和"依赖"方向写反；②"使用语境"这个要素只有使用质量这一层才有；③考点形式：判断题"内部质量好则使用质量一定好"（错，是影响不是等同）；④记忆口诀：**内影响外、外影响用；用依赖外、外依赖内；语境只在最外层**。

**过渡**：三层里最靠内、也最早能测的那一层就是内部度量，它到底量什么、有什么好处？我们看下一页。

---

### 【2.19】内部度量（2 分钟）

> **口播**：这一页讲内部度量。课件上给了两张图，主题是内部度量的对象和它的价值，备注里有一句英文提示——Economic risk mitigation，也就是"缓解经济风险"，另外还点出 ISO/IEC 9126-1:2001 把软件质量模型分成内部质量与外部质量模型、使用质量模型。
> 内部度量量的是什么呢？量的是**中间产品自身的可测量属性**：代码和设计文档的规模、结构复杂度、模块之间的耦合程度、注释情况、需求到代码的可追溯性等等。这些东西有一个共同特点——**不需要把系统完整跑起来就能测**，静态评审、静态分析工具就能给出数据。
> 它的价值就在那句"缓解经济风险"上。软件工程里有个普遍规律：缺陷发现得越晚，修复代价越高，因为越晚就意味着越多的设计、代码和测试已经建立在错误的基础之上。内部度量让团队在编码阶段、甚至在评审阶段就拿到质量数据，从而把修复成本压在最便宜的那个时间点上。
> 但请注意内部度量的局限：它测的是"中间产品的属性"，不是"用户能感知的效果"。圈复杂度低不代表用户能顺利下单，注释率高也不代表注释说得对。所以内部度量只能告诉你"哪里可能有问题"，不能替你做"能不能交付"的最终判断。
> 再给一个实操建议：内部度量最好成组使用。只看复杂度容易被误导，但把"复杂度偏高＋被频繁修改＋评审中问题集中"三个信号叠加起来，高风险模块基本就锁定了，测试和评审资源就该优先压到这些模块上，这就是最朴素的数据驱动测试。

**板书**：写"**内部度量＝量中间产品本身**"，下面列：**规模 · 复杂度 · 耦合度 · 可追溯性 · 注释/规范符合度**；再写两个关键词："**不需要运行程序**"＋"**Economic risk mitigation（缓解经济风险）**"；旁边画一条代价曲线并标注"**越晚发现，修复越贵**"。

**提问**：既然内部度量不能证明用户满意，为什么还要花人力去做静态分析和代码评审？

**预设回答**：
- 答"为了提前发现问题，省钱"：✅ 对了，就是"缓解经济风险"。点评：追问一句"省在哪里"——**省在还没有把错误放大器做大的时候修复**，一个需求理解偏差在需求阶段改是写几行字，在上线后改可能是全量回归。
- 答"因为标准要求做，属于流程合规"：⚠️ 只答了形式。点评：合规只是手段，真正目的是**让不可见的东西变得可见**；代码质量数据是团队判断"能不能进入下一阶段"的门禁依据。
- 答"内部度量好，那就以圈复杂度为唯一指标考核开发"：❌ 非常危险的做法。点评：单一指标一定被"优化"（程序员把函数拆碎，复杂度好看但可读性更差），**内部度量要成组看、结合评审判断**，不能拿来当 KPI 硬压。

**易错点 / 考点**：①内部度量**不需要运行程序**，这是它与外部度量最本质的区别；②不要把内部度量与静态测试混为一谈：**内部度量是"量数据"，静态测试是"找缺陷"**，两者常同时进行但目的不同；③考点形式：判断某项活动属于内部度量还是外部度量（如"统计圈复杂度"属内部，"测量登录响应时间"属外部）；④口诀：**内部量自己（代码文档）、外部量行为、使用量效果**。

**过渡**：内部、外部、使用这三级到 ISO 25010 里被重新组织成了两个模型：一个管产品本身，一个管用户使用。先看产品质量模型。

---

### 【2.20】产品质量模型（3 分钟）

> **口播**：这一页是产品质量模型。课件给了两个关键信息：一个是 ISO 官方的标准在线浏览地址（iso.org 的 OBP 平台，标准号是 ISO/IEC 25010 第 1 版），另一个是**GB/T 25000.10-2016 质量模型**——也就是说，我们国家等同采用的标准就是它，考试和写测试方案时引用这个国标号最稳。
> 产品质量模型要回答的问题是：**软件这个"产品"本身，应该从哪几个维度评价？** 在 GB/T 25000.10 里，产品质量特性有八个：功能适合性、性能效率、兼容性、易用性、可靠性、安全性、可维护性、可移植性。
> 我们来对比一下它和 ISO 9126 的六大特征：可靠性、易用性、可维护性、可移植性这四项保留了下来；功能性细化为"功能适合性"，强调的是"功能是否满足规定和隐含需求"，而不只是"有没有这个功能"；效率改称"性能效率"，把时间行为和资源利用都纳进来；新增了两项——**兼容性**（与其他产品共享环境、交换信息的能力，比如能不能和现有系统对接、能不能和别的软件共存）和**安全性**（信息保密性、完整性、抗抵赖、可核查、真实性）。
> 为什么要新增这两项？看看今天的软件形态就明白了：系统都是联网的、都要集成、都存着用户数据。**在 9126 的年代，安全性和兼容性是"附加项"；在今天，它们是"入场券"**——一个不能对接的单机系统，在业务上几乎没有价值；一个泄露用户数据的系统，功能再全也是负分。
> 还有一层：产品质量模型里的这些特性都是"产品属性"，必须靠需求、设计、编码、测试共同实现，不能指望某个阶段事后补出来。所以需求评审时就该问：这个需求的兼容性要求是什么、安全要求是什么，而不是等系统做完再补一轮安全测试。

**板书**：写"**产品质量模型（GB/T 25000.10-2016 / ISO/IEC 25010）**"，下面竖排八个：**功能适合性 · 性能效率 · 兼容性 · 易用性 · 可靠性 · 安全性 · 可维护性 · 可移植性**；右侧写"**相比 ISO 9126：保留 4 项，功能性→功能适合性，效率→性能效率，新增 兼容性＋安全性**"。

**提问**：为什么标准要把"安全性"从功能性下面的一个子特性，提升为一个独立的质量特性？

**预设回答**：
- 答"因为安全问题越来越严重"：✅ 方向对。点评：更准确地说，是**安全已经不只是"某个功能的属性"，而是贯穿全部功能的横切要求**——登录、支付、上传、日志都涉及，放在功能性子项里会被漏掉。
- 答"提升层级只是标准改版的形式调整，没有实质意义"：⚠️ 低估了标准演进。点评：标准属性的"层级位置"决定了**评审和测试的关注度**；一个条目从子特性升到特性，意味着它必须有独立的测试类型、独立的验收门槛。
- 答"安全是运维和安全团队的事，测试不用管"：❌ 必须纠正。点评：安全性作为产品质量特性，**在测试范围内**，常见的有认证授权、输入校验、敏感信息保护等测试项；出了问题，测试同样是责任方之一。

**易错点 / 考点**：①标准号对应要准：**产品质量模型＝ISO/IEC 25010（GB/T 25000.10-2016）**；②八个特性最容易漏掉"兼容性"和"安全性"；③不要把"性能效率"写成"性能"或"效率"就草草带过，标准含义是**时间行为＋资源利用**；④考点形式：给出场景判断属于哪个特性（"换数据库后系统仍能运行"→可移植性；"与第三方支付接口正常交互"→兼容性；"越权访问被拦截"→安全性）；⑤记忆口诀：**功能性能、兼容易用、可靠安全、可维护可移植**。

**过渡**：产品质量模型管的是"产品本身好不好"，可用户其实不关心产品，只关心"我用得顺不顺"。这就轮到另一个模型——使用质量模型。

---

### 【2.21】使用质量模型（2 分钟）

> **口播**：这一页是使用质量模型。它和上一页的产品质量模型是一对：产品质量模型站在**产品**角度问"这个软件本身有哪些质量维度"，使用质量模型站在**用户**角度问"用户在实际使用语境里，能不能达成他的目标"。课件这一页也是以图为主，备注同样提示了 Economic risk mitigation 和 ISO/IEC 9126-1:2001 的两分法。
> 使用质量的特性，按现行的 GB/T 25000.10／ISO 25010，一般列五个：有效性、效率、满意度、免于风险、语境覆盖。有效性是说用户能不能准确、完整地达成目标；效率是说达成目标要花多少时间、多少成本；满意度是用户的主观感受，包括有用性、可信度、愉悦感、舒适度；免于风险是说软件有没有给用户的经济、健康、数据安全带来风险；语境覆盖是说它能不能在用户真实的使用场景下（不同设备、不同环境、不同任务）都成立。
> 我提醒大家注意一点：在早期的 ISO 9126 里，使用质量是四项——有效性、生产率、安全性、满意度；到了 25010 时代扩展成上面这五项，把"风险"和"语境覆盖"单独提出来。这背后的变化很有味道：**标准开始承认——同一个软件在不同的使用语境下，使用质量可以是完全不同的**。手机上流畅，不代表在弱网的山村里可用；办公室里好用，不代表戴着手套的车间工人能用。
> 再把它和验收测试挂上钩：验收测试的判定准则，本质上就是使用质量的指标化——任务完成率、平均完成时间、严重问题数、无障碍可用程度等等。如果一份验收方案里只有"功能是否符合需求"这一条，那它评的是产品，不是使用。

**板书**：写"**使用质量模型（用户视角）**"，横排五个：**有效性 · 效率 · 满意度 · 免于风险 · 语境覆盖**；下面写对比："**ISO 9126 时代四项：有效性·生产率·安全性·满意度 → 25010 扩展为五项**"；右侧写一句"**同一软件，不同语境，使用质量不同**"。

**提问**：请举一个"产品质量不错、但使用质量很差"的例子，并说明差在哪一项上。

**预设回答**：
- 答"功能齐全但老年人不会用，满意度低"：✅ 很好的例子。点评：这属于**易用性与满意度**问题，它提醒我们——产品的功能适合性达标，不代表使用质量达标，**用户的达成成本和感受是独立维度**。
- 答"产品质量和使用质量是一回事，只是叫法不同"：❌ 概念混淆。点评：两者观察对象不同——**前者看产品属性，后者看使用结果**；一个产品可以特性全达标却在真实语境里失败（比如强光下屏幕看不清）。
- 答"只要用户投诉多就是使用质量差"：⚠️ 不完整。点评：投诉只是满意度的信号，使用质量还要看**有效性（任务是否真的完成）和免于风险（有没有造成损失）**；很多失败的用户根本不投诉，直接流失。

**易错点 / 考点**：①两套模型不要张冠李戴：**产品质量模型 8 特性，使用质量模型 5 特性**；②"语境覆盖"只出现在使用质量模型里，是 25010 的新增项；③考点形式：给出用户场景判断属于使用质量的哪一项（"新用户 3 分钟完成注册"→有效性/效率；"系统不会误导用户造成资金损失"→免于风险）；④口诀：**有效、高效、满意、无风险、语境覆盖**。

**过渡**：光讲模型还是抽象的，下一页课件给了一个具体例子——把它套到 Web Portal 上看，使用质量到底怎么评。

---

### 【2.22】示例：Web Portal 的使用质量（2 分钟）

> **口播**：这一页是示例，课件用一个 Web Portal（门户网站）来说明"使用质量"怎么落地。所谓门户，通常是企业的信息入口：登录、导航、公告、单点登录到各个业务系统。我们就把刚才那五项使用质量特性，一项一项套到这个门户上。
> 第一项有效性：用户能不能真的完成他要做的事——登录成功、找到要办的事项、点进正确的业务系统，而不是在导航里迷路。第二项效率：完成这些事要花多少时间和步骤，比如从首页到目标系统要不要点五次、加载要不要等十秒。第三项满意度：用户对界面的信任感和舒适度，包括信息是不是准确、样式是不是一致、提示是不是清楚。第四项免于风险：门户里往往挂着单点登录和员工信息，一旦被冒用或者跳转到钓鱼页面，损失是直接的，所以风险要单独评。第五项语境覆盖：员工在电脑上用、在手机审批时用、在弱网的外勤现场用，效果可能完全不同。
> 大家可以发现，这里用的方法很朴素：**把抽象的质量特性，翻译成具体用户能感知的问题**。这正是使用质量评价的核心动作——不是问"这个系统质量好不好"，而是问"哪一类用户，在什么语境下，完成哪一件事，会失败"。
> 再补一层：门户的使用质量评价通常不是一次性结论，而要分语境、分角色来看。同一套指标，对天天使用的老员工和偶尔登录的新员工，答案可能完全相反；对电脑端和对手机端，也可能一个通过、一个不通过。所以报告要按语境分组给结论，而不是给一个全局平均分——平均值最擅长掩盖问题。

**板书**：写"**示例：Web Portal 的使用质量**"，左侧列五特性，右侧并列写出问句：**有效性→能否完成登录/办事；效率→要几步·等多久；满意度→是否信任舒适；免于风险→账号与信息是否安全；语境覆盖→PC/手机/弱网是否都可办**；下方写一句总结："**把特性翻译成用户能感知的问题**"。

**提问**：如果只能选三项指标来评价这个门户的使用质量，你选哪三项？为什么？

**预设回答**：
- 答"有效性、效率、免于风险"：✅ 很务实。点评：这三项**能直接量化、且直接对应业务损失**——办事失败、耗时过长、账号被冒用，都是能被统计和追责的。
- 答"满意度最重要，发个问卷就行了"：⚠️ 只靠主观数据不够。点评：问卷受样本和情绪影响大，**要与客观指标互相印证**；满意度高但任务完成率低，往往说明用户根本没意识到自己用错了。
- 答"门户是内部系统，风险可以不用评"：❌ 危险的判断。点评：门户通常是**单点登录的入口，是攻击价值最高的一环**；它一旦失守，后面所有业务系统一起暴露。

**易错点 / 考点**：①示例类题目的答题结构：**先定用户与语境 → 再按特性逐项分解 → 最后给可测指标**；②最常见的错误是只说界面感受，不给可测口径；③考点形式：给一个系统（如选课系统、外卖 App）让你按使用质量五特性列评价角度；④口诀：**先问谁在用、在哪用，再问能不能办成、要多久、信不信、险不险**。

**过渡**：从这一页开始，我们的关注点从"什么是好质量"转到反面：质量出了问题，就是缺陷。先给缺陷下一个正式定义。

---

### 【2.23】2.1.2 软件缺陷的定义（3 分钟）

> **口播**：我们进入 2.1.2，软件缺陷的定义。课件上给的核心表述是：**任何程序、系统中的问题，比如与产品设计书的不一致性、不能满足用户的需求，都属于软件缺陷。**这句话虽然短，但包含了两个很关键的判断来源，我拆开讲。
> 第一个来源是"与产品设计书的不一致性"。也就是说，规格说明、设计文档是基准，程序的行为跟基准不符，就是缺陷。比如需求书写着"密码长度不少于 8 位"，程序却允许 6 位，这就是不一致，不需要讨论。
> 第二个来源是"不能满足用户的需求"。请注意这一句的分量——它意味着**即使程序完全符合设计书，只要用户的需求没有被满足，仍然算缺陷**。为什么？因为设计书本身可能写错了、写漏了。用户说"我要能导出 Excel"，需求文档里没写，程序自然也没有这个功能，从"一致性"角度它没错，从"满足需求"角度它就是缺陷。
> 这两个来源正好构成了我们后面反复用的两条判定思路：**对照规格（正向思维：该做的做了没有）**和**对照用户期望（反向思维：还有什么情况让他失望）**。课件这一页还配了图，表达的也是同样的意思——缺陷的判定不能只看代码对错，还要看它是否偏离了设计和用户的期望。
> 所以大家记住一个判断口径：**缺陷不是"程序里有错误"这么窄，而是"任何让产品与设计或用户期望产生偏离的问题"**，它可能藏在代码里，也可能藏在需求、设计、文档甚至配置里。
> 还有一个实务提醒：判定缺陷时一定要写清"期望"和"实际"。只说一句"这样不对"，开发会反问"那应该怎样"；把规格条款或用户场景引出来，问题才是可讨论、可裁决的。这也是缺陷报告里最容易被新手省略、又最不能省略的一栏。

**板书**：写"**2.1.2 软件缺陷的定义**"；下面两条并列：**① 与产品设计书不一致（对照规格）／② 不能满足用户需求（对照期望）**；右侧补一句："**判定缺陷的两把尺子：规格 ＋ 用户期望**"；再写"**缺陷可以藏在需求、设计、代码、文档、配置里**"。

**提问**：需求文档漏写了一个功能，程序按文档做完了，测试该不该把它记为缺陷？请说明理由。

**预设回答**：
- 答"该记，因为用户需求没被满足"：✅ 符合课件口径。点评：但要点出处理方式——**这类问题的根因在需求，不在代码**，报告时要写清"需求遗漏"，让责任流向正确的位置，而不是直接指责开发。
- 答"不该记，程序符合规格说明就是对的"：❌ 很常见，但只对了一半。点评：符合规格是"通过下限"，不是"质量上限"；**用户期望才是最终验收标准**，漏需求造成的问题最终仍会以用户投诉的形式回到团队。
- 答"记也可以，但要等需求方确认再说"：⚠️ 流程上没错，时机上要小心。点评：**先把发现记录下来，再走确认流程**，不要因为"口径未定"就不记录；很多缺陷就是这样在讨论中消失的。

**易错点 / 考点**：①缺陷定义的两个来源要能同时说出来，只答"程序错误"是不完整的；②"与设计书不一致"和"不满足用户需求"可能同时成立、也可能只成立一条，考试常给场景让你判断属于哪一种；③考点形式：判断"符合规格说明但用户不满意"是否算缺陷（算）；④记忆口诀：**两把尺子量缺陷——一把量规格，一把量期望**。

**过渡**：定义讲完了，我们来看一个有意思的历史现场：软件缺陷这个词，最早是怎么来的？请看"First Bug"。

---

### 【2.24】First Bug（3 分钟）

> **口播**：这一页标题叫 First Bug，"第一只虫子"。图上的人物是 Grace Hopper，格蕾丝·霍珀，1906 到 1992 年，她是计算机史上的传奇人物：参与早期计算机的研制、推动了编译器的发展，被称为 COBOL 之母，也是美国海军的少将。
> 课件这一页讲的是那个著名的故事：早期计算机使用大量机电继电器，某次机器故障排查时，工程师从继电器里取出一只飞蛾，把它贴进维护日志，并写下"发现 bug 的第一个实际案例"。从此，"bug"这个词在计算机领域就流行开来，排除故障也被叫做 debugging——"捉虫"。这里补一个更严谨的细节：bug 这个说法在更早的工程领域就已经用来指代故障了，但这只飞蛾让它在计算机行业里彻底流行，成为我们今天通用的术语。
> 我想请大家注意这个故事里最易被忽略的一点：**为什么工程师要把一只飞虫郑重地贴进日志本、还写上一句话？** 因为这只虫子不是一个笑话，这是一份**缺陷记录**——记录现象、保留证据、说明原因、供后来人查阅。这正是本课要培养的基本功：发现问题要如实记录，留下可追溯的证据，而不是口头说一句"刚才有点问题，重启一下好了"。
> 同学们，测试工作看起来是在跟代码打交道，本质上是在跟"诚实"打交道。把不利于自己的结果隐去、把偶发问题当作没发生，短期看省事，长期看就是把风险留给用户。霍珀那一代人留下的不只是"bug"这个词，还有一种一丝不苟的记录习惯。
> 再深一层看，记录习惯背后是工程的可重复性：只有把现象、环境、步骤写下来，别人才能复现、才能验证修复、才能在下次遇到相似问题时快速定位。测试人员交出去的最有价值的资产，往往不是"我发现了 bug"，而是一份别人照着就能复现的问题记录。

**板书**：写"**First Bug —— Grace Hopper（1906–1992）**"；下面写 **1947 年哈佛 Mark II 继电器中的飞蛾 → 贴入维护日志 → "第一个实际的 bug" → debugging（捉虫）**；右侧写一句落点："**发现 → 记录 → 留证据 → 可追溯**"。

**【思政落点 1】** 讲什么故事：霍珀团队把一只飞蛾贴进日志本并写明"这是第一个实际发现的 bug"。怎么联系知识点：软件缺陷定义要求"可追溯的问题记录"，缺陷报告的最小要素就是现象、环境、证据、影响。落到什么价值观：**科学精神与职业诚信——如实记录每一个问题、不隐去不利结果，是测试人员的职业底线，也是工程文化的基石。**

**提问**：如果一次测试中发现的问题是偶发的、复现不了，你会怎么处理？直接忽略还是记录？

**预设回答**：
- 答"记录下来，标注偶发和已尝试的复现步骤"：✅ 正确做法。点评：偶发问题往往是**并发、时序、资源竞争**类缺陷的前兆，最容易被忽略，也最容易在生产环境放大；记录时要把环境、时间、操作序列都留下来。
- 答"复现不了就当没有，省得浪费开发时间"：❌ 这是典型的隐瞒式处理。点评：把"我没法复现"变成"系统没问题"，本质上是**用省略换安心**；真出事故时，团队连线索都没有。
- 答"先记，但优先级放低，等再出现时合并"：✅ 稳妥。点评：补充一句——**允许低优先级，但不允许不记录**；同时要注明"暂不可复现"，方便后续出现同类现象时快速关联。

**易错点 / 考点**：①年代与人名对应：**Grace Hopper，1906–1992，First Bug 故事**；②"bug 一词由这只飞蛾首创"是流传很广的误解，准确说法是它让该词在计算机领域流行；③考点形式：名词解释"debugging"，或简答"从 First Bug 看缺陷记录应包括哪些要素"；④口诀：**先记下来，再想办法复现**。

**过渡**：认识了"第一只虫"，我们回到术语本身——缺陷在中文和英文里有非常多的说法，它们之间有微妙的差别，这正是下一页那张对照表要解决的问题。

---

### 【2.25】缺陷 – Defect, Bug（3 分钟）

> **口播**：这一页的标题是"缺陷 – Defect, Bug"，课件用一张表列出了缺陷在中英文里的各种说法，一共九组：缺点 defect、偏差 variance、谬误 fault、失败 failure、问题 problem、矛盾 inconsistency、错误 error、毛病 incident、异常 anomy。大家第一眼可能觉得"这些不都差不多吗"？请注意，正是这些词的混用造成了团队沟通和缺陷统计里的大量扯皮，所以要把它们的关系理清楚。
> 所以这三者不是同义词替换，而是一条因果链。**error（错误）**通常指人犯的错，比如需求理解错了、代码写错了一位。**fault 或 defect（谬误／缺陷）**指的是留在产品里的那个错误状态，比如代码里那行错误的判断条件，它是静态存在的。**failure（失败／失效）**指的是运行时表现出来的不正常结果，比如用户提交表单后系统崩溃。
> 三者构成一条链：**人犯 error → 产品里留下 fault/defect → 运行时出现 failure**。这也是为什么缺陷管理里必须区分"根因"和"现象"：用户看到的是 failure，工程师要找的是 fault，而真正要改进流程去解决的是 error 的产生原因。
> 剩下的几个词也有各自的语境：variance（偏差）常用在"实际结果与预期不一致"；inconsistency（矛盾）强调与需求、文档之间的相互冲突；problem（问题）是最宽泛的口语说法；incident（毛病／事件）在运维和缺陷追踪系统里常指一次故障事件；anomy（异常）指偏离常规的状态。**术语可以多，但描述缺陷时的口径必须统一**，这也是缺陷报告要使用标准字段和统一分级的原因。

**板书**：写"**缺陷的多种说法**"，左中右三列对照：**缺点 defect｜偏差 variance｜谬误 fault｜失败 failure｜问题 problem｜矛盾 inconsistency｜错误 error｜毛病 incident｜异常 anomy**；下面画链条：**error（人为错误）→ fault / defect（产品中的缺陷状态）→ failure（运行中的失效）**；旁注"**用户看到 failure，工程师找 fault，流程要治 error**"。

**提问**：线上用户报"系统崩溃了"，工程师说"这是环境问题不是缺陷"。这句话问题出在哪？

**预设回答**：
- 答"环境问题也是缺陷，因为用户受到了影响"：✅ 直击要点。点评：要补充专业表述——**用户感知到 failure，就必须先立案追踪**，至于根因是代码、配置、环境还是数据，是调查结论，不能作为"不记录"的理由。
- 答"工程师说得对，代码没问题就不是 bug"：❌ 混淆了 fault 和 failure 的层次。点评：**缺陷的定义看的是"偏离期望"，不是"代码有没有错"**；环境适配失败本身就是可移植性或兼容性上的质量问题。
- 答"两边说的不是一回事，各说各的"：⚠️ 看到了术语分歧，但止步于此。点评：这恰恰说明**团队需要统一的缺陷定义和分级口径**，否则同一件事有人算 bug、有人算配置问题，统计数字永远对不上。

**易错点 / 考点**：①error / fault(defect) / failure 三者的层次关系是本节最核心的考点，务必按"人—产品—运行"这条线记；②九个英文词不要张冠李戴，尤其 fault 与 failure 常被互换；③考点形式：给出场景判断属于 error、fault 还是 failure（"程序员把 '>=' 写成 '>'"→error/fault，"边界值输入时结果错误"→failure）；④记忆口诀：**人错 error、物错 fault、跑错 failure**。

**过渡**：术语口径统一之后，还要有权威定义做依据。下一页我们就看两个标准的原话：IEEE 729 和 ISO 29119。

---

### 【2.26】软件缺陷（3 分钟）

> **口播**：这一页给出软件缺陷的权威定义，课件引了两处。第一处是 IEEE 729（1983 年）给出的标准定义，它从两个角度描述：**从产品内部看，软件缺陷是软件产品开发或维护过程中所存在的错误、毛病等各种问题；从外部看，软件缺陷是系统所需要实现的某种功能的失效或违背。**请大家注意这个"内外两看"的结构：内部看是"问题存在"，外部看是"功能失效"，一个偏静态、一个偏动态，正好和前面讲的 error/fault/failure 呼应。
> 第二处是 ISO 29119 的定义，也是我们这门课后面做测试要常引用的标准。它把缺陷描述为：**组件或系统中会导致其无法执行所要求功能的瑕疵**；同时给出扩展说法：**任何依据需求规格说明、设计文档等基准而产生偏离的情况**，都算缺陷。下面还有一条非常重要的注（NOTE）：缺陷可能是在**评审、测试、分析、编译或使用软件产品及相关文档**的过程中被发现的——但不仅限于这些活动。
> 这条注把三件事说透了。第一，缺陷的发现手段不止"运行测试"一种，**评审、静态分析、编译告警乃至用户使用**都是发现渠道；第二，缺陷的载体不止程序代码，**文档、需求、设计**同样可能有缺陷；第三，只要偏离了基准或期望，就是缺陷，不需要等到它造成线上事故。
> 所以这一页请记住一句话：**缺陷是偏离期望的任何瑕疵，发现它的时机和手段可以多种多样，但判定它的尺子只有两把——基准（规格、设计、文档）和期望（用户需求）。**
> 最后给一个学习建议：这两个定义不要死背英文原句，要抓住它们共同的内核——偏离基准或期望，并且导致应有的功能无法实现。抓住内核，遇到没见过的表述，你也能判断它算不算缺陷。

**板书**：写"**软件缺陷的权威定义**"；左侧写 **IEEE 729（1983）：内部看＝开发/维护中存在的错误、毛病；外部看＝所需功能的失效或违背**；右侧写 **ISO 29119：会导致组件或系统无法执行所要求功能的瑕疵；任何偏离需求规格说明、设计文档等基准的情况**；下面写 NOTE 的三个发现渠道：**评审 · 测试 · 分析 · 编译 · 使用（不限于此）**，再画一条底线："**基准 ＋ 期望＝判定缺陷的两把尺子**"。

**提问**：ISO 29119 的注里说缺陷可能在"编译"和"使用"阶段被发现。请各举一个例子，并说明它们为什么容易被团队忽视。

**预设回答**：
- 答"编译告警说明代码有问题，但大家习惯性忽略告警"：✅ 非常真实。点评：大量空指针、未初始化变量、类型截断都藏在编译告警里，**把告警当噪音，就是把缺陷放进版本库**。
- 答"用户使用中发现的问题不算缺陷，因为没有用例"：❌ 需要纠正。点评：用户是真实语境下的测试者，**生产环境的用户反馈是缺陷的重要来源**；区别只在于它是最昂贵的一种发现渠道。
- 答"评审发现的只能算建议，不能记缺陷"：⚠️ 概念不准。点评：评审发现的需求二义、设计错误都是缺陷，**只是缺陷的载体不是代码**；记录时应标明发现阶段，便于做缺陷来源分析。

**易错点 / 考点**：①IEEE 729 的"内部／外部"两分法是经典考法，要能准确复述；②ISO 29119 定义里的两个要点——"无法执行所要求的功能"和"偏离需求规格说明、设计文档等基准"；③最容易漏的就是那条 NOTE：**缺陷发现不限于测试**，还可能是评审、分析、编译、使用；④考点形式：名词解释、判断"只有运行程序发现的问题才叫缺陷"（错）、简答"缺陷可能在哪些阶段被发现"；⑤记忆口诀：**内看问题、外看失效；偏离基准、即为缺陷；发现渠道、不止测试**。

**过渡**：到这里，第 2 章关于"质量"和"缺陷"的基本概念就讲完了——质量模型告诉我们什么是好，缺陷定义告诉我们什么是坏。接下来我们会用这些口径进入下一部分：缺陷是怎么分类的、测试又是怎么分类的。