|
配置文件的内容主要分为五个部分。A、D、E部分保存的是case无关的元数据，B和C保存的是通用的header数据。 A部分的数据有：整个web service的url前缀（图中的“drapi.serviceUrl”），公用的soap header代号（图中的“drapi.headersGroup”），所有service的代号（图中的“drapi.servicesGroup”）。 B和C部分是两个公用的header。Normal和editor是他们的代号，在A中给出。Dr-api用到的header信息主要有username/password/token/target，都在这里给出。这些header会被每个case引用。 D和E部分是两个service。它们的代号在A中给出。每个service有三个字段：name表示service的名称；url表示service的url后缀。 数据文件夹里保存的是每个case的数据。数据文件夹可以再进行分层：每个子目录的名字就是上面提到的service的名字，那么该子目录下所有case访问的url都是这个service的url。每个case有XXX.input.xml、XXX.output.xml和XXX.properties三个文件表示，XXX表示case的名称（为了应用到ficus中，XXX最好不带空格，否则会被ficus分成数组）。 ficus数据驱动 数据驱动使用ficus的data_driven关键字。关于这个关键字可以参考FICUS_DataDriven。 这个关键字需要两个主要的输入：csv文件，执行单个case的关键字。Csv文件的每一行都表示一个case，data_driven会针对csv文件的每一行循环调用执行单个case的关键字。 我们需要对此编写两个关键字。第一个是读取配置文件和数据文件夹生成csv文件。这个关键字首先会读取公共的配置文件，得到service列表和输入header列表；然后创建一个csv文件，包含这几列：url，使用的Header名称，case名称，XXX.input.xml路径，XXX.output.xml路径和properties中的字段。读取数据文件夹的每个数据文件，根据XXX.input.xml/XXX.output.xml/XXX.properties的组合来添加case到csv文件中。 第二个关键字是用来执行单个case。输入就是csv文件的一行。首先根据使用的Header和XXX.input.xml拼装成输入的XML包，使用HTTP方式向Web Service Server发送请求，接收HTTP相应，解析出Header和Body，将Header中个字段和XXX.properties中的个字段做对比，将Body和XXX.output.xml做对比。 ficus调用java关键字 我们写关键字使用的是Java，这里简单提一下如何用ficus调用java关键字（感谢朱雷同学的帮助）。在最新版的ficus程序里，有一个Java目录，有一个ficus-java-stub.bat文件。将自己写的java关键字打成jar包，放到这个目录，然后启动这个文件就可以启动ficus的Java桩。在写case的时候，首先要添加library，为了使用Java桩，需要添加FicusProxy.JavaProxy | XXX | YYY | localhost | 2345。XXX和YYY都是java关键字所在的public类的类名，这些类的public方法名称都是ficus关键字。 它的原理是：FicusProxy.JavaProxy是一个python关键字，当ficus遇到一个关键字的时候，会通过JavaProxy来查询。JavaProxy会通过socket发送请求到Java桩。Java桩加载了java关键字所在的jar包，因而可以通过反射找到以关键字为名字的方法，从而实现调用。 提示一点，如果自定义的java关键字（都是java方法）所在的类比较多，那么最好把FicusProxy.py的BaseProxy的_receive函数的length默认值改大一点儿，这个值表示ficus和Java桩通信每次发送的数据长度。如果太小，发送的数据会被截断，包含关键字名称和参数那部分会被截断，就会出错。 总结 以上便是我们在HTTP层面进行Web Service测试的总结。这种方法由于需要手动构造输入和输出SOAP包的body，因而在数据量较小并且不关注输出包body的场景使用起来很方便。由于使用的数据驱动，也很方便应对接口的变动。 后续考虑迁移到eFicus中，实现case的管理和执行一体化。
| 
