又到了期末复习的时候。软件测试这门课说简单也简单说麻烦也麻烦。简单在于它不像数据结构或算法那样需要你写一堆代码麻烦在于概念多、术语密、案例分析绕稍不注意就把黑盒和白盒混在一起把测试级别和测试类型搅成一锅粥。我当年期末复习的时候就犯过这个毛病抱着教材从第一章翻到最后一章合上书感觉什么都记住了一到做题又模棱两可。这篇文章就是帮你把软件测试基础练习的重点重新梳理一遍。不是照搬教材而是按期末考试的出题习惯来拆解哪些概念必须背、哪些计算必须会、哪些案例必须能现场设计。适合正在准备软件测试期末考试的在校同学也适合刚入行想快速建立测试知识框架的初学者。耐心看完配合题目练一遍期末应该能稳不少。1. 先摸清楚这门课到底在考什么1.1 软件测试的目标与定义别只会背“验证”教材上对软件测试的定义一般都这么写在规定条件下对程序进行操作以发现程序错误、衡量软件质量并对其是否满足设计要求进行评估的过程。这句话有两个关键词容易被考试问到验证和确认。验证英文叫Verification核心问题是“我们有没有正确地构造产品”也就是对照需求文档、设计文档检查每一步做对没有。确认英文叫Validation核心问题是“我们构造的产品是不是正确的产品”也就是最终交付的东西到底能不能满足用户的真实需求。区别在哪里举个生活化的例子你照着食谱做一道菜验证是检查你有没有按食谱的步骤放调料、控制火候确认则是这道菜端上桌客人吃了一口说好吃这才是确认成功。做测试不是单纯“找bug”而是通过验证和确认两条线为软件质量提供信心。期末选择题如果出现“软件测试的目的是什么”千万不要选“证明程序没有错误”正解是“发现程序中尽可能多的错误”这个坑年年有人踩。1.2 七条测试原则每个都能对应一个反面场景测试原则是期末的高频考点经常以判断或简答形式出现。核心是这几条每一条你都要能举出例子来说服阅卷老师你真的理解了。测试能证明缺陷存在但不能证明缺陷不存在这就是第一个原则。哪怕你设计了1000条用例全都通过也只能说明这1000条覆盖到的路径没问题覆盖不到的地方依然可能藏着问题。测试越早介入发现缺陷的成本越低这一点对应软件工程里的“缺陷放大模型”需求阶段的一个理解偏差留到系统测试阶段可能需要花几十倍的代价去修复。所以测试不是等代码写完才开始需求评审、设计评审阶段就要参与。缺陷集群性、杀虫剂悖论这两条也经常成对出现。缺陷集中在少数模块里经验丰富的测试员会把资源倾斜到高风险区域这就是集群性。测试用例反复使用同一批数据、同一套路径时间久了再难发现新问题就好像杀虫剂用多了虫子产生抗药性所以要不断补充新的测试输入。剩余两条——测试活动依赖于测试背景、不存在缺陷不一定代表没有部署失败前者说的是不同行业、不同场景下测试策略不一样后者说的是就算测出来的bug全修完了也可能因为环境配置、用户使用习惯等问题导致上线后依然不顺利。复习的时候把每一条原则对应到一个具体的场景里记比死背定义要牢固得多。1.3 测试级别和测试类型一张表分清很多同学把测试级别和测试类型混在一起答一考试就露馅。级别强调测试的粒度阶段类型强调测试的目的和角度它们是两个维度的东西。软件测试通常分为四个级别单元测试、集成测试、系统测试、验收测试。单元测试针对最小模块一般由开发人员自己完成集成测试关注模块之间的接口和交互系统测试把整个软件系统当作整体验证是否满足需求验收测试由用户或代表用户的团队来做决定软件是否可以被接受。集成测试的策略也是简答题常客。自顶向下集成需要写桩模块用来模拟被测模块的下层调用自底向上集成需要写驱动模块用来模拟上层调用大爆炸集成一次性把模块全部组装起来适合模块规模不大的项目探索式或叫混合式集成则结合了前两种的优点。测试类型就更多了功能测试看需求功能是否实现性能测试看响应时间、吞吐量、资源占用压力测试看系统在极端负载下的表现回归测试看修改代码之后有没有把原有功能弄坏冒烟测试则在版本提测后先快速跑一遍主流程如果主流程都过不了直接退回给开发不进行详细测试。另外还有安全测试、兼容性测试、易用性测试等。复习时可以用“级别回答开发流程的阶段类型回答测试关注的角度”这一句话来区分。2. 黑盒测试用例设计最容易现学现用的得分点黑盒测试把程序看作一个不透明的黑盒子不关心内部逻辑只关心输入和输出。期末考试里黑盒设计方法是大题中的绝对主力尤其是等价类划分和边界值分析基本属于必考内容。如果你能把这两类题完整地按步骤写出来卷面分数至少保住三成。2.1 等价类划分先列有效再找无效等价类划分的思路是把无穷多的输入数据按是否产生相同效果分成若干类从每类中选择有代表性的数据作为测试用例。它最重要的一个原则是不仅要有有效等价类还要有无效等价类。很多新手只想着测合法输入忘了程序要能优雅地处理非法输入结果丢分丢得莫名其妙。拿一个典型题目来演示。假设有一个报名系统要求输入年龄规定年龄在1周岁到120周岁之间为合法。有效等价类是1到120之间的整数无效等价类至少有三个小于1的整数、大于120的整数、非数字或小数等异常输入。注意小数虽然数字上落在1到120之间但如果需求明确要求整数小数就要归入无效等价类。题目没有明确说整数时你可以先写明前提假设这也是一种得分策略。组织答案时按下面这个格式写基本不会失分确定输入条件年龄为1~120的整数。划分等价类并编号有效等价类1~120的整数无效等价类小于1的整数、大于120的整数、非整数小数、字符、空值等为每个等价类设计一个用例编号对应写明输入值和预期输出。实际考试时题干还可能给多个输入条件比如同时有姓名长度、邮箱格式、密码长度你要对每个条件分别划分等价类再组合出测试用例。组合时不需要把所有有效类做笛卡尔积全覆盖通常取一条覆盖所有有效类的用例再为每个无效类单独设计一条用例。这样既能验证正常流程也能验证异常流程。2.2 边界值分析六个点轻松拿下计算类题目边界值分析是基于一个朴素又真实的经验程序最容易在边界处出错。写代码时“”和“”写混、循环的起止条件差一位这些都是经典bug所以测试用例必须重点覆盖边界。还是以上面的年龄条件“1~120的整数”为例。边界是1和120那么需要测试的典型边界值包括上点1、120离点0、121有时还要针对内点取2、119。如果你学过边界值分析的“两值法”和“三值法”简单记忆就是上点是边界上刚好合法的点内点是边界内侧紧邻的点离点是边界外侧紧邻的点。对1的下边界上点就是1内点就是2离点就是0对120的上边界上点就是120内点就是119离点就是121。期末计算题里经常出现“如果输入范围是a到b请设计边界值测试用例”的题目。标准处理方式是对最小值a取a-1、a、a1三个值对最大值b取b-1、b、b1三个值再加上一个正常范围内的代表值一共7个用例基本能覆盖边界附近的常见缺陷。如果把每个边界点的“刚好等于”和“刚刚越界”都覆盖到那这道大题就可以拿满了。边界值分析要配合等价类划分一起用等价类确定测哪些类别边界值确定每个类别里最值得测的具体数值。两个方法不是对立的是互补的。答题时先写“采用等价类划分边界值分析方法”再展开具体用例阅卷老师一看就知道你学明白了。2.3 决策表和状态转换两个容易被忽视的高频点决策表法适合处理多个条件之间相互组合、不同组合对应不同动作的业务逻辑。比如登录功能有账号存在与否、密码正确与否、账号锁定与否三个条件每个条件有“是/否”两种取值理论上共2的3次方等于8种组合。决策表由条件桩、动作桩、条件项和动作项组成看起来复杂其实画起来就是一张规规矩矩的表格。考试中遇到这类题建议先把条件桩和动作桩列出来再逐步填入条件项的组合。条件过多导致组合爆炸时可以通过合并相同动作的条件项来化简。这个方法虽然比等价类和边界值繁琐但考察频率不低尤其是“根据以下业务规则设计决策表”这类题一旦掌握就是送分题。状态转换法关注的是被测系统在不同状态之间如何迁移。比如一个订单有“待支付”“已支付”“已发货”“已取消”四种状态事件“支付”让待支付变成已支付“取消”可能在待支付和已支付两个状态下都允许操作“发货”只能在已支付状态下发生等等。考试时可能给你状态图要你列出状态迁移表或者反过来根据需求描述补全状态图。答题时注意区分合法迁移和非法迁移很多题目专门考查“非法状态下操作应被拒绝”这一点。3. 白盒测试与覆盖率概念题和计算题的结合体白盒测试又叫结构测试或逻辑驱动测试测试人员需要了解程序内部结构和逻辑路径以此为基础设计用例。期末考题一般集中在覆盖率概念、圈复杂度计算、根据流程图画独立路径这几个方面。3.1 语句覆盖、判定覆盖、条件覆盖三者千万别混先看一段简单的伪代码输入变量a、b if (a 1 b 5) c a b else c a - b 输出c语句覆盖要求每条可执行语句至少被执行一次。上面这段代码只要执行一次if条件为真的分支就能覆盖“c a b”这条语句执行一次if条件为假的分支就能覆盖“c a - b”。所以设计两条用例就能达到语句覆盖。但问题在于万一程序里有一句“if (x 10) x 10”藏在某个分支里语句覆盖如果不满足执行条件就可能漏掉。语句覆盖是最弱的标准。判定覆盖也叫分支覆盖要求每个判定的“真”“假”分支都至少走一次。上面代码只有一个判定设计一条条件为真、一条条件为假的用例就能同时满足语句覆盖和判定覆盖。但如果判定本身由多个逻辑条件组成比如“a1 b5”判定覆盖不能保证每个子条件都取过不同值。条件覆盖要求每个判定中的每个条件都取到真和假两种可能。对“a1 b5”来说就是要让a1出现真和假让b5出现真和假。设计用例时要分别关注a和b而不是只看整个if的结果。再往上还有判定/条件覆盖和条件组合覆盖条件组合覆盖要求对每个判定的所有条件组合都至少出现一次。复习时可以简单记语句覆盖最弱条件组合覆盖相对最强但也不是最强中的最强因为还有路径覆盖。3.2 圈复杂度计算记住三个公式就够圈复杂度是白盒测试部分最常考的计算题它表示程序中独立路径的数量。计算方法常用三种V(G) 区域数V(G) E - N 2其中E是控制流图中的边数N是节点数V(G) P 1其中P是判定节点数区域数就是控制流图把平面分成的封闭区域的个数加上图外背景区域。画流程图时一个顺序执行部分算一个节点一个判定算一个节点边的数量按箭头算。圈子不圆的同学在计算时容易数错边我的建议是在图上用数字标好每个节点、每条边再去套公式别用眼睛扫一遍就填答案。以上面的伪代码为例。它有一个if判定流程图中判定节点引出两个分支最后汇合。判定节点数P1所以V(G)P12也就是说需要两条独立路径才能做到基本路径覆盖。如果代码里有嵌套的if判定节点数就要逐个数清楚嵌套内的每个if都算一个判定节点。这里有个常见的易错点and和or连接多个条件时如果在一个if内部判定节点按一个算但条件覆盖考虑的是每个独立条件各自取真取假。3.3 独立路径与实际用例设计步骤独立路径的概念在白盒测试里特别重要。一条独立路径至少包含一条此前路径没走过的边基本路径集的路径数量等于圈复杂度数值。考试可能会给一小段代码或流程图要求你列出独立路径并设计测试用例。操作步骤一般是把代码转换成控制流图每个处理框是节点箭头是边。确定圈复杂度V(G)。从起点到终点找V(G)条独立路径。为每条路径设计一组输入使程序实际走该路径并写出预期输出。还是用上面的伪代码路径一走if为真的分支路径二走if为假的分支。设计用例时要给出a和b的取值比如路径一取a5、b2使a1和b5同时成立路径二取a0、b10使判定整体为假。写完路径后还要简单说明预期的c值分别是7和-10。这样一套完整的白盒考试答案结构就出来了。如果题目还要求写“测试结果分析”记得加上“执行结果与预期一致说明该路径逻辑正确”这类结论。4. 缺陷管理与测试文档主观题别再空着期末试卷里除了选择判断和用例设计还有一类让人头疼的题目就是简答和案例分析题给你一段缺陷描述让你填写缺陷报告单或者问你缺陷从提交到关闭经历哪些阶段又或者让你写出测试计划包含哪些要素。很多同学不是不会而是不知道按什么结构来答写了两三行就憋不出来。其实这类题有套路掌握了模板就非常稳。4.1 缺陷生命周期从发现到关闭的完整状态流转缺陷生命周期描述了一个bug从被测试人员发现到最后关闭或被拒绝的完整过程。标准的生命周期一般是这样测试人员提交缺陷状态为新建测试负责人审核后确认是有效缺陷将状态改为已确认并指派给开发人员状态变为已分配开发人员修复完成后状态改为已修复测试人员在新的版本上验证修复是否生效如果验证通过状态改为已关闭。如果验证明明还复现或者开发说自己修复了但测试一跑还是原样就把状态重新置为重新打开或新建继续跟踪。除此之外还有几种特殊状态开发人员认为这不是缺陷的可以标记为拒绝或无效优先级不高、这版本修不完的可以标记为推迟或延期处理如果发现是需求理解不一致导致的可能转到讨论阶段。考试时画状态流转图不现实但你可以用文字加箭头把状态列出来再补充说明“每条状态流转都有相应的触发条件”。这样答既清晰又不啰嗦。4.2 缺陷报告的关键字段优先级和严重性是两回事填写缺陷报告单是经典实操题型题干通常会给你一段bug描述比如“在登录页面输入正确用户名和密码点击登录按钮后无响应浏览器控制台报500错误”。你要把这段信息拆解到不同字段里。缺陷报告单的字段很多但核心是这几点缺陷编号、缺陷标题、所属模块、发现版本、发现环境、优先级、严重性、操作步骤、预期结果、实际结果、附件或截图。最容易失分的是优先级和严重性的区别。严重性衡量缺陷对软件质量的破坏程度比如系统崩溃、数据丢失就算严重程度高界面按钮文字错别字就算严重程度低。优先级衡量修复缺陷的紧迫程度从业务流程是否被阻塞的角度来看。一个严重性很高但当前用户根本走不到那个功能的bug优先级可能并不高一个严重性很低的文案错误如果客户马上要验收首页优先级也会临时调高。答题时要分开写不要混为一谈。操作步骤一定要写清楚前置条件和复现路径。比如前置条件是“已登录用户账号拥有管理员权限”复现路径是“进入系统设置→点击用户管理→选择某个用户→点击删除按钮”预期结果是“弹出二次确认对话框确认后用户被删除”实际结果是“点击删除按钮直接删除且无任何提示”。缺少前置条件、缺少具体路径都是扣分项。如果你是自主设计缺陷报告的题目可以按下面这个模板来写缺陷标题【功能缺陷】删除用户时缺少二次确认 所属模块用户管理模块 环境Windows 10 / Chrome 120 / 测试版本V1.2 严重性中 优先级高 操作步骤进入用户管理页面→点击用户“A”的删除按钮 预期结果弹出是否确认删除的对话框点击确定后才删除 实际结果点击后立即删除用户无任何确认提示 备注附加截图及抓取的接口日志4.3 测试计划、测试用例与主观题的答题套路测试计划是测试工作的顶层设计包含的内容有不少测试目标、测试范围、测试策略、资源安排、进度安排、风险与应对措施、准入标准与准出标准。在很多判断题里会把“测试计划只需要列出测试用例”这种说法拿来考察你需要能一眼看出这种表述的错误。测试计划关注“做什么、谁来做、什么时候做、怎么做”的层面而测试用例关注“具体输入什么、操作什么、预期什么”的层面。测试用例的字段通常包括用例编号、用例名称、优先级、前置条件、测试数据、操作步骤、预期结果、实际结果、测试结果。答题时设计测试用例不要把预期结果空着也不要写“程序正常运行”这种空话一定要具体到“页面显示XX提示信息”“返回值为XX”“数据库记录被更新为XX状态”。阅卷老师看到具体的预期结果才能判断你真的会设计用例而不是在凑字数。遇到“简述集成测试中自顶向下策略的优缺点”这类简答题可以按“定义过程优缺点适用场景”的结构回答。先用一句话说明自顶向下集成是从顶层模块开始按控制层次逐步向下把子模块用桩模块代替再说明优点是能较早验证主要控制结构缺点是桩模块成本高底层模块错误可能较晚暴露最后补一句适用于控制结构清晰、顶层逻辑稳定的项目。这种结构化答题法几乎能应付大多数测试理论简答题。5. 自动化测试概念和期末冲刺的复习策略自动化测试在期末试卷里占的比重一般不高但一定会有那么一两道概念题比如“什么是自动化测试”“自动化测试的优缺点”“什么场景适合自动化测试”。这些基础概念靠死记也能答但如果能把它们串进整个测试框架里理解答题会更有底气。5.1 自动化测试的基本原则理解比背答案重要自动化测试本质上是把人为操作的测试活动转化为由工具或脚本自动执行的过程。它的核心价值不是替代手工测试而是解放测试人员重复劳动同时提升回归测试的效率。所以那些一次性需求、界面尚未稳定的模块不适合大手笔做自动化而频繁回归、功能稳定、执行步骤重复度高的场景比如登录、注册、订单主流程等就比较适合自动化。考试常考的点是自动化测试的优缺点。优点可以从效率、一致性、覆盖率、资源消耗几个角度展开脚本执行速度快凌晨也能跑全量回归重复操作每次都按相同脚本执行避免人为主观差异脚本能覆盖手工很难执行的庞大用例集同时解放人力资源去关注探索性测试。缺点是开发维护脚本的成本高需求变更后脚本需要跟着改对测试人员的编程能力也有要求再加上自动化工具或框架本身的引入成本小型项目可能得不偿失。回答优缺点时能给出“什么场景该用、什么场景不该用”的分析得分就会更高。5.2 期末冲刺怎么安排别把时间耗在低效抄写上到了临近考试光靠从头翻教材效率太低。我个人比较推荐按知识点分组刷题把每一章最核心的概念做成自测卡片来记忆。比如看到“等价类划分”你心里要能马上说出它的步骤和适用场景看到“缺陷”要能立刻说出生命周期各状态和缺陷报告单的关键字段。说不出来就优先巩固这个点而不是拿起一套题从头刷到尾。另一个高效方法是用“穿线法”把分散的知识串起来。比如给你一个登录模块你可以从需求评审、设计测试用例、执行测试、记录缺陷、回归验证到最终输出测试报告完整走一遍流程把课程里几乎所有知识都融进去。需求阶段先分析输入条件和业务规则用等价类边界值设计用例测试执行阶段记录实际结果与预期不符的地方缺陷管理阶段填写缺陷单并跟踪生命周期缺陷修复后做回归决定整个模块是否可以进入验收。这个练习如果能在考试前做两遍比背十遍章节框架都管用。5.3 一道综合题的自查式解法最后分享一个自查思路适用于各种综合设计题。拿到题目后不要急着下笔先自问三个问题题目给出的是需求规格还是实现代码需求规格用黑盒方法实现代码用白盒方法。输入空间是连续范围、离散集合还是条件组合连续范围用边界值等价类离散集合枚举等价类多条件组合考虑决策表。答题时需要包含前置条件、具体输入、操作步骤和预期结果吗只要题目说“设计测试用例”这四要素就都别落下。按这个思路走即使题目背景陌生也不会出现思路跑偏的情况。我见过有同学拿到综合题第一反应是回忆教材原文结果花了十分钟背了一段不相关概念最后连用例都没设计完。正确姿势是先判断题型和出题意图再动手写得分效率会高很多。6. 一些实战中踩过的坑和复习建议第一不要过度依赖所谓“题库”。某个知识点的题目确实见过原题再现的概率也有但一旦换个场景、换个数据死记答案的人就会露馅。比如等价类划分题目从“年龄1到120”换成“成绩0到150”或“金额100到5000”核心做法完全一样就看你会不会迁移。理解规则永远比记住答案可靠。第二做计算题一定要看清判定条件。圈复杂度计算的流程图中如果判断条件是复合条件比如“A and B”“A or B”数判定节点时是按一个判定节点来算的。但如果题目明确要求按条件组合覆盖设计用例就需要把A和B分别列出来。审题这一步往往就拉开了一大批人的分数。第三考前不要只背名词解释。软件测试的期末卷子名词解释比重不大应用分析才是大头。哪怕你把“回归测试”的定义背得滚瓜烂熟碰到“版本更新后应该优先执行哪种测试”的选择题还是要能瞬间反应过来是回归测试。概念记住意思和应用场景比逐字背诵更有用。第四读题目时把关键词圈出来。看到“从用户角度”“不考虑内部结构”就圈出来对应黑盒看到“覆盖”“路径”“分支”就对应白盒看到“止损”“退出标准”就对应测试计划或缺陷管理。这些关键词是答题的指路牌能帮你快速锁定知识模块。写到这里软件测试基础练习的重点基本过了一遍。说实话这门课的知识量不算大难的是把概念和应用真正对应起来。期末复习阶段与其焦虑地翻书不如动手把典型题目按“审题—选方法—写用例—给结论”的流程练一遍。练得多了就会发现试卷上的题目再怎么变也逃不出等价类、边界值、判定覆盖、缺陷生命周期这些核心话题。祝你复习顺利考试稳过。
