自动化测试的一些思考与总结

自动化测试环境的准备

Eclipce+Maven+Testng+Selinum+Firfox

Test Case的编写

（1）对于自动化代码层次的划分。

1. Action：该包是自动化测试用例的方法入口，每一个Action对应一个功能模块，命名规则以功能模块所在页面的URL名称近似，见其名如见其模。

   ​ 例：开源信息管理功能模块的URL：opsInfoManager，相互对应的Action就命名为OpsInfoManagerAction.java，每一个Action中可以划分为三个部分：setup、test case、tearDown。setup中可以完成执行这个action所需要准备的工作，如驱动打开一个浏览器，执行sql操作准备数据环境；test case是多个方法，每个方法对应该功能模块的每一个功能测试点，以方法名称的首字母控制执行顺序；tearDown中主要的clear刚刚执行的case遗留的测试数据，保证每一次执行该Action的前后环境没有被改变。

2. Page：这包是为Action提供具体方法，每一个Page与一个Action相互对应，命名规则以功能模块所在页面的URL名称近似，如开源信息管理功能模块的Page命名规则就是OpsInfoManagerPage.java。如此抽取实际的操作函数是为了尽量保证Action的代码简洁明了，具体实现交由Page来操作。例：如果想要测试新增一个许可协议，那么只需在Action中的test case部分加入一个测试方法。

   Public void atestAddLisence() throws Exception(){
    boolean res=true;
    res=res && HomePage.login(driver);
       res=res && HomePage.toManager(driver);
    res=res && ConfigManagerPage.addProtocol(driver);
    assertEquals(res , true);
   }
   

   可以看到这个方法中简单明了的指出新增一个许可协议需要的几个步骤：

   ​ *****（1）登陆指定的网站

   ​ *****（2）进入到指定页面

   ​ *****（3）执行新增操作

   ​ *****（4）判断执行结果

   Action不需了解具体每一步是如何执行的，只关注执行的结果，具体的执行步骤、页面元素的定位都是封装在Page里面。

3. page.properties文件

   该文件是页面元素的Xpath与Class的存放文件。讲Page中的获取元素的操作与元素具体的Xpath和Class抽离更方便后期的维护与管理，而Xpath和Class的命名规范自己定义，但是尽量能够见名如见其意。如：

   ​ 配置管理中的新增应用类型的button命名为：

   ConfigManagerPage.addApplyBtn_xpath
   ConfigManagerPage.addApplyBtn_class

   如若使用xpath尽可能的使用元素的id进行定位，这样会节省很多后期由于页面变动，导致元素xpath定位不到导致的维护负担。

4. Utils

   该包主要提供一些工具类：数据库操作类，Json格式转换类，接口驱动类，Web驱动类等。提供一些通用的函数封装。

5. Beans

   该包主要提供一些JavaBean，目前主要是用于接口自动化编写时的Json数据域对象之间的相互转换：参数与结果集的封装。

6. uploadFiles

   该包主要存放的是自动化测试过程中需要上传的测试文件，集中管理，方便明了。

目前对于自动化测试用例的几点总结

1. 代码层次结构划分明确，有助于理解这个代码流程，可读性更高。

2. Test case中必须使用断言用来保证用例执行结果的可靠。

   Public void atestAddLisence() throws Exception(){
       boolean res=true;
       res=res && HomePage.login(driver);
       res=res && HomePage.toManager(driver);
       res=res && ConfigManagerPage.addProtocol(driver);
       assertEquals(res , true);
   }
   

3. 命名规范化，名如其意。

   随着项目的不断迭代更新，功能越来越完善，自动化用例覆盖的愈来愈多，好的命名方式对于日后的维护管理十分有帮助。

4. 每一次case的执行前后都要是干净的环境，不能遗留数据。

   每次执行结束的clear动作是为了下次的执行不受到这次执行的干扰，保证用例的可靠。

5. 数据隔离。

   同样的sql插入操作可能在不同的功能模块中都要复用，若插入的数据都一样，那么会有几个问题：

   若其中一个case执行完后clear的不够彻底，那么不光会影响这个case后续的执行，还会影响依赖相同数据的case的执行，不同case之间相互耦合，会导致case的不稳定。
   由于自动化case的覆盖率逐渐提高，那么case的数量也逐渐上升，会导致整个case执行所需的时间越来越长，为了缩短执行时间，可能会配置使得多个case并行执行，但是由于两个case并行执行的顺序无法控制，若其中一个case执行完，另一个case执行一半，此时执行完的case进行clear操作，那么就把那个执行到一般的case所依赖的数据环境破坏了，从而会导致case的失败，这样case会很不稳定。

6. 参数化，不要硬编码。

   同一个方法，可能会被不同的功能模块调用，那为了做到第五点的数据隔离，就需要尽可能的参数化，方便更改参数，维护管理。

7. 全部使用id定位元素，退而求其次使用class定位，坚决不要使用xpath很长的定位方式，减轻日后维护的负担。