OceanBase是蚂蚁金服/阿里巴巴自研的金融级分布式关系数据库，每一行代码都出自OceanBase工程师之手，光内核代码行数就已经达到百万级别。通过技术创新为业务带来价值一直是OceanBase孜孜不倦的追求，OceanBase数据库本身解决了高可用、扩展性、数据一致性等问题，软件本身的复杂度不言而喻。而复杂性是软件质量的天敌，正所谓千里之堤溃于蚁穴，任何一个软件bug都有可能给客户带来巨大损失。在研发过程中OceanBase始终将质量放在首位，将质量保证贯穿于架构设计、编码、测试等每一个工程环节。
工程理念
经过多年的摸索，OceanBase团队打造了独特的工程文化。测试和开发同时进行，功能测试不再是一个独立分开的过程，而是融入到开发环节，从源端控制引入bug的概率。资深测试人员的精力主要放在难度较大的bug的发现，测试体系建设和相关技术钻研、测试自动化实施。我们建立了一套高效的代码准入流程，防范了许多初级的问题，提升了团队整体的研发效率。
高可用的架构设计
分布式
OceanBase是个分布式系统，可以容忍不同等级的故障，如单机故障、机房故障、城市故障，故障影响范围相对可控。虽然分布式架构设计非常复杂，给实现和测试的难度带来了指数级的增加，但生产环境上暴露的多数bug并不会立即影响业务，运维或研发同学会有一定的时间让集群恢复正常，借助分布式系统良好的扩展性和单机容错能力，一般都有可以规避的运维手段。
一主多备
OceanBase是一主多备模式，主备库通过redo log同步，每个库都有完整的数据。当主库出现故障，OceanBase会自动将主切到另外一个数据完整的备库，做到数据无损，服务可以在30秒左右恢复。虽然并不是所有的bug都能通过自动切主恢复，但是运维人员也可以通过强制切主、甚至杀主库进程的方法将流量切到新主，大部分生产环境的问题都可以通过这个操作快速将业务恢复。
数据自检
如果程序在运行过程中发生问题，导致了数据错误，OceanBase的checksum校验机制可以提前发现。这个机制可以帮助线下测试环境更容易的发现数据质量的问题，线下测试有80%的数据正确性问题都是通过数据库自检发现的，大大降低了生产环境出现数据不一致后的风险。redolog、不同副本、磁盘数据都有checksum校验，另外，每个节点上都存了两个版本（合并）的数据，如果最新一次合并的数据出了质量问题，集群仍然可以从上一个版本的数据中恢复。
升级对业务无感知
大型数据库软件的开发测试周期一般比较长，bug数往往是以万为单位计的，这也是为什么传统数据库厂商每隔1-2年才出一个GA版本的原因之一，但即使这样，数据库升级仍然是个风险非常高的变更，业务需要承担巨大的风险。
OceanBase诞生于互联网公司，必须具备快速迭代快速上线的能力，不可能等所有的功能和bugfix都完成后才发布上线。数据库稳定性与互联网要求的“短频快”的矛盾，除了要求数据库版本的遗留bug做到可控，本身必须具备灰度升级的能力，同时要做到业务对升级过程无感知。
OceanBase升级版本的时候一般先升级没有业务流量的备库，备库升级完成后会先将主切到原备库，验证业务正常,新版本的质量满足期望，才会继续升级下1个库，全部升级完成后将主切回主库，如果升级过程中发现新版本有严重的质量问题，升级会暂停，问题解决后升级流程才会继续。升级过程中的主动改选对业务是无损的，业务无感知，升级带来的风险可控。
其他
除了上面这些，OceanBase的很多设计都有质量控制方面的考量，比如为了避免升级新版本后优化器性能退化，plan有灰度生效的机制；按zone（副本）来灰度启用新特性；流量回放等等。
严格管控代码质量
“严苛”的编码规范
OceanBase团队执行“严苛”的编码规范，并且随着产品的发展不断的在修订,如严格遵守函数单入口单出口、每个函数必须检查输入参数的合法性、不允许coredump和主动退出、所有函数都要用ret返回错误码等等。OceanBase的编码规范长达几十页，为了提升代码审查的效率，OceanBase借助代码检查软件coverity，定期扫描代码发现潜在风险。
Testing as a Service
为了让开发人员专注代码本身，避免在测试执行上花费太多时间，OceanBase团队建立了高效轻便的TaaS（即Testing-as-a-Service）平台，操作都在本机用快捷命令完成。大部分日常回归的测试场景都可以自助完成，测试需要的机器、回归测试用例、工具等对开发人员透明。
测试准入
obfarm（测试农场）是OceanBase TasS平台提供的代码准入测试，是特定测试用例的集合，包括SQL功能、分布式功能、版本间兼容性等等，任何一次代码提交都会有相应的obfarm测试数据，通过obfarm的测试用例是代码提交的最低要求，不同模块也可以根据修改的影响面增加其他测试内容。
测试防守
OceanBase测试分为功能测试和系统测试两大类。
功能测试
OceanBase是一套功能完备的关系数据库，功能点非常多。在进入系统测试阶段之前，我们已经做了大量的单元和功能测试。按照测试点划分，功能测试可以分为两大类，一类是外部功能，属于最终客户可以看到的功能，如SQL功能，测试需要使用多种连接器验证数据库功能，开源数据库的测试用例可以为我所用;另外一类是内部功能，如每日合并，日志同步等等，需要自己构造测试场景，测试相对比较复杂。如果按照测试方法分，可以写测试用例做有针对性的测试，也可以用工具做随机测试。前者需要脑洞大开进行系统的测试分析，将测试用例用特定的语言（可以是自定义的语法）实现出来，工作量比较大，而随机测试虽然也需要做测试分析，但是主要是用工具达到测试目的，测试有一定随机性，是对测试用例的补充。OceanBase引入和自主开发了很多这样的测试框架和工具，积累了成千上万的测试用例。
系统测试
系统测试分为兼容性测试、异常测试、正确性压测、性能压测、业务仿真等等。
兼容性测试：如上文所述，OceanBase升级可以做到灰度，可以跨版本。这就要求OceanBase不同版本之间互相兼容，对于分布式系统来说是个比较大的挑战,涉及schema、RPC协议、执行计划、日志或数据格式等等，每个新功能都需要将兼容性作为功能开发的一部分，也给测试增加了变量。
异常测试：容灾能力是分布式系统的基本功能，用于异常处理的代码行数占了很多大的比重，简单的功能测试基本上覆盖不到。容灾能力涉及功能模块比较多，所以我们把它也归到系统测试。分布式系统的异常测试，包括网络分区、网络抖动、磁盘异常、程序退出、机器掉电等等。分布式系统状态复杂，组合是爆炸式的，很多bug并不会直接导致进程crash，或者是集群状态紊乱，需要测试人员对系统非常了解。测试需要系统7*24h运行、数据规模达到一定级别，随机注入异常(开源工具有fiu、Jepsen、Simian Army等等)，各种状态组合才能将bug暴露出来。异常测试往往要跟稳定性压测、正确性压测同时进行。
正确性压测：数据的一致性测试我们内部称之为正确性测试，这种bug虽然占比不高，但是破坏性如洪水猛兽。分布式系统正确性的验证有用数学语言描述系统的状态和时序的，如TLA+，也有用Jepsen，并发读写多个数据节点，注入错误，验证最终数据的一致性。生产环境上系统的运行情况远比这个复杂。从发现BUG（不是为了证明软件正确）的角度出发，我们为OceanBase设计了一套可以做正确性验证的数据模型。经过这么多年的磨合，模型变得日益复杂，可以覆盖并发事务（只读、长事务、锁冲突等等维度）、主备切换（主动、被动）、系统恢复等等生产环境可能碰到的情况，事务的ACID特性都能得到验证。这个工具自问世以来一直是发现高质量bug的利器，为版本质量立下了汗马功劳。同时，后面提到的业务建模也会对测试数据设计规则，确保测试万无一失。
业务仿真：作为一款通用的分布式关系数据库，不同类型的业务对数据库的需求是不一样的，光从部署方式上就可以分为1地3中心、2地3中心、3地5中心、读写库分离等等，在业务大促的时候，各种弹出弹回方案眼花缭乱，这些能力都是数据库产品本身要具备的。所以业务模拟是我们测试的重要组成部分，从业务特征（流水或者状态）、灾备要求 、稳定性要求、性能容量等方面进行覆盖，为支撑业务大促(如双11)保驾护航。
除了这些，探索性测试也是我们常使用的方法之一，产品和业务需求变化的非常快，质量风险也在变化，通过不断调整测试策略，保持快速学习能力，通过对系统全局的理解发现系统隐藏的风险。最终将这些发现沉淀为可以自动化的测试用例或工具。
OceanBase有测试机器数百台，它们7*24小时在运行每一个测试任务，跟所有OceanBase同学一起稳扎稳打，努力为客户提供高质量的产品和服务。
本文转载自公众号：oceanbase
新书推荐：《深入分布式缓存》
联系客服
