风险驱动的测试

作者： Peter Arrenbrecht

原文链接：

http://googletesting.blogspot.tw/2014/05/testing-on-toilet-risk-driven-testing.html

我们都习惯于依照代码来进行测试，如：单元测试，功能测试，UI测试等——这便是我们所有的工作内容。但别忘了，我们是专业人员，我们大多认为小版本的测试可以快速完成，而大项目的测试则要确保安全和没有漏测。或者我们可能只是在评审时提出意见。我们太习惯于这种测试方式，以致于我们在进行测试时都不再考虑这样做的理由。这样不仅浪费时间和也会有潜在危险。

测试的目的是降低项目潜在的重大风险，并获得最大利益。而利益并不总是来源于你的例行测试，或者根本不是来源于测试。

举两个例子：

“我们构建了一个调试工具，接着对它进行单元测试，集成测试和UI测试，之后准备发布。”

这种做法仍有未解决的问题，不能达到目的。

主要的风险是：为了测试这个调试工具，我们要考虑到数据破坏或关闭服务器的情况。但是没有一个测试涉及到这一操作，他们觉得已经保证了工具的安全性，“完成”了测试。

我们取消发布。

我们想要取消一个功能，因此需要警告会受到影响的用户。又一次地，我们对此进行了单元测试和集成测试，和一个高成本的端对端测试。

这种做法很普遍，但是浪费精力。

这个警告实际是特别需要端对端全面覆盖所有场景来测试的，但是它通常只在三个release版本后才出现。最低成本且有效的测试是什么？在每次release之前进行手工测试。

较好的方法：风险优先

对于所有项目和功能，先考虑一下再进行测试。头脑风暴出主要的风险和相应的规避方案。先做到这点，你才可以不浪费精力并能尝试你的设想。把他们当做一个QA设计记录下来，这样你就可以在评审和讨论时将其提出。

当然，标准的测试方法在大多数测试中仍然是一个好的方法（因为它是一种标准）。小版本的测试是低成本并容易编写和维护的，大的项目测试保证核心功能的使用以及集成。

要记住，测试是一种方法，获得利益才是关键。你的任务则是让利益最大化。