qileilove

blog已经转移至github,大家请访问 http://qaseven.github.io/

快速完成和读懂测试计划

 每个项目测试计划都会不一样,但是一般情况下,每个公司都会有相应的模板,尤其是项目很频繁的公司,相对应的模板应该就更全面,并且更容易修改,更能适应新项目。

  并且,经常接触测试计划的人可能会察觉到,实际上很多测试的计划都大同小意,里面有很多相似的模块,像是说明,缺陷管理,项目通过标准,暂停标准,恢复标准,风险管理,等等,都是可以直接套用的,并且这其中有过多的官方的术语,就是一种套话,客套话,很多文字是为了使文章更好去读,读起来更舒服,充当的是绿叶的角色。

  但是基本上说包含核心的内容都是根据不同的项目量身定做的,比如具体要测试特性,测试的milestone,schedule等等,这些是测试人员的测试的依据,时间安排的标准,是绝对马虎不得的,这也是测试计划的精髓所在。

  所以总的来说测试计划可以宏观的认为包含两个部分,一个是具体项目的测试安排,日程安排,人员分工,任务分工,里程碑的成果物等等,另一个是,适用于很多项目的一些约定俗成的标准,管理的方案,风险、缺陷的管理等等,这些不必随着项目的变化而更改,只要有一份模板,针对不同的项目进行简单的更改就可以了。

  其实这种写测试计划的方法也可以减少你的时间,更高效更有速度的阅读测试计划,因为当你拿到手中的是20几页的测试计划时,如果你选择从头一点一点的看,那真的很佩服你,如果是你的母语还好,文档若是一种外语,对自己来说很闹心,对公司来说也很浪费成本呀。一旦你清楚了测试计划中的窍门,你完全可一跳过那些标准,直接找到最核心的安排,分工,这样可以为您省去很多时间,也可以为公司创造更大的价值。

  如果您不是第一次接触测试计划,想必对这些会有一些感觉,对于读测试计划而言,知道这些是不够的,而需要的是去剖析一篇测试计划,一旦将其中的各个模块都弄懂了,在以后的阅读中就会是飞速了,不管阅读那个公司的,因为他们的本质是一样的,就有点像只要你掌握了一门编程语言,在去学其他的语言,也就是几个小时的事了。

  所以,理论讲到这里开篇也开到这里,接下来,我们就以随便的一篇文档进行剖析,最后可能会给各位一些网上普遍的测试模板,可以作为练习,自己阅读一下,是否可以快速阅读。

  我的这篇文档并非母语,所以各位要有准备,我们先从目录入手,简单预览一下:

  Test plan

  1,introduction
  2,test items
  3,features to be tested
  4,feature not to be tested
  5,approach
  6,item pass/fail criteria
  7,suspension criteria and resumption requirement
  8,test deliverables
  9,testing task and schedule
  10,environmental needs
  11,staffing
  12risks management
  13,approvals

  看起来有点多,不过仔细分析一下,里面需要写项只有1,3,4,8,9,10,11这几项,并且每一项需要写的东西都不多,其他的模块基本上都是绿叶啦!

  在这些需要写的模块中,有些还只是更改部分就行了,并且,在有些项目中,其中的有些东西都可以省略,但是要看具体公司的规定,有些公司测试计划是越多越好呀,显得严谨周密,结果让写的人闹心,看得人也不舒心呀!

  第1项中,有三项需要更改:

  product summary(产品目录),主要就是列出一些项目的功能特性,包含哪些模块,哪些软件,对与比较大的系统列出来,更有利于后面的分析,但是小的系统就没什么必要了。references(参考文献),这个就比较随意了,一般都会列出不同参与者的一些资料

  product milestore candidates(里程碑),这个是比较重要的,但是在后期也会出现,这里就是一个概览,一般都用表格的方式。

  第3项,是核心的东西,一般的就用这项来代替需求分析了,可能额外没有具体的需求分析文档,所以阅读时这是最重要的,和需求是统一等级的,所以在编写的时候也不仅仅测试经理自己写,可能更多的回去参考开发的需求,或者开发文档中的一些特性项目,这个应该不需要原创太多,主要是需求分析人员已经做好的东西搬过来了。

  第4项相对前面,就会好理解很多,主要由于一些硬性条件没法满足,无法进行测试的东西做一些说明。

  第8项,可以和里程碑相对应起来,但是又没有里程碑那么重要,就是在测试过程的小阶段说产生的成果物提前进行的一个预计,主要就是为了把一个很大的目标(一个一年或半年的项目顺利完成),拆分成一个月的成果检验(里程碑),然后再拆分两周的小任务,可以指导你短期的工作,但是,这个也会根据时间做适当的相应的调整的。

  第9项,这里主要的就是将里程碑进行完善和优化,要能够具体看了就知道怎么实施的文档。还有就是日程的安排,要对时间把握,另外有写时候会额外加一个文档schedule,专门就是做时间方面的计划的。

  第10项是,环境要求,这个就比较容易了,有什么写什么。

  第11项也是比较重要核心的东西,但是,有写的很详细,有些写的很宽松;对于大的项目,这个就会写的很简略,因为周期半年的项目没办法一下子把人员的任务都安排好呀,只能标记上需要哪些团队,都负责什么样的任务。具体的在根据具体的情况进行人员的分配。但是有些时候,对于项目比较小,可能就几周,人员也不多的时候,就需要将具体的分工分配下去,我当时分工分的很细,所以当时这个花费我很多时间去写,对后期的影响也很大,正因为这个任务分配的仔细,后期人执行起来有计可循,按照规定,每个人完成任务也都很有成就感。

  其余的就是额外的,基本也是不用动的,这其中包含了一个大块,里面有些很多文档的内容很丰富占了整个测试计划的很大的篇幅。

  第2项,列出了使用的测试的步骤,基本每个项目都可以按照这么去测试,里面包括冒泡,功能性能之类的,还会对具体的做一些特定的说明,尤其是公司会使用特定的工具。

  第5项这是篇幅最大的一个,里面冉冉就是一个测试方案的缩写版本,所以,这部分完全可以取代测试方案了,里面包括了测试用例的设计规则,使用的测试的方法(冒烟,交互性,系统,性能等等),缺陷管理的方法,缺陷曲线,会议评审的方式,测量和度量,这些都包括目标和范围,所以里面分析的很细,想必很多公司在弄这个的时候都是集结了很多经验的。

  第12项,风险管理,就是根据公司制定的了。

  综上所述,对这一个测试计划做了简单 的分析,相信可以类比到很多的测试计划。

  最后,再小小的总结一下,测试计划,其实是很简单的文档,写起来简单,读起来也简单,因为他有太多的相似和雷同,手中只要有一个模板,就有参考,再根据实际情况做一些小的调整。要弄清楚的是测试计划中核心部分和绿叶部分。

posted on 2013-02-26 11:05 顺其自然EVO 阅读(401) 评论(0)  编辑  收藏 所属分类: 测试学习专栏敏捷测试


只有注册用户登录后才能发表评论。


网站导航:
 
<2013年2月>
272829303112
3456789
10111213141516
17181920212223
242526272812
3456789

导航

统计

常用链接

留言簿(55)

随笔分类

随笔档案

文章分类

文章档案

搜索

最新评论

阅读排行榜

评论排行榜