如何管理测试项目（二）

前言

本文属于项目管理系列，之前已经写过一篇，今后也还会继续探讨这个话题。

前言与本文主题没有直接关系，算是笔者的啰嗦之言，不喜可以跳过。

也许跟自己的职业生涯有关（初做开发、后转技术支持，再后来直接做了测试管理），在走上管理岗，开始搭建测试流程的时候，着实困扰过一段时间。因为此前没有在测试团队工作过，所以不清楚究竟应该搭建什么样的规范，更不清楚什么样的规范才能快速顺畅的在公司内部推行。

很快，接触到了CMMI，也因此了解到了其他公司的一些流程规范，坦白说，在看到CMMI里的一些范例后，当时确有一种“如获至宝”的感觉，因为终于有了可以参考的、正规的案例。于是在此后一段时间，也开始推行收获的这些“宝贝”。结果想必你们也猜到了，很不顺畅。

在推行受阻后，开始反思那段时间的所做所为，时间长了，也确有收获。

正所谓逆着难从，顺着易行。难从则逆，易行泽顺。员工都是喜欢做容易的事，我一进去就把人家的工作搞得很复杂，不失败才怪。

我听过一种论调，就是做领导一定要坚定，即使错了也要坚定。坦白说我做不到“执迷不悟”，至少现在做不到。

另外，我也发现了规范里一些经不起推敲的地方。比如今天讨论的话题。

“测试停止标准 ”，也有公司叫“测试出口标准 ”，想必很多人都为此纠结过，本文就这个话题说说当年踏足的那些坑，希望对大家有所帮助。

正文

下面是我看到过的一个“测试停止标准”：

• 测试用例执行率100%；
• 功能性测试用例执行通过率100%；
• 非功能性测试用例执行通过率90%以上；
• 已实现/计划实现用例=100%；
• 测试遗留的bug数量：
• 严重的缺陷：0个；
• 一般缺陷：0个；
• 次要错误：0个
• 修补改进：小于5个。

大家看到这个，是否会有什么感觉呢？

对我来说，我觉得这里面反映了一个测试用例的使用问题。这里的通过率是需要一些前提条件的，否则统计测试用例的通过率说明不了任何问题：90%的通过率到底是好还是不好？如果不掌握测试内容的详细信息，就没法回答这个问题。统计所实现的测试用例与计划实现的测试用例比例也说明不了任何问题：也许最困难的测试用例被推到最后，最后10%的用例需要50%的时间完成。也许所计划的测试用例数还根本不足以覆盖重要的风险。我认为，如果我们使用不合适的、解释不通的测试用例指标，向客户说明测试范围和完整性，不管是否是故意的，都是欺骗行为。

那么我们是否不应该统计这些数据呢？

我觉得，知道的少但是正视这种现实，总归要比知道的少但假装知道的很多好。况且我们可以讨论这些数字的含义。例如讨论测试用例通过率为何没有达到预期。也许没有足够的人执行所有的测试，或编写错误报告，或检验已发现的问题是否全部解决。可以利用这些数字说明自己的考虑。

一般来说，需要使测试过程具有可视性。指标可以做到这一点。但是不要指望项目经理和开发能够理解全部指标——不管我们认为指标多么“合理明了”、多么能够“自我解释”。相比指标，测试经理还是需要多关注用例的内容（即风险和覆盖率）。

什么才是测试结束的标准呢？

我们都知道，测试的价值在于它提供的信息。估计测试的价值是很困难的，而且我们都知道“我们不可能发现所有的问题”。一般来说，当我们有理由相信系统存在严重bug的可能性很低时，就可以停止测试。

怎么判断测试的足够好了呢？

判断测试是否足够好有很多因素：

1. 知道要发现的重要问题的种类，知道程序的不同模块如何表现出严重问题，且做了与这些风险相对应的测试
2. 测试策略具备多样性
3. 清晰的定义或汇报了测试策略、测试结果和质量评估
4. 使用了所有可用的资源进行测试
5. 满足客户期望满足的所有测试过程标准

如果上面这些都做了，上线后仍然存在问题，那么原因可能有：

1. 测试人员没有自己想象的那样了解风险
2. 测试人员在测试中出现错误
3. 测试人员的风险评估是正确的，但是管理层决定冒风险

总结

到底什么样的测试结束标准才是科学的？我我只能给出一般性的原则，具体的结束标准还是要根据项目情况、客户意愿等多方面因素具体考虑，而且测试能否结束，往往会随着测试经理对项目理解的加深而改变。另外在测试过程中遗漏问题不算问题，粗心、不认真思索或不通过实践吸取教训才是问题。