Chinaunix首页 | 论坛 | 博客
  • 博客访问: 117470
  • 博文数量: 107
  • 博客积分: 0
  • 博客等级: 民兵
  • 技术积分: 291
  • 用 户 组: 普通用户
  • 注册时间: 2014-11-12 22:20
文章分类

全部博文(107)

文章存档

2017年(39)

2016年(1)

2015年(3)

2014年(1)

2011年(2)

2010年(41)

2009年(19)

2008年(1)

我的朋友
最近访客

分类: 系统运维

2010-09-25 14:55:19

  作为对测试工作和项目情况的总结,对测试成果的体现,有着很重要的意义。通常来讲,我们会在测试过程中,由测试经理定期写工作汇报给上级,在测试结束后,写一份包罗万象的,然后发给上级、成员、或者客户。这是普遍的做法,但经过这几年的总结,我开始根据不同的对象,写不同的报告。
  主要是因为不同的对象,关注不同的事务。如果一股脑的把所有的内容都揉合在一份文档里,文档内容过长,试问哪个阅读者有耐心去读完?曾经把文档的结构做过调整,按阅读者进行了结构的调整,但是问题还是来了,一是,遇到挑剔的上层,他们会认为你发的东西还是过于冗余,太多他不关心的东西,那么你的工作就做的不好。二是,在测试报告中,难免会有一些不适合发给客户的内容。其他还有很多情况,让一份包罗万象的测试报告被万般挑剔。
  总体来说,报告的对象大致分为3类:
  项目管理阶层、项目组开发测试人员、客户或其他的预期读者
  对于不同的读者,在不同的阶段,侧重点的大概内容如下(这里只说开发结束后的测试报告部分,也只提一个框架,具体的大家自己根据公司实际情况去填充。开发中的各类报告在此省略):
  ◇   项目管理阶层
    ●  产品的质量
    ●  对整个过程的总结、分析
    ●  展示一些测试团队的成果数据
    ●  对消耗的资源(时间、人力、物力)进行分析
  ◇    项目组成员
    ●  对各个阶段进行总结,关注可以提升的地方,以及值得推广的经验
    ●  对各个阶段每个成员的表现进行分析、统计,进行评定
  ◇    客户或其他的预期读者
  
    ●  产品的质量信息(包括对用例执行情况的统计、趋势的分析、性能报告手册等)
    ●  其他的客户要求提供的信息
  简单的看,这种做法只是把原有的文档拆分成3份文档,有的放矢。
  总体来说,无论哪种形式的报告,原则都是一致的:简单易懂,风格一致。
本文转载自51Testing软件测试网,原文链接:
阅读(948) | 评论(0) | 转发(0) |
给主人留下些什么吧!~~