对测试工作目的的认识误区

在IT行业，其实一直对软件测试，测试这个工作的目的，一直有着不太准确的认识。

各种说法都有，比较流行，被很多IT工作甚至测试从业者认可的有下面两种：

• 测试是为了发现Bug

大家一般概念中通常都会把做测试和找Bug等同起来，也就是说软件测试的目的是为了发现产品中的问题。

• 测试是为了验证产品满足需求

也有从测试执行的角度来说，测试工作是为了证明软件产品是符合产品需求定义，是为了验证需求是否实现的。

那这些说法对不对呢？ 可以说对，也可以说不对

确实，测试工作的主要产出就是我们发现的各种产品bug，而要验证需求则是我们测试工作的主要输入和评估标准。

但这些就是我们要进行测试工作的目的吗？

单纯把测试工作的目的从上面几点来看就狭隘了。

测试是为了找Bug吗？

我们做测试工作是为了发现bug吗？

bug对于产品来说，意味着成本，bug本身对产品来说是不会产生价值的。被解决掉的Bug才会带来产品质量的提升，进而体现到产品的价值中去。bug的减少，对产品才有价值。

所以，单纯地把发现更多bug作为测试工作目的是一个误区，这也是很多团队错误地把发现bug的数量作为测试工作成效依据的主要原因。如果bug发现得越多代表测试工作越好，测试人员是不是就不应该再早期阶段去参与？因为在前期就规避掉的问题其实会导致到测试阶段bug变少，如果测试工作是希望发现更多bug，是不是就应该希望产品提测的时候包含更多bug呢？ 这个导向显然是不符合产品利益的。

因此把发现bug作为测试工作的目的是一个常见的，明显的对测试工作的认识误区

测试就是为了验证需求吗？

第二个对测试工作目的的认识误区，就是认为测试工作就是为了验证产品的需求。这其实是另一个被广泛接受的错误认识。甚至我们当今流传广泛的很多软件工程实践，都是建立在这个错误认识之上的。

测试大牛James Bach有篇著名的论文，探讨了Testing跟Checking的区别。

也就是测试工作远远不止是checking。而验证需求，这样的checking只是测试工作的一部分。测试要深入产品、发现潜在的深层问题，还需要除了checking之外的更多其他能力支撑，包括探索、试验、设问、推理等等

所以，把验证需求，当作测试工作的目的，是不够的。像工厂质检那样依据严格的规程来确定产品是否合格，和软件产品这种偏创造性的行业也并不匹配。这也是我们说自动化测试更多是为了提升执行效率和快速得到已覆盖场景的验证结果反馈，但自动化测试本身并不能达到完成产品测试的目的。

测试除了验证需求中明确的功能外，还需要针对交付产品进行更深度的探索，才更可能充分发现产品中的质量问题。这也是近年探索式测试被更多提及的主要缘由。

软件测试工作的真正目的

好，那既然测试工作的目的既不是为了找Bug，也不是为了验证需求，那目的究竟是什么呢？

软件测试的真正目的： 准确、及时地评估出被测对象的质量状态

这里的核心是评估质量状态。质量是产品属性，只能通过产品本身的变更来调整，所以测试工作无法提高质量，也无法保证质量。但通过测试工作，我们可以通过暴露产品中的问题，反映出产品的质量状态。我们的主要作用是对当前产品的质量进行评估。再由产品或项目针对这个状态来对质量进行改进。

所以测试工作对于质量的贡献更多体现在这个评估出的质量状态是否及时和准确两方面。

准确评估

测试无法穷尽，在有限的时间内发现产品的所有问题也是不可能的。但测试的职责是需要在有限的时间内，尽可能多地将影响产品质量的问题暴露出来。这里除了数量外，我们还要看问题的影响，综合这两点，才是更准确地反映质量。

及时评估

产品是无法进行无限测试的，而且测试工作其实本身是成本支出。所以通过测试工作得出产品质量状态的时效对于产品的质量改进和成本控制也尤为关键。问题发现得越早，修复成本就越低；得出质量状态评估的时间越短，产品进行针对性改进的空间就越大。所以测试工作的目的，还包括提高测试效率，通过自动化、测试左移等手段来尽可能及时地完成产品质量评估。

所以这才是我们进行软件测试工作的真正目的，不是为了发现更多的bug，也不是仅仅是对需求实现的检查，而是通过我们的专业能力，在有限的时间内，及时、充分地反映出当前产品实际的质量状态。

---

以上就是关于软件测试工作目的 的分享，我是城下秋草。 秋草观测台，观察测试业