不想当元帅的士兵不是好士兵。

《笑傲测试》笔记(第七式:语报平安)

上一篇 / 下一篇  2012-11-27 21:38:44

主题:如何书写测试报告

领导们通常是很关注测试的,因为通常只有测试团队才能够提供项目所处的真正位置。这种位置感来源于模块的成熟度、稳定度和主要问题列表。这种信息,我们叫它项目的可视性信息。可视性信息可以分为两类:

1) 对内的信息汇总,以测试日志为典型,记录每个测试工程师一天的进度、发现和困难,上报给测试经理;

2) 对外的信息发布,以测试报告为典型。测试经理汇总测试的数据和信息,作为项目进度和状态的重要标识上报给项目管理者。

一、测试日志(Test Log

测试日志是帮助测试经理获取测试信息的重要途径,它的发布者是测试团队中的每一个成员,测试日志的读者是测试经理,而在规模大一些的测试团队中,可能是测试小组的组长。测试日志的使命是让测试经理了解自己团队的状况。

二、测试报告(Test Report)——言简意赅、图文并茂

测试报告写作的七大原则:

(1) 字数要够少够精炼

用最少的篇幅和最简单的结构同时传达出所有的关键信息,这才是测试报告应该做的事。

1.首先要减少说废话套话,和测试无关的语言越少越好;

2.其次要避免过于细节,在报告后面可以尽情地添加附件来提供详细的信息,给求知欲强的人留有进一步专研的空间;

3.最后,信息要分层派送,比如封面上三句话说出你最想说的心里话,中间的内容把这三点展开来说,最后的封底处作出你作为测试人员对待测软件的评价和结论。

(2) 图表要够多够通俗

1. 饼图比大小(软件遗留问题模块分布)

2. 柱图比高矮(各测试组发现问题个数)

3. 曲线图上蹿下跳(软件稳定度的变化,问题解决率的变化,测试用例通过率的变化)

4. 面积图比胖瘦(遗留问题的解决趋势)

5. 图表要用的正确才有效

项目管理者关注的大部分东西都有合适的图表来表示:

1. 总体成熟度和子模块的成熟度:成熟度的计算方式有很多,其中最简单的是统计测试用例的通过率,我们在上面讲曲线图的时候有例子。

2. 缺陷分布:各种模块内遗留的问题数目及其比例,能帮助读者大略了解各个模块的稳定程度,饼图就是个很好的例子。

3. 缺陷趋势:成熟度的变化趋势,从中可以看出软件质量的走向,也是那个曲线图的例子。

4. 问题解决趋势,这是个很有用的关注点,从中可以看出问题解决的速度和趋势。当问题解决的速度下降的时候,能够及时向管理层报警提起重视,面积图的例子讲的就是这方面的东西。

图表能够标出各测试组或测试工程师的效率和进度,以便及时发现暗藏的问题,避免进度受影响;图表还能显示出各模块问题数和测试用例通过率的关系。

(3) 颜色鲜艳,通俗易懂

绿色代表一切正常,红色代表糟糕,黄色代表不好说。在测试报告中用绿色表示稳定的模块,红色表示有问题的模块。

(4) 既报喜又报忧,汇总出最严重的问题

在测试报告中列出未解决的TOP10严重故障。评审的对象之一就是剩余的严重问题都有哪些,以及产品带着这些问题上市的风险有多大,测试人员公正和客观的评价将是一个重要的参考。

(5) 报告时间要及时

测试报告是为了让项目的管理者在第一时间了解项目的状态,因此报告的时间不能拖拖拉拉,新闻变成了旧闻就不值钱了。根据报告的重要程度和所做测试量的大小,测试报告准备的时间也应当不一样。

(6)罗列的数据准确有力

测试关注质量,但如果测试本身的质量无法保证,那测试还不如不做。测试内部需要建立抽查机制:
1. 抽查应该成为一种持续的压力,不能搞献礼工程;
2. 抽查的比例要事先约定,根据是抽查的工作量和可投入的人力等;

3. 执行抽查的人必须有经验或者够权威,否则抽查出问题以后必将导致无休止的争论。

4. 参考以往的趋势(比如:测试用例通过率变化明显部分抽查)

(7) 逻辑要经得起推敲

测试报告中要做出很多结论,要注意结论的逻辑必须经得起推敲,做出的结论要有说服力。


TAG:

xin_晴的个人空间 引用 删除 xin_晴   /   2012-11-29 11:16:49
您好,我是51Testing软件测试网的编辑,您的本篇博文被推荐至51Testing软件测试网首页发表:http://www.51testing.com/html/11/n-830011.html
感谢您关注并支持51Testing博客,期待您更多的优秀原创博文。
 

评分:0

我来说两句

Open Toolbar