口播：前面我们已经知道什么是软件缺陷。可到了实际工作里，摆在测试人员面前的问题非常具体：屏幕上出现的这个现象，到底算不算缺陷？要回答它，先得学会认缺陷的"长相"。课件把软件缺陷的现象归纳成六类。第一类，功能、特性没有实现，或者只实现了一部分——需求说要支持批量导入，结果只能一条一条录，这就是没实现。第二类，设计不合理，本身就存在缺陷——两个模块都往同一张表里写数据，谁也没加锁，代码每行看着都对，可设计从一开始就是错的。第三类，实际结果和预期结果不一致——你输入三加五，它给你九，这是最典型的缺陷现象。第四类，运行出错，包括运行中断、系统崩溃、界面混乱——点一下按钮程序直接退出，或者弹出一堆重叠的窗口，用户根本没法用。第五类，数据结果不正确、精度不够——金额算出来多了两分钱，坐标算出来偏了几米，功能"跑通了"，但结果是错的。第六类，用户不能接受的其他问题，比如存取时间过长、界面不美观——这一类最容易吵架，因为需求文档里往往没写"多快算快""多好看算好看"，可用户就是不接受。这六类，你就把它当成一张筛查清单：拿到一个现象，先往这六类里对号入座，能对上号的，基本可以判定为缺陷；对不上号的，先别急着报，回去查需求、问用户。注意了，前三类和第四、第五类属于"硬缺陷"，有明确对错，可以直接判定；第六类属于"软缺陷"，要靠用户感受和业务约定来判定，这正是我们下一页要解决的问题。
板书：缺陷六现象 → ①功能未实现/部分实现 ②设计不合理 ③实际结果≠预期结果 ④运行出错（中断/崩溃/界面混乱）⑤数据不正确/精度不够 ⑥用户不能接受（存取慢/界面不美观）
提问：登录页面上，密码输入框比用户名输入框窄了 2 个像素。这算不算缺陷？依据是我们刚讲的哪一类现象？
预设回答：第一种答"不算，功能全都正常"——先肯定他关注了功能，再把他拉回第六类"用户不能接受的其他问题"，追问：如果不算缺陷，那 UI 走查时提的这个意见该叫什么？提示它属于界面设计与一致性范畴。第二种答"算，因为界面不好看"——肯定结论，但要求他说出对应哪一类现象，训练"用清单说话"的习惯，不能凭感觉定性。第三种答"看需求或 UI 规范怎么写"——这是最佳答案，请他说出需求里没写时怎么办，自然引到"判断依据"上，为下一页的判断准则做铺垫。
易错点 / 考点：常见混淆有三种：把"数据结果不正确、精度不够"当成"功能没实现"；把"存取时间过长"当成性能没做，忽略了它在这页属于"用户不能接受"这一类；把界面问题一律判为缺陷，不看设计规范和用户约定。考试形式多为选择或判断："下列哪项不属于软件缺陷的现象"。判断三步法：一查需求有没有要求，二看结果对不对，三问用户能不能接受。
过渡：现象能对上号，可"预期结果"到底由谁说了算？同一段行为，有人说是缺陷，有人说是特性，这就引出了下一页——软件缺陷的判断准则。
口播：上一页我们学会了从现象上认缺陷，但现象只是表面。一句"实际结果和预期结果不一致"，难点从来不在"实际结果"——跑一下就有；难点在"预期结果"从哪儿来。这个负责给出预期、并判定测试通不通过的机制，业界有个专门的名字，叫测试预言，Test Oracle。课件给的定义是：Test Oracle 就是决定一项测试是否通过的一种判断机制；它要求把被测试系统的实际输出与所期望的输出进行比较，从而判断有没有差异，也就是判断是不是缺陷。那么预期从哪儿来？课件列了七类依据，我们分三组记。第一组是最有分量的两个来源：需求规格说明书和其他需求、设计规范文档，这是第一位的依据；还有竞争对手的产品——用户常说"人家某某软件就是这么做的"，竞品可以当参照，但要谨慎，别人的行为不等于你的需求。第二组是四类偏自动化的预言：启发式测试预言，靠经验规则判断，比如"金额不可能为负数"；统计测试预言，靠统计规律判断，比如响应时间的分布有没有偏离历史基线；一致性测试预言，靠同一系统不同实现之间的一致性判断，比如新旧版本对同一个请求的结果应当一致；基于模型的测试预言，把一个模型当作正确答案的来源，拿实际输出跟模型推演的结果比。第三组是人类预言，Human oracle，说白就是由人来判断，靠测试人员的经验、业务知识，甚至最终靠用户的感受。这一页要建立一个意识：判断缺陷不是拍脑袋，而是有依据、可追溯的。你报一个缺陷，就必须说清楚"我拿什么当预期"。
板书：判断准则（Test Oracle）＝决定测试是否通过的比较机制：实际输出 vs 期望输出 → ①需求规格说明书/需求与设计规范文档 ②竞争对手产品 ③启发式预言 ④统计预言 ⑤一致性预言 ⑥基于模型的预言 ⑦人类预言
提问：测试一个计算器应用，输入 0.1 加 0.2，屏幕上显示 0.30000000000000004。你用什么当预期结果？请说出依据属于课件里的哪一类。
预设回答：答"预期是 0.3，所以是缺陷"——肯定他发现问题的敏锐，追问依据：需求文档有没有规定精度和舍入规则？若有，属于第一类依据；若没有，就要靠启发式预言（常识规则）或人类预言来判断，并说明这类问题在不同业务里结论可能不同。答"浮点数就这样，不算缺陷"——引导他区分"实现限制"与"用户可接受"，请他从用户视角判断这句结果用户能不能接受，再强调结论必须有依据、能说服人。答"用另一个计算器比对"——这是很聪明的答案，指出这属于一致性或竞品参照的思路，同时提醒：参照物的行为同样要先确认是对的。
易错点 / 考点：最常错的是把 Test Oracle 理解成"测试工具"或者"测试用例"，其实它是"判断是否通过的机制"。第二个混淆是把"人类预言"当成不专业、靠感觉，实际上人工判断在易用性、业务规则、界面审美上是不可替代的。考试形式常见为名词解释、选择（下列哪个不属于缺陷判断依据）和案例题（给出场景问依据是什么）。记忆口诀：物、竞、启、统、一、模、人——文档为准，竞品参照，四类预言兜底，人能拍板。
【思政落点 1】：讲"判断缺陷必须有依据"，可以联系工程中的标准意识：需求文档、设计规范、行业标准就是判断是非的尺子。测试人员手里的尺子如果有偏差，报出去的缺陷就站不住脚，团队会因此反复扯皮。做质量工作的人，既要有自己的判断，更要尊重客观依据，用数据和规范说话，而不是用嗓门大小说话——这就是科学精神在测试岗位上的具体落点。
过渡：知道了怎么判断缺陷，接下来要回答一个更根本的问题：这些缺陷到底是从哪儿冒出来的？
口播：缺陷从哪儿来？课件把产生原因归成三大类。第一类是技术问题。里面又分三种：算法错误，思路本身就是错的；计算和精度问题，比如浮点数累积误差、单位换算错误；接口参数传递不匹配，A 模块传来的单位是厘米，B 模块当成米收下，单看两边都没错，一对接就出事。第二类是团队工作。这一条最容易被忽视，杀伤力却最大——沟通不充分、误解。评审会上大家都点头，散会后三个人脑子里装着三个版本的需求；接口约定只写在聊天记录里，没人落进文档；跨部门、跨地域的团队各做各的。这类缺陷不是谁技术差，是信息传递断了。第三类是软件本身的问题：文档错误，说明书写错了参数；用户使用场合，也就是 user scenario 考虑不周，没想过用户会在地铁里断网操作；时间上不协调或不一致带来的问题，比如定时任务和用户操作撞在一起、几台机器的时钟不同步；还有系统的自我恢复、数据的异地备份、灾难性恢复等，这些功能平时不跑，一跑就是大事故。课件这一页还挂了参考文献，主题是"缺陷驱动的过程改进"。它在告诉我们：分析缺陷产生的原因，不是为了追责某个人，而是为了回头改流程。同一个原因反复出现，说明流程有洞，而不是某个人不小心。给你一个判断经验：如果某个缺陷让你觉得"这怎么能怪开发"，那它大概率属于团队工作或软件本身这两类，解决方案在流程和文档里，不在某一行代码里。
板书：缺陷产生三来源 → 技术（算法错误／计算与精度／接口参数传递不匹配）｜团队（沟通不充分、误解）｜软件本身（文档错误、用户使用场合、时间不协调或不一致、自我恢复与数据异地备份/灾难恢复）
提问：一个接口联调失败：前端按"秒"传超时时间，后端按"毫秒"解释，结果请求 3 秒就超时。这个缺陷属于课件所说的哪一类原因？根子上该怎么修？
预设回答：答"技术问题，接口参数不匹配"——正确，但要追问他会不会把它只当代码 bug 修，提醒他真正的修法是补上接口契约与单位约定，属于流程改进。答"沟通问题"——也说得通，表扬他从团队角度看问题，说明技术类与团队类常常并存，评审与文档化是共同解药。答"前后端都有责任"——把它变成教学素材：缺陷归因的目的是定位可改进的环节，不是分摊责任，请他给出具体改进动作（统一单位、接口文档、联调用例）。
易错点 / 考点：常错在把"缺陷产生原因"与"缺陷现象"混为一谈：现象回答"看到什么"，原因回答"为什么会有"。另一处混淆是把"文档错误"归到技术问题，其实课件把它放在"软件本身"一类。考试常考分类题（下列哪项属于团队工作导致的缺陷）和简答（简述缺陷产生的三类原因）。记忆抓手：技术、协作、软件——写错了、没沟通清、想漏了场景。
过渡：三类原因是从性质上分，把缺陷按来源归好类之后，我们还得知道每一类各占多少、哪一类是重灾区，这就有了缺陷的构成。
口播：接着看 2.1.5 软件缺陷的构成。上一页讲的是原因的大类，这一页要做的是把缺陷变成可以统计、可以量化的结构。所谓构成，就是把收集到的缺陷按来源或者根源做归类统计，看每一类各占多少。课件这一页配了两张图，出处标得很清楚：一张来自 2010 年 1 月发表在 International Journal of Industrial Engineering and Management 第一卷第四期第 155 到 161 页的论文，题目是《Requirements-based testing process in practice》，讲的是需求驱动的测试流程实践；另一张来自 scopemaster 的技术博客，题目是《软件缺陷的根本原因》。这里我要特别提醒：课件图上的百分比我不要求你们背，不同项目、不同统计口径差别很大，背数字没有意义；你要学的是看图的方法。图上的分类通常包括需求类、设计类、编码类、文档类、环境与配置类、人员与沟通类。看这张图要问三个问题：第一，哪一类贡献的数量最多？第二，严重级别最高的那些缺陷集中在哪一类？第三，上一次做过程改进以后，这一类有没有下降？这三个问题回答清楚了，过程改进才有靶子，否则所谓改进就是拍脑袋。回到课程设计上，你们后面要记录缺陷，我要求每条缺陷都标注来源类别和发现阶段，目的就是让你们最后能画出属于自己项目的那张构成图，用数据说明"我们的问题主要出在需求还是编码"。
板书：缺陷的构成＝按来源/根源归类统计 → 需求｜设计｜编码｜文档｜环境与配置｜人员与沟通；图谱出处：IJIEM 2010,1(4):155-161《Requirements-based testing process in practice》＋ scopemaster《root causes of software bugs》；三问：哪类最多？严重缺陷集中在哪类？改进后是否下降？
提问：如果你们项目统计出来的缺陷构成图显示：需求类缺陷占的数量最多，而且严重级别高的缺陷也几乎都在需求类。下个迭代你打算改哪三件事？
预设回答：答"让开发小心点"——点评这个答案没抓住根源，需求类缺陷靠开发小心是治不住的，引导他往评审和需求确认上想。答"加强需求评审、需求要让用户确认、需求变更要走流程"——这是好答案，帮他排优先级：先做实需求评审的检查单，再补需求基线确认。答"测试人员提前介入需求评审"——很好，进一步点出这就是测试左移，让测试人员在需求阶段就提出二义性和可测性问题。
【思政落点 2】：缺陷构成分析里有一个职业底线问题：不能只统计"好修好说"的缺陷，把难看的、自己漏掉的、指标不利的隐去。数据一旦被美化，过程改进就失去了方向，用户拿到了虚假的质量信号。将来你们做缺陷记录和测试报告，要如实记、如实报，不因为影响考核就删除或降级——诚信是质量工作者的第一块基石。
易错点 / 考点：常错有两个：把"构成"当成"某一类缺陷的详细步骤"，其实它讲的是各类缺陷的比例结构；另一个是把构成图当成背数字的材料。考试常考简答（什么是缺陷的构成分析，它的作用是什么）和案例题（根据给定的缺陷清单做归类统计，并给出改进建议）。记忆抓手：归好类、看比例、找靶子、改流程。
过渡：构成回答的是"哪一类多"，但缺陷还有一个更隐蔽的维度——它是在什么时候被引入、又在什么时候才被发现。
口播：有了构成，再看分布。分布讲的是时间维度：缺陷是在哪个阶段被引入的，又是在哪个阶段被发现的。课件这一页给了两句关键结论。第一句：在真正的程序测试之前，通过审查、评审，就可以发现更多的缺陷。注意这个"真正的程序测试之前"，指的是代码还没跑起来、甚至还没写完的时候。为什么强调这一点？因为很多同学脑子里有个默认流程：写完代码交给测试，测试就是点点点。可事实上，评审和静态检查能抓到的缺陷数量相当可观，而且成本低得多。第二句更有意思：需求的缺陷会在需求评审、设计、编码、测试等过程中逐步被发现，很难在需求分析这一个阶段就全部发现。这句话包含两层含义。一层是需求缺陷的影响会一路向下传：设计、编码、测试各个阶段都可能因为它出问题，所以你在编码阶段看到的一个 bug，根子可能在一周前的需求文档里。另一层是别指望需求评审一次就把需求缺陷清干净，缺陷的发现是一个随时间逐步收敛的过程，所以要反复评审、持续跟踪。这页的图把两个分布画在一起：一条是缺陷被引入的阶段分布，一条是缺陷被发现或被修复的阶段分布，两条线错开的那片区域，就是缺陷潜伏的时间。潜伏得越久，暴露得越晚，代价就越大——这就直接接到下一页。
板书：分布＝引入阶段 × 发现阶段 → 引入曲线 vs 发现曲线 → 两线错开区＝缺陷潜伏期；结论①真正的程序测试之前，审查/评审已能发现更多缺陷 ②需求缺陷会经需求评审→设计→编码→测试逐步发现，难在需求分析一次清空
提问：一个上线后才被用户发现的计算错误，追查发现是需求文档里"折扣按四舍五入"这句话没写清楚。请说出这个缺陷的引入阶段和发现阶段，并解释为什么它的代价特别高。
预设回答：答"引入在需求阶段，发现在上线后"——正确，追问中间的三个环节（需求评审、设计、编码、测试）为什么都没有拦住它，让学生看到每个环节都本可以拦住。答"是开发写错了"——借此纠正归因偏差：需求二义性没有被评审识别，问题在信息传递和评审有效性上，不全在编码。答"这种缺陷没法避免"——点评他悲观的部分有现实依据（需求缺陷很难一次清空），但要求他说出可以改善的动作，比如需求评审检查单、原型确认、用例反查需求覆盖。
易错点 / 考点：最常错的是把"缺陷引入阶段"和"缺陷发现阶段"当成同一个东西，画图时两条线重合。第二个易错点是把评审当成"走形式、浪费时间"。考试常考判断（缺陷大多是在编码阶段引入的）、识图题（读出两条曲线的错位区并说明含义）和简答（为什么说需求缺陷很难在需求分析阶段全部发现）。记忆抓手：引入是源头，发现是关口，两个关口错开多大，返工就多贵。
过渡：潜伏期越长代价越大——那到底大成什么样？课件用两个关键词给出了答案：劣质成本，以及非线性增长。
口播：2.1.6 修复软件缺陷的成本。这一页有两个关键词。第一个叫劣质成本，英文缩写 COPQ，Cost of Poor Quality。缺陷带来的成本就叫劣质成本。注意这个名字的立场：它不是"测试成本"，也不是"开发成本"，而是"因为质量不好而额外付出的钱"。它包含什么？返工的人力、重新测试的时间、紧急发版的加班、线上事故的赔付、客户流失、品牌受损，甚至包括你反复开会澄清、写事故报告所花的时间。第二个关键词是：非线性增长。课件明确说，缺陷不及时处理带来的成本很高，而且是呈非线性增长的。什么意思？缺陷留在系统里的时间越长，修复它的代价不是每天多一点点，而是越往后越陡。原因很直观：需求阶段的一个缺陷，当场改，就是改一句话、动一段文档；拖到设计阶段改，要改设计、改接口；拖到编码阶段改，要改代码，而且可能已经被几十处引用；拖到测试或上线以后才发现，还要加上定位成本、回归成本、错误数据的修复成本，以及对已经造成后果的追责成本。你还会发现一个规律：越晚发现的缺陷越难定位，因为代码和设计已经改了很多轮，现场都被破坏了。所以测试左移不是一句口号，它背后是一条经济规律。这里我要提醒一个常见误区：不要以为"测试花的时间越少，项目就越省"。省下来的测试时间，往往会在后期以几倍甚至几十倍的返工还回去。测试不是单纯的成本项，它是把风险成本提前锁住的保险。
板书：修复成本 → ①劣质成本 COPQ（Cost of Poor Quality）：返工＋重测＋紧急发版＋事故赔付＋客户流失＋品牌损失 ②非线性增长：需求→设计→编码→测试→上线，越往后越陡（定位/回归/数据修复/追责成本叠加）→ 结论：测试左移＝经济规律
提问：项目快到截止日期了，有人提议"这轮回归测试砍掉一半，能省三天时间"。请你用这一页的两个概念回应他，并给出你的判断。
预设回答：答"省三天，但上线后可能要赔三十天"——好答案，让他说清 COPQ 里具体包含哪些项目，把直觉变成可计算的账：三天测试人力对比潜在的返工、赔付与流失。答"砍了就砍了，风险我不管"——不要简单否定，把它当教学素材，请他写下这个决定的风险清单，再讨论谁为劣质成本最终买单。答"只能砍低风险模块的用例，高风险必须保住"——这是最职业的答案，表扬并补充：要基于缺陷分布和影响面排序，而不是平均砍一半，这就是风险驱动的测试。
【思政落点 3】：成本曲线讲的是"欠下的质量债早晚要还"，这正好对应职业责任：明知道某个功能没有验证充分，却为了赶进度签字放行，代价最终由用户承担——历史上不少事故就是这么发生的。同学们将来在岗位上，可能会面对"能不能先上线"的压力，请记住，你有责任把风险讲清楚、写清楚，而不是替别人承担不该承担的沉默。
易错点 / 考点：常错有两个：把 COPQ 理解成"测试部门的花费"，其实它是质量不好造成的全部额外损失；把非线性增长理解成"线性增长得更快一点"，忽略了曲线后半段的陡增。考试常见为选择题（COPQ 的含义）、判断题（缺陷修复成本随阶段线性增长——错）和案例题（比较在不同阶段修复同一缺陷的代价并给结论）。记忆抓手：质量不好多花的钱＝COPQ；越晚越贵，非直线。
过渡：到这里，2.1 软件缺陷就讲完了——从现象、准则、产生、构成、分布到成本。接下来我们要问：用什么办法把这些缺陷找出来？这就是 2.2 软件测试的分类。
口播：从这一页开始进入 2.2，软件测试的分类。前面 2.1 讲的是缺陷：是什么、怎么判断、从哪儿来、怎么分布、代价多大。讲透了缺陷，接下来自然要问：用什么办法把它找出来？办法有很多，名字也很多——功能、性能、静态、白盒、回归……不先建立分类框架，这些名词就是一盘散沙，到了项目上也不知道该选哪个。所以 2.2 的任务，就是把这些方法挂到一棵分类树上去。这一节按六个步骤走：概念，这个维度是什么、什么场景用；做法，要掌握哪些知识和技术；举例，用案例帮你看懂怎么用；经验分享，讲理论与实际的差距；学习建议；以及对应的实用工具和模板。重点是分类维度和选择依据，不是背名词。学完你要能做到两件事：拿到一个项目，能说出该做哪几类测试；听到一个陌生名词，能判断它挂在哪个维度上。
板书：2.2 软件测试的分类 → 学习路径：概念（什么场景用）→ 讲解（要掌握什么）→ 举例（案例/Demo）→ 经验分享（理论与实际的差距）→ 学习建议 → 实用工具/模板；目标：拿到项目能选类型，听到名词能定位维度
提问：在进入分类之前先热身：请凭直觉说出你知道的三种测试名称，并试着说说它们分别是从什么角度来划分的。
预设回答：答"功能测试、性能测试、安全测试"——表扬，指出这三个都是从"测试目的"这个角度划分的，属于同一根主枝，让学生体会同一维度下可以有很多类型。答"单元测试、集成测试、系统测试"——指出这是从"测试对象或范围"划分的，与上一组不是同一个角度，正好说明为什么需要多个维度。答"白盒、黑盒"——指出这是从"是否针对内部结构"划分的，属于另一个视角。三种回答都记在黑板不同位置，直接变成分类树的雏形。
易错点 / 考点：常见错误是把不同维度的名词混在一起当成平级分类（比如"单元测试和性能测试哪个先做"），考核中常有"下列分类不属于同一维度的是"。判断三步法：先问"按什么分"，再问"这一维有哪些取值"，最后才问"该选哪个"。
过渡：框架交代完了，我们先看这张分类总览图，把整节的骨架装进脑子里。
口播：这一页是 2.2 的分类总览图，一张图把整节的骨架画出来了。看这种图有个方法：先看它从哪几个方向分叉，再看每一根分叉下面挂了哪几片叶子。图的主干就是"软件测试"这四个字，往外伸出几根主枝，对应我们后面要逐个讲的分类维度。第一根主枝，按测试的对象或范围分：单元测试、集成测试、系统测试，一直到验收测试，越往后测的对象越大、越接近用户。第二根主枝，按测试的目的分，也就是我们常说的测试类型：功能、性能、可靠性、安全性、兼容性、回归等等。第三根主枝，按被测程序有没有被执行来分：静态测试和动态测试。第四根主枝，按测试有没有盯着内部结构和实现算法来分：白盒和黑盒，中间还有灰盒。第五根主枝，按测试方法分：精准测试、变异测试、蜕变测试、MBT 这些相对进阶的方法。同学们看这张图的时候，脑子里的动作应该是：先把五根主枝记住，再把每一个你听说过的测试名词往枝上挂。挂得上去，说明你的知识是有结构的；挂不上去，说明你只是记住了名字。这里有一个非常重要的提醒：这些维度不是互相排斥的单选题，而是可以叠加的坐标。同一个测试活动，可以同时是系统测试、性能测试、动态测试、黑盒测试，并且用基于模型的方法来设计。所以以后不要问"这个项目到底该做黑盒还是白盒"，而要问"在哪个层次、为了什么目的、用什么视角、借助什么方法"。
板书：分类总览图 → 主干：软件测试 → 五主枝：①对象/范围（单元→集成→系统→验收）②目的/类型（功能·性能·可靠性·安全·兼容·回归）③是否执行程序（静态/动态）④是否针对内部结构（白盒/黑盒/灰盒）⑤方法（精准·变异·蜕变·MBT）；维度可叠加＝坐标系，不是单选题
提问：请给"用 Selenium 脚本跑一遍电商网站的下单流程，看页面和订单数据是否正确"这个活动打上四个坐标标签。
预设回答：答"系统测试＋功能测试＋动态测试＋黑盒测试"——标准答案，请他逐个说明理由，尤其解释为什么是黑盒（脚本只操作界面、不关心内部实现）。答"自动化测试、回归测试"——认可这两点，但指出自动化属于"执行方式"这一对，回归属于"测试目的"，维度不同，帮他区分。答"白盒测试，因为脚本能看到代码"——这是典型错误，借此讲清白盒的关键是"是否针对内部结构和实现算法来设计用例"，而不是"手里有没有代码"，脚本走的是界面，仍是黑盒。
易错点 / 考点：常错在把分类维度当成分等级、分先后，或者认为一个测试只能属于一类。考试常见为多选题（下列哪些维度可以用来给同一个测试活动打标签）和识图题（从分类图中指出某名词所属维度）。记忆口诀：范围、目的、跑不跑、看里看外、用什么法。
过渡：五根主枝先记牢，接下来我们逐个拆开看，先从最常用的按对象和目的分类讲起。
口播：这一页把五个分类维度展开讲。第一个维度，按测试的对象或范围分，范围从小到大排：底层测试，也就是单元测试，测的是最小的可测单位，通常是一个函数、一个类或者一个模块；接口测试或集成测试，测的是模块拼起来之后能不能正确协作，重点在接口、数据传递和调用顺序；系统测试，把整个系统装进接近真实的环境，按需求从头到尾验证；再往上就是业务层的验收测试，由用户或者业务方确认"这是不是我要的东西"。记住一条主线：越往下，测的是"零件对不对"，执行主体多是开发人员；越往上，测的是"整机能不能交付"，执行主体逐渐转向测试人员和用户。第二个维度，按测试的目的分，也就是测试类型：功能测试看功能对不对；性能测试看快不快、扛不扛得住；可靠性测试看长时间运行稳不稳；安全性测试看会不会被攻破；兼容性测试看在不同浏览器、操作系统、设备、数据下是否都正常；回归测试看改了一处有没有碰坏别处。第三个维度，按被测软件在测试过程中是否被执行，分为静态测试和动态测试。第四个维度，按是否针对系统的内部结构和具体实现算法，分为白盒测试和黑盒测试。第五个维度，按测试方法分：精准测试、变异测试、蜕变测试、MBT，也就是基于模型的测试，这些属于进阶方法，后面章节会逐个展开。这五个维度的顺序和课件一致，请大家按这个顺序记，不要打乱。
板书：五个维度 → ①对象/范围：单元（底层）→ 接口/集成 → 系统 → 业务层验收 ②目的/类型：功能·性能·可靠性·安全·兼容·回归 ③是否执行程序：静态 / 动态 ④是否针对内部结构与算法：白盒 / 黑盒 ⑤方法：精准测试·变异测试·蜕变测试·MBT
提问：一个银行 App 要上线新版本。请分别从"对象/范围"和"目的/类型"两个维度，各说出两个必须做的测试，并说明理由。
预设回答：答"单元测试和集成测试；功能测试和性能测试"——达标，请他把每个测试对应的对象说清楚，特别是集成测试要盯接口和转账对账的数据一致性。答"就做一个系统测试，覆盖全部功能"——借这个答案讲"层次不能互相替代"：系统测试跑通了，不代表单元内部的分支和边界都被覆盖，缺陷定位也会困难得多。答"安全性测试最重要，因为涉及资金"——认可风险判断，同时补充：安全和性能再重要也不能替代功能与回归，要按风险排优先级而不是做单选题。
易错点 / 考点：最容易错的是把"对象/范围"和"目的/类型"混为一谈，比如认为"系统测试"和"功能测试"是同一个维度的平级名词。第二个易错点是把"验收测试"只当成一个流程节点，忘了它是测试范围维度上的最高层。考试常见为分类连线题、多选题（下列哪些属于按测试目的分类）。判断三步法：先问"测的是谁"（范围），再问"为了什么"（目的），最后问"怎么测"（静态动态、黑白、方法）。
过渡：五个维度搭好了架子，但还有一组更细的说法需要单独讲——就是同样是做测试，方式上可以差得很远。
口播：这一页讲软件测试方式，课件列了四对，一共八种：静态测试和动态测试；主动测试和被动测试；手工测试和自动化测试；基于脚本的测试和探索式测试。为什么要把它们成对摆出来？因为它们回答的是四个不同的问题：程序跑不跑？——这是静态对动态。测试人员要不要主动去驱动系统？——这是主动对被动。用例由人来执行还是由机器执行？——这是手工对自动化。用例是提前设计好了照做，还是边测边设计？——这是基于脚本的测试与探索式测试。请注意，每一对里的两个选项之间，不是"新的取代旧的"，也不是"好的和坏的"，而是各有各的适用场景，实际项目里往往是组合使用的。举个例子说明它们能叠加：一个电商系统的支付模块，你既可以做动态的功能测试，也可以做静态的代码评审；回归用例可以交给自动化跑，同时用探索式的手工测试专门去找自动化脚本想不到的路径；上线以后还要靠被动测试，从监控和日志里发现问题。所以学这四对，目标不是选边站，而是建立一个坐标——拿到一个测试任务，你要能说清楚它在四个坐标上分别落在哪里。接下来我们逐对来看。首先是静态测试和动态测试，这是最基础、也最能体现测试左移的一对。
板书：测试方式四对 → 跑不跑：静态 / 动态｜谁驱动：主动 / 被动｜谁执行：手工 / 自动化｜用例何时设计：基于脚本 / 探索式；四对＝四个坐标轴，可叠加组合使用
提问：请判断这句话对不对，并说明理由："自动化测试比手工测试先进，所以项目里应该尽量用自动化测试替代手工测试。"
预设回答：答"不对，有些场景必须手工"——追问是哪些场景，引导他说出探索式测试、易用性判断、需求频繁变动的部分，把结论落到"场景决定方式"。答"对，自动化效率高"——不直接否定效率这个事实，而是请他算一笔账：只跑一次的用例，写脚本的成本能不能收回来，让他自己发现自动化的前提是"可重复、稳定、量大"。答"两者结合，回归用自动化，新功能用探索式手工"——最佳答案，表扬并补一句：企业里这正是常见的分工方式，自动化守住既有功能，人去找未知的问题。
易错点 / 考点：常错在把四对方式当成互斥的选项，认为一个测试只能属于每对中的一边；第二个易错点是认为"自动化一定优于手工"。考试常见为判断、选择和简答（简述软件测试的几种方式并各举一例）。记忆口诀：跑不跑、谁驱动、谁执行、怎么设计。
过渡：四对里先看第一对，也是最基础、最容易考的一对——静态测试和动态测试。
口播：静态测试和动态测试的区别，一句话就能说清：程序有没有跑起来。动态测试是通过运行程序发现错误——你设计输入、执行、观察输出，再跟预期比，我们在上一节做的练习基本都是这一类。静态测试不执行程序，而是通过人工评审、代码扫描和静态分析来发现错误，文档评审、代码走查、工具扫描都算。这里要划清几个边界。第一，静态测试查什么？查需求文档里的二义性和遗漏，查设计里不合理的地方，查代码里的空指针、数组越界、资源没释放、命名和编码规范问题。这些问题如果留到运行时才发现，代价会大得多——有些问题比如内存泄漏，跑一次两次根本看不出来。第二，静态测试不等于"随便看看"。课件这一页特意列出了评审会议里的角色分工：主持人负责组织会议、控制节奏、确保议题不跑偏；作者是被评审对象的作者，负责讲解、答疑并记录问题；记录员负责如实记录每一个问题和决议，不能漏记、不能美化；列席人员旁听学习并提供补充视角；内审员负责检查过程是否合规；技术专业人员提供领域内的技术判断；用户代表则从需求和业务角度把关。有了这套分工，评审才是"有产出、可跟踪"的活动，而不是一次聊天。第三，不要以为静态测试就是评审，代码的静态分析主要靠工具来做，但人工的代码评审同样不可或缺，两者是互补的。最后给一个判断口径：凡是"我读了、我看了、我扫了"的，都是静态测试；凡是"我运行了、我点了、我发请求了"的，都是动态测试。
板书：静态 vs 动态 → 静态＝不执行程序：人工评审（走查/会议评审/互为评审）＋代码扫描/静态分析 → 查需求二义、设计不合理、代码规范与隐患；动态＝运行程序：设计输入→执行→比对输出；评审角色分工：主持人（组织控场）·作者（讲解答疑记录）·记录员（如实记录）·列席人员（旁听补充）·内审员（查合规）·技术专业人员（技术判断）·用户代表（需求业务把关）
提问：一个模块刚写完，还没运行过一次。用静态方法你能查出哪些类型的问题？请至少说出三类，并各举一个具体例子。
预设回答：答"规范问题、空指针、资源没释放"——达标，请他补充"需求或设计层面的问题"，比如接口参数单位没写清、异常分支没有设计，让他意识到静态测试不只看代码。答"没运行怎么知道对不对"——这是很有代表性的误解，借此讲清：静态测试查的是"能不能对"，而不是"跑出来对不对"，规范、结构、逻辑路径上的矛盾在纸上就能看出来。答"只能靠工具扫描"——补充人工评审的不可替代性，比如变量命名歧义、注释与代码不符、业务规则理解偏差，工具往往扫不出来。
易错点 / 考点：最常错的是把"静态测试"等同于"测试文档"或者"不重要的测试"；第二个易错点是以为静态测试只针对代码，漏掉需求与设计文档。考试常见为选择（下列哪项属于静态测试）、判断（静态测试不执行程序——对）和案例题（给定一段代码，指出可用静态分析发现的隐患）。记忆抓手：不动程序就是静态；评审看文档、走查看代码、扫描靠工具。
过渡：静态和动态讲的是"程序跑不跑"，接下来这对讲的是"测试人员要不要主动去驱动系统"——主动测试与被动测试。
口播：第二对是主动测试和被动测试。主动测试，是测试人员主动出击：主动设计用例、构造输入、驱动系统、观察输出。我们平时课堂练习做的几乎都是主动测试——测什么、怎么测、什么时候测，控制权都在你手里。被动测试不一样，它不主动去打扰系统，而是在系统正常运行的过程中收集数据、观察行为，从日志、监控指标、用户反馈、缺陷报告、线上数据里发现问题。打个比方：主动测试像体检，你自己走到医院，医生按项目给你逐项查；被动测试像戴手环，不打扰你的生活，却持续记录心率、睡眠，异常了才报警。为什么需要被动测试？因为有些缺陷只在真实环境、真实数据、真实并发下才暴露，你在实验室里构造不出来；而且被动测试不会干扰用户，特别适合线上系统、生产环境和已经在跑的产品。它当然也有局限：不主动，就不知道系统在你没观察到的地方发生了什么；没有现成的预期结果可以对照，判断更多要靠基线、统计和趋势。所以在企业里两者是配合使用的：上线前靠主动测试把关，上线后靠被动测试感知。顺带说一句，很多同学把"被动测试"理解成"消极测试、随便测测"，这是完全错的——要做好被动测试，前提是对系统非常了解，知道该采集哪些指标、该盯哪些日志、该关注哪些异常模式，工作量一点都不小。
板书：主动 vs 被动 → 主动：测试人员设计用例、构造输入、驱动系统、观察输出（控制权在测试方，如功能/回归测试）｜被动：不干扰系统运行，采集日志·监控·用户反馈·线上数据，靠基线与统计判断（适合生产环境、灰度发布、Beta 与线上监控）｜关系：上线前主动把关，上线后被动感知，配合使用
提问：产品已经上线三个月，用户投诉"偶尔下单失败，但好像又自己好了"，而且无法稳定复现。这时你更该用主动测试还是被动测试？具体怎么做？
预设回答：答"被动测试，去看日志和监控"——正确，追问看什么：失败请求的时间分布、并发峰值、下游依赖的响应时间与错误码、是否有重试和自动恢复的痕迹。答"主动测试，我写脚本一直点下单"——肯定这个动作的价值，但指出难点在于"无法稳定复现"，先靠被动测试收集线索缩小范围，再用主动测试验证假设，让两者形成闭环。答"这种问题查不出来"——借机讲灰度与埋点的重要性：可观测性本身就是设计的一部分，没有日志和监控，被动测试就无从下手。
易错点 / 考点：最容易错的是把"被动测试"理解成被动消极、不设计、不投入；第二个易错点是认为被动测试只能发现问题不能定位问题，其实通过日志与监控的关联分析，被动测试经常能给出非常精确的线索。考试常见为选择、判断（被动测试需要运行系统但不主动输入——对）和案例题（给定线上问题场景，选择测试方式并说明理由）。判断三步法：谁在驱动？系统在不在真实运行？判断依据是预期还是基线？
过渡：主动和被动讲的是"谁来驱动"，接下来这对讲的是"谁来执行"——手工测试和自动化测试。
口播：最后一对，手工测试和自动化测试。手工测试，就是人按用例一步一步执行，自己观察、自己判断结果。自动化测试，是用脚本或工具来执行并比对结果，机器跑、机器判，或者机器跑、人来判。先破除一个常见误解：自动化测试不是"更高级的手工测试"，它不是万能的。哪些适合自动化？回归测试，因为用例稳定、要反复跑很多遍；性能测试和压力测试，要模拟成百上千并发，人根本做不了；大批量的数据驱动测试；以及持续集成里的冒烟测试。哪些必须靠手工？需求还在频繁变动、脚本写了马上就废的；探索式测试，靠人的直觉、经验和联想去找问题；易用性、界面美观这类靠主观感受判断的；还有一次性的、只跑一遍的验证。从投入上看，自动化有前期成本：写脚本、搭环境、准备测试数据，还有持续的维护成本。用例只跑一两次，自动化是亏的；用例要跑上百次，自动化才划算。还有一个很重要的经验：脚本会腐化，界面一改、接口一变，脚本就红一片，所以自动化测试本身也是需要长期维护的资产，不是写完就一劳永逸。课件这一页配了三张图，画的就是手工与自动化在不同场景下的分工，以及投入与产出的对比，大家结合图来理解：图的重点不是告诉你哪个更好，而是告诉你边界在哪里。
板书：手工 vs 自动化 → 手工：人执行、人判断（适用：需求多变、探索式、易用性主观判断、一次性验证）｜自动化：脚本/工具执行与比对（适用：稳定回归、性能与并发、数据驱动、持续集成冒烟）｜成本：自动化有编写＋环境＋数据＋维护成本，重复次数足够多才划算；脚本会腐化，需持续维护
提问：你们要在两周内交付一个学生选课系统，功能还在改，回归用例大约 30 条。你会选择把回归全部自动化吗？请说明理由。
预设回答：答"会，自动化效率高"——请他算账：30 条用例、两周内可能只跑两三次，而写脚本加调试可能要三四天，还要跟着需求变化改脚本，让他自己发现不划算。答"不会，需求还在变，脚本维护成本太高，先手工跑几轮，等需求稳定再挑高频用例自动化"——这是最职业的答案，表扬并补充：可以只自动化"核心且稳定"的若干条，作为冒烟用。答"自动化能发现更多缺陷"——纠正这个误解：自动化擅长"验证已知的预期"，不擅长发现未知问题，发现新缺陷更多依赖人的探索与思考，这正是探索式测试的价值所在。
易错点 / 考点：常错有三个：认为自动化一定优于手工；把"自动化测试"等同于"性能测试工具"，忽略它只是一种执行方式；忽略脚本的维护成本，以为写完就完了。考试常见为选择、判断（所有回归测试都应当自动化——错）和简答（比较手工测试与自动化测试的适用场景）。记忆抓手：机器擅长"反复核对已知"，人擅长"发现未知"；量大稳定交给机器，变化探索留给人。
过渡：四种测试方式我们讲了三对——静态与动态、主动与被动、手工与自动化，还剩最后一对：基于脚本的测试与探索式测试，下一页接着讲。