上线前的回归测试发现了大问题
上周我们给社区养老平台做版本更新，新增了家属远程查看老人用餐记录的功能。一切看起来都挺顺，直到回归测试时发现，原本稳定的‘紧急呼叫自动通知’功能突然不推送消息了。
这可不是小毛病。张阿姨上个月就靠这个功能，及时被送到医院。要是真出了事，系统掉链子，责任谁担得起？
先别急着改，得搞清楚到底动了哪根筋
开发小李第一反应是回滚代码，但经验告诉我们，不能光治标。我们拉出最近两周的代码提交记录，一条条比对。最后发现，问题出在一个看似无关的公共函数——formatTimestamp()。新功能为了显示用餐时间，优化了这个时间格式化方法，结果老功能依赖的旧时间戳格式被破坏了。
<!-- 修复前的错误调用 -->
<button onclick="triggerAlert(formatTimestamp(data.time))">紧急呼叫</button>
<!-- 修复后，兼容老逻辑 -->
<button onclick="triggerAlert(data.time)">紧急呼叫</button>老人用的系统，稳定比炫技更重要
很多家属觉得功能越多越好，但我们做护理系统的，心里得有杆秤。上次加了个语音提醒倒计时，本以为贴心，结果几位听力不太好的老人嫌吵，还误触了取消按钮。后来只好默认关闭，改成可选。
所以现在每加一个功能，我们都得跑一遍“老人模拟测试”：请几位合作的护理员，用最慢的操作速度，反复切换页面、断网重连、误点按钮，看看系统会不会崩。
建立自己的“护理功能清单”
我们现在有个内部文档，列着所有涉及安全的核心功能：紧急呼叫、用药提醒、夜间巡检打卡、跌倒检测通知……每次发版前，必须逐项手动验证。哪怕自动化测试通过了，也得真人走一遍。
有一次自动化脚本没覆盖到安卓低版本，结果老人用的老年机收不到推送。从那以后，我们加了台二手红米手机专门测兼容性。
技术会变，需求会增，但老人的安全底线不能碰。功能可以慢慢加，但老的、关键的部分，宁可笨一点，也不能出错。