大家好呀上一期咱们把 PRD 里的坑全问出结论文档定稿到 V2.0。今天就接着往下走一步。项目前提和前两期一样 全新从 0 搭起来的练习项目业务背景、用户、规则全部 AI 虚构不是真实项目。PRD 定稿之后发生的事很多新人是这么想的方案定了 → 等开发写完 → 提测 → 开始测。实际上中间还夹着一步而且这步没做好的话后面要么漏测、要么背锅产品方案要拆成一张张需求单分下去测试得按单认领认领完才知道这轮到底要测什么。本期带你走一遍需求单是怎么拆的、评审上我盯什么、我按什么顺序认领、单子里看不出来的坑怎么挖。 本期项目速览项目内容项目名SimpleHR简人系统四条业务主线考勤打卡 · 请假 · 审批流 · 报销本期输入策划拆好的28 条需求单本期重点按单认领测试范围、盯验收点、拉交叉风险我的活儿逐条过单 → 打回不能验的 → 排执行顺序 → 出认领记录一、先掰扯清楚方案不是我定的这点我踩过一次坑先说在前头。❌ 常见误解PRD 定稿了测试该出「测试方案」了✅ 实际情况方案是产品/策划定的测试自己定的是测试策略 测试计划这俩不是一回事谁定定的是什么产品方案小陈产品做什么功能、业务规则怎么定需求单四位策划功能怎么拆给开发、验收点是什么测试策略 计划我测什么、不测什么、几轮、准入准出所以我没有去写「SimpleHR 测试方案」这种文档——方案在上游我只负责把它翻译成测试范围。依据是策划建好的需求单不是那份几十页的 PRD。 这个口径搞混了会很难受你写的东西没人看产品还觉得你越界。二、需求单是怎么拆出来的小陈把功能按业务域 变更频率拆成四块分给四个策划策划负责业务域需求单边界约定小鹿考勤线REQ-101 ~ 108只管打卡数据怎么产生和判定不算钱阿哲假勤线 组织底座REQ-201 ~ 206请假时长余额自己算走审批一律调小柯的引擎小柯审批流引擎REQ-301 ~ 306只做通用引擎不关心单据内容小孟报销线 通知日志REQ-401 ~ 408报销合规自己管审批链同样调引擎一共28 条P0 12 条、P1 14 条、P2 2 条。我特别留意了他们内部对齐过的三条原则因为这三条直接决定我后面好不好测规则归属唯一一条规则只写在一张单里。比如「加班时长取申请与打卡的较小者」写在考勤单审批单里不再重复描述——避免两边各写一半最后谁都不认。跨模块走接口不走口头考勤只把「加班已通过 时长」交给审批审批不反查考勤明细。共用的先定审批流引擎优先级最高四条线都依赖它。第 3 条对我很关键引擎不定完请假/补卡/加班/报销全测不了。这就是我排执行顺序的依据。三、评审上我盯的不是「规则对不对」是「验收点能不能验」逐条过单的时候我给每张单打了个标标记含义条数✅ 能验验收点写成了可观察的结果16⚠️ 要补写得含糊得让策划补7 要造数据结论清楚但我得先准备数据环境5重点说说那 7 条「要补」的我在会上直接打回去了 我提的问题✅ 当场结论REQ-101 改完考勤日历当天的判定会不会重算不回溯次日生效REQ-104 跨月夜班报表按打卡日还是按自然月拆按上班打卡日归属不拆REQ-107 加班 1 小时 40 分钟折算多少向下取整到小时40 分钟丢弃REQ-108 次月修正要不要回写上月报表不回写只在次月报表标注「上月修正」REQ-206 病假改判事假后余额变负怎么办允许临时负余额并提示HR 手工处理REQ-305 后提交者被提示「已被处理」后页面状态刷不刷提示同时强制刷新REQ-406 「不允许换费用类型」前端置灰算不算做完前端置灰 后端二次校验只做前端不算这 7 条有个共同点都不是主流程全是「做完之后会怎样」。 我盯验收点的标准就一句话——能不能设计一个操作然后眼睛看到结果。像「支持灵活配置」「体验流畅」这种我没法验就一定要打回去换成可观察的结论。还有 5 条标 的是那种「结论清楚但我现在测不了」的比如REQ-105 非公司 IP 打卡 → 我本地改不了 IP 段得让老周开个测试开关REQ-407 费用超 90 天拦截 → 得先造一批 90 天前、91 天前的历史单据REQ-404 改后缀的 exe 要被拦 → 得准备一份伪装成 jpg 的样本文件。这种我都是在认领的时候就提不等到执行那天才发现没数据。 ① REQ-201 组织架构与账号 没账号后面全免谈 │ ② REQ-301~303 审批引擎 接口 10-10 就绪先打接口不等页面 │ ③ REQ-101~103 考勤判定 打卡数据是一切的输入 │ ④ REQ-202~203 请假时长与余额 │ ⑤ REQ-401~403 报销主流程与合规 │ ⑥ 其余 P1 / P2 │ ⑦ 交叉风险专项最后统一跑 四、认领顺序谁卡住别人的路谁先测28 条全是我一个人跟那先测哪条我一般不按编号排按依赖排两个判断点引擎卡住四条线所以哪怕它在编号上排第三我也把它放第二测后端接口 10-10 就绪、页面 10-16 才提测中间那六天我拿接口先把引擎验一遍不干等页面。之前踩过的坑按编号从 REQ-101 开始测测到一半发现审批走不通前面全白跑。先测被依赖的永远比先测好测的划算。范围上也顺手定死了P0 12 条全量 边界值 后面进自动化P1 14 条主流程 关键边界P2 2 条只过主流程。五、单子里看不出来的坑交叉风险这是我觉得认领这一步最值钱的部分。需求单是竖着切的但系统是横着跑的。有些场景两张单单独测都对连起来就错。文档里给了 3 条我自己又补了 2 条#风险涉及我要验什么1加班时长依赖审批通过结果小鹿 × 小柯通过后报表里的加班时长是否按「申请与实际取小」更新2报销月累计额度依赖审批中状态小孟 × 小柯审批中占额度、驳回后是否实时释放3调休余额被请假单扣减小鹿 × 阿哲两侧余额是否同步4补卡/请假通过后考勤判定要重算小鹿 × 小柯原来的「缺卡/旷工」是否改判引擎不感知单据内容回调谁做5组织架构变更影响在途审批单阿哲 × 小柯部门调整后审批中的单走原审批人还是新审批人第 4、5 条是我自己加的需求单文档里没写。我的经验是凡是「A 通过之后要改 B 的数据」的场景默认就有坑认领时看到这种字眼就先记下来。这 5 条我单独拉了个专项放到最后一轮统一跑——上下游都就位了再验中途跑纯属浪费时间。六、给测试小白的小提醒 先分清口径方案是产品/策划定的测试定的是策略 计划认领按策划的业务线分出问题能直接找对人别在群里问一圈过单盯验收点能不能验「体验流畅」这种一律打回换成可观察的结论需要造数据的单认领时就提别等执行当天发现没环境执行顺序按依赖排不按编号排谁卡住别人的路谁先测交叉风险单独拉清单A 通过之后要改 B 数据的场景是漏测重灾区认领完把「不测什么」也写下来P2 只过主流程、进二期的 4 条免得后面扯皮✅ 本期产出产出说明 需求单认领记录28 条逐单认领结论能验 / 要补 / 要造数据 打回的 7 个验收点已在评审当场拿到结论策划回写需求单 V1.1⚠️ 交叉风险清单 5 条含我自己补的 2 条排进测试计划专项落在仓库docs/01-需求阶段/04-需求单认领记录-SimpleHR.md仓库地址GitHub - 1072121758/SimpleHR-- · GitHub 下期预告范围认领完了接下来得把它写成一份正式的测试计划——测什么、不测什么、几轮、什么情况下打回。下一期我把测试策略和计划一起定下来顺便讲讲怎么写才不会后面背锅。本项目全部资料开源在 GitHub欢迎 Star一起交流测试