前阵子帮团队筛测试岗的简历一天翻了七十多份几乎每隔三五份就能看到「全国大学生软件测试大赛」这几个字。有个同学写着省赛获奖我随口问了一句给你一个年龄输入框允许填 18 到 60你打算设计几条用例、分别取什么值他先背了等价类和边界值的定义背得很顺我又追问如果这个框同时还限制「只能数字」「不能为空」你一共设计几条、怎么组合他就卡住了。这就是我写这篇东西的原因。软件测试这项技能在比赛里被拆成了很具体的题目可很多人准备的方向偏了——把它当成一门「知识点考试」狂背概念、狂背 API而不是当成一次小型的项目交付演练。比赛本身确实是很好的能力凭证但它真正值钱的地方是逼你把「测试用例设计」「自动化脚本」「缺陷定位」这三件事在一个限时环境里串起来做完这个体验和后来进公司接需求、写用例、搭自动化、跟着版本跑回归是同一种肌肉。下面这些内容适合三类人看正在准备参赛的在校生、刚入行想从「点点点」往外走的测试新人以及想搞清楚面试官到底在问什么的朋友。我会把赛题背后的技术点拆开讲也会把我在实际项目和带新人过程中踩过的坑一并倒出来。1. 从赛场到工位这套赛题为什么和真实项目的活儿高度重合比赛当天的场景其实很朴素一台电脑、一个在线评测平台、几个小时的倒计时、题目按通过情况给分。你写完脚本点提交平台跑一遍红绿分明。这种「提交—判分—返工」的循环和真实项目里「提测—跑回归—挂了几条—连夜定位」是同一种压力只是压缩到了几小时里。我在公司带过几个打过比赛的新人最明显的差异不是工具用得熟不熟而是他们习惯先想「这个场景有哪些分支」再动手写脚本。没打过比赛的新人往往拿到需求就开始点点到哪算哪回归的时候才发现漏了一大片。这个思维习惯的差别基本上决定了一个测试工程师前两年的成长速度。1.1 赛项方向拆开看每一条都对应一类岗位以我接触到的赛项方向来看大体可以分成这么几类各年的赛项名称和数量会有调整具体以当年的赛项说明为准这里讲的是能力模型赛项方向主要考察的能力对应的岗位日常Web 应用测试元素定位、表单校验、多页面流程、自动化脚本与断言Web 功能测试、自动化测试移动应用测试元素识别、手势操作、原生与混合页面切换、多分辨率适配App 测试、移动端自动化开发者测试白盒单元测试编写、覆盖率分析、依赖打桩测试开发、开发自测嵌入式测试C 语言、硬件抽象、异常与时序场景嵌入式软件测试用例设计综合等价类、边界值、判定表、场景法、错误推测所有测试岗的地基这张表的意义不在于「哪个赛项更高级」而在于它帮你确认自己现在缺哪一块。很多人一上来就想冲移动端自动化结果元素定位写不稳脚本跑十次挂八次时间全耗在调环境上用例设计的分一分没拿。1.2 用例设计是地基脚本只是手脚自动化脚本的本质是把已经设计好的用例翻译成机器能执行的指令。这话听起来像废话但它的推论很硬设计阶段漏掉的分支脚本写得再花哨也补不回来。举个我印象很深的例子。有一类题是折扣计算订单金额满 100 减 20满 200 减 50会员再打 9 折折扣不叠加但取优惠最大的那个。不少人拿到题就开始写脚本先测 99、再测 100、再测 200看着挺完整。但真正的分支在哪里在「100 到 200 之间用哪个规则」「刚好 200 时会员价和满减谁更划算」「金额为 0 和负数怎么处理」「金额输入小数怎么处理」。这些分支不是靠写脚本能想出来的是靠设计用例时把条件桩和动作桩一条条列出来。还有一件特别现实的事评测平台的脚本通常是「一断全断」的。你第 3 步断言失败抛异常第 4 到第 10 步的分数就全丢了。所以在赛场上脚本的抗中断能力和用例覆盖率一样重要。我一般的做法是每个独立场景做成一个测试方法互不依赖失败一个不影响其他所有断言失败都用 try 包住继续往下走最后统一汇总。这个习惯带到工作里同样管用——回归脚本里一条用例挂掉不该拖垮整个回归任务。2. 测试用例设计方法拿分最稳的一块也是最容易被忽视的一块理论题和综合题里用例设计方法的性价比是最高的。它不需要你装环境、不需要你调依赖纯靠脑子但很多人恰恰在这里失分因为背了定义不会用。我见过太多人能把等价类的定义一字不差地背出来却没法在一道具体题目里正确切分出有效区间。方法本身不难难的是「从题干里抠出条件」。题干不会写得像教科书那样规整它会把限制藏在描述里比如「用户名长度 6 到 20 位支持字母、数字和下划线且必须以字母开头」。这一句话里其实藏了四个约束条件任何一个没抠出来你的用例集就是残缺的。2.1 等价类与边界值先划区间再取三个点我自己的固定流程是这样先分类后取值。把每个输入拆成有效等价类和无效等价类。有效等价类往往只有一两个无效等价类往往一堆——空值、超长、超短、类型错误、格式错误、特殊字符每一个都是独立的一条。边界值只取三类点上点、离点、内点。上点就是边界本身离点是紧挨着边界外侧的那个值内点是区间内部随便一个正常值。拿「年龄 18 到 60」举例可以这样组织取值类型具体值预期结果上点下边界18通过上点上边界60通过离点下边界外侧17拒绝离点上边界外侧61拒绝内点30通过类型异常abc、12.5拒绝空值空、纯空格拒绝这里有个很常见的误区很多人只测 17 和 61不测 18 和 60。但边界本身恰恰是最容易出错的地方开发写判断时用的是还是只有测了上点才能发现。我在真实项目里抓到的「临界值判断写反」这类缺陷两只手数不过来。2.2 判定表与因果图多条件组合题的标准解法当题目里出现「同时满足若干条件才产生某个结果」的时候等价类和边界值就不够用了得上判定表。判定表的做法是把所有条件列成条件桩把所有可能的动作列成动作桩然后穷举条件的真假组合逐行确定应该执行哪个动作。比如一个登录场景条件是「用户名正确/错误」「密码正确/错误」「验证码正确/错误」三个条件二值一共 8 行。写完之后再做化简某些条件在某些动作下根本不影响结果那两行就可以合并。提示判定表列完之后一定要做化简不然 4 个条件就是 16 行、5 个条件就是 32 行时间根本不够。化简的依据是「这一列和另一列的动作完全一致且只有一个条件的取值不同」那就说明这个条件在该场景下无关。因果图本质上和判定表是同一件事的两种表达判定表更适合写成用例因果图更适合在纸上快速理清逻辑。赛场上我建议直接用判定表因为它天然就是一列一条用例转换成本最低。2.3 正交实验与错误推测时间不够时的取舍策略组合爆炸是绕不开的。如果题目里有 4 个下拉框每个 3 个选项全组合 81 条你不可能全写。这时候要么用正交表挑出代表性组合要么用 Pairwise两两组合覆盖的思路。正交表的用法不是玄学它保证任意两个因素的所有取值组合都至少出现一次。三因素三水平的标准表是 L9(3⁴)9 行就能覆盖 81 种组合的关键部分。当然前提是你要能识别出「哪些因素之间存在交互」——如果两个因素完全独立那就不需要正交各测各的就行。错误推测法听起来不正式但在真实项目里用得最多也最需要经验。我个人的「错误清单」大概是这些空值、纯空格、前后带空格很多系统不做 trim admin和admin会被当成两个账号超长输入尤其是那种卡在数据库字段长度附近的值全角字符、特殊符号、纯表情符号输入数字框里输入负数和科学计数法1e5重复提交、连点两次按钮中途刷新页面、后退再前进时间相关跨天、跨月、闰年 2 月 29 日这份清单是我这些年攒下来的比任何教材上的错误推测示例都好用。比赛里时间紧把它当检查表对着题目扫一遍往往能多捞出两三分。3. Web 与移动端自动化脚本写不出来多半是定位和等待没搞明白自动化赛项大家抱怨最多的就是「脚本在我电脑上跑得好好的提交上去就挂」。这句话我听过太多次了在工作里也一样。绝大多数情况下问题不在业务逻辑而在两个地方元素定位不稳和等待没处理好。这两个问题的本质是同一个你的脚本对页面状态的假设太强了。你假设元素已经存在、假设它可见、假设它可点击、假设跳转已经完成。只要有一个假设不成立脚本就挂。3.1 元素定位优先级从稳到不稳定位方式的稳定性是有明确排序的我一般按这个顺序找id最稳前提是它是唯一的、不动态生成的。name 或稳定的自定义属性比如>from selenium.webdriver.common.by import By # 推荐语义清晰页面结构调整不容易波及 submit_btn driver.find_element(By.CSS_SELECTOR, form#login .btn-primary) # 慎用绝对路径结构一变就断 # driver.find_element(By.XPATH, /html/body/div[2]/form/div[3]/button)移动端还多一层坑原生页面和 WebView 页面是两套体系。Appium 里必须显式切换 context否则你用 Web 的定位方式去原生页面上找元素必然找不到。混合应用里经常出现「列表页是原生的点进去是 H5」的情况切换时机没抓准脚本就会卡在找不到元素上。3.2 等待策略隐式等待、显式等待和硬等待的取舍关于等待我踩过的坑足够写一篇长文。结论先给出来等待方式做法适用场景风险硬等待sleep(3)只适合调试浪费时间且 3 秒不一定够隐式等待全局设置超时找不到元素就轮询整体兜底与显式等待混用时行为不可预期显式等待等待某个具体条件成立推荐的主方案条件写错会一直等到超时隐式等待和显式等待混用是个经典雷区。很多驱动实现里隐式等待会拉长显式等待的实际耗时导致本来 5 秒能过的用例拖到 30 秒。我的习惯是全局隐式等待设一个很小的值比如 2 秒做兜底核心交互点全部用显式等待。from selenium.webdriver.support.ui import WebDriverWait from selenium.webdriver.support import expected_conditions as EC wait WebDriverWait(driver, 10) # 等到按钮真正可点击而不是只等到它出现在 DOM 里 btn wait.until(EC.element_to_be_clickable((By.ID, submit))) btn.click() # 等到结果区域出现文字而不是等固定秒数 wait.until(EC.text_to_be_present_in_element((By.ID, result), 登录成功))presence_of_element_located和element_to_be_clickable的区别值得单独说一句前者只保证元素在 DOM 里存在后者保证它可见、可点击。页面没渲染完的时候元素可能已经在 DOM 里了但还盖着遮罩层这时候去点击会直接抛异常。凡是点击操作就用element_to_be_clickable别用 presence。3.3 断言分层决定得分上限的不是操作是断言很多人写脚本操作写得飞起断言只有一句assert True或者干脆不写断言。这在赛场上是致命的——评测平台是靠断言判断你这条用例过没过没有断言就等于没有结论。我的断言分三层页面级跳转后的 URL、页面标题、关键提示文案。元素级目标元素的文本、属性、是否可见、是否被禁用。数据级如果题目给了接口或数据库入口直接核对数据落库结果。再加一个容易忽略的点断言的信息要写清楚。assert result 登录成功和assert result 登录成功, f实际返回的是 {result}在调试阶段的效率差好几倍。赛场上时间紧张一条信息完整的失败提示能帮你省下十分钟。4. 开发者测试与白盒覆盖语句、判定、条件、路径到底差在哪白盒这块是我觉得最有意思、也最容易被低估的部分。它的核心问题是你写的测试用例到底覆盖了代码的哪些执行路径而「覆盖」这件事不同的标准差别极大。很多同学知道「语句覆盖」也知道「分支覆盖」但说不清两者为什么不同的场景下结果会不一样。我拿一段最朴素的代码来讲int check(int a, int b) { if (a 0 b 0) { return 1; } return 0; }4.1 六种覆盖率标准用同一段代码对照覆盖标准含义这段代码需要的最少用例语句覆盖每行代码至少执行一次a1, b1走到 return 1再补一组走到 return 0判定覆盖每个判断的真假分支各走一次同上两组即可条件覆盖每个原子条件的真假各出现一次a0 真/假、b0 真/假 各一次条件判定覆盖判定覆盖 条件覆盖通常 2 到 3 组条件组合覆盖每个条件的所有组合都出现a0 与 b0 的 4 种组合各一次路径覆盖所有可能路径都执行这里没有循环路径数等于组合数关键差别在哪条件覆盖不保证判定覆盖。举个典型反例用例一是 a1, b-1a 的条件真、b 的条件假用例二是 a-1, b1a 假、b 真。这两条用例把「a0 真、a0 假、b0 真、b0 假」都覆盖到了但整个if判定始终为假return 1那一行从来没被执行过。这就是为什么工业界做安全关键软件时往往要求更强的标准比如修件判定覆盖MC/DC。注意覆盖率不是越高越好而是要盯着「未覆盖的那部分」。赛场上如果你的覆盖率卡在 85% 上不去别急着加用例先去看报告里标红的分支是什么往往是一个异常分支——比如某个参数为 null 的兜底逻辑。找到它一条用例就能补上。4.2 单元测试的打桩把依赖挡在门外白盒题里经常出现「被测函数依赖了外部接口」比如一个查询余额的函数里调了远程服务。这时候你不能真的去连外部服务得打桩。打桩的本质是用可控的假对象替换不可控的真依赖让测试只关注被测逻辑本身。在 Java 里通常用 Mockito在 Python 里用unittest.mockfrom unittest.mock import patch patch(service.remote_client.query) def test_balance_when_remote_fails(mock_query): # 模拟外部服务抛异常验证被测代码的兜底逻辑 mock_query.side_effect TimeoutError(timeout) result get_balance(u001) assert result is None mock_query.assert_called_once_with(u001)这里最重要的是最后那句assert_called_once_with——它验证的不只是返回值还有调用行为。真实项目里我遇到过「重试逻辑写错导致外部接口被调了三次」的缺陷就是靠这类断言抓出来的。4.3 嵌入式 C 单元测试的特别之处嵌入式赛项和白盒赛项的差别主要在三个地方没有操作系统、内存受限、代码里直接读写硬件寄存器。第三点是最大的障碍。如果被测代码里直接写着REG_CTRL | 0x01你在 PC 上根本跑不起来。所以要做的第一件事是识别出哪些是硬件相关代码把它们打桩掉。常见做法是在头文件里定义一组可替换的接口测试时链接另一份空实现。编译环境上嵌入式测试一般是在 PC 上用宿主编译器跑单元测试工具链常见的组合是 Unity 或 CppUTest 加 GCC再配合覆盖率工具生成报告。这里有几个务实的经验别在赛场上试图跑真实硬件纯软件打桩跑得快也稳。注意数据类型的宽度int在 PC 上是 4 字节在目标平台上可能是 2 字节涉及溢出判断的用例要显式用int16_t这类定长类型。注意无符号数的回绕for (u8 i 10; i 0; i--)这种写法是死循环是很典型的嵌入式缺陷题。5. 环境、工具与现场操作这些「非技术」细节经常直接决定名次技术能力差不多的情况下名次往往被这些细节决定。我见过太多人准备了三个月最后因为环境没配好、时间分配崩了、提交前没自查白白丢分。5.1 开赛前的环境清单比赛前一周就该把下面这张表在本地过一遍不要等到开赛当天早上才动手检查项确认内容运行时JDK 或 Python 版本、环境变量是否生效依赖包驱动、测试框架、报告插件是否已装且版本兼容浏览器驱动版本与浏览器严格匹配这是最经典的坑编辑器快捷键、代码片段、调试配置提前设好网络是否需要访问特定资源提前确认可用性备用方案主要工具跑不起来时有没有退路浏览器驱动和浏览器版本不匹配这一条我每年都能见到有人栽在上面。新版浏览器出来后驱动往往滞后赛前一定要锁定版本别开自动更新。5.2 时间怎么切如果是 4 小时的场次我的分配习惯大致是前 30 分钟只读题一行代码都不写。把每个场景的分支在草稿纸上列出来标注优先级。这段时间看着像浪费实际上决定了后面三小时的方向对不对。接下来 2 小时集中写脚本。每写完一个场景就跑一遍别攒着一起跑不然调试时错误堆在一起定位成本翻倍。40 分钟做联调和收尾。补齐断言、加异常处理、把互不依赖的场景拆成独立方法。最后 30 分钟做提交前自查并且一定要留出提交的时间。平台在截止前几分钟往往特别拥堵卡着点提交是高风险行为。5.3 几个真实翻过的车数据污染上一个用例注册了test01下一个用例还用test01注册结果必然失败。要么用时间戳随机生成唯一数据要么在用例开头先清理。执行顺序依赖用例 A 依赖用例 B 留下的数据。单跑全挂一起跑能过这种脚本在评测平台上大概率全军覆没。每条用例都必须是自包含的。路径写死代码里写了本机的绝对路径换台机器就找不到文件。全部改成相对路径或者参数化配置。没留日志和截图失败的时候只返回一个AssertionError你根本不知道页面长什么样。加一个失败自动截图和日志输出的钩子成本很低收益极高。6. 从比赛能力到简历能力面试官真正问的是什么聊完了比赛本身说说它的下游价值。这两年测试岗的面试问的东西其实高度集中在几类测试用例设计思路、自动化框架理解、缺陷定位过程、以及一些所谓「八股」基础。面试官问「你用过哪些测试方法」他真正想知道的不是你能不能背出七八种方法的定义而是你拿到一个陌生需求时第一步会怎么做。这也是比赛训练出来的能力最值钱的地方——你习惯性地先划分有效等价类和无效等价类先列条件桩和动作桩先想异常分支。这个反应速度是练出来的。6.1 高频问题的拆解方式有一道题我觉得几乎每次面试都会遇到「给你一个登录页面你怎么测」这道题不是让你穷举而是看你的思维结构。我的答题框架是这样的先讲功能路径正常登录、记住密码、第三方登录、退出登录。再讲输入校验用户名密码的等价类和边界值、空值、超长、特殊字符、前后空格、大小写敏感。然后讲业务规则密码错误几次锁定、锁定后怎么解锁、验证码时效、勾选协议才能登录。接着讲交互和兼容性键盘回车提交、多浏览器、不同分辨率。最后讲安全和服务端越权、重复提交、会话失效后跳转、接口直接调用能不能绕过前端校验。这个结构的价值在于它有层次。面试官听到「先功能、后校验、再业务、再兼容、最后安全」马上就知道你有系统性的思维而不是靠零散经验。6.2 银行类测试和嵌入式测试的关注点差异关键词里出现了「银行软件测试」和「嵌入式软件测试」这两块和普通互联网业务的测试思路差别挺大的简单说几句。银行类系统的测试最核心的关键词是一致性和可追溯。一笔交易从渠道到核心系统再到账务金额、状态、时间必须严格对齐所以测试重点在于幂等性同一笔请求重复提交账只能记一次。对账逻辑日终批量跑完明细和汇总必须能对上对不上要有差错处理路径。批量处理几万条数据跑批时的耗时、失败重试、断点续跑。数据脱敏与权限不同岗位角色能看到的数据范围必须严格隔离。回归范围控制这类系统改动一处牵连一片测试范围的裁剪比用例数量更重要。嵌入式测试的关注点完全是另一套时序、资源、异常恢复。时序上要看中断响应有没有超时、通信有没有超时重传资源上要盯内存有没有泄漏、栈会不会溢出异常恢复上要测掉电、看门狗复位、通信断连后能不能自愈。这些场景在普通 Web 测试里根本不会遇到所以如果你简历里写了嵌入式测试经历面试官一定会往这几个方向追问。6.3 简历里怎么写这段经历才不像背八股我筛简历时最怕看到的是这样的写法「参加 XX 测试大赛使用 Selenium 完成 Web 自动化测试熟悉等价类、边界值等方法。」这句话信息量为零因为每个人都能这么写。改成这样会好很多负责某电商下单模块的自动化脚本覆盖 5 个核心场景设计用例 40 余条其中异常分支用例占比约三分之一脚本采用独立测试方法拆分单场景失败不影响整体执行提交前定位并修正元素定位不稳定问题将脚本通过率从 70% 提升到 100%。差别在哪有具体的模块、有数字、有过程、有结果。这四样凑齐了面试官才有得问你才有得聊。而且这一段里藏了好几个可以延伸的话题为什么异常分支占三分之一、怎么做到场景独立、元素定位不稳定是怎么定位到根因的——这些都是你的主场。7. 我个人在这类比赛上的一点体会带过几届学生之后我发现一个规律拿名次的人往往不是工具用得最花哨的那个而是用例设计那一块几乎不失分的那个。因为自动化脚本会受环境、版本、网络各种因素影响运气成分不小但用例设计是纯逻辑推演只要方法对、抠条件细就是稳定的得分点。再分享一个特别小的技巧。比赛前我会让准备参赛的人做一件事**拿自己学校教务系统的登录和选课页面练手从设计用例一路做到写自动化脚本全程计时。**这个练习的好处是页面足够复杂、足够「不友好」——嵌套的 iframe、异步加载的表格、复杂的表单校验比任何模拟题都真实。把这个啃下来赛场上大部分页面结构你都会觉得眼熟。最后一句实在话比赛的成绩两年后就没人看了但你在备赛过程中养成的「先想分支再动手」的习惯会跟着你很多年。我在实际项目里能比别人早一步发现缺陷靠的基本就是这套从用例设计里练出来的条件反射。
软件测试大赛备战：用例设计、自动化脚本与缺陷定位
前阵子帮团队筛测试岗的简历一天翻了七十多份几乎每隔三五份就能看到「全国大学生软件测试大赛」这几个字。有个同学写着省赛获奖我随口问了一句给你一个年龄输入框允许填 18 到 60你打算设计几条用例、分别取什么值他先背了等价类和边界值的定义背得很顺我又追问如果这个框同时还限制「只能数字」「不能为空」你一共设计几条、怎么组合他就卡住了。这就是我写这篇东西的原因。软件测试这项技能在比赛里被拆成了很具体的题目可很多人准备的方向偏了——把它当成一门「知识点考试」狂背概念、狂背 API而不是当成一次小型的项目交付演练。比赛本身确实是很好的能力凭证但它真正值钱的地方是逼你把「测试用例设计」「自动化脚本」「缺陷定位」这三件事在一个限时环境里串起来做完这个体验和后来进公司接需求、写用例、搭自动化、跟着版本跑回归是同一种肌肉。下面这些内容适合三类人看正在准备参赛的在校生、刚入行想从「点点点」往外走的测试新人以及想搞清楚面试官到底在问什么的朋友。我会把赛题背后的技术点拆开讲也会把我在实际项目和带新人过程中踩过的坑一并倒出来。1. 从赛场到工位这套赛题为什么和真实项目的活儿高度重合比赛当天的场景其实很朴素一台电脑、一个在线评测平台、几个小时的倒计时、题目按通过情况给分。你写完脚本点提交平台跑一遍红绿分明。这种「提交—判分—返工」的循环和真实项目里「提测—跑回归—挂了几条—连夜定位」是同一种压力只是压缩到了几小时里。我在公司带过几个打过比赛的新人最明显的差异不是工具用得熟不熟而是他们习惯先想「这个场景有哪些分支」再动手写脚本。没打过比赛的新人往往拿到需求就开始点点到哪算哪回归的时候才发现漏了一大片。这个思维习惯的差别基本上决定了一个测试工程师前两年的成长速度。1.1 赛项方向拆开看每一条都对应一类岗位以我接触到的赛项方向来看大体可以分成这么几类各年的赛项名称和数量会有调整具体以当年的赛项说明为准这里讲的是能力模型赛项方向主要考察的能力对应的岗位日常Web 应用测试元素定位、表单校验、多页面流程、自动化脚本与断言Web 功能测试、自动化测试移动应用测试元素识别、手势操作、原生与混合页面切换、多分辨率适配App 测试、移动端自动化开发者测试白盒单元测试编写、覆盖率分析、依赖打桩测试开发、开发自测嵌入式测试C 语言、硬件抽象、异常与时序场景嵌入式软件测试用例设计综合等价类、边界值、判定表、场景法、错误推测所有测试岗的地基这张表的意义不在于「哪个赛项更高级」而在于它帮你确认自己现在缺哪一块。很多人一上来就想冲移动端自动化结果元素定位写不稳脚本跑十次挂八次时间全耗在调环境上用例设计的分一分没拿。1.2 用例设计是地基脚本只是手脚自动化脚本的本质是把已经设计好的用例翻译成机器能执行的指令。这话听起来像废话但它的推论很硬设计阶段漏掉的分支脚本写得再花哨也补不回来。举个我印象很深的例子。有一类题是折扣计算订单金额满 100 减 20满 200 减 50会员再打 9 折折扣不叠加但取优惠最大的那个。不少人拿到题就开始写脚本先测 99、再测 100、再测 200看着挺完整。但真正的分支在哪里在「100 到 200 之间用哪个规则」「刚好 200 时会员价和满减谁更划算」「金额为 0 和负数怎么处理」「金额输入小数怎么处理」。这些分支不是靠写脚本能想出来的是靠设计用例时把条件桩和动作桩一条条列出来。还有一件特别现实的事评测平台的脚本通常是「一断全断」的。你第 3 步断言失败抛异常第 4 到第 10 步的分数就全丢了。所以在赛场上脚本的抗中断能力和用例覆盖率一样重要。我一般的做法是每个独立场景做成一个测试方法互不依赖失败一个不影响其他所有断言失败都用 try 包住继续往下走最后统一汇总。这个习惯带到工作里同样管用——回归脚本里一条用例挂掉不该拖垮整个回归任务。2. 测试用例设计方法拿分最稳的一块也是最容易被忽视的一块理论题和综合题里用例设计方法的性价比是最高的。它不需要你装环境、不需要你调依赖纯靠脑子但很多人恰恰在这里失分因为背了定义不会用。我见过太多人能把等价类的定义一字不差地背出来却没法在一道具体题目里正确切分出有效区间。方法本身不难难的是「从题干里抠出条件」。题干不会写得像教科书那样规整它会把限制藏在描述里比如「用户名长度 6 到 20 位支持字母、数字和下划线且必须以字母开头」。这一句话里其实藏了四个约束条件任何一个没抠出来你的用例集就是残缺的。2.1 等价类与边界值先划区间再取三个点我自己的固定流程是这样先分类后取值。把每个输入拆成有效等价类和无效等价类。有效等价类往往只有一两个无效等价类往往一堆——空值、超长、超短、类型错误、格式错误、特殊字符每一个都是独立的一条。边界值只取三类点上点、离点、内点。上点就是边界本身离点是紧挨着边界外侧的那个值内点是区间内部随便一个正常值。拿「年龄 18 到 60」举例可以这样组织取值类型具体值预期结果上点下边界18通过上点上边界60通过离点下边界外侧17拒绝离点上边界外侧61拒绝内点30通过类型异常abc、12.5拒绝空值空、纯空格拒绝这里有个很常见的误区很多人只测 17 和 61不测 18 和 60。但边界本身恰恰是最容易出错的地方开发写判断时用的是还是只有测了上点才能发现。我在真实项目里抓到的「临界值判断写反」这类缺陷两只手数不过来。2.2 判定表与因果图多条件组合题的标准解法当题目里出现「同时满足若干条件才产生某个结果」的时候等价类和边界值就不够用了得上判定表。判定表的做法是把所有条件列成条件桩把所有可能的动作列成动作桩然后穷举条件的真假组合逐行确定应该执行哪个动作。比如一个登录场景条件是「用户名正确/错误」「密码正确/错误」「验证码正确/错误」三个条件二值一共 8 行。写完之后再做化简某些条件在某些动作下根本不影响结果那两行就可以合并。提示判定表列完之后一定要做化简不然 4 个条件就是 16 行、5 个条件就是 32 行时间根本不够。化简的依据是「这一列和另一列的动作完全一致且只有一个条件的取值不同」那就说明这个条件在该场景下无关。因果图本质上和判定表是同一件事的两种表达判定表更适合写成用例因果图更适合在纸上快速理清逻辑。赛场上我建议直接用判定表因为它天然就是一列一条用例转换成本最低。2.3 正交实验与错误推测时间不够时的取舍策略组合爆炸是绕不开的。如果题目里有 4 个下拉框每个 3 个选项全组合 81 条你不可能全写。这时候要么用正交表挑出代表性组合要么用 Pairwise两两组合覆盖的思路。正交表的用法不是玄学它保证任意两个因素的所有取值组合都至少出现一次。三因素三水平的标准表是 L9(3⁴)9 行就能覆盖 81 种组合的关键部分。当然前提是你要能识别出「哪些因素之间存在交互」——如果两个因素完全独立那就不需要正交各测各的就行。错误推测法听起来不正式但在真实项目里用得最多也最需要经验。我个人的「错误清单」大概是这些空值、纯空格、前后带空格很多系统不做 trim admin和admin会被当成两个账号超长输入尤其是那种卡在数据库字段长度附近的值全角字符、特殊符号、纯表情符号输入数字框里输入负数和科学计数法1e5重复提交、连点两次按钮中途刷新页面、后退再前进时间相关跨天、跨月、闰年 2 月 29 日这份清单是我这些年攒下来的比任何教材上的错误推测示例都好用。比赛里时间紧把它当检查表对着题目扫一遍往往能多捞出两三分。3. Web 与移动端自动化脚本写不出来多半是定位和等待没搞明白自动化赛项大家抱怨最多的就是「脚本在我电脑上跑得好好的提交上去就挂」。这句话我听过太多次了在工作里也一样。绝大多数情况下问题不在业务逻辑而在两个地方元素定位不稳和等待没处理好。这两个问题的本质是同一个你的脚本对页面状态的假设太强了。你假设元素已经存在、假设它可见、假设它可点击、假设跳转已经完成。只要有一个假设不成立脚本就挂。3.1 元素定位优先级从稳到不稳定位方式的稳定性是有明确排序的我一般按这个顺序找id最稳前提是它是唯一的、不动态生成的。name 或稳定的自定义属性比如>from selenium.webdriver.common.by import By # 推荐语义清晰页面结构调整不容易波及 submit_btn driver.find_element(By.CSS_SELECTOR, form#login .btn-primary) # 慎用绝对路径结构一变就断 # driver.find_element(By.XPATH, /html/body/div[2]/form/div[3]/button)移动端还多一层坑原生页面和 WebView 页面是两套体系。Appium 里必须显式切换 context否则你用 Web 的定位方式去原生页面上找元素必然找不到。混合应用里经常出现「列表页是原生的点进去是 H5」的情况切换时机没抓准脚本就会卡在找不到元素上。3.2 等待策略隐式等待、显式等待和硬等待的取舍关于等待我踩过的坑足够写一篇长文。结论先给出来等待方式做法适用场景风险硬等待sleep(3)只适合调试浪费时间且 3 秒不一定够隐式等待全局设置超时找不到元素就轮询整体兜底与显式等待混用时行为不可预期显式等待等待某个具体条件成立推荐的主方案条件写错会一直等到超时隐式等待和显式等待混用是个经典雷区。很多驱动实现里隐式等待会拉长显式等待的实际耗时导致本来 5 秒能过的用例拖到 30 秒。我的习惯是全局隐式等待设一个很小的值比如 2 秒做兜底核心交互点全部用显式等待。from selenium.webdriver.support.ui import WebDriverWait from selenium.webdriver.support import expected_conditions as EC wait WebDriverWait(driver, 10) # 等到按钮真正可点击而不是只等到它出现在 DOM 里 btn wait.until(EC.element_to_be_clickable((By.ID, submit))) btn.click() # 等到结果区域出现文字而不是等固定秒数 wait.until(EC.text_to_be_present_in_element((By.ID, result), 登录成功))presence_of_element_located和element_to_be_clickable的区别值得单独说一句前者只保证元素在 DOM 里存在后者保证它可见、可点击。页面没渲染完的时候元素可能已经在 DOM 里了但还盖着遮罩层这时候去点击会直接抛异常。凡是点击操作就用element_to_be_clickable别用 presence。3.3 断言分层决定得分上限的不是操作是断言很多人写脚本操作写得飞起断言只有一句assert True或者干脆不写断言。这在赛场上是致命的——评测平台是靠断言判断你这条用例过没过没有断言就等于没有结论。我的断言分三层页面级跳转后的 URL、页面标题、关键提示文案。元素级目标元素的文本、属性、是否可见、是否被禁用。数据级如果题目给了接口或数据库入口直接核对数据落库结果。再加一个容易忽略的点断言的信息要写清楚。assert result 登录成功和assert result 登录成功, f实际返回的是 {result}在调试阶段的效率差好几倍。赛场上时间紧张一条信息完整的失败提示能帮你省下十分钟。4. 开发者测试与白盒覆盖语句、判定、条件、路径到底差在哪白盒这块是我觉得最有意思、也最容易被低估的部分。它的核心问题是你写的测试用例到底覆盖了代码的哪些执行路径而「覆盖」这件事不同的标准差别极大。很多同学知道「语句覆盖」也知道「分支覆盖」但说不清两者为什么不同的场景下结果会不一样。我拿一段最朴素的代码来讲int check(int a, int b) { if (a 0 b 0) { return 1; } return 0; }4.1 六种覆盖率标准用同一段代码对照覆盖标准含义这段代码需要的最少用例语句覆盖每行代码至少执行一次a1, b1走到 return 1再补一组走到 return 0判定覆盖每个判断的真假分支各走一次同上两组即可条件覆盖每个原子条件的真假各出现一次a0 真/假、b0 真/假 各一次条件判定覆盖判定覆盖 条件覆盖通常 2 到 3 组条件组合覆盖每个条件的所有组合都出现a0 与 b0 的 4 种组合各一次路径覆盖所有可能路径都执行这里没有循环路径数等于组合数关键差别在哪条件覆盖不保证判定覆盖。举个典型反例用例一是 a1, b-1a 的条件真、b 的条件假用例二是 a-1, b1a 假、b 真。这两条用例把「a0 真、a0 假、b0 真、b0 假」都覆盖到了但整个if判定始终为假return 1那一行从来没被执行过。这就是为什么工业界做安全关键软件时往往要求更强的标准比如修件判定覆盖MC/DC。注意覆盖率不是越高越好而是要盯着「未覆盖的那部分」。赛场上如果你的覆盖率卡在 85% 上不去别急着加用例先去看报告里标红的分支是什么往往是一个异常分支——比如某个参数为 null 的兜底逻辑。找到它一条用例就能补上。4.2 单元测试的打桩把依赖挡在门外白盒题里经常出现「被测函数依赖了外部接口」比如一个查询余额的函数里调了远程服务。这时候你不能真的去连外部服务得打桩。打桩的本质是用可控的假对象替换不可控的真依赖让测试只关注被测逻辑本身。在 Java 里通常用 Mockito在 Python 里用unittest.mockfrom unittest.mock import patch patch(service.remote_client.query) def test_balance_when_remote_fails(mock_query): # 模拟外部服务抛异常验证被测代码的兜底逻辑 mock_query.side_effect TimeoutError(timeout) result get_balance(u001) assert result is None mock_query.assert_called_once_with(u001)这里最重要的是最后那句assert_called_once_with——它验证的不只是返回值还有调用行为。真实项目里我遇到过「重试逻辑写错导致外部接口被调了三次」的缺陷就是靠这类断言抓出来的。4.3 嵌入式 C 单元测试的特别之处嵌入式赛项和白盒赛项的差别主要在三个地方没有操作系统、内存受限、代码里直接读写硬件寄存器。第三点是最大的障碍。如果被测代码里直接写着REG_CTRL | 0x01你在 PC 上根本跑不起来。所以要做的第一件事是识别出哪些是硬件相关代码把它们打桩掉。常见做法是在头文件里定义一组可替换的接口测试时链接另一份空实现。编译环境上嵌入式测试一般是在 PC 上用宿主编译器跑单元测试工具链常见的组合是 Unity 或 CppUTest 加 GCC再配合覆盖率工具生成报告。这里有几个务实的经验别在赛场上试图跑真实硬件纯软件打桩跑得快也稳。注意数据类型的宽度int在 PC 上是 4 字节在目标平台上可能是 2 字节涉及溢出判断的用例要显式用int16_t这类定长类型。注意无符号数的回绕for (u8 i 10; i 0; i--)这种写法是死循环是很典型的嵌入式缺陷题。5. 环境、工具与现场操作这些「非技术」细节经常直接决定名次技术能力差不多的情况下名次往往被这些细节决定。我见过太多人准备了三个月最后因为环境没配好、时间分配崩了、提交前没自查白白丢分。5.1 开赛前的环境清单比赛前一周就该把下面这张表在本地过一遍不要等到开赛当天早上才动手检查项确认内容运行时JDK 或 Python 版本、环境变量是否生效依赖包驱动、测试框架、报告插件是否已装且版本兼容浏览器驱动版本与浏览器严格匹配这是最经典的坑编辑器快捷键、代码片段、调试配置提前设好网络是否需要访问特定资源提前确认可用性备用方案主要工具跑不起来时有没有退路浏览器驱动和浏览器版本不匹配这一条我每年都能见到有人栽在上面。新版浏览器出来后驱动往往滞后赛前一定要锁定版本别开自动更新。5.2 时间怎么切如果是 4 小时的场次我的分配习惯大致是前 30 分钟只读题一行代码都不写。把每个场景的分支在草稿纸上列出来标注优先级。这段时间看着像浪费实际上决定了后面三小时的方向对不对。接下来 2 小时集中写脚本。每写完一个场景就跑一遍别攒着一起跑不然调试时错误堆在一起定位成本翻倍。40 分钟做联调和收尾。补齐断言、加异常处理、把互不依赖的场景拆成独立方法。最后 30 分钟做提交前自查并且一定要留出提交的时间。平台在截止前几分钟往往特别拥堵卡着点提交是高风险行为。5.3 几个真实翻过的车数据污染上一个用例注册了test01下一个用例还用test01注册结果必然失败。要么用时间戳随机生成唯一数据要么在用例开头先清理。执行顺序依赖用例 A 依赖用例 B 留下的数据。单跑全挂一起跑能过这种脚本在评测平台上大概率全军覆没。每条用例都必须是自包含的。路径写死代码里写了本机的绝对路径换台机器就找不到文件。全部改成相对路径或者参数化配置。没留日志和截图失败的时候只返回一个AssertionError你根本不知道页面长什么样。加一个失败自动截图和日志输出的钩子成本很低收益极高。6. 从比赛能力到简历能力面试官真正问的是什么聊完了比赛本身说说它的下游价值。这两年测试岗的面试问的东西其实高度集中在几类测试用例设计思路、自动化框架理解、缺陷定位过程、以及一些所谓「八股」基础。面试官问「你用过哪些测试方法」他真正想知道的不是你能不能背出七八种方法的定义而是你拿到一个陌生需求时第一步会怎么做。这也是比赛训练出来的能力最值钱的地方——你习惯性地先划分有效等价类和无效等价类先列条件桩和动作桩先想异常分支。这个反应速度是练出来的。6.1 高频问题的拆解方式有一道题我觉得几乎每次面试都会遇到「给你一个登录页面你怎么测」这道题不是让你穷举而是看你的思维结构。我的答题框架是这样的先讲功能路径正常登录、记住密码、第三方登录、退出登录。再讲输入校验用户名密码的等价类和边界值、空值、超长、特殊字符、前后空格、大小写敏感。然后讲业务规则密码错误几次锁定、锁定后怎么解锁、验证码时效、勾选协议才能登录。接着讲交互和兼容性键盘回车提交、多浏览器、不同分辨率。最后讲安全和服务端越权、重复提交、会话失效后跳转、接口直接调用能不能绕过前端校验。这个结构的价值在于它有层次。面试官听到「先功能、后校验、再业务、再兼容、最后安全」马上就知道你有系统性的思维而不是靠零散经验。6.2 银行类测试和嵌入式测试的关注点差异关键词里出现了「银行软件测试」和「嵌入式软件测试」这两块和普通互联网业务的测试思路差别挺大的简单说几句。银行类系统的测试最核心的关键词是一致性和可追溯。一笔交易从渠道到核心系统再到账务金额、状态、时间必须严格对齐所以测试重点在于幂等性同一笔请求重复提交账只能记一次。对账逻辑日终批量跑完明细和汇总必须能对上对不上要有差错处理路径。批量处理几万条数据跑批时的耗时、失败重试、断点续跑。数据脱敏与权限不同岗位角色能看到的数据范围必须严格隔离。回归范围控制这类系统改动一处牵连一片测试范围的裁剪比用例数量更重要。嵌入式测试的关注点完全是另一套时序、资源、异常恢复。时序上要看中断响应有没有超时、通信有没有超时重传资源上要盯内存有没有泄漏、栈会不会溢出异常恢复上要测掉电、看门狗复位、通信断连后能不能自愈。这些场景在普通 Web 测试里根本不会遇到所以如果你简历里写了嵌入式测试经历面试官一定会往这几个方向追问。6.3 简历里怎么写这段经历才不像背八股我筛简历时最怕看到的是这样的写法「参加 XX 测试大赛使用 Selenium 完成 Web 自动化测试熟悉等价类、边界值等方法。」这句话信息量为零因为每个人都能这么写。改成这样会好很多负责某电商下单模块的自动化脚本覆盖 5 个核心场景设计用例 40 余条其中异常分支用例占比约三分之一脚本采用独立测试方法拆分单场景失败不影响整体执行提交前定位并修正元素定位不稳定问题将脚本通过率从 70% 提升到 100%。差别在哪有具体的模块、有数字、有过程、有结果。这四样凑齐了面试官才有得问你才有得聊。而且这一段里藏了好几个可以延伸的话题为什么异常分支占三分之一、怎么做到场景独立、元素定位不稳定是怎么定位到根因的——这些都是你的主场。7. 我个人在这类比赛上的一点体会带过几届学生之后我发现一个规律拿名次的人往往不是工具用得最花哨的那个而是用例设计那一块几乎不失分的那个。因为自动化脚本会受环境、版本、网络各种因素影响运气成分不小但用例设计是纯逻辑推演只要方法对、抠条件细就是稳定的得分点。再分享一个特别小的技巧。比赛前我会让准备参赛的人做一件事**拿自己学校教务系统的登录和选课页面练手从设计用例一路做到写自动化脚本全程计时。**这个练习的好处是页面足够复杂、足够「不友好」——嵌套的 iframe、异步加载的表格、复杂的表单校验比任何模拟题都真实。把这个啃下来赛场上大部分页面结构你都会觉得眼熟。最后一句实在话比赛的成绩两年后就没人看了但你在备赛过程中养成的「先想分支再动手」的习惯会跟着你很多年。我在实际项目里能比别人早一步发现缺陷靠的基本就是这套从用例设计里练出来的条件反射。
