### 【1.40】1.3.4 软件测试的其它观点（2 分钟）

> **口播**：前面几页我们走了三步：1.3.1 看软件测试这门学科是怎么形成的，1.3.2 看围绕测试的正反两方面的争辩，1.3.3 给出软件测试的定义。到了这一页，1.3.4，我们要接着追一个问题：定义有了，那能不能从更多角度把测试看得更立体一点？答案是能。这一节给大家五个视角，等于从五个不同的坡面去爬同一座山。第一，质量视角，测试是对软件质量进行全面评估；第二，风险视角，测试是对潜在的各种质量风险进行评估；第三，经济视角，测试是用最小的代价换最高的软件产品质量；第四，基于 Test Oracle 的认知，判断输出结果对不对，得有判断准则；第五，基于批判性思维的认知，测试是借助观察、经验、反思、推理和沟通来收集信息、做出结论的不断探索的过程。有同学会问：定义不就够了吗，为什么要费劲讲五个视角？因为定义是一句话，观点是一整套看问题的方式。你在企业里跟人讨论"这个版本要不要多测一轮"，只背定义是说服不了人的：跟项目经理要讲风险，跟老板要讲成本，跟开发要讲判断准则，跟客户要讲质量。不同角色的语言不一样，测试人员必须会切换语言。打个比方，同一辆车，司机关心好不好开，修车师傅关心哪里容易坏，保险公司关心出事故的概率，二手车商关心值多少钱——车是同一辆，问题不同，结论自然不同。还要提醒一句：这五个视角不是五套互相打架的说法，而是互补的。质量视角回答"测什么"，风险视角回答"先测什么"，经济视角回答"值不值得测"，Test Oracle 回答"怎么判定对错"，批判性思维回答"用什么态度去测"。考试爱考"观点与核心主张"的对应，给你一句话让你判断它属于哪个视角，所以接下来每一页，请重点抓那句话的关键词。

**板书**：1.3.4 其它观点 → 质量视角｜风险视角｜经济视角｜Test Oracle｜批判性思维 → 互补、不冲突

**提问**：如果项目经理说"这个版本时间很紧，少测一点"，五个视角里你更可能用哪一个去跟他沟通？为什么？

**预设回答**：①答"风险视角"——正确，且能说出"按风险排序，砍掉低风险项而不是平均砍"。教师点评：方向对，要追问一句"那你怎么证明哪些是低风险"，逼学生给出风险判断的依据。②答"质量视角"——只对了一半。教师追问：你讲质量，项目经理会说"质量我当然要，但时间不够"，这句话没有说服力；质量视角讲的是"测什么"，不是"砍多少"。③答"经济视角也行"——可以接受，但要提醒：经济视角解决的是"这笔测试投入值不值"，是用成本收益算账，跟"先测哪块"是两个问题。把三种回答并排写在黑板上，正好演示五个视角各管一段，不是随便挑一个都行。

**易错点 / 考点**：最典型的错，是把五个视角背成五句口号，却分不清谁回答哪个问题。判断三步法：先看这句话在谈"测什么"还是"先测什么"还是"值不值"；再看它有没有提到判断准则；最后看它是不是在讲收集信息、做结论的过程。选择题常考"从经济视角看软件测试的核心是什么"这类对应题，判断题常把"测试就是找 Bug"当正确项来设置陷阱。

**过渡**：五个视角，我们从最容易被挂在嘴边、也最容易被理解偏的一个开始——质量视角。

### 【1.41】从质量视角认知软件测试（4 分钟）

> **口播**：这一页进入质量视角。课件上那句话是：软件测试被认为是对软件质量进行全面评估的活动，给出质量信息，从而确定质量是否满足设计和用户的需求。请抓住三个关键词：全面评估、给出质量信息、满足需求。第一层，测试是一项评估活动，不是"找茬活动"。大家看这张图，中间画着"发现 Bug？"，后面专门带了一个问号，这就是在提醒我们：测试的目的不只是找 Bug，而是给出质量信息，让决策者知道这个软件现在到底能不能交付。你把 Bug 报上去，开发改完，测试再验，这一整套动作的最终产出，是一份关于质量的判断，而不是一堆缺陷单。第二层，为什么会有缺陷？看图的下半部分：左边是用户，带着"要求/期望"；右边是质量，也就是实际做出来的东西；中间标着"矛盾/对立"。软件缺陷的本质，就是做出来的东西和用户要求的、期望的东西之间出现了落差。这句话很重要，它解释了后面为什么要做需求评审、为什么要写验收标准——因为只有当"要求和期望"被写清楚，落差才可判定。第三层，靠什么评估？图里写了"质量模型"。质量模型就是一把尺子。国际上常用的软件质量模型，会把质量拆成功能适合性、性能效率、兼容性、易用性、可靠性、安全性、可维护性、可移植性这些特性。没有这把尺子，"质量好"就是一句空话，A 说挺好，B 说不行，吵到最后谁嗓门大谁赢。生活里的道理是一样的：体检报告不会只写"你身体不错"，它给出血压、血糖、血脂这些指标，让医生和你都能对比、能追踪。测试报告也一样，要给出可对比、可追踪的质量信息。为什么这个视角重要？因为太多团队的测试报告只写一句"测试通过，未发现严重问题"，这句话对决策几乎没有价值——它是结论，不是信息。真正有用的写法是：测了哪些质量特性、覆盖了多少条需求、剩余风险集中在哪里。这一页还埋下了后面反复要用的三个概念：需求是测试的依据，质量特性是测试的维度，评估结论必须建立在证据之上。

**板书**：质量视角 → 全面评估 + 给出质量信息 → 用户"要求/期望" ↔ 质量（矛盾/对立）→ 评估靠"质量模型" → 发现 Bug？（不只是找 Bug）→ 需求是依据、质量特性是维度、结论靠证据

**提问**：课件的图里，"发现 Bug"后面为什么要加一个问号？如果测试只以"找到 Bug"为目的，会漏掉什么？

**预设回答**：①答"因为测试的目的不只是找 Bug"——正确。教师追问：那除了找 Bug，测试还产出什么？引导学生说出"质量信息、能否交付的判断、剩余风险"。②答"因为不是每次都能找到 Bug"——这是典型错误，把目的和结果搞混了。教师点评：找不到 Bug 的那一轮测试一样有价值，它提供了"当前版本在这些范围内没有发现问题"的信息，这是发版决策的证据；要找 Bug 才做测试，等于把测试当成抽奖。③答"因为 Bug 这个词有歧义，需求理解错了也算 Bug"——有深度，可以顺势引到下一句"矛盾/对立"：需求本身有歧义时，判断对错的标准就不牢靠，所以要提前评审需求。三种回答按"结论—证据—标准"三层排一下，学生就明白为什么测试报告要写信息而不是只写结论。

**易错点 / 考点**：两个混淆点。第一，把"测试"等同于"找 Bug"，忽略"给出质量信息"，这是最常见的选择题陷阱。第二，把质量模型当成考试名词硬背，却不会用它组织测试：考案例题时，要求你针对某个系统列出该测哪些质量特性，只写"功能"两个字是拿不到分的。记忆口诀：要评估、给信息、比需求、靠模型。

**过渡**：质量视角回答的是"测什么"，但它回答不了"先测什么"。要回答这个问题，我们得换到风险视角去看。

### 【1.42】从风险视角认知软件测试（4 分钟）

> **口播**：这一页讲风险视角。课件上写着：软件测试被认为是对软件系统中潜在的各种质量风险进行评估的活动。后面还有一句非常关键的话：测试是样本实验而不能穷尽，其风险总是存在的。再往下，是"基于风险的测试"这个说法——它强调对软件开发的全过程进行检测，随时发现问题、报告问题，减少对客户不利影响的风险。我们先拆"测试是样本实验而不能穷尽"。这句话的意思是：你不可能把用户所有可能的输入、所有可能的操作顺序、所有可能的运行环境都试一遍。输入组合是爆炸式增长的，一个几百行的小程序，穷举路径都做不到，何况一个几十万行的系统。既然测不完，那就必须选择测什么——这就是样本实验。既然是抽样，就一定会有漏网之鱼，所以风险永远存在，测试的目标不是"消灭风险"，而是把风险压到可以接受的水平。这就引出基于风险的测试：哪里出事概率高、出了事后果重，就优先测哪里。风险大致等于"发生的可能性"乘以"一旦发生的损失"。举个身边的例子：一个电商系统，支付和退款模块一旦出错就是真金白银的损失，而"关于我们"页面的错别字损失极小。时间只够测一半的时候，先测支付，这叫按风险排序，不叫偷懒。再看图上这条链：上面是需求、设计、代码，中间是功能和非功能特性，往下是测试，最后到交付；左边站着产品经理、项目经理和开发人员，图里向下的箭头旁边写着"持续反馈质量风险"，而且是两处，意思是从头到尾一直在反馈。这一点是理解本页的钥匙：风险不是等到测试阶段才暴露，需求写得含糊、设计接口对不上、代码没有异常处理，这些都是风险源，测试人员要尽早介入，随时把风险信息反馈回去。所以风险视角下的测试，是贯穿开发全过程的一项检测活动，不等同于最后阶段的验证。对客户来说，提前发现一个高风险问题，可能就避免了一次线上事故、一次口碑崩塌。

**板书**：风险视角 → 测试＝样本实验，不能穷尽 → 风险＝可能性 × 影响 → 基于风险的测试：全过程检测、随时发现、随时报告 → 需求→设计→代码→（功能/非功能特性）→测试→交付，向上"持续反馈质量风险"

**提问**：同样的测试时间，为什么"平均分配给每个功能模块"是一种不负责任的做法？请举一个你熟悉的系统来说明。

**预设回答**：①答"因为有的模块出问题损失大，平均分配等于高风险的地方没测够"——正确，能说出概率和影响两个维度更好。教师点评：让他具体说出"哪个模块、什么后果"，把抽象原则落到场景。②答"因为测试时间不够，从来测不完"——只答对了一半，这只解释了为什么要选择，没解释为什么不能平均。教师追问：那如果某个模块又简单又不重要，你给它同样的人力，损失的是什么？引导学生说出"机会成本"。③答"平均分配没什么不好，覆盖面广"——这是很典型的错误直觉。教师点评：覆盖面广不等于风险低，覆盖了十个不重要功能，不如覆盖一个支付功能；把这句话写在黑板上，作为"风险排序"的反面教材，再让学生把它改写成"按风险×影响排序"。

**易错点 / 考点**：第一，把"基于风险的测试"误解成"高风险模块多测几轮"这么简单，漏掉"全过程检测、持续反馈"这一半。第二，误以为测试可以做到零风险、穷尽验证，判断题常拿"只要测试足够充分就能保证软件无缺陷"来设坑，答案是错的。判断三步法：先问"能不能穷尽"（不能），再问"先测哪里"（风险高的），最后问"风险从哪来"（需求、设计、代码全过程）。

**过渡**：既然测不完，就必须做取舍；而只要谈取舍，就绕不开钱。接下来我们从经济视角算一算这笔账。

### 【1.43】从经济视角认知软件测试（3 分钟）

> **口播**：这一页从经济视角看测试。课件原话是这样四句：测试的经济观点就是以最小的代价获得最高的软件产品质量；经济观点也要求软件测试尽早开展工作；发现缺陷越早，返工的工作量就越小，所造成的损失就越小；还有一句是最扎心的——测试的成本要小于缺陷造成的损失，测试才有意义。我们一句一句来。第一句，"以最小的代价获得最高的质量"，注意不是"不计代价追求零缺陷"。测试是要花钱的：要人、要时间、要环境、要机器。如果为了一百万分之一的概率去投入巨大成本，那这笔钱花得不值。所以测试从来不是"测得越多越好"，而是"花得值"。第二句和第三句连起来看，是这一页的核心：为什么要尽早测？因为发现得越早，返工的工作量越小，损失越小。缺陷像滚雪球，需求阶段一句话的含糊，到了设计就变成接口定义错误，到了编码就变成一片实现，到了测试甚至上线才暴露，这时候要改的不只是一个字，而是设计、代码、文档、数据，甚至已经交付给用户的产品。生活里的类比很好懂：牙上有个小黑点，早去看，补一下就好；拖到牙神经坏了，就要根管治疗加牙冠，钱和罪都翻好几倍。汽车刚有异响就去检查，也许只是换个垫片；拖到高速上抛锚，损失的就是拖车费、误工费甚至安全。软件行业最典型的例子，就是英特尔当年奔腾处理器的浮点除法缺陷，据本课程案例素材，最后召回换货付出的代价在四亿美元这个量级。一个除法算错的细节，最后变成了一场大规模的召回。第四句给了我们一把决策尺子：测试的成本小于缺陷造成的损失，测试才有意义。反过来，如果某类缺陷造成的损失远小于测试它的成本，那就要重新考虑测到什么程度。这也解释了为什么测试要有优先级、要做风险排序——钱要花在刀刃上。同学们以后写测试计划，里面一定会有"范围和取舍"，那时你要能说清：我为什么测这些，为什么这一段先测，为什么那一段只做抽样。

**板书**：经济视角 → 最小代价 × 最高质量 → 尽早测试：发现越早，返工越小、损失越小 → 决策尺子：测试成本 < 缺陷损失，测试才有意义 → 测试不是"越多越好"，是"花得值"

**提问**：有人说"质量是免费的"。结合这一页的经济视角，你同意吗？如果不完全同意，请把这句话补完整。

**预设回答**：①答"不完全同意，预防的投入是必要的，但质量不是零成本"——很好。教师点评：这话的原始含义是"把缺陷挡在前面比事后返工便宜"，而不是"一分钱不花就有高质量"。②答"同意，做好质量就不需要返工"——典型错误。教师追问：那测试人员、测试环境、回归测试的机器要不要钱？引导学生区分"预防成本低"和"成本为零"。③答"只有测试成本小于损失才值得测"——抓住了课件的尺子。教师点评：这句话是对的，但要追问边界——损失怎么估？让学生意识到"损失估算"本身就是一件需要判断的事，不能拍脑袋。

**易错点 / 考点**：常见错误有两个。一是把经济视角读成"少测省钱"，其实它的落脚点是"尽早测"和"算总账"。二是忽略"测试也是有成本的"，答案例题时只写"要测得更充分"，不提成本与收益的平衡。考试常考判断题："缺陷发现得越晚，修复成本越高"——正确；"测试投入越多，质量一定越高"——错误。记忆口诀：早发现、小返工、算总账。

**【思政落点 43】** 讲什么故事：课件这句"测试成本要小于缺陷造成的损失，测试才有意义"，背后是企业实实在在的钱，也是用户实实在在的安全。怎么联系知识点：经济视角不是教大家省钱省测试，恰恰相反，它告诉我们缺陷一旦流到用户手里，代价会成倍放大——英特尔奔腾的浮点除法错误，最后是四亿美元量级的召回。落到什么价值观：工程人员的每一次"这个先不测了，赶进度"，都不是一句轻飘飘的话，最终买单的是企业和用户；把缺陷挡在交付之前，既是职业能力，也是质量责任的底线。

**过渡**：经济视角告诉我们要算总账，可要算账，前提是能判断"这一段结果到底对不对"。这就引出了 Test Oracle 的认知。

### 【1.44】基于 Test Oracle 的认知（3 分钟）

> **口播**：这一页很短，字也很少，但它是整个测试活动的地基。课件上只有一句话：输出结果是否正确，需要判断准则。图也只有一张，画的就是这个意思。什么叫判断准则？就是当你把一组输入喂给程序、程序吐出一个结果的时候，你凭什么说这个结果是对的。这个"凭什么"，在测试领域有一个专门的术语，叫 Test Oracle，中文一般翻译成测试预言或测试判定准则。为什么它这么重要？因为没有 Oracle，测试就变成了"看着像对的就算对"。举个最简单的例子：一个计算器程序，你输入 2 加 3，它输出 5，你说对；如果它输出 6，你说错。你的判断准则来自小学数学，这就是 Oracle。再比如登录功能：输入正确的账号密码，期望结果是登录成功、跳转到首页、并且页面右上角显示用户名。这一串"期望结果"，才是你的判断准则。如果只写"登录成功"，那系统提示"登录成功"却把你导到一个空白页，你算不算通过？没有准则，就判不了。那 Oracle 从哪里来？常见的有几类：需求规格和验收标准，这是最正规的来源；业务规则和领域知识，比如财务系统里借贷必须相等；旧系统的实际行为，做系统改造时拿老系统当参照；已有的参考实现或者同类产品的表现；还有测试人员的人工经验判断。这里要提醒一个现实困难，业内叫"Oracle 问题"：有些输出很难有唯一的正确标准。比如界面的美观程度、语音识别的结果质量、算法给用户推荐得合不合理，甚至是今天大量的 AI 输出——这些地方"对"的边界很模糊。遇到这种情况，通常的做法是把它转化成可判定的形式：把美观转成设计规范的检查项，把推荐质量转成一批标注好的样本和一条通过线，或者引入多人评审。所以这一页想让大家记住的是：测试不是"跑一遍看看"，测试是先有准则、再执行、最后比对。你在本课程的实验里写测试用例，表头一定会有"预期结果"这一列，那一列就是你的 Oracle，它不是形式主义，它是你能不能判定通过的依据。

**板书**：Test Oracle → 输出结果是否正确，需要判断准则 → 准则来源：需求规格/验收标准｜业务规则与领域知识｜旧系统行为｜参考实现｜人工经验 → 有准则才能判"通过/不通过" → 难判定的输出要转化为可判定形式

**提问**：测试用例表里"预期结果"这一列，如果空着或者写成"正常显示"，会带来什么后果？

**预设回答**：①答"没法判断测试通过还是失败，两个人可能得出两个结论"——正确。教师点评：再追一步，这种不一致在团队协作里会导致什么？引导到"缺陷争议、返工、回归标准不统一"。②答"没关系，执行的人自己知道对错"——典型错误。教师点评：写用例的人知道，不代表执行的人知道，更不代表三个月后回归测试的人知道；用例是给团队用的，不是给个人备忘的。③答"可以事后补上"——可接受但不是好做法。教师追问：如果开发改完代码，你又补了新的预期结果，那这次改动到底算通过还是没通过？引导学生理解：Oracle 是先于执行确定的，事后补等于给结果找解释。

**易错点 / 考点**：第一，把 Test Oracle 当成某个工具或某个测试类型，其实它是一个概念——判定准则。第二，写用例时把预期结果写成"结果正确""正常"这类无法判定的表述，这是实验和课程设计里最常见的扣分点。第三，误以为 Oracle 只能来自需求文档；事实上领域知识、旧系统、参考实现、人工经验都可以，但来源越客观，争议越小。判断口诀：先有准则、再执行、后比对。

**过渡**：有了准则，还差一样东西——态度。因为再好的准则，也挡不住"我觉得没问题"这种随意判断。

### 【1.45】基于批判性思维的认知（3 分钟）

> **口播**：这一页把测试和一种思维方式绑在一起。课件上是这么说的：软件测试就是借助观察、经验、反思、推理或沟通等收集信息，并对软件产品相关的质量信息进行分析，以此评估软件质量，并做出结论。后面还跟着一句短语：不断探索的过程。我们先看前半句里的五个手段：观察、经验、反思、推理、沟通。观察，是看现象——点下去有没有反应、返回的数据对不对、界面有没有错位；经验，是你见过类似的系统怎么出错，比如日期、金额、并发；反思，是回头想"我刚才这个判断是不是太快了""这里没出问题是不是因为我根本没测到"；推理，是从已知推未知——这个输入框限制了长度，那粘贴超长文本会怎样；沟通，是找开发、产品、用户把需求问清楚。这五种手段合起来，是在收集信息，而不是在收集感觉。后半句"做出结论"，说明测试最终要给出判断，但判断必须建立在分析过的质量信息之上。那"批判性思维"体现在哪里？体现在一个根本立场：不轻信。程序说"保存成功"，不一定真保存了，要去数据库里核实；界面显示"操作已完成"，不一定真完成，要看状态有没有变；开发说"这个功能没问题"，那就要用证据来确认。这跟前面 risk 视角里那句"测试是样本实验"是一脉相承的。反过来，如果测试人员的思维方式是"我写的用例都跑过了，应该没问题"，那就从批判性思维滑回了自我安慰。这也是本页两个图要表达的对照：一个是不断提出疑问、不断探索的循环，一个是一旦停止怀疑就停止发现缺陷。生活里我们其实每天都在用批判性思维：买东西看配料表，不听广告听成分；看到"限时特价"先想是不是原价就那样。做测试就是把这种较真的习惯，变成一种有方法、有记录、有结论的工作方式。请记住这句话：测试人员不是软件的敌人，但一定是"未经证实的结论"的敌人。

**板书**：批判性思维 → 观察｜经验｜反思｜推理｜沟通＝收集信息 → 分析质量信息 → 评估质量、做出结论 → 不断探索的过程 → 核心立场：不轻信、要证据

**提问**：界面上弹出"保存成功"，为什么还不能直接判定这个功能测试通过？你会再去看什么？

**预设回答**：①答"要去数据库或列表里查一下数据真的写进去了"——正确。教师点评：这就是观察加推理，把界面提示当作线索而不是结论。②答"把提示截个图，用例就算过了"——典型错误，属于只验证了现象、没验证结果。教师追问：如果程序只弹了提示、实际什么都没存，你这条用例是不是漏掉了缺陷？③答"看开发怎么说"——不可取。教师点评：沟通是手段之一，但沟通用来澄清需求，不能用来替代验证；开发说存了，你仍然要自己看到证据。

**易错点 / 考点**：第一，把批判性思维理解成"跟开发抬杠""什么都怀疑"，其实它的落点是收集信息、分析信息、做出有依据的结论。第二，把"探索"当成漫无目的地乱点，忽略课件列的五个手段和后续的分析动作。第三，考试里常把"测试是证明程序没有错误"当正确项，这是反的——测试是带着怀疑去求证，不是去证明"我写对了"。记忆口诀：不轻信、找证据、做结论。

**【思政落点 45】** 讲什么故事：批判性思维这一页，考验的其实是一个人的诚信与科学态度。怎么联系知识点：课件要求测试借助观察、经验、反思、推理、沟通去收集信息，再基于信息做出结论——这就是用证据说话。落到什么价值观：发现缺陷不报告、为了赶进度隐去不利结果、把"没测"写成"通过"，都是对事实的背叛；如实记录、如实评价，是测试人员最基本的职业操守，也是我们这门课过程性考核看重的态度。

**过渡**：到这里，软件的"其它观点"讲完了。接下来要处理一个在课堂上和工作中都极易混淆的关系——测试和质量保证到底是什么关系。

### 【1.46】1.4 测试与质量保证的关系（2 分钟）

> **口播**：这一页是 1.4 节的开头，标题就是本节要回答的问题：测试与质量保证的关系。大家先看这张图，它把本节要建立的框架先摆出来了。为什么单独拿一节来讲这个关系？因为这是最容易被混为一谈的一对概念。很多同学一听说"质量保证"，脑子里想的就是"测试"；也有同学以为"测试"和"质量保证"是两个各自为政的部门。这两种理解都会出问题：前一种会导致你把质量保证做成了事后检测，后一种会导致两边互相推责任——测试说"你怎么没保证质量"，质量保证说"我提醒过你，是你没测出来"。我们先看课件备注里列的内容：1.3.1 软件测试学科的形成、1.3.2 正反两方面的争辩、1.3.3 软件测试的定义、1.3.4 软件测试的其它观点——这是刚才这一大段的回顾，说明我们前面的讨论都还在 1.3 节里。现在转进 1.4，接下来三页要依次回答三个问题：第一，什么是 SQA，也就是软件质量保证；第二，SQA 到底做哪些活动；第三，软件测试和 SQA 之间谁包含谁、谁指导谁、谁给谁提供数据。这三个问题的答案，都会在实验报告和课程设计文档里用到——比如你写测试计划，如果分不清"测试活动"和"SQA 活动"，范围就会写乱；你写质量报告，如果分不清"我提供数据"和"我负责整个流程"，职责就会越界。所以这一节虽然概念性强，但它是后面所有文档写作的语法。最后把本节最容易混的一点先点出来：以后做题，凡是问"谁负责流程与规范"的，答案指向质量保证；凡是问"谁给出产品的验证结论"的，答案指向测试。这两个答案千万不要对调。

**板书**：1.4 测试与质量保证的关系 → 三问：什么是 SQA？SQA 有哪些活动？测试与 SQA 谁包含谁？→ 前面回顾：1.3.1 学科形成｜1.3.2 正反争辩｜1.3.3 定义｜1.3.4 其它观点

**提问**：你们觉得"测试"和"质量保证"是一回事吗？如果是两回事，差别在哪一句话上？

**预设回答**：①答"不是一回事，测试是查产品，质量保证是管流程"——很接近正确答案。教师点评：这句直觉很好，先记在黑板上，等第 49 页再严格对照。②答"是一回事，测试就是保证质量"——最常见的错误。教师追问：如果测试就是质量保证，那一个没有独立测试团队的公司，是不是就没有质量保证了？引导学生发现两者活动范围不同。③答"质量保证更大，包含测试"——方向对了。教师点评：正确但不完整，要补上"包含"之外还有"指导和监督"这层关系，留到第 49 页揭晓。

**易错点 / 考点**：本节的混淆点集中在层级关系上——软件测试是 SQA 的活动之一，但 SQA 不等于测试；"测试是 SQA 的重要手段"和"SQA 指导监督测试"是两句话、两个方向，不能只答一半。判断三步法：先看它说的是流程还是产品，再看它是给数据还是提要求，最后落到对应的那一栏。选择题常把两者对调来设坑，务必看清主语。

**过渡**：要把这个关系讲清楚，先得知道 SQA 本身是什么——下一页我们就给它一个正式的定义。

### 【1.47】什么是 SQA？（4 分钟）

> **口播**：这一页回答什么是 SQA。SQA 是软件质量保证的英文缩写，全称 Software Quality Assurance。课件给出了一个完整定义：软件质量保证活动是通过对软件产品有计划的进行评审和审计来验证软件是否合乎标准的系统工程，通过协调、审查和跟踪以获取有用信息，形成分析结果以指导软件过程。这个定义里有三个动作请画下来：有计划的评审、审计、以及验证是否合乎标准；还有一条目的：指导软件过程。注意最后这四个字——指导软件过程，它说明 SQA 关心的不只是"这个产品行不行"，更是"我们造产品的这套流程行不行"。围绕这个定义，课件又给了三句展开。第一句：对软件工程各个阶段的进展、完成质量及出现的问题进行评审、跟踪。注意"各个阶段"，从需求到设计到编码到测试到上线，每个阶段都要有检查点，而不是最后一次性大检查。第二句：审查和验证软件产品是否遵守适用的标准、规程和要求，并最终确保符合标准、满足要求。这里说的是"合规"，标准可能是国际标准、行业标准，也可能是公司自己定的开发规范和编码规范。第三句：建立软件质量要素的度量机制，了解各种指标的量化信息，向管理者提供可视信息。这一句最容易被忽略，但它非常实在——质量保证要拿出数据，比如缺陷密度、评审发现率、需求变更次数、用例通过率，用这些量化信息让管理者看清楚现状。把三句合起来看，SQA 的工作方式可以概括成三个词：定标准、查执行、报数据。生活里最好懂的例子是食品安全检查：不是等吃坏肚子才去查，而是从原料采购、生产车间、包装、出厂检验，一路都有标准和抽查记录。软件也一样，SQA 是给软件生产过程装的一套"质量体系"，测试只是这套体系里的一环。所以如果你以后做测试工程师，会经常收到 SQA 发来的评审通知、度量表格和规范更新；而如果你做质量保证，就要学会从测试数据里读出流程的问题，而不是只盯着缺陷数。

**板书**：SQA＝Software Quality Assurance 软件质量保证 → 定义：有计划地评审、审计，验证是否合乎标准 → 目的：获取信息、分析结果、指导软件过程 → 三句展开：①各阶段进展/质量/问题 评审跟踪 ②审查验证是否遵守标准、规程、要求 ③建立度量机制，向管理者提供可视信息 → 三词概括：定标准、查执行、报数据

**提问**："向管理者提供可视信息"为什么也要算 SQA 的工作？只提交一份缺陷清单不行吗？

**预设回答**：①答"不行，管理者要做决策，需要看趋势和量化指标，不只是零散的问题"——正确。教师点评：顺势点出缺陷密度、通过率这类指标比单条缺陷更能反映流程状态。②答"因为管理者看不懂技术细节"——有点道理但角度偏了。教师点评：不是看不懂，而是管理决策需要的是"趋势、对比、风险"，单条缺陷回答不了"这个版本能不能发"。③答"这是形式主义，交清单就够"——典型错误。教师追问：如果缺陷有 200 条但都集中在同一个模块，清单能告诉你什么？引导学生说出"集中度、根因、流程改进方向"。

**易错点 / 考点**：第一，把 SQA 缩写成"质量检测"，忽略它是过程性的、计划性的系统工程。第二，只记住定义，答不出 SQA 的三个工作面向（评审跟踪、合规验证、度量报告）。第三，考试中常出现"以下哪项不属于 SQA 的工作"，要把 SQA 的度量、评审、审计、标准执行和"具体写代码"区分开。记忆口诀：定标准、查执行、报数据，目的是指导过程。

**过渡**：定义讲完了，那 SQA 具体要做哪些活动呢？下一页列出了七项。

### 【1.48】SQA 活动（3 分钟）

> **口播**：这一页列出 SQA 的具体活动，一共七项，我们一项一项过。第一，技术方法的应用。就是说开发过程要用对方法和工具，用什么开发方法、什么设计方法、什么建模手段，SQA 会关注这些方法有没有被正确使用，因为它直接影响质量。第二，正式技术评审的实施。注意"正式"两个字——它和随便找人看两眼完全不同，正式技术评审要有计划、有角色、有检查单、有记录、有结论。第三，软件测试。这一项请大家重点画下来。软件测试是 SQA 的活动之一，也就是说测试在质量保证的框架之内。第四，标准的执行。编码规范、文档模板、命名约定、配置管理要求，这些标准要落地执行，SQA 负责推动和检查。第五，修改的控制。也就是变更控制，代码、需求、文档的每一次修改都要走流程、要评估影响、要留痕。为什么这一项重要？因为大量缺陷不是"一开始就写错"，而是"改出来的"——修了 A 功能结果弄坏了 B 功能。第六，度量。要建立指标，收集数据，比如缺陷密度、评审效率、测试通过率。没有度量，改进就没有方向。第七，质量记录和记录保存。评审记录、测试报告、变更记录，这些都要归档保存，一方面是为了追溯，另一方面是为了体系审核时能提供证据。把这七项放在一起看，你会发现一个规律：它们大部分都不是"直接检查产品"，而是在检查"做事的方式"——方法对不对、评审做没做、标准守没守、变更管没管、数据有没有。只有第三项"软件测试"是直接对产品做验证和确认。这就解释了为什么测试是 SQA 的重要手段之一，但绝不是全部。同学们在做课程设计的时候，其实可以拿这七项当自查表：你的项目有没有走评审？代码有没有规范？需求变更有没有记录？测试数据有没有统计？测试报告有没有归档？这七问答下来，基本就知道一个团队的质量管理水平在哪里。也提醒一句，考试里非常喜欢问"软件测试是不是 SQA 的活动之一"，答案是肯定的，别答成"两回事"。

**板书**：SQA 活动七项 → ①技术方法的应用 ②正式技术评审的实施 ③软件测试 ④标准的执行 ⑤修改的控制 ⑥度量 ⑦质量记录和记录保存 → 多数查"做事方式"，第③项直接查产品 → 结论：测试是 SQA 的重要手段之一，不是全部

**提问**：这七项里，哪一项最容易被小团队省略？被省略之后，通常在什么时候付出代价？

**预设回答**：①答"质量记录和记录保存，或者度量"，也有人答"正式技术评审"——都合理。教师点评：请他给出一个具体后果，比如没有记录，出了线上问题无法追溯是哪次改动引入的。②答"测试最容易被省"——不准确。教师点评：测试往往是小团队唯一保留的"质量动作"，恰恰是被裁到只剩它；真正的空白通常是评审、度量和记录。③答"七项都得做，一项都不能省"——态度可嘉但要引导到现实：资源有限时应该按风险取舍，但"不留记录"这种省法等于把可追溯性一起省掉了，代价最大。

**易错点 / 考点**：第一，漏项。七项里"修改的控制""度量""质量记录"最容易被忽略，考试多选常在这里设置正确项。第二，把"技术方法的应用"理解成"使用测试工具"，它的范围更宽，指开发全过程中技术方法的正确使用。第三，判断题常考"软件测试是 SQA 活动之一"——正确；"SQA 就是软件测试"——错误。记忆口诀：法（方法）评（评审）测（测试）标（标准）改（变更）度（度量）记（记录）。

**过渡**：七项活动里有测试，也有评审、标准、变更、度量。那测试在整个 SQA 里到底站在什么位置？下一页我们就正面对比。

### 【1.49】软件测试 vs. SQA（4 分钟）

> **口播**：这一页是本节的核心，把测试和 SQA 摆在一起对照。课件给了三层关系，我们逐层看。第一层：SQA 指导、监督软件测试的计划和执行，督促测试工作的结果客观、准确和有效，并协助测试流程的改进。请注意这三个词——客观、准确、有效。SQA 不替测试干活，它盯着测试干得对不对：你的测试计划有没有覆盖关键需求，你的测试结果是不是如实记录，你的测试流程有没有可以改进的地方。第二层：软件测试是 SQA 重要手段之一，为 SQA 提供所需的数据，作为质量评价的客观依据。也就是说，SQA 要判断"这批产品的质量行不行""这条流程改得对不对"，它靠什么下判断？靠测试给的数据。测试是 SQA 的眼睛和手。第三层是最容易考的对照：SQA 是一项管理工作，侧重于对流程的评审和监控；测试是一项技术性的工作，侧重对产品进行评估和验证。一个管过程，一个验产品；一个关注"我们是怎么做的"，一个关注"做出来的东西对不对"。把三层连起来记，就是一句话：SQA 给测试定规矩、看规矩有没有被守，测试给 SQA 交数据、当质量判断的依据。这里要澄清两个常见误解。第一个误解是"测试做得越多，SQA 就越好"。不对——测试发现了一大堆缺陷，恰恰说明前面的需求、设计、评审环节有问题，SQA 该做的是去改进流程，而不是庆祝测试团队发现的缺陷多。第二个误解是"有了 SQA 就不用测试，或者有了测试就不需要 SQA"。也不对——没有测试，SQA 的结论没有客观数据支撑，只能靠感觉；没有 SQA，测试容易变成自说自话，标准不统一、结果不可比、流程不改进。这一页的知识在你们的课程设计里会直接用到：写测试计划时，范围、准则、记录方式其实都受质量保证要求约束；写质量报告时，你要清楚自己提供的是"数据与验证结论"，流程评审和改进建议属于另一条线。分得清这两条线，文档就不会写串。

**板书**：软件测试 vs. SQA → SQA 指导、监督测试的计划与执行（客观、准确、有效）→ 测试是 SQA 重要手段之一，为 SQA 提供数据 → SQA＝管理工作，侧重流程的评审与监控；测试＝技术工作，侧重产品的评估与验证 → 一句话：SQA 定规矩看规矩，测试交数据当依据

**提问**：如果某个版本测试发现缺陷特别多，是先表扬测试团队，还是先检查流程？为什么？

**预设回答**：①答"先检查流程，说明前面环节没拦住缺陷"——正确。教师点评：追一句"那测试团队该不该表扬"，引导学生区分"发现缺陷有价值"和"缺陷多说明前期失控"两件事。②答"表扬测试，说明测试认真"——情绪上合理，但漏了重点。教师追问：如果需求评审做扎实了，这批缺陷里有多少根本不会产生？让学生体会"质量是设计出来的，不是测出来的"。③答"两个都要查"——稳妥，可以接受。教师点评：这个回答不错，但要问清优先级：先看缺陷的引入阶段分布，才能判断是流程问题还是个别疏忽。

**易错点 / 考点**：第一，把两者的关系答成"包含关系"就停手，漏掉"指导、监督、提供数据"三层互动。第二，答选择题时把"SQA 侧重产品验证、测试侧重流程监控"选成正确项——这是把两者对调了，属于高频陷阱。第三，判断题"SQA 就是测试部门""测试人员就是 SQA 人员"都是错的。记忆口诀：SQA 管过程，测试验产品；SQA 给测试定规矩，测试给 SQA 交数据。

**【思政落点 49】** 讲什么故事：课件特意强调 SQA 要"督促测试工作的结果客观、准确和有效"，这句话说的是监督，落点其实是诚信。怎么联系知识点：测试向 SQA 提供质量评价的客观依据，数据一旦被修饰，整个质量判断就失去意义。落到什么价值观：真实是质量工作的生命线。企业里为了过一个质量门而修改测试结论、遮掩失败用例，短期看是"顺利交付"，长期看是拿用户和公司信誉做赌注。我们做课程设计也一样，测出来的问题如实写、测不到的地方如实标明范围，这才是合格的工程素养。

**过渡**：说清了测试和质量保证的关系，还有一个关系同样重要，而且更贴近日常——测试和开发的关系。

### 【1.50】1.5 测试与开发的关系（2 分钟）

> **口播**：这一页进入 1.5 节，标题是测试与开发的关系。同样先放一张图，把这一节的问题摆出来。为什么这个关系也值得单独讲一节？因为它直接决定测试在项目里被摆在什么位置。在不少团队和不少人的直觉里，开发是"造东西的"，测试是"检查东西的"，造完了才轮到检查，所以测试天然排在开发后面。这种想法听起来很自然，实际代价非常大：测试时间被排在最后，一旦前面延期，被压缩的永远是测试；缺陷暴露得晚，返工成本高；测试成了"把关的唯一一道墙"，压力大、效果差。这一节要纠正的就是这个排序。课件备注里仍然是刚才 1.3 节的四个小节作为回顾，说明现在我们正式转入 1.5。本节接下来用两页来对照：第一页讲"测试不是开发下一道工序"，把传统的那条串联链摆出来，让大家看清它的危害；第二页讲"测试与开发是并行、协作的关系"，给出正确的组织方式。这两页合起来，也是本课程后面很多内容的思想基础——比如为什么要有测试左移，为什么单元测试要由开发来写，为什么缺陷修复过程需要开发与测试反复沟通。请大家带着一个问题听：如果测试不是最后一道工序，那它在需求阶段、设计阶段应该做什么？这个问题在第 52 页会给出答案。最后还要纠一个态度：这一节不是要否定开发，也不是要把测试抬到开发之上，而是纠正一种排序。开发和测试是同一支队伍里的两种专业能力，没有谁比谁低一等，谁先谁后也不是身份问题，而是时机问题。

**板书**：1.5 测试与开发的关系 → 传统直觉：开发造、测试查，测试排最后 → 代价：时间被挤、缺陷晚暴露、返工大 → 本节两问：测试是下一道工序吗？测试与开发该是什么关系？→ 回顾：1.3.1—1.3.4

**提问**：回想一下你做过的课程项目或小组作业，测试是安排在哪一步做的？结果如何？

**预设回答**：①答"最后交之前随便点几下"——非常真实，也是本页要打的靶子。教师点评：不要批评，先问"那几次点出来的问题好改吗"，多数学生会说难改，因为结构已经定了。②答"边写边测"——好回答。教师点评：这正是第 52 页要讲的并行协作，可以先表扬并让他说明具体做法。③答"我们分工，有人专门测"——这是"流程上的顺序"和"人员上的分工"混在一起了。教师追问：专门测的那个人，是从需求阶段就参与，还是等着代码写完才开始？把混点拆开，学生才能分清"角色分工"和"阶段排序"是两回事。

**易错点 / 考点**：第一，把"并行协作"当成口号，答不出在哪些阶段交换哪些信息；第二，把"测试不是下一道工序"理解成"测试不必在开发之后执行"，把介入时机和执行时机混为一谈；第三，误以为测试左移就是要测试人员去替开发写代码。判断口诀：活动提前介入、执行按版本推进、责任团队共担。

**过渡**：先看最常见、也最需要纠正的那张图——把测试当成开发的下一道工序。

### 【1.51】测试不是开发下一道工序（3 分钟）

> **口播**：这一页只有一条链：需求定义、设计、编程、测试、交付，五个方框一字排开。大家注意，这条链本身没有错——从时间上看，需求确实在设计和编程之前，代码确实在测试之前。它错在哪？错在我们把它理解成"做完上一格才能进下一格，做完就没我的事了"。这条链最大的问题是可以被读成一条流水线：需求分析员交需求，设计师交设计，程序员交代码，测试员交测试报告，然后交付。每一格都只管自己那一环，前一格交出去就结束。这在软件里会带来三个后果。第一个后果，缺陷发现得晚。需求里的一处含糊、设计里的一处接口不一致，一路上没人质疑，一直走到测试阶段才被发现，这时候要改的东西已经扩散到设计、代码、数据、文档。第二个后果，返工量成倍放大。经济视角那一页我们讲过：发现越早，返工越小。第三个后果，最实际——测试时间被压到最短。因为它在链条末端，前面每一格延期都会吃掉它的时间，而它又是最后一格，没有地方可以再往后推，于是只能压缩用例、压缩回归、压缩环境准备，最后连"测完"都做不到。真实世界里的教训不少。据本课程案例素材，波音星际客机的软件问题，反映出的就是测试被拆散、端到端验证不足；更早的火星探测器事故，则与模块接口没有做充分的集成测试有关。这些事故的共性不是"程序没写出来"，而是"没有人从整体上验证它"。所以这一页要建立的观念是：这条链描述的是**工作产品的依赖顺序**，不是**人员的篱笆**。你可以按顺序产出需求、设计、代码，但测试的思维和活动必须提前介入，从需求阶段就盯着每一样工作产品的质量。有同学会问：那测试到底放在哪？答案是：测试无处不在，下一张图会讲清楚。

**板书**：传统串联链：需求定义 → 设计 → 编程 → 测试 → 交付 → 误读＝"做完上一格就没我的事" → 三后果：①缺陷发现晚 ②返工成倍放大 ③测试时间被压缩（末位、无路可退）→ 案例：系统集成与端到端验证不足引发事故 → 正解：这是工作产品的依赖顺序，不是人员的篱笆

**提问**：为什么这条链上最容易"牺牲"的总是测试？如果不想被牺牲，测试应该在前面做哪些事？

**预设回答**：①答"因为它在最后，没有下游可以顺延"——准确。教师点评：这句话点出了排程上的本质，写进板书。②答"因为测试不重要"——错误但值得讨论。教师追问：如果测试不重要，为什么出了线上事故大家第一个问的是"测了没有"？引导学生发现：说它不重要，只是因为它"看起来不产出功能"。③答"前面做需求评审和设计评审，把问题提前拦下来"——很好的回答。教师点评：这正是测试左移，可以顺势让大家举一个"需求评审里发现的问题"的例子，把抽象概念落到自己的项目上。

**易错点 / 考点**：第一，把"测试不是下一道工序"误读成"测试不需要在开发之后进行"——测试的执行确实在产品可用之后，但测试的介入必须提前，这是两件事。第二，考试里常把"测试是开发完成后的最后一个阶段"当作正确说法，这是典型的错误选项。第三，写文档时把测试计划安排在编码结束后才启动，属于实践扣分点。判断三步法：问顺序（时间上有先后，正常）→ 问介入（活动是否提前，必须提前）→ 问人员（是不是各扫门前雪，不能）。

**过渡**：既然不该是一条单向流水线，那测试和开发到底该怎么排、怎么配合？最后一张图给出答案。

### 【1.52】测试与开发是并行、协作的关系（3 分钟）

> **口播**：这一页是 1.5 节的结论：测试与开发是并行、协作的关系。这张图要大家看出的，是两条轨道同时向前推进，并且在每个节点上都在交换信息。我们把"并行"和"协作"分开讲。先说并行。并行指的是测试活动和开发活动在时间上重叠，而不是一前一后排队。怎么重叠？需求阶段，测试人员就参与需求评审，专门盯那几个问题：这条需求能不能验证？验收标准写清楚了吗？有没有互相矛盾或者含糊的地方？这些正是后面写用例的依据。设计阶段，测试人员参与设计评审，关注接口约定、异常处理、数据边界，同时开始做测试需求分析和测试计划。编码阶段，开发人员自己写单元测试，测试人员准备测试数据和用例，双方对接口契约达成一致，甚至可以先把接口的测试用例冻结下来，等实现完成就能马上开跑。到了系统测试和验收阶段，测试人员主导，开发人员待命修缺陷，缺陷修复后由测试人员回归验证，形成闭环。再说协作。协作的意思不是"客气"，而是双方对同一个目标负责。测试人员不是来挑刺的，他的产出是质量信息，帮团队在交付前发现问题；开发人员也不是把代码一丢就完事，他要提供可测的版本、清楚的变更说明、真实的环境和日志。落到具体做法上有几条特别实用：一是缺陷报告要写得能被复现——步骤、数据、环境、期望与实际，缺一样开发就要来回问；二是修复后要说明影响范围，方便测试判断回归哪些用例；三是遇到需求歧义，一起找产品确认，而不是互相赌气。这套并行协作的机制，业内常叫测试左移和持续反馈，前面 1.3.4 风险视角里那句"持续反馈质量风险"讲的就是它。给大家一句话总结：开发和测试不是接力赛的上下两棒，而是同一辆车上的两个仪表——一个负责把车开起来，一个负责告诉你车况怎么样；只有并排看着同一块路，才知道什么时候该踩刹车。这也正是我们课程设计里要求团队协作、要求测试与开发文档互相配套的原因。

**板书**：测试与开发＝并行 + 协作 → 并行：需求评审介入（可验证性/验收标准）→ 设计评审介入（接口、异常、边界）→ 编码期：单元测试 + 用例与数据准备 + 冻结接口契约 → 系统/验收：测试主导，开发修复，回归闭环 → 协作：缺陷可复现、变更讲影响、歧义一起找产品 → 关键词：测试左移、持续反馈

**提问**：测试左移最直接的好处是什么？请从"缺陷的引入阶段"和"修复成本"两个角度各说一句。

**预设回答**：①答"越早发现问题，改动越小、成本越低"——正确，覆盖了成本角度。教师点评：再补一句引入阶段的角度——在需求阶段拦下一个歧义，等于同时拦住了由这个歧义派生出的设计错误、代码错误和一批用例。②答"测试人员可以早点开始写用例，后面轻松点"——只说到进度，没说质量。教师追问：如果测试人员只是在旁边写用例，不提需求问题，算不算左移？引导学生区分"提前干活"和"提前发现问题"。③答"左移就是让开发多写代码少测试"——方向反了。教师点评：左移不但不减测试，反而让开发承担更多的验证责任（比如单元测试），是总量增加、位置前移。

**易错点 / 考点**：第一，把"并行"理解成"同时开始、各干各的"，漏掉"协作"和信息交换这一半。第二，认为测试左移就是"测试提前介入执行"，忽略了需求与设计评审阶段的介入形式。第三，判断题常见"开发和测试是两个独立的、互不干涉的阶段"——错误；"测试人员只对产品负责，不对流程负责"——也不准确，因为测试结果同时是 SQA 评价流程的依据。记忆口诀：并行不排队，协作不甩锅；左移一步，省下十倍。

**【思政落点 52】** 讲什么故事：这一页讲协作，最能体现一个团队的质量文化。怎么联系知识点：测试与开发并行协作，意味着缺陷信息要如实、及时地在两边流动，谁的锅先放一边，先把问题解决。落到什么价值观：软件是集体作品，推责比缺陷更伤人。开发对测试隐瞒改动、测试对开发夸大问题，都会让团队失去互信；反过来，把"我们一起把这个缺陷解决掉"当成默认姿态，团队的质量水平和交付能力都会上一个台阶——这也是本课程团队协作与工程表达能力这一目标想训练的东西。

**过渡**：到这里，第 1 章关于"测试是什么、为什么必须测、测试与质量保证是什么关系、测试与开发是什么关系"的讨论就讲完了。下面我们把镜头拉近，进入软件测试的基本概念——测试的分类与级别、静态测试与动态测试、黑盒白盒与灰盒，看看一次具体的测试工作到底是怎么分类、怎么分层展开的。