【ZStack】自动化测试系统3——基于模型的测试

ZStack的模型测试系统采用有限状态机来生成随机API操作，通过动作选择策略执行，寻找软件边界问题。该系统能够覆盖人类逻辑难以触及的测试场景，提高测试覆盖率。通过定义退出条件和失败回放机制，便于调试和问题定位，是保障IaaS软件质量的重要工具。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

模型测试系统是zstack-woodpecker中的一个子项目。通过有限状态机和行为选择策略，它可以产生随机的API操作，一直运行下去，直到遇到一个缺陷或者预定义的退出条件。ZStack依赖模型测试去测试真实世界中难以遇到的边界用例，在测试覆盖度方面补充集成测试和系统测试。

概述

测试覆盖率是一个判断一个测试系统品质的重要指示器。常规测试方法论，例如单元测试，集成测试，系统测试，都是由人类逻辑思考构建的，难以覆盖软件中的边界场景。这个问题在IaaS软件中变得更加明显，因为管理不同的子系统会导致极为复杂的场景。 ZStack通过引入基于模型的测试来解决这个问题。它可以产生由随机API组合构成的场景，会持续运行知道遇到预定义的退出条件或者找到一个缺陷。作为机器驱动的测试，基于模型的测试可以克服人类逻辑思考的缺陷来执行一些，看起来反人类逻辑，但是API完全正确的测试，帮助发现难以被人类主导的测试发现的边界问题。

一个例子可以帮助理解这个思想。基于模型的测试系统通常在执行大约200个API后暴露一个bug，在调试后，我们找到最小重现这个问题的序列是：

创建一个VM
关闭这个VM
为这个VM的根云盘创建一个云盘快照
从这个VM的根云盘创建一个新的数据云盘快照
销毁这个VM
创建一个新的数据云盘，使用4中的模板
从6中的数据云盘创建一个新的云盘快照

这个操作序列显然是反逻辑的，我们相信没有测试者会写一个集成测试用例或者系统测试用例这么做。这就是机器思考闪光的地方，因为它没有人类的感情，会做人类感觉不合理的事情。在找到这个bug之后，我们生成了一个回归测试为以后保障这个问题。

#基于模型的测试系统基于模型的测试系统，因为由机器驱动，也被称为机器人测试。当这个系统运行时，它从一个模型（在下面几节中也被称为阶段）移动到另一个模型，通过执行被动作选择策略选出的动作（也被称为操作）。在每一个模型完成之后，检查器将会验证测试结果，测试退出条件。如果任何失败被发现，或者退出条件被满足，系统将会退出。否则，它将会移动到下一个模型，然后重复。

有限状态机

在基于模型的测试的理论中，有许许多多生成测试操作的方式。例如：有限状态机，自动推导，模型检验。我们选择使用有限状态机，因为它自然地适合IaaS软件，其中每一个资源都由状态驱动。例如，从用户角度看，VM的状态像这样：

在基于模型的测试系统中，每一个资源的每一个状态都预先定义在test_state.py中，看起来像：

vm_state_dict = {
            Any: 1 ,
            vm_header.RUNNING: 2,