测试计划评审

《测试计划评审》由会员分享，可在线阅读，更多相关《测试计划评审（8页珍藏版）》请在金锄头文库上搜索。

1、为了适应公司新战略的发展，保障停车场安保新项目的正常、顺利开展，特制定安保从业人员的业务技能及个人素质的培训计划测试计划评审测试计划评审表测试计划编写规范广州卓勤信息技术有限公司目录1.目的.32.适用范围.33.术语和缩略语.34.规范要求.35.引用文件.36.质量记录.37.附录：软件测试计划模版.41.目的软件测试计划用于明确软件产品确认测试过程中测试设计、测试执行及测试总结工作的具体任务分解、人员安排、进度及输出结果。以使整个测试工作有计划地顺利进行。本文规定了测试的编写格式及要求。2.适用范围本规范适用于软件项目与软件产品的功能测试与系统测试。3.术语和缩略语本程序采用质量手册中的

2、术语和缩略语及其定义。4.规范要求1)按照项目计划的要求，由测试负责人编写软件测试计划；2)软件测试计划由项目经理PM审核，项目管理部门负责人批准；3)软件测试计划由测试负责人TL组织测试小组和开发部门进行评审。5.引用文件本程序采用质量手册中的术语和缩略语及其定义。6.质量记录“软件测试计划评审记录”7.附录：软件测试计划模版软件测试计划评审记录记录编号：1.由PM审核，项目管理部门负责人批准。2.此页不足记录结果时，可以有附页，总页数包含所有附页。项目名称软件测试计划4测试计划编写6要素？1）why为什么要进行这些测试；2)what测试哪些方面，不同阶段的工作内容；3)when测试不同阶段

3、的起止时间；4)where相应文档，缺陷的存放位置，测试环境等；5)who项目有关人员组成，安排哪些测试人员进行测试6)how如何去做，使用哪些测试工具以及测试方法进行测试。做好测试计划和测试用例的工作的关键先说测试计划吧一个好的测试计划是用来计划测试的，指导整个测试过程。所以一个好的测试计划一定是可以指导测试的，就是对整个测试过程中的人力，时间，资源，策略，范围的一个说明。作为一个测试计划来讲，核心的三个要素是时间，资源，范围。，时间就是什么时候做以及要花多久做，资源就是你要调用的人力、机器等资源，范围是你要测试的东西以及测试重点。除以上提到的3项之外，还有比较重要的项目有策略、风险控制等项

4、目。要把一个计划做得很有实用性，按照笔者的经验，要注意以下几个方面：a.上面提到的三要素不能少b.测试策略一定要交待清楚，就是大概怎么测试c.需要其他人员协调的，要交待清楚d.在估计测试所需的时间、人力及其它资源时，尽量做到客观、准确、留有余地，特别是估计开发时间和debug时间，以及要对自己的执行用例速度，回归速度心里有数e.测试计划中每个阶段要明确表明，并且测试阶段的输入、输出文档要清楚f.测试计划中的时间段不宜太长，太长就比较模糊，不好度量，不好checkg.一定要有风险控制，要不然计划缺乏可执行性h.计划写完之后不是装在兜里，要组织PM和Dev进行评审i.要不断更新计划，记住：每个计划

5、都是动态的，不是一成不变的再说测试用例和测试计划一样，测试用例很多时候也沦为形式，这是软件测试的可悲之处，软件测试的依据就是测试用例，如果用例弃之不用，你凭什么做好测试？这个很可笑。但是实际测试过程中很多时候测试用例并没用到实处，笔者认为还是用例实用性问题，有的时候用例洋洋洒洒数万字，到回归测试的时候根本用不上，至于如何选择回归测试用例，我曾经写过另一篇文章，欢迎查阅。下面我就个人体会谈谈做好测试用例的关键。首先，在做用例之前，要做两件事情。第一，透彻了解程序。第二，做一个正式的测试设计。然后再开始写用例。一般写用例的步骤和建房子一样，先搭框架，然后填材料，填材料的时候，主要根据需求做相关的设

6、计，具体的设计方法就是那几种一般来说，设计一个比较实用的测试用例，注意如下几个方面：a.选用好的用例管理工具b.用例一定要及时更新c.做好用例分级d.做好用例评审，写用例之前可以征询相关人员的意见e.可以考虑结对编写，这个是不错的主意f.要全面，包括功能、性能、兼容性、安全性、易用性、容错性等等g.注意把握适当的颗粒度OK，以上是我个人总结的一些心得，希望对您有些帮助.-我不知道lz说的做好测试计划中的“做好”两字具体指的是什么对于目前大部分公司存在的状况，很多测试计划文档只是一种形式而已所以我的理解是：怎样让测试计划对整个测试工作真正具有指导作用这里把测试计划和测试方案分开来讲测试计划中最重

7、要的内容包括：进度安排；人力、物力资源分配、风险假设和规避措施。写好测试计划的关键在于：1充分了解你的团队的整体实力和团队中每个成员的特点2充分理解为当前软件制订的整个研发活动过程带过项目的人都知道：在实际项目中，往往进度才是第一位的，但是对进度的把握和估算却是极其困难的。只有做到这两点才有可能对进度有比较准确的把握，对人员有一个合理的分配。否则所谓的进度，所谓的资源分配，都是拍脑袋得出的结果，风险假设更是无从谈起，这样的测试计划文档只能流于形式也就不足为奇了。写好测试方案的关键在于：1有一个合理的测试计划2熟悉相关业务3深入体会用户的实际需求这个不想多解释了，不难理解。至于测试用例看到上面不

8、少朋友认为关键在于理解用户需求其实理解用户实际需求是一切的根本并且对于有些测试对应的测试用例通常和用户需求之间的关系可能并不直接或是十分密切当然，如果有一份好的需求和设计文档的话，什么事情都解决了。可是现实往往是不存在这样的文档的。所以我的看法是：1对业务理解的深入程度2经验3有自己的文档前两条不解释了。自己的文档包括两方面：一个是常用的特殊测试数据，比如一些特殊字符，极限长度的输入等等。这个在项目时间紧迫的时候是非常有帮助的。另一个就是自己测试模块对应的相关需求和设计文档。服务器上的标准文档拖到本地来并且记得及时更新。然后在测试过程中，需要什么内容文档上没有，最直接的方法是和开发人员沟通。任何标准文档上缺少的内容，只要是和你有关的，一定要记得做记录。当然你有时间有精力把整个系统的需求和设计文档都捣鼓出来最好，不过通常是没这可能性的。补充说明：lz最后提到的“完全凭借自己的经验在执行测试活动”不如说是完全凭借自己的感觉在执行测试活动项目需要的用例详尽程度可以商量，但是必须要有。如果进度很紧，可以用一部分用例加上checklist进行测试活动目的-通过该培训员工可对保安行业有初步了解，并感受到安保行业的发展的巨大潜力，可提升其的专业水平，并确保其在这个行业的安全感。