有没有20届毕业的小伙伴呀~TiDB 的“破坏之王”需要你！

我们在做什么？

我们测试团队是 TiDB 的“破坏者”，用各种手段尽早发现系统的 bug 是我们的工作。TiDB 有丰富的产品线，在这些产品线中，我们面对着不同的挑战。

首先，TiDB 内核稳定是整个系统稳定的基础和重中之重。TiDB 新版本的内核仍然处于高速发展的阶段。因此，测试要尽早发现新特性的正确性和稳定性问题，包括但不限于：

• 对 TiFlash 列存引擎，测试要构造破坏一致性保证的情况；

• 在 3.0 中，TiDB 增加了悲观事务，并支持了 RC 隔离级别。在 4.0 中，TiDB 支持了大事务，优化了 GC 的性能。这些特性的重要性不言而喻，必须进行严苛的、长时间的性能测试和稳定性测试；

• 挑战不断优化的 SQL 优化器和执行引擎，确保功能增强后的系统正确性和性能。例如 Index Merge、SQL Hint 和 SQL Plan Management 等特性；

• 验证调度稳定性的特性，例如 4.0 中的新热点调度器，构建不同的接近真实场景的负载，找出在这些负载下的系统不稳定的情况；

• TiKV 的稳定性是内核稳定性的基础，在保证 Raft 层优化性能的前提下，尽早发现稳定性隐患是我们的职责。

其次，TiDB 还具备一个强大的生态工具系统。TiCDC、BR、TiDB Binlog 等产品都需要为用户提供长时间稳定的服务，且不能影响线上业务。我们在测试时要想方设法用各种极限情况去“破坏”这些工具的服务质量，从而为产品研发提供改进和优化的方向。

此外，作为云原生的数据库， TiDB 在云环境的复杂性是开发团队和测试团队共同面临的挑战，测试需要不断模拟云环境常见的错误来发现 TiDB Operator 和 DBaas 的错误。

上述每一项任务拿出来都是巨大的挑战。为了应对这些挑战，我们需要尽可能的理解代码，真正的做到“既见森林，也见树木”，高效地发现问题。

除了深入钻研 TiDB 本身的代码，尽可能了解产品实现细节以提高测试质量，我们还在学习和研究不同的测试方法，为团队打造更多的武器。面对以下疑问，我们已经有了比较成熟的测试方案和工具，并在持续优化中：

• SQL 语法空间无穷大，如何用模糊测试（Fuzz Test）遍历更多的测试空间？

• Failover 是分布式系统最大特性，如何用混沌工程（Chaos Enginnering）攻击 TiDB Failover 的能力（我们已经开发并开源了 Chaos Mesh™）？

• 如何用 FailPoint 高效模拟错误，提升事务等大量错误处理模块的测试效率？

• 如何高效使用和扩展 Jepsen 等正确性验证工具？

• 如何用 TLA+ 证明系统设计的正确性？

如果你这些问题的答案非常好奇，或者有自己独到的见解，欢迎加入我们一起折腾！

我们还在做什么？

除了测试产品特性，我们还在不断完善测试的基础设施，不断提升“攻击 TiDB”的效率。

我们正在完善一套快速进化的高度自动化测试生态。高度自动化意味着：

• 自动执行数千万级的测试用例；

• 自动报 bug，并保留环境；

• 自动输出结果和质量报告。

我们打造了一组添加测试用例非常简单、功能却非常强大的自动化测试框架，提升写测试用例的效率。你甚至只需要写 SQL 就能自动生成测试用例。这个测试框架还提供了测试用例的编排能力，无论你是想要串行、并行、还是串并行，都可以满足你的需求。这提升了用例执行效率，简化了重复用例的管理成本。到这里就结束了么？不，并没有，随着产品的演化，这个框架也需要不断的进化。我们期待屏幕前的你带来更多的有趣的想法，并和我们一起将想法实现。

随着测试用例的爆炸式增长，我们需要更多的 TiDB 资源以并行的方式执行数千万级的测试用例。我们打造了一个「资源池服务」，可以从 K8s 集群中快速生成不同拓扑、不同配置的 TiDB 资源。在测试团队，你会了解到关于基础设施的许多细节，会面临大规模系统的管理挑战，各种复杂系统的痛点都需要你来解决。

我们也正在解决长稳测试、升级测试、长链路测试的自动化问题。随着这套基础设施的不断完善，测试团队可以节省大量人力，把更多的精力投入到研究新的测试方法和开发新的测试武器中去。

写在最后

我们测试团队（QA Team）是一个“小而精”的团队。如果你看到了这篇文章，又恰好具备以下特质：

• 希望接受数据库测试的挑战；

• 快速的学习能力；

• 强大的动手能力，热爱开发工具提升工作效率；

• 对混沌工程、模糊测试等领域有浓厚兴趣。

那么，欢迎上船，体验这「上可览全貌，下可享细节」的“破坏之王”的快乐吧。