|
|
发表于 2007-9-27 18:01:19
|
显示全部楼层
说实话,这份文档不算一份好的测试"总结""报告",
我简单看了一下,发现一些问题,希望对大家有所帮助:
1. 突出重点:
测试报告重点是报告,文档的读者通常是qa manager或者是project manager, 甚至是公司的其他中层或者高层. 而他们通常只关注问题的结果, 而不关注实现的细节. 所以要重点突出测试的成果,状态,问题, 建议,而其他的可以作为附件,提供给对之感兴趣的人做参考. 所以可以考虑将测试成果之类的提前, 把具体测试方法之类的细节放在附件或者文档后半部分.
2.总结经验/教训
作为一份总结报告,需要体现一部分对测试结果的分析,当前项目的质量分析,而不能仅仅是各种数据的罗列
比如说,各任务的执行情况,不能仅仅体现完成. 建议附加, 计划完成时间,实际完成时间,提前或滞后原因
3. 细节方面:
3.1 缺陷列表缺少priority域, 开发人员比较难已已之为根据决定修bug的先后,也容易造成比较难修但是很重要的问题拖到最后
3.2 缺少resource方面的统计信息,如qa几人,senior qa几人等等
3.3 测试总结报告不仅仅报告当前存在的问题,也要总结实际工作成果,比如说总共发现bug的数量,分布
3.4 测试报告有别于测试计划,部分内容建议仅应保留在测试计划中,如测试方法细节
3.5 测试总结报告里面没有看到和requirements相关的内容,其实测试就是检验和requirements的契合程度,否则也无法衡量测试的质量和目标. 比如性能测试,如果有requirements,就可以很方便进行分析
3.6 ...
当然这份文档中还是有很多让人欣喜的内容,比如开发文档测试方面的内容,这是即使很多测试很成熟的公司所没有做到的. |
|
/1 
关于我们
