浅谈云上可靠性测试

引言

疫情之下，科技支撑有目共睹，多个产业迎来逆势增长。科技创新赋能的“云技术”，不再仅仅是战“疫”的重要工具，更将带动全社会的数字化转型，对产业发展产生深远的意义。而在产品上云之前，云上数据的可信（安全性、可靠性等）一直是大家关注的重点。

近年来，云上可靠性事故的案例层出不穷。如：

2018年7月XX云因存储空间使用率过高发起搬迁扩容。为加快速度，运维人员手动关闭了搬迁过程的数据校验，并在搬迁完成后立即释放了源数据空间。由于物理硬盘固件版本缺陷导致的静默错误，文件系统元数据损坏，导致租户数据丢失；

2018年9月4日清晨因雷电导致XX云中南美Region机房制冷异常，引起部分设备损坏/自动关闭，大部分云服务器中断超24小时；

2018年10月21日晚，GitHub对故障的100G光纤设备维护更换导致东海岸数据中心网络中断43秒，由此引发数据库异常，服务降级持续24小时11分钟；

2019年X月，XX云某region因代码缺陷导致包周期EIP出现大量退订，引起客户业务故障引发客户强烈不满。恢复丢失资源约花费XX分钟。

“云技术”带来了数字化变革，但云上的可靠性问题又一次次让客户胆战心惊，下面重点谈谈如何做云上的可靠性测试。

1 什么是可靠性测试

可靠性测试就是采用特定的方法激活系统中的各种故障（FAULT），通过观察失效（FAILURE）的发生情况来对系统容错能力（故障定位、故障恢复、故障报告等）进行评估并利用该评估结果来推动产品持续减少失效的一种测试活动。

产品的可靠性能力主要体现在防错能力、容错能力和纠错能力。因此可靠性测试也主要围绕产品的这三大能力进行测试。

防错能力主要考察服务的故障预警能力，如CPU、内存、磁盘等的容量监控告警能力。

容错能力主要考察服务故障后的故障隔离、故障自恢复的能力以及隔离时间。

纠错能力则主要考察业务故障后告警能力以及故障修复文档的可操作性。

2 可靠性测试设计

可靠性测试设计主要从产品故障模式库和业务流程两方面着手进行分析：

故障模式考虑的因素包括外部因素和内部因素。内部因素包括软件，硬件，网络和数据。外部因素包括人，负载，灾难，电力，环境等。

流程驱动主要从异常逻辑、异常事件、业务运行环境三方面来分析：

异常逻辑主要包括（1）流程处理逻辑结果不符合预期；（2）流程处理逻辑过程中所发生的非期望事件。

异常事件对业务流程的影响最终也会体现到逻辑上来，产生异常或不产生异常与切入点有关，需要通过多次反复操作增加冲突几率。

业务运行环境不稳定对业务的影响，主要指周边服务/链路状态不稳定，系统资源占用不稳定等对业务流程的影响。

无论从哪个角度出发，均属于抽取式分析。无法达到故障模式和业务流程的完全组合覆盖。产品故障模式库实例化无法考虑所有业务流程，业务流程可靠性分析也不会考虑所有故障模式。故障场景分析即是将测试对象分析结果与故障模式相结合，将系统结构、组网架构、业务场景和关键数据融入到故障模式和业务流程的分析中，分别生成故障模式用例、功能测试异常用例、性能测试异常用例，共同构成可靠性用例。

3 可靠性测试框架

一个完整的可靠性测试框架主要由四部分组成，业务背景流量、激活故障的平台或工具、被测对象及故障后的监控平台（主要用于监控故障注入后的告警、隔离恢复时间）。

可靠性测试框架：

业务背景流量是由业务的基本功能或性能场景组成的，主要是用来在故障注入前和故障注入后检测业务是否正常，故障注入前需保证业务0错误才能准确看到故障注入后系统的反应；故障注入后检查业务背景流量主要是为了观察故障后业务的隔离恢复时间。

激活故障的方式有两种，（1）通过业务场景的构造触发故障自然发生；（2）故障注入测试：直接模拟某种故障，属人为产生故障。

业务场景构造测试方法：

压力测试：通过使系统达到一定的负荷状态(或超过其设计的最大负荷)，用以检验系统在资源利用率高的情况下的工作状况；

长稳测试：在一定的压力状况下系统持续较长时间运行能力的测试；

异常业务场景测试：通过异常操作、业务配置、异常业务流量等构造异常业务场景进行测试，主要有：主备倒换、插拔网线、触发时序类问题等。

故障注入测试方法：

网络级故障注入：覆盖网络组网相关的接口、链路、物理连接、时间时钟等故障对象的故障模式；

系统级故障注入：覆盖单系统内的链路、时间时钟等故障对象的故障模式的模拟；

资源类故障注入：覆盖进程在使用内存类（动态内存、消息包、消息队列）、CPU、硬盘/FLASH等系统资源类故障对象的故障模式；

数据类故障注入：覆盖数据库、文件等数据类故障对象的故障模式；

接口健壮性测试：覆盖系统中的各种接口协议消息及其对应的故障模式；

硬件故障注入：覆盖硬件平台中的单板、硬盘、内存、网卡芯片、CPU、总线、控制器等故障对象的故障模式。

被测对象系统即为将要注入故障的受体。

故障后的监控手段通常也叫做运维可靠性主要包括告警、故障恢复时间、故障恢复指南、日志定位能力等，用于检测系统在故障后的纠错能力。

4 结束语

可靠性测试的关键是了解业务组网、架构和业务场景。基于业务组网和架构选择合适的故障模式，在合理的点注入故障，然后得到预期的效果。可靠性测试分析既要求测试人员了解客户应用场景，又要求熟悉系统业务流程，所以需要测试人员和开发人员共同完成。

从客户应用的角度进行：客户应用场景是测试人员擅长的，对指导测试也比较直接。主要有：大业务压力、长时间运行、业务叠加、多服务同时操作设备、流量模型、异常报文、业务配置顺序、异常操作等。

从系统实现的角度进行：需要开发和测试团队合作进行分析。主要有：时序问题、内存泄漏、组件失效、CPU过载等。

网络

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。