### 【1.1】软件测试方法和技术（2 分钟）

> **口播**：同学们好，欢迎来到《软件测试课程设计》。我是这门课的任课老师周宇文。这门课的教材是朱少民老师主编、清华大学出版社 2022 年出版的《软件测试方法和技术（第 4 版）》。先交个底：这是专业选修课，32 学时、2 学分，理论 16 学时加实验 16 学时，一半时间讲原理，一半时间在机房动手。考核方式是考查，看平时的过程性表现，加上最后的课程设计作品与答辩。今天先不急着学工具，我们回答一个最根本的问题——软件为什么要测？不测会怎样？把这个问题想明白，后面所有方法才有落脚点。

**板书**：课程名 → 教材＝朱少民《软件测试方法和技术（第4版）》清华 2022 → 32学时（理论16＋实验16）→ 考查（过程性＋作品答辩）

**提问**：你们觉得，一个软件完全不测试就上线，最坏会发生什么？

**预设回答**：①"大不了不好用，用户骂两句"——这是最典型的低估，我会追问：如果它管的是钱、是电、是医疗设备呢？②"会崩溃、会赔钱"——方向对但太笼统，要求他说清"哪一类损失、谁来承担"。③"现在都敏捷了，边开发边测，不用专门测"——这句话先记在黑板上，讲到敏捷那一页再回来算账。

**易错点 / 考点**：最常见的错，是把软件测试等同于"点点鼠标看有没有报错"。记三句话：测试是有理论、有方法、有流程的学科；测试的目标是发现缺陷、提供质量信息，不是证明软件是对的；测试不是开发之后的收尾工序。判断三步法：一问测什么（对象与范围），二问谁来测、何时测（主体与时机），三问测到什么程度算完（准则）。

**过渡**：坐标定下来了。接下来看一张图，它会告诉我们：软件测试这座山，到底是什么形状。

### 【1.2】软件测试全景图（3 分钟）

> **口播**：这张图叫"软件测试全景图"。它不是让大家背的，而是要在脑子里建一张地图。所谓全景图，就是把和软件测试有关的东西按几个维度铺开。横着看，是软件的生命周期：需求、设计、编码、集成、部署、运维，测试在每个阶段都有自己的活儿。竖着看，是测试的不同层次：单元测试、集成测试、系统测试、验收测试。再往里看，是测试的类型与方法：功能、性能、安全、兼容性、易用性，以及黑盒方法、白盒方法。最后还有一列是支撑体系：测试流程与规范、测试管理、缺陷跟踪、自动化工具。为什么先看这张图？因为新手最常犯的错，是手里只有一把锤子，就把所有东西都当钉子——只学一种方法，什么问题都拿它去套。有了全景图，你才知道自己站在哪儿，手上这把工具适合解决哪一类问题。打个比方，这就像去医院：全景图告诉你有内科、外科、影像科、检验科，你挂号之前得先知道自己大概是什么毛病。软件也一样，性能问题拿功能用例去测，是永远测不出来的。

**板书**：画一张四层图 → ①生命周期（需求→设计→编码→集成→部署→运维）②测试层次（单元→集成→系统→验收）③类型方法（功能/性能/安全/兼容/易用＋黑盒/白盒）④支撑（流程规范→管理→缺陷跟踪→自动化工具）

**提问**：如果用户投诉"这个 App 一到晚上八点就卡"，按全景图，你该去哪个格子找工具？

**预设回答**：①"找功能测试"——错，功能测试看的是"做得对不对"，不看"快不快"，我会引导他往性能格子走；②"找性能测试"——对，但要追问：是响应时间、吞吐量还是并发用户数的问题？③还有同学会说"先看看是不是网络问题"——这个思路很好，说明他有了分层排查的意识，可以表扬并补一句：先用监控确认瓶颈在客户端、网络还是服务端，再选工具。

**易错点 / 考点**：容易混的是"层次"和"类型"——层次回答"在哪一级测"，类型回答"测什么属性"。判断题常考"性能测试属于系统测试阶段"这类说法，要按"层次＋类型"两个坐标分别作答。

**过渡**：地图看完了，我们把镜头拉近：这张地图上的那些词，彼此是什么关系？

### 【1.3】系统地理解软件测试（4 分钟）

> **口播**：这一页请大家跟着我一起看，标题叫"系统地理解软件测试"。图上有二十来个词：软件、质量、缺陷、测试、目标、测试用例、方法、设计、实施、发现、清除、阶段、管理、思想、源泉、确定、寻求、指导。看着散，其实是一条完整的逻辑链。第一，测试的对象是"软件"，追求的是"质量"，所以质量是整套活动的目标；没有质量这个目标，测试就变成"为测而测"。第二，质量的敌人是"缺陷"，缺陷就是测试直接要对付的东西——做测试，本质上就是找缺陷、报缺陷、推动清除。第三，"源泉"和"确定"回答的是测试从哪里开始：测试的源泉是需求与用户期望，需求不确定，测试就无从下手，所以测试要尽早介入，先把"测什么"确定下来。第四，"寻求""设计""方法""测试用例"是一条技术链：先寻求怎么测，再设计测试用例，再选合适的方法，用例是这件工作的核心产物。第五，"实施""发现""清除"是执行链：把用例跑起来，发现缺陷，推动清除。第六，"阶段""管理""思想""指导"是保障链：测试要分阶段推进，要靠管理组织资源、进度和缺陷，还要靠测试思想来指导决策。再打个比方，这整张图就像看病：目的是健康，也就是质量；症状是发烧，也就是缺陷；你不能看一眼就开药，得先问诊、验血、拍片，这就是分析与用例设计；确诊后治疗是清除缺陷，康复靠作息管理就是阶段与管理。放到软件行业里，拿一个登录功能说：需求写着"手机号加验证码可以登录"，这是源泉；用例要覆盖正常登录、验证码错误、账号被锁、网络中断、重复点击，这是设计；每个异常都要记成缺陷单、跟踪到关闭，这是管理与执行。所以一句话口诀：目标管质量，对象抓缺陷，源泉看需求，核心是用例，落地靠执行，保障靠管理和思想。

**板书**：质量（目标）→ 缺陷（对象）→ 需求（源泉）→ 用例（核心）→ 方法/设计（怎么测）→ 实施/发现/清除（执行）→ 阶段/管理/思想（保障）

**提问**：请用一句话说说，"缺陷"和"测试用例"是什么关系？

**预设回答**：①"用例是用来找缺陷的"——对，但不够深，我会补充：用例是把"希望发现的缺陷"提前翻译成可执行步骤；②"用例就是操作步骤"——典型的窄化，要提醒用例还必须写明前置条件、输入数据、预期结果和判定准则；③有同学会说"没有预期结果就不算用例"——这句很到位，可以顺势强调：没有预期结果，就无法判断实际结果是"对"还是"错"。

**易错点 / 考点**：这一页最爱考"关系"而不是"定义"。记住一条主线：需求是源泉，用例是核心，缺陷是对象，质量是目标。选择题常把"测试的目的是证明软件没有缺陷"当干扰项，这句话是错的——测试只能证明缺陷存在，不能证明缺陷不存在。

**【思政落点 1】**：这二十来个词里，"清除"两个字最见职业底线。找缺陷是技术活，报缺陷是良心活。行业里有真实教训：发现缺陷却因为怕影响绩效、怕得罪人而选择隐瞒，最后问题流到用户手上，代价由公众承担。请同学们记住——测试人员手里握着的是别人看不见的风险，如实记录、不隐去不利结果，是这个岗位的第一条职业底线，也是一名工程师对国家、对社会负责的起点。

**过渡**：原理讲完了，大家可能更关心一个现实问题：学这个，将来干什么？我们看两张招聘市场的图。

### 【1.4】从就业市场看软件测试（3 分钟）

> **口播**：这一页是两张图，都来自招聘市场。第一张是岗位与需求分布，第二张是岗位要求里的技能关键词。据课件数据，招聘平台上与软件测试相关的岗位长期保持稳定需求，测试工程师、自动化测试工程师、测试开发工程师是三类最常见的职位名称。请大家重点看第二张图里的技能词：功能测试、用例设计、缺陷管理、数据库、接口测试、性能测试、自动化脚本、Linux、Python 或 Java。有没有发现？这些词跟咱们这门课的大纲几乎一一对应——用例设计、缺陷管理、接口测试、性能测试、自动化工具，后面都会讲到。为什么要先看就业？因为学习最怕"不知道学了有什么用"。这张图告诉大家：测试不是"点鼠标的岗位"，而是一个有明确能力栈的岗位。招聘方要的不是"你会不会用某个工具"，而是"你能不能分析需求、设计用例、定位问题、说清缺陷并推动它被修掉"。把这张图记在心里，以后每学一个方法，都问自己一句：这一条能不能写进简历，能不能在面试里讲出一个具体例子？

**板书**：三类岗位（测试工程师／自动化测试／测试开发）→ 技能栈：功能测试·用例设计·缺陷管理·数据库·接口测试·性能测试·自动化脚本·Linux·Python/Java

**提问**：招聘要求里为什么不直接写"会用某某工具"，而写"用例设计能力"？

**预设回答**：①"工具学得快，能力难练"——很准，工具两星期能上手，设计思维要一学期；②"工具会过时"——也对，方向一致；③"因为公司用的工具各不相同"——这是最实在的回答，正好引出结论：工具是载体，方法是本事；方法迁移得走，工具只是脚手架。

**易错点 / 考点**：别把"软件测试"理解成"软件测试工具"。考试如果问"测试工程师最核心的能力是什么"，落在"测试分析与用例设计"上，而不是某个工具的操作步骤。

**过渡**：既然岗位在变，那今天的行业跟十年前比，到底变了什么？我们看敏捷时代这一页。

### 【1.5】在敏捷时代，如何看待软件测试？（3 分钟）

> **口播**：这一页标题是个问题：敏捷时代，怎么看待软件测试？课件给了五条判断，我逐条讲。第一条，敏捷开发模式提倡整个团队对质量、对测试负责。注意这句话的分量——测试不再是"测试组的事"，产品、开发、测试都得为质量签字。第二条，开发与测试越来越融合，比如课件提到的微软测试人员转型：过去微软有庞大的专职测试岗，后来大量测试岗位被并入开发角色，测试能力变成开发者的基本功。第三条，持续交付倒逼持续测试，但测试最容易成为瓶颈。为什么？因为代码一天能集成十次，自动化测试要是跑一次要两个小时，交付就被卡住了。这就像高速公路：路修得再宽，收费站只有一个窗口，车照样堵。第四条，测试左移、测试前移，让开发做更多的测试——把缺陷拦在需求和设计阶段，越早越便宜。第五条，测试驱动开发，英文缩写 TDD：测试在前、开发在后，先写测试再写实现。这里再补一个生活化的类比：敏捷时代的质量，就像一支球队的防守——不是后卫一个人的事，前锋也要回防，教练也要布阵；如果大家都觉得"丢球是后卫的问题"，这支球队一定丢球。软件行业里还有一个很典型的现象：很多团队每天多次把代码合并到主干，每次合并都会自动触发一轮测试，谁把测试跑红了，谁就得马上修，绝不允许红色状态过夜。这就是"持续测试"的真实样子——测试不是一道关卡，而是开发流水线上的传送带。所以课件才提醒我们：这条路最怕的就是瓶颈。一旦自动化测试跑得比开发还慢，团队就会开始"绕过测试"，而一旦绕过，质量就会以看不见的方式持续下滑。大家把这一页记成一句：质量是全员责任，测试要与开发并行，而不是排在开发后面。

**板书**：①全员质量责任 ②开发测试融合（微软测试转型）③持续交付→持续测试（瓶颈风险）④测试左移/前移 ⑤TDD：测试在前、开发在后

**提问**：为什么说"测试最容易成为瓶颈"？如果你们团队的自动化测试要跑两个小时，你会怎么改？

**预设回答**：①"因为测试最慢"——太表面，我会追问慢在哪里；②"因为每次提交都要跑全量测试"——这就说到点子上了：可以分层，提交时跑冒烟与单元测试，夜间跑全量与性能；③"可以并行、可以分布式跑"——也对，属于工程手段；④有同学说"那就少测一点吧"——这是危险回答，绝不能靠减少测试来提速度，要换成"提高测试的性价比"，说清哪一层该测什么。

**易错点 / 考点**：TDD 的顺序一定要记准——先写测试，再写实现，最后重构；顺序反了就变成"补测试"。判断题常把"测试左移"错误理解为"把测试人员提前招进来"，左移的核心是测试活动在时间轴上向前移，测试人员更早介入需求与设计。

**过渡**：讲到这里，有位同学可能会想：那我这门课到底是要背概念，还是要练本事？下面两页，一页讲能力，一页讲方法。

### 【1.6】如何借助这门课培养学生的分析问题和解决问题的能力？（3 分钟）

> **口播**：这一页的问题很直接：这门课怎么培养大家分析问题和解决问题的能力？课件给了三个抓手。第一个抓手是"强调分析能力，测试分析是基础"。请注意，测试分析是基础——拿到一个功能，先要分析它有哪些输入、哪些分支、哪些边界、哪些异常，分析不清楚，用例就只能靠拍脑袋。第二个抓手是"批判性思维，比如探索式测试"。探索式测试要求你一边学习系统、一边设计用例、一边执行、一边根据结果调整下一步——它不相信"需求写完就万事大吉"，而是主动去质疑："这里是不是有问题？"第三个抓手是"工程思维，找到不同的解决方案，从中选出最优的"。这句话是这门课的灵魂：现实中的测试问题，从来没有唯一解。时间有限、人手有限，你是全量回归，还是按风险挑重点回归？这不是聪明不聪明的问题，是工程权衡的问题。举个生活中的类比：装修房子，预算和工期都有限，你是全屋精装还是先把水电做好？会算账的人，才是好工程师。那批判性思维怎么练？就是刚才说的探索式测试，它不是"随便点点"，而是带着问题去试探系统：先花二十分钟熟悉功能，再列出一批"我怀疑会出问题"的点，比如改价格后再改数量、优惠券和积分同时用、页面刷新一半就断网，然后一边试一边记录，试完复盘的发现又变成新的怀疑。这个过程就像侦探查案——不是等案情自己送上门，而是主动去找矛盾之处。工程思维又怎么练？还是拿购物车举例：如果测试时间只够覆盖一半功能，你是按页面从头测到尾，还是先把"下单、支付、退款"这条主链路测透？成熟的答案一定是后者，因为主链路出错的代价最大。这就是风险驱动：把有限的测试资源，压在出错代价最高的地方。我们这门课的实验和作业，都会逼着大家做这种权衡，并说明你权衡的理由。

**板书**：分析能力（测试分析是基础）→ 批判性思维（探索式测试）→ 工程思维（多方案比较→选最优，并说明理由）

**提问**：同一条需求，张三设计了 8 条用例，李四设计了 30 条。谁的测试更好？

**预设回答**：①"李四更全面"——这是最常见的直觉，我会反问：如果上线时间只剩两小时，30 条跑得完吗？②"张三更好，因为效率高"——也未必，如果那 8 条漏掉了核心分支，效率就是假效率；③比较理想的回答是"要看覆盖了什么，而不是看数量"——这就讲到关键：用覆盖率和风险来评价，而不是用条数。顺势提醒：用例数量不是绩效，漏测才是事故。

**易错点 / 考点**：别把"探索式测试"当成"随便点点"。它是有方法、有记录、有章程的：先明确测试目标与时间盒，边测边记，事后复盘并沉淀为可复用的用例。简答题若问"分析能力与工程思维的区别"，答：分析能力解决"有哪些问题要测"，工程思维解决"在约束下先测哪些、怎么测最划算"。

**过渡**：能力怎么练出来？光靠听讲不行，得动手。下一页讲实验教学。

### 【1.7】如何通过实验教学培养学生的实际能力？（3 分钟）

> **口播**：这一页讲实验。课件第一句就说：软件测试是一门实践性很强的课程。这句话不是套话——你可以把等价类划分的定义背得滚瓜烂熟，但面对一个真实的登录页面，你还是会漏掉手机号带空格、密码含中文、验证码过期这些情况。所以这门课的方法是"做中学"：听一遍，不如自己做一遍。课件还给了两条方法：问题驱动教学与实验；实验就是分析问题、解决问题的过程。什么是问题驱动？就是先给你一个"跑不通""算不对""会崩"的现象，然后你自己去定位：是环境问题、数据问题，还是程序逻辑问题。这个过程跟将来上班是一模一样的——领导给你一个 bug 单，上面只有一句"用户反馈下不了单"，剩下的全靠你自己查。其实道理跟学游泳、学开车一样：教练讲一百遍换气和打方向盘都没用，你得自己下水、自己上路；而实验课就是你们的泳池和练车场，在这里犯错不要钱，在工作里犯错很贵。软件行业里有个很朴素的经验：同一个缺陷，在需求评审时发现，改一句话；在设计阶段发现，改一段设计；在编码阶段发现，改几行代码；上线之后才发现，就要改代码、改数据、发版本、安抚用户，甚至上门道歉——越往后越贵。所以我们做实验，练的不只是"会不会用工具"，而是在练"我能多早发现它"。我给大家一个忠告：实验课别抄步骤、别只截图。真正长本事的是三件事——第一，把现象记录清楚（什么环境、什么数据、怎么操作、出现什么）；第二，把猜想和验证过程写下来，哪怕猜错了也写；第三，把结论沉淀成可复用的用例或检查清单。这门课的平时分，很大一部分就看这三件事做得实不实。

**板书**：做中学 → 问题驱动（给现象，找原因）→ 实验＝分析问题＋解决问题 → 记录三件事：现象/环境/数据、猜想与验证、沉淀用例清单

**提问**：实验报告里只写"运行成功，结果正确"，为什么拿不到高分？

**预设回答**：①"因为没分析"——对；②"因为没有记录过程"——也对；③"因为不知道他到底测了什么数据"——这正是关键：没有输入数据和预期结果，这份报告无法被复现，也就无法被信任。补一句：可复现是测试报告的生命线。

**易错点 / 考点**：常考"缺陷报告必备要素"：环境、版本、前置条件、操作步骤、实际结果、预期结果、复现概率、附件证据。判断三步法：别人按你写的步骤能不能复现？缺陷能不能被定位？不写预期结果的报告，等于没写。

**过渡**：方法有了，那这门课用什么教材、学哪几块内容？我们看下一页。

### 【1.8】《软件测试方法和技术》（3 分钟）

> **口播**：介绍一下我们手里的这本教材。据课件数据，这本书 2005 年出版，现在是第 4 版，是"十一五""十二五"国家级规划教材，也是上海市普通高校优秀教材；有 300 多所大学在使用，销量超过 20 万册，并连续三年获得清华大学出版社畅销书奖。这几个数字说明什么？说明它是一本被长期验证过的教材，不是速成手册。再看结构，本书共分三篇：第一篇"软件测试的原理与方法"，第二篇"软件测试技术"，第三篇"软件测试项目实践"。这个三篇结构其实对应了我们学习的三个阶段：先懂原理（知道为什么这么测），再学技术（知道用什么工具、什么方法测），最后做项目（在真实的约束下把前面学的用起来）。所以大家在读这本书的时候，不要一上来就跳到工具章节，工具是学得最快的，原理才是决定你上限的东西。这个三篇结构，很像医学院的培养路径：第一篇是基础医学，教你人体是怎么运转的；第二篇是临床技术，教你怎么用各种仪器去查、去治；第三篇是临床实习，把你扔到真实的病人面前做判断。没有第一篇，你看到症状只会乱开药；没有第三篇，你背再多书也不敢上手术台。我们这门课同样如此：第 3 章的方法如果脱离了原理，就会变成"照着公式套用例"；而课程设计如果不动手，你也永远不知道真实的软件有多不听话。所以我的建议是，读教材的时候手里要有三支笔：第一支划概念，第二支记工具怎么用，第三支写"这个方法在什么场景下会失效"。第三支笔最重要，因为任何测试方法都有它测不到的东西，知道边界，才知道什么时候该换方法。也提醒一句：教材第 4 版跟我们这门课的课件是对齐的，课后作业里出现的概念，都能在书上找到出处，遇到不懂的先翻书，再问老师。

**板书**：2005 年首版 → 第 4 版（2022）→ 国家级规划教材·上海市优秀教材 → 300+ 所高校使用·销量 20 万册+·连续三年清华畅销书奖 → 三篇：原理与方法｜技术｜项目实践

**提问**：为什么教材要分成"原理与方法""技术""项目实践"三篇，而不是直接把工具从第一页讲到最后一页？

**预设回答**：①"因为要先懂原理"——对；②"因为技术会过时，原理不会"——这个回答很成熟，可以表扬；③"因为最后要做项目"——也对：知识只有在项目里被串起来才会变成能力。可以把三种回答合成一句：原理决定你会不会想，技术决定你会不会做，项目决定你能不能交付。

**易错点 / 考点**：注意区分"教材版本"与"课程课时"这类事实性信息，别把第 4 版记成第 3 版，也别把 32 学时记成 64 学时。客观题常考教材结构与出版信息，记住"三篇"和"2022 年第 4 版"。

**过渡**：三篇里我们最先进入的是第一篇。第一篇包含哪四章？看下一页。

### 【1.9】第1篇 软件测试的原理与方法（2 分钟）

> **口播**：这是第一篇的目录页，包含四章。第 1 章"引论"，也就是我们今天开始讲的内容，回答的是"为什么必须测、什么是测试"这些根本问题；第 2 章"软件测试的基本概念"，把测试的分类、级别、静态与动态、黑盒与白盒这些概念系统化；第 3 章"软件测试方法"，进入具体方法：等价类划分、边界值分析、判定表、因果图、路径覆盖等等；第 4 章"软件测试流程和规范"，讲测试怎么在团队里组织起来，从测试计划、测试设计到缺陷管理、测试报告。大家注意这个顺序：先讲必要性（为什么），再讲概念（是什么），再讲方法（怎么做），最后讲流程（怎么组织起来做）。这是一条从"想明白"到"做得对"再到"做得稳"的路线。很多同学做课程设计时最痛苦的不是不会用工具，而是不知道从哪儿下手，根源就是跳过了前两章。所以第一篇这四章，请务必跟着走扎实。

**板书**：第1篇 ＝ 第1章 引论（为什么）→ 第2章 基本概念（是什么）→ 第3章 测试方法（怎么做）→ 第4章 流程和规范（怎么组织）

**提问**：为什么"流程和规范"要放在"方法"之后讲，而不是一开始就讲？

**预设回答**：①"因为要先会方法才知道流程管什么"——很到位；②"因为流程是给团队用的"——也有道理，个人可以先会方法，团队才需要流程；③"因为流程不重要，可以最后看"——要纠正：流程不是不重要，而是它依赖于方法；没有方法的流程只是一堆表格。

**易错点 / 考点**：常考"四章的顺序与各自主题"的对应关系。记忆口诀：一论（引论）二概（概念）三法（方法）四流程。

**过渡**：好，教材结构清楚了，我们正式进入第 1 章。

### 【1.10】软件测试方法和技术（2 分钟）

> **口播**：翻到这一页，我们正式进入第 1 章"引论"。这一章在整个课程里的位置，相当于盖房子的地基。它不教你某个具体的用例设计技巧，而是回答三个问题：第一，为什么必须做软件测试——用真实事故说话；第二，什么是软件测试——把它作为一个学科来定义；第三，测试和质量保证、和开发到底是什么关系。这三问答不清楚，后面学得越多越乱：你会把测试当成开发的附属品，会把质量保证和测试混为一谈，也会在执行时失去判断标准。所以接下来这一章，我会带着大家看一批真实案例，每个案例都问一句：如果当时有规范的测试，哪些问题本来可以被提前发现？请大家带着这个问题听。

**板书**：第 1 章 引论 → 三问：为什么必须测／什么是测试／测试与质保、开发的关系

**提问**：如果让你只用一个词概括第 1 章的主题，你选哪个词？

**预设回答**：①"定义"——只答对了一半，定义只是其中一问；②"案例"——案例是手段不是主题；③"必要性"——这个最贴切，第 1 章的主线就是回答"为什么非测不可"。

**易错点 / 考点**：第 1 章的考点集中在"测试的必要性""测试的定义""测试与调试、质量保证的区别"三处。注意"测试≠调试"：调试是定位并修复缺陷的开发活动，测试是发现缺陷、提供质量信息的活动。

**过渡**：第 1 章要讲哪六节？我们看全章目录。

### 【1.11】1.1 软件测试的必要性（3 分钟）

> **口播**：这是第 1 章的目录，一共六节：1.1 软件测试的必要性；1.2 为什么要进行软件测试；1.3 什么是软件测试；1.4 测试和质量保证的关系；1.5 测试和开发的关系；1.6 测试驱动开发的思想。请特别注意 1.1，它下面挂着一串案例：迪斯尼的多媒体游戏、一个缺陷造成数亿美元损失、火星探测飞船坠毁、软件测试走捷径导致灾难再次发生、错误指令造成骑士资本集团损失（课件数据为 4.4 亿美元）、AWS 宕机整整 4 个小时、预定的酒店住不进去露宿街头、Uber 泄漏个人隐私导致用户要求赔偿 3 亿多元，还有更多悲剧。我先把这一串名字报出来，大家不要急着记数字，先记住一件事：这些不是故事会，而是我们这门课的"病历本"。每看完一个案例，我都要问你们一句——这件事如果放在今天，用我们后面要学的方法，能不能提前发现？

**板书**：1.1 必要性｜1.2 为什么测｜1.3 什么是测试｜1.4 测试与质量保证｜1.5 测试与开发｜1.6 TDD → 1.1 案例串：迪斯尼·奔腾缺陷·火星飞船·捷径重演·骑士资本·AWS 宕机·酒店预订·Uber 隐私

**提问**：这些事故来自游戏、芯片、航天、金融、云计算、出行、酒店等完全不同的行业，它们的共同点是什么？

**预设回答**：①"都是软件出问题"——太笼统；②"都造成了很大损失"——对，但还要再进一步；③"共同点是：缺陷已经流到了用户端才被发现"——这个回答最好，正好点出测试的价值：把发现缺陷的时点往前移。

**易错点 / 考点**：容易把"缺陷"和"故障"混着用。缺陷是软件中存在的问题，故障是缺陷被触发后表现出来的异常。案例题答题模板：现象→影响范围→根因（哪一类缺陷）→如果做了哪一级测试可以拦截。

**过渡**：案例从哪里讲起？我们先看 1.1 这一节的开篇。

### 【1.12】1.1 软件测试的必要性（2 分钟）

> **口播**：这是 1.1 节的开篇页。按课件的说明，这一节要先列写本课时的学习要点，再依次深入讲解；如果有学习要求，就写在要点之后。课件还给了我们讲每一节要走的六个动作：讲概念——这个概念是什么，工作中什么场景会用到；讲讲解——要胜任这个能力，需要掌握哪些知识和技术；举例子——用一个案例或一个演示帮大家真正看懂怎么用；分享经验——特别是理论和实际有差异的地方；给学习建议——告诉大家在真实学习或工作场景里可以怎么用；提供实用工具——这一节对应的工具或模板。请大家把这六个动作记成一条学习路径：概念→知识→案例→经验→建议→工具。这也是我要求你们做课程设计时的顺序：先弄明白要解决什么问题，再选方法，再动手，最后沉淀成模板。接下来的 1.1.1，我们就从第一个案例开始。

**板书**：六步学习路径：概念（什么场景用）→ 知识技术（要会什么）→ 案例/demo（怎么用）→ 经验分享（理论与实际的差）→ 学习建议 → 实用工具/模板

**提问**：为什么课件要把"经验分享——理论和实际的差异"单独列成一个动作？

**预设回答**：①"因为实际比理论复杂"——对，这是核心；②"因为书上写的做不到"——过于绝对，应该说"现实中要受时间、人力、环境的约束"；③"因为老师有工作经验"——也算一个原因，但重点不在老师，而在你们将来要面对的取舍。

**易错点 / 考点**：常考"学习方法论"类简答题，答"概念—知识—案例—经验—建议—工具"六步即可拿分；若问"理论与实际的差异体现在哪"，答：约束条件（时间、成本、环境、人手）导致的取舍与优先级排序。

**过渡**：好，第一个案例来了——圣诞节的迪斯尼。

### 【1.13】迪斯尼并不总是带来笑声（5 分钟）

> **口播**：这个案例的标题叫"迪斯尼并不总是带来笑声"。据课件数据，1994 年圣诞节前夕，迪斯尼公司发布了第一个面向儿童的多媒体光盘游戏"狮子王童话"。圣诞节后的第一天，客户支持部的电话就开始响个不停，不断有人咨询、抱怨：为什么游戏总是安装不成功？为什么装上了也没法正常使用？事后发现，这个游戏软件只能在少数系统上正常运行，课件把它归为一类：兼容性问题。圣诞节前发布，是典型的"节日档期"发布：发布时间定死，留给测试的窗口被压缩。买游戏的是家长，圣诞早晨孩子拆开礼物等着玩，结果装不上、进不去、没声音，家长的第一反应不是"这是兼容性缺陷"，而是"迪斯尼的东西怎么这么差"。这就是质量问题的真实代价：它不只是返工成本，更是品牌信誉的损失，而信誉的修复成本远高于当初把测试做完整的成本。兼容性问题为什么难躲？因为它本质是组合爆炸：操作系统版本、显卡与声卡驱动、光驱型号、解码器、区域语言、分辨率，每一项都可能不同。你不可能把所有组合都买齐了测，所以兼容性测试的核心不是"全都测"，而是先分析用户群，找出主流配置与高风险组合，按优先级覆盖，这正是我们后面要学的等价类划分和风险驱动测试的思想雏形。如果当年有规范的测试流程，哪些问题可能被提前发现？至少三件事：第一，需求与设计阶段就明确"支持的运行环境清单"，并写进验收条件，不在清单里的系统就明确不支持、在包装上写清楚；第二，系统测试阶段针对主流配置矩阵做真实环境实测，而不是只在开发机上验证；第三，发布前让没参与开发的人从"拆包装"开始走一遍真实安装体验。这类缺陷放到今天的手机 App 上就是"某个机型闪退"，放到网页上就是"某个浏览器排版错乱"——本质没变。

**板书**：1994 圣诞前夕发布"狮子王童话"→ 节后客服电话不断（装不上/用不了）→ 根因：兼容性问题（只能在少数系统正常运行）→ 代价：用户流失＋品牌受损 → 对策：环境清单进需求 → 配置矩阵按风险覆盖 → 第三方真实安装体验

**提问**：如果你是迪斯尼当时的测试负责人，只有一周时间，你会怎么安排兼容性测试？

**预设回答**：①"把所有系统都买来测"——时间成本都不允许，我会追问：一周够吗？钱够吗？②"按市场占有率排，先测主流的三个系统"——这是很实际的答案，可以表扬，并补充还要看"用户群特征"：买儿童游戏的家长，家里电脑往往偏旧或偏杂牌；③"测一下开发机不就行了"——要立刻纠正，这正是案例翻车的根源：只在开发环境验证，等于没测兼容性；④"先做需求评审，把支持范围写清楚"——这个回答境界最高，说明他把测试往左移了，可以不测的组合就不测，但不能装作支持。

**易错点 / 考点**：这一页最常考"缺陷类型的判断"：安装不上、运行不了、只在少数系统正常 → 兼容性缺陷，而不是功能性缺陷。判断三步法：一，换环境问题就消失吗？是→兼容性；二，功能在支持的环境里是否按规格实现？是→不是功能缺陷；三，有没有明确的"支持环境清单"？没有→需求与文档缺陷，也要记一笔。简答题如果问"兼容性测试怎么做"，答题要点：确定支持矩阵→分析用户配置分布→识别高风险组合→按优先级与等价类覆盖→形成清单并写入发布标准。

**【思政落点 2】**：迪斯尼这个案例里，损失最大的是什么？是那些圣诞节早晨失望的孩子和他们父母的信任。测试人员的岗位之所以重要，是因为我们守着产品交给公众前的最后一道关。课件后面还会讲到放疗仪致死、航天器坠毁这类更沉重的案例，也会有国产游戏《血狮》的教训——把没有经过充分验证的产品当作成熟产品去卖，透支的是用户的信任，也是行业的信誉。请把"质量责任"四个字写进职业观：你签下的每一个"测试通过"，都可能关系到别人的时间、财产，甚至安全。

**过渡**：迪斯尼的代价是口碑，下一页我们要看的这个案例，代价直接用亿美元来计算——一个缺陷，究竟能贵到什么程度？