在软件测试活动中，我们在每一轮测试完成之后，都会向项目组和相关的人员出具一份测试报告。这份报告的作用不仅需要展示该版软件的质量信息，也需要给项目组提供一些相关的分析。
测试报告中，有几个点非常重要。
测试对象
测试对象即我们要测试什么东西。但这个测试对象的描述是一个限定词，我们要描述我们的被测对象应该用能够让别人一眼就能知道的方式去描述。
比如我们要去买一个iphone，我们如果只是给导购员说买一个iphone，她会问你具体的型号。我们去说买一个iphone11、128G、黑色，这样基本就限定了你的对象。（要抬杠的话这里可以说是国行还是美版之类的）
我们的软件一样的需要进行相关的描述，对于嵌入式的软件来说，我们要描述的就不仅仅是软件，还需要加上硬件信息。
测试范围
由于不是所有的软件释放都有足够多的时间和人力来进行测试，在每一轮软件释放的时候都需要有软件测试计划，而软件测试报告中的测试范围是用于描述软件计划中所定义的软件测试范围是否被完整覆盖。
理论上来说，软件测试活动中所测试的范围应该是大于等于软件计划中的范围，不排除在软件测试过程中因为遇到了重大的问题而block了软件的测试导致软件测试没能完成。如果出现这种情况的时候，需要特别加粗字体进行说明
测试用例执行结果
这个部分是整个测试用例中报告的查阅者Zui关注的重点之一。阅读者通过阅读这一部分能够获取他想要获取的信息。
我们可以附录上测试用例的统计表，如图
这样一目了然的能够知道各个模块的通过率。
在这里，我个人建议不需要附录上各个模块的每个用例的测试结果，如果每个模块有不通过的测试用例，需要附录上该问题的具体描述以及Bug号，着重指出问题。
当然，我们应该要求所有测试用例的执行者需要在每一轮测试过程中不断更新测试用例，以确保在下一轮测试中能够使用正确的测试用例。
测试结果及分析
测试结果的是测试报告的执行者即TesterLeader需要做的事情，对于项目经理或者软件经理，通俗的来说你的Boss只需要知道软件的进展，比如当前还是的缺陷是处于什么状态的，是发散状态还是收敛状态，软件的critical的缺陷是否得到了修复，还是剩余了多少。是否有软件的修改引致的新问题等等。
如果在这个地方能够加上一些图表，会更利于阅读者了解产品的质量状况，如Bug曲线图等等。
这些部分都需要在测试结果中展现，而这些都属于客观的一些数据，谈不上真正的分析。而好的软件报告应该有测试人员对于软件的一些分析。比如，在本轮软件中，比如某个模块的缺陷突然爆发，我们就需要分析这个是因为测试用例设计的不合理导致原本很多问题应该发现而延迟被发现还是因为软件进行了重构导致了软件的缺陷激增等情况。这些方面的分析可以提供给项目经理或者软件经理用于之后软件版本的控制。
一个简单的软件测试报告的例子
目录
测试环境
测试结果
软件测试报告
3.1 测试用例执行情况
3.2 专项测试情况
3.3 自由测试情况
问题
4.1 已修复问题验证状态
4.2 新问题发现情况
4.3 问题去视图
4.4 客户发现问题状态
4.5 本轮软件测试
ps:软件测试报告完成发布后，并不表示软件测试就完成，仍然需要去关注所提出来的问题，包括修复的情况，需要复现的情况等等。
