【巨杉数据库SequoiaDB】巨杉数据库无人值守智能自动化测试实践

刚刚过去的春节,新型冠状病毒疫情突如其来地横扫大江南北。为了响应国家号召,许多软件公司和互联网公司也将在较长一段时间内建议员工采取远程办公的方式,同时也存在骨干工程师无法及时返岗的问题,使得生产力大受影响。

对于软件企业来说,研发与测试是两大核心命脉。研发团队保障着产品新功能新特性的及时发布,而测试团队则如同马的缰绳,确保产品不会由于迭代速度过快、设计考虑角度不周,而导致软件缺陷的产生。

巨杉数据库在9年的自研和技术创新历程中,在研发体系构建、自动化测试、团队线上线下结合等方面积累了很多经验。从2011年团队成立之初开始,巨杉数据库的整个技术研发体系就以面向流程协作的方式进行构建。其核心思想是,任何员工可以在任何地点,只要遵循正确的流程,就可以与整个团队有机地衔接在一起。

在这个非常时刻,为了帮助在远程办公期间内保质保量完成新版本的迭代与测试工作,我们也将我们自己的一些经验分享给大家,主要介绍巨杉如何在无人值守的环境下,完成产品的自动化测试与研发协作。

基础体系

网络基础设施

我们的整个开发环境分为内外网两大网络,其中外部网络可以连接到广域网Internet,而内部网络则没有广域网连接。外网包括办公室中每个员工的台式机,以及可供员工进行远程连接的***服务器与防火墙。工程师们无论使用办公室的电脑,还是通过配发的笔记本电脑从远程通过***接入,均连入公司的外网网段。

公司的外网网段与内网则只能通过虚拟桌面连接,任何员工的办公室电脑或通过***连入的笔记本电脑,均无法直接访问内网环境中的开发与测试服务器。通过使用Remote Desktop等远程连接软件,我们工程师的电脑连接到虚拟桌面服务器后,所有的文档、代码、测试用例的编写均在虚拟桌面服务器中完成。同时,虚拟桌面可以直接通过SSH连接内网的开发与测试服务器,可以进行代码的编译、提交、测试等所有操作。

?

通过这种机制,任何工程师可以在任何时间地点,使用任何笔记本或台式机即可接入自己的虚拟桌面,大家所有的文档、代码、资料均统一存储在个人的虚拟桌面中。例如对于长时间的编译任务来说,就算是编译到一半需要换个工作环境,大家只需要合上笔记本电脑,回到家中打开并连上***,就可以看到自己的远程桌面上编译的结果了。

在巨杉的内部网络,则主要分为管理集群、开发集群、以及测试集群三大网段。

管理集群

管理集群主要包括Jira流程管理、Confluence内容管理、Gitlab代码管理、以及我们内部自研的资源管理等几大服务。

其中Jira流程管理作为研发与测试的主要协作流程,任何测试团队发现的潜在bug会在内部Jira上提单,并分配给对应模块的开发负责人。研发工程师接收到测试提交的问题单后,会进行问题重现与编码修复。

任何代码的修改需要在研发内部进行code review,同时当开发人员编写的代码完全通过测试后,则进行代码merge操作。不论是code review还是merge,我们均基于Gitlab进行代码的流程管控。

?

我们全部的正式设计文档均在Gitlab中保存,而研发与测试人员自己的一些经验分享则会上传到Confluence内容管理系统中,前线实施工程师与所有的后方研发测试人员均可以访问Confluence系统中的文档。

?

当前我们内网的服务器总数,虚拟机与物理机加起来近千台。因此如何协调管理分配这些计算和测试资源,也是非常复杂的事情。一些测试用例可能需要几十上百台服务器资源,如何在需要时进行分配,在不需要时释放这些资源,就是我们内部自研的自动化资源管理框架所承担的任务。

研发与测试集群

而对于研发集群来说,主要承担的任务就是代码编译与单元测试。在我们的开发环境中,每个工程师均被分配最少三台虚拟机。每次编译完成,在正式提交持续集成测试之前,每个工程师必须完整通过自己的单元测试以及快速标准测试。

在巨杉的快速标准测试中,当前包含大约2800个测试用例,完整运行一遍大约需要20分钟左右,所有开发人员在将代码提交给持续集成测试框架之前,必须完成快速标准测试,已保障代码最基本的健壮性。

而测试集群则分为三大部分:持续集成、性能测试、以及功能和混沌测试。

其中,持续集成CI使用Jenkins工具,结合我们自行开发的远程调度框架,运行在大约300台虚拟机中,24小时不间断地反复运行近2万个测试用例。

?

而性能测试则是完全基于物理机,包括多种配置的x86服务器、OpenPower服务器、以及国产化ARM服务器。我们当前使用了十余套不同类型的性能测试框架,包括benchmarksql、tpccrunner、sysbench以及一系列其他的标准化测试框架。每个重要功能的合入与变更、以及所有的版本发布之前必须完成性能测试,并绘出与之前所有版本的性能对比曲线,以进行性能回归测试。

功能测试与混沌测试使用同一集群。一般来说,功能测试需要一定的手工操作,主要是用来模拟一些外部汇报的问题、以及一些较难使用脚本自动化完成的操作。另外,新功能开发后,测试团队在梳理出测试用例后会首先在功能测试区完成对应测试,再将其固化为持续集成脚本进行自动化测试。

巨杉数据库每次版本发布前会有2周左右的代码冻结窗口。在代码冻结窗口内,除非最高优先级的故障修复才会被允许合并入主干代码库。在这个期间内,测试团队会用最严格的的手段,使用 libfiu 结合混沌测试的机制,在整个集群环境中随意注入故障(例如网络中断、丢包、磁盘数据损坏、磁盘满、控制器错误、服务器挂起、服务器掉电、服务器时间错乱等),并确保数据不会产生错乱或丢失。

远程协作

如果说网络设施是保障无人值守团队有效协作的基础,远程协作工具与流程则是是否能够高效进行协作的核心。

巨杉数据库当前的团队分散在北京、上海、广州、深圳、成都等几大城市,团队之间的沟通非常频繁,因此早在2014年就开始搭建了远程协作通讯机制。

当前我们使用了两套不同的远程会议系统(小鱼易连以及Maxhub),以避免任何一套失效。其中小鱼易连要作为Presentation分享以及多人会议系统,支持超过20方同时在线,对于驻扎在各个客户现场的前线实施工程师与后方研发测试通讯非常有帮助。而Maxhub则更多作为技术讨论系统,支持远程白板绘图。工程师可以在电视终端上,通过触控笔直接绘图,而远程的团队则可以在他们对应的电视终端上听到语音,并实时看到所绘制的图像。

除了正式的视频会议与分享之外,由于巨杉的研发团队内部虚拟桌面网络不直接连接广域网,因此IM工具使用的是不需要外网链接的RTX;而如果需要与前线实施团队交流时则通过桌面电脑,使用Skype作为团队之间的实时沟通工具。

团队组织

众所周知,一个大型项目必须被尽可能切分成小模块,才能够有效保障开发周期与代码质量。几十人同时进行一个功能的开发必然会导致灾难性的结果。

巨杉数据库的研发体系按照研发+测试进行划分。研发人员则一方面按各自专长,以SQL引擎、优化器、数据索引存储、集群管理、以及事务管理等模块,作为领域专家负责对应模块问题的解决;同时也会根据新功能开发任务划分为一个个虚拟团队(或者叫做“部落”),每个虚拟团队以2-5人为主。

一般来说,一个典型的虚拟团队包括2位开发人员与1位测试工程师,极端情况下可以包含3位开发人员与2位测试工程师。如果一个功能模块需要超过3个工程师完成,则意味着该模块需要被进一步分解为更细的子任务。

该测试人员需要在功能的设计之初阶段即参与整个模块的设计讨论,并在前期对功能需求做出深入的了解。与功能设计同时,测试工程师必须尽早完成测试用例的设计,并在开发人员正式编码前通过测试用例评审。

测试用例的开发与代码开发几乎同时开始进行,理想情况下数据库程序代码开发完毕后测试用例代码需要已经准备好,并可以立刻开始进行功能性验证。在进行功能性验证的同时,该测试用例会被作为新的测试单元合并入集成测试框架,确保之后所有新的迭代不会影响该功能的正常运行。

具体来说,在测试流程方面,所有测试与开发人员均需要参与的例会包括:

1)Planning:确定目标产品功能scope,作出工作量预估与安排,细化任务并作出sizing;

2)Implementation:所有用例尽可能在测试开始前完成。实践中,开发人员阶段性完成开发任务,测试也可同步,尽早发现问题尽早在需要的情况下重新设计;

3)Retrospection:团队分析项目成功经验及问题和障碍。

每次功能开发完毕并合入主干后,该虚拟团队将会解散,所有成员则会被分配入其他的项目和模块中。在紧急情况下,一些骨干工程师可能会同时参与多个虚拟团队的开发或测试工作。

在团队协作方面,我们目前已经做到了跨地域、跨部门的协同,目前团队已经在六地跨国、跨地区办公,可以保证工作的高效。

自动化测试用例

测试用例

规划与管理

在测试的工作中,工具毕竟都只能作为辅助,而真正对产品质量进行保障的还是测试用例的完善程度。对于数据库这类紧耦合的基础软件来说,各种功能并发和顺序在不同的排列组合下可以说是天文数字般的场景,完全不可能做到100%全覆盖。因此,测试团队需要做的,是在有限的测试用例和测试时间内,尽可能做到对程序代码的全面覆盖。

测试团队需要针对每个功能进行story用例设计和实现,通过用例间的并发以及用例本身的并发,以及可靠性自动化用例构造断电、断网、集群中节点异常、磁盘空间满等各种随机故障来保障不同场景产品的质量。所有自动化用例对应的文本用例均使用testlink统一管理,且用例按特性指定责任人按时维护跟踪。

持续集成CI

随着数据库系统越来越复杂,我们需要覆盖的测试场景与用例也越来越多。到目前为主,巨杉数据库总共已经包含了近2万个不同的测试用例,单纯的自动化测试用例也已经超过了1万个,完整运行所有的自动化测试用例需要3-4小时,而覆盖全部自动化与手工测试用例(包括性能测试与混沌测试)则需要近1周的时间。

在这么多的测试用例中,不可能每次代码提交都要求运行一遍全部用例,这样只会让开发效率变得低下。因此,巨杉的测试团队使用了多级测试保障的规范,将全部测试用例分为5个级别:

1)提交构建+基线测试

该级别为最低测试级别,也叫做快速标准测试程序,所有研发人员在提交代码前必须手工运行并通过该测试,以达到最基本的稳定性需求。

该测试用例包直接坐落在巨杉数据库程序的代码树中,开发人员可以在编译完成后直接调用脚本,运行该级别的测试程序。

?
快速标准测试程序大约包含2800个左右的简单测试用例,基本上能够覆盖大部分常用的数据库基本功能。开发人员每次提交代码后,测试框架在后台会同样运行一遍该快速标准测试程序,如果发现任何异常则意味着该开发人员没有按照要求运行相关测试用例,会被记以相应的违规警告。

2)每日构建+集成测试

该级别为标准的回归测试项目,由我们的持续集成框架(CI)反复24x7地运行。该测试框架每天夜间2点自动根据当天最新提交的代码触发全编译,之后在大约300台虚拟机中反复24x7地运行近2万个测试用例。

?

这些测试用例远比快速标准测试用例复杂很多,除了最基本的功能操作以外,包含了大量的并发与混合操作业务逻辑,尽可能模拟真实客户现场的用户操作。实际上,我们很多集成测试用例设计就是来自于客户的真实操作环境。

巨杉的标准回归测试完全运行一次大约需要4-5小时。基本上早上工程师上班后能够第一时间看到夜间编译版本的运行结果。

3) 七天稳定性压力测试

回归测试只是保障程序不出现破坏已有功能的问题,但是一般来说很难针对内存泄露、性能下降、随机故障等问题进行检测。我们知道,一些随机问题并不会每次运行程序都出现,而是运行了一段时间后可能在某种特定场景和条件之下才会出现。因此,我们的第三级测试为七天稳定性压力测试。

在该测试下,巨杉数据库集群会在多台服务器中同时运行包括TPCC、sysbench以及模拟一些已知客户业务场景的压力测试程序。该测试的目的是尽可能将数据库的增删改查打满,同时在运行的过程中不断检测性能是否存在下降、进程的内存消耗是否不断增加,最后168小时后会出具汇总报告。

4)多场景性能自动对比测试

测试级别1-3均为基准测试,测试结果为通过或不通过。但是软件不同版本之间毕竟代码做过修改,如果一个不注意很可能造成整体的性能下降。因此,巨杉数据库测试级别4为多场景下的性能自动对比测试。

在该测试中,我们会基于测试级别3的稳定性压力测试框架,使用最新版本与之前的次新版本在同样的硬件环境下运行同样的逻辑,运行6小时候对比两者的性能。

一般来说,如果发现最新版本的性能与次新版本存在下降则会作为故障提交给研发分析,如果该性能下降达到5%以上则会成为重大故障,极端情况下会中断版本的发布直到问题解决。

5)故障注入与可靠性测试

测试级别1-4均为正常环境的测试,也就是所有的软件硬件环境均正确配置且不存在突发故障。但是我们知道,在真实的生产环境中,任何软硬件的故障都有可能发生,而作为数据库软件必须保障在任何故障发生后数据的不错不丢。

在该测试级别中会引入混沌测试与手工测试。测试工程师被要求以任意“有创意”的方式来“折腾”数据库,只要发现最后的数据造成了丢失或不一致,都会被认为是产品bug并成为重大故障报告给研发团队。

而混沌测试则更为极端。我们的混沌测试框架能够在操作系统和网络层面自动随机注入故障,例如磁盘I/O直接返回一个全空的数据页或错误码,或者网络中随机丢包或者字节跳变,用以验证数据库软件对于异常情况的处理能力。

?

与手工测试一样,混沌测试中产生的数据丢失或不一致均会以重大故障报告给研发团队,极端情况下可能造成版本发布的推迟。

可以看到,巨杉的持续集成体系覆盖了从代码的提交、系统集成、长时间运行、版本间升级、以及第三方软硬件故障等场景。其中,除了测试级别5需要一定程度的手工运行外,其余所有测试场景均可以做到自动运行、检测结果、生成报告、并发出告警邮件。

研发测试协作

一旦发现问题,测试团队需要第一时间将故障报告给研发团队对应的模块负责人。我们所有的测试用例均用一个负责人(团队),不管任何测试用例失败均会向该测试用例的负责人(团队)自动发送告警邮件,其中包括测试用例号以及对应的日志下载路径。同时,任何测试用例失败后其虚拟机将会被冻结,不会继续运行任何其他的测试用例,直到测试与研发人员在该环境重现问题并解锁该虚拟机。

测试用例负责人看到失败的用例或收到邮件后,会第一时间下载分析日志。如果发现该问题并不是测试用例本身编写错误导致,则会对比上一次正常运行的日志,并结合这段时间内所提交的代码更新进行简单的问题定位。

当故障被限定到某个具体某块后,测试用例负责人会通过Jira向研发团队开一个ticket,根据测试用例重要性的不同标记严重级别。而研发人员在接收到ticket后会直接登录到被冻结的虚拟机上查看环境与日志,必要时可以重新运行测试脚本并打断点定位问题。

当研发人员修复问题并进行code review后,首先会在开发环境本地运行快速标准测试程序,完成后研发人员会针对问题所影响的测试用例单独运行,确保该修复真正解决了测试用例报告的问题。

本地测试流程通过后,开发人员则可以使用git来commit并push代码进入主干。代码进入主干后会自动触发提交构建程序,在后台虚拟机针对该push进行编译并在此运行快速标准测试程序,保障代码的最基本稳定性。

到了每天晚上2点,CI系统会自动触发最新主干代码的全编译,大约1小时编译时间后会在300台测试虚拟机上运行4-5小时,在早上8点前完成所有测试用例的运行并产生结果报告。

工具列表

最后,我们简单罗列一下巨杉在进行自动化测试中所使用到的工具:

本文主要分享了巨杉数据库在自动化测试方面的实践。作为自研技术公司,公司成立以来,巨杉在研发体系、自动化测试、多地工作协调管理以及用户支持服务等方面,搭建了自己的完善体系,积累了丰富的经验。因此,我们在非常时期也将会保证提供给用户一如既往的服务和支持,保证我们的技术研发进度不受影响。

在新型冠状病毒引发的肺炎疫情形势严峻的今天,我们要求所有的员工尽可能在家办公保护好自己,同时也由于预先建设了相对完善的远程协作与自动化测试的机制,最大程度上减少了本次疫情对研发测试进度的影响。

文章分享的我们的研发和测试机制,希望也可以作为软件公司的参考,最终帮助到大家解决远程办公协作、研发测试管理的问题。

巨杉数据库与全体员工,也衷心希望本次疫情得到快速解决,每个人和每个家庭在新的一年幸福安康,平安顺利!

?

原文地址:https://blog.51cto.com/13722387/2469041

时间: 2024-10-05 10:49:25

【巨杉数据库SequoiaDB】巨杉数据库无人值守智能自动化测试实践的相关文章

【巨杉数据库SequoiaDB】点燃深秋,巨杉数据库亮相DTC数据技术嘉年华大会

2019年11月15日,第九届数据技术嘉年华大会在北京隆重召开,本次大会以 "开源 ? 智能 ? 云数据 - 自主驱动发展 创新引领未来" 为主题,探索数据价值,共论智能未来.SequoiaDB 巨杉数据库作为领先的金融级分布式关系型数据库,为大家带来新一代分布式数据库的发展趋势和特性,也通过分享巨杉的丰富金融级实践经验,帮助大家充分了解分布式数据库当前的应用场景. ****分布式数据库发展趋势 在上午主会场的分享中,巨杉数据库联合创始人王涛,为大家带来了题为"新一代分布式数

【巨杉数据库SequoiaDB】为“战疫” 保驾护航,巨杉在行动

2020年,我们经历了一个不平静的新春,在这场大的"战疫"中,巨杉数据库也积极响应号召,勇于承担新一代科技企业的社会担当,用自己的行动助力这场疫情防控阻击战! 赋能"战疫"快速响应 巨杉数据库目前服务许多政府部门应用平台,其中在广州市电子政务中心,就管理了全市近1500万人口的海量医保社保相关数据.医保.社保是抗击疫情工作的"弹药库",也是市民面对疫病的"定心丸". 目前,服务该业务的巨杉数据库集群,在2020年实现系统0错误

SequoiaDB巨杉数据库携手民生银行分布式数据管理平台

日前,SequoiaDB巨杉数据库成功中选民生银行新一期"年度生产运营商业软件许可和服务采购"项目,再次携手推进分布式数据库管理平台建设.自从2014年正式和民生银行建立合作,巨杉数据库至今已经管理超过2PB的数据,节点数超过130台物理服务器,并已经在数据中台.分布式影像管理等多个核心业务系统.平台规模使用. 民生银行简介:民生银行是中国第一家主要由民营企业发起设立的全国性股份制商业银行,截至2017年末,中国民生银行已经成为资产总额59,020.86亿元,一级资本净额超过3800亿

巨杉Tech | 使用 SequoiaDB 分布式数据库搭建JIRA流程管理系统

介绍 JIRA是Atlassian公司出品的项目与事务跟踪工具,被广泛应用于缺陷跟踪.客户服务.需求收集.流程审批.任务跟踪.项目跟踪和敏捷管理等工作领域.很多企业与互联网公司都在使用Jira作为内部流程管理系统,进行团队协作与问题单管理. JIRA的后台数据库可以选择使用嵌入式数据库或MySQL/PGSQL等专业数据库.一般来说,大部分企业选择MySQL作为底层的数据存储.但是,随着问题工单的不断积累,对于较大型企业来说MySQL所支撑的数据量可能很快达到瓶颈.用户可以选择使用SequoiaD

SequoiaDB 巨杉数据库Docker镜像使用教程

为方便用户快速体验,SequoiaDB 巨杉数据库提供基于 Docker 的镜像.本文介绍如何在 Docker 环境下部署 SequoiaDB 分布式集群环境. 集群规划 我们准备在五个容器中部署一个多节点高可用 SequoiaDB 集群. 主机名 IP 分区组 部署软件Coord 协调节点 172.17.0.2:11810 SYSCoord SequoiaDB 3.2.1Catalog编目节点 172.17.0.2:11800 SYSCatalogGroup SequoiaDB 3.2.1Da

巨杉Tech|SequoiaDB 巨杉数据库高可用容灾测试

数据库的高可用是指最大程度地为用户提供服务,避免服务器宕机等故障带来的服务中断.数据库的高可用性不仅仅体现在数据库能否持续提供服务,而且也体现在能否保证数据的一致性. SequoiaDB 巨杉数据库作为一款100%兼容 MySQL 的国产开源分布式数据库,它在高可用方面的表现如何?它的高可用性是如何实现的?本文将详细描述SequoiaDB巨杉数据库的高可用性原理,并进行测试验证. 01 巨杉分布式集群架构 SequoiaDB 巨杉数据库采用计算与存储分离架构,SequoiaSQL-MySQL 是

【巨杉数据库SequoiaDB】巨杉Tech | 四步走,快速诊断数据库集群状态

1.背景 SequoiaDB 巨杉数据库是一款金融级分布式数据库,包括了分布式 NewSQL.分布式文件系统与对象存储.与高性能 NoSQL 三种存储模式,分别对应分布式在线交易.非结构化数据和内容管理.以及海量数据管理和高性能访问场景. 集群一般会使用三副本方式以确保数据安全.假若集群发生因硬件故障等原因导致的节点故障或集群异常,数据库管理员应进行系统的分析和诊断,以确保集群正常工作,不会影响用户的正常使用.本文将与大家分享一下基本的 SequoiaDB 数据库诊断方法. 数据库集群诊断 1)

【巨杉数据库SequoiaDB】企业级和开源领域“两开花”,巨杉引领国产数据库创新

2019年12月15日,OSC 源创会·年终盛典在深圳圆满举行.巨杉数据库作为业界领先的金融级分布式数据库厂商, 获得 "2019年开源数据库先锋企业" 及 "2019 GVP-Gitee最有价值开源项目" 两项殊荣. ? SequoiaDB 巨杉数据库始终坚持自研路线,并于2014年正式开源,是国内最早的开源数据库之一.经过8年的自主研发和技术发展,迭代发展出了技术领先.产品安全稳定.通用性强的金融级产品.今年 SequoiaDB 发布两个主要的版本,近期发布的3

【巨杉数据库SequoiaDB】巨杉数据库 v5.0 Beta版 正式发布

2020年疫情的出现对众多企业运营造成了严重的影响.面对突发状况,巨杉利用长期积累的远程研发协作体系,仍然坚持进行技术创新,按照已有规划--推进研发工作,正式推出了巨杉数据库(SequoiaDB) v5.0 Beta版. 我们也在这里向大家介绍一下,SequoiaDB v5.0 版本中将会包含哪些激动人心的功能和特性. ARM架构的官方支持 从 3.2 版本开始,SequoiaDB 已经在有限版本中支持 ARM 芯片服务器与国产操作系统.从 SequoiaDB v5.0 开始,我们正式官方支持飞