金融业一直是IT发展的前沿，对应用功能、计算准确的要求非常高，导致了测试工作的量非常大：需要颗粒度更小的测试、需要大量的回归、频繁的版本发布需要更多的回归测试……
在2002年，自动化测试逐渐走到国内，开始了第一个商业银行的自动化测试项目：给一个核心业务系统做自动化测试。作者有幸被邀请去给一些建议。早的自动化测试，基本上是个“按键精灵+excel”来完成的，使用了winrunner来编写测试脚本。这个项目失败了，原因主要是：1）缺乏自动化和测试用例良好的结合，因此光有自动化也不能达到好的测试效果；2）缺少测试框架；由于缺乏对自动化测试的深刻认识，导致在没有测试框架之下执行测试用例，问题百出；3）测试工具弱小，很多功能不支持。当然，也跟自动化测试工程师对工具不熟悉有很大关系。
无论如何，自动化测试的思想是金光大道，所有看过的人都对它充满希望。
2003年，我们开始开发第一个自动化测试软件，面向终端系统的自动化测试工具：Terminal AutoRunner，大名鼎鼎的自动化测试软件，也可以说是国内第一个自动化测试软件，自动化的开始鼻祖了。
开始，我们去掉了测试脚本，使用xml配置来实现自动化测试，后来发现不使用脚本语言寸步难行——写给现在总是喊着要配置不要脚本的测试工程师——于是引入了java测试脚本，配置了ide，但是测试脚本可以自动来生成。
2004年，产品推出，获得好评，很多用户选用这这个工具，包括建设银行、中信银行、邮政银行、平安银行等等。
图1：TAR
TAR只能够支持终端系统的自动化测试，应用场景受到很大的限制，于是我们希望开发一个全新的软件，能够支持windows下的自动化测试，支持Browser、win32应用等等，于是有了AutoRunner。
自动化测试，复杂的是底层的组件识别录制算法。如同在黑暗中摸索，经过几年的研发，终于在2006年推出了第一个版本，终于可以在windows下实现自动化测试了！
在2008年，我们把模糊识别引入到AutoRunner，终于可以实现基于权重的对象库，实现了智能化执行和识别，这是AutoRunner2.0版本。这个版本拥有很多用户，包括很多金融客户、企业客户，以及测评的用户。
由于在前期的版本中，期望太高，想要支持几乎所有类型的技术框架，比如QT、.net、java UI（swt、swing、awt等）、browser等，因此代码交叉比较混乱。因此我们重构了代码，改进了识别算法，成为目前稳定的版本——3.9.
图3：强大的3.9
Version3.9是一个强大、稳定的版本，支持几乎所有的技术框架，从QT、silverlight、browser、.net、win32，从画图软件到制造、军工系统，几乎都得到了支持。
为了AutoRunner，很多高手都付出了自己的努力，从早期的snick胡，到中后期和3.9版本的核心老汪，都是非常了不起的。
Version4.0版本
实际上，4.0增加了很多的功能，比如图形对象、图像识别、支持H5等等。但是，我们还是希望给即将到来的4.0增加以下功能：
第一，增加可配置的自定义函数。在关键字视图框架中，可以配置的内部函数是固定的，对于复杂的对象处理，难以使用配置的方式来实现，影响了基于框架的测试脚本的扩展，因此希望增加一个功能，允许用户来自定义内置函数，并且允许这个函数来拖拽使用，达到更强大的可配置的目标。
第二，增加了对chrome、firefox浏览器的支持。随着浏览器的升级，为了安全性和速度的考虑，浏览器越来越不允许使用插件。这样几乎所有的自动化测试工具都无法使用BHO技术来实现自动化测试了。AutoRunner的这个技术，是为了解决这个问题而来的。
第三，强化了图形对象模块。图形对象，是对待无法识别的组件的终解决方案，有了这个技术，可以实现所有对象的录制和执行。
第四，智能学习。是可以通过定义，自动化识别需要录制的所有脚本的对象库，无需用户操作。根据对象库，用户可以来配置、编写测试脚本，无需使用复杂的录制过程，提升效率。当被测试系统发生变化，可以及时发现发生改变的对象。
第五，智能命名。对象的名字跟它在数据字典中的名字总是不一致，由此导致了繁琐和困难的管理。4.0强在录制和学习的时候，给对象一个“正确”的名字，提升编写脚本的效率，也便于脚本维护。
目前AutoRunner365版，告别Lic文件授权，现在注册，立刻使用。
注册账户即可使用，无需授权，无需会代码编程，快速上手自动化测试，降低企业测试成本，只需为批量执行付费，支持丰富技术框架，浏览器、应用程序和QT等。
推荐阅读：
自动化测试工具下载地址
AutoRunner自动化测试的标准流程是怎样的？
AR365如何实现B/S系统自动化测试
web自动化测试工具AR和APP自动化测试工具MR的区别
sales@spasvo.com
