[鹿鸣推荐]关于计划测试

关于计划测试

 

本文作者 : 陈雷 (jackeichan@gmail.com )

 

测试人员的目标是尽早的找出缺陷，并确保缺陷真正的解决。而好的测试计划可以更好的帮助测试人员把握自己的工作情况。

首先明确一个概念——测试计划。

这里的测试计划，计划是作为动词而不是名词使用，或者应该叫做“计划测试”更恰当，其中的重点在于对整个测试项目工作的计划，而通常大家理解的“测试计划”只是用来记录最终结果的那份文档。再说得明确一点，是“计划测试工作”，而不是“编制测试计划”。

计划测试通常是开始测试工作的第一个任务，一般来说应该由团队中具有丰富测试经验的工程师或者测试经理来完成，不建议测试新手接手这件事情。不过新手可以帮忙整理一些计划测试所需要的资料，也可以从中知道计划测试工作需要哪些信息，为以后从全局的角度看待测试问题打好基础。另外，测试新手还可以通过帮助整理资料学着制定自己的测试任务和计划自己的工作，也是不错的锻炼。

不知道会不会有人看了上面的内容会说：说了这么多废话，到底测试计划是干什么用的？我认为，计划测试的最终目的是为了交流！

有人认为计划测试是为了方便安排自己的工作，其实也可以有这个作用。不过在实际的开发过程中，一般由多个团队相互协调来完成工作，测试工作作为这个过程中的一环也不会例外。在计划测试的过程中，测试人员要明确测试的范围、方法、资源和进度，明确正在测试的项目需要测试的特性、每个任务的负责人，还有与测试相关的风险。这些内容的定义是为了说明测试团队的意图、期望以及对将要执行的任务的理解，最终同开发部门（或者客户支持部等相关的部门）交流并确定下来。

下面是我在制定测试计划时考虑的一些问题和经验。当然，因为计划本身应该是一个动态的过程，所以当发现下面的问题不适用于具体的工作时，可以增加、减少或调整。但是有一点需要注意，最终确定下的问题列表应当在项目组中进行讨论，在不同的部门间相互沟通，最终达成一致。另外，限于本人的工作经验，不能保证这些问题一定适用于所有的项目，而只是包括了一些常见的需要考虑的问题，很多具体的工作问题，大家还是要“一切从实际出发”，自己多研究多思考。

 

1.计划测试过程的目的是什么？

我一向推崇的做事方法是先明确自己到底要什么，然后明确自己为了这个目标要做什么，之后才明确该怎么做，这些对于计划测试一样适用。如果你无法找到计划测试的理由，那么就不要在这上面费太大力气了。

关于计划测试过程的目的，我的观点已经在上面描述过——为了交流。为了更好的开展工作，测试部门需要各个部门的认可和支持。

 

2.你所要进行测试的产品和版本是什么？

可能很多朋友会说：现在我们的项目管理很混乱，在整个测试过程中会不断的有新版本，测试工作太被动了。

如果真的是这样，那么就考虑引入完善的版本管理方法吧。因为一直从事一些大型项目的测试，对于版本的迭代，并且是无序的迭代，我已经吃尽了苦头。如果无法把测试人员和开发人员的注意力集中到某个版本，那么工作的情绪和信心会逐渐跌落。

 

3.产品的质量目标是什么？

可能在一个项目中，老板、市场部、客户支持部同开发人员、测试人员对于质量的认识都不相同，那么就有可能会出现争论。不过不管怎么说，各部门必须要有一个明确的质量要求，并且为自己的要求提出一个准确的定义：要求响应速度，就要明确每秒响应多少业务；要求稳定，就要明确需要运行多少小时不出现问题；要求缺陷级别，就要明确系统在使用时不能出现某个级别的bug……

最终，必须使测试目标明确并一致通过，以免无法确定测试结束和程序发布的时间。

 

4.需要什么资源？

首先就是人员的问题。测试工作需要多少人？都有什么角色？这些角色的责任是什么？什么人负责分配的工作？出了什么样的问题应该找谁……

这里建议还要考虑互相之间的交流方法：只有几个人，在一间大房子里通过口头的方式就能有效交流；测试人员太多的时候，就要考虑使用一些工具来方便联系。

另外就是测试配置环境的问题。需要使用的软件在哪里可以下载？测试工具放在哪里？需要的硬件怎么解决？文档在哪里？以及上面的问题应该找谁联系……这些都要考虑到。如果某些资源要依赖于其他团队，则也应当把这些团队的责任和任务进行明确。

 

5.有哪些术语或名词需要定义？

这里也是很关键的一个地方。当项目中的一些概念模糊不清，大家都有各自的理解却没有有效交流过的时候，可能对工作的开展带来一系列影响。

 

6.哪些需要测试，哪些不需要测试？

这里如果可能，应当尽量说明需要测试和不需要测试的理由。通常我的做法是需要测试的部分作为测试需求，不需要测试的部分作为测试风险。

 

7.怎样定义测试阶段？

在计划测试过程中，应当明确每一个测试阶段的具体含义、工作内容和最终交付的工件。对于定义测试阶段，我以为更多的是为了形成测试工作的连贯性，帮助你更好的准确衡量测试工作量。

与此相关的概念是进入、退出规则。每一个定义的阶段都应该有明确的进入规则和退出规则。缺少了这两个规则，你将有可能会发现，原来定义的阶段失去了意义，测试工作不再连贯，而是变成了很多毫无关系的单个工作；测试工作变得遥遥无期，谁也说不明白到底到什么时候可以结束。

 

8.如何定义测试策略？

这是计划测试过程中最重要的部分，建议不要由测试新手来完成。

定义系统测试阶段的测试策略，考虑的问题有下面几个：

a.准备涉及哪些测试类型？

不同的软件涉及到的测试类型可能会有差别。对于这些具体内容的选择，建议可以参考RUP中的内容。

b.不同的测试类型是否准备使用不同的测试方法和技术？这些方法和技术准备在什么时候采用，如何采用？

比如是否准备使用黑盒测试？是否需要考虑白盒测试？是否需要使用测试工具？哪些采用手工测试？哪些采用自动化测试？……。

c.哪些因素可能对你的测试策略产生影响？是否会导致策略的改变或者影响策略的实施？

 

9.测试进度如何制定？

测试工作同其他团队（比如开发部门）的工作是紧密相关、相互依赖的。建议大家在制定进度前一定要明确哪些因素会对你的进度起到消极作用，哪些因素会起到积极作用，哪些因素应该作为必要条件，这些因素发生变化会产生什么影响。在确定进度开始时间和结束时间时，使用相对日期而不是绝对日期。

 

10.是否需要明确测试风险？

在实际工作中，测试工作会受到很多因素的影响和限制，有些时候甚至会限制测试工作的完成。测试人员一定要明确的指出计划中存在的测试风险，并同其他团队讨论，取得一致的意见，测试人员应该尽早提出测试风险，以避免在项目后期发现存在风险问题而引起恐慌。

 

最后，还要说一下，在实际测试工作中，可以整个项目制定一个测试计划；可以不同的测试阶段制定不同的测试计划；可以不同的测试类型制定不同的测试计划；也可以不同的功能模块制定一个测试计划。

工作方法的选择，关键是要有效，对实际的工作可以产生有益的影响。

 

再次提醒大家两点：

1.重要的是计划过程，而不是产生的文档。

2.在工作过程中，如果无法按照自己预定的进度完成，不要害怕或者沮丧。进度的作用就像一把尺子，你在工作中不断的用这把尺子来衡量自己――哪些地方需要调整，哪些任务需要多少时间。慢慢地，在制定进度和执行进度的过程中，你就会越来越容易把握自己的工作，就算出现突发事件，你也可以有足够的能力来处理它。

 

 

 

后续

这篇文章写于2003年，如今一年多过去了，在工作中又学到了很多新的东西，写作水平也得到了提高，并且很荣幸的在2004年的《程序员》杂志中开启了“软件测试专栏”，把几年来的工作经验化成“软件测试实践”系列共三篇文章发表其中。

思想，只有在分享和交流中才能真正获得成长，欢迎大家给我email，一起交流软件测试相关的话题，共同进步，共同成长。

 

 

作者简介：（黑体三号。一般单起一页，各种信息都是可选的，完全尊重个人意见）

 

	姓名：陈雷， 网名：jackei（宋体5号和Times New Roman五号，以下均如此）
	软件测试工程师，软件测试和软件过程改进实践的积极推动者。坚信“实践是检验真理的唯一标准”，而“‘创新’永远比‘记忆’更重要”，愿做软件测试实践的先行者。
这里是详细信息。 个人教育和成长经历：2001年从某医学院毕业，踏上了“IT不归路”，期间从事过一年多的开发工作和两年多的测试工作，如今致力于软件测试和软件过程改进工作的创新和实践。 擅长的技术领域：软件测试/过程改进/软件工程方法论的研究 目前的工作动态：目前于广州某通信公司担任软件测试工程师一职 个人主页：http://blog.csdn.net/jackei/ 个人Blog：http://www.cnblogs.com/jackei/ MSN：jackei_chan@hotmail.com E-mail：jackeichan@gmail.com   个人作品展示，包括 书评: 《推荐几本软件测试方面的经典书籍 》 原创文档：请参见我的Blog