当测试活动完成之后，要形成测试报告。在测试报告中，测试人员要对测试数据展开分析，并将测试结果和对测试数据的分析向利益相关方通报。
测试数据分析，也是GJB5000/CMMI的验证和确认过程域的一个专用实践，但是，少有实施GJB5000A的组织对这一实践有很好地理解，测试报告中多以罗列测试数据为主，几乎没有什么有价值的分析。
对于测试结果应该如何去分析才会给项目带来价值呢？
软件的测试结果可以从以下几个方面进行分析：
测试目标是否达成
已发现的缺陷对系统的影响
软件交付使用后可能面临的风险
软件优化建议
过程改进建议
1. 测试目标是否达成
软件测试通常需要达成两个主要目标。第一个目标是保证软件满足用户需求。第二个目标是保证软件能运行在真实的用户环境中。
对于第一个目标，要通过分析执行测试用例对需求覆盖的充分性来判断；而第二个目标是通过分析测试环境和真实环境的差异来判断。
2. 已发现的缺陷对系统的影响
对测试结果的分析除了回答软件是否满足需求之外，还应该回答已经发现了很多缺陷的软件会对软件所在的系统造成什么影响。
有条测试公理是这样描述的：随着软件中某个部分已发现的缺陷的不断增多，其中存在更多未发现的缺陷的概率也会增大。
所以，如果某个功能模块发现的不只一个缺陷，那么这个功能模块就可能潜伏着尚未发现的缺陷。测试人员应当分析这样的功能模块对软件所在系统是否造成影响，以帮助管理者做出决策。
3. 软件交付使用后可能面临风险
测试人员应能根据组织的测试数据库，来预测软件遗留的缺陷，并据此来判断软件交付使用后是否存在风险。
4. 软件优化建议
测试人员可以从软件模块的缺陷分布的统计分析中给出对软件进一步优化的建议。
软件模块的缺陷分布能够标识出哪些模块有较多的缺陷，这些模块应当在软件的后续维护活动中优先进行重构。
5. 过程改进建议
测试人员可以从引入阶段的缺陷分布来给出过程改进的建议。
引入阶段的缺陷分布能够标识出引入缺陷较多的阶段，这些阶段缺陷较多，就意味着这些阶段中的质量控制不好，或者是质量活动有效性不足，或者是质量活动被裁剪得太多。组织的EPG就当考虑对此类的软件开发模型进行改进，加强那些出现缺陷较多的阶段的质量控制。
这正是：
辛苦测试有结果，不作分析浪费多
满足需求给结论，支持改进结硕果
联系客服
