拿到糟糕旧页面，前端选择重构还是修补？
每次前端说“我要重构这个页面”，测试心里就咯噔一下重构前两周，测试问什么时候提测，前端说快了再给一周第三周测试再问，前端说发现依赖要升级再等等第四周产品扛不住了强行上线，测试只拿到两天时间，测完发现老的逻辑和新的实现有一处对不上，线上炸了重构最大的代价从来不是前端多写几行代码，是测试要重新测一遍老页面虽然烂，但测试已经踩过所有坑了，边界条件兼容问题历史数据全在用例库里躺着。你重构完了测试得重新测一遍，之前三个月积累的回归用例全部作废，这个成本谁来算真正让测试破防的是重构完的代码比原来还难测原来是一个大组件，测试直接模拟用户操作就行，重构之后拆成了八个小组件，要分别mock分别断言分别测交互，测试脚本比重构前还长了三倍那什么情况可以重构测试视角最支持重构的情况只有一种，旧页面每次改完都要测一周，出Bug率还居高不下，重构之后回归时间能压到两天，这种ROI测试双手赞成其他情况，修补比重构更香每次改页面的时候顺便优化一小块，测试只需要回归改动的那一小块，不需要全量重测，风险可控排期可预期，测试也不用熬夜说到底，重构还是修补，测试最关心的就一件事，你改完我还能不能按时测完如果你重构之前不跟测试对齐排期，不在提测前三天给出版本让测试先跑冒烟，那你重构完上线崩了的时候，复盘会议上测试一定会说一句“当初就该修补的”
发布于 四川
分享
2
赞
未登录
友善发言
评论
加载中
