网管自动化测试项目实践联想（GUI测试框架测试设计思想）

散步的SUN

这些天对于电信网管自动化测试项目总算是完成了一个阶段性的框架建设工作

回头简单总结一下，网管自动化项目主要分为

1、网管GUI的操作和判断

2、配置是否下发成功的判断。

而之前考虑的脚本与录制回放相结合的方法框架是不成功的，原因有几个：

1、录制的脚本识别性太差，其录制回放工具是采用的对象静态映射的机制，读取其控件的对象属性，根据对象属性的阈值进行计算判断是否能识别，因此界面控件属性的频繁变化容易造成界面对象识别困难，导致脚本频繁运行失败。

2、录制的脚本维护性太差，举个例子，若是某一个按钮是“确定”按钮，若一个项目有100个脚本，50个脚本有“确定”这个按钮，当某天，研发部门因此需求关系，将“确定”更改为“是”，那么需要更改50个脚本项目，因此维护量太大。

3、更主要的是，录制的脚本灵活性与拓展性太差，其脚本录制时主要是是按照测试用例来的，若是测试用例更改，则脚本也需要对应更改，而，更改一次脚本的工作量是很大的，而且脚本的调试过程还会消耗大量的工作时间。

因此，总体上来说，为什么很多公司的GUI自动化会失败，主要是太过于相信工具，却没有更深一层的考虑问题，没有一个适合自己公司的自动化测试框架。

因此，根据以上缺陷，进行了需求分析，总结与设计出了一个适合自身网管产品的测试框架：

1、分层，对象层、逻辑层与用例层分开，直观清晰。

2、关注性，每层只关注自己层次关注的东西，这样造成维护量大大减少。

3、耦合性，各层之间没有影响，各层之间的耦合性低，靠的是接口来传递参数。

4、由脚本分别进行对设备与网管的操作，可以完成项目的第二个部分。

实践证明，利用这种框架搭建出来的测试项目，完全比以前的录制回放和一些脚本技术相结合的框架好多了。而且实践中，录制这种手段已经基本被抛弃了，只是用到了工具的对象识别技术和一些类及方法库。

目标发展：什么时候能做到脱离工具或者直接应用开源的工具搭建一个稳定的框架就OK了。

gaha

LZ的思路说的很明白，其实就是因为存在那些弊端，所以我不喜欢用QTP做自动化，太多限制，而且不够灵活不说，他本身也存在隐患。

所以现在我就是:
1 通过selenium-IDE对执行步骤的识别，控件等的定位，逐步编写执行脚本；
2 自己根据判断的形式和结论的内容写不同的class和方法；
3 同样有针对界面的判断和后台业务逻辑，数据库操作的不同class，实际等同于检查点；
4 再编写一些写表的方法，基本就差不多了。
5 导入适当格式的用例去跑吧。

pengwentao

学习了。

shang2305

不知道 你放弃了录制和回放脚本，最后你用的什么工具？ 我现在也纠结这是否用脚本录制与回放这种方式

散步的SUN

回复 2# cnsong99
不好意思，设计公司利益问题
不过可以一起学习交流一下，阁下在哪个城市工作？

cnsong99

我也是做电信项目的。你可以把你的自动化框架和代码共享吗谢谢了