webservice接口功能自动化测试准备工作（转）

在一些集成系统中会经常用到webservice，并且这些web服务又往往作为最底层的东西支撑着这个系统。因此，对于webservice的测试才显得异常的重要。下面简要谈一下我对webservice功能测试的一些个人观点。

一、用例设计及开发

在用例设计及开发之前，我们需要对webservice中包含的方法做一些简要的分析。主要从以下几个方面考虑：

（1）哪些方法可能需要使用工具手工测试。

（2）哪些方法可以使用工具自动测试。

（3）哪几个方法可以组成一个业务场景。比如订票和退订的两个方法。

（4）哪些方法可以用于构造业务场景的初始化数据。

（5）哪些方法在开发过程中会经常用到，是需要重点测试的。

（6）分析每个方法，看看他们被调用后返回的结果是可以直接查到还是需要通过调用其他方法才能查到。

（7）根据方法实现的难易程度划分场景。

（8）方法调用后的验证方式。

（9）接口中是否有枚举类型。

当然以上只是一个参考，前期如果考虑的很多，越对后面的测试有利。很多情况下，接口的测试是否很充分就决定于前期的准备工作，而不是后面的测试实施。

再对接口做过比较详细的分析后，我们往往可以得出这些东西：

（1）接口形成的场景集

（2）可以使用工具手工测试的接口集

（3）可以使用工具自动测试的接口集

现在可以根据我们的分析结果来设计测试用例。将用于场景集的接口，我们的测试用例需要考虑到测试数据的重复使用以及接口间数据的传递；可使用工具手工测试的接口往往本身比较简单，但是构造数据以及验证结果往往会比较麻烦，所以在用例设计和开发的时候务必要将初始化数据构造及结果验证步骤写详细；可使用工具自动测试的接口，则要考虑到初始化数据的构造和回收，设计的思路应以简单的输入数据为主（数据驱动）。

为什么说使用工具手工测试和使用工具自动测试。因为前者使用的工具简单，但需要用户手工对每个方法的参数进行填写，每次只能执行一条用例。后者，则只用绑定数据库或数据表等快速自动执行每一条用例。后面介绍到测试工具的时候，就可以理解者一点了。

二、测试工具选择

网上有很多介绍webservice功能测试的工具，在这里我只做一些补充。感兴趣的朋友可以查看相关资料。

（1）webservice studio

这款微软出的小工具，十分好用。但其致命的缺点就是不能数据驱动，也就是说不能捆绑用例。但是用作手工测试还是戳戳有余的。有一点，可以注意一下：使用这个工具测试某个方法的时候，如果其中一个参数需要出入空值，你不能就直接不填，你需要在工具中把该参数的ISNUll属性选择True。否则可能会出现与预期不一致的结果。

（2）soatest

这个工具应该非常好了，自身功能很强大，并且可以使用javascrip扩展其功能。可以捆绑数据并且允许在工具中对某几个方法合并后一起管理（即创建一个test suit）。soatest不论是管理脚本还是捆绑数据以及结果展现都是非常优秀，但是也是存在一些缺陷，比如：如果某个方法中存在枚举类型的参数，你就必须编写复杂的脚本去扩展，否则是不能直接捆绑这个枚举类型的参数测试数据。

（3）QTP

好了，谈谈QTP测试webservice了。第一反应，要用到QTP的webservice插件。其实这也是没必要的，具体可以参看我的前一篇文章（vbs测试webservcie）。那个脚本就是使用vbs去测试webservcie的，而不是使用QTP的扩展插件。

当然，作为备选方法，QTP的webservice插件还是可以考虑一下的。其实QTP使用webservice插件后录制webservice的脚本会很少，最重要的是XML检查点可以自动产生，减少捆绑数据时候的麻烦。

三、webservice测试完成后的自动化实施

其实接口测试完成后的脚本会对我们的系统集成很有好处。我们可以用这些接口脚本来构造我们的初始化数据，为我们后面的系统自动化实施打好基础。