报告模板

一份开发可以直接排查的 Android Bug 报告

报告不是附件堆积,而是把最短复现路径、预期与实际结果、环境和同一时间段的证据连接起来。

直接答案

Android Bug 报告至少应包含明确标题、环境与版本、最短复现步骤、预期结果、实际结果、发生时间,以及同一复现窗口内的截图或录像、异常日志和相关请求。敏感信息应在分享前删除或打码。

TabQA 导出的 Android Bug 报告和截图日志附件
结构化字段说明问题,附件证明发生了什么;两者缺一不可。

可直接使用的模板

# [模块] 简短描述实际问题

- 时间:YYYY-MM-DD HH:mm:ss + 时区
- 设备:品牌 / 型号 / Android 版本
- App:名称 / 版本 / 包名 / 环境

## 复现步骤
1. …
2. …
3. …

## 预期结果
…

## 实际结果
…

## 附件
- 录像与关键截图
- 同一时间范围内的 logcat
- 相关请求或脱敏 HAR

提交前检查

  • 标题描述实际差异,而不是只写“功能异常”。
  • 步骤从可重复的起点开始,并删除无关动作。
  • 录像、截图、日志和请求使用同一发生时间。
  • 说明是否必现、出现频率和已尝试的排查。
  • 检查账号、令牌、设备标识和生产数据。

TabQA 如何生成初稿

TabQA 保存设备与目标 App 信息、终态截图、录像、筛选后的日志和网络请求。测试人员填写标题、步骤、预期与实际结果后,可以导出 report.md 和选中的附件。报告仍应由提交人检查和补充业务背景。

来源与依据