公司嵌入式部分最近一段时间在推行白盒测试，我们部门也在针对自己的代码进行尝试。有一套代码是让设备作为server，接收client发来的tcp+http+xml请求，然后进行回复。其中解析和封装并不是我们自己写的，而是用的soap工具，所以代码量非常大。现在面对这么庞大的代码进行真正的白盒测试也不现实。所以我们用soapUI来模拟client来发送xml请求，去检测server的问题。

  不知道之前进行了什么，告诉我的时候就是安装soapUI来测server，研究一下怎么用。查了资料，看了一下软件，发现我们要做的这个白盒测试是假的。忽略接口内部实现，只能测试各个xml分析回复接口。

  我只会嵌入式c，c++，java均不会。研究发现soapUI使用的是groovy脚本，和java差不多，所以做起来不太顺手。翻阅了能查到的所以博客，自己感觉没有哪一篇是非常好的。恰好今天刚好实现了自己的预期，所以写本文章，方便自己，方便他人。这几天进行了反复的尝试。

  我想实现的功能很简单。soapUI作为client，我们自己设备作为server，client反复向server发送xml请求，最简单的就是检测server是否依然依然隐藏段错误。这套代码可是不断根据现场和项目优化了好几年的工程。自认为还可以，但简单的测试就有很多段错误，不服不行，这个工具测试很有必要。谁知道哪天谁又改出什么段错误。

  xml里面有很多节点，例如某个节点叫做<profile>profiletoken_001</profile>，这个例子与我们实际的类似，但并不完全一样。节点内容profiletoken_001有时候需要从profiletoken_001循环到profiletoken_100。（第一次csdn写博客，上传的照片也不知道去哪了，凑合看吧。）像截图一样去添加n个Step也不现实，所以必须写脚本。他们的区别只是xml里面的某一个节点值，如图所示。

  用脚本中的变量替换xml里面的节点值，然后执行对应step（发送xml），功能简单描述就是这一句话。下面这一段就是我脚本源码。

1、第一行：log.info是打印。

2、第二行：虽然不能想c一样使用宏，但可以这么定义，其实简单定义一个变量就能实现，也可以查阅java，使用final static等。

3、第五行：for循环不必说。

4、第八行：cProfile = String.format("%04d", iProfile);是为了实现格式化输入，例如a=1，转换后变为0001。

5、第十行：groovy脚本中变量，字符串拼接非常自由，怎么拼都可以，格式也不是那么严格。

6、第十一行和十三行：定义一个变量，在context下面定义，在xml中即可调用。

7、第十四行：testRunner和context类似，是soapUI里面的东西，可以调用。实现对应step的调用，Step-ProfileToken+x为具体Test Steps的名字。

8、第十五行：sleep精度为ms，1000代表一秒。

 

1 log.info "TestCase";
 2def int PROFILE_NUM = 3//宏
 3 def int iProfile = 0;//该声明可以省略
 4def String cProfile;
 5 for( iProfile = 1;   iProfile <  PROFILE_NUM; iProfile++)
 6 {
 7 log.info "iProfile = $iProfile";
 8 cProfile = String.format("%04d", iProfile);
 9 log.info "cProfile=$cProfile";
 10 context.ProfileToken = "protoken_ch" + cProfile;
 11 log.info"ProfileToken = $context.ProfileToken";
 12 context.PositionX = iProfile;
 13 log.info "PositionX=$context.PositionX";
 14 testRunner.runTestStepByName("Step-ProfileToken+x");
 15 sleep(2000);//2秒
 16 }

 

  脚本写完后，修改xml文件。<wsdl:ProfileToken>${ProfileToken}</wsdl:ProfileToken>这个是其中一个节点，节点值用脚本中定义的context下面的变量替换即可。$｛变量名｝。然后就可以运行脚本了。

  创建工程，导入wsdl等就不再赘述，估计也不会影响大家的使用，网上这部分博客很多。soapUI还有很多强大的功能，针对回复断言也比较简单，一用就会，不再描述。还有针对excel等文件参数导入。soapUI的工程也不是一朝一夕完成的，一个好的工程肯定是经过团队成员不断优化，才能把一套代码检测完全。到那个时候，添加功能还是修改bug，用soapUI工程对应一跑，肯定对后期维护有很大帮助，bug暴露在结项之前，结项后就不会有纠结的现场，纠结的bug。

  后期不知道我们还会怎么用，有什么值得写的东西还会再写。感谢之前的大神们把自己的经验分享出来我才能实现自己的功能。