可复现的软件缺陷收集
用于提交可复现软件问题的缺陷报告表
引导报告人提供受影响组件和构建版本、运行环境、最短可重复路径、预期结果、实际结果和证据，而不要求其猜测优先级或指定修复人。
登录后可查看已填充的视图，再安装带示例数据的应用，以测试关联记录、决策和仪表板。
报告人提供什么，分诊团队决定什么
优秀的缺陷报告表能够提高他人复现问题的成功率。它应先收集可观察事实，再由分诊团队决定严重程度、优先级、负责人和目标版本。
- 报告人字段与分诊字段分开
- 适合移动端且支持上传文件证据的表单
- 缺少信息时退回补充，而不是直接拒绝
报告人字段指南
收集完整复现所需的最少信息
每个字段都应帮助他人复现、分类或调查问题。
- 01
清晰摘要
描述可见故障及受影响的操作。
- 02
组件和构建版本
选择产品模块，并在已知时填写确切版本。
- 03
环境
记录设备、浏览器、操作系统、租户或配置。
- 04
复现步骤
按顺序列出最短可重复操作。
- 05
预期结果与实际结果
分别说明应有结果和实际发生的情况。
- 06
证据与影响
附上有用证据，并说明谁因此无法继续工作。
提交后
退回不完整报告，同时保留沟通过程
表单只是起点；每种分诊结果都需要明确的下一步。
检查可复现性
确认环境，并按所提供的路径重复操作。
请求补充背景
带着具体问题退回报告，并沿用同一记录。
合并重复项
将新报告关联到标准问题，而不是将其删除。
接受并分派
记录严重程度、优先级、负责人和目标版本。
撰写可执行的报告
用可观察的差异取代含糊表述
只要将背景、操作和结果分开说明，简短的报告也可以很完整。
| 模糊报告 | 可执行报告 | 改进之处 |
|---|---|---|
| 结账坏了 | Web 4.28.0 中，从 3DS 页面返回后支付确认超时 | 明确了操作、故障和构建版本。 |
| 同步重复 | 断线重连后连续点击两次同步，会生成两条本地 ID 相同的记录 | 给出了可重复触发方式和可观察结果。 |
| 导出错误 | Reporting 12.2 的计划 CSV 导出遗漏了两个已保存的自定义列 | 说明了运行模式、数据差异和版本。 |
问题与适用边界
缺陷报告表常见问题
帮助判断哪些字段应由报告人填写，哪些应留给分诊团队。
报告人应该选择严重程度和优先级吗？
通常不应。报告人可以说明业务影响和紧急程度，再由分诊团队依据统一标准确定严重程度和优先级。
复现步骤应该写多长？
使用他人能够重复的最短步骤。只有在前置设置会改变结果时才写入，并注明间歇性问题的发生频率。
如果报告人不知道构建版本怎么办？
允许填写“暂不清楚”，但应收集足够的环境信息，便于分诊时识别版本。不要因一个技术字段缺失而阻止提交有价值的报告。
表单可以在移动端使用吗？
可以。报告人可用手机记录受影响的组件、运行环境、复现步骤和证据，并将报告提交到与桌面端相同的分诊队列。
改进首次交接
从他人能够复现的报告开始
在桌面端或移动端打开示例表单，再根据您的产品调整字段和流转。