虽然已经2023年了，但还是有技术人员认为，测试是不需要理解需求背景和设计方案，也不用参加需求评审、设计评审，只需要按照需求文档，就可以编写详细全面的测试用例，甚至很多测试也是这么认为的。也有很多纯黑盒功能测试对自己熟练掌握“业务流程”而沾沾自喜。不理解业务流程背后的逻辑，仅依靠需求文档和对业务的表面理解，真的可以做好测试工作吗。
因为测试工作是针对一系列输入，将输出结果和预期进行比较的过程。我们可以将代码当成一个函数y=f(x)。因为不知道内部实现逻辑，我们不知道这是什么函数，只能设计一系列输入，x1、x2、x3，看输出的y1、y2、y3是否和需求文档中说明的预期相同。而且由于不可能穷举所有输入，通常按照等价类边界值等方式选取有代表性的值（或组合)作为输入。
假设需求是x和y的乘积是10，我们可能会选x=1、2、1.5、2.5，测试结果确实无误。但是，代码中的设计是y=10/x，当x为0时，程序就异常了。不理解函数，你能知道x是不能为0的吗，你会刚好覆盖到这个场景吗。
你可能会说，x为0是特殊值，肯定会测试的，那假设函数为y=10/(x-1)呢，你保证一定会覆盖到这个值吗。
你可能会说，特殊情况应该在文档标明，否则就是文档疏漏。如果需求要求xy=10，只是程序设计成了y=10/x呢。
你可能又会说，那这就是需求和设计不符，开发没有按照需求实现，噢，亲爱的，你的工作就是要找出这些不一致吖，让开发100%按照需求实现，你琢磨琢磨这个可能性有多大。
于是你退一步说，那开发应该在设计文档里标明实现逻辑，或者在测试案例评审的时候跟测试提出需要增加这个情况的测试，有没有可能开发写的时候觉得这里肯定不会出问题。
你也可能会说，然后我不懂背后逻辑，但是我测试经验丰富，根据以往错误经验，经常能发现重要缺陷，看到上传图片我就能想到图片类型、图片大小限制，看到金额计算我就知道不能用float类型处理，你能确保每次都刚好选中特殊入参吗。
开发说优化了代码，让你回归一下，比如原本函数是y=√x^2，改成了y=x，这两个函数看起来相等，但是x的作用域其实不同，这并不真正是同一个函数，所以你真的不用知道开发的改动点，只是拿几个场景测一下主流程就觉得可以0 bug上线了吗。
再举一个常见的例子。借款申请提交成功页会提示该客户在我行未开卡，请联系客户经理办卡。测试同学认为，测试数据默认没有开卡，这样提示是正常的，当要执行有卡的情况的案例时，找开发同学拿测试数据，一提交果然提示已开卡，测试通过。
你有没有思考过，校验客户是否开卡的逻辑是什么，是某个服务提供了专门的查询接口，检验的要素是什么，或者是去某某库中查询的，这个库的数据是怎么来的，是业务系统自己的数据还是从基础数据导过来的，导数的逻辑是什么，会不会出现注销了的卡也当成已开卡，导数是T+0还是T+1，如果是T+1会不会有问题。当你看到页面上这个您已开卡/未开卡时，有思考过这些问题吗，还是看到页面有按照需求的不同结果展示，就认为测试充分了。
功能测试不只是根据原型图在页面上点点点，能跳转到相应的页面，返回相应的数据，出现相应的提示就是100%覆盖了。你可以不看代码，但是对你负责的系统，你需要知道业务流程、数据走向、表结构、数据类型。否则即使你测完了，发现了多少缺陷，也顺利通过了验收，测试质量也是堪忧的，只是什么时候生产问题会暴露出来而已。
这里说的业务流程，不仅是操作流程，还包括系统交互、数据流，即使你熟练掌握该系统使用流程，用户填写××提交后，系统返回××，后台生成代办事项……是个使用过的人都可以说出来，你作为系统的测试和使用者的区别是什么，核心竞争力是什么。你应该知道，用户填写的信息，提交是用的什么接口，是什么服务调用什么服务，数据是落到什么表，哪些任务是通过调度触发的。
现在我们经常听到测试质量和测试效率，测试质量不是单纯靠时间堆砌能弥补的。就拿前面的y=10/(x-1)来说，你设计了1000个xn，如果你没有刚好用x=1，显然这1000个测试案例都可以测试通过并且发现不了缺陷，但是如果你知道这个逻辑，你就可以轻松找到让系统出错的参数，而不必做无用功。
所以对测试而言，设计文档和需求文档是同等重要的，测试非常有必要参与设计评审。在设计测试用例阶段，也要多和开发沟通设计实现细节，才能设计出针对性强的测试用例，避免遗漏测试点，并且能在这个阶段通过设计方案提前发现开发的漏洞，发现系统风险是最好的了。同理，测试用例评审时，所有相关的开发也需要参与，除了补充测试用例中遗漏的重要测试场景，还可以给开发完善设计的思路。
你说，那这样不是毙掉了不懂代码的测试吗。不是的，设计不等于代码，你知道系统调用链路并不等于你需要知道代码中的每个类。
你说，测试资源受限制，没有这么多精力去理解，给测试的时间只刚好够写测试用例和执行测试，哪里有时间去搞懂实现方式。首先这并不会花费你什么额外时间，而且越是时间不够，精准测试就越重要不是吗。