前各个软件公司都很重视自动化软件测试。甚至会把软件测试自动化率（自动化测试用例占整个测试用例的比例）作为软件测试人员（也叫质量保证工程师）绩效考核的内容之一。追求自动化测试比例的初衷是很好的，但是不顾软件产品的实际情况和软件测试人员的情况，而过分追求高的测试自动化比例，会得到适得其反的效果。我们常常会听到某软件的自动化测试率高达70～80%，可是还是不得不聘请大量的测试人员来进行手动测试。这在无形之中把软件测试引入了误区。

ZStack的测试架构师认为，软件自动化测试的好坏可以用软件缺陷的发现的比率来衡量。换句话说如果整个系统的自动化测试比例达到80%，那么通过自动化测试发现软件缺陷的数量应该达到甚至超过全部软件缺陷数量的80%。举个例子，iSCSI主存储是即将发布的ZStack 0.7版本的重要功能。ZStack现有的自动化测试用例在没有修改一行代码的情况下，就可以用于测试iSCSI主存储的功能。之前开发人员手动测试没有发现的软件缺陷，但是用自动化测试用例发现了5个缺陷。这个就是非常有效的自动化测试用例。

ZStack对软件质量非常看重，因为我们深知人是最聪明也是最不可靠的（以后我们也许可以探讨一下人性与软件测试的相关话题），所以从整个软件设计的开始，ZStack就决定尽可能地依靠全自动的测试手段来探测各种可能出现的软件缺陷。

传统的自动化测试有一个优势就是每轮测试都会严格执行之前定义好的全部测试用例，无一遗漏。通过对前后测试结果的比较，就可以得出质量的变化情况。不过这个优势也是它的弱点。设计软件测试的人员都知道，由于无法穷举所有的测试可能，所以预先设计的测试用例也只能覆盖一部分最常见（或者说是测试人员最希望测试到）的领域。那么对于没有测试到的领域就无法确定其是否存在软件缺陷。这个问题该怎么破呢？为此，ZStack的自动化测试特别引入了一种特别的测试－－基于模型的测试（Model-based Testing)。

基于模型的测试是一种人工智能的测试方法，可以用于自动的构造测试场景和测试用例。它要求测试人员首先基于软件功能构造出各种模型（或者叫做行为），然后制定行为和行为之间的关系以及行为和系统的关系（有限状态机），之后自动测试系统就可以智能的根据当前的被测系统的状态（场景）以及预设的规则，选择下一步要执行的行为。理论上这种测试方法可以尽可能的遍历被测试系统中各种可能经历的行为链，从而极大的提高了测试覆盖率。由于它每次执行的路径和以往不同，所以可以构造出完全不同的测试用例，我们也可以称之为智能的软件测试。

下面，我们来大致看看ZStack是怎么构造基于模型的测试的。不过首先我们要说明的是，整个基于模型测试的难点在于提取测试模型，以及编写测试模型验证代码，而非基于模型的测试框架本身和模型算法。所以以后遇到推销基于模型测试“框架”的人，千万不要觉得他们牛的一塌糊涂，真正牛的是实现具体测试的人，而非框架本身。实现测试系统的工程师才是真正的英雄。换句话说，虽然现实中有一些现成的基于模型的测试的框架，但是如果其他IaaS想要重现ZStack的智能测试也绝非易事。

ZStack基于模型的测试首先就是要把各种IaaS操作定义成模型。这里我们拿虚拟机实例的各种操作举例。虚拟机实例通常只有4个状态，状态和状态之间可以定义标准的操作。把状态和操作画出来后，我们就得到了虚拟机实例的状态迁移图（有限状态机）。可以看到上图中Running和Stopped的状态之间可以通过stop和start操作做成状态环。那么智能测试就可以根据预先设定的规则，可能会让虚拟机在这个环里做有限的测试。这一个看起来好像很简单，但是要知道IaaS里面还有很多其他资源的状态迁移图。而且很多资源之间是有相互依赖关系的，例如在某些系统中只有虚拟机处于Stopped的状态才可以做磁盘快照。而且用户在操作IaaS的时候，也不会只做虚拟机状态的改变，通常会和其他资源的actions混合操作。所有当把所有资源的迁移图画完，就会发现整个IaaS的场景和可选的行为之间的关系还是非常非常复杂的。ZStack的测试工程师可是花费了不少的时间来完成这项艰巨的工作。

当创造完场景和行为关系图后，智能测试就可以开始最初的测试工作。一开始的时候，它的智力水平并不高，只能从当前可执行的所有操作中随机的选择一个操作。极端情况，这可能会导致它一直在虚拟机实例的操作中绕圈子，而有些操作从来就没有执行过。慢慢的ZStack工程师就开始给他添加了两个更高的智慧：公平调度算法和基于历史测试路径的调度算法。

公平调度算法会让智能测试系统尽量选择最少执行的行为作为下一个操作。

而基于历史测试路径的算法可以让智能系统选择曾经没有测试过的路径。有了这两种更加智能的调度算法，智能测试系统也就可以更好的发挥它的能力，未来ZStack的测试工程师们还会设计出一些更高级的复合测试算法，来增加智能测试系统的智商。除了发现一些常规的问题外，通过基于模型的测试还发现了不少我们称之为Corner Case的缺陷，它们可能是90%的ZStack用户永远也不会触发的问题。虽说是corner case，但是一旦在开发的阶段没有发现，等到用户遇到的时候，就会花费很大的力气来修复，有一些可能还是致命的。所以这种基于模型的智能测试给ZStack带来了很大的好处。

基于模型的测试和ZStack的另外两大自动化测试系统：集成测试和系统测试构成了ZStack质量控制的三驾马车。在当今DevOps当道的今天，我们希望ZStack的测试和研发投入比力求做到1:1（以后我们也许可以和大家交流为什么纯粹的靠开发人员来做测试是有问题的） ，我们希望把软件质量永远放在ZStack的第一位。

希望今天浅析的ZStack智能测试方法能给广大软件质量保证师从实践角度带来一些好的想法。最后我们想要感谢全世界的软件测试工程师，感谢你们在每一件软件产品后面付出的辛苦努力！