编写维护测试用例时遇到的若干问题记录

[cosven]

概述

• 用例运行 问题比较多，挺影响效率的
• 用例实现 方面问题虽然有，但相对是可控的

用例运行

• A 想让一个用例运行 长期 在不同配置/分支的 TiDB 集群上、目前需要写上百行的 yaml 文件
  • 举个例子
    • add argo files for bank2-compaction #320 这个 PR 其实只是想修改 TiDB 集群配置，让 bank2 用例运行在不同配置的集群上，但是却需要自己编写 5 个文件，效率很低，以后维护也比较困难。
  • 期望
    • 流程更简单、更加可维护
• B feature 开关不能很好的组合
• C case 运行结果报告的 展示 与 通知

注：tipocket 虽然提供了 matrix，但它也有几个问题

1. 没有很好的实践
2. matrix 似乎是纯随机的，而现阶段确定性需求更高一点

用例实现

• Z 编写一个用例，代码和流程比较复杂

1. 编写完用例后，需要编写相应的 yaml 文件
   1. yaml 文件大部分内容是 重复 的，而且文件行数比较多，编写、review、维护 都很心累
2. 对于自调度的用例。它们也是实现 Client interface 的方式，这带来两个问题
   1. NextRequest / DumpState / Invoke / Start 等方法，代码看起来不太优雅
   2. 目前这种 Client interface 的模式，很多用例把逻辑都塞在 Start 函数里面

• 期望：
  1. 代码能够更加简洁（对于自调度的用例，能不能实现一个更简单的 client interface？）
  2. 不需要编写上百行的配置，只需要 10 来行可以搞定

• 无法在本地方便的调试用例 编写维护测试用例时遇到的若干问题记录 #321 (comment)

[youjiali1995]

确实相比之前薛定谔难用了很多，需要了解 argo 的工作流程才行～

[zhouqiang-cl]

这个我们可能得想办法如何解决，其实我们各类测试运行不是特别顺畅，从大面上来讲，存在的几个问题

1. 环境问题(资源不够)
2. 框架问题(易用性不够)
3. 自动化问题(如何自动化发现，自动化 debug)
4. case 自身问题(这个需要 R&D 开发)

今天我们在一个群里聊过，其实在保障测试持续高效的运行里面，都需要解决，投入的精力应该要不少，这块目前我们正在尝试解决。我们可能首先需要解决一些根本性上的问题，易用性和自动化

[youjiali1995]

对了。tipocket 有失败通知嘛？以前薛定谔可以发到 slack 上。

[cosven]

对了。tipocket 有失败通知嘛？以前薛定谔可以发到 slack 上。

@mahjonp
不过我理解现在的 case 都没有负责人，通知也不知道发给谁把 🤔

我把这个点补充到上面的 issue 中去，失败通知也很重要。

[mahjonp]

确实相比之前薛定谔难用了很多，需要了解 argo 的工作流程才行～

归根到底, 主要是当我们迁移完薛定谔用例后, 没有人力和精力进行持续的改进(包括 UI 等都需要投入一定的精力), 使用 argo 是为了能够快速运行起来, 适用于过渡的阶段, 由于缺乏构建易用性的投入, 将使用的成本转移到了使用者头上.

另外一个方面, 我们一开始将 tipocket 定位成客户端的模式, 即可以单独部署运行, 不依赖于一个平台去调度(比如薛定谔), 因此调度依赖于类似 Argo 平台进行.

除了@cosven 提到的, 还有:

• 使用 loki 进行日志归档存在各种问题.
• case 的上下线以及谁来 Owner.

这些的改进方面可能都需要保障测试持续高效的运行专项里头解决. @zhouqiang-cl @youjiali1995 @cosven

[cosven]

考虑到可投入的精力，准备先解决 A,B 两个问题。

方案：

• 人肉写脚本，自动生成 argo workflow -> A
• 修改 tipocket，让它的用例支持指定配置内容 -> B

[youjiali1995]

还有个问题，能不能跑 PR 里的 case，有时候本地能跑的合进去后发现还是有问题

[cosven]

还有个问题，能不能跑 PR 里的 case，有时候本地能跑的合进去后发现还是有问题

我觉得这也是个大问题。本地不能方便的 debug，算是用例开发的子问题。

个人前几天实现一个工具，目标是 方便的调试/运行一个用例（包含 PR 的用例代码） ，但它目前还是要求使用者对 kubectl/argo 等工具有一定了解：https://github.com/cosven/tidb-testing/tree/master/tipocket-ctl （ps：正在思考如果推广给大家试用，emmm）。

[cosven]

运行了大约 4 次 pipelined locking 用例，每次半个小时到 10 个小时不等，发现几个问题：

1. 环境不够稳定
   • K8s pod 所在物理机机器资源可能枯竭（比如内存不足），导致 TiDB 集群实例不正常（connection refused）
2. tipocket 层面的不稳定性（长时间运行用例，case 可能失败）
   

另外，这些问题，目前不是很容易排查。

[mahjonp]

修复了之前存在的 issue 里头没提到的问题，依赖冲突。#347

以后编写 case 需要将 case 本身依赖的 module 和 tipocket 测试主体框架引入的隔离开，采用类似 nested sub-modules 的方式。

目前分离工作已经完成，#347 还有一些脚手架工具和文档补齐工作。