【IT168 技术文档】

　　问题描述：在软件测试完成后，采用工具(TD、QC)或人工收集了一些数据，形成了各种图表。怎样去发挥这些数据的作用，进行有效深层次的数据分析，从而改进测试流程，完善测试过程?

　　精彩回答：

　　楼主说的数据分析! 其实可以理解为测试完成以后所要做的测试报告和总结，因为总结里会包括你之前所做的，遇到的问题，已经你做完后想提的建议等。把测试的过程和结果写成文档，并对发现的问题和缺陷进行分析，为纠正软件的存在的质量问题提供依据，同时为软件验收和交付打下基础。这是测试报告的定义。

　　通常，用户对测试结论部分感兴趣，开发人员希望从缺陷结果以及分析得到产品开发质量的信息，项目管理者对测试执行中成本、资源和时间予与重视，而高层经理希望能够阅读到简单的图表并且能够与其他项目进行同向比较。此部分可以具体描述为什么类型的人可参考本报告XXX页XXX章节，你的报告读者越多，你的工作越容易被人重视，前提是必须让阅读者感到你的报告是有价值而且值得浪费一点时间去关注的。

　　至于测试报告的格式，一般都有模板，这里也不多说了，只说说要注意的部分。

　　1、简要介绍测试中采用的方法和工具

　　测试方法可以写上测试的重点和采用的测试模式，这样可以一目了然的知道是否遗漏了重要的测试点和关键块。工具为可选项，当使用到测试工具和相关工具时，要说明。注意要注明软件名称，版本号等……

　　2、测试结果及缺陷分析

　　这是整个测试报告中这是最核心的部分，这部分主要汇总各种数据并进行度量，度量包括对测试过程的度量和能力评估、对软件产品的质量度量和产品评估。举楼主提到的TD为例子，可以用td生成BUG不同状态的数量表，如表1

　　从上表可以看出 每一天 存在的BUG数有多少， 还有多少没有修改， 有多少BUG被重新打开 等等…… 而且还可以细分到人，如BUG总数里有多少BUG 是谁找到的，BUG的严重程度是什么，是否是比较显性的，是否是很隐性的，这样就可以从一个方面考察测试人员的综合素质。

　　此外可以用生成的BUG 走势图，更直观的分析测试流程是否正常，见下面的粗略分析

　　open线可以看出这个项目是提交了3次版本的 11号 17号 21号 3次版本提交， 这与实际的情况一致。

　　Fixed线也是可以看出3个波峰。其他的线也是中规中矩，

　　这几个指标都符合1版本80% 2版本90% 3版本98%的通过率。这是很正常，流程走的很顺的一次测试任务。

　　那再看下面的这张图：

　　分析：

　　Open线 也是出现了3个波峰，但是不是按照 " 高-中-低 " 的方式排列，而是 3个相同差不多的波峰，这就说了3个可能 。

　　一 可能是测试人员不合格，在测试第1版本的时候没有全力测试

　　二 可能就是开发提交版本的时候，修改的部分引起了其他模块的异常，要么修改了需求，要么程序写的非常糟糕，可以要求打回去重写。

　　三 就是需求老是在变，而且各部门没有沟通好。。

　　Fixed线 可以看到 开发人员一直在修改BUG ，这样对项目，对测试 ，对开发都是很闹心的事情，而且这样的版本发布，也是提心吊胆的……

　　3、特定类型bug分析总结

　　对一些测试得出的比较典型的和严重程度教高的BUG 要列举出来。这样可以让开发人员再下次版本设计的时候可以注意到。

　　举例： 一些输入框不允许html代码的输入，而且这样的操作会影响到这个网站的安全，那么就要提出来，以至使开发人员在全网站把类似的代码屏蔽或者转换掉。因为测试人员测试的东西比较有限，可能发现不全，开发人员关注的层面是代码面，了解的程度比你深，而且他们还可以用批量的方法查找，替换。

　　4、残留缺陷与未解决问题(延迟的BUG)

　　编号：BUG号

　　缺陷概要：该缺陷描述的事实

　　原因分析：为什么会引起缺陷，缺陷的后果，目前不解决BUG的原因。以及这些问题如果发出去了会造成什么样的影响，影响是不是大?是否可控等……

　　预防和改进措施：弥补手段和长期策略

　　5、测试结论

　　报告到了这个部分就是一个总结了，对上述过程、缺陷分析之后该下个结论，此部分为项目经理、部门经理以及高层经理关注了。

　　1. 测试执行是否充分(可以增加对安全性、可靠性、可维护性和功能性描述)

　　2. 对测试风险的控制措施和成效

　　3. 测试目标是否完成

　　4. 测试是否通过

　　5. 是否可以进入下一阶段项目目标

　　6、建议

　　1.对系统存在问题的说明，描述测试所揭露的软件缺陷和不足，以及可能给软件实施和运行带来的影响

　　2.可能存在的潜在缺陷和后续工作

　　3.对缺陷修改和产品设计的建议

　　4.对过程改进方面的建议