之前看了scylla blog关于测试的介绍，这里做简要摘录。官方文章是16年写的，名称方面可能现在已有所不同。

Scylla testing part 1: Apache Cassandra compatibility testing

scylladb作为分布式的nosql数据库，为了保证可靠性和正确性，自然免不了有严格的测试。有以下几种测试类别需要覆盖：

• 本身的单元测试（处在源码tests文件夹下）
• seastar单元测试
• scylla软件包测试，用avocado
• 长期性测试，运行在aws
• cassandra的单元测试和dtest

与cassandra实现相关的test case就忽略掉，但通用的feature test如cql，仍需作用于scylla

Scylla testing part 2: Extending Jepsen for testing Scylla/

Jepsen是由Kyle Kingsbury编写的专门用于测试分布式系统正确性的测试工具

• Jepsen会运行多个task
  • controller，控制ssh登陆到每台节点，启动和停止进程；
  • database服务，本身要被测试的服务
  • generator，负责产生客户端请求包括nemissis请求；
  • checker，最后用来verify一个执行历史是否正确
• nemisis是那种可以制造坏事情的对象。它可以分裂节点集合，制造分区，干扰时钟等
• scylla版本的Jepsen测试，用到了faketime，去给同一host上的不同容器设置不同时钟；
• scylla-jepsen增加了一个后台任务loader，负责在正常测试同时对集群施加足够的压力，以验证在高负载情况下的正确性
• 对cassandra/scylla的一个简单测试需要5-10min，整个test suite需要几小时（好长啊）
• 由jepsen test发现的scylla bug

计划增加的功能：

• 目前jepsen checkers只验证数据是否能成功读到，并未考虑节点宕机后读取的问题
• schema change的测试，同时发生分区的情况
• 模拟更多的网络故障，如半关闭

scylla jepsen wiki

scylla testing part 3: CharybdeFS: a new fault-injecting filesystem for software testing

scylla团队弄了个failure injection filesystem: charybdefs，它介于scylla和real filesystem（如xfs)之间，通过以一定的概率改变实际FS的行为来测试；一个典型用例是，在scylla flush/sync时，给它发kill -9，然后在重启时检查数据是否一致。

charybdefs可以模拟的故障有：

• disk io(EIO)
• OOM(ENOMEM)
• file already exist(EEXIST)
• disk quota exceeded(EDQUOT)

另外一个使用场景是，模拟disk/filesystem slowdown。在这种情况下就会造成latency spikes
charybdefs也不仅仅是用来测试cassandra/scylla，还可测试其它存储系统如ceph

scylla testing part 4: Distributed tests

• unit-test, dtest在scylla日常测试中用得最多。也有很多bug是由dtest发现的；
• dtest和jepsen test会有些交集，但侧重点不一样，后者侧重在时钟漂移、网络分区下的测试
• dtest是在scylla项目开始时就用了，一边写basic Functionality代码，一边测; 其间还发现原生的dtest对nodetool命令的测试不是很完善，所以scylla 这边要接着写

cassandra-dtest: https://github.com/riptano/cassandra-dtest
How to Write a Dtest, by Philip Thompson

Testing part 5: Longevity testing

一个维护良好的项目应有以下测试：

1. 单元测试。测函数与类
2. 功能测试。在scylla中就用(修改过的)dtest，测试local process
3. 集成测试。在整个生命周期内测试entire stack of the program，在scylla这称为scylla-longevity-tests
4. 性能测试

此篇文章讨论longevity tests，在AWS上创建集群。典型的工作流如下：

1. 创建scylla cluster
2. 启动多个client loader，发起任意的cql op,常用cassandra-stress
3. 集群内有一个nemisis线程，随机地选项non-seed节点进行捣乱，即对集群搞点小破坏，有五种操作，都是以Monkey作为命名后缀
4. nemesis线程周期性地disrupt the cluster
5. 运行c-s. 默认的命令行如：

cassandra-stress write cl=QUORUM duration=1440m -schema 'replication(factor=3)' -mode cql3 native -rate threads=4 -node 172.31.27.192

6. nemesis会操作一台节点，remove它，再add a new one
7. 看看c-s是否能在给定的时间段内运行良好

也有相关bug是由这个过程测出来的。

repo: https://github.com/scylladb/scylla-longevity-tests (现在名称叫scylla-cluster-tests)