性能测试

Ayo · 2023年10月06日 · 最后由树叶回复于 2023年10月30日 · 13327 次阅读

历史帖

借鉴

前言

分享最近测试平台功能点实现，暂未开源；功能均一人开发完成 MVP 小步快走，沉下心去做一定会有结果，奥利给！

持续测试

Checklist

在相当长的一段时间内测试平台与运维平台对接的方式是在测试平台中维护一个字典，例如 CMDB 的每个环境对应了测试平台中的某些任务，在发布测试节点中触发测试，但随着功能的完善（代码扫描/APP 配置检测/字符集检测/路由检测），项目类型增多（软件/物联）每个测试节点所对应的动作内容是不完全相同的，例如当发布 web 应用时我们除了自动化测试之外可能还需要扫描代码以及检查路由配置，但这些在物联发布时是不需要的；以往出现这种问题时我们将会给任务增加更多的动作类型例如现在已有的 API 测试/UI 测试/性能测试/资源探测等的任务类型，除此之外我们需要对于单个环境建立大量的不同类型的任务来应对这样的需求；

为了缓解任务模块长期更改以及自动适配更多环境的目的我们基于图 1 抽象出了一层 Checklist 来聚合测试点，用内置测试点以及支持自定义测试点的方式适配一些定制化的需求，对于 web/物联这种发布类型的差别我们可以分别设置了两种全局默认的 Checklist，当没有 checklist 绑定触发测试的环境时将使用全局默认的来检查

测试结果/通知

新环境测试自动创建关联

以往在运维创建一个新环境时对于测试而言需要对着该环境在测试平台中创建一系列的配置，例如获取 CMDB 环境基础配置->在测试平台中创建环境 -> 跑基础环境数据 -> 创建几个属于该环境的测试任务关联用例分支 -> 创建与 CMDB 关联关系等;

而我们需要的一些配置都可以从 CMDB 中获取，所以我们只需要在 CMDB 创建环境后将我们需要的环境信息发给咋们，咋们根据一个固定的模版将变动的数据填入即可完成关系的建立，这样就可以在环境建立之后不需要人为介入的自动检测该环境的服务状态；

代码扫描

我们有时会出现一些代码写法不严谨以及数据库字段更改后造成与代码不匹配，例如代码中字段长度限制的长度要大于数据库字段长度，这样会在某种状态下出现代码异常，以及会出现一些 SQL 语句遗漏执行造成的问题，所以我们扫描了发布的代码注解以及当前环境的数据库字段，试图最大程度的找出字段长度不一致，或未定义，或表字段缺失，或表缺失等异常问题，而在另外一方面也可以覆盖单接口测试的范围；

而另外一些因为老旧表字段的字符集不一样在 join 查询时会出现部分异常，所以我们扫描了全表字段的字符集类型所有类型，拿出了一些异常点给予改动的参考；

影响点扫描

如图 2 在 CMDB 触发测试时同时扫描发布的镜像信息根据打包的服务于分支信息获取影响到的上层接口，基于 jcci 二开因服务代码过多在 diff 以及扫描文件的过程中加入了并发，最后分析得到影响点以及影响的接口及其推荐的用例（PS: 目前测试依旧全量执行，这个仅用来辅助分析此次的变更是否自动化覆盖），并可在线查看进行此次发布的变更代码；

数据质量

数据质量主要用于线上数据的准确性校验，而我们之前写的一些自动化测试用例也可以作为收集器提供数据，设计对应的指标以及拼凑不同的规则来校验数据的准确性；

数据模型：主要用来持久化一些计算好的时序性的数据，并可生成 DDL 以及预览一些落库数据

数据采集：适配 SQL/Python/测试用例采集，并配置后置数据数据处理器，对于一些需要持久化的数据则会关联落入定义好的数据模型中（其实总的来说也就是个定时任务）

指标定义：描述的是数据的一种形式也可以是从数据模型中取出来或经过计算得值，例如指标描述的是三日内数据的增量占比，可以从数据模型中取出数据再计算；

规则任务：为指标的编排以及条件组的或/与计算，一个颗层层嵌套的🌲

日志聚合

目前我们每个环境都会有一套 Grafana Loki 日志面板来审查每个环境的日志，但我想看到所有环境的某个异常并按照服务分组，针对错误代码跳转到对应的代码位置，以及在每天早上/晚上提醒该环境的一些异常信息实现起来却有些困难，因为我们基于 Grafana Loki API 封装了一个顶层的面板，来手动/自动聚合当日所有环境的异常日志，并联合内部代码平台支持异常日志代码判断的搜索跳转；