这是以前的一篇老贴，发到这边来请大家一起讨论。 最近看到论坛上有些讨论测试计划的制定和测试策略的帖子，也有些朋友在MSN上问到一些关于如何制定测试计划和怎么来确定计划需要的时间的问题，愚以为现在很多测试人员对于一些基础的工作还是不是非常熟悉，故撰此文，希望可以对大家有所帮助。 测试人员的目标是尽早的找出缺陷，并确保其被真正的解决。而好的测试计划可以更好的帮助测试人员把握自己的工作情况。 首先明确一个经常看到一些测试人员理解错误的概念——测试计划。 这里的测试计划，计划是作为动词而不是名词使用的，或者应该叫做“计划测试”更恰当一些，重点在于对整个测试项目工作的计划，而“测试计划”只是用来记录最终结果的那份文档而已。再说得明确一点，是“计划测试工作”，而不是“编制测试计划”。也曾经见过一些负责制定测试计划的人，通过各种渠道找到一份测试计划的模板或者范例，花上几个小时甚至更短的时间复制、剪切、粘贴，以极高的效率完成了一份“测试计划”，并以此沾沾自喜。啊，boss可曾想到，这样的人对于他的公司是灾难性的啊。 计划测试通常是开始测试工作的第一个任务，一般来说应该由团队中具有丰富测试经验的工程师或者测试经理、主管来完成，不建议测试新手接手这件事情——因为这就好像女人研究哲学，既是哲学的不幸，也是女人的不幸——不同的角色还是要安心做好本职工作。不过新手可以帮忙整理一些计划测试所需要的资料，也可以从中知道计划测试工作都需要那些信息，为以后从全局的角度看待测试问题打好基础。另外，测试新手还可以通过帮助整理资料来学着制定自己的测试任务和计划自己的工作，也是不错的锻炼呢！ 不知道会不会有人看了上面的内容会说：说了这么多废话，到底测试计划是干什么用的！？ 计划测试的最终目的是为了交流。 hi，是不是和你们想的很不一样，有没有人认为计划测试是为了方便安排自己的工作？ 嗯，也可以有这个作用。不过在实际的开发过程中，是多个团队相互协调来完成工作的，测试工作作为这个过程中的一环，也不会例外。在计划测试的过程中，测试人员要明确的规定测试活动的范围、方法、资源和进度，明确正在测试的项目、要测试的特性、每个任务的负责人，还有与测试相关的风险。这些内容的定义是为了测试团队的意图、期望以及对将要执行的任务的理解，最终将同开发部（或者再加上客户支持部等相关的部门）交流，并最终确定下来。 这是我的第一篇“长篇大论”，看到这里，如果你有兴趣，可以花些时间来研究一下下面的内容，如果你已经非常熟悉下面的问题，那么我对于一些实际工作提出的经验或许也会对你有所帮助。 近日在“测试时代论坛”上看到seanhe 朋友的一个帖子，其中列出了一个非常完整的测试计划的内容列表，可以说涉及到测试工作需要考虑的方方面面，非常的全面，不过却没有对这些项目作出具体解释。而我更倾向于使用一个问题列表的方式来进行工作——这还是从《Database Design》一书中学到的工作方法，此书的原作者为Ryan K.Stephens ，中文版由机械工业出版社2001年出版，建议即使对数据库方面没有兴趣的朋友也可以参考其中的一些工作方法和思路，关于此书中文版的相关信息请参见下面的网址http://www.china-pub.com/computers/common/info.asp?id=3435。 下面是我在制定测试计划是考虑的一些问题和一些其他经验。当然，因为计划本身应该是一个动态的过程，所以当发现下面的问题不适用于具体的工作时，可以增加、减少或者别的调整。但是有一点，最终确定下的问题列表应当在项目组中进行讨论，不同的部门间相互沟通，最终达成一致。另外，限于本人的工作经验，不能保证这些问题一定适用于所有的项目，而只是包括了一些常见的需要考虑的问题，很多具体的工作问题，大家还是要“一切从实际出发”，自己多研究，多思考。 1.计划测试过程的目的是什么？ 我一向推崇的做事方法是先明确自己到底要什么，然后明确自己为了这个目标要做什么，之后才会明确该怎么做。对于计划测试一样适用。如果你无法找到计划测试的理由，那么就不要在这上面费太大力气了。 对于这个问题，我的观点已经在上面描述过——为了交流。为了更好的开展工作，需要开发部、客户支持部、市场部、管理层知道你要做什么，并且你还需要更多的争取他们的认可和支持。 2.你所要进行测试的产品和版本是什么？ 可能很多朋友会说：我们的项目管理现在很混乱，在整个测试过程中会不断的有新的版本出来，测试工作太被动了。 oh，如果真的是这样，那么就考虑引入完善的版本管理方法吧。因为一直从事一些大型项目的测试，对于版本的迭代，并且是无序的迭代，我已经吃尽了苦头。如果无法把测试人员和开发人员的注意力集中到某个版本上，那么工作的情绪和信心会逐渐跌落。 3.产品的质量目标是什么？ 可能在一个项目中，boss、市场部、客户支持部同开发人员、测试人员对于质量的认识都不相同，那么就有可能会出现争论。不过不管怎么说，必须要有一个明确的质量要求，既然大家都有自己的要求，那么就为自己的要求提出一个准确的定义：要求响应速度的，就要明确是每秒响应多少业务，还是什么别的；要求稳定的，就要明确运行N小时不死机还是在某种环境下可以正常工作；又或者要求系统在使用时不能出现某个级别的bug？ 最终，必须使测试目标明确并一致通过，以免无法确定测试结束和程序发布的时间。 4.需要那些资源？ 首先就是人员的问题。测试工作需要多少人？都有那些角色？这些角色的责任是什么？哪些人负责哪些工作？出了什么样的问题应该找谁？这里建议还要考虑互相之间的交流方法，如果只有几个人可能在一间大房子里可以通过口头的方式有效交流，但是有些时候测试人员太多，涉及的范围比较广的时候就要考虑使用一些工具来方便联系。 需要使用的软件在哪里可以下载，测试工具放在哪里？需要的硬件怎么解决？文档在哪里？以及上面的问题应该找谁联系，都要考虑到。如果某些资源要依赖于其他团队，则也应当把这些团队的责任和任务明确一下。 5.有那些术语或名词需要定义的？ 这里也是很关键的一个地方，当项目中的一些概念模糊不清并且大家都有各自的理解却相互间从来没有好好交流过这些不同理解的时候，就可能对工作的开展带来一些影响。最常见的问题就是你要东他却给你西^_^ 6.哪些需要测试？哪些不需要测试？ 这里如果可能，应当尽量说明需要测试和不需要测试的理由。通常我的做法是需要测试的部分作为测试需求，不需要测试的部分作为测试风险。 7.怎样定义测试阶段？ 在计划测试过程中，应当明确每一个测试阶段的具体含义、工作内容和最终交付的工件。对于定义测试阶段，愚以为更多的是为了形成测试工作的连贯性，并可以帮助你更好的准确的衡量测试工作量。 与此相关的两个概念是进入、退出规则。每一个明确定义的阶段都应该有一个明确的进入规则和退出规则，绝对的来说明进入一个阶段的的规则，和当前阶段工作结束，进入下一个阶段的规则。如果缺少了这两个规则，你将有可能会发现，原来定义的阶段失去了意义，测试工作不再连贯，而是变成了很多很多毫无关系的单个工作，测试工作变得遥遥无期，谁也说不明白到底到什么时候可以结束。 8.如何定义测试策略？ 这可是计划测试过程中最最最重头的部分，绝对不希望由测试新手来完成。 通常我是负责定义系统测试阶段的测试策略。考虑的问题有下面几个： a.准备涉及那些测试类型？ 不同的软件涉及到的测试类型可能会有差别。对于这些具体内容的选择，建议可以参考RUP中的内容。 b.不同的测试类型是否准备使用不同的测试方法和技术？这些方法和技术准备在什么时候采用？如何采用 比如是否准备使用黑盒子测试？是否需要考虑白盒子测试？是否要考虑使用测试工具？那些采用手工测试？那些采用自动化测试？等等。 c.有那些因素将可能对你的测试策略产生影响？是否会导致策略的改变或者影响策略的实施？ 9.测试进度如何制定？ 嘿嘿，在这个问题上，我可栽过跟头。一定要明白一点，测试工作同其他团队——比如开发部——的工作是紧密相关的，是相互依赖的。当初我就因为对这个问题认识不足，太理想化，结果制定的进度无法完成，拖了又拖——当然这里就不追究是谁的责任了。 建议大家在制定进度前一定要明确那些因素会对你的进度起到消极影响，那些因素会起到积极影响，如果这些因素发生变化会产生什么影响。对于那些作为必要条件的因素，要考虑到进度中来，在确定进度开始和结束日期时，使用相对日期而不是绝对日期。比如XXX工作开始于XXX部门XXXX工作的结束并提交XXXX东东，预计用多久完成当前任务。 10.是否需要明确测试风险？ 在实际工作中，测试工作会受到很多因素的影响和限制，有些时候甚至会限制测试工作的完成，比如期限。我曾经在51CMM上开过一个“关于时间受限的测试项目”的帖子，讨论的结果是这种情况下只能抓重点业务，最基本的质量要求，其他的部分，作为风险处理。 关于这个问题，是测试人员很大的一个责任，一定要明确的指出计划中存在的测试粉线，并同其他团队讨论，取得一致的意见。一定要尽早提出，以避免在项目后期发现存在风险问题而引起的恐慌。 最后，还要说一下，在实际测试工作中，可以整个项目制定一个测试计划，也可以不同的测试阶段制定不同的测试计划，也可以不同的测试类型制定不同的测试计划，也可以不同的功能模块制定一个测试计划。工作方法的选择，关键是要有效，对实际的工作可以产生有益的影响。 注意： 最后再次提醒大家两点： 1.重要的是计划过程，而不是产生的文档。 2.在工作过程中，如果无法按照自己预定的进度完成，也不要害怕或者沮丧，进度的作用就像一把尺子，而不是鞭子。你在工作中不断的用这把尺子来衡量自己，那些地方需要调整，那些任务到底需要多少时间，慢慢的，在制定进度和执行进度的过程中，你就会越来越容易把握自己的工作，就算出现突发事件，你也可以有足够的能力来处理它。 |
 【郑重声明】 本人依法保留对本文的所有权利，未经本人允许，任何人不得擅自将本文中内容用做任何盈利性的用途。为尊重作者的劳动成果，如需转载或引用，请注明文章出处及作者。 moc.liamtoh@nahc_iekcaj |
