我们什么时候停止我们的项目？我们应该在我们达到目标的时候停止。可是，目标是什么？Aaron认为所谓目标，即测试应该实现的可度量的要求，这个东西更常见的叫法——测试停止标准。
不知道有没有程序员会笑话Aaron说：我们项目就是一个测试人员在点点，甚至不要测试人员点点我们也可以顺利交付给客户很有用的产品；不知道有没有测试人员会讲：我们测试的时候除了用例之外什么都没有，更不用说什么无聊的测试停止标准 =! 不过Aaron告诉你，真要在项目里面有了这么个东西，只会对大家都好。你想，测试停止标准就是那可以止渴的“梅”，有了它咱就有了奋斗的方向，有了等到出头之日的盼头。同时因为一些项目组中测试标准也会作为版本发布标准——尽管这两者还是有区别的——所以测试停止标准对于开发人员和PM也是有用的。
当然，并不是所有的测试停止标准都会有这般功效，在Aaron看来，一个合格的测试停止标准应该满足一下条件：
在计划阶段尽早订立测试停止标准
没有规矩不成方圆，先定下规矩可以帮助我们一开始就计划的时候就在画着“方圆”，而不是等画了一点点之后才发现用的“规矩”不是标准版的，那样浪费了时间。
测试停止标准应该获得项目负责人的确认
这一条尤其适用于并不是那么和谐的项目组以及习惯优柔寡断的项目负责人领导的项目组。还要注意口说无凭，所以立字为据有时候也是需要的~我们的目的是要使规矩“定”下来。
对于这一条，存在这两个风险：
一是容易导致不和谐：如果项目负责人签了，感觉像是兄弟们在给他上枷锁似的，更像是把一些责任推到他的身上去了。（因为存在这样一种情况，大家订立一个规矩，可是后来做的东西让top leader不满意，普通组员这个时候好歹还可以推说我们组的规矩是这样做的，不需要问，当时签字确认的项目负责人这下子责任就大了。）
二是因为需求变化，因为测试停止标准要求满足可度量性（具体内容在后文详谈），所以可能会涉及到比较细致的东西，比如某个核心模块应该怎么样才算行——如果在后期需求变了，会不得不更改“定”下来的测试停止标准了。
对于这些风险的预防和处理，Aaron虽然有些心得，但是考虑到各个作坊情况不一样，Aaron就不误导各位了。
测试停止标准应该是可度量的
Aaron看来，对于测试停止标准，“可度量”这个要求是必需的，用抽象的语言来描述测试停止标准是无意义的。如在测试停止标准里面出现“在适当的时间停止测试”这句话是不对的，所谓“合适的时间”这类词汇，要么让人不解其意，要么出现“一千个观众眼中有一千个哈姆莱特”这种情况，因此一个准确的定义是必需的。
测试停止标准都是可以达到的
这个很容易理解，如果标准里面出现了要我们三五个人十来杆抢在一个月内造一个跟windows Xp一模一样的操作系统给客户，那定这个标准的人怕是跟Aaron前天一样SB了~测试停止标准之中切忌出现不可能实现的或者很难达到的目标，比如在测试停止标准里面出现“修复所有的bug”这种条文，我们就要考虑实际情况中我们是否可能修复所有的bug，项目的要求是否如此严格——所有的bug都必须修复，而不是被处理（修复，延迟并报告等处理方式），是否允许部分bug推迟修复？
测试停止标准的检查者
测试停止标准作为一个验收标准，还需要明确规定标准执法者。没有规矩不成方圆，但是有了规矩而不执行，也是成不了“方圆”的，所以需要执法者或者说护法者，在这里体现为检查和核实我们的测试是否达到了标准。有时候，为了表示民主，大家一起说了算在人数不多的项目组也是一个可取的方式。
Aaron讲了自己的一些理解，但看着过于抽象，所以就继续具体点讲一下。开发人员贴code，Aaron这边没Code，只好贴几张便签纸 J
1
》有效测试用例（功能）执行率达到X%？
》单元测试代码行覆盖率达到X%？
》单元测试用例通过率X%？
》单元测试用例设计通过评审
》核心模块（A,;B,D等模块）测试覆盖
》所发现缺陷均纳入缺陷管理系统
》优先级最高的bug全部修复
》其他bug全部被处理（修复，延迟并报告等处理方式）
》功能测试用例模块，功能点覆盖率达到？
1
比如单元测试活动在满足以下所有条件之后可停止：
》核心模块代码100％ 经过Code Review
》单元测试用例设计通过评审
》测试用例执行率100%
》最新版本的单元测试通过率为100%
》单元测试全局代码行覆盖率不低于80%
》单元测试单个模块代码行覆盖率不低于70%
》单元测试中被测单元发现的bug产生率不低于3个/千行代码
》所有发现缺陷都纳入缺陷追踪系统
》优先级1类bug全部被修复
》优先级2，3类bug全部被处理（修复或者不处理并明确在测试报告指出且获得通过）
》完成了单元测试报告并通过评审
……
1
测试活动在满足下列条件之一时需要暂停或者终止：
》新的需求变更过大，测试活动应暂停，待需求定义稳定后继续；
》测试超过了预定时间，且测试时间不可能继续增加的情况下应停止测试；
》测试成本增高（Bug发现率低于1个/周，此时所发现缺陷低于预定义的上限）；
》若开发暂停，则相应测试也应暂停，并备份暂停点数据；
》软件系统通过验收测试；
》软件项目在其开发生命周期内出现重大估算和进度偏差，需暂停或终止时，测试应随之暂停或终止，并备份暂停或终止点数据；
》项目负责人申明停止项目；
》团队集体（开发，管理，测试，市场，销售人员）同意停止项目（因市场及利益等原因）；
……
上面几张便签来自网络和个人实践，Aaron只是摘选部分，切不可直接拿来作模板，否则就是Aaron的误人子弟的罪过了~这几张便签纸并不能直接帮助读者建立起一个适合自己项目的“测试停止标准”，因为Aaron相信大家的能力。Aaron将测试停止标准扯到计划测试系列的目的，是要提醒读者在计划的时候就要有看到我们的结果的眼光。项目也好，测试过程也好，都是以结果为导向的，没有最后的成功，中间过程即使很完美，对于项目（产品）自身是没有任何意义的（大多数情况下，项目成员在吞食失败的挫折感的同时，至少还收获了经验，所以可能还会有人会享受失败项目中的“美好的过程”）。
后记：终于写完了《计划测试系列》的所有文章了，Aaron却更加忐忑起来。或许是以前在51testing待得时间比较久，还真没有感受到冷若冰霜的感觉。或许Aaron本不该坚持在一个满是开发人员的园子里面发测试文章，但是也喜欢.NET开发的Aaron喜欢上了这个园子，冇得办法~
