● 单元测试单个模块代码行覆盖率不低于70%
● 单元测试中被测单元发现的bug产生率不低于3个/千行代码
● 所有发现缺陷都纳入缺陷追踪系统
● 优先级1类bug全部被修复
● 优先级2，3类bug全部被处理(修复或者不处理并明确在测试报告指出且获得通过)
● 完成了单元测试报告并通过评审
……
实际工作中会出现的停止“标准”
测试活动在满足下列条件之一时需要暂停或者终止：
● 新的需求变更过大，测试活动应暂停，待需求定义稳定后继续;
● 测试超过了预定时间，且测试时间不可能继续增加的情况下应停止测试;
● 测试成本增高(Bug发现率低于1个/周，此时所发现缺陷低于预定义的上限);
● 若开发暂停，则相应测试也应暂停，并备份暂停点数据;
● 软件系统通过验收测试;
● 软件项目在其开发生命周期内出现重大估算和进度偏差，需暂停或终止时，测试应随之暂停或终止，并备份暂停或终止点数据;
● 项目负责人申明停止项目;
● 团队集体(开发，管理，测试，市场，销售人员)同意停止项目(因市场及利益等原因);
……
上面几张便签来自网络和个人实践，只是摘选部分，切不可直接拿来作模板，否则鄙人就有误人子弟的罪过了~这几张便签纸并不能直接帮助读者建立起一个适合自己项目的“测试停止标准”，相信大家都有这样的能力。我将测试停止标准扯到计划测试系列的目的，是要提醒读者在计划的时候就要有看到我们的结果的眼光。项目也好，测试过程也好，都是以结果为导向的，没有最后的成功，中间过程即使很完美，对于项目(产品)自身是没有任何意义的(大多数情况下，项目成员在吞食失败的挫折感的同时，至少还收获了经验，所以可能还会有人会享受失败项目中的“美好的过程”)。
文章来源于领测软件测试网 https://www.ltesting.net/
