目录
生产环境全链路性能测试体系建设之路主要包括生产测试流程规范建设、生产测试工具平台建设、生产测试实施团队建设、落地实施细则。
本文主要聊一聊生产测试工具平台建设。
一、应用管理
性能测试的数据隔离配置按照应用维度进行管理，相关功能包括应用增删改查、单应用维测试流量开启或关闭控制、应用下实例状态管理、预期数管理和测试规则版本管理。
对于实例状态，主要分为已就绪和未就绪两种。已就绪状态包括：实例生效的规则版本和最新发布版本一致且无异常情况；探针已经成功安装且应用所有实例已就绪，可以进行测试；实例自身已就绪，等待应用进入就绪状态。
未就绪状态包括：实例生效的规则版本和最新发布版本不一致，或发生异常；实例处于初始化状态，即探针启动的默认状态；测试探针正在安装中；测试探针安装成功等待下发测试配置；测试探针安装失败，需重新安装探针；由于全局错误不能再实施测试，此时需检查探针日志。
对于接收压测流量，该功能用于管理应用实例是否接收处理测试流量。若开启接收，则应用实例会处理测试流量；若关闭接收，则应用实例不会处理测试流量，此时如果发起测试请求则直接报错，并且能在应用日志中看到错误信息"不允许测试流量”。
对于预期数，它用于校验应用实例状态是否和预期一致，以便对实例状态做出判断。预期数用于评估应用是否存在漏部署的节点，避免存在漏部署节点导致生产流量数据污染。若设置预期数，而实际已就绪数与预期数不符，则无法启动对应目标的测试。
对于规则配置版本，它用于服务端和底层探针对比版本，以使测试人员确认探针上最新的配置规则是否生效。初始版本为0，发布变更或还原变更会影响实例状态校验。对于规则变更，若发布变更，系统会将最新规则同步至庭层服务，同时会生产一个递增版本号。若未发布变更，提示存在未发布变更，可点击“发布变更“按钮进行发布，或通过”还原变更“清除未发布规则。还原变更指的是还原至上一次已发布规则版本。
二、测试规则配置管理
对测试规则的管理包括对规则的添加、编辑、删除、导入/导出、启用/禁用等。其中导出/导入规则是从应用维度全量导入或导出配置规则，启用/禁用规则是针对单条数据进行操作，不影响其他规则。有规则变更成功无须重启应用，但需发布变更才能生效。
平台的规则配置主要包括影子库表、Mock规则、白名单、定时任务、消息配置、影子日志、实例监控等功能。
在影子库表功能中，配置影子库表服务地址，请求将转发到影子库表服务地址，否则将转发到原库表。测试流量会到影子库表，如果没有配置测试流量就会报错。
选择类型，添加数据库类型，可基于配置代码模板快速配置规则，支持批量添加多条规则，遵循JSON 5格式。
在Mock规则功能中，支持配置HTTP、DUBB0等类型的Mock规则。它用于模拟请求接口调用返回值，使测试流程继续执行，但实际不会进行外部调用。
在白名单功能中，测试人员可以看到提示“开启校验白名单，不在白名单内的请求路径和消息Topic无法调用和发送，即压测流量无法通过"，白名单主要用于在测试过程中拦截请求，只允许放行白名单中配置的请求。
白名单功能支持一次批量添加多条规则，需选择类型：HTTP、Dubbo、Kafka或RabbltMQ，可根据提供的配置代码极板进行规则配置。规则添加完成后默认是禁用状态。
在消息配置功能中，测试人员会看到提示“启用影子Topic后，实例会将发送给原Topic的消息转为影子Topic”，消息配置默认开启。
在影子日志功能中，测试人员配置测试流量产生的日志保存路径。若原目录下不存在该路径，则自动创建一个子目录；若已存在，则日志会存储在该路径中。
三、链路分析
平台具有链路分析能力，下面分别讲解平台上关于链路分析的配置项。
首先是链路查询。它支持应用、实例、服务、请求结果、耗时、返回行数和开始时间等维度查询链路。
其次是调用树。该功能可用于查看当前应用调用情况，可通过结果分析查看具体应用是否正常。
再次是调用详情。它支持查看服务名称、类型、开始时间、耗时、入参、返回、异常和日志等信息。
最后是业务统计。它包括数据库、远程调用、消息Topic这3个子项。其中，数据库展示的是通过探针的业务请求调用了哪些存储工具(如MYSQL、Redis等)及其相关配置信息。
此时，开启应用接收测试流量则展示的是影子库表信息，未开启应用接收测试流量则展示的是真实库表信息。远程调用展示了通过探针枪理的业务请求调用的接口及其相关信息。
消息Topic展示了通过探针理的业务请求调用的消息中间件(如Kaka、RocketMO等)及其相关配置信息。
相应地，开启应用接收测试流量时展示的是影子中间件信息，未开启应用接收测试流量时展示的是真实中间件信息。
四、工具平台服务化
基于公司内的项目性能测试经验，提炼生产性能测试的阶段性工作的细节，形成指南和规范，各项目组根据业务需求可申请生产测试服务支持。
对于常态化项目，做好流程规划把控，考虑可能影响项目实施的生产环境的变化因素，例如:接口变化影响测试实施，系统变化影响测试范围，系统应用组件变化造成数据污染，系统中间件变化造成测试链路变化。
从两个方向展开规划，以应对以上变化。
方向一，沉淀相关文档；
方向二，对供应商项目组提求。
具体措施方案如下:
沉淀接口文档，每次测试前做接口比对和接口模型比对，考量每次变更对测试的影响，跟项目组确认后推进测试实施；
沉淀测试系统范围，每次根据接口文档提前做系统范围确认，在前一次基础上做更新；
沉淀系统组件和中间件详情，每次根据文档做中间件和代码组件确认，做组件基线；
针对系统中间件及其他组件，希望每当有架构改变的时候同步测试项目组，项目组根据变动提前做好应对方案。
阅读后若有收获，不吝关注，分享，留言评论等操作！！！
标签：配置,测试,性能,链路,探针,实例,应用,规则 From： https://blog.csdn.net/qd_lifeng/article/details/144442554