ZStack实践汇 | 高效开发测试打造产品化私有云

做者：许佳珺
 

 

前言

随着愈来愈多的企业将云计算产品应用到基础设施及其核心业务中，如何提升和保证软件交付质量、减小软件开发迭代周期、加速软件发布频率成为全部云厂商面临的关键问题。

根据IDC 2018年的预测，中国云计算市场在将来5年将持续高速发展的态势，主要表现为：中国传统的非云计算IT基础架构占总体IT基础架构的投入比例将从2018年的50.3%降低到2022年的40.7%；中国私有云平台建设的市场规模将以年均24.8%的复合增加率快速增加；中国云计算IT基础架构支出占全球市场比将从2018年的12%上升到2022年的25%，届时中国私有云IT基础架构支出将超过美国，成为全球第一大市场。在这一轮新的迭代更新中，更多的企业和行业开始部署或者创建更大规模的私有云；而新应用（数据分析，AI，IoT，移动）和新场景（边缘计算，智慧/平安城市，行业云）也对云平台提出了更高的需求。

ZStack凭借创新的产品化理念，在业内率先提出云计算的4S标准 – 简单Simple，健壮Strong，弹性Scalable，智能Smart。同时，ZStack企业版从初版发布到最新的3.5.0版本，一直以每六周一次的周期迭代更新软件版本，快速提高和扩展产品功能，积极应对云计算市场对私有云产品不断增加的需求。而保证其私有云产品化的关键要素有如下三点：

1.    流程 – 快速敏捷
2.    运维 – 智能高效
3.    测试 – 严谨全面

 

注：ZStack坚持快速、简洁、高效的开发、运维、测试流程，确保新需求六周即可实现

1.    流程 – 快速敏捷

ZStack开发流程依然定义了传统开发模式中的几个关键阶段 - FF、CF、RC和GA。同时针对不一样阶段的任务和目标，进行有的放矢地优化。在Feature Freeze阶段，主要以需求分析为主，要求产品经理将客户的需求分片化、分级化，需求描述本地化，更有效地将需求安排到不一样发布版本周期中。开发和测试工程师则须要将Code Freeze和Release Candidate的任务提早到Feature Freeze阶段中，减小互相之间任务的依赖，提升各个阶段的并发度。而测试不只须要渗透到开发的每一个环节中，同时也要经过模型测试、路径测试、稳定性测试等方法，提升代码的覆盖度和测试效率。每一个发布周期经过反复地从需求->开发->测试的快速迭代，保证了产品的新需求和问题始终可以被快速知足和解决。

 注：ZStack产品开发流程高度并发，保证版本之间快速迭代

2.    运维 – 智能高效

做为私有云产品开发的基础保证，一套快速、稳定、高并发、可伸缩的运维系统是必要的。而传统运维提供的简单CI和CD功能是显然没法知足这样快速迭代的需求。ZStack产品化过程当中，搭建了一套以ZStack + Kubernetes为基础、面向公司各个部门的总体性服务框架。这套框架中所包括的服务内容涵盖从开发&测试人员使用的测试环境、到整个项目的管理工具。框架的底层以ZStack做为IaaS提供给上层可靠的、可扩展的物理资源，同时结合Kubernetes，将容器运行于云主机中，既保证了隔离性、又充分利用了ZStack和Kubernetes对云主机和Docker调度的优点，起到了对上层服务高可用、高并发及可伸缩的双重保障。

注：ZStack做为IaaS层向上层服务提供可靠的物理资源，而更重要的是，内部的ZStack环境也会随着发布版本更新，真正作到了本身的产品本身先用起来
 

注：实际生产环境中，一次自动化测试至少在Jenkins上并发建立500+个请求，每一个请求包含10~50个测试用例，ZStack + Kubernetes保证了这些请求几秒内能够被处理

3.    测试 – 严谨全面

打造一个产品化的私有云软件须要全面且严谨的测试，这不只仅是单元测试和集成测试能保证的。ZStack从如下四个方面入手强化测试：

3.1     测试高效化：整个产品流程中开发和测试要同步进行，这包括了对不一样的开发分支须要有不一样深度的测试代码保证其质量——例如，对于Release分支，必须有持续性的Nightly测试把控天天进入的代码质量；对于Feature分支，须要能快速检测出patch对代码核心功能影响的BAT测试。同时测试系统和CI系统要高度集成而且作到同步触发。

高效化的另外一个重点就是要作到全部测试都能运行在云端，提升测试的并发度和资源利用率。ZStack内部的测试都是跑在云端的，而云端环境也是基于ZStack自身搭建的，利用其对底层硬件资源的抽象和管理，模拟出测试中须要的不一样的硬件配置场景，包括网络、存储、虚拟化平台、甚至不一样的ZStack高级功能配置，如企业管理、灾备服务等。同时，为了知足大规模资源需求的测试场景，例如1万台或10万台云主机的测试场景，ZStack测试中还实现了simulator机制，即不真实分配硬件资源，而使用mock后端API的方式提供了对后端资源的调配，真正作到了有针对性的测试。

注：ZStack云端测试的环境构建是经过XML配置文件实现的，测试工程师能够很是简单地用几分钟配置出一台自动化环境

3.2    测试标准化：ZStack所涵盖的测试内容不只包括功能性测试，还包括一套完整测试体系所须要的各类测试，如开发工程师须要作的集成/单元测试，测试工程师须要作的系统测试中的压力、性能、可靠性测试、以及针对不一样版本定制的发布测试。例如ZStack的可靠性测试就包括了两类测试 – MTBF和DPMO测试，MTBF会对ZStack平台进行15,000小时长时间的真实用户操做模拟；DPMO测试则会对ZStack平台进行高达10,000次的断/上电、重启等测试。

标准化的另外一方面体如今对关键节点的标准把控上，对FF、CF、RC和GA各个阶段都会有相应的代码准入和验收标准，例如CF阶段后功能开发代码禁止进入发布分支而只能进入下一个发布版本的周期；又例如各个阶段验收时要求的bug数量限制，CF阶段要求小于5个P0，GA阶段要求没有P0的bug。

 

3.3 测试覆盖智能化：软件测试无法达到100%的覆盖率，因此咱们要作的是在资源有限的状况下，以尽可能少的代价作到尽量高的覆盖率。要提升覆盖率，需从两方面入手，一方面是对代码进行覆盖率检查，咱们在平常CI的包中插入了代码不一样模块的覆盖率，不论是手动仍是自动测试，或是平常bug的验证，都会为覆盖率提供数据。

另外一方面咱们增长了模型测试，它能够产生由随机API组合构成的场景，会持续运行直到遇到预约义的退出条件或者找到一个缺陷。这种模型测试很好地弥补了人为定义用例的不足，提升了测试场景和路径的覆盖率。由这种测试模型，也衍生出了三种不一样场景的覆盖率提升测试：

 

 

3.3.1 覆盖率测试：除常规有序的测试步骤外，运用模型测试，收集无序测试步骤下的测试覆盖率。

3.3.2 MTBF测试： 从有序和无序两种测试维度，对系统稳定性及可靠性进行测试。

3.3.3 路径测试： 一般一个系统测试用例最多5-6个操做步骤，而最终客户的问题场景是极其复杂的，一般须要10~20个以上的步骤才能重现，运用模型测试的方法，能够有效减小构建测试用例的代码量。

 

注：一个典型路径测试，只须要将测试对象和操做步骤写到测试用例中便可完成

3.4 报告立体化： 主要从两方面实现，一是测试报告的结果自动化、可读化，是经过对测试用例中插入DITA描述实现的。另外一方面是结果的可追溯和可回放，这是经过记录测试过程当中API的调用顺序和参数实现的。

 

注：一个测试结果的操做记录及回放方法，可以有效帮助开发测试工程师重现bug

总结

做为产品化的云计算公司，ZStack一直致力于打造自研的ZStack私有云、ZStack混合云、ZStack Mini超融合一体机、ZStack CMP多云管理平台、ZStack企业级分布式存储等产品和方案。本文从开发流程、基础运维以及测试能效等角度，介绍了 ZStack 团队如何高效打造一个产品化的私有云。

 

欢迎关注ZStack中国社区QQ群、ZStack官方微信！