Python微信订餐小程序课程视频
https://edu.csdn.net/course/detail/36074
Python实战量化交易理财系统
https://edu.csdn.net/course/detail/35475
微信搜索【大奇测试开】，关注这个坚持分享测试开发干货的家伙。
继上次 《谈谈最近做的一个自动化平台》?一个多月的时间里，这个平台又有了不少迭代功能，就再来谈一谈。
迭代功能
从大的需求方面有两处一个是?Dashboard，这块主要是团队负责人比较关注的层面，他（她）们需要看一些度量信息和趋势变化。
[迭代图1]包含两份数据，
- 平台的概览数据：其中包括绑定的项目数，平台调度执行数（包含手动触发和定时触发），还有近一个月的累计数和通过率。
- 日构建成功率：仪表盘查看项目当然执行和通过率情况，其中展示了当天多次运行的次数，最高（左），最低（右），平局（仪表盘）
这里的仪表盘采用了红黄绿灯，目前根据项目定的通用条件是，绿灯>＝95%，黄灯>70%，红灯<＝70%
[迭代图2]趋势图表示30天内每日平均通过率，主要看某个项目通过率是否稳定，是否有某个点的异常情况，以及可以对比出哪个团队自动化做的比较好。图中因为项目多，目前各个团队自身脚本不稳定+多套微服务的测试环境不稳定因素导致了线乱，随着各方面的稳定，理想的趋势线应该是围绕90%～100%区域呈现。
[迭代图3]对应上边趋势图，使用堆叠柱状图展示当天执行测试业务的自动化用例数量（去重）以及累计数量，在全量定时全部配置的情况下，反应当天覆盖率，以及自动化CASE的增长变化。
画重点，上边这些图表最终使用的是G2Plot组件，官方的描述是开箱即用、易于配置、具有良好视觉和交互体验的通用统计图表库。一开始我调研的其实是ECharts，但从原始数据结构简单性上来说确前者更容易上手，这两个组建库的使用方式我也将在《提测平台》系列的最后一节报表实现中具体讲讲。
另一需求是?快捷操作功能，这块主要来自测试同学的较多的反馈需求，之前的进入代码管理执行计划，入口稍微有点深，在快速执行和推动研发自测执行的时候不方便，所以增加一个集快速选择执行和合并状态展示功能。
[迭代图4]新增我的快捷管理，在头部选择项目、计划、环境便可立即执行，并支持收藏项目优先展示和快速进入项目管理，执行历史将汇集任务&报告集合在一起进行展示和功能操作，这项功能大大提高了使用率和组外的推广效果。
[迭代图5]展示是在原有每日定时基础上增加了Cron自定义定时，另外这块定时任务后端实现也从python apscheduler 迁移到了xxljob，开源XXL-JOB是一个分布式任务调度平台，源代码是两个JAVA工程项目，部署容易可以二次开发，这个找个时间可以写个教程分享出来，提前了解可参考官网https://www.xuxueli.com/。
迭代的内容只挑选几个变动比较大地方，其他交互优化/BUG修复/小需求就不在这里讨论了。
平台打通
团队内部用例平台上有个转测单功能，主要是做测试流程管理和质量的卡点，其中对于某个需求可以设置在状态转变的时候触发自动化测试，然后收到自动化测试平台的执行完的回调结果，根据通过率决定卡点过不过，比如研发提测通过率大于95%才可以进入下一阶段，否则直接通知打回，这是其中一个平台打通功能。
到这里以为就结束了吗？不不不，每天10个小时的高效不会只产出这些的，还有个年后的计划被提前的并行开发的大需求在周期内完成了…
单接口测试
类Postman界面化的单接口web，团队维度接口和用例数据共享，目的还是根据公司内部和业务特性降低接口自动化门槛和统一框架与流程，为什么平台一开始就上这个功能，原因在第一篇的有提到过，就是快速将已有分散的自动化统一起来，引导大家平台使用，再有一定依赖度和更多的需求下，推出这个更易用版的界面化配置功能更容易切换，其实简单的说更容易让平台的得到推广和使用起来，看一看多少公司很多类似平台除了为了完成KPI和晋级PPT，易用性、实用性、推广性有多难做。
[单接口图1]展示了核心的页面架构，需求设计和实现上主要参考了现在个人认为比较不错的一个可协同ApiFox平台，参考就了参考了不避讳，官方的定位?Apifox = Postman + Swagger + Mock + JMeter，相比Postman和Yapi平台确实是一个服务端做接口管理的不错软件工具，感谢这么好的一个工具，想体验的可以直达官方https://www.apifox.cn/?了解详情。由于是第一个内部测试板，功能没有上太多，主要是Http接口陪着和CASE管理的基础功能，以及一种Json格式的校验能力，展示上已树的形式全部展示，便于操快捷操作，这也是重点参考ApiFox的地方。
[单接口图2]是环境管理，这个根据一个业务团队有多个微服务的特点是支持了一套环境下支持多个HOST配置，同时是支持部署平台内Docker服务ID的直接调用。
[单接口图3]演示的是个POST接口用例请求，有请求参数和返回参数+配置的断言结果，内部基本除了Dubble就是标准HTTP的GET/POST请求，所以优先上的此功能。
[单接口图4]配套的用例集管理，主要是创建测试计划进行测试执行。
[单接口图5]和上边迭代中的快捷操作页面类似，是集任务调度，报告汇总和快捷执行为一体的“执行报告”管理页面，目前还只是作为状态展示和查询的一个简单页面。
[单接口图6]报告部分结果保存与自动化的报告使用的是一个总表，详细表是两表，但展现形式上差不多，所以页面采用的是一个样式，包括飞书的消息通知都是一套，只是在个别字段和逻辑处理上加了兼容性。对于单口测试还只是个初版，这部分也画个重点，前端很多是要定制化所以页面实现是由组内前端同学共同开发而成的，后端技术上，请求逻辑断言等处理是利用Python requests库、eval函数和jsonpath库实现了核心逻辑。
随着迭代这部分功能应该也会越来丰富，但绝不是重复造轮子再写个WEB版的Postman，而是打造一个符合质量团队需求，适应业务形态的提升测试质量的效率平台，后续规划上短期和长期会有如下一些打算：
- 增加Dubble的请求
- 全局/自定义变量定义
- 前置处理/后置处理
- 数据库的配置和使用
- 内置和自定义预处理脚本
- 用例管理支持场景化配置即上下文
- 更多http格式请求&返回处理
- 更多断言的方式的处理
- 高级脚本功能支持
- …
关于后续更多进展和分享欢迎持续关注公众号或博客。