3.4 软件测试:联调试跑 零件装成了整车,发车前要试跑。测试站是旅程里最容易被误解的一站——它不是"证明软件没坏"的仪式,而是有组织地寻找故障信息的调查活动。本节讲四级试跑各自的分工、用例怎么设计得少而准、缺陷怎么流转、试跑报告怎么写才算有结论。 试跑的正确姿势:先想会怎么坏 新手设计用例的习惯是把正常流程跑一遍——这恰恰是信息量最低的部分:正常路径开发自测时早就跑过。有经验的测试员反过来想:哪里最容易坏,就在哪里下注。两个最经典的下注方法是: 等价类划分:把无穷的输入切成若干"命运相同"的类,每类挑代表。运费金额分三类——正常正值、零、负值——负值该被拦截还是按零处理?一条用例定生死; 边界值分析:缺陷最爱藏在边界。满减门槛满三百减五十,那就测 299.99、300、300.01 三笔。
零件装成了整车,发车前要试跑。测试站是旅程里最容易被误解的一站——它不是"证明软件没坏"的仪式,而是有组织地寻找故障信息的调查活动。本节讲四级试跑各自的分工、用例怎么设计得少而准、缺陷怎么流转、试跑报告怎么写才算有结论。
新手设计用例的习惯是把正常流程跑一遍——这恰恰是信息量最低的部分:正常路径开发自测时早就跑过。有经验的测试员反过来想:哪里最容易坏,就在哪里下注。两个最经典的下注方法是:
用例不在多在准。盲目堆用例数量的团队,回归一次要几天,最后必然偷工减料;用例精准的团队,核心回归几个小时跑完,才敢谈高频发车。

四级试跑各自回答的问题不同,混在一起就都答不好:
| 层级 | 谁主导 | 回答的问题 | 典型环境 |
|---|---|---|---|
| 单元测试 | 开发 | 这个函数对不对 | 内存中,无网络无库 |
| 集成测试 | 开发与测试 | 模块拼接后还咬合吗 | 独立联调环境 |
| 系统测试 | 测试 | 整车满足货单了吗 | 仿真生产环境 |
| 验收测试 | 用户与产品 | 这车能收货吗 | 类生产环境 |
试跑发现的每个故障都应立案流转,而不是在聊天窗口里消失。缺陷的生命周期是一条带回路的状态链:
立案信息决定修复速度:复现步骤、期望与实际、环境版本、日志片段,四样齐全的缺陷单平均修复周期远短于"点这里不对劲"。另一个值得盯的数字是** reopen 率**(复验不通过打回的比例)——它高,说明修复方没理解缺陷根因,或复验方没验到根因上。
班次末的试跑报告不是缺陷流水账,它的骨架是结论先行:这趟能不能发。支撑结论的通常是三本账:用例执行账(多少条、通过率、未覆盖面)、缺陷账(新立多少、遗留多少、遗留项的风险评级)、风险账(已知但未验证的场景清单)。云梯迭代七的报告结论栏只有一行:"遗留缺陷四项,其中两项影响展示不影响金额,可发;两项涉金额已修复待复验,复验通过即发。"——这种报告,调度台三分钟就能做决策。
⚠️ 报告最忌"通过率百分之九十八"这类无背景数字。九十八好还是坏,取决于那百分之二卡在哪些货上——把"没通过的是什么"讲清楚,比把"通过了多少"讲漂亮有用得多。
等价类听着抽象,落到云梯的一个真实字段上就具体了。需求里"运费金额"的约束是:大于零、小于等于十万、两位小数。切等价类:有效类三个(普通值、下边界、上边界),无效类四个(负数、零、超上限、三位小数)。边界值再从有效类的边缘挤水分:取零点零一、十万、九万九千九百九十九点九九各测一条。九条用例覆盖了绝大多数风险敞口——对比"随便点几个数测测"的十几条随机用例,条数更少、命中率更高。用例设计的本质是用结构化的抽样对抗随机撒网,等价类与边界值是抽样框,不是玄学。
班次越跑越密,全量回归从习惯变成奢侈,按影响面选回归范围成了必修课。云梯的选法分三层:核心冒烟(计费、下单两条主干链路,任何提交后必跑,二十分钟);受影响面回归(按本次改动的模块与下游依赖,选取关联用例,一小时内);全量回归(发版前与夜间轮跑)。选层的依据来自一张"模块—用例"映射表,它随架构演进而维护——映射表过期的标志,是"改了计费却没人知道要跑对账的用例"这类漏网开始出现。选范围的本质是维护一张影响传导图,图准了,回归又快又稳。
试跑报告之外,还有一本更值钱的账:缺陷引入分析。每个确认的缺陷追两个问题——它诞生于哪一站(需求、设计、编码)、它本该在哪一站被拦住。云梯统计过一个季度的账:诞生在编码站的占七成,但"本该在评审拦截而没拦住"的占四成——后一个数字指向的不是写代码的人,而是走查清单的盲区。引入分析的产出直接回灌:缺陷类型进检查单、漏检的站点加验证动作、反复出现的类型升级为专项。缺陷是免费的老师,验尸报告就是学费收据——只修不复盘的缺陷,等于交了学费没上课。
问:测试要不要懂代码? 懂得越多越好,但用途不同。懂代码的测试员能定位缺陷层次(接口、数据、逻辑),与开发对话省一半时间;不懂代码的测试员在用户视角的探索上反而更敏锐——他们撞见的是"真实用户会掉进去的坑"。理想配置是两种人都有,各守一层;单打独斗的测试员,至少要能读懂接口定义与数据结构。
问:自动化之后,手工测试还有价值吗? 自动化接手的是"重复执行的判定",人工守住的恰恰是自动化给不了的两样:探索性测试(没有预设路径,靠直觉找系统的怪脾气)与体验评判(流程走得通,但用户用得别扭)。第 6.3 节的检测线图里那两个白色工位,就是人工的正当席位——机器上的每一个座位,都不该由人占着,人该站的地方,机器也替不了。
试跑放行了,列车驶向最后一道闸——发车站台。