后台自动化测试与持续部署实践 https://mp.weixin.qq.com/s/lqwGUCKZM0AvEw_xh-7BDA

后台自动化测试与持续部署实践

原创 腾讯程序员 腾讯技术工程 2022-04-18 17:16

4) 接入全链路追踪系统

状态码和状态消息是面向客户的，拿着它们去找失败点可能会定位精度不足。全链路追踪非常有价值，任何现代的后端系统都应该接入一套 OpenTelemetry 的实现，使用 OpenTelemetry 的好处是其协议具有通用性，可以很好地被各种工具支持。每一个严肃的业务开发都有必要了解这一块的知识，当你需要排查一个线上问题而无从下手时就会深有体会。

腾讯内部天机阁工具可以作为 OpenTelemetry 的后端，我们将所有的服务接入了天机阁。接入全链路追踪后，在接口测试和端到端测试时，使用统一的格式将 Trace ID 打印到 test log 中，一旦测试失败，就可以拿着 Trace ID 去快速定位失败点。

1.2.2. 提升可理解性

可理解性是指被测系统的信息获取是否容易，信息本身是否完备，并且易于理解。比如被测对象是否有说明文档，并且文档本身可读性以及及时性都有保证。常见的可理解性包含以下这些方面：

• 提供用户文档（使用手册等）、工程师文档（设计文档等）、程序资源（源代码、代码注释等）以及质量信息（测试报告等）


• 文档、流程、代码、注释、提示信息易于理解


• 被测对象是否有单一且清楚定义的任务，体现出关注点分离


• 被测对象的行为是否可以进行具有确定性的推导与预测


• 被测对象的设计模式能够被很好地理解，并且遵循行业通用规范


• …

我们在可理解性上的实践目前并不多，后面有更多经验时再进行分享。

1.2.3. 提升可控制性

可控制性是指能否容易地控制程序的行为、输入和输出，是否可以将被测系统的状态控制到测试条件的要求。一般来讲，可控制性好的系统一定更容易被测试，也更容易实现自动化测试。可控制性一般体现在以下各个方面：

• 在业务层面，业务流程和业务场景应该易分解，尽可能实现分段控制与验证。对于复杂的业务流程需合理设定分解点，在测试时能够对其进行分解。


• 在架构层面，应采用模块化设计，各模块之间支持独立部署与测试，具有良好的可隔离性，便于构造 Mock 环境来模拟依赖。


• 在数据层面，测试数据也需要可控制性，能够低成本构建多样性的测试数据，以满足不同测试场景的要求。


• 在技术实现层面，可控制性的实现手段涉及很多方面，比如提供适当的手段在系统外部直接或间接的控制系统的状态及变量、在系统外部实现方便的接口调用、私有函数以及内部变量的外部访问能力、运行时的可注入能力、轻量级的插桩能力、使用 AOP（Aspect Oriented Programming）、trpc-filter(trpc 服务的插件特性)等实现更好的可控制性等。

为了提升中间件的可隔离性及更好的构建测试数据，我们对中间件做了下述几项治理工作：

1) 统一使用名字服务进行寻址

微服务架构下，如果还是使用固定的 ip:port 访问中间件，将难以灵活应对中间件扩缩容，也很难使用集群式管理。因此，寻址方式应该统一使用名字服务，统一通过 namespace+env 方式进行寻址，无需再为各个环境单独配置 ip:port。

以 db 为例，目前 db 可支持通过域名或名字服务寻址：

a. 通过域名寻址，需要为 Production 和 Development 分别配置不同的域名，如下面的 tap1.com 和 tap2.com;

b. 通过名字服务寻址，不同环境用同一个名字 tap.db，再通过 namespace/env 到北极星(腾讯内部的统一服务发现和治理平台)寻址不同环境的地址，即可访问；

运行结束后自动显示测试报告：

通过持续优化秒级监控发现的问题，我们将系统的稳定性提升到 99.99% 以上并能够一直保持。

3.1.2. 提升测试稳定性

单元测试的稳定性提升方式，主要有：

• 避免使用 sleep


• 减少 mock 的使用


• 不要在用例中修改或依赖系统环境，如时钟


• 不使用随机数作为输入


• 单测中不能访问数据库、网络，不要跨进程调用


• ……

接口测试的稳定性提升方式，主要有：

• 下游服务及外部 http 依赖，尽量使用 mock


• 依赖的数据，应该在 setup 时初始化，不要依赖库中现有的数据


• 对测试数据的修改，测试结束后需要还原


• 运行时使用独立的隔离测试环境，避免冲突


• ……

接口测试和端到端测试实践的过程中，我们经常会遇到不稳定的用例（ Flaky Test ）：相同的测试用例，有时测试通过，有时又测试不通过。这样的测试用例可以理解为是不稳定、可靠度低的测试用例。造成用例不稳定的原因有很多种，比如测试代码本身的问题、测试框架的问题、被测系统及其依赖的软件库的问题等。如果有很多这种测试用例，我们将会对测试失去信心。

在 LogReplay 项目的自动化实践中，我们使用 TestOne Flakiness 缓解方案提升端到端测试可靠性的运行方案：监控并记录测试用例的可靠性数值（flakiness 值），如果达到某个阈值，则认为这个用例不可靠，并自动移除该测试用例（不在关键路径中运行、或测试结果不作为关键路径是否成功的标志）。如下图所示：

当然，我们的微服务中，不止有代码变更，还有配置、数据库等变更，接下来我们也需要继续探索并实现配置、数据库等变更的持续、自动化部署。

不同类型的业务场景和需求差别较大，自动化测试与持续部署的方式及思路也不尽相同，本文只是我们的“一家之言”，并不一定适用于其他的业务场景。但，我们追求的目标，应该是类似的，都是希望能“质量更高”、“速度更快”，而实现这两个目标，都离不开自动化测试、自动化部署。回到本文的标题，希望有越来越多的业务一起探索实践、及分享后台自动化测试与持续部署实践，也随时欢迎一起交流。

用到的测试工具：

文中描述的工具绝大部分皆为腾讯内部自研产品。

TestOne : 腾讯自主研发的一站式测试平台， 能给用户一站式浸入式的测试体验。

术语：

1. CI: 持续集成（Continuous Integration）


2. CD: 持续部署（Continuous Deployment）


3. mockserver : 实现 mock 功能的服务，可以对服务进行 mock


4. Sandbox/Test/Staging/Canary/Production 环境：沙箱测试环境，基线测试环境，预发布环境，金丝雀环境，正式环境，统称为线上环境


5. Flaky Test : 片状测试，不稳定测试，是一种具有不确定性结果的测试：对于相同的代码，运行相同的测试，它有时会通过，而有时会失败。