### 【2.79】探索式测试定义（3 分钟） > **口播**：前面几页我们把静态测试、动态测试、手工测试、自动化测试这些"测试方式"逐一过了一遍，现在来到一个很有意思、也特别容易被误解的概念——探索式测试。这一页给出的定义，来自 Cem Kaner 在 2006 年 6 月 6 日软件测试协会会议上的主题演讲《Exploratory Testing After 23 Years》。标题里的"23 年"往前一推，就是 1983 年——也就是说，这个概念从出现到被系统总结，走了二十多年。 > 定义是这样说的：探索式测试是一种软件测试风格（Style），它强调独立测试人员（Individual Tester）的个人自由和职责（Personal Freedom and Responsibility），为了持续优化其工作的价值（Value），将测试相关学习（Test-related Learning）、测试设计（Test Design）、测试执行（Execution）和测试结果分析（Analysis）作为相互支持的活动，在整个项目过程中并行地执行。 > 请大家抓住四个关键词。第一是"风格"，它不是一种具体技术，也不是一个工具，而是一种做事的方式；第二是"独立测试人员"，强调个人的自由和职责——自由给你了，责任也一起给你，你不能说"用例没写我就不会测"；第三是四个活动：学习、设计、执行、分析，它们是相互支持、并行进行的，不是先学完再设计、设计完再执行那种串行；第四是"持续优化工作的价值"，这句是灵魂——探索式测试不是乱测，它每一步都在问"我这一轮测下来，对项目到底有什么价值"。 > 生活里最好的类比是"老医师问诊"。新手照着检查单一项一项勾，老医师一边听你说、一边追问、一边当场决定下一个该查什么，学、想、查、判断是同时发生的。软件行业里也一样，一个刚上线、需求天天改的移动端产品，就特别适合用这种风格去探。 > 课件备注里还给了两个词：Interpretation 是"解释、说明"，Mutually 是"互为、相互地"。后者正好对应定义里那句"相互支持的活动"，请大家顺手记住。 **板书**：探索式测试（ET）→ 风格 Style ≠ 技术 → 独立测试人员：个人自由＋职责 → 学习→设计→执行→分析（相互支持、并行）→ 持续优化价值｜出处：Cem Kaner 2006.6.6 演讲（概念源头 1983 年） **提问**：定义里说四个活动是"并行执行"的，那它跟"想到哪测到哪"的乱测，差别到底在哪里？ **预设回答**：①"没差别，就是随机点一点"——典型错误。要追一句：随机点的人有没有在记录、分析、调整下一轮策略？没有分析就没有探索，那只是碰运气。②"差别在于有没有用例"——部分对，探索式测试也可能有松散的用例甚至测试章程，关键是学习和设计在执行现场实时发生。③"差别在于测试人员的能力和责任心"——说得好，这正是定义里"个人自由和职责"的落点：自由越大，越依赖自律。 **易错点 / 考点**：①把探索式测试等同于 Ad-hoc（即兴）乱测——错，它是"有结构的即兴"。②把"并行"理解成"不做设计"——错，设计还在，只是挪到执行过程中去做。③选择、判断题常考这个定义的出处：Cem Kaner，2006 年主题演讲，概念源头可追到 1983 年。记忆口诀：**风格、独立、四活动并行、价值驱动**。 **过渡**：知道了探索式测试是什么，我们自然会问：它跟传统的、按用例一条条执行的测试，到底该怎么摆？下一页课件给出一条谱系。 --- ### 【2.80】基于脚本的测试 vs. 探索式测试（3 分钟） > **口播**：这一页是课件里第一张"对照图"，它把各种测试做法排成了一条从"规范"到"自由"的连续谱。谱的最左端是 Fully Scripted Testing，完全脚本化的测试，用例写得满满的，一步一步照着执行；往右走是 Automated Tests，自动化测试；再往右进入中段，出现了 Test Design、Test Execution，以及松散的测试用例和测试场景；接着是 Bug Hunting，缺陷猎捕；再往右是 Exploratory Testing 探索式测试、Product Exploration 产品探索；最右端是 Ad-hoc Testing，完全自由的探索，想到哪测到哪。课件还摆出了"角色扮演测试"这一类做法，提示我们中段存在大量介于规范与自由之间的测试形式。 > 这张图最想告诉大家的一句话是：**这不是一道二选一的判断题，而是一条光谱**。左端追求可控、可重复、可度量；右端追求灵活、应变、靠人的判断。真实项目里你几乎不会只用一端，而是看阶段、看风险、看被测对象，来决定自己站在谱上的哪一段。回归测试、验收测试、需要反复执行的冒烟测试，就往左边站，越自动化越好；一个全新的功能、一份含糊的需求、一个还没被任何人碰过的模块，就往右边站，靠人去探。 > 为什么会有这么一条谱？因为左右两端的成本结构不一样。规范脚本前期投入大：要分析需求、要写用例、要评审，但一旦写好就能反复执行，边际成本很低；自由探索前期几乎不用投入，立刻就能开始，可它高度依赖执行者的水平和状态——今天这个人能发现的问题，换个人可能一个都发现不了。 > 所以判断标准很朴素：**这段测试会不会被重复执行很多次？需求是不是已经稳定？**两个都"是"，就往规范一侧走；两个都"否"，就往自由一侧走。 > 顺带说一句，课件把 Ad-hoc 放在最右端，也是在提醒我们：探索式测试虽然位于谱的右侧，但不等于最右端那个"完全自由的探索"，它是有方法、有记录、有分析的——这一点上一页讲定义时已经埋了伏笔。 **板书**：规范 ←——————————→ 自由 Fully Scripted Testing → Automated Tests → Test Design / Test Execution / 松散的测试用例、测试场景 → Bug Hunting → Exploratory Testing → Product Exploration → Ad-hoc Testing（完全自由的探索）｜中段还有角色扮演测试等形式 **提问**：同一个登录功能，如果它是长期维护的核心模块，你把它放在谱上的哪一段？如果它是本周才加的一个实验性开关呢？ **预设回答**：①"核心模块放左边，实验性功能放右边"——标准答案。追问为什么：核心模块回归次数多、需求稳定，脚本化和自动化的收益最高。②"都放右边，人工测发现的问题更多"——要纠正：人工发现的问题"看起来多"，但不可重复、不可度量，回归时无法保证不漏。③"都放左边，全写成自动化"——也要纠正：需求都没定的实验功能写脚本是浪费，需求一改脚本全废。 **易错点 / 考点**：①最易错：以为探索式测试就等于 Ad-hoc 测试。课件把两者分列在谱上的不同位置，Ad-hoc 是"完全自由的探索"，ET 是右侧但有方法的一档。②选择题常考两端的名称：最规范端是 Fully Scripted Testing，最自由端是 Ad-hoc Testing。③简答题常问"什么时候用脚本化、什么时候用探索式"，答题三步法：**看重复次数 → 看需求稳定性 → 看风险与人员水平**。 **过渡**：谱系图讲完了，下一页课件把两端拉成一张逐条对照表，我们一条一条看。 --- ### 【2.81】ET vs. ST -2（3 分钟） > **口播**：这一页是探索式测试（ET）和基于脚本的测试（ST）的第二张对比页。上一页看的是它们在谱系上的位置，这一页看的是一条一条的工作方式差异。先看左边的 Scripted Testing，脚本化测试：第一，先设计、后执行，顺序不能倒；第二，强调逻辑分析，靠文档和推理把用例推出来；第三，关注需求和测试文档，文档是它的主战场；第四，有明确的测试标准——什么算通过、什么算失败，事先定死；第五，强调评审、可控，用例要评审，执行要可控；第六，总体上严谨、规范。 > 再看右边的 Exploratory Testing：第一，学习、设计和执行并行，边学边设计边测；第二，上下文驱动，测什么、怎么测，由当前这个产品、这个版本、这段时间的上下文决定，而不是照搬模板；第三，强调个人能力，同样的时间，高手和新人的产出差距极大；第四，Test Oracle，测试判定准则，这是重点——脚本化测试的判定标准写在用例里，而探索式测试常常要测试人员现场判断"我看到的这个现象算不算缺陷"；第五，关注与产品的交互，测试人员是真的像用户一样在用；第六，拥抱变化、乐趣，需求变了不慌，反而觉得有新东西可探。 > 我们把它压成一句话：**脚本化测试是把不确定性提前消灭在文档里，探索式测试是把不确定性留到现场、用人的判断去消化。**左边赌的是"我事先想得够全"，右边赌的是"我现场反应够快"。所以左边最怕需求变更，一变，用例全废；右边最怕人员不行，人一弱，测试就变成瞎点。 > 页面上标的是"ET vs. ST -2"，说明这是对比的第二页——第一页看谱系位置，第二页看工作方式，两页合起来才是完整的一对。 **板书**：ST：先设计→后执行｜逻辑分析｜重需求和测试文档｜标准明确｜强调评审、可控｜严谨规范 ET：学习＋设计＋执行并行｜上下文驱动｜靠个人能力｜Test Oracle 现场判定｜关注与产品交互｜拥抱变化、乐趣 一句话：ST 把不确定消灭在文档里；ET 把不确定留到现场消化 **提问**：右边提到探索式测试要有 Test Oracle，那如果一个测试人员说"我觉得这里不对劲，但我一时说不清为什么"，这算不算发现了缺陷？ **预设回答**：①"不算，说不清就不是缺陷"——要纠正：发现异常只是第一步，接下来要做的是最小化复现、对照需求文档和同类产品的行为，把它变成可描述、可举证的缺陷，说不清只是起点。②"算，凭直觉就行"——也要纠正：缺陷必须能复现、能说明影响，否则开发无法修、也无法验证。③"要看能不能稳定复现、是否偏离需求和用户期望"——好答案，这正好落到缺陷报告的要素上。 **易错点 / 考点**：①Test Oracle 常被译错成"测试预言"，标准说法是"测试判定准则/预期结果来源"，考试要能解释它回答的是"凭什么判断这次测试通过了"。②简答高频：ST 与 ET 的差别，至少要答出"是否先设计后执行""是否上下文驱动""对文档和标准的依赖程度"三条。③易错：把"拥抱变化"当成"不做计划"——ET 同样要有测试章程和时间盒。 **过渡**：测试做完了，结果就摆在那里，那我们怎么判断"测够了没有、这个版本能不能发"？下一页讲测试结果与过程评估。 --- ### 【2.82】测试结果和过程评估（3 分钟） > **口播**：前面几页讲的是怎么测，这一页讲的是测完之后怎么看。课件把它分成两件事：测试结果评估和测试过程评估。这两件事经常被混为一谈，其实一个看的是产品，一个看的是我们自己的工作。 > 先看测试结果评估，课件给了三个分析角度。第一，分析测试覆盖率，目的是了解测试是否充分——覆盖率高不代表质量一定好，但覆盖率低一定说明还有大片区域没人碰过，这是"测没测到"的问题。第二，做缺陷的趋势分析，看缺陷是越来越多还是越来越少，从而了解缺陷是否已经收敛——如果每天发现的缺陷还在往上走，说明这个版本远没到稳定的时候。第三，做缺陷的分布分析，看缺陷集中在哪几个模块、集中在哪几类严重程度，再基于缺陷来评估当前被测试版本的质量。注意这里的落脚点是"版本质量"，也就是为"这个版本能不能发布"提供依据。 > 再看测试过程评估。课件讲得很清楚：结合测试计划来进行评审，相当于把计划的测试活动和实际执行的活动做比较，了解测试计划执行的情况和效果。说白了就是"计划 vs 实际"的偏差分析：计划里要执行的用例，实际只跑了一部分，差在哪里？计划的回归时间被压缩了，是人力不够还是环境卡住了？过程评估的目的不是追责，而是发现流程里的堵点，让下一轮计划定得更靠谱。 > 记住这三层顺序：**先看结果够不够（覆盖率），再看问题收敛没有（趋势与分布），最后回过头看自己干得怎么样（过程偏差）。**很多同学写测试总结只写"测了多少条用例、发现多少缺陷"，那只是结果的一半；把覆盖率、趋势、分布和计划偏差补齐，才叫会评估。 **板书**：测试结果评估 → 覆盖率（是否充分）→ 缺陷趋势（是否收敛）→ 缺陷分布（集中在哪里）→ 版本质量判断 测试过程评估 → 计划的活动 vs 实际的活动 → 偏差与效果 → 改进下一轮计划 三层顺序：测没测到 → 问题收没收敛 → 自己干得怎么样 **提问**：如果 A 版本发现 100 个缺陷，B 版本发现 30 个缺陷，能不能直接说 A 的质量比 B 差？ **预设回答**：①"当然更差，缺陷多"——典型错误。追问：这 100 个是随便点出来的，还是照着系统化的用例测出来的？测试强度不同，发现数就不可比。②"要看缺陷是否收敛、分布在哪里、测试投入有多少"——好答案，三个角度全用上了。③"要看严重程度"——对，同样是 100 个，90 个界面文案错误和 90 个数据计算错误，结论完全相反。 **易错点 / 考点**：①最大误区：把"缺陷总数"直接等同于"质量水平"，必须结合测试充分性和投入来看。②"收敛"要会解释：新增缺陷数随时间下降，并且严重缺陷已基本关闭。③选择题常考两种评估的区分：结果评估看产品与版本，过程评估看计划执行。口诀：**覆盖看充分，趋势看收敛，分布看集中，过程看偏差。** **过渡**：到这里第 2 章的概念就全部讲完了，我们花几分钟把整章串成一张全景图。 --- ### 【2.83】本章小结（3 分钟） > **口播**：这一页是全章"收口"的地方，一共五条，我们一条一条过。 > 第一条：缺陷是质量的对立面。这句话的意思是，谈缺陷之前必须先谈质量——质量是什么？是软件满足规定需求和隐含需求、也就是满足用户期望的程度。所以课件提醒我们，要借助产品质量模型和使用质量模型来理解质量：产品质量模型看的是软件本身的属性，使用质量模型看的是软件被真正使用起来以后，对用户任务产生了什么效果。 > 第二条讲缺陷的因果链条：缺陷是内部错误，它在外部表现为失效。这一点非常关键——用户看不到你代码里那行写错的条件判断，用户只看到"点结算没反应"。而缺陷的来源很多，课件点了三个大源头：需求定义、设计和代码。需求写歪了，后面怎么努力都歪；设计漏了边界，代码再漂亮也补不回来。课件还强调一句：缺陷要尽早发现、尽早修正，否则带来的劣质成本越大——这就是我们前面讲过的成本放大效应，越往后修越贵。 > 第三条列了软件测试方式的几组对比：静态 vs 动态、主动 vs 被动、手工测试 vs 自动化测试、基于脚本的测试 vs 探索式测试。这一条是"横向"的，讲的是同一件事可以用哪些不同方式去做。 > 第四条列了单元测试、集成测试、系统测试和验收测试。课件这里字面写的是"软件测试方式"，但列出来的这四项其实是"测试级别"，也有教材叫测试阶段。易错点就在这里：方式回答"怎么测"，级别回答"在哪一层测、由谁来测"，这是两条不同的轴线。后面讲单元测试与集成测试的章节会专门展开这四级。 > 第五条讲软件测试的工作范畴，一共六件事：测试需求分析、测试策略制定、测试计划、测试设计、测试执行、测试结果和过程评估。这六件事就是大家做课程设计时要走完的完整链路，也是本课程第 3 篇各章的主题。 > 课件的落脚点写得很清楚：帮助同学们建立软件测试的整体全景图。这张图请务必装进脑子里——纵向是级别，横向是方式，中间贯穿的是六项工作，最上面压着的是质量与缺陷这条主线。 **【思政落点 1】** 科学精神·质量观·诚信。质量模型和缺陷分类不是背概念，而是在训练一种"凡事讲证据、讲分类、讲因果"的科学态度：说质量要有指标，说缺陷要有复现和影响。再往前一步就是职业诚信——测试人员发现了缺陷却隐去不报，等于把风险留给用户、留给同事。所以这一章真正要立的规矩是：数据如实记录，不利结果不隐瞒。 **板书**：①缺陷＝质量的对立面（产品质量模型＋使用质量模型）②缺陷：内部错误→外部失效；来源＝需求/设计/代码；越早修越便宜 ③方式：静态 vs 动态、主动 vs 被动、手工 vs 自动化、脚本 vs 探索 ④级别：单元→集成→系统→验收 ⑤工作范畴：需求分析→策略→计划→设计→执行→结果与过程评估 **提问**：请用一句话说出"方式"和"级别"的区别，并举一个例子。 **预设回答**：①"方式是怎么测，级别是在哪一层测。比如对登录模块做单元测试——单元测试是级别；用白盒还是黑盒、手工还是自动化，是方式。"——标准答案。②"级别就是阶段，方式就是方法，差不多"——要纠正：混用会导致计划里写不清"谁在什么阶段用什么手段"。③"方式包含级别"——错误，正好用课件第四条那句表述来纠偏。 **易错点 / 考点**：①课件第四条文字写的是"软件测试方式"，但列的是单元/集成/系统/验收，实质是级别——考"测试级别有哪些"就答这四项。②顺序题：六项工作范畴的先后顺序（需求分析在计划之前）不能颠倒。③本章小结本身是简答题高发区，建议按"质量—缺陷—方式—级别—工作范畴"五段来背。 **过渡**：概念都清楚了，接下来是两件要动手做的事——课后作业和本章的思考题。 --- ### 【2.84】作业（2 分钟） > **口播**：这一页是本课程的第一次课后作业，我把要求念清楚，也讲清楚我到底想看什么。作业要求是：选择同类的两到三个产品，比如词典类、视频播放器这一类，对它们做一次质量比较。具体四件事：第一，详细地分析它们的外部质量和使用质量；第二，列出它们之间有明显差异的质量属性；第三，列出这类软件在需求评审时需要关注的功能点；第四，列出这类软件在设计评审时需要关注的非功能特性。 > 先解释两个词，不然大家容易写偏。外部质量，指的是从外面看得见、可以测量的质量特性，比如功能是否齐全、界面是否好用、运行是否流畅、在不同设备上是否兼容。使用质量，指的是放到真实使用场景里去看：它能不能帮用户把任务顺利完成、效率高不高、用户满不满意、有没有风险。同样一个词典软件，外部质量看它词库多大、查询多快；使用质量看你查一个生词到看懂例句，一共花了多少秒、中间有没有被广告打断。 > 第三条和第四条是把"比较"转换成"评审关注点"，这是本次作业最有价值的部分。需求评审关注功能点，就是在需求阶段要问清楚哪些功能、哪些流程、哪些边界；设计评审关注非功能特性，就是性能、安全、兼容、易用、可维护这些"不是功能却决定体验"的属性。为什么这么设计？因为这两个正是测试人员最应该提前介入的会议。 > 交作业时我提醒三点：一是写清你比较的是哪几个产品、什么版本、什么时候测的，这叫测试环境信息；二是质量属性的差异要给出证据，比如截图或具体操作步骤，不能只写"感觉 A 比 B 好"；三是把"我认为需要关注的点"和"它实际上做到了什么"分开写，前者是你的判断，后者是事实，混在一起就分不清哪是分析、哪是臆测。 > 这门课的考核方式是过程性考核加上课程设计作品与答辩，这份作业就是过程分的一部分，请认真做。 **板书**：同类产品 2–3 个（词典、播放器…）→ ①外部质量＋使用质量分析 ②有明显差异的质量属性 ③需求评审关注的功能点 ④设计评审关注的非功能特性｜作业要求：写清版本与环境、差异要给证据、判断与事实分开写 **提问**：如果让你比较两款词典 App，你会用哪个指标来判断"使用质量"的差别？ **预设回答**：①"看谁的词库大"——那是外部质量里的功能属性，还没到使用质量。②"查同一个生词，从输入到看完释义和例句的总耗时、总步骤数"——好答案，这就是任务级的效率指标。③"看应用商店评分"——可以当参考信号，但要追问：评分受价格、广告、运营影响，不能当作质量测量的主证据。 **易错点 / 考点**：①易错：把"使用质量"当成"用户体验好不好"这种纯主观感受，它其实是围绕任务效果、效率、满意度、风险的可观察指标。②功能点与非功能特性容易写反：需求评审数功能，设计评审谈非功能。③这份作业的内容与期末课程设计里的"测试需求分析"直接相关，别当形式作业交。 **过渡**：作业之外，课件还留了三道思考题，这三道题就是本章的考点清单，我们把它讲透。 --- ### 【2.85】思考题（4 分钟） > **口播**：这一页的三道思考题，请大家一定当成复习提纲来用，因为本章期末要考的点基本都在里面。我把参考答案一题一题讲。 > 第一题：为什么说缺陷是质量的对立面？先明确质量的定义——质量是软件满足规定需求和隐含需求、也就是满足用户期望的程度。而缺陷恰恰是违背需求与期望、导致结果不正确的问题。所以两者是同一个坐标轴上的两端：质量是"满足期望"的度量，缺陷是"违背期望"的实证。缺陷越多、越严重，质量就越低；反过来，想让质量高，最直接的动作就是减少缺陷，尤其是减少严重缺陷。答题时一定要走三步：先给质量下定义，再讲缺陷是"违背"，最后落到"数量与严重程度共同决定质量水平"，三步缺一不可。 > 第二题：为什么静态测试和动态测试是一对对立统一体？"对立"讲的是手段：静态测试不运行程序，靠阅读、评审、检查文档和代码来发现问题；动态测试必须运行程序，通过输入数据、观察输出来发现问题。一个不动、一个要动，这是手段上的对立。"统一"讲的是目标和互补关系：两者的目标完全一致，都是发现缺陷、评价质量；而且它们能覆盖对方覆盖不到的地方——静态测试擅长抓需求里的二义性、设计上的缺陷、编码规范与逻辑问题，这些问题程序跑起来未必暴露；动态测试擅长验证运行时的真实行为，比如计算错误、性能瓶颈、并发问题，这些问题光看代码很难断定。所以标准答案是：手段对立，目标统一，功能互补，缺一不可。 > 第三题：为什么说测试需求分析是测试计划、测试设计的基础？一句话，测试需求分析回答的是"测什么"——测试项有哪些、范围到哪里、优先级怎么排、可测性如何。这些答案一旦有了，测试计划才有依据：范围定了才能估工作量和资源，优先级定了才能排进度、安排人力，风险点清楚了才能定应对措施。测试设计同样依赖它：只有明确了测试项和它的可测性，才能决定用哪些方法、覆盖到什么程度、判定准则是什么。反过来想，如果跳过测试需求分析直接写计划，就会出现"计划里排满了场次，却不知道要测什么"；直接写用例，就会出现"用例写得漂亮，却漏了最重要的业务场景"。这正是后面"测试需求分析与测试计划"那一章要专门解决的问题。 > 三道题串起来其实就是本章的主线：先有质量与缺陷的概念，再有静态与动态两类手段，最后用测试需求分析把概念接进工程流程。 **板书**：①质量＝满足规定需求＋隐含需求（期望）；缺陷＝违背需求与期望 → 同一坐标轴两端，缺陷的数量与严重程度决定质量水平 ②静态（不运行程序：阅读、评审、检查；抓需求二义性、设计缺陷、规范问题）↔ 动态（运行程序：抓计算错误、性能、并发）→ 手段对立、目标统一、功能互补 ③测试需求分析＝回答"测什么"（测试项、范围、优先级、可测性）→ 计划据此定范围、资源、进度、风险；设计据此定方法、覆盖与判定准则 **提问**：如果只允许你做静态测试或者只允许你做动态测试，你选哪一个？为什么？ **预设回答**：①"选动态，能跑起来才算真测试"——要纠正：跑起来之前，需求二义性和设计缺陷已经在里面了，动态测试往往只能看到症状，说不出根因。②"选静态，成本低"——要纠正：不运行就永远无法确认运行时行为和系统级质量。③"两个都不能只选一个"——正确，正好回扣"对立统一"。 **易错点 / 考点**：①把静态测试等同于"看代码"——不完整，需求文档、设计文档、测试用例甚至用户手册的评审都属于静态测试。②只答"一个运行一个不运行"而漏掉"互补"，最多得一半分。③判断题高频：静态测试也能发现缺陷（对）；缺陷是内部错误、失效是外部表现（对）；测试需求分析在测试计划之后进行（错，必须在前）。口诀：**对立看手段，统一看目标，基础看"测什么"。** **过渡**：三道思考题之后，本章还留了一个动手实验，我们把它的要求说清楚。 --- ### 【2.86】实验：完成一个简单的测试过程（3 分钟） > **口播**：这是本章的实验，名字很朴素——完成一个简单的测试过程。注意"过程"两个字，它不是让你背概念，而是让你完整走一遍"分析—执行—记录—报告"的闭环。 > 第一步，选被测对象。课件给了两个来源：优先用你在软件工程课或其他课程里开发过的软件系统，从里面选定一到两个功能模块；如果手上没有系统，就用课件给的两个练习站点——saucedemo 和 automationpractice。这两个都是业界经典的练习用电商站点，功能完整、又没有真实业务风险，随便点、随便试，非常适合第一次做功能测试。 > 第二步，先做初步的功能测试分析。课件提了两个具体问题：一是了解功能操作的路径，也就是从哪进、点几步能到；二是明确要输入哪些数据，以及有哪些特殊、异常的数据或操作。这一步就是"设计"，不要一上来就乱点，先把入口、路径、输入项写清楚。比如登录功能，你要问：输入框接受什么格式？空值、超长值、错误密码、特殊字符算不算异常？能不能只用键盘 Tab 和回车走完全流程？ > 第三步，执行手工测试。课件的要求很形象：像用户使用产品那样操作软件，进行手工测试，发现缺陷并记录。请务必做到"操作有路径、缺陷有步骤、现象有截图"。记录一条缺陷至少要有四样东西：怎么操作、期望什么结果、实际什么结果、能不能稳定复现。 > 第四步，完成一个非规范的测试报告。这里的"非规范"我要特别强调：它的意思是第一次不要求你套正式模板、不要求完整的测试计划与评审流程，而不是"可以随便写"。报告里至少要有被测对象与版本、测试的功能模块、用了哪些数据和异常输入、发现的缺陷清单，以及你自己的一句结论。 > 具体细节见教材第 40 到 41 页。这个实验是后面课程设计的基础动作，工具上先不做硬性要求，先把"发现缺陷并把它说清楚"这件事做到位。 **板书**：①选对象：自研系统 1–2 个功能模块／saucedemo、automationpractice ②初步分析：操作路径＋输入数据（含特殊、异常） ③手工测试：像用户一样用，发现并记录缺陷 ④非规范报告（非规范 ≠ 随便写）｜详见教材 P40–P41｜一条缺陷四要素：操作步骤、期望结果、实际结果、可复现性 **提问**：在登录功能里，你会设计哪些"特殊、异常"的数据或操作？ **预设回答**：①"输入错误的密码"——对，但太基础，继续追问：空用户名、超长字符、前后空格、大小写、SQL 特殊字符呢？②"连续点五次登录按钮"——好例子，属于异常操作，考验防重复提交。③"点登录后再按浏览器后退，看状态对不对"——很好的思路，这是流程与状态类的异常路径。教师点评：特殊与异常输入通常从"格式、长度、边界、顺序、频率、状态"六个方向去想。 **易错点 / 考点**：①把"非规范报告"理解成可以只写结论——报告必须有证据链。②缺陷记录只写"这里有 bug"——工程和考试都要求给出复现步骤与期望/实际的对比。③容易漏掉"分析"这一步直接开测，导致测试没有针对性；而这一步恰恰是本章测试设计意识落到手上的地方。 **过渡**：这节课的内容就到这里，最后我们用一句话帮大家收个尾。 --- ### 【2.87】感谢聆听（1 分钟） > **口播**：好，以上就是本节课的内容。这一章讲到这里，我们把软件测试的基本概念过了一遍：缺陷是质量的对立面，缺陷是内部错误、在外部表现为失效；测试方式有静态与动态、主动与被动、手工与自动化、基于脚本与探索式；测试级别有单元、集成、系统、验收；工作范畴从测试需求分析、测试策略、测试计划、测试设计、测试执行，一直到测试结果和过程评估。请回去把本章小结那张全景图和三道思考题结合起来复习，作业和实验按要求提交。 > 我是广东金融学院的周宇文，课件和资料会发到课程群，有问题随时找我。感谢聆听，下次课我们进入新的内容。 **板书**：质量与缺陷 → 方式（静态/动态、主动/被动、手工/自动化、脚本/探索）→ 级别（单元/集成/系统/验收）→ 工作范畴（需求分析→策略→计划→设计→执行→评估）｜下次课预告 · 作业与实验提交提醒 · 联系方式 **提问**：请用一句话说出本章你最有收获的一个概念。 **预设回答**：①"缺陷是内部错误，失效是外部表现"——能把这两层分开，说明因果链理解了。②"静态测试不运行程序、动态测试运行程序，两者互补"——分类思维到位。③"测试需求分析必须先于测试计划"——工程顺序意识有了，这正是后面课程设计的起点。 **易错点 / 考点**：收尾前再点一遍本章三个高频错点——探索式测试不等于 Ad-hoc 乱测；"软件测试方式"那一条列出的其实是测试级别；测试需求分析在计划与设计之前，顺序不能颠倒。 **过渡**：第 2 章到此结束，下次课我们进入新的一章，开始讲具体的测试方法与技术。