录制，到底给我们带来了什么

  记得我刚开始使用RFT进行gui界面自动化测试时，也是用的录制和回放的手段，后来一小段时间后就放弃了，也许很多刚接触自动化测试工具同行和我有一样，也是从录制入手，有的，也许和我一样一段时间放弃了录制，有的也许一段时间后还是坚持录制，好与坏，短时间谁也说不清楚，但是我觉得，自动化测试，不走到最后谁也说不清楚，或者自动化测试本身就没有头。

  我把某位同行的疑问说一下（用的是RFT工具）：

“我没有感觉到写脚本相比录制回放的优势在哪里?当然我知道肯定是有优势的。首先录制简单，插入验证点，数据池都很直观，执行速度又快。那么我们录制完成，再在脚本中加入一些诸如try catch，sleep()，logInfo()等防止意外和记录的代码来完善，那不就是很完美了，何必全写脚本呢？何必要动态查找呢？还慢。录制时自动把控件映射到TestObjectMap里了，直接用就行，根本不用find()，录制完再改也方便。录制也是根据控件属性来定位，应该都不会出错。你说复用性，再复用也得写脚本，有那时间我再录制一下也够了；维护？维护写的脚本比录制的方便在哪，录制的脚本增删几个控件应该是很容易的事。”

  总体来说，疑问可以分为以下几点：

     1）    录制简单，手工在录制的脚本上根据需求进行二次开发就很完美了，何必全写脚本。

     2）    录制的控件映射也很强大，无需用动态搜索了。

     3）    复用性方面和维护性方面，有写脚本的时间直接再录制一遍不就好了。

  二、           录制的优势

    当然什么事情要以辩证的观点看问题，我先说说录制的优势吧

1         操作简单，测试人员容易上手，这对于大多没有编程经验的人来说是一件很有诱惑的事情。

2         构建测试脚本快速，在手工测试的同时，也可以将测试脚本生成好。

3         如果是商业型软件，就不用操心其测试工具带来的问题，大多都可以进行技术支持。

    三、           我眼中的“录制”

    以我个人的看法，做自动化测试，最大的也是最容易进入的一个误区，就是太拘泥于自动化测试工具，因为自动化测试的需求变化性很大，而商业型的自动化测试工具的重点是面向于简易的操作性，这样往往是以失去韧性为代价的。因此，商业型工具中的“录制使用”则是自动化测试“误区”中的“误区”。

        1） “录制简单，手工在录制的脚本上根据需求进行二次开发就很完美了，何必全写脚本。”，为什么会有疑问说录制比写脚本简单，那是因为你没有建立起一个合适的自动化测试框架，如果有了这个框架之后，你会发现你可以脱离RFT的IDE，在任何时候任何环境下可以进行你的脚本开发，而此“测试脚本”在直观上就是等同于“测试步骤”。

         2） “录制的控件映射也很强大，无需用动态搜索了”，静态的控件映射，其实是一种很不灵活的方式，其机制为了满足对象定位的精确性，而失去了其灵活性，想想，举java界面来说，其静态的映射方法是将其java界面映射成一系列的树节点关系，若是树的结构有所变化，那么其对象查找就会受到影响。并且其静态映射还需对一个控件的各个属性进行阈值计算，得到一个值后才确认是否识别。那么我们用动态搜索方法的话，就可以依靠我们的界面的特点，进行基于某一个特别的属性进行匹配即可。总之，越简单则越灵活。

          3） “复用性方面和维护性方面，有写脚本的时间直接再录制一遍不就好了“，自动化测试定位很重要，为什么会有这么多失败，就是因为对以后会发生的情况的预估不够。想想，也许十个用例脚本维护量很小，可是等到成千上百个脚本的时候，你还能有心思进行维护，你可以说重新录制，那么这样的话，你会疲于录制，而最终放弃自动化测试。

总之，为什么录制会带来这么大的维护量？因为个人觉得，自动化测试的重点，也是难点就是一个适应变化过程。而录制方式，将其对象的查找、逻辑方方法的处理、测试用例的组织一锅端的放在了一个脚本中，当出问题时，牵一发而动全身。所以，分层是一件很重要的事情，有编程经验的人一定知道，在设计模式中提倡的原则就是，“面向接口编程，而不是面向实现”，也有一种说话“抽象不应该依赖于细节，而细节应该依赖于抽象”，即说软件编程模式，要做到职责细分，增加其拓展性与可维护性，如果将其抽象与实现写到一起的话，那么到后期，此软件在重用性和可拓展性方面则会很差。所以说，做自动化测试其实就是一门软件设计的艺术。

    四、           如何应用“录制”

    这里我不在框架上说如何去应用了，而只是说如果你只想先依靠自动化测试工具的自动化测试做一些事情，没有人力和精力去投入，虽然构建一个简单的自动化测试框架不需要很大的精力，个人以为，那么你就要在流程上把握了。

        1） 当一个产品不稳定时，那么别用其来构建自动化测试项目，可以尽量将录制用在需要进行很多次重复操作的过程，例如：需要对某个界面的某个输入框进行数值输入遍历测试。

        2） 如果你的产品界面很稳定，那么恭喜你，你可以试着去用，但是我还是不提倡，因为录制是不可能形成自动化测试规模的。

        3） 如果你开发组能够配合你不去刻意修改你的脚本中录制的界面，那么也恭喜你，但是这是不可能的…

    当然，时代是发展的，技术也是发展的，也许有一天，录制的这种方式可以很稳定之后，但是我坚信的是，录制再发展，其也是基于我们的框架上的，因为我一直相信“需求引导设计”，只有自动化测试框架才是我们需求的集合，而录制只能是我们自动化测试框架上的一种实现方式而已。