(一)——万事开头难
测试计划应该是整个测试流程中第一份测试文档了，但是一般情况下去不是测试人员学习的第一站。或许是因为万事开头难的缘故，测试计划确实挺让人纠结了。
很多有了一定的经验的测试人员在教新人的时候第一步都不是按照测试流程先从测试计划开始，而是让从测试用例的执行开始——这虽是无奈之举，但是对于测试新手来讲，还是可以学习很多东西的。闲话扯得有点远，回到我要介绍的正题上面来，计划测试。
对， 是计划测试，不是测试计划。尽管我们刚才讨论了一些关于测试计划的内容。但是我们需要关心的的确是计划测试，而不是测试计划。永远要记住，我们是在做测 试，而不是在完成文档，尽管我们经常需要诸如测试计划测试用例测试报告之类的各种各样的文档，但是那些都不是测试的本质。
既然是计划测试，那么我们首先要搞明白测试到底要干什么。笔者将它抽象概括为：特定的人在特定的时间在特定的地方做了特定的事情以实现特定的目标。其实任何一项工作都可以抽象成前面这句话，所以我们还需要将这句话与我们所从事的测试工作联系起来。
所谓人，当然是指测试人员了，而“特定的人”则坚持的是“按能力分工”各司其职的原则。测试用例设计人员做测试设计，测试用例执行人员做执行用例等等。
所谓“特定的时间”，是指我们的测试过程是分成各种阶段的，各种阶段所侧重的测试要点是不一样的。
所谓“特定的地方”则是指测试环境，这是指我们必须在计划我们的测试工作的时候就要考虑到某些特殊类型的测试是需要特殊的环境的，这个环境包括了硬件设施(如手机测试你总得拿个手机来试试吧，总不能一直纸上谈兵来着)环境，计算机硬件环境和软件环境。
所谓“特定的事情”即是指我们测试技术本身了，也就是诸如测试用例设计，测试用例执行，写测试代码，部署测试环境等等。
所 谓“特定的目标”即是指我们测试的目的。测试是需要成本的，人力物力都是需要的，既然我们对测试有投入那么我们是期望获得一些东西的。测试最常喊的口号是 改善质量水平，也有一些还在喊保证质量的，这就是我们所谓“目标”。不过，可惜的是这些口号并没有多大的用处，因为在实际的软件项目中我们更加看重的则是 可度量的测试工作，也就是说我们要由一个可度量的“目标”——亦即“特定的目标”——可能是发现了多少bug可能是测试覆盖率达到了多少等等。
我 们在计划测试的时候，需要考虑的不仅仅是测试本身，从上面的分析可以看出，我们要关注“人、时、地、事、责”，也就是古代中华所讲究的“天时地利人和”之 类的东西。需要指出的是，在我们计划测试的过程中，最常被人忽略的就是我们测试应该达到什么目标这个问题了。在计划测试的时候，切记要约定好测试的目标， 这一目标反映在测试计划文档中即“测试结束标准”。
关于计划测试的内容有很多，在接下来的文章中，笔者将逐一展开与大家分享。
(二)——测试计划
在前一篇文章中，我们提到了计划测试要考虑到人、事、时等诸多问题，也提到了计划测试重在计划这个过程而不在测试计划这个文档。
这 篇文章却要专门讨论一些测试计划相关的话题。网络上现在已经泛滥了关于测试计划的模板——用泛滥只是表示很多，并没有贬损的意思，笔者才疏一时想不到好的 词语——这些模板对于制作一份测试计划文档来讲非常有用，但是生搬硬套这些文档却并不能帮助我们很好的计划我们的测试工作，但是这些测试计划中的主题却可 以很好地帮助我们计划我们的测试工作并有效避免疏漏。
我并不会给出一份我所常用的测试计划模板，因为这些模板实在已经太多，已经够用了。笔 者在测试工作中，曾经写出两种测试计划，一种类似于当前网络上流传的版本，另外一种则是在笔者的某篇blog文章中提到的所谓“实用主义测试计划”——事 实上是更接近测试设计书的一个文档，但是确实有些公司把它称之为测试计划，而在本系列文章中笔者将不再讨论这种测试计划，也不会考虑细到“怎样设计某个功 能的测试用例”的程度的计划工作。#p#分页标题#e#
本文前面提到，网络上流传的测试计划有很多，但是雷同的也多，往往有些测试人员随便 到网络上找几个测试计划的模板，然后东拼西凑便可以作出一份像模像样的测试计划出来。笔者结合自己的经验以及一些相关资料(当然包括网络上流传的诸多测试 计划模板)，列出了测试计划中有关计划的相关主题：
测试结束标准
一些相关约定，部分模板中添加入“术语”一栏
测试工作中产生的文档及定义(测试用例文档，缺陷报告文档等)
测试工作个团队之前的协调工作，主要包括开发组需要对测试组提供的相关帮助
测试的范围
测试的时间安排(时间进度表)
测试的策略
测试过程中的资源要求
测试人员的任务分派
测试中可能遇到的风险等问题
测试工作的度量和统计
测试工具相关的计划
等等。
以 上这些主题都是常见且有助于我们做好计划工作的内容，至于测试费用等的计划，笔者认为适当估计但不要过分追求，因为在实际的操作过程中，测试工作延期、测 试工具购置、人员流动造成的培训费用等会打乱这个计划，并且在测试计划中列出的费用是不会跟财务直接挂钩的，具体费用还得依照公司专用流程，因此“测试费 用”这类主题在笔者计划测试的过程中不会考虑太多。
PS：2009-3-9更新：
测试计划有三重境界：
第一重：什么都有用
第二重：什么都没用
第三重：仅部分有用
第四重：什么都有用
第五重：什么都没用
(三)——人
在本系列文章中的第一篇，笔者就提到了计划的实质是“特定的人在特定的时间在特定的地方做了特定的事情以实现特定的目标”,在上一篇文章的回复中，土豆老粗回复了对于测试计划的看法，也就是5W1H定义：
< WHY：为什么要写测试计划;
< WHAT：测试什么;
< WHEN：测试不同阶段的起止时间;
< WHERE：文档放哪;
< WHO：哪些人去做;
< HOW：怎么测试;
这 个定义相对于我的来说，对于测试计划定义得更加详细。不过，正像笔者在博客签名中所宣称的那样：来自草根的实用主义。因此，5w1h定义就不适合三五个人 十来杆抢的软件作坊了。对于很多刚刚起步测试活动(近两年才拥有“专门测试人员”，注意是“专门”而不一定是“专业”)的公司来讲——而这种公司，就笔者 接触的一些同仁口中所述，在中国还不在少数——或许一些简化版的东西会更适合现在的他们，等到渐渐成长起来，我们才逐渐步入正轨。本文中笔者继续自己的草 根实用主义，分享自己的关于计划测试活动中人的一些拙见。
这阵子软件相关论坛上都多多少少有人提到了工具与人的关系，在笔者看来这是一个很扯淡的问题，人的作用是不可能被工具取代的，人之所以为人而不是跟其他动物一样处于原始的生存状态，是因为人会“使用”工具。不过关于人和工具的那点儿事，则是后话了。
中 国有句老话“养兵千日，用在一时”。这句话往往是在临战的时候将军(测试负责人)对战士(普通测试人员)说的。中国古代还有一个方法叫做“战时兵闲时农” 的策略，即我们广大的劳动人民在没有战争的时候安心种我们的地，一旦战争爆发或者国家需要的时候我们就披上盔甲去作战。这两句话给我们一个提示：我们应该 培养我们的测试人员或者说我们的测试队伍。
先拿“养兵千日用在一时”来讲，正如我上面提到的，往往在临战的时候大家才想起这句话，可是我们 不妨倒过来想一想，一时的用是需要千日的积累的。这也是在提示我们，一支优秀的测试队伍的每个人都应该是优秀的并且我们需要在“用一时”之前好好“养千 日”。这种积累不是一天两天可以形成的，正所谓冰冻三尺非一日之寒。为什么要在谈论计划测试的时候谈论这个问题呢?原因在于“巧妇难为无米之炊”，我们在 做计划的时候如果发现没有一个可用之才，那我们的计划怕是做不下去了，或者我们只有准备另外招新人到行伍中间来，亦或者只能外包测试给专业队伍，这无疑又 增加了项目的风险，因为新人或者其他队伍使我们不了解的，他们会做成什么样子只有老天知道，当我们把命运交给老天的时候，这相当于在玩火。我们需要把“养 千日兵”拉到我们的计划中来，从更加长远的角度来计划一下我们的测试工作，测试方向等等。对于人才的培养，一般使用的是人尽其才的分工制度，即某一个或者 一些人熟练掌握某一些测试技能，并对其他技能有所了解，最理想的情况下，我们在测试的方向(或者说是本公司主要的开发方向相关联的各个测试技术方面)都有 “专家”，这样才可以保证一个测试队伍可以应付不可预知的测试任务。#p#分页标题#e#
对于草根一族来讲，一开始公司很可能就你一个测试人员，有几种情况：
< 公司将“建立一支专业的软件(测试)队伍”的艰巨任务寄托在你身上时，先不要沾沾自喜袭击已经被boss重视了;
< 公司只是拿你来标榜自己拥有了测试，拿你来写测试计划，测试报告等提交给客户看的文档的专业测试——文档——人员
上 面两种是比较常见的情况，在笔者看来，这两种情况都很好创造了给你学习的机会，第一种情况你可以打着公司的“建立一支专业的软件(测试)队伍”旗号学习; 第二种情况来讲，如果仅仅是写文档的话，那剩余的时间就可以好好利用下来了，而目的在于你想提高自己的技能。而我们的学习方向，笔者大概归纳一下：
< 测试理论(包括测试基本概念，流程，管理等等内容。对于测试来讲，这才是基本)
< 测试文档 (虽然网络上的文档中的内容对于目前的你来说不可能完全有用，但是知道一份专业或者说完整的文档是怎么写的也是必要的)
< 测试工具(对于刚起步的测试人员，如果你不是开发大牛，建议你还是先使用别人已经写好的工具)
< 开发知识 (有则加之，无则添之，总是是要学，因为这一点是为将来打算，这些知识有助于我们更好地测试)
笔 者在文章开头提到了人与工具的问题。现在各种各样的测试工具很多，有关于性能的测试工具，有关于功能自动化的测试工具等等。不过昨天看到一篇博文，博文作 者深感当前几乎所有人讨论的问题都是测试工具怎么用，而关于测试工具开发相关的帖子却很少，笔者也认为这是一个不正常的现象。的确，对于大多数软件项目组 来讲，自己开发一个性能测试工具并不是一个现实的想法，又鉴于性能测试的重要性，在测试组中拥有掌握主流性能测试工具的专家是很迫切的需求。如果可以的 话，我们拥有自动化测试工具的专家，我们拥有自动化测试工具自主开发的专家等等这些都是很有用的。不过这些专家的培养的顺序也要顺势而行，不仅急不得而且 也急不了。
当一个优秀的测试团队成立起来之后，“米”的问题就解决了，这个时候再来针对某一个具体的项目考虑怎样“炊”的问题就简单很多 了。简单，并不代表可以不费吹灰之力就可以把事情摆平了。要知道，人是一个复杂的动物，人的心情会有阴晴圆缺，人会有喜怒哀乐，关于这些跟技术不搭调的问 题笔者就不扯了，毕竟笔者的人生阅历还没有精彩到可以教读者怎么做人的地步~关于计划测试中人有关的话题，在本系列的后续文章中会结合“特定的事”“特定 的时间”等等继续探讨。
(四)——地
正所谓，天时地利人和，前面的一片里面笔者花费了大堆口水在“用兵一时，养兵千日”的怎么“养兵”和“兵”自己怎么实现自我修行。 人有了，该是考虑“地利”的问题了。所谓地利，即指软件的测试环境，这与开发环境有着很大的不同，同时也保持了一定的联系(废话)。
测试不会凭空出现，正是因为之前有过太多的教训，人们开始对质量重视起来。从这个意义上来讲，相关组织是为了避免损失而测试，而减少支出其实是赚了钱，所以他们进行测试是为了获取利润的。从另外一个方面来看，测试也要投资，而测试环境则在这些支出中免不了分一杯“羹”。
先看一个笔者赶制的一个草图
对于上面的图，简单说明一下，或者“按图索骥”吧。 在我们计划测试的过程中，我们使用由顶向下的分析策略。
所谓测试环境(我们这里指的是物理意义上的环境)，对于软件测试来讲“咔嚓”一声分成两半：硬件环境和软件环境。
把硬件环境拿出来讲，包括了测试项目依赖的硬件环境，测试工作本身依赖的硬件环境。
所 谓测试项目依赖的硬件环境，举例来讲我们测试一个手机操作系统，总得要拿出个手机来试一试吧;如果拖拉机也需要软件配备，那么一台拖拉机也是需要的，另外 还需要弄一个库房或者至少一个空地来放这个拖拉机;所谓测试工作本身依赖的硬件环境，至少得一台测试用的机器吧，对于特殊要求，比如开发一个嵌入式程序用 来监控室内二氧化碳的浓度，这个时候一个特殊的工作室可能也是必要的，至少有一个工具可以改变二氧化碳浓度，有个地方可以困住这些二氧化碳吧。关于机器， 我们还需要考虑到机器的配置等等问题。#p#分页标题#e#
接着就是软件环境了，跟硬件环境一样，包括了测试项目依赖的软件和测试工作本身依赖的软件，当然最重要的是要有个操作系统，还要搭上待测的应用程序。
关 于待测应用程序就不讲了，想想如果没有待测程序那我们还测什么啊，是不?测试项目依赖的软件，这里面的弯弯绕就显得多了一点了。首先，待测程序引用或者操 作的一些应用程序得准备齐整，比如说某应用程序用于监测某个人每天打开了多少次Outlook并收发了多少邮件，如果机器上没有装上outlook的那我 们就只能测试没有outlook下该应用程序的的表现这一种情况了，虽然这也是一个很重要的用例，但是更多的有用的用例还是需要我们配备上 outlook来测测的。其次待测程序运行的平台，.NET开发的你总得安装上相应的.NET Framework吧，web应用程序没个浏览器也是不行的。
测试工作本身依赖的软件，说明白点主要就是测试工具了，这里面的弯弯绕太多，笔者就不绕进去了。
操作系统，对于基于windows操作系统的软件，我们就需要考虑到微软这些年来给我们贡献的这么多版本，如果考虑到其他操作系统，我们就不得不考虑到苹果等等的贡献了。
总 结一下，对于测试人员来讲，在项目里面不需要考虑到所有的部分(图的叶子部分)，但非叶子节点部分还是得好好琢磨琢磨。对于开发人员来讲，比较常出现的一 个情况是软件工作的环境问题：应用Team Foundation管理团队项目的时候，项目开发人员A引用了外部DLL(假设为C.DLL)，当签入源代码的时候这个DLL是不被签入到TFS上的， 这就会导致服务器上的版本编译不通过，提示无法找到DLL之类的错误信息。这是一个常见的环境错误。另外，如果项目组成员使用的开发环境不一致，也可能导 致应用程序集成失败或者BVT运行不通过;如果开发团队开发环境一致，那么在对应用程序有兼容性要求的时候，相关的系统兼容性测试是必需的。
(五)——时
到 了“时”了，这是计划测试过程中最让人纠结的地方了。计划本来就是一件很麻烦的事情，关键点就在于计划的时候很难拿捏准时间的长度。在一本称之为《软件工 程中的事实与谬误》的书籍中，作者提到一条软件项目走向失败的两大因素中的一条就是估算不准，由此可见计划之难了。Aaron现在对于时间计划搞得也是没 模没样。
初一的时候计划在十五月圆之夜一起赏月对饮，可是天有不测风云，到了十五那天天气转阴了，月亮连个影子都没有更不要提月圆了。在项 目中也会经常遇到这种情况，我们预计某年某月某日我们实现某项功能，可是等真的到了那一天，才发现原来我们想象中的那项功能依然只能存在与想象之中了。
那我们怎么做时间计划呢? 在Aaron看来，因项目性质而异，要知道我们从事的项目大致可以分为两种：产品性质的和外包性质的。这两种性质的项目对于时间的要求，对于测试强度的要求是大不一样的。
对 于一般外包项目来讲，对于测试要求相对较低，而时间是固定的。当前大多数标榜使用螺旋开发的团队其实只是变相的甚至是变质的瀑布模型，对于测试的现状更是 如此。测试先行，测试与项目同时启动在大多数项目中都只是一句口号而已，因为大家心里都明白，口号是不要钱的，所以空喊口号这种最廉价的朝脸上贴金的方式 广受软件作坊主们的欢迎甚至推崇。废话不扯了，对于这种项目的测试工作来讲，一般是标准的段段式的，即计划测试，测试用例设计，测试用例执行及bug管 理，测试报告提交等等阶段。这就好弄多了，根据经验(如果一点经验都没有，那还有直觉)我们把这几个阶段换算成比例，然后把测试总时间瓜分了，需要提醒大 家的就是记得在瓜分之后留点“缓冲时间”来，否则到时候出了点意外就麻烦了，记住是在每段时间之后加上一个缓冲期，而不是最后加上一次。
对 于产品来讲，测试要求会比较高，时间当然也是需要考虑的，套用IT界最常被引用的一句话，“在这个瞬息万变的时代”，把握时机对于一个产品来讲无疑是很重 要的。不过，由于众公司都不愿意自己的产品一出生生了满身毒疮——bug。轻则产品销量受损，重则产夭折，甚至严重影响公司形象乃至导致公司运转等严重问 题。这个时候我们还是先将测试分段，对于这种项目，我们首先站在测试质量的角度，实事求是按照功能点数目、难度，测试经验等来估计测试时间，然后将总时间 加起来，如果时间充裕，我们考虑加入更多测试面，如果时间紧迫，我们考虑是否删除部分非核心功能，以降低开发和测试的时间成本，从而为测试质量保驾护 航。#p#分页标题#e#
回到上面的“月圆之夜”的故事片段上来，这个片段提醒了我们在时间计划的时候还有一些问题需要注意。上面提到计划 失败是因为“月圆”这个外界因素没有达到要求，这就提醒我们在计划的过程中，应当尽量减少对于外界的依赖，如果依赖是必需的，那么对于依赖可能导致的意外 我们要多出几套应急方案。另外，在项目执行过程中，及时检查项目进度也是必要的，这可以避免我们跑在错误的道路上，那样只会越错越远，这部分不属于计划测 试的范畴，因此不做考虑了，如果有兴趣可以看一下持续集成相关的资料。
(六)——事
本计划的上一篇《计划测试系列(五)——时》，是Aaron的软肋，写得很糟糕，但为了保持完整性，Aaron还是贴出来了，看着寥寥几人的访问量，Aaron觉得应该加油写出更好的东西出来。废话少说，开始念叨计划测试系列中关于事的部分。
测 试是做什么事的呢?测试是为了……赶紧打住，Aaron指的“事” 是一个测试项目过程中所做的具体的事，不是拿着《软件测试》或者其他的经典来念句子的。按照Aaron自己在上一篇中的理解，软件项目流程或者说一个迭代 必定要经过计划实施总结这几个阶段。对于测试来讲我们可以将各个阶段再细分，然后就成了下面这个样子：
制定测试计划
至于计划 的作用就不再赘述了，而测试计划作为计划测试活动的结晶，理应受到重视。在实际项目中Aaron发现自己写出来的测试计划这个文档本身意义并不大，至少没 有计划测试的过程那般有意义。在很多软件作坊之中，测试计划自一出生便被打入冷宫，测试计划的意义仅仅是作坊主朝自己脸上贴金而使用的一种手段。 Aaron推荐的方法是完成一个交差的测试计划后，维护一个名为测试计划实质上更像测试设计(Test Design Spec)的文档，在整个测试执行过程中该文档都起着提纲的作用，而且任何读者都可以通过这份Test Design Spec中了解Aaron对项目测试的想法和测试思路。Aaron在自己所处的项目组中争取到了Test Design Spec的Review机会。Aaron是这样告诉他们的：Aaron担心自己理解错误了PM的意思，Aaron担心自己想的跟Dev不一样，Aaron 想先把事情说清楚，所以Aaron要Review。
关于测试计划的内容Aaron在本系列文章的第二篇也聊过——《计划测试系列(二)——测试计划 》。
测试软件需求
软 件需求是测试应该覆盖到的地方，这也是为什么很多软件方法提倡测试尽早介入到软件开发进程中的原因之一。对于PM提供的那份Feature列表或者 Feature Spec，我们应该抱着怀疑的态度，PM不是项目对象领域的专家，他会犯错，他也会马虎，他也会有脑袋短路的时候，所以这个时侯需要包括测试人员在内的很 多项目成员来一起检查这个list或者spec，称之为Review。对于测试人员及其他参与Review的人员应该实现阅读文档并了解项目相关领域的知 识。Aaron刚才提到的Test Design Spec的Review工作比较好地完成了任务，当然限于相关业务知识和经验，Test Design Spec的质量会有高有低，Reivew的效果也就可能很不一样。Aaron建议先不断锤炼自己的Test Design Spec之后再提交Review，Aaron自己一般要到V1.3版本才敢拿出去跟PM和Dev“分享”。
测试用例设计
有关测试用例设计的方法，诸如等价类划分，边界值分析，甚至需求矩阵方法等等，Aaron在这里就不在闲聊，这些东西网络上已有的文档要比Aaron讲的专业的多，更何况这些内容也不是本文的目的所在。
执行测试
主 要是指测试用例的执行，但是还应该包括测试用例的更新，还包括bug的提交和管理等等内容。Aaron在周期稍长的迭代中还会每周发一个Weekly Test Report给项目组成员，帮助他们了解一周来测试工作的进展(以测试用例的数量趋势，分布)，还会报告当前的bug相关的信息(Bug总数，趋势，严重 bug分布，区域分布等)，这些对于帮助项目顺利进行很有帮助。
报告测试结果
Aaron在周期稍长的迭代中会每周发一个 Weekly Test Report给项目组成员，帮助他们了解一周来测试工作的进展(以测试用例的数量趋势，分布)，还会报告当前的bug相关的信息(Bug总数，趋势，严重 bug分布，区域分布等)，这些对于帮助项目顺利进行很有帮助。当然，在一个迭代结束或者项目结束之后我们也要提交一个测试报告，这是一份总结性的报 告。#p#分页标题#e#
安装测试
考虑软件所使用的各种硬软件环境等问题，不仅仅在计划的过程中体现到，还要检查部署文档或者产品说明书中是否包含了安装环境的定义和介绍。
自动化测试
自动化测试的范畴及涉及的内容很多，根据项目组的实际情况引入和实施自动化测试是软件测试发展的趋势。
性能测试
性能测试的范畴又包括了压力测试，负载测试，性能测试(狭义)，大容量测试等等，这些都要根据实际需求加以取舍和安排，并在计划中体现出来。
更新(软件变更)测试
主要指版本的升级测试，尤其对于产品性质的软件更应该注意这方面的问题。
测 试工作本身还包括了其他很多内容，Failover和Switchover测试等等很多内容都需要考虑，有时候还要对软件的逻辑关系，软件的物理关系进行 测试，还有更常见的界面测试，可用性测试，验收测试等。这些测试及测试程度的取舍则取决与项目实际情况(时间，成本等等)以及测试人员个人的经验等等。
(七)——我们什么时候停止?
我们什么时候停止我们的项目?我们应该在我们达到目标的时候停止。可是，目标是什么?Aaron认为所谓目标，即测试应该实现的可度量的要求，这个东西更常见的叫法——测试停止标准。
不 知道有没有程序员会笑话Aaron说：我们项目就是一个测试人员在点点，甚至不要测试人员点点我们也可以顺利交付给客户很有用的产品;不知道有没有测试人 员会讲：我们测试的时候除了用例之外什么都没有，更不用说什么无聊的测试停止标准 =! 不过Aaron告诉你，真要在项目里面有了这么个东西，只会对大家都好。你想，测试停止标准就是那可以止渴的“梅”，有了它咱就有了奋斗的方向，有了等到 出头之日的盼头。同时因为一些项目组中测试标准也会作为版本发布标准——尽管这两者还是有区别的——所以测试停止标准对于开发人员和PM也是有用的。
当然，并不是所有的测试停止标准都会有这般功效，在Aaron看来，一个合格的测试停止标准应该满足一下条件：
在计划阶段尽早订立测试停止标准
没有规矩不成方圆，先定下规矩可以帮助我们一开始就计划的时候就在画着“方圆”，而不是等画了一点点之后才发现用的“规矩”不是标准版的，那样浪费了时间。
测试停止标准应该获得项目负责人的确认
这一条尤其适用于并不是那么和谐的项目组以及习惯优柔寡断的项目负责人领导的项目组。还要注意口说无凭，所以立字为据有时候也是需要的~我们的目的是要使规矩“定”下来。
对于这一条，存在这两个风险：
一 是容易导致不和谐：如果项目负责人签了，感觉像是兄弟们在给他上枷锁似的，更像是把一些责任推到他的身上去了。(因为存在这样一种情况，大家订立一个规 矩，可是后来做的东西让top leader不满意，普通组员这个时候好歹还可以推说我们组的规矩是这样做的，不需要问，当时签字确认的项目负责人这下子责任就大了。)
二是因为需求变化，因为测试停止标准要求满足可度量性(具体内容在后文详谈)，所以可能会涉及到比较细致的东西，比如某个核心模块应该怎么样才算行——如果在后期需求变了，会不得不更改“定”下来的测试停止标准了。
对于这些风险的预防和处理，Aaron虽然有些心得，但是考虑到各个作坊情况不一样，Aaron就不误导各位了。
测试停止标准应该是可度量的
Aaron 看来，对于测试停止标准，“可度量”这个要求是必需的，用抽象的语言来描述测试停止标准是无意义的。如在测试停止标准里面出现“在适当的时间停止测试”这 句话是不对的，所谓“合适的时间”这类词汇，要么让人不解其意，要么出现“一千个观众眼中有一千个哈姆莱特”这种情况，因此一个准确的定义是必需的。
测试停止标准都是可以达到的
这 个很容易理解，如果标准里面出现了要我们三五个人十来杆抢在一个月内造一个跟windows Xp一模一样的操作系统给客户，那定这个标准的人怕是跟Aaron前天一样SB了~测试停止标准之中切忌出现不可能实现的或者很难达到的目标，比如在测试 停止标准里面出现“修复所有的bug”这种条文，我们就要考虑实际情况中我们是否可能修复所有的bug，项目的要求是否如此严格——所有的bug都必须修 复，而不是被处理(修复，延迟并报告等处理方式)，是否允许部分bug推迟修复?#p#分页标题#e#
测试停止标准的检查者
测 试停止标准作为一个验收标准，还需要明确规定标准执法者。没有规矩不成方圆，但是有了规矩而不执行，也是成不了“方圆”的，所以需要执法者或者说护法者， 在这里体现为检查和核实我们的测试是否达到了标准。有时候，为了表示民主，大家一起说了算在人数不多的项目组也是一个可取的方式。
Aaron讲了自己的一些理解，但看着过于抽象，所以就继续具体点讲一下。开发人员贴code，Aaron这边没Code，只好贴几张便签纸
测试标准应该包含的内容：
》有效测试用例（功能）执行率达到X%？
》单元测试代码行覆盖率达到X%？
》单元测试用例通过率X%？
》单元测试用例设计通过评审
》核心模块（A,;B,D等模块）测试覆盖
》所发现缺陷均纳入缺陷管理系统
》优先级最高的bug全部修复
》其他bug全部被处理（修复，延迟并报告等处理方式）
》功能测试用例模块，功能点覆盖率达到？ 按照测试类型来的测试停止标准：
比如单元测试活动在满足以下所有条件之后可停止：
》核心模块代码100％ 经过Code Review
》单元测试用例设计通过评审
》测试用例执行率100%
》最新版本的单元测试通过率为100%
》单元测试全局代码行覆盖率不低于80%
》单元测试单个模块代码行覆盖率不低于70%
》单元测试中被测单元发现的bug产生率不低于3个/千行代码
》所有发现缺陷都纳入缺陷追踪系统
》优先级1类bug全部被修复
》优先级2，3类bug全部被处理（修复或者不处理并明确在测试报告指出且获得通过）
》完成了单元测试报告并通过评审
…… 实际工作中会出现的停止“标准”
测试活动在满足下列条件之一时需要暂停或者终止：
》新的需求变更过大，测试活动应暂停，待需求定义稳定后继续；
》测试超过了预定时间，且测试时间不可能继续增加的情况下应停止测试；
》测试成本增高（Bug发现率低于1个/周，此时所发现缺陷低于预定义的上限）；
》若开发暂停，则相应测试也应暂停，并备份暂停点数据；
》软件系统通过验收测试；
》软件项目在其开发生命周期内出现重大估算和进度偏差，需暂停或终止时，测试应随之暂停或终止，并备份暂停或终止点数据；
》项目负责人申明停止项目；
》团队集体（开发，管理，测试，市场，销售人员）同意停止项目（因市场及利益等原因）；
……
上 面几张便签来自网络和个人实践，Aaron只是摘选部分，切不可直接拿来作模板，否则就是 Aaron的误人子弟的罪过了~这几张便签纸并不能直接帮助读者建立起一个适合自己项目的“测试停止标准”，因为Aaron相信大家的能力。Aaron将 测试停止标准扯到计划测试系列的目的，是要提醒读者在计划的时候就要有看到我们的结果的眼光。项目也好，测试过程也好，都是以结果为导向的，没有最后的成 功，中间过程即使很完美，对于项目(产品)自身是没有任何意义的(大多数情况下，项目成员在吞食失败的挫折感的同时，至少还收获了经验，所以可能还会有人 会享受失败项目中的“美好的过程”)。
