需求一旦修改测试该如何进行呢最近面临的项目经过很多次需求更改或者是前期没有需求实际操作起来让人很是头疼恰到也看到大家也有着相同的讨论。来源于微信公众号测试论道学习并进行整理1 场景再现大家几乎都遇到过这样的场景需求已经评审结束 工作量也已内部评估问题/风险点讨论过一轮 测试计划排好了此时产品经理/软件工程师说了一句“有个小调整不大不影响其它功能。”大家的第一反应通常不是紧张而是判断——既然改动不多补几条用例就行。问题往往就从这里开始。一次“只是小改动”的代价某次项目中增加一个多次判断规则原逻辑是 当触发条件1后执行动作3修改后 当触发条件1后同时满足是否满足***条件听起来像多加一个条件判断。开发评估半天说改动集中在考虑多角度用户场景测试也顺着这个方向补了用例功能自测没问题回归也过了。结果发布到现场使用后客户投诉功能使用怎么不符合常规设想问题不在增加规则本身。修改的一个函数被多个模块复用。测试只围绕“新增规则”设计覆盖却没有重新梳理“整个判断逻辑链路”。判断起点错了后面全都偏了。2 注意事项需求变动应该变的不是代码是前提很多测试在需求变动时会自然进入“补充模式”补充用例-补充回归-补充时间但真正需要做的不是补充。而是重新建立判断前提。需求变动本质是前提变化。前提一变推导就需要重来。为什么工作量总被低估有经验的测试往往习惯用“改动大小”判断影响。看改了多少代码。 看改了几个接口。 看是不是核心模块。但这些都只是表象。真正决定工作量的是影响面。影响面包括 • 数据是否被多处复用 • 逻辑是否嵌入多个流程 • 是否改变状态流转路径 • 是否影响历史数据结构工作量变化不来自新增功能点。来自被影响的整个逻辑板块。3 风险感知风险不是延续的是重新计算的很多团队在需求变动后只是在原风险清单上“补一条”。这其实是在延续旧结论。真正应该做的是——推翻一次原风险识别。原本低风险的功能模块可能瞬间成为高风险区域。风险不会自动更新。如果不重算就一定会留下盲区。测试覆盖的对象变了需求变动后一个常见误区是只围绕新增逻辑设计用例。但系统不是功能点集合。它是链路结构。测试覆盖的对象应该是“关系结构”。只测新增点是最容易产生假安全感的方式。4 时间争议时间不够时怎么办需求变动往往发生在迭代中后期。时间不够是常态。关键不是全覆盖。而是清晰表达影响面。当你能明确说出 • 哪些链路被牵动 • 哪些模块必须回归 • 哪些风险是团队选择接受决策才是有依据的。真正危险的不是压缩测试时间。而是在错误的影响面认知下做决策。经验的盲区有经验的测试很容易说一句话“这块逻辑一直很稳定。”问题是—— 稳定建立在旧规则之上。规则改变稳定性本身就失效。经验没有错。错的是把经验当成无需重算的理由。判断力不在于见过多少版本。而在于当假设被打破时 是否愿意推翻自己的结论。5 写在最后需求变动时测试如果只是“补测” 那是在延续旧假设。真正的责任是重新计算。重新算工作量。 重新算风险。 重新算覆盖范围。系统不是静态的。每一次规则变化都在重塑它的结构。测试的价值不是发现多少问题。而是在判断被推翻的那一刻 敢不敢重算一次。