测试计划编写.docx

4 4． 测试计划编写 6 要素？（5W1H） 1）why——为什么要进行这些测试； what—测试哪些方面，不同阶段的工作内容； when—测试不同阶段的起止时间； where—相应文档，缺陷的存放位置，测试环境等； who—项目有关人员组成，安排哪些测试人员进行测试 how—如何去做，使用哪些测试工具以及测试方法进行测试。 做好测试计划和测试用例的工作的关键 做好测试计划和测试用例的工作的关键 （一） 先说测试计划吧 一个好的测试计划是用来计划测试的，指导整个测试过程。所以一个好的测试计划一定是可以指导测试的， 就是对整个测试过程中的人力，时间，资源，策略，范围的一个说明。 作为一个测试计划来讲，核心的三个要素是时间，资源，范围。（这句话摘自微软的软件测试培训材料）， 时间就是什么时候做以及要花多久做，资源就是你要调用的人力、机器等资源，范围是你要测试的东西以 及测试重点。 除以上提到的 3 项之外，还有比较重要的项目有策略（具体就是怎么测）、风险控制（一旦有问题采取什么应急措施）等项目。 要把一个计划做得很有实用性，按照笔者的经验，要注意以下几个方面： 上面提到的三要素不能少 测试策略一定要交待清楚，就是大概怎么测试 需要其他人员（部门）协调的，要交待清楚 在估计测试所需的时间、人力及其它资源时，尽量做到客观、准确、留有余地，特别是估计开发时间和 debug 时间，以及要对自己的执行用例速度，回归速度心里有数 测试计划中每个阶段要明确表明，并且测试阶段的输入、输出文档要清楚 测试计划中的时间段不宜太长（最好以 day 为单位），太长就比较模糊，不好度量，不好 check 一定要有风险控制，要不然计划缺乏可执行性 计划写完之后不是装在兜里，要组织PM 和 Dev 进行评审 要不断更新计划，记住：每个计划都是动态的，不是一成不变的 （二） 再说测试用例 和测试计划一样，测试用例很多时候也沦为形式，这是软件测试的可悲之处，软件测试的依据就是测试用例，如果用例弃之不用，你凭什么做好测试？这个很可笑。但是实际测试过程中很多时候测试用例并没用到实处，笔者认为还是用例实用性问题，有的时候用例洋洋洒洒数万字，到回归测试的时候根本用不上， 至于如何选择回归测试用例，我曾经写过另一篇文章，欢迎查阅。 下面我就个人体会谈谈做好测试用例的关键。首先，在做用例之前，要做两件事情。 第一， 透彻了解程序（需求和架构）。 第二， 做一个正式的测试设计（最好文档化）。然后再开始写用例。一般写用例的步骤和建房子一样，先搭框架，然后填材料，填材料的时候，主要根据需求做相关的设计，具体的设计方法就是那几种（郑老的书上写的很清楚） 一般来说，设计一个比较实用的测试用例，注意如下几个方面： 选用好的用例管理工具（这个很重要，千万不要用 word，excel） 用例一定要及时更新（补充新的想法，删除过时的需求） 做好用例分级 做好用例评审，写用例之前可以征询相关人员的意见 可以考虑结对编写，这个是不错的主意 要全面，包括功能、性能、兼容性、安全性、易用性、容错性等等 注意把握适当的颗粒度 OK，以上是我个人总结的一些心得，希望对您有些帮助. 我不知道 lz 说的做好测试计划中的“做好”两字具体指的是什么 对于目前大部分公司存在的状况，很多测试计划文档只是一种形式而已所以我的理解是：怎样让测试计划对整个测试工作真正具有指导作用 这里把测试计划和测试方案分开来讲（计划对应于管理层面的问题，方案对应于技术方面的问题） 测试计划中最重要的内容包括：进度安排；人力、物力资源分配（包括组织结构等）、风险假设和规避措施。（其他像软件版本号之类的，只要是个人都会写，这里不列了） 写好测试计划的关键在于： 充分了解你的团队的整体实力和团队中每个成员的特点 充分理解为当前软件制订的整个研发活动过程 带过项目的人都知道：在实际项目中，往往进度才是第一位的，但是对进度的把握和估算却是极其困难的。只有做到这两点才有可能对进度有比较准确的把握，对人员有一个合理的分配。否则所谓的进度，所谓的资源分配，都是拍脑袋得出的结果，风险假设更是无从谈起，这样的测试计划文档只能流于形式也就不足为奇了。 写好测试方案的关键在于： 有一个合理的测试计划 熟悉相关业务 深入体会用户的实际需求 这个不想多解释了，不难理解。 至于测试用例 看到上面不少朋友认为关键在于理解用户需求其实理解用户实际需求是一切的根本 并且对于有些测试（比如像单元测试）对应的测试用例通常和用户需求之间的关系可能并不直接或是十分密切 当然，如果有一份好的需求和设计文档的话，什么事情都解决了。 可是现实往往是不存在这样的文档的。所以我的看法是： 1 对业务理解的深入程度 经验 经验 有自己的文档 前两条不解释了。 自己的文档包括两方面：一个是