入行软件测试的人员最需要掌握的基本功有三：设计测试用例、发现缺陷、撰写测试报告，透过这三个基本功基本可以摸清一名测试人员的专业度及其在其他方面的测试技能熟练程度，而从测试报告可以看出用例设计和发现缺陷两项基本功是否扎实，本文简短的梳理了软件测试报告需要包含哪些基本内容。
特别备注：本文案例是笔者所在项目的实践，仅作为互联网软件研发质量保证参考，因地制宜的实施，而不是时机不成熟就统计，那可能本末倒置，甚至带来负面影响。
背景介绍
互联网行业大多都追求敏捷，即产品需求快速迭代发布。Web、H5、服务端一般可以做到每日发布，至少每周一次发布，目前所负责业务线是每周两次发布。 关于敏捷实践经验，未来再梳理，本文不赘述。
当前研发迭代周期：
客户端产品：Android/iOS各一个版本
H5/web/服务端：每周两次发布（两个发布日）
测试报告规范
1. 客户端产品：
1）系统集成测试阶段输出 - 每日测试报告
2）版本测试总结报告 - 版本发布完输出
2. 日常迭代测试报告：发布日输出；大需求单独输出测试报告
3. 质量总结报告：建议半年输出1次，每年2次
测试报告内容
<需求统计分析>案例：
<缺陷回归分析>案例：
<缺陷一次性修复成功率>案例：
软件质量总结报告
备注1：建议半年输出1次，每年2次
备注2：有两个数据（单位需求缺陷数、单位需求用例数），可以统计作为研发效能考量，但有个前提：产品需求规范，研发流程规范，测试用例设计规范等系列规范落地执行后，拉长时间段对比方有意义。
单位需求缺陷数：
一定程度上反映提测质量
单位需求用例数：
一定程度上反映需求复杂度
<缺陷趋势图>案例：
<研发过程数据统计>案例：
项目 | 实现需求数 | 新增测试用例 | 新增缺陷数 | 线上故障 | 漏测率 （线上故障/新增缺陷） |
项目1 | 139 | 1052 | 765 | 3 | 0.39% |
项目2 | 130 | 351 | 457 | 3 | 0.66% |
项目3 | 145 | 710 | 124 | 0 | 0.00% |
项目4 | 791 | 1753 | 477 | 2 | 0.42% |
项目5 | 54 | 177 | 67 | 2 | 2.99% |
项目6 | 442 | 3988 | 762 | 8 | 1.05% |
项目7 | 9 | 16 | 23 | 0 | 0.00% |
项目8 | 444 | 264 | 82 | 2 | 2.44% |
项目9 | 23 | 51 | 25 | 0 | 0.00% |
项目10 | 11 | 0 | 3 | 0 | 0.00% |
总数 | 2188 | 8362 | 2785 | 20 | 0.72% |
<用户反馈分析>案例：
end