作者：TIB工作室成员 孙宗韬
这些天对于电信网管自动化测试项目总算是完成了一个阶段性的框架建设工作
回头简单总结一下，网管自动化项目主要分为
1、网管GUI的操作和判断
2、配置是否下发成功的判断。
而之前考虑的脚本与录制回放相结合的方法框架是不成功的，原因有几个：
1、录制的脚本识别性太差，其录制回放工具是采用的对象静态映射的机制，读取其控件的对象属性，根据对象属性的阈值进行计算判断是否能识别，因此界面控件属性的频繁变化容易造成界面对象识别困难，导致脚本频繁运行失败。
2、录制的脚本维护性太差，举个例子，若是某一个按钮是“确定”按钮，若一个项目有100个脚本，50个脚本有“确定”这个按钮，当某天，研发部门因此需求关系，将“确定”更改为“是”，那么需要更改50个脚本项目，因此维护量太大。
3、更主要的是，录制的脚本灵活性与拓展性太差，其脚本录制时主要是是按照测试用例来的，若是测试用例更改，则脚本也需要对应更改，而，更改一次脚本的工作量是很大的，而且脚本的调试过程还会消耗大量的工作时间。
因此，总体上来说，为什么很多公司的GUI自动化会失败，主要是太过于相信工具，却没有更深一层的考虑问题，没有一个适合自己公司的自动化测试框架。
因此，根据以上缺陷，进行了需求分析，总结与设计出了一个适合自身网管产品的测试框架：
1、分层，对象层、逻辑层与用例层分开，直观清晰。
2、关注性，每层只关注自己层次关注的东西，这样造成维护量大大减少。
3、耦合性，各层之间没有影响，各层之间的耦合性低，靠的是接口来传递参数。
4、由脚本分别进行对设备与网管的操作，可以完成项目的第二个部分。
实践证明，利用这种框架搭建出来的测试项目，完全比以前的录制回放和一些脚本技术相结合的框架好多了。而且实践中，录制这种手段已经基本被抛弃了，只是用到了工具的对象识别技术和一些类及方法库。
目标发展：什么时候能做到脱离工具或者直接应用开源的工具搭建一个稳定的框架就OK了。