【IT168 技术文档】最近在webservice的项目中，主要使用SOAPUI进行webservice的测试，SOAPUI是一个开源的测试API的工具，对于现在的SOAP，REST的webservice的支持都很好。下面简单介绍下SOAPUI的原理，SOAPUI和大多数的工具一样，都是使用HTTPREQUEST对相应的资源进行请求很提取。再得到response之后进行相应的处理，对XML进行XPATH定位。注意的是SOAP方法中包含GET，POST的方法，POST的方法主要使用Application/xml的MIME形式发送相应的POST数据。这里注意webservice都有一些通病，对SQLinjection基本都没有相应的保护，所以我们要注意的是对webservice中POST的数据进行校验。也就是通常所说的安全校验。
对webservice的测试主要分为两个阶段，首先是对WEB Ui层面的数据XML Response与webservice的schema进行对比测试，其次是web Ui层面的数据与数据库服务器中相应的数据进行验证。这两个阶段的测试必须进行对比，以防止webservice的编写严谨度不够。
在实际项目中遇到过这样的一个BUG，在UI界面的功能中，详细信息中的必填项（非0）与受限制项（比如有文本限制，字体限制等等）在webservice实现中没有体现，我们可以用0值POST到数据库中。主要是由于开发在wenservice编写中没有校验和严谨的设计。
SOAPUI支持的语言是GROOVY，作为JAVA的脚本语言，GROOVY的扩展性很强，再加上SOAPUI中原本实现的utils类能对相应的response进行XPATH的定位，得到相应的数据进行验证，在webservice实现中还能够使用property transfer进行对参数的传递，功能十分强大。
在使用SOAPUI前如果是大数据量的，比如100个CASE对数据的查询比较频繁，建议在使用前，对SOAPUI的JVM的设置提高，建议在1G左右，这样可以提高SOAPUI的可用性。
下面，将具体对SOAPUI的脚本编程和进阶使用进行分析。
SOAPUI的使用之前介绍的有两方面。先介绍第一种测试。
就是对schema及Response XML的验证，这里主要的流程是：
第一步，将resource对应到您相应要测的XSD文件，也可有WSDL或者WADL加载生成。然后加入对应比较的resouce源，即响应response的URL。
第二步，比较相应的XML和XSD。比较方法有两种。
第一种方法是讲对应的XSD和Response XML利用JAVA程序进行比较，对应的读XML的方法有多种，SAX，DOM，JDOM，4JDOM等等，您可以选择相应的进行比较。之中4JDOM对XPATH支持，并且其的算法支持大数据量，性能比较好。
下面是对应test case RESPONSE的获得：
def step = testRunner.testCase.testSteps["XXXX"]
def result = step.testRequest.response.contentAsString
第二种方法是用SOAPUI支持的groovy语言进行比较，以下有个简单的实例，您可以扩展：
import javax.xml.transform.stream.StreamSource
import javax.xml.validation.SchemaFactory
def factory = SchemaFactory.newInstance(XMLConstants.W3C_XML_SCHEMA_NS_URI)
def schema = factory.newSchema(new StreamSource(new StringReader(XSDFILEREADERXX)))
def validator = schema.newValidator( )
validator.validate(new StreamSource(new StringReader(XMLFILEREADERXXXXXX)))
第三步，这里您能在每个test case的界面设置相应的assert点，您也能在后台的groovy语言进行assert。
在groovy脚本中您能使用相应的ＩＯ操作进行对测试结果的输出，这里项目中使用对应的txt文档配置需要测试的测试用例，并对测试结果进行输出，报错机制要完善哦，呵呵。
第四步，我们这里需要使用testrunner.bat -s XXXXX,XXXXX对应您相应的TestSuite名称，如果有多个suite，您可以使用组合命令自动化，对JAVA程序的调用可以写成相应的ANT脚本，之后用.bat文件进行自动化测试。
这样您就完成了第一步的对schema的验证测试。
NOTE：注意的是大部分的schema的bug是由相应的sequnce的设置原因以及元素的缺失。在测试的同时我们还要重视非法数据的使用，特别POST的数据。这里提醒有时soapUI的POST方法需要您选择MIME类型，才能发送正确的数据，大多针对UI层能正确使用，但soapUI测试出现 HTTP500-错误的情况。
介绍第二种测试。
就是对API编写是否正确严谨的验证，这里主要的流程是：
第一步，加入对应比较的resouce源，即响应response的URL。
第二步，比较相应的XML和对应数据库服务器的数据。
比较方法有两种：
第一种方法是将对应的数据库数据利用JAVA程序组成acutual的XML数据与相应的Response XML进行比较。可以使用相应的GROOVY的脚本进行XML的重组。
import groovy.sql.Sql def xml = new groovy.xml.MarkupBuilder(writer) |
然后使用Diff进行比较：
def xmlDiff = new Diff(expectedResult,acutualResult) |
第二种方法是用SOAPUI自带的groovy utils类进行XPATH的操作，以下有个简单的实例，您可以扩展：
def groovyUtils = new com.eviware.soapui.support.GroovyUtils( context ) |
XXXXX：您对应的SOAP或者REST的test case步骤。
YYYYY：对应的Response的XPATH定位。
摘取相应的数据和数据库比较。
第一种方法比较全面但扩展性较差，第二种方法的扩展性不错，而且易于修改，但是其可能会遗漏一些边缘的BUG。
第三步，我们这里一样需要使用testrunner.bat -s XXXXX,XXXXX对应您相应的TestSuite名称，如果有多个suite，您可以使用组合命令自动化。
这样您就完成了第二步的对API编写是否正确严谨的验证测试。
这里并没有结束，这里需要您进行第四步测试，在对应的GUI测试中功能测试中出现的BUG需要在API中进行验证，防止API的严谨性差。与之前提到的例子主要集中在Negative和Boundary的test case验证，保证webservice API的正确及安全性。
附加：这里您也能对API的POST数据进行简单的SQL injection测试，大部分的API由于使用的工具或者简单代码编写致使出现类似的安全漏洞。
