自动化测试-EOS产品集成验证整体框架

一.工具名称

   EOS产品集成验证整体框架

二.参与人员

   负责人：谢国正     

        主要参与人员：王俊其、李舸

三.背景

    对于版本的验证，版本数量与测试的工作量都比较大，如果采用手工的集成验证方式，要获取验证的测试报告，验证一个版本周期较长，且工作效率非常低。为了提供一种高效地验证与回归手段，自动化测试方案是势在必行，因此需要一个支持自动化测试执行的框架，以满足我们更高的测试要求：
    1、必须能够自动连续执行所有用例。
    2、能够分模块生成测试报告。
    3、能够自动发生测试结果邮件。

四.工具主要特性和功能介绍

       新的集成验证框架，不仅能满足以上三个基本要素，而且可以实现多测试机同时测试。如果说前面三个基本要素，可以实现一个测试机的自动化集成验证。那么实现多测试机通知机制后，就可以多机同时进行。将测试人员的工作量减少到最小。极大的提高集成验证的工作效率。

五.工具的总体设计思路

1、  基本框架的说明

1）、概述

根据EOS6的测试需求，与Server相关的测试包括两个方面：即运行期（Server启动）测试与非运行期（Server不启动）测试。

    对于非运行期的测试相对比较简单，所有的测试用例基本上都可以用java代码编写，用Junit测试框架执行。

 但对于运行期的测试，相对来说，场景比较复杂，在编写测试用例的时候，会因为业务场景的不同而采用不同的格式，主要有：jsp(包括TagUnit对Tag的测试),页面流，逻辑流，由于测试页面流都运用了Mock的方式去执行，Jsp(包括TagUnit)用例也可以用Java以URL的方式调起并运行。因此用例主要就可以归纳为两个类，即Junit用例与逻辑流用例。

2）、基本原理

测试框架基本原理是：用例解析－》用例执行－》生成测试报告---》发送报告邮件
3）、使用方法

测试框架的调用方式主要是Junit与逻辑流，主要功能有对测试用例的执行、用例统计、生成测试报告并以邮件的方式发送给接收人。测试用例与框架实现了完全的松耦合，如果测试用例需要在框架中运行，则需要在用例对应的Contribuion的[配置信息](META-INF)下新增cases.xml文件用于对测试用例的描述。

对应Schema如下：
用例描述如图所示：

说明：

1、  用例描述支持多级嵌套；

2、  对于同一类型的用例只要指定父节点的caseType类型即可，子节点可以不用另行指定；

3、  用例描述中只有name属性是必须的；

4、  对于Junit用例，只要描述执行入口测试类即可；

5、  默认所有用例有效，如果设置isValid属性值为false，则用例为无效，如果父节点设置了其值则对子节点描述的用例均为有效，用此功能可控制某一Contribuion下的地所有用例暂时不执行；

6、  用例对的id与parentId默认会自动生成，也可自定义，可以方便用例的归类展示；

7、  Action属性指的是用例的执行Action；

8、  其它用例属性可以依情况设定。

4）、执行方式

本测试框架的运行主要提供了两种访问方式：

a、  以逻辑流的方式执行；逻辑流为：com.primeton.eos.test.framework.biz_framework.new_test_run
b、  以页面展示的方式选择性执行。

页面入口为：

url：http://localhost:8080/eos-default/framework/index.jsp

2、多机通知机制的架构：

                                           图 1

       如图1所示，整体设计思路是：架设一台主管测试的司令机，将所有的监控和触发工作交给司令机来完成，士兵机只负责执行测试。（得到软件分层理念的启发）如果要多加测试环境就只要多加一个士兵机。

       下面以一个士兵机为例，说明一次自动集成验证的过程：
 如图所示，日编译完成后由司令机，通知士兵机开始安装新版本，士兵机完成安装后再通知司令机，测试环境已经准备好了（待命状态）。司令机发出调用（http），士兵机自动执行。

整个过程简单清晰，扩展性好。

六.工具的不足以及未来的发展和扩展计划

1、 多机通知在士兵机的执行过程中，经常挂起。分析可能是因为：司令机Http访问是有命令方式触发的（C start）带来的。初步的改进计划是，通过java 的URL类的实现HTTP调用。这样的实现方案可以提高执行效率，而且可以增加框架的稳定性；
2、 不支持带参数测试用例的执行；
3、 没有对测试对象测试覆盖率的统计功能；
4、 框架的扩展性比较强，对于jsp页面类型的用例以及Tag的测试，将来都可以纳入到本框架内进行测试；
5、 生产的测试报告还比较粗糙，统计功能不够强，还需要进一步完善。

七.补充内容:

1、框架项目资源路径：

     cvs:192.168.2.25:/cvsroot/EOS6V/develop/test/stest/server/test-framework

2、链接wiki资源：

     《集成验证自动化框架的总结和展望》：

   http://192.168.1.28:8080/pages/viewpage.action?pageId=5614156

《集成验证自动化框架的总结和展望》：

http://192.168.1.28:8080/pages/viewpage.action?pageId=7046061