在数码港的网络排错日常里，经常遇到新同事问：写好的测试用例到底要不要签字确认？这个问题听起来像是流程上的小事，但真碰上了，谁都说不准。
签字背后的责任归属
某次公司上线新路由器固件，测试组写了二十多个测试用例，覆盖了DHCP、NAT穿透、端口映射等场景。开发改完一轮后，直接在群里说“已修复”，运维就上了生产。结果第二天凌晨，整个办公区断网两小时。复盘时发现，有个边界用例明明写了“多VLAN并发压力测试”，但没人执行，也没人确认。这时候有人翻记录，说“你写了没让我签，我以为不用做”。
从那以后，项目组开始要求关键模块的测试用例必须有测试负责人和开发对接人双签。不是搞形式主义，而是划清责任线。签字不等于免责，但能避免“我以为你做了”这种扯皮。
什么时候非签不可？
涉及核心链路变更，比如主备切换逻辑、BGP路由策略调整，这类测试用例通常要走正式评审。这时候纸质或电子签核流程就少不了。尤其是金融类客户环境，审计查起来，没签字的用例等于没做。
但如果是日常排查，比如“ping不通是不是DNS问题”这种临时写的验证步骤，写在协作文档里，大家实时更新状态，反而比等签字更高效。强求每个小动作都签字，只会拖慢排错节奏。
电子化流程正在替代手签
现在多数团队用Jira或禅道管理测试任务。测试用例关联到具体Ticket，状态从“待执行”变“已完成”，负责人点一下就算确认。系统自动留痕，比手写签名更难抵赖。我们组还加了规则：高优先级用例执行前，必须@相关开发，超时未回应可直接升级。
有次排查光模块误码问题，测试同学把流量打流脚本贴在任务评论区：
<script>\n for i in {1..100}; do \n ping -c 10 192.168.10.$i \n done\n</script>签字的本质是共识确认
与其纠结形式，不如关注有没有真正达成一致。见过最有效的做法是站会时拉上开发、测试、运维三方，对着屏幕过一遍关键用例，当场口头确认。录音存档，比找人补签更有说服力。
说白了，签字不是目的。确保该测的都测了，出事能追溯，才是网络排错这行的实际需求。