测试覆盖与测试工作关系问题的思考

前言

参考原文:http://sauceio.com/index.php/2015/09/can-you-test-it-all-test-coverage-vs-resources/

近期参与每一个项目的时候，我都有这样一个疑问：产品的所有方面都可以被测试吗？当然答案是否定的。要么没有时间测试，要么就是缺人测试。那么问题来了：在有损测试的情况下，我们该如何保证交付高质量的产品？也许我们应该更加精准的完成测试。

常见原因

以笔者多年的工作经验来讲，我们手忙脚乱地完成测试并发布产品，通常是由以下原因导致的：

1、用户故事（story）太大。当story太大时，就会很难进行任务分解，也难以确定所有特性的验收标准。此时，不但难以规划不可预见的情况，而且也难以协调项目遇到的问题。

2、产品工作流过于复杂。由于特性的关系，使得产品的工作流可能是非常复杂的，此时也难以判断是否为用户实际需要的产品。同时，由于复杂工作流的存在，测试人员将面临更多挑战去梳理清楚每一个测试场景，并为之设计端到端的测试用例。即使划分更多的很小的story，整体工作流仍要包括所有的story，如果工作流过于复杂同样可能会导致漏测。

3、不使用测试驱动的开发。开发为了暂时的方便快捷而舍弃了规则和QA，这种行为将为项目的未来带来巨大的挑战，问题将会滞后甚至阻塞测试的进程。

4、发布期限问题。你参与项目中，项目成员都明确了解整体计划吗？清楚交付日期吗？如果开发进度滞后，但仍坚持按期交付，矛盾该如何解决呢？

5、需求太多。项目需要实现太多需求，看到所有的需求已让人目瞪口呆。我们需要考虑产品的多个版本，不同的浏览器（或浏览器版本），多种移动终端，操作系统等，这些对任何人来说都是挑战。如果要实现以上所提到的所有需求，并要达到100％的测试覆盖，这真的可以完成吗？

怎么办？

以上的几点并不是反对QA去完成足够的测试覆盖范围。但是，在现实中，测试真的需要面面俱到吗？我们应该更加精准地完成测试。

首先，让story变小！如果story足够小，也就更容易识别的验收标准，并确保覆盖范围（至少是对于那些孤立的功能），同时可以根据经典测试三角形（单元测试、集成测试和UI测试）来制定测试策略。

抓住主要的工作流！每个人使用习惯都是不同的，我们也无法预测用户如何与系统进行交互，但我们可以知道大多数用户会怎么做，可以跟设计师或用研沟通多了解相关信息。经过对常用操作流的梳理，我们可以深入了解这些工作流，以找出真正需要测试覆盖的部分，并优先实现这部分工作流的自动化测试。其他较少涉及的用户场景可以开展探索式测试。

二八原则：哪个才是风险最大的模块？扪心自问，我们怎样才能做到用尽可能少的测试去发现尽可能多的bug？通俗的说，如何通过20％的测试去发现80％的bug？此时，如果有积累足够的历史数据，并分析发现某些模块极少存在问题，那么我们是否还需要投入很多的测试资源呢？我们是否应该集中测试资源在经常发现问题的模块呢？

大数据：必须承认，开始听到“大数据”这个流行词我是拒绝的，但后来发现这玩意儿还挺管用。通过分析我们可以知道客户端情况、浏览器版本和点击流，这些分析结论都可以帮助我们制定测试策略。然后，我们也可以更合理分配时间，关注测试进展和人力分配。

最后，我想说质量保证是整个项目组的事。的确，我们无法做到测试的完全覆盖，但是我们可以通过测试策略、测试合计和测试执行的过程让整个测试流程变得更加精准。需要提醒的是，要做到什么程度的测试覆盖，是整个项目团队的决定，而不仅仅是测试人员。我们可以驱动沟通并提出建议，但项目组最终决定我们什么时间要完成测试，我们应该测试哪些点。