基于模型驱动的自动化测试设计

序言：一直在思考一个问题：业界自动化测试被大家认为应用的场景主要是产品稳定、周期较长的测试项目，而且自动化测试不是用来发现和定位问题的。大家应该知道，“杀虫剂效应”，虫子对农药产生抗体的，那产品何尝不会对反复不变的测试产品抗体呢，那么这样，自动化测试的效果只会越来越差，根本上只能去更改自动化测试脚本，让其变得更有适应性。这其实自然界的一种规律。而更好的方法，我觉得是只需要在自动化测试系统中添加相应的因子或者是模型，系统则会自动适应生成一系列的自动化测试用例，业界内流行的机器学习也是让程序变得有学习型，前两个月对自动化测试中的基于模型的技术进行了研究，还弄了个小专利，不过没有推广，因为其要求测试人员的一些编程功底，而且成熟度不够，但是却让我更相信证一个事实，那就是自动化测试是可以用来发现更多问题的。
　　（PS：序言好像写的有点长了…）
　　一、人工测试的场景
　　为什么人工往往比自动化测试更具有效率，分析一下：
　　1、人工具有反应性，发现产品异常不是去继续按用例执行，而是根据异常结果进行不同的处理，因而能快速发现问题。
　　2、人工具有变化性，能够自我学习，并且基于功能，快速发现新的测试用例，从而让测试变得更有充分性和适应性。
　　二、基于模型驱动的应用

　　所谓的model，其实是一系列的状态机，一般都是有限状态机，是表示有限个状态以及在这些状态之间的转移和动作等行为的数学模型可以，可以将一个有限状态机看做是一个特殊的有向图（这个在算法导论中可以参照），它包括一些状态（节点）和连接这些状态的有向弧。每一个有限状态机都有一个启始状态和一个终止状态和若干中间状态。每一条弧上带有从一个状态进入下一个状态的条件。下图是我画的一个说明图：

从开始模型起，箭头表示上一个模型能够根据不同的条件触发进入下一个模型，经历若干个模型后，到达结束模型止。从而获得了一系列的遍历路径。这么一说，也许大家就能想到如何将其技术小用在测试中了吧。

　　三、基于模型驱动的自动化测试设计

　　在自动化测试中，每一个模型相当于一个测试场景，不同的测试场景之间的触发有不同的条件，一个整体的功能测试，比有开始和结束两个状态。因此，设计自动化测试系统可包含这几个测试模块：人机交互模块、总体控制模块、模型驱动模块、数据库交互模块、测试用例组装和分析模块、执行模块、测试结果分析验证模块。

　　重点是测试用例组装和分析模块，其可以根据不同的测试方式进行测试用例的组装，第一种按输入指定的测试序列直接进行模型组装生成用例，第二种测试方式是在测试过程中模型不断根据输出状态和触发条件进行组装和生成用例。应用就是

　　1、随机序列，则无需人工去构造用例，而是根据测试模型，应用深度或者广度优先遍历算法，生成所有用例，例如：你从北京去上海，有几种途径选择，测试时，你只需定义好各个城市节点状态，则可自动生成从北京去往上海的路径，可以快速应用到实际测试中。这样，保证了测试的充分性，也节省了人工构造用例的时间。当然，最后生成的用例也需要人工审查保证。

　　2、指定序列，则可以按指定的序列去检验功能，例如：北京到上海，指定的路径是：从北京到南京，再到上海，主要是测试这条路径。

　　总结：当然，上述的很多系统很多工作还未完成，实践上也是颇为简易，而且适合的场景也很有限，所谓的数据驱动和关键字驱动已经很适用，而且驱动还有太多的思想还没有挖掘清晰，我个人觉得：技术很重要，但是落地的应用更重要，技术是为了服务需求和实践的，所以有时候高明的技术在某个时候效率不一定比得上基础的技术应用。

本文出自 散步的SUN 的51Testing软件测试博客：http://www.51testing.com/?382641