测试工程师的修炼：识别需求

做了十来年的软件测试工程师，今天开个题，开始写测试相关的内容，进行些沉淀与积累。

对于近年的软件工程来说，尤其是软工的国内发展趋势而言，软件开发的规范性大幅度提高了，一个标志点是，大部分软件都有需求了，不再处于之前的“蛮荒”阶段。当然，需求以各种形式存在，软件需求、用户故事等等，不一而足。

我们今天的主题要从测试的视角看需求，而不从产品的角度看需求，因为这两个视角对于需求的要求完全不同。一个假设：需求文档满足产品要求，正确地提取了用户需求，没有误读。

测试人员对软件需求有什么要求？

当然，首先要正确准确，其次是完备没有遗漏，还需要满足可测性的要求，这三点缺一不可。正确性是基础，完备和可测试更进一步的要求，三性中任何一点不满足，都会对测试造成很大的影响。例如说，可测性无法满足直接导致无法测试（没法儿做），还会影响测试的正确性（导致返工），影响测试充分性（导致测试工作量预估不足）。

如果导致了测试的问题，一定是开发人员的错吗？当然，错误是开发人员引入的，任何时候任何错误我们都可以推给开发；但是本着责任心来说，测试人员作为质量保证重要的环节是脱不开责任的。作为测试人员，我们需要识别需求是否正确合理，满足应有的属性，而非一味本着逃避责任的态度。

更加极端一些的角度，测试人员应该在阅读需求之前假设需求是错误的，使用批判性思维对其进行结构化整理，在整合的过程中逐渐对其进行证实。而非假设正确，对其进行证伪。这样的思路，从底层上可以训练测试人员的思维方式，尽量避免遗漏文档问题。

在这个过程中，测试人员不仅仅是看需求本身，更需要看需求背后的项目环境因素，比如任务本身是什么、有什么关键的信息、开发团队和人员能力如何、测试团队在该方面的能力如何、测试设备和环境如何等启发式测试来覆盖需求背后的要素。

在识别需求的过程中，对于一些业务逻辑类型的需求，测试人员即便调用批判性思维和普通的逻辑思维无法对其判断时，应争取相关的说明和培训，或者争取与开发人员的沟通，提高对业务的理解能力，然后判断其正确性，而非刻意避过，减少关注。

近些年有测试左移的概念和实践，识别需求是测试左移中一个重要的视角和实践，不同的是，我们的视角是测试人员需要在前期对需求进行判断，减少后期的浪费。

这也契合那条测试原则：测试尽早介入，缺陷发现越早，修复的成本就越小。