对于某个多服务项目的测试总结

服务项目的测试总结"/>

对于某个多服务项目的测试总结

• 项目背景
• 1.1. 业务背景

该项目是属于地产项目行业的，我们组要做的内容是实现该高端地产的智慧通行（包括

员工/住户管理、人/车通行、访客通行）、物业管理和数字化该地产/园区所具有的特色。

1.2. 技术背景

我们组实现这些需求时，在架构设计和技术选型时选择了多个微服务（多个微服务+一个gateway）和MySQL数据库（一个服务对应一个数据库，每个数据库里又多张表）及Redis，采用了react实现web管理平台和Vue-mini编写微信小程序。

• 测试范围

2.1. 测试对象：有微信小程序、web管理系统及涉及到的后端服务。

2.2. 测试类型：有项目整体的功能测试、性能测试、安全性测试和小程序的兼容性测试。

当项目进行了几个迭代后，我替换了原来的QA角色，在我知道我的测试范围后，我觉

得这是一个没什么挑战而且吃老本的活，但是随着项目的推进，我还是学到了一些新知识（比如利用JMeter工具造数据和做一些性能测试）和应用了一些方法到项目中来提升团队的效能（比如缺陷分析的运用）；同时在整个项目测试中，我发现我可以把测试过程中遇到的一些值得注意的问题总结下来。

• 问题总结

在一个项目里，能被测试出来的bug其实有很多，而且会有各种类型的bug及原因。

我就不一一举例总结和举例了，就针对架构设计里的某些阶段和技术选型提出一些值得注意的地方。

3.1. 数据库表字段设计

我们在功能测试和数据库方面相关的内容时，除了常见的关注数据存储增删改、一致性

和数据明暗安全性，还有一点要注意：就是表里每个字段的类型和限制字数，这一点有时候容易被忽略，特别是多个库多个表涉及到同一个含义字段时。一次测试时我发现某组数据写入数据库表时，总是报SQL执行错误，后来排查发现是某个字段在某个表里设计的限制字数比产生数据源那张表的限制字数小，从而导致字数超长写入失败。这个字段在很多表里有运用到，但是我们总共有几十张表，不可能一张表一张表去人工排查，而我们QA的责任之一就是要找全这些表，所以要借助SQL命令去找出来。我当时运用了一条命令很快就找出来了。

SELECT * FROM information_schema.columns WHERE column_name='字段名';

3.2. 微服务网关Gateway

微服务实践的方式已经多年了，其中采用比较多的设计模式就是有API网关设计。微服

务网关设计其中一个便利就是可以统一管控接口访问权限，当然这其中也有隐患。我们组发现其中之一的隐患：用户角色很多，各角色的权限在权限服务有配置，同时在gateway里有映射各角色的接口访问权限，如果用户角色权限在权限服务配置里有变更，部署时又只部署了权限服务，而gateway没有触发部署，就会导致某些接口访问失败。所以我们采用的解决方案是每次权限服务重启就通知gateway清楚缓存，重新拿权限服务那边的权限再缓存。

       3.3. 服务部署在多个pod中

       现在很多的服务部署都采用云部署，而云平台中Kubernetes最小部署单位就是pod，管理着一个或一组容器。我们的每个服务就在pod上运行，当一个服务有部署在多个pod时，就相当于每个pod中都有微服务的副本，这种情况下需要特别注意下从微服务触发的事件。比如在服务中要执行某个事件，去Redis中获取一个缓存数据，然后发送短信给某个特定用户，没有特殊处理的话每个pod中的副本都会去Redis中拿取，然后这个用户就会收到多条一样的短信；所以我们需要在Redis那边设置锁，保证该微服务只取一次。

3.4. token变更

一般有用户概念的系统都会有用户信息管理，而用户信息特别是涉及到权限的大多在

token里，所以token变更能少就尽量少，不然变更后的token在前端没有重新获取时，会影响变更后的用户权限，导致某些接口或者模块访问失败。我们组也采用了在token放一些用户信息和权限，因为需求的迭代，我们经历过在token里添加一个新的字段用来和第三方系统互通。当时我们把涉及到token的权限服务和其他与第三方系统互通的服务部署了，但是前端已登录的用户在token过期前没有重新拿token，导致这部分用户在访问相关接口时直接挂了。而我们当时采用最简单的解决方法就是对于这一版的前端直接修改了获取token的key值，这样就导致已登录用户在打开产品使用时需要重新明路登录授权获取新的token。

3.5. 端到端接口契约

做一个系统时，不可避免会有前后端或者其他第三方的系统/接口，那么这中间就涉及

到各方数据使用的一致性——我们所谓的接口契约，要求相关联方使用的接口数据结构和数据值一致性。在项目开发过程中，一般分工明确的前后端或者第三方，都会预先约定使用的接口数据结构和相关的含义和值，这样大家就按照契约来开发，最后再联调就行了。但是往往开发过程中或者某个故事卡开发完成后提供方会去动一动契约，比如就某个结构的值变更成另一方不识别的了或者数据结构变了，但又忘了通知其他参与方，这样就导致该接口的链路不通了。有些项目组会在这方面做严格的监察，比如契约测试或者更细致的接口测试，但更多的项目组是没有做的。这样就给QA带来了更多工作量或者给项目带来了更大风险。

四、写在最后

针对不同的项目，选用不同的技术选型和架构设计，肯定会引发不同的bug，这个需要我们慢慢沉淀，当然要发现这些问题，我们QA除了要了解业务，还需要了解项目组采用的技术及其可能引发的问题。