测试管理 小红书自动化框架 hydra 的升级之道 -- 用 DisConf 解决代码和配置分离

ymsun · 发布于 2017年07月10日 · 最后由 gxdprivate 回复于 2017年07月12日 · 1186 次阅读
本帖已被设为精华帖!

小红书自动化框架hydra的升级之道 -- 用DisConf解决代码和配置分离

使用背景

在一个分布式环境中,同类型的服务往往会部署很多实例。这些实例使用了同一套配置,为了更好地维护这些配置就产生了配置管理服务。通过配置管理可以解决分布式环境下多台服务实例的配置统一管理问题。

目前我们使用的测试框架中包含配置文件与配置信息,所带来的问题是很容易导致敏感信息泄露。同时对于测试框架应用的不同环境,配置信息也会需要做相应的修改,所以需要有个中间层来屏蔽这个区别。在调研现有的开源配置管理平台后决定试点disconf将部分业务的配置文件和配置信息从代码中剥离。通过disconf来方便管理多个服务实例的配置,也可以针对不同的环境设置不同的配置文件。

简介

1、Disconf是百度开源的分布式配置管理平台(Distributed Configuration Management Platform),可以为各种业务平台提供统一的配置管理服务。

特点:

  • 支持配置项+配置文件的分布式化管理
  • 配置发布统一化:同一份配置文件可在多个环境中使用、提供统一的平台管理
  • 极简的使用方式(注解式编程 或 XML代码无代码侵入模式)
  • 模块划分:disconf-core/disconf-client/disconf-tool/disconf-web

2、测试框架hydra介绍:我们的测试框架分为两个部分:框架hydra+测试用例hydra_case(设计框架见下图)。测试脚本用javascript编写,框架用java实现。通过nashorn引擎做到测试框架与测试用例分离,运行测试用例时只需调用框架封装好的第三方库即可(将第三方库上传远端,运行case时自动拉取最新的库)。通过testlink绑定对应的测试用例,执行测试用例后生成测试结果直接上传redmine。其中测试用例所需的接口url等数据文件与框架所需的配置文件都存储在disconf配置管理平台,运行case时会自动获取。我们的框架底层也集成了各种测试服务包,包括webdriver、appium、restful等。

当然,未使用disconf前配置文件与数据文件是直接写在框架与测试用例文件中的。

结合disconf使用

disconf具体的安装步骤在作者的github和文档中写的很清楚了,这里不再重复

github地址

文档地址

安装依赖软件:Mysql、Tomcat、Nginx、Zookeeper、Redis。

使用:为了client能使用disconf中配置文件,通过研究发现需要强依赖java的Spring框架,依靠注解的方式获取disconf远端存储的配置文件。然而我们现有的测试框架中未使用spring,再结合dev使用的是python,如果强制引入spring的话代价有点大。好在通过disconf作者给出的文档和查看源代码发现disconf可以对配置进行持久化管理并对外提供restful接口。通过调用部分接口并对返回result进行解析很容易就可以获取到disconf上的配置文件或者配置项信息 (此处我们对配置文件和数据文件分别作了解析:如properties和json)。当然调试过程中也遇到一些问题,比如调用配置列表接口发现还需要登录认证。好在作者也提供了登录api,只要调用登录接口记住cookie即可。

挑选1个api做解释:

/api/web/config/list:

  • 描述:根据app, env , version 获取所有的 配置列表,含有machine size, machine list,error num 等信息

  • 请求类型: GET

  • 参数

# name desc 是否必要
1 appId app
2 envId 环境
3 version 版本

返回示例:

{

    "message": {},
    "sessionId": "10df60bc-adfg-dggrg77159929",
    "success": "true",
    "page": {
        "result": [
            {
                "configId": 152,
                "appName": "app_test",
                "appId": 1,
                "version": "0.0.1",
                "envId": 2,
                "envName": "qa",
                "type": "配置文件",
                "typeId": 0,
                "key": "test.properties",
                "value": "auto=bbdxxjdccdcccdxdcdc\nauto2=cd",
                "createTime": "20170703170620",
                "modifyTime": "201707031706",
                "machineSize": 0,
                "machineList": null,
                "errorNum": 0
            },
            "pageNo": null,
            "pageSize": null,
            "orderBy": "name",
            "totalCount": 1,
            "footResult": null,
            "order": "asc"
        }
    }

/api/account/signin:

  • 描述:登录

  • 请求类型: POST

  • 参数

# name desc 是否必要
1 name 用户名
2 password 密码
3 remember 是否记住自己
  • 返回示例:

失败示例:

{

    "sessionId": "5b9270-7149-4c55-af96-3bf60741b",
    "message": {
        "field": {
            "password": "密码不正确"
        }
    },
    "success": "false",
    "status": 2000
}

成功示例

{

    "message": {},
    "sessionId": "029efac2d-fec1-40c7-b0d2-8433fb8a8c2c76",
    "success": "true",
    "result": {
        "visitor": {
            "id": 6,
            "name": "admin",
            "role": null
        }
    }
}

创建/获取单个配置项、配置文件等也都可以通过api接口实现,即使想对disconf-web进行改造和接口封装也是比较容易实现的。为了结合disconf作为我们测试框架的配置管理中心,我们不仅支持了java版本的配置文件解析,python版本的接口实现之后也会支持方便更多的服务使用disconf。

使用总结

以上是我们测试框架与disconf结合使用的简单介绍。

使用disconf存储配置信息带来的好处是1、可以做到敏感信息与代码分离,而使用api方式接入获取配置信息简单方便不需要引入任何额外的依赖。2、解决了测试用例部署到不同环境运行时配置文件的不同问题(无需在代码中对不同环境分别写入各自的配置信息)。3、变更配置或者测试数据只需平台操作即可,无需更改代码。

暂时由于api的获取配置方式,我们还没有做到支持依赖zk获得实时更新配置信息的推送。这也是接下来我们需要去做的事情~

共收到 3 条回复
605

这个思路很赞,由配置中心搞定环境配置问题,这样配置项就不用分散到各个项目维护了。

605 chenhengjie123 将本帖设为了精华贴 07月10日 22:32
12169

我感觉这个思路不仅可以管理用例调度,也可以用于测试,生产环境的管理。

需要 登录 后方可回复, 如果你还没有账号请点击这里 注册