排查程序错误


提供复现依据

排查错误时,应同时提供预期行为、实际行为、操作步骤和报错原文。只有“运行不了”或“页面异常”等描述,难以确定问题发生的具体位置。

日志宜保留必要上下文,但应先删除访问令牌、账号密码和客户隐私。截取错误时,不宜只保留最后一句,还应保留触发命令及能够说明调用位置的内容。

请排查当前项目中的{书籍重复保存}问题。

预期行为:{连续点击保存按钮,只创建一条记录}。
实际行为:{快速点击两次后,列表出现两条相同记录}。
复现步骤:
1. 打开新增书籍页面;
2. 填写合法信息;
3. 在较短时间内连续点击保存两次;
4. 返回列表查看记录。

相关资料:{浏览器网络请求记录、已脱敏的服务日志、相关截图}。
发生范围:{当前本地开发环境}。

请先定位请求触发、接口处理及数据写入过程,说明可以确认的原因。
不要仅根据现象直接添加延时,也不要未经分析便同时重写前后端。

确定原因后,提出必要修改及验证方法。
如需更多信息,请说明需要补充的日志或操作。

依据原因修复

修复方案应对应已经确认的问题来源。前端按钮状态、服务端重复请求处理和数据库约束解决的是不同层面的问题,应根据业务要求决定处理位置。

确认方案后,可继续要求:

请按已确认方案修复{重复保存}问题。

本轮仅修改与该问题直接相关的逻辑。
先补充能够复现问题的检查或测试,再实施修复,并重新验证。

交付时说明:
1. 已确认的原因;
2. 修改的文件与主要处理方式;
3. 实际执行的检查命令和结果;
4. 尚未覆盖的情况。

不得通过删除断言、跳过失败用例或关闭校验来制造通过结果。

若修复后仍失败,应比较本轮与上一轮的错误变化,核对是否解决了原问题,还是仅改变了报错形式。每轮修改宜保持范围明确,使结果能够追溯。

评论

登录后查看