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

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

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

　　四、如何应用“录制”

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

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

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

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

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

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

原创作品，转载时请务必以超链接形式标明本文原始出处、作者信息和本声明，否则将追究法律责任。