口播：上一页我们对比了手工测试和自动化测试，这一页把第 2.2 节最后一组测试方式补齐，也是最有意思的一组：基于脚本的测试和探索式测试。 先说基于脚本的测试（Scripted Testing）。它的做法很直观：先把测试设计做完，把用例一条条写清楚，再按计划执行，执行完了再分析结果。也就是说，"测试设计、测试执行、分析"这三件事被拆成了先后阶段——先想清楚，再动手，最后复盘。 探索式测试（Exploratory Testing）刚好相反，它把学习、设计、执行、分析这四件事拧成一个循环：一边了解被测软件，一边设计下一步怎么测，马上执行，看到结果再回头修正自己的理解和思路。请注意，测试设计并没有消失，它只是从"事前一次性做完"变成了"执行过程中持续进行"。这个概念最早由测试专家 Cem Kaner 提出，他强调的是测试者的自由与责任并存。 打个比方。基于脚本的测试像照着菜谱做菜：菜谱写好了，按步骤下锅，味道不对就回去改菜谱。探索式测试像老厨师试新食材：先尝一口，再换个火候，边做边判断，手上没有现成菜谱，但脑子里一直在设计。 软件行业里这两种方式都在用，而且常常混着用。需求稳定、接口明确的回归场景，比如每次发版都要跑的登录、下单、支付主流程，适合用脚本化的用例守住底线；而产品刚上线、需求还很模糊、文档只有薄薄几页的时候，你写不出准确的用例，硬写出来的用例测的往往不是真风险，这时候就该让有经验的测试人员去"边学边测"，快速把主要风险点摸出来。 所以选择依据可以记三条：需求稳定不稳定、被测对象熟不熟悉、时间紧不紧。需求稳、对象熟、要长期回归，就脚本化；需求在变、对象生、要快速摸风险，就探索式。
板书：基于脚本：设计 → 执行 → 分析（先写后跑；可复用、可回归）｜ 探索式：学习 ↔ 设计 ↔ 执行 ↔ 分析（循环；边学边测）｜ 选择依据：需求稳定度 · 对象熟悉度 · 时间压力 · 是否长期回归
提问：一个刚上线的新 App，需求文档只有一页，团队里也没人测过，你手上没有任何历史用例。这时候你是先花两天写一份两百条的用例库，还是先动手点一小时？为什么？
预设回答：
易错点 / 考点：最大的坑是把探索式测试等同于"随意乱点"（ad hoc 测试）。考试常见判断题："探索式测试就是不做测试设计、不用写用例的测试"——错。探索式测试的设计工作一直存在，只是它和执行交织在一起，并且要求测试者记录过程、复盘发现、把有效路径沉淀成可回归的用例。判断三步法：有没有带着目标去测？有没有边测边设计？有没有记录与沉淀？
过渡：到这里，第 2.2 节"软件测试方式"的四组对比就全讲完了。接下来我们进入 2.3 节，讲一对更基础、更本质的划分：静态测试和动态测试。
口播：从这一页开始，我们进入 2.3 节：静态测试和动态测试。 这一节要回答的核心问题只有一个：测试到底要不要把程序跑起来。不运行被测程序，靠人看文档、看代码，靠工具扫代码，这叫静态测试；把程序运行起来，喂数据、看输出、比结果，这叫动态测试。这一条分界线，是后面所有测试技术的一级分类，务必先立住。 再补一句它的分量：这组分类不是学术摆设，它直接决定你下一步能拿出什么手段——是坐在评审桌上挑问题，还是到环境里去跑用例。选错了手段，力气就白费了。 本节我们按三步走：第一步，讲产品评审，也就是对需求文档、设计文档和代码的评审——解决"该不该这么写"；第二步，讲静态分析，也就是不运行程序的代码检查——解决"代码里藏着什么问题"；第三步，讲验证与确认，也就是 V&V——解决"我们做的到底对不对、是不是用户真正要的"。 请大家带着一个问题听本节：静态测试不跑程序，它凭什么能发现缺陷？如果这个问题想通了，你就会明白教材为什么反复强调"越早发现越便宜"，也会明白测试为什么要往需求、设计这些"纸面产物"上延伸。顺便提醒：这一节的关键词——评审、静态分析、验证、确认——全是后面考试的高频词，听到一个就在脑子里归好类。
板书：2.3 静态 vs 动态 ｜ 分界线：是否运行被测程序 ｜ 路线：产品评审（需求/设计/代码）→ 静态分析（不跑程序查代码）→ 验证与确认（V&V）
提问：一个程序运行起来一切正常，是不是就说明它没问题？
预设回答：
易错点 / 考点：别把"静态"理解成"不动脑子地看"，也别把"动态"理解成"随便跑跑"。判断口径只有一条：被测程序有没有被执行。选择、判断题常把"代码评审""代码走查""静态扫描"和"运行程序调试"混在一起考，按这条口径一一对号即可。
过渡：先看第一块——产品评审。它管的是文档和代码的质量，也是所有测试活动里最能省钱的环节。
口播：什么是静态测试？教材给的定义很干净：静态测试包括对软件产品的需求和设计文档、代码的评审，比如技术评审、文档评审等，以及对代码的静态分析。一句话，凡是"不运行被测程序、靠人对产物进行检查"的活动，基本都算静态测试。 这里有一条特别容易被忽略的边界，请注意：管理评审、流程评审不属于静态测试，它们属于质量保证，也就是 QA。为什么？因为静态测试盯的是"产品"——需求、设计、代码这些交付物；而管理评审、流程评审盯的是"过程"——项目怎么管的、流程执行得规不规范。对象不一样，归属就不一样。这条边界考试很爱考。 再看评审的主要形式，教材列了三种：互为评审（Peer review）、走查（walk-through）、会议评审（Inspection）。我们可以按"正式程度"给它们排个队。互为评审最轻，就是同事之间互相看一遍，随时可以发生；走查是作者带着几个人把自己的文档或代码过一遍，边讲边收集意见，介于正式与非正式之间；会议评审最正式，有明确的角色分工——主持人、作者、记录员、检查人员，要按检查单逐条核对，发现问题要记录、要跟踪、要闭环。前面那张图里出现的那些角色，说的就是会议评审的阵势。 最后还有一句：代码的静态分析主要采用工具进行，但人工的代码评审也不可或缺。为什么人工不能省？因为工具只认规则，不认业务。工具能告诉你"这个变量定义了没用"，但告诉不了你"这段业务逻辑把用户等级算反了"——后者只有懂需求的人看得出来。 生活类比：静态测试像交稿前的校对。你不是把文章念给别人听（那是动态测试），而是拿着红笔逐字看——错别字、句子不通、前后矛盾、引用不准。文章还没"运行"，错误就能挑出一大半。
板书：静态测试＝不运行程序，检查"产物" ｜ 对象：需求文档 · 设计文档 · 代码 ｜ 手段：评审（Peer review / Walk-through / Inspection）＋ 代码静态分析 ｜ 边界：管理评审、流程评审 → QA，不属于静态测试 ｜ 工具为主，人工不可省
提问：下面四项里，哪一项不属于静态测试？A 需求文档评审；B 代码走查；C 管理评审；D 用工具扫描代码。
预设回答：
易错点 / 考点：三个高频混淆点。①把管理评审、流程评审错当成静态测试——记住"评产品是测试，评过程是 QA"。②把"互为评审 / 走查 / 会议评审"的正式程度记反——口诀"互看最轻、走查居中、会议最重"。③以为静态分析全靠工具——教材明确说人工的代码评审不可或缺。考试可能出选择题判断归属，也可能在案例题里问"以下哪些活动属于静态测试"。
过渡：三种评审形式里，用得最多、收益也最大的，是产品评审。它评的到底是什么？下一页我们专门讲。
口播：2.3.1 讲产品评审。先明确评审对象：需求文档、设计和代码。也就是说，从"要做什么"到"打算怎么做"再到"真的怎么写的"，每一个阶段的产物都要被检查一遍。 教材有两句话要划重点。第一句：通过软件评审，可以更早地发现需求工程、软件设计等各个方面的问题，大大减少大量的后期返工，将质量成本从昂贵的后期返工转化为前期的缺陷发现。说白了，就是把"花钱改"提前成"花时间看"。第二句：评审是对软件元素或者项目状态的一种评估手段，以确定其是否与期望的结果保持一致，并使其得到改进。请注意后半句"并使其得到改进"——评审的目的不是挑毛病，更不是追责，而是让产物变好。 为什么"更早"这么值钱？回到第 1 章讲过的缺陷修复成本曲线：同一个缺陷，在需求评审时发现，改的是一句话；在设计阶段发现，改的是一张图；到编码阶段发现，改的是代码加联调；等上线之后被用户发现，改的是补丁、是数据、是口碑，甚至可能是召回和赔偿。中间差的不是一点点工作量，而是数量级。 举个身边的例子。学生选课系统里有一句需求写着"系统应支持高并发选课"。评审时有人追问：高并发是多少？一千人同时点，还是两万人同时点？课程容量怎么算、超卖怎么处理？这些问题在评审桌上问出来，答案是改几行文字；如果等到选课当天系统卡死、课程被超选，再回头找原因，那就是一场事故。 所以测试人员参加产品评审，不是去"旁听"的，而是去提问、去挑二义、去预判可测性。你在评审会上问的每一个问题，都可能是后面省下来的一轮返工。
板书：2.3.1 产品评审 ｜ 对象：需求文档 → 设计 → 代码 ｜ 价值：后期返工 → 前期缺陷发现（质量成本前移）｜ 定义：评估产物是否与期望一致，并使其得到改进 ｜ 测试人员角色：提问 · 挑二义 · 预判可测性
提问："把质量成本从后期返工转化为前期发现"，这句话落到你自己的项目里，具体是哪一笔钱、哪一段时间？
预设回答：
易错点 / 考点：两个易错点。①记错评审对象：产品评审的对象是需求文档、设计和代码，不包括"人员绩效""项目进度"。②把评审等同于"找茬、考核"——教材强调评审是评估并改进产物。案例题里问"如何降低后期返工成本"，标准答案里一定有"尽早开展需求与设计评审"这一条。
过渡：产品评审里最先做、收益最大的是需求评审。需求评审判到底要解决哪些问题？下一页给了五类清单。
口播：这一页列出需求评审要解决的问题，一共五类。我把它当作一张"找茬清单"来用，五个字：错、漏、糊、多、乱。 第一类，不正确的需求认识。需求方说的是 A，写进文档变成了 B，大家还都以为写的是 A。比如学生选课系统里"允许学生退课"，被写成了"允许管理员替学生退课"，一个主语的变化，权限就全错了。 第二类，丢掉的需求点。该有的漏了——需求里通篇讲选课，却没人提"退课之后名额什么时候释放""密码忘了怎么找回"。这类问题的可怕之处在于，漏掉的东西不会在评审桌上喊疼，它会在上线后用户投诉时才出现。 第三类，模糊的描述。像"界面友好""操作简便""响应速度快""尽量兼容主流浏览器"，这些词人人能念、人人解释不同，全是不可测的表述。模糊的需求等于把决策权偷偷交给了开发，最后验收时谁都不认账。 第四类，多余的或没意义的需求。需求文档里塞进了根本用不上、或者与目标无关的东西：校园系统只有两万师生，却要求"支持百万级并发"。多写的不只是文字，是设计复杂度、开发工作量和测试成本。 第五类，不一致的理解。同一句话，开发读出一个意思，测试读出另一个意思，客户心里还有第三个意思。评审桌上不说穿，等到测试提了缺陷，开发一句"我按需求做的"，就变成了扯皮。 你可以把需求评审理解成给图纸做"体检"：这五类问题，就是最常查出的五种病。查得越早，图纸越好改。
板书：需求评审五类问题：① 不正确的需求认识 ② 丢掉的需求点 ③ 模糊的描述 ④ 多余的 / 没意义的需求 ⑤ 不一致的理解 ｜ 口诀：错 · 漏 · 糊 · 多 · 乱
提问："系统应具有良好的用户体验"——这句话属于这五类里的哪一类？为什么必须改掉才能继续往下做？
预设回答：
易错点 / 考点：五类问题容易混，尤其"模糊的描述"和"不一致的理解"——前者是单句话本身说不清，后者是多个人的理解对不上，而一句话模糊往往顺带造成理解不一致。判断题常把"模糊"归到"多余"里去设陷阱。答题时按"错、漏、糊、多、乱"五个字逐条对照，就不容易漏项。
过渡：知道了要解决什么问题，还得知道按什么尺子来判断。下一页给出需求评审的六条标准。
口播：需求评审不能凭感觉，得有一把尺子。教材给了六条标准：正确性、完备性、易理解性、一致性、易测试性、易追溯性。我给大家一个口诀：正确完备好理解，一致可测可追溯。 正确性，是说需求真的反映了用户的真实需要，没有写错、没有写偏。一条错误的需求，写得再漂亮也是负分。 完备性，是说该有的都有，功能、性能、约束、异常处理、边界情况，一个都不漏。判断完备性有个笨办法：拿业务流程从头走到尾，每一步都问一句"需求里写了吗"。 易理解性，是指描述清楚、没有二义，开发、测试、客户看同一句话，理解一致。凡是需要"再解释一下才明白"的需求，都不算过关。 一致性，是指需求之间不打架：文档内部不矛盾，跟上一版不矛盾，跟相关标准、跟已有系统也不矛盾。常见的坑是同一份文档里，前面写"学生最多选 6 门课"，后面写"最多选 8 门"。 易测试性，是指这条需求可以被验证、可以量化。这一条对在座的各位最直接——需求不可测，测试就没法设计用例，也没法判定通过与否。 易追溯性，是指每条需求都有唯一标识，能从需求追到设计、追到代码、追到测试用例，反过来也能从用例追回需求。有了追溯，才能回答"这条需求到底测了没有"和"这个用例是为哪条需求写的"。 这六条不是理论摆设。你们做课程设计的时候，拿这六条去审自己写的需求，能挑出一堆问题。
板书：需求评审六标准：正确性 · 完备性 · 易理解性 · 一致性 · 易测试性 · 易追溯性 ｜ 口诀：正确完备好理解，一致可测可追溯
提问：这六条里，哪一条最直接决定"测试能不能开工"？请说明理由。
预设回答：
易错点 / 考点：六条标准几乎每年都会以简答或选择的形式出现，务必按口诀背全，尤其别把"易测试性"漏掉——它最容易被学生忽略，却和工作最相关。另有一个高频概念题：需求"可测试"的标准表述是什么？答题要点是"可量化、有明确判定准则"。选择题里常把"可维护性""可移植性"混进来当干扰项——那是 ISO/IEC 25010 的质量特性，不是需求评审标准。
过渡：标准有了，方法呢？下一页讲怎么把需求评审真正做好——八条注意事项。
口播：这一页讲方法：怎么才能把需求评审做好。教材给了八条，我按"会前、会中、会后"帮大家归一下类。 会前两条。第一，有明确的评审标准，比如准备一份需求质量 checklist——就把上一页那六条当尺子。第二，熟悉评审内容，为评审做好准备。这一条最实在：参会前把需求文档读一遍，把看不懂的地方标出来，把想问的问题写下来。临时进会场才第一次读文档的人，只能跟着别人点头，评审会就变成了走过场。 会中四条。第三，该参加的人都需要参加。需求评审最怕两种缺席：写代码的没来，和真正用系统的人没来。第四，针对问题阐述观点，而非针对个人。可以说"这段描述会导致权限判断错误"，不要说"这是谁写的"。第五，从客户角度想问题，多问几个为什么。不要只问"这个功能怎么实现"，更要问"用户为什么要这个功能、不做行不行"。第六，在会前或会后提出自己建设性的意见。有些复杂意见当场说不清，写成书面意见反而更有效。 会后两条。第七，对发现的问题跟踪到底。记录下来的问题必须有人改、有人复核、有人关闭，不能散会即结束。第八，针对需求文档等报告问题——把问题落成书面记录，而不是停留在口头，否则过两天就没人认账。 最后还有一句总要求：检查需求定义是否合理、清楚，是否具有可测试性。这三问可以作为每次评审的自检清单。
板书：会前：明确 checklist · 熟悉内容做准备 ｜ 会中：该到的都到 · 对事不对人 · 站在客户角度多问为什么 · 提建设性意见 ｜ 会后：跟踪到底 · 书面报告问题 ｜ 自检三问：是否合理 · 是否清楚 · 是否可测
提问：评审会上，你发现同事负责的那段需求有严重二义性，很可能引发返工。你打算怎么开口？
预设回答：
易错点 / 考点：八条里最常考的是"针对问题而非针对个人"和"对发现的问题跟踪到底"，案例题常设"评审会开成了批斗会"或"问题记录了没人管"的情境，让你分析并给出改进措施。另外要记住：评审不是一次性会议，而是一个"发现—记录—修改—复核—关闭"的闭环，缺了后半段，前面全白做。
【思政落点 1】 请记住评审席上的两条底线。第一条叫"对事不对人"：我们用证据和事实说话，指出的是文档里的缺陷，不是同事的能力。第二条叫"跟踪到底"：发现了问题却因为怕麻烦、怕担责而放过，等于把风险转嫁给用户和团队。将来你们做测试、报缺陷，一定会遇到"这个 bug 报上去领导不高兴"的时刻——请记住，如实记录、如实上报，是对用户负责，也是对自己的职业信誉负责。质量这条线，是靠一个个不肯将就的人守住的。
过渡：需求评审判的是"做什么"。接下来，我们要评"打算怎么做"——设计评审。
口播：需求评审核对了"要做什么"，设计评审要核对"打算怎么做"。教材把设计评审的目标讲得很明确：保证需求能在设计中得到准确和完整的表示，也就是保证系统架构设计和产品功能规格说明书的质量。它评的核心产物，是设计规格说明书。 这一页的图给了四个抓手，我逐一拆开。 第一，系统架构。看分层是否清晰、模块之间耦合紧不紧、有没有单点、扩展和降级怎么考虑。架构评审是"高层"的评审，改起来最贵，所以最应该在纸面上就改掉。 第二，可测试性。这是测试人员最该盯的地方：接口有没有暴露、能不能 mock、关键路径有没有日志、内部状态可不可观测、能不能构造出需要的数据。可测试性差的设计，测试阶段只能靠"点点点"，覆盖率上不去，问题也定位不了。 第三，系统部署。部署拓扑、环境依赖、配置管理、升级与回滚方案，这些看着离测试很远，其实直接决定你能不能搭出一套可复现的测试环境。 第四，从高层到底层。设计评审不是一次过，而是层层往下：先审总体架构，再审模块设计、接口设计、数据库设计，最后审到产品功能规格说明书。借助 UML 等建模工具，用类图、时序图、状态图把设计"画出来"，画不清、看不懂的地方就是风险点。 这里面最需要各位记住的一句话是：不断从测试角度去问开发。设计评审不是开发的独角戏，测试人员问的每一个"这里怎么测""出错了怎么发现"，都是在为后面的测试省时间。
板书：设计评审 ｜ 目标：保证需求在设计中得到准确、完整的表示（系统架构设计＋功能规格说明书）｜ 抓手：系统架构 · 可测试性 · 系统部署 ｜ 方式：从高层到底层 · 借 UML 等建模工具 · 不断从测试角度问开发
提问：作为测试人员参加设计评审，你最该问的三个问题是什么？请给出你的清单。
预设回答：
易错点 / 考点：常见混淆是"设计评审"和"代码评审"的边界：设计评审看架构、接口、数据、部署与可测试性这些"纸面设计"，代码评审看具体实现。判断题还爱考"设计评审只在编码前做一次"——错，它随设计逐步细化、从高层到底层持续进行。记忆抓手："架构—可测—部署"三问，再加一句"从测试角度问开发"。
过渡：设计评审到底能拦下哪些问题？下一页给了一张很典型的清单。
口播：这一页把设计评审常能拦下的问题列了出来，我逐条讲，你会发现每一条都对应后面测试阶段的一场噩梦。 第一，是否有设计规范。团队有没有统一的分层方式、命名约定、接口约定、异常处理约定。没有规范，代码就是"每人一套写法"，后期维护和测试都无从下手。 第二，系统架构设计的不合理。比如该分的层没分、耦合过紧、职责不清，一个改动要牵动半个系统。架构一旦定型，改造成本极高。 第三，单点失效。某个组件、某个服务、某个数据库一旦挂掉，整条业务链就断了，既没有备份也没有降级。这类问题在设计图上看得见，在代码里反而看不出来。 第四，数据的不完整性、不一致性。字段该有的没有、该唯一的没约束、同一份数据在多处存储口径不一，最后表现成"同一个学生在两个页面看到的成绩不一样"。 第五，缺乏可测试性。没有对外接口、不能单独运行、状态不可观测、测试数据造不出来。这一条直接决定测试的效率和可信度。 第六，具体功能设计的问题。比如流程走不通、异常分支没考虑、权限设计有漏洞——这些是"在设计层面就能看出来的功能缺陷"。 结论很清楚：这些问题在设计评审阶段被发现，代价是改图纸；留到系统测试阶段，代价就是改代码、改数据、改部署，甚至推翻重来。
板书：设计评审常见问题：设计规范缺失 · 架构设计不合理 · 单点失效 · 数据不完整 / 不一致 · 缺乏可测试性 · 具体功能设计缺陷 ｜ 一句话：图纸上改便宜，代码里改昂贵
提问：为什么"缺乏可测试性"必须在设计评审阶段解决，而不是等测试执行时再抱怨？
预设回答：
易错点 / 考点："单点失效"和"数据不一致"是设计评审的经典考点，案例题里常给一段架构描述让你找问题，答题时要能说出"问题是什么、会造成什么后果、怎么改"。另外记住判断口径：凡是"改起来要动结构"的问题，都该在设计评审解决；凡是"改一行代码"的问题，可以留到代码评审。
过渡：评审是"靠人看"，静态分析是"靠技术和工具看"。2.3.2 节，我们从这里开始。
口播：进入 2.3.2，静态分析。这一页只有两张图，我请大家把它当成一张"全景图"来看，看图的时候抓三件事。 第一件，静态分析管什么。它不运行程序，而是把需求和设计模型、源代码当成分析对象，从中提取信息，检查程序逻辑上的各种缺陷和可疑的程序构造。所以它的产出通常不是"通过 / 不通过"，而是一批"值得你去看一眼"的发现。 第二件，谁来分析。一头是人，一头是工具。人靠经验和理解，工具靠规则和算法，两者不是替代关系，而是配合关系——下一页我们就把这两种情况拆开讲。 第三件，它站在整个测试流程的什么位置。静态分析站在最前面，紧挨着编码。这时候程序还没跑起来，问题还在"纸面"上，改起来的代价最小。 请带着一个判断标准去看这两张图：凡是"不运行被测程序、直接对代码或模型做检查"的，都是静态分析。至于它具体分成哪两种情况、用了哪些技术、怎么从代码里一层层抽信息，接下来两页会逐层展开。
板书：2.3.2 静态分析 ｜ 不运行程序，直接分析需求 / 设计模型 / 源代码 ｜ 两类执行者：人工（经验）＋ 工具（规则、算法）｜ 位置：紧贴编码，越早越便宜
提问：静态分析的产出，为什么通常不是"合格 / 不合格"，而是一批"可疑点"？
预设回答：
易错点 / 考点：别把静态分析窄化成"代码风格检查"。教材的定义包含两层：既看代码是否满足规范性、质量要求，也检查程序逻辑中的缺陷与可疑构造。选择、判断题常把"静态分析能发现运行时的性能瓶颈"设为错误选项——性能必须运行程序才能测，属于动态测试。
过渡：静态分析具体分成哪两种情况？下一页给出答案：人工检测和计算机辅助静态分析。
口播：静态分析分两种情况，教材讲得很清楚：一种是人工检测，一种是计算机辅助静态分析。 先说人工检测。它偏重于编码风格、质量的检验，由人对设计、代码进行分析，能有效地发现逻辑设计和编码错误。注意"有效"这两个字——人工最擅长发现的是"需要理解意图才能判断"的问题，比如命名与语义不符、注释和代码打架、边界条件想漏了、异常处理写反了。这些问题工具几乎看不出来，因为它需要知道"这段代码本来想干什么"。 再说计算机辅助静态分析。它利用静态分析工具对被测程序进行特性分析，从程序中提取一些信息，以便检查程序逻辑的各种缺陷和可疑的程序构造。工具的优势是快、全、不知疲倦：几十万行代码几分钟扫完，规则一视同仁，还能出各种度量报告。但工具的短板也很明显：它不懂业务，只会按规则报警，容易误报，也可能漏报。 所以两者是配合关系，不是替代关系。现实中的用法是：先用工具做"初筛"，让它把可疑点全扫出来、按严重程度排好序；再由人做"复判"，逐条判断哪些是真问题、哪些是误报、哪些虽然报警但业务上无所谓。工具负责广度，人负责深度。 打个比方，这就像体检。仪器负责测指标——血压、血糖、心电图，又快又客观；医生负责看报告下结论——这个指标确实高，但结合你的具体情况要不要紧。只信仪器会吓人，只凭感觉会漏病。
板书：静态分析两种情况 ｜ ① 人工检测：偏重编码风格与质量，擅长发现逻辑设计和编码错误 ｜ ② 计算机辅助静态分析：工具提取程序信息，检查逻辑缺陷与可疑构造 ｜ 关系：工具初筛（广度）＋ 人工复判（深度）
提问：你用一个静态分析工具扫了项目，报出 300 条告警。你打算怎么处理这 300 条？
预设回答：
易错点 / 考点：高频考点是把两种方式的能力边界搞混：人工检测偏重编码风格与质量，能发现逻辑设计和编码错误；工具负责特性分析、提取程序信息、发现可疑构造。还要记住工具不能替代人工。考试若问"静态分析能否完全自动化"，答案是否定的。
过渡：两种方式里，"计算机辅助静态分析"背后是一整套代码分析技术。下一页我们走进代码静态分析的流水线。
口播：这一页讲代码静态分析的原理。教材的定义是：通过词法分析（Lexer）、语法分析（Parser）、控制流分析、数据流分析等技术对程序代码进行扫描，验证代码是否满足规范性、质量要求等。 我们顺着流水线走一遍。第一步，词法分析。程序源代码经过词法分析器（Lexer），被切成一个个 Token，也就是各种不同种类的单词：关键字、标识符、常量、运算符、分隔符。这一步只认"词"，不认"句"。第二步，语法分析。Token 交给语法分析器（Parser），它做分析和语法检查，产出一棵抽象语法树（AST）——树形结构把"谁是谁的组成部分"表达清楚。走到这里，工具才算"读懂了句法"。 再往下是两座桥。一是控制流：通常用控制流图（CFG）来表示程序的控制流，节点是基本块，边是可能的跳转，分支和循环一眼就能看出来。二是数据流：通常用静态单赋值（SSA）来表示程序中数据的使用-定义链（Use-Def Chain），每个变量只被赋值一次，于是"这个值从哪儿来、到哪儿去"被追得清清楚楚。前面说的"变量定义了没用""用了没定义"，就是在这两座桥上被抓出来的。 教材还提到更高级的一类技术：静态分析可以采用模拟程序执行的技术，比如符号执行、抽象解释、值依赖分析，并采用数学约束求解工具进行路径约减或可达性分析，以减少误报、增加效率。通俗地说，符号执行就是拿"符号值"代替具体输入，把程序当数学题去推；路径一多就会"路径爆炸"，这时候用约束求解做路径约减和可达性判断，把走不到的路径砍掉，效率才上得来。 回头看前面那两张图：左边是"程序怎么被读懂"，右边是"读懂之后能查出什么"。这条流水线的每一级，都对应着一类能查出来的缺陷。
板书：程序 → Lexer（词法分析）→ Token → Parser（语法分析）→ AST ｜ 控制流：CFG ｜ 数据流：SSA（Use-Def Chain）｜ 高级：符号执行 · 抽象解释 · 值依赖分析 ＋ 约束求解（路径约减 / 可达性分析 → 减少误报）
提问：为什么"变量定义了没用""变量用了没定义"这类问题工具能轻松发现，而"这个循环少跑了一次"却很难？
预设回答：
易错点 / 考点：这一页的专业词最容易记混：Lexer 做词法分析、产出 Token；Parser 做语法分析、产出 AST；CFG 管控制流，SSA 管数据流。答题时别把 CFG 和 SSA 的功能对调。另一个高频点：符号执行、抽象解释属于"模拟程序执行"的静态分析技术，注意它们仍然不真正运行被测程序，别误判成动态测试——这是选择题的经典陷阱。
过渡：静态测试的手段讲完了——评审和静态分析。但它们有一个共同的局限：只能验证"符合不符合规格"。那"规格本身对不对"由谁来管？下一页，验证与确认。
口播：这一页是 2.3 节的收口，也是整章最经典的一对概念。教材说：软件测试是由"验证（Verification）"和"有效性确认（Validation）"活动构成的整体。注意"整体"两个字——它是两件事合起来的，缺一不可。 先看验证，Verification，教材给的原问句是：Are we building the product right？我们是否正确地构造了软件？也就是"是否正确地做事"，验证开发过程是否遵守已定义好的内容，验证产品满足规格设计说明书的一致性。它的参照物是——规格设计说明书。 再看有效性确认，Validation，原问句是：Are we building the right product？我们是否构造了正是用户所需要的软件？也就是"是否正在做正确的事"，验证产品所实现的功能是否满足用户的需求。它的参照物是——用户需求。 一个是"正确地做事"，一个是"做正确的事"。口诀记牢：验证看文档，确认看用户——跟规格说明书比是 Verification，跟用户需求比是 Validation。 举个例子。团队按设计说明书严格实现了"成绩报表导出"：字段、格式全对，验证 100% 通过。可用户真正想要的是"成绩一出来就自动推送到手机"，报表根本没人下载。功能没错，方向错了——这就是典型的"验证通过、确认失败"。 再打个比方：盖房子时监理拿图纸核对钢筋型号、承重墙位置，这是验证；你搬进去住才发现厨房小得转不开身——图纸不合你的需要，这是确认出了问题。 完整的 V&V 告诉我们：既要问"有没有按规格做对"，也要问"这个规格是不是用户真正要的"。前者靠评审、静态分析和测试查一致性，后者靠需求评审、用户验收和真实使用查价值。
板书：2.3.3 V&V ｜ Verification（验证）：Are we building the product right？正确地做事 → 对照"规格设计说明书"｜ Validation（有效性确认）：Are we building the right product？做正确的事 → 对照"用户需求"｜ 口诀：验证看文档，确认看用户
提问：一个项目的测试用例 100% 全部通过，能说明这个软件成功吗？为什么？
预设回答：
易错点 / 考点：这是全章最容易考、也最容易错的一对概念。①中译名易混：Verification 一般译"验证"，Validation 译"确认（有效性确认）"；英文题干问哪个对应哪个，一律按参照物判断。②参照物易混：记住"验证看文档、确认看用户"。③常见陷阱选项："验证和确认是一回事"——错，两者的手段与视角不同，但目标统一，都是为了提高质量。判断三步法：先找参照物 → 再定 V 还是 V → 最后判断这句描述对不对。另外记住：评审是静态的 V&V，测试是动态的 V&V。
【思政落点 2】 这一页其实藏着一个很硬的职业态度：不要满足于"文档上通过了"。规格说明书也是人写的，它也可能错、也可能过时。真正严谨的工程思维，是既不迷信文档，也不迷信自己的实现，而是始终追问一句"用户到底要什么"。将来你们做测试、写报告，如果发现"功能全部通过但没人愿意用"，请如实写出来，而不是把不利结论藏起来——诚实报出真相，比给出一个漂亮的通过率更重要。这就是科学精神在测试岗位上的样子。
过渡：到这里，2.3 节的三块内容——产品评审、静态分析、验证与确认——全部讲完，静态测试与动态测试这条主线也就闭合了。下一页，我们把视角从测试方法转到测试工作本身，看看软件测试到底分哪些层次、有哪些岗位分工。