软件测试报告怎样写

其实没有什么固定的格式的：我认为只要介绍清楚你的测试覆盖范围、测试目的、测试执行过程情况、bug的不同维度统计（如bug模块分布图、bug严重程度分布图、bug来源分布图等），然后再加上一些bug来源分析，最后加个测试结论，应该就行了！如果你一定要模板的话，可以把你的邮箱留给我，我到时发你一份类似的，或者网上模板确实有很多，关键把握了我说的几个因素，然后看报告阅读对象的偏重点吧！

最近完成了一个我司初始期产品的可用性测试项目，基本可以理解为对新用户进行一下产品全流程各关键节点的体验走查，但也涉及了首页改版设计的需求挖掘。本篇主要是记录一下其中可用性测试部分的报告是如何向业务方呈现的，且怎么呈现更具有说服力与专业性。

首先，对于可用性任务的设置与计算方法网上已经介绍的十分详细，对于基本测试方法有需求的朋友可以随手某百，我就不再赘述。在这里，个人推荐一本书Jeff Sauro等人所著的《用户体验度量》，书中对于可用性测试样本的统计指标与方法，常用的可用性测量问卷与分数转化、对照参数已经有了很好的解读与传授教学。

一般，可用性测试的周期从接到需求到出具完整报告，我这边的项目周期是2-3周。这个时间的跨度取决于目标用户的招募难度与业务数据的完备性。我们在进行完整测试及对样本数据整理和汇总后，就进入了报告的撰写阶段。这个环节，才是传达用研价值的最关键环节。

话不多说，直接进入报告架构环节交代：

（PS：以下是我个人的报告架构，欢迎更专业的用研高手指点拔高）

Part 1 研究背景：

1交代研究目的（一针见血指出你这个报告能干嘛，结合业务发展背景更能提高观众的阅读兴趣）

2样本招募标准与配比，且需要把每个用户的基本产品使用经验进行下简单介绍，帮助业务方基本了解一下目前用户本产品与同类产品的使用经验（指标：频率、时长、深度、接触渠道等）

3如果业务方对研究方法不是很了解可以对方法也进行下介绍（目的作用、样本量代表性说明、可用性测试监测指标、计算方法等等）。个人觉得这个环节挺必要，因为业务方往往能够系统掌握方法论的较少，向上汇报的时候这些信息能够很前置且直观的打消观众的后续阅读疑惑

Part 2：产品可用性测试评估：

1当前产品整体可用性水平、曲线分级范围（整体可用性量表分数转化计算得出）

2关键任务（功能）的可用性水平：在这里我们可以结合功能价值与任务可用性水平一并输出一个XY轴的四象限图，一目了然划分流程体验优先级水平。随后，基于不同任务的可用性指标对比找出目前各环节的关键问题。推荐一篇文章，大家可以参照这位大大的详细说明来进行呈现与绘制。

文章——可用性测试：任务评估模型与计量方式 >

测试报告是把测试的过程和结果写成文档，对发现的问题和缺陷进行分析，为纠正软件的存在的质量问题提供依据，同时为软件验收和交付打下基础。包含以下内容：

1、概述 包括项目背景、需求分析。

2、测试时间、测试环境。

3、测试过程 评审记录、测试范围、测试用例。

4、功能实现清单 列出是否已经按照测试计划实现功能。

5、缺陷统计 测试缺陷统计; 测试用例执行情况统计。

测试报告是测试阶段最后的文档产出物。优秀的测试经理或测试人员应该具备良好的文档编写能力，一份详细的测试报告包含足够的信息，包括产品质量和测试过程的评价，测试报告基于测试中的数据采集以及对最终的测试结果分析。

---