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

　　前言

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

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

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

　　 1、 流程 &ndash； 快速敏捷

　　 2、 运维 &ndash； 智能高效

　　 3、测试 &ndash； 严谨全面

　　#FormatImgID_1#

　　注：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 测试高效化：整个产品流程中开发和测试要同步进行，这包括了对不同的开发分支需要有不同深度的测试代码保证其质量&mdash；&mdash；例如，对于Release分支，必须有持续性的Nightly测试把控每天进入的代码质量；对于Feature分支，需要能快速检测出patch对代码核心功能影响的BAT测试。同时测试系统和CI系统要高度集成并且做到同步触发。

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

　　注：ZStack云端测试的环境构建是通过XML配置文件实现的，测试工程师可以非常简单地用几分钟配置出一台自动化环境。

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

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

　　3。3 测试覆盖智能化：软件测试没法达到的覆盖率，所以我们要做的是在资源有限的情况下，以尽量少的代价做到尽可能高的覆盖率。要提高覆盖率，需从两方面入手，一方面是对代码进行覆盖率检查，我们在日常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混合云、ZStackMini超融合一体机、ZStack CMP多云管理平台、ZStack企业级分布式存储等产品和方案。本文从开发流程、基础运维以及测试能效等角度，介绍了 ZStack 团队如何高效打造一个产品化的私有云。