静态代码检查方面 ， 我们使用业界通用的sonarqube ， 但我们的特色点是代码push的时候它会自动执行 ， 然后消息反馈 。 同时我们有增量跟全量的报告 。 我们有很多历史在的基础上 ， 如果你要求它去全量的解决问题 ， 这在业务非常繁忙的时候是不现实的 ， 所以我们做了增量 ， 只去检查当前这次变更引入的问题 ， 只要解决了这些问题并能够保证不新增 ， 后续再去慢慢地解决全量问题 。

接口自动化方面 ， 接口自动化这里我讲的是灭霸即接口回归问题 ， 接口自动化大家最头疼的就是要自己去写case ， 业务变动又比较频繁 。 我们的时间点是怎么做的？我们会基于检查点的case自动生成补全清理 。 例如航司 ， 航空公司是有很多公司的 ， 比如说南航、国航、川航等 ， 相当于每一个航空公司对应一个业务 ， 我可能就要对这一个类型去进行验证 ， 所以我们需要用户先定义一个检查点维度 ， 然后业务在线上执行的时候 ， 会去生成日志 ， 我们通过日志去采集这些具体的case ， 再生成补全 。 当过了一段时间 ， 如果检查点没有这种业务的case请求了 ， 我们就可以自动清理 ， 这就解决了我们人工维护case的一个痛点 。

代码覆盖率是基于Jacoco实现的 ， 也是增量跟全量的一个报告 ， 可以看这次变更的一个覆盖率情况 。

上述是多种手段 ， 下面看一下我们的测试环境 。

文章图片

我们对环境的定义是什么？这个环境肯定不是单应用的环境 ， 这种单应用的环境是对于整个业务的测试 ， 它起到的作用是非常薄弱的 。 所以我们对环境的定义是支持一种业务测试 ， 能支持一种业务测试的应用去依赖以及它所用的资源的一个组合 。 所以我们环境的组成就包括AppCode、数据存储、中间件、网络配置、环境变量等 。
环境有了 ， 但是不可能每次进行一个业务测试或项目测试的时候 ， 都去重新搭建一套环境 ， 这样成本是非常高的 。 我们之前去做项目复盘时 ， 对于delay项目大家吐槽最多的是为什么delay？是因为环境问题 。 所以我们把环境的这些信息做成了模板可配置 ， 这样就实现了资源与信息的积累沉淀 。
其次是业务巡检 。 开发同学、测试同学只是去使用提供的环境 ， 服务提供方要保证可用性 ， 让开发同学只是去用它 ， 而不是再去为它的可靠性分担精力 ， 所以我们有业务巡检 。
我们之前创建一套环境后就实现了完全的资源隔离 ， 相当于有一套环境给全部的应用分配资源 ， 这是对于资源的极大浪费 ， 同时创建速度也很低 ， 所以我们又做了一个软路由环境 ， 基准环境跟项目环境 。
下面我们通过下图来详细解说 。

文章图片

• 首先是环境创建的流程 ， 上图中我们可以看到我们包含了环境 ， 即应用及其依赖 ， 所以我们会先锁定资源 ， 包括Kvm、 DB这些东西 ， 然后再进行采集编排 ， 然后去触发任务执行 ， 调度执行 。
• 其次是业务巡检 ， 我们会定期去调用业务线提供的一些全链路测试case ， 定期去执行 ， 验证这个环境的可靠性 。 同时我们也会去消费一些变更消息 ， 包括配置变更、代码变更、数据变更 ， 去同步这个环境 ， 这样就保证了我们基础环境的自运维 。
• 然后是软路由 ， 我们会有一套基准环境 ， 是全链路的 ， 包含了全部的应用 ， 但是对于项目来说 ， 只需要建环境值 ， 包含自己变更的这些应用以及它的一些DB依赖 。 在真正业务测试的时候 ， 从网关进来 ， 如果在软路由 ， 即自己这个项目环境里边有 ， 我就会走到自己项目环境 ， 如果没有就会请求到基准环境 。 从这个层面来看 ， 项目对应的环境它只包含自己本次变革的应用 ， 对资源的节约是非常大的 。 同时因为应用少了 ， 我们创建的速度也提升了 ， 这样就会保证在我们的测试过程跟开发过程中 ， 环境不会成为瓶颈了 。
  • 上一页
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 下一页

  特别声明：本站内容均来自网友提供或互联网，仅供参考，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系，我们将在24小时内删除。