本文主要介绍了在某单位实施自动化测试过程中，如何编写自动化测试用例，保证自动化测试框架满足测试需求。 因为测试内容多，执行时间长，环境特殊，所以在编写用例过程中对测试公共方法优化，并编写自动化测试用例工具，下文描述了详细优化内容以及达到的效果。

摘要

本文主要介绍了在某单位实施自动化测试过程中，如何编写自动化测试用例，保证自动化测试框架满足测试需求。 因为测试内容多，执行时间长，环境特殊，所以在编写用例过程中对测试公共方法优化，并编写自动化测试用例工具，下文描述了详细优化内容以及达到的效果。

web测试方式

1、测试内容分析

某单位整体开发比较规范，一般流程图都是按照规范开发的，

以业务流程的流程图为示例；

从测试角度分析，定义统一的测试方法：

业务流程中需要验证的是环节和由环节串起来的总场景。环节中需要验证环节中页面的字段，和字段的校验；场景需要考虑是否有分叉，有流转条件等情况。

为了测试页面，需要准备测试数据，凡是页面上输入字段内容要从AS400库中读取的表或字段，都需要放入案例准备库，录入复核中的相关数据，都需要放入案例准备库。

2、测试用例实现

1）测试架构

按照测试分层的测试架构方式，测试用例都是被统一测试平台调用；因为项目组中普遍使用的是EOS开发，拖拽的方式使用起来比较方便，所以测试部封装了运算逻辑方便测试调用，测试用例都是由技术组件和业务组件组成，业务组件是和业务相关的内容，是指开发过程中持续积累的。

最底层的逻辑流中调用的都是运算逻辑，调用的是封装好的组件，例如登录页面打开菜单的逻辑流test.web.bpm.qsbHelper.startBrowse.startBrowse_zhxz ：

一个环节的完整输入内容并提交的逻辑流：test.web.bpm.qsb.J023_ETFJJDMWH_ZHXZ.ZHXZ_YWSL_110.ywsl_110Pass

整体场景，串起所有环节的内容：

test.web.bpm.qsb.J023_ETFJJDMWH_ZHXZ.ZHXZ.testScene2，“110_业务受理”图元调用了上面的逻辑流：

按照逐层嵌套功能的方式，通过逻辑流调用公共组件方式，提供的公共组件有两类：一类是技术组件，和业务无关，具体对浏览器操作，一类是业务组件，和业务相关，只需要传参数就可以使用，提高构件的复用度，降低编写代码的难度：

    技术组件，例如模拟鼠标事件进行点击或者双击鼠标，获取文本框的信息，做最基础的键盘操作等和业务无关的组件；业务组件，提供了和EAI中流程相关的业务操作，例如登录，领取代办任务，文件上传，EAI菜单等组件，目前不包括通用的verify，共有62个业务组件，测试用例开发人员可以直接调用相关的业务组件。

2）测试组织

定义具体的测试代码结构和命名规范：

 业务流程：

测试业务流程过程中，按照业务流程图的编号，定义每个环节和场景的包名。

一般环节的测试内容是打开了页面后进行字段的校验，所以每个环节的正常操作是先执行任务到那个环节，再在页面中检查验证点。从页面组织的角度是每个环节定义一个before的逻辑流，用来从环节1走到要验证的环节，然后再执行其它的验证点，执行完成后需要退出登录，关闭浏览器。

为此，框架新扩展了功能，就像junit测试中的before和after，配置测试用例，配置了before和after内容的，在执行前都会先执行before，在执行后会执行after。同时根据utp中选择的用例来决定是否执行before和after。对于一个环节来说，只选择了1个用例，会执行一次before，after，选择全部的用例，也会只在最开始执行before，在最后执行after。

 <handler beforeAction="test.web.bpm.fxb.F026_GSZFXDJ.GSZ_GSYXLR_111.before111" afterAction="test.web.bpm.fxbHelper.startBrowse.after" execute-rule="batch">

   <case>test.web.bpm.fxb.F026_GSZFXDJ.GSZ_GSYXLR_111.boxnumVerify</case>

   <case>test.web.bpm.fxb.F026_GSZFXDJ.GSZ_GSYXLR_111.companyfullnameVerify</case>

  <case>test.web.bpm.fxb.F026_GSZFXDJ.GSZ_GSYXLR_111.companyshortnameVerify</case>

 </handler>

 录入复核

在测试录入复核过程中，为了保证测试用例之间的数据相互不干扰，几乎每个测试用例都需要进行数据库初始化的操作，数据库分层主要分为：基准数据，流程数据，案例数据。其中基准数据和流程数据是初始化到一个运行库中，内容较全面，初始化时间也较长，案例数据是初始化到另外一个运行库中，内容较少，初始化时间较短。

为此，框架新扩展了功能，支持测试用例的AS400的数据库初始化操作：

<handler dsName="as400">

       <case id="CASE00543">CGFYBDPF01-showManager-testScene009</case>

       <case id="CASE00535">CGFYBDPF01-addManager-testScene001</case>

       <case id="CASE00536">CGFYBDPF01-addManager-testScene002</case>

<case id="CASE00537">CGFYBDPF01-addManager-testScene003</case>

</handler>

因为设计时，每个初始化操作都对应了案例编号，所以只需要配置对应的案例编号。虽然也提供了初始化400数据库的公共方法，但是使用目前这种方式，可以不用全部执行基准数据和流程数据，而根据所选择的用例只执行一遍，因为一个配置对应的是一组基准数据和流程数据，这样既方便编写代码，也加强了规范，还提高了执行效率。

问题和方案

搭建了整体的环境，采用了上述的管理框架后，整体功能实现没有问题，只是在性能和稳定性上需要继续做优化。

1、测试用例编写效率

问题：

1、 按照最基本的测试用例编写方式，根据测试设计，编写对应的测试逻辑。最开始编写加调试一个40个环节的流程，需要1个人月

2、 因为必须要使用逻辑流开发，所以对于测试人员来说需要熟悉EOS，熟悉逻辑流开发，调试。

原因：

一个流程有40个环节，分析流程图后可能需要5个测试场景，就有5个逻辑流；每个环节对应的完整操作至少需要40个逻辑流；每个环节有10个字段，就需要10个逻辑流，这样这个流程就需要145个逻辑流用例。字段校验的逻辑流是复用的，其它的逻辑流都需要一个个图元拖拽，设置图元属性，整体花费的时间较多。最开始编写加调试一个40个环节的流程，需要1个人月。

改进：

1） 提供业务流程用例生成工具：

 通过解析流程图来分析业务场景，生成场景代码

 通过读取在数据库中的业务流程的环节配置来生成校验字段代码

 通过代码中字段的规范，默认填入字段的xpath

生成代码按照最初定义的组织结构和规范生成，此工具是另一个开发商开发，是开发了eclipse的一些插件，选择流程图即可生成代码，生成代码前对于多路分支需要进行一些配置，生成代码后需要参考设计文档，对生成的测试用例中的用户名/密码，环节字段值等进行修改。并最终进行调试。

这种方式的好处是：

 基于已经配置完成的流程生成代码，效率较高

 生成和规范一致的代码，规范性较好

 生成的逻辑流代码，有不通用的场景时修改方便，灵活性较高

这种方式的劣势是：

 根据开发的代码生成测试用例，不符合测试开发流程

 生成测试用例代码较多，代码维护工作量较大

 对测试人员要求没有降低，还是需要会逻辑流开发、调试

2） 提供录入复核用例配置工具

 根据录入复核的一般操作，建立录入复核测试模型

 通过页面配置完成测试用例编写，生成的是一组配置文件

 页面配置界面中通过代码中字段的规范，默认填入字段的xpath

录入复核页面配置一般操作方式是：配置待测试的录入复核编号和名称 ，配置登录用户名/密码，登录菜单 ，配置测试的执行步骤，配置字段的校验值。配置完成后进行调试录入复核测试用例。

这种方式的好处是：

 按照测试设计文档进行配置，效率较高

 生成的是配置文件，代码维护工作量小

 不依赖开发代码，可以实现开发、测试并行

 测试人员了解业务即可，要求不高

      这种方式的劣势是：

 按照固定步骤配置，灵活性不高

效果：

改进后，一个40个环节的业务流程加调试从1人月，到只需要5人日。

一个录入复核原本编写逻辑流用例加调试需要10人日，改进后需要2人日。

2、测试用例执行效率

问题：

大的业务流程执行时间过长，一个40个环节的业务流程需要12小时。

原因：

测试一个业务流程的过程是需要验证每个环节和场景的。每个环节的验证需要先走到那个环节，然后再进行验证。这样40个环节的业务流程，环节的验证中，第一个环节就走了40遍，第二个环节走了39遍，第三个环节走了38遍，所以加起来的时间就很长.

改进：

1、 分环节验证时，提供公共方法，直接从开始跳到待测试的环节进行字段校验

2、 因为有些页面跳转比较慢，页面等待时间是写定等待多少秒，而实际等待的时间并不是固定的，改进方式是提供公共组件方法可以等待对象出现再进行下一步操作。

效果：

一个40个环节的业务流程只需要2个小时。一个350个环节8个分支的业务流程需要10小时。

总结

某单位在实施自动化测试过程中遇到了时间紧，编写用例任务重，人员基础低等诸多问题，在解决问题过程中，我们优先解决了可用性，再解决易用性，为了提高性能，新开发了几个工具，从目前来看解决了某单位今年的测试内容，也降低了编写用例的难度。

上述是列举了几个典型问题，未来的改进可能需要从易用性的角度和从管理者的视角考虑，希望上面的总结内容能给未来实施的同学一些启发。也希望我们的产品发展越来越好。