专业深钻互联网软件测试技术文章，提升大家平时测试技术水平、素养和面试测试岗位的水平！...
jmeter如何将上一个请求的结果作为下一个请求的参数——使用正则提取器
转载地址：下面有三篇都是关于讲解jmeter的关联（将上一个请求的结果作为下一个请求的参数），第一篇看不懂就看第二篇，第三篇最易懂！【第一篇】1、简介　　Apache JMeter是Apache组织开发的基于Java的压力测试工具。用于对软件做压力测试，它最初被设计用于Web应用测试但后来扩展到其他测试领域。 它可以用于测试静态和动态资源例如静态文件、Java 小服务程序、CGI 脚本、Java 对象、数据库， FTP 服务器， 等等。JMeter 可以用于对服务器、网络或对象模拟巨大的负载，来自不同压力类别下测试它们的强度和分析整体性能。另外，JMeter能够对应用程序做功能/回归测试，通过创建带有断言的脚本来验证你的程序返回了你期望的结果。为了最大限度的灵活性，JMeter允许使用正则表达式创建断言。　　Apache jmeter 可以用于对静态的和动态的资源（文件，Servlet，Perl脚本，java 对象，数据库和查询，FTP服务器等等）的性能进行测试。它可以用于对服务器，网络 或对象模拟繁重的负载来测试它们的强度或分析不同压力类型下的整体性能。你可以使用它做性能的图形分析或在大并发负载测试你的服务器/脚本/对象。2、用途1.能够对HTTP和FTP服务器进行压力和性能测试， 也可以对任何数据库进行同样的测试（通过JDBC）。2.完全的可移植性和100% 纯java。3.完全 Swing 和轻量组件支持（预编译的JAR使用 javax.swing.*)包。4.完全多线程 框架允许通过多个线程并发取样和 通过单独的线程组对不同的功能同时取样。5.精心的GUI设计允许快速操作和更精确的计时。6.缓存和离线分析/回放测试结果。3、下载、简单应用　　下载、简单应用可参照：4、如何将上一个请求的结果作为下一个请求的参数　　在压力测试的时候，经常要将几个流程串联起来才能将程序测试通过。如：我现在用户首先要登录，获得我登录的凭证（tokenId），之后我的请求其他的资源的时候需要带上这个凭证。才能识别你是否是合法的用户。1）、创建一个线程租2）、创建一个获取凭证的请求3）、创建后置处理器　　 JMeter GUI 视图中右击该采样器打开右键菜单 -& 添加 -& 后置处理器 -& 正则表达式提取器，打开"正则表达式提取器"会话页面并编辑其内容如下：　　后置处理器是当这个请求返回后要做得事情，我这里是要从返回的内容中将我们要的tokenId获取出来。这里使用“正则表达式提取器”，用正则表达式，将我们要的内容获取出来。4）、正则表达式提取器配置引用名称是下个请求将要引用到的变量名；正则表达式是提取你想要内容的正则表达式，小括号()表示提取，也就是说对于你想要提取的内容需要用它括起来；模板是使用提取到的第几个值。因为可能有多个值匹配，所以要使用模板。从 1 开始匹配，依次类推。这里只有一个，所以填写 $1$ 即可；匹配数字表示如何取值。0 代表随机取值，1 代表全部取值。这里只有一个，填 1 即可；缺省值表示参数没有取到值的话，默认给它的值。一般不填。这个请求返回的数据如下：{"message":"success","statusCode":200,"registerDay":"20","tokenId":"bf5ae22885f5"} 　　我们现在要获取的是上面这个json字符串中tokenId的值，即
bf5ae22885f5
。5）、添加下一个请求　　在这个请求中，我们要将上面的tokenId作为一个参数一并发送。　　同上2）、添加一个http请求（线程租右键——》添加——》Sampler——》HTTP请求） 6）、添加查看结果树　　7）、执行后，即可通过”查看结果树“查询 　【第二篇】正则表达式提取器是一个后置处理器，作用是在请求完成后，从响应数据中截取一部分字符串保存到变量中，以便下一个请求使用,下面我们就来做一个简单的例子吧1.首先在线程组下添加两个HTTP请求，2.添加好两个HTTP请求后，在每个HTTP请求下添加一个查看结果数3.在第一个HTTP请求下添加正则表达式提取器4.在第一个HTTP请求添加好IP地址，路径，端口号，协议，方法，如果有参数，还需要添加参数，我这里没有参数所以就不添加了5.点击绿色箭头启动，查看第一个HTTP请求完成后的响应数据6.第一个HTTP请求完成后的响应数据的url是随机变化的，每次HTTP请求完成后的响应数据的url是不同的，现在需要获取第一个HTTP请求完成后的响应数据的url作为第二个HTTP请求的IP地址，这个时候就需要用到正则表达式提取器，正则表达式提取器是一个后置处理器，作用是在请求完成后，从响应数据中截取一部分字符串保存到变量中，以便下一个请求使用。7.现在编辑正则表达式提取器8.说明：（1）引用名称：作为下一个请求要引用的参数名称，如填写myurl，则可用${myurl}引用它来作为第二个HTTP请求的IP地址 (2)正则表达式用""包起来，如第一个HTTP请求完成后的响应数据{"status":"ok","message":"创建房间成功","data":{"url":"https://www.pp2pp.xyz/room/58ff022f5cd4c32ae9a7f457"}} 我们只需要URL,所以正则表达式为
"url":"https://(.+?)"() 表示括起来的部分就是要提取的。. 表示匹配任何字符串。+ 表示一次或多次。?表示不要太贪婪，在找到第一个匹配项后停止。（3）模板：用$$引用起来，如果在正则表达式中有多个正则表达式，则可以是$2$，$3$等等，表示解析到的第几个值给myurl。如：$1$表示解析到的第1个值，我们这里只有一个正则表达式，所以是$1$（4）匹配数字：0代表随机取值，1代表全部取值，通常情况下填1（5）缺省值：如果参数没有取得到值，那默认给一个值让它取，通常情况下为空 9.现在可以开始编辑第二个HTTP请求,10.我们再来点击绿色箭头启动，查看这两个HTTP请求完成后的响应数据，可以看到第二个HTTP请求地址就是第一个HTTP请求的响应数据的URL 11.如果是要获取第一个HTTP的响应数据的URL地址的后面数字作为第二个HTTP的参数，做法也是一样的，只是正则表达式不一样，如第一个HTTP请求完成后的响应数据{"status":"ok","message":"创建房间成功","data":{"url":"https://www.pp2pp.xyz/room/58ff022f5cd4c32ae9a7f457"}} 如果我们只需要URL后面的数字58ff022f5cd4c32ae9a7f457,那么正则表达式为
"url":"https://www.pp2pp.xyz/room/(.+?)"【第三篇】（正则表达式提取器是Jmeter关联中的一种）使用场景：有两个HTTP请求，请求A的返回数据中有一个字段“ABCD”，该字段要作为请求B的入参。1、添加方式请求A上右键--&后置处理器-&正则表达式提取器2、提取A请求中的taskCode对应的值为了获取到上图中圈起来的这个值，要配置正则表达式提取器：说明：（1）引用名称：下一个请求要引用的参数名称，如填写Atask，则可用${Atask}引用它。（2）正则表达式：　　　　()：括起来的部分就是要提取的。　　　　.：匹配任何字符串。　　　　+：一次或多次。　　　　?：不要太贪婪，在找到第一个匹配项后停止。（4）匹配数字：0代表随机取值，1代表全部取值，通常情况下填0（5）缺省值：如果参数没有取得到值，那默认给一个值让它取，我填的Error3、获取到的值传入B请求看一下请求B是否如预期的一样传入Atask这个值引用成功~~ 记录一个好用的测试正则表达式的工具：工具名称：RegexTester使用方法： 如果觉得本文的文章写得很好，打个赏，多少都行~~~
没有更多推荐了，
加入CSDN，享受更精准的内容推荐，与500万程序员共同成长！本帖已被设为精华帖！
接口测试实践的记录
在敏捷开发交付的流程中，自动化测试实际上被放在一个看起来挺重要的位置，而自动化测试中，接口测试是一个投入产出比比较高的
一种自动化测试的形式，而我自己也做了一个这样的脚手架一样的东西可以方便进行自动化测试，关键是在一些现有第三包的基础上做实现，其实一个脚手架不需要几个JAVA类就可以完成了，至少我自己的这个在10个文件以内.要论行数估计也没有多少代码量，主要时间其实都是在想怎么更方便的写自动化测试，怎么使用以后的开源代码了。
下面介绍一下我自己如何完成这个自动化接口测试
脚手架设计和实现的，以及我自己实现过程中的种种发现。主要从以下几个方面来讲：
如何构建接口自动化测试的脚手架
关于接口测试参考的一些资源
关于接口测试的后续的一些想法
如何构建接口自动化测试的脚手架
接口测试本文中主要是指HTTP的请求，构建接口自动化测试脚手架的时候，首先先看看平常接口测试，测试人员时如何做的，我了解主要是以下几种方式：
通过操作页面/APP来触发接口调用
使用诸如SOAPYUI/JMETER/POSTMAN 或者其他的客户端工具来进行接口测试
我自己都使用过SOAPUI/JMETER/POSTMAN,不能说使用的多么深入，但是常用的功能也都有用过，比如SOAPUI构建一个项目完整的接口自动化测试用例，大概有200+以上的用例，可以支持不同的测试环境，检查点中可以检查数据库,使用XPATH/XQUERY来检查／获取指定的值，进行不同API的数据传递等等，这些工具(指功能测试方面)大体的逻辑我觉得是类似的,基本上都有:
发起请求的客户端,需要测试人员构建，也有通过WSDL/WADL自己生成的，不过数据都是需要测试人员输入的
根据表达式进行取值的Resolver,就是可以根据XPATH/XQUERY语法，或者其他的语法来获取指定的值，
就是用来传递上下文数据的一种方式
外部可以参数话数据，比如环境配置
可以查看测试结果，这个其实可以理解为某种测试框架的一个功能，比如JUNIT，TESTNG
接口自动化测试脚手架的构建
根据以上的分析如果自己需要实现的话，最主要需要实现一下其实就是请求的构建，请求构建包括了:
发起请求的客户端
请求数据的构建
对于发起请求的客户端就直接使用了Spring RestTemplate,考虑的主要原因如下:
使用相对比较方便,模块化比较清晰
可以使用HTTPClient的实现
Spring RestTemplate所在的包还有其他一些接口的支持，以后如果使用其他接口可以不需要换包也可以做
在实际的使用过程中，其实也遇到了一些问题，比如如下的内容:
HTTPS的访问
开发接口定义不够准确的问题,造成使用RestTemplate时候出现了一些不在开始预期范中的问题
如何解决这些问题,在后面再详细介绍，这里说明一下使用RestTemplate的一个主要流程：
1. 构建请求，设置请求的Header，URL，Accept，ContextType，Token等等
2. 调用请求获取返回的Response，
这个ResponseRestTemplate中实际上封装了一个ResponseEntity的类，里面包括了请求状态，Body之类
RestTemplate 有个好处就是如果给RestTemplate设定了MessageConverter的话，他可以自动把请求的返回类型直接转换，比如你发起请求的时候设置了JOSN的Message Converter，他可以帮你把类，或者字符串自己转化为JSON来发送，同样如果是返回值是JSON的话，也可以帮你自己将JSON转换成你指定类型的JAVA BEAN
说完这个流程，我们就说说如何通过RestTemplate构建一个简单的HTTP请求:
Map&String,String& urlVariable = new Map&String,String& ();
urlVariable.put("q","test");
JavaBean javaBean = restTemplate.getForObject("http://www.baidu.com",JavaBean.class,urlVariable);
JavaBean javaBean1 = restTemplate.postForObject("http://www.baidu.com",JavaBean.class,urlVariable);
ResponseEntity e =
restTemplate.getForEntity("http://www.baidu.com",JavaBean.class,urlVariable);
实际上使用RestTemplate还是挺简单的，不过为了让使测试更为方便一点，然后每个人的代码更统一点，自己重新封装了一下RestTemplate的使用，主要分为三个概念:
Service 的描述
客户端调用
接口服务描述
Service的描述实际上就是一个JSON文件，只不过自己规定了一下，格式类似于,这个文件描述了API的定义，当然API的body没有在这个里面，不过为了不把事情搞复杂，就暂时不放在这个里面.
"apiDomainName": "applicationName",
"contentType": "application/x-www-form-urlencoded",
"headers": {
"Accept": "application/json, text/javascript, */*"
"method": "POST",
"pathParameters": [],
"queryParameters": [
"username",
"resourceURL": "/application/subdomain"
测试数据类：
private Map&String, String& queryParameters = Maps.newHashMap();
private Map&String, String& pathParameters = Maps.newHashMap();
private Map&String, String& headers = Maps.newHashMap();
private T body;
而如何调用客户端就变成,而且其实每一个API的访问其实都可以这样子来做，
ResponseEntity response = RestTemplateHelper.build(serviceDescriptionPath,requestData).call();
说明一下的是：
serviceDescriptionPath就是接口的描述
requestData就是需要进行测试的数据
然后实际上接口的描述是开发还没有开发好的时候就已经定了的，所以这里的变量就变成如何构建requestData了
构建RequestData
构建requestData实际上就是设计测试用例，那么这里也是使用Excel的方式，将不同的值填写到excel里面，不过为了减少set值这样的操作，这个脚手架就提供了一些工具，可以直接将数据设置到RequestData实例，具体的操作如下:
Excel是如下格式的：
data.queryParameters(username)
data.queryParameters(year)
data.queryParameters(month)
说明一下，通过反射的方式，可以直接生成一个requestData的实例,同时queryParameters中值已经设置好了，这样调用代码中就不需要写类似于：
RequestData data = new RequestData();
data.queryParameters.put("username","1");
data.queryParameters.put("year","2015");
这里有兴趣的同学可以参考这个包:里面其实已经有很方便的通过反射去赋值了,
&dependency&
&groupId&org.jodd&/groupId&
&artifactId&jodd-bean&/artifactId&
&version&3.6.6&/version&
&/dependency&
使用TestNG的DataProvider
刚才讲述了如何发生生成数据，那么通过Excel的方式提供不同的数据，就可以通过TestNG的DataProvider了
所以测试数据通过，TestNG data provider的实现在这里就不多少了，网上其实有很多内容了.
接口测试的代码看起来就是这个样子了 @DataProvider(name = "data")
public Iterator&Object[]& getAPITestData(Method m) throws Exception {
Map&String, Class& clazz = new HashMap&String, Class&();
clazz.put("RequestData", RequestData.class);
Iterator&Object[]& y = TestData.provider("testcase/api1.xls", m, clazzMap);
@Test(dataProvider = "data")
public void testAPITest(RequestData data) {
ResponseEntity response = RestTemplateHelper.build(serviceDescriptionPath,requestData).call();
Assert.assertEqual(response.getStatus,200); // response 的期望值实际可以通过dataprovider传入
而且几乎所有的代码都差不多成这个样子了，那么获取可以写个代码生成的东西,当然最后通过了JsonPath写了一些获取JSON值的工具，这个暂时也就不说了.
那么代码生成吧
当封装好这些东西之后，发现所有的接口都类似了，然后就做了代码生成的工具了,代码生成器的入口实际上个就是那个服务描述文件开始的，
所以代码生成器的参数就是服务描述文件，在实际的使用的过程中，接口描述这个文件也可以自动生成，目前总共支持以下几种:
手动编写描述文件
抓取开发API规格网站接口的描述，自动生成描述文件
解析HAR文件自动生成描述文件，解析HAR其实不难，就是繁琐一点字段有点多
后续想打通和POSTMAN的连接，可以接收POSTMAN的导出文件，然后也可以导出POSTMANT的，以后开BUG就什么也不说，直接放一个POSTMAN文件其实也挺帅的
至此一个接口测试的脚手架就大致完成了.总结起来就是:
封装了RestTemplate，让他接受一个接口的描述文件，一个请求的数据
通过Excel传数据给请求的数据进行数据驱动
相同类似的代码进行代码生成
最后其实这样子使用下来,接口构建几个简单一点的自动化测试用例，其实也就是几分钟的事情.
在实现过程中，实际上还有一些特殊情况，比如说需要token，认证信息，这些通过一个公用函数的方式就可以解决，然后在代码生成的时候
直接讲这个放在实际测试的接口前面调用. 后有就是上面说到的的:
HTTPS的访问
开发接口定义不够准确的问题,造成使用RestTemplate时候出现了一些不在开始预期范中的问题
HTTPS的访问是通过如下代码解决的,创建一个略SSL的httpclient就可以了
public static RestTemplateClientHelper getHttpClientImplInstance(){
RestTemplateClientHelper client = new RestTemplateClientHelper();
HttpClient httpClient = getIgnoreSSLHttpClient();
client.setTemplate(new RestTemplate(new HttpComponentsClientHttpRequestFactory(httpClient)));
return client;
* 获取忽略SSL的httpclient，支持https的请求
private static HttpClient getIgnoreSSLHttpClient() {
CloseableHttpClient httpClient = null;
httpClient = HttpClients.custom().
setHostnameVerifier(new AllowAllHostnameVerifier()).
setSslcontext(new SSLContextBuilder().loadTrustMaterial(null, new TrustStrategy() {
public boolean isTrusted(X509Certificate[] arg0, String arg1) throws CertificateException {
return true;
}).build()).build();
} catch (NoSuchAlgorithmException | KeyManagementException | KeyStoreException e) {
logger.error(e);
return httpClient;
还有一个就是有时开发的接口返回类型(accept type)不能让RestTemplate处理，那么其实添加自己定义个MessageConverter就好了:
下面是一个修改阿里自己的FastJSON的MessageConverter的例子,
其实也没改什么，就是捕捉了一个异常，主要是不知道什么原因调用时候readInternal就抛出和编码格式有关系的异常，然后就捕捉了一下异常反正也就把那个问题就没有了，不过这个改法应该也是有问题的.
public class ModifiedFastJsonHttpMessageConverter extends AbstractHttpMessageConverter&Object& {
public ModifiedFastJsonHttpMessageConverter() {
super(new MediaType("application", "json", UTF8), new MediaType("application", "*+json", UTF8));
this.charset = UTF8;
this.features = new SerializerFeature[0];
............
protected Object readInternal(Class&?& clazz, HttpInputMessage inputMessage) throws IOException, HttpMessageNotReadableException {
ByteArrayOutputStream baos = new ByteArrayOutputStream();
InputStream in = inputMessage.getBody();
byte[] buf = new byte[1024];
while(true) {
int bytes = in.read(buf);
if(bytes == -1) {
byte[] bytes1 = baos.toByteArray();
return JSON.parseObject(bytes1, 0, bytes1.length, this.charset.newDecoder(), clazz);
}catch (Exception e){
return baos.toString("UTF-8");
if(bytes & 0) {
baos.write(buf, 0, bytes);
后续的一些想法
后续希望在这个基础上再做点其他的一些事情:
增加POSTMAN的代码生成的支持
探索能不能通过API接口描述直接生成JMETER的JMX文件，可以讲基础的JMETER性能测试的基础代码也生成好
整理一下放到GITHUB上面，其实整个脚手架自己也就是几个文件而已，:)
建立一个MOCK SERVER，方便模拟一些API调用的方式
做一个简单点获取JSON中指定字段，然后传递给下一个API使用的工具
如果觉得我的文章对您有用，请随意打赏。您的支持将鼓励我继续创作！
感觉走偏了。。。
设计思路还是挺好的. 采用的是标准方案. 代码生成貌似没提太多, 估计是还没做吧.
基本上和我们公司现在用的框架是一致的.
你的是testng+restemplate+har代码生成.
我的是scalatest+playws+har代码生成.
还是挺像的. 思路也很像
问题在于那个描述文件 其实本身就已经跟har很接近了. 将来用起来不会太方便.
同时java的样本代码也有点多, 可以考虑进一步精简.
总体不错, 挺赞的.
代码生成其实已经做好了.如果有HAR就不用去写那个描述文件了，会根据HAR自己生成，如果接口还没有开发完成还没有实际使用过，这种情况下就只好自己去写描述文件了. 然后填写测试数据来做测试用例设计了。理想情况下(按照需求说明文档的规范做的)，开发好了，接口自动化测试也可以跑起来了。不过代码确实需要再精简，要更少代码更少代码。
下次帮我看看我那个，感觉偏了?
—— 来自TesterHome官方
有个问题想问下，你一开始有提到进行上下文数据的传递，但你文中没有提到具体的实现方式。想问下你这一块的实现是放在了 Java 里面还是在 excel 中？
目前这块做的不太好，后续需要放不少精力做这个。目前已经做的一些是这样的:
数据创建的时候根据上下问去再造点数据，比如说有些测试可能是这样的测试用例说一个已经有过订单的人，这个时候其实用例里面应该说不是具体的一个人，而是满足条件的这个人，所以在Excel里面其实是放有过订单的这个类型，然后在用一段sql去获取满足条件这样的人，那么如果一般情况时这样的话，自己写代码的话可能就是先创建个类在去执行一段sql去取值，然后再赋值给这个人，我现在做的是，创建数据类是通过一个工厂方式去创建的，然后这些根据一些初始化的内容获得的东西，都会放在beanPostConstruction中去实现，这样Excel里面填写一些关键数据，然后通过这个DataFactory去创建JAVA Bean的时候会自动运行beanPostConstruction里面的东西，这样可以少写一些代码
-还有一种就是几个API调用之后，有些内容需要从前一个API获取，再给第二个或者第三个API，这个还没有实现的很好
我自己大体的思路就是把API的返回都放到一个结果集里面，一个MAP里面，然后在根据一些传入的表达式来获取这些值，再来传递，不过还没有完全实现出来，一直没有想的太清楚这块，需要自己在写些代码试试
这块我也在想，但还没找到能兼顾灵活度和易用度的方案。
思寒这块是怎么做的？
另外这块我觉得和开发的规范有关系，如果一些返回字段实际是表示相同内容的(业务上的意义)，而这些字段名又都不同，传这个上下文感觉是会啰嗦的。
我现在遇到最常用的场景其实就是一些 id 的传递。create 接口执行成功时会返回 id ，然后其他接口要把 id 作为参数去获取相关的信息。
Jmeter 的实现是有一个 post processor 专门做这个事情（类似于你的 Resolver ，专门处理返回值），把返回值放到一些全局变量里，然后下一个接口再去调用这个变量。因为使用的是变量，所以字段名是否相同没有太大关系。
业务流程：
1、填写内容发布帖子
2、跳转到新发布的帖子
3、删除新发布的帖子
http://10.0.0.1/create/?content=HelloWorld
&id&001&id/&
http://10.0.0.1/post/?id=001
&content&HelloWorld&content/&
http://10.0.0.1/delete/?id=001
&status&deleted&status/&
发送http://10.0.0.1/create/?content=HelloWorld
验证 id 内容由数字组成
查询数据库，验证响应中 id 代表的帖子内容是 HelloWorld
前提：存在 id 是002的帖子内容是 WelcomeWorld
发送http://10.0.0.1/post/?id=002
验证 content 内容是 WelcomeWorld
前提：存在 id 是003的帖子
发送http://10.0.0.1/delete/?id=002
验证 status 内容是 deleted
3、验证数据库帖子是否
每次单条用例前，用单条 SQL 准备满足“前提”数据
或者直接准备一个满足“前提”的数据库
删除接口和查看接口就不用依赖发帖接口了
整体思路包括利用postman的想法都差不多，区别就在于我们还什么都没开始做。。。。请教作者测试数据库数据的初始化有什么好方案么
还是看不明白其中具体做法细节,原理比较容易懂
这个是什么的接口测试呢？没接触过，想了解一下。
做一个简单点获取JSON中指定字段，然后传递给下一个API使用的工具
在excel或者数据库里面维护测试数据加个字段应该能达到你的要求， 是否依赖(Y/N)，比如依赖哪个接口，目前我这边接口测试是这样做的，这样你所有的数据，可以全部批量生成了，response的数据再提取出来给下一个接口参数。
此文甚好 容我细品
mark一下，正好最近接手一个网关的平台，还没有具体看公司的方案，学习一下！
17楼 已删除
测试初手。。想问一下楼主 soapUI作为自动化接口测试有什么优点和缺点吗？ 为什么要抛弃这个工具而想到自己写一个框架呢？
楼主看到，请勾搭我一下下
SOAPUI 我也用过一段时间，他还是不错的。我也用过他做自动化的接口测试，我一个人负责功能和自动化，基本上也有300+多个case的，20-30多个接口，每个迭代两周，测试环境，集成环境都要测一遍，回归，新功能都要覆盖，基本上一个人也能搞定了，所以说效果还是不错的。我说说他的好处：
SOAPUI 如果用来做自动化测试的话，基本功能基本都可以完成，包括文件上传，上下文参数传递，环境配置，数据库验证，json返回结果认证等等，甚至可以去出数据库的值来作为参数，而这些甚至不需要编程，不过你需要学习SOAPUI自己的一系列表达式的规则
SOAPUI 可以和MAVEN这些结合，但是我没有去研究如何做
不好的地方：
SOAPUI的表达式学习你是要花点时间的
复杂的数据初始化和验证的时候有点力不从心了
以上只是我个人的体会，其实用SOAPUI还是比较方便的,不过你至少要把他的官方文档中和你需要测试的东西的说明看一遍.
我自己觉得我为什么自己写代码的目的(个人想法，如果有不同意见请跳过我说的)是：
做自动化测试目标不是让人不写代码，而是写代码，了解代码，去更深入的理解一些基础性的，原理性的东西
自己工具更灵活一点，可以更方便的实现一些自己想要的东西，同时又比SOAPUI更轻量,SOAPUI 可以测一堆东西，不过我只要测RESTFUL类型的API
[该话题已被删除]
中提及了此贴
多谢楼主回答 还有一些疑惑
就是当项目的每个任务开发是前后台同一个人做
这个时候怎么介入到接口测试？ 或许当开发完成后台时前台也做好了。。。
你好，我现在使用的是java+excel 的方式，和你的区别应该就是数据请求没有做封装。但是现在发现一个问题，每个请求的test和数据提供都差不多，区别在于数据设置或者是参数值输入的时候不一样，我想问一下你的代码生怎么处理的吗，是使用模板生成还是使用生成文件或者其他的，谢谢。
中提及了此贴
中提及了此贴
后方可回复, 如果你还没有账号请点击这里 。
simonpatrick (simonpatrick)
第 3721 位会员 /
共收到 21 条回复