为什么测试要了解系统架构

前段时间星球群里大家聊起了系统架构相关的话题。有同学说现在测试面试太难了，既要懂业务，又要写代码，更要懂系统架构，对常用的中间件也要有所了解，最好是有一定的使用经验，学不完，根本学不完。

事实真的是这样吗？从我的观察来说，上述的要求在一些知名互联网企业确实有这些要求，如果你在面试时能表现出良好的技术能力和深厚的业务经验，且对系统架构和常用中间件有所了解，对面试加分不少，通过的概率也会更大。

大部分测试岗位，在实际场景中主要的工作内容还是围绕着需求和测试用例开展点点点工作。以前还有专职的自动化测试和性能测试岗位，近几年随着市场环境的变化，专项岗位越来越少，对测试的要求变化趋势也逐渐向着全栈工程师演变。

从我的角度来理解，这是市场回归理性和现实的转变。所谓的全栈工程师，并不是要求你对技术和业务都精通，而是你要对你所在岗位的工作内容负责，一站到底。

比如你是一位测试工程师，负责某一个业务模块或者业务线的测试工作，那这部分和测试相关的工作涉及到的所有问题，到你这里就要兜底，能全部解决。

毕竟，作为测试工程师，对软件质量负责，推动解决自己负责部分的质量问题，也是应有之义。

为什么这篇文章的标题我会建议测试工程师有必要了解系统架构，不妨从下面几个角度来理解。

首先，我们的测试对象是什么？是根据抽象业务需求通过技术实现的具象的软件产品，即软件系统是业务的实现载体。要做好软件产品的质量保障工作，你势必要对它有足够的了解，否则无论是设计用例还是发现BUG，都是浮于表面，无法发现深层次的问题。

其次，我们常用的测试手段，比如接口测试、性能测试以及自动化测试，也是借助各种测试工具或者框架通过技术手段来验证软件系统的功能实现是否和需求要求一致。

以接口自动化测试为例，要想做好接口自动化测试，首先要了解接口的输入输出参数，其次要了解请求的上下游调用关系，再次要对数据的整个传输链路有所了解(如消息是否被消费，缓存是否命中，数据库数据是否落库)，否则落地过程中会遇到很多阻塞问题。

最后，自动化测试中，测试数据如何管理，出现问题如何查看日志排查(监控)，服务如何部署(服务注册配置)，诸如此类的问题，最后对应的都是系统架构。

下图为一个简易的微服务系统架构图：

我们在需求评审时，可能会遇到对某某业务进行流程优化，改动某某部分，然后进行需求分析并设计用例。

但是在实际的测试过程中，我们需要了解改动部分直接涉及了哪些服务，对上下游服务有什么影响，原来的技术实现是否能支撑改动后的用户访问量，是否需要在线上针对性进行验证和配置预案，诸如此类很多因素需要考量。

要解决这些问题，首先要把业务流程捋清楚，然后搞明白服务间的调用依赖关系，最后对系统架构有全面的了解，才能更好的解决这些问题，做好质量保障工作。

搞清楚这些，无论你做自动化测试还是性能测试，实施难度都可以降低很多，基于此做产出做汇报，也更有说服力。

这篇文章先聊到这儿，下篇文章，我会分享一些系统架构知识入门的经验，敬请期待。