如何获取网站开发语言,手机网站和pc网站,响应式网站首页,ie浏览器哪个做网站稳定每个项目测试计划都会不一样#xff0c;但是一般情况下#xff0c;每个公司都会有相应的模板#xff0c;尤其是项目很频繁的公司#xff0c;相对应的模板应该就更全面#xff0c;并且更容易修改#xff0c;更能适应新项目。 并且#xff0c;经常接触测试计划的人可能会察… 每个项目测试计划都会不一样但是一般情况下每个公司都会有相应的模板尤其是项目很频繁的公司相对应的模板应该就更全面并且更容易修改更能适应新项目。 并且经常接触测试计划的人可能会察觉到实际上很多测试的计划都大同小意里面有很多相似的模块像是说明缺陷管理项目通过标准暂停标准恢复标准风险管理等等都是可以直接套用的并且这其中有过多的官方的术语就是一种套话客套话很多文字是为了使文章更好去读读起来更舒服充当的是绿叶的角色。 但是基本上说包含核心的内容都是根据不同的项目量身定做的比如具体要测试特性测试的milestoneschedule等等这些是测试人员的测试的依据时间安排的标准是绝对马虎不得的这也是测试计划的精髓所在。 所以总的来说测试计划可以宏观的认为包含两个部分一个是具体项目的测试安排日程安排人员分工任务分工里程碑的成果物等等另一个是适用于很多项目的一些约定俗成的标准管理的方案风险、缺陷的管理等等这些不必随着项目的变化而更改只要有一份模板针对不同的项目进行简单的更改就可以了。 其实这种写测试计划的方法也可以减少你的时间更高效更有速度的阅读测试计划因为当你拿到手中的是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 看起来有点多不过仔细分析一下里面需要写项只有134891011这几项并且每一项需要写的东西都不多其他的模块基本上都是绿叶啦 在这些需要写的模块中有些还只是更改部分就行了并且在有些项目中其中的有些东西都可以省略但是要看具体公司的规定有些公司测试计划是越多越好呀显得严谨周密结果让写的人闹心看得人也不舒心呀 第1项中有三项需要更改 product summary(产品目录)主要就是列出一些项目的功能特性包含哪些模块哪些软件对与比较大的系统列出来更有利于后面的分析但是小的系统就没什么必要了。 references(参考文献)这个就比较随意了一般都会列出不同参与者的一些资料 product milestore candidates(里程碑)这个是比较重要的但是在后期也会出现这里就是一个概览一般都用表格的方式。 第3项是核心的东西一般的就用这项来代替需求分析了可能额外没有具体的需求分析文档所以阅读时这是最重要的和需求是统一等级的所以在编写的时候也不仅仅测试经理自己写可能更多的回去参考开发的需求或者开发文档中的一些特性项目这个应该不需要原创太多主要是需求分析人员已经做好的东西搬过来了。 第4项相对前面就会好理解很多主要由于一些硬性条件没法满足无法进行测试的东西做一些说明。 第8项可以和里程碑相对应起来但是又没有里程碑那么重要就是在测试过程的小阶段说产生的成果物提前进行的一个预计主要就是为了把一个很大的目标一个一年或半年的项目顺利完成拆分成一个月的成果检验里程碑然后再拆分两周的小任务可以指导你短期的工作但是这个也会根据时间做适当的相应的调整的。 第9项这里主要的就是将里程碑进行完善和优化要能够具体看了就知道怎么实施的文档。还有就是日程的安排要对时间把握另外有写时候会额外加一个文档schedule专门就是做时间方面的计划的。 第10项是环境要求这个就比较容易了有什么写什么。 第11项也是比较重要核心的东西但是有写的很详细有些写的很宽松对于大的项目这个就会写的很简略因为周期半年的项目没办法一下子把人员的任务都安排好呀只能标记上需要哪些团队都负责什么样的任务。具体的在根据具体的情况进行人员的分配。但是有些时候对于项目比较小可能就几周人员也不多的时候就需要将具体的分工分配下去我当时分工分的很细所以当时这个花费我很多时间去写对后期的影响也很大正因为这个任务分配的仔细后期人执行起来有计可循按照规定每个人完成任务也都很有成就感。 其余的就是额外的基本也是不用动的这其中包含了一个大块里面有些很多文档的内容很丰富占了整个测试计划的很大的篇幅。 第2项列出了使用的测试的步骤基本每个项目都可以按照这么去测试里面包括冒泡功能性能之类的还会对具体的做一些特定的说明尤其是公司会使用特定的工具。 第5项这是篇幅最大的一个里面冉冉就是一个测试方案的缩写版本所以这部分完全可以取代测试方案了里面包括了测试用例的设计规则使用的测试的方法冒烟交互性系统性能等等缺陷管理的方法缺陷曲线会议评审的方式测量和度量这些都包括目标和范围所以里面分析的很细想必很多公司在弄这个的时候都是集结了很多经验的。 第12项风险管理就是根据公司制定的了。 综上所述对这一个测试计划做了简单 的分析相信可以类比到很多的测试计划。 最后再小小的总结一下测试计划其实是很简单的文档写起来简单读起来也简单因为他有太多的相似和雷同手中只要有一个模板就有参考再根据实际情况做一些小的调整。要弄清楚的是测试计划中核心部分和绿叶部分。转载于:https://www.cnblogs.com/feiers/archive/2010/05/07/1729954.html
