软件系统是以构成计算机系统一部分的软件为基础的内部通信组件的系统。本文的主要内容是通过对软件系统通信节点的识别，分享软件系统的测试思路。
 如图 1-1 所示，在一套软件系统中，我们对其进行层次划分，可以分为四层，分别为用户层、展示层、服务层和关联层。四个层次间含有三个关键的通信节点，这里分别定义为通信上节点、通信中节点和通信下节点。
  
           图 1-1 软件系统分层

 在整个软件系统的通信中，用户与客户端（手机/电脑）进行交互，触发信息流动，信息先是至下而上流转到服务层，而后从上而下反馈至用户，从而完成信息传递的闭环。为了验证信息在整个闭环中流转的正确性，本质上我们要验证信息在系统中每一个节点的流转都是稳定且正确的。下文将分享软件系统中三个关键通信节点的测试思路。

一、通信下节点

 系统第一个关键节点为系统中用户与展示层的通信节点，如图 2-1 所示，这里定义它为通信下节点。
  
           图 2-1 通信下节点

 为了验证信息在这个通信节点间流转的正确性，我们需要在理解业务内容和产品需求的基础上，作为软件产品的第一批用户，通过与客户端交互的方式来开展黑盒测试（功能测试），尽可能完整地模拟用户所处的环境和各业务场景下可能产生的数据流，验证业务流程能够得到正确的实现。通过黑盒测试，我们以用户的角色最直接地验证系统的功能性和易用性，但这种方式验证系统的弊端也比较明显：对整个系统通信的验证只停留在表层。

二、通信中节点

 系统第二个关键节点为展示层与服务层的通信节点，如图 3-1 所示，这里定义它为通信中节点。
  
           图 3-1 通信中节点

 相对于上文的通信下节点，通信中节点的信息交互对于普通用户是不可见的。通信中节点的交互方式主要是通过定义好的网络通信协议及 API 接口进行数据交互。这里的网络通信协议可以理解为是两个人约定的交流语言（类似中文 or 英语），API 接口可以理解为包含特定语言语法的对话方式（音频 or 视频）。为了保障客户端与服务层进行的通信是准确高效的，我们需要在理解需求数据点和接口 API 定义的基础上开展灰盒测试（介于黑盒测试和白盒测试的一种测试）。在这个节点中，通信输入的内容是客户端发送的数据信息，通信输出的内容是服务层响应的数据信息。针对通信中节点的数据流转，我们需要验证展示层发起正确的请求信息，服务层返回正确的响应信息，以及展示层正确地展示服务层响应的数据这三个部分。
 识别通信中节点后，为了更直接地验证数据在这个节点流转的正确性，我们可以对上下层服务进行拆分，建立代理层，如图 3-2 所示。
  
           图 3-2 通信中节点（代理层）

 通过建立代理层，我们可以暂时解除展示层与服务层的强依赖，分别与节点上下游进行直接对话，通过代理层捕获展示层是否发起正确的请求信息，通过伪造不同场景请求数据验证服务层是否返回正确的响应数据，以及通过伪造不同场景的响应数据验证展示层是否正确展示，从而摆脱只能通过操作底层客户端进行系统验证的局限。

2.1 服务层：服务端与数据库间通信节点

 在通信中节点建立代理层后，我们可以通过模拟接口请求数据和校验响应数据的方法来校验服务层输入及输出的正确性，但是我们可能无法保证数据在服务内部（存储层和逻辑层间）的通信是否正确。如图 3-3 所示，图中的黄色箭头为服务端与数据库间通信节点，为了验证系统服务层的正确性，我们也需要明确服务端和数据库通信机制和通信数据，验证服务端与数据库之间数据流转的正确性。
  
           图 3-3 服务端与数据库间通信节点（服务层）

 我们可以使用工具直接与数据库建立连接，获取对数据增删改查的权限。可以直接校验外部数据输入经过服务端逻辑处理后，数据（数据存储）是否正确存储，也可以直接修改或删除数据库数据，模拟不同业务场景去校验数据经过服务端逻辑处理（数据转化）是否正确输出。

2.2 服务端内部通信节点

 了解服务层内部服务端与数据库间的通信节点及数据流转后，服务层对于我们已经不再是完全的黑盒。如果我们想更加深入验证服务端内部数据流转的正确性，我们就需要分析下服务端（逻辑处理）内部的通信节点。如图 3-4 所示，数据 A 在服务内部的可能经过四个节点，为了验证数据 A 能够正确转换成数据 B，实际上需要我们验证数据 A 在每个节点都能正确流转，我们也同样可以通过节点间建立代理（打桩）的方法对系统开展基于代码模块的测试（白盒测试）。
  
           图 3-4 服务端内部通信节点（服务层）

三、通信上节点

 系统第三个关键节点为服务层与关联层的通信节点，如图 4-1 所示，这里定义它为通信上节点。
  
           图 4-1 通信上节点

 由于通信上节点关联服务层和上游服务，测试服务层及以下环节过程中，一方面我们难以保证上游服务的测试环境总是稳定的，另一方面为了验证上游不同类型的数据场景，我们通常需要从服务层下游进行数据输入，增加了数据流转的链路。因此，如图 4-2 所示，我们可以在通信上节点增加代理层隔离上游，既可以降低对上游服务的强依赖，也可以减少数据流转的链路。
  
           图 4-2 通信上节点（代理层）

 除了增加代理层的方法外，如图 4-3 所示，我们也可以让服务层的服务下沉到本地（本地调试），在本地启用服务，通过本地代理工具模拟（Mock）上游数据进行调试（白盒测试），验证服务层内部数据流转的正确性。
  
           图 4-3 服务层本地调试

四、总结

 作为测试工程师，我们需要与产品经理、UI/UX、运营、运维以及各个岗位的研发人员交流，共同协作完成一个项目的设计、开发、测试、运营及运维工作。在工作中我们相对重视加强与人的沟通，但是我们却相对忽视加强与计算机系统的沟通。不仅因为工作内容限制了我们与计算机系统的沟通机会，也因为计算机系统的抽象性和复杂性容易使我们望而却步。
 本文在介绍对软件系统层级及系统关键通信节点的思考同时，也介绍了通过建立代理层直接对话通信节点上下游服务的思路，从而探索软件系统的全链路测试。本文尚未介绍具体的测试工具或者是技术，本文想分享的核心内容是分而治之的思想以及由表及里的探索式测试思路。为了提升我们直接与计算机的对话能力，我们可以尝试由表及里地去识别计算机中可能的通信节点，结合工具的使用循序渐进去了解与系统节点间的通信方式和通信细节，逐步加强与系统各通信节点的对话能力。如图 5-1 所示，现实中的软件系统可能更为复杂，但是，我们依然可以以通信节点的识别和拆分为基础，尝试去思考如何分而测之。
  
           图 5-1 软件系统（扩展）

作者简介：Chaofan，爱测角成员之一，专注探索和分享软件质量保障。
原文地址：《漫谈软件系统测试——通信节点识别》