我们有几个soapui项目,每个项目都在不同的web服务上发送测试请求。然而,对于每个项目,执行测试的Groovy脚本在很大程度上是相同的。因此,我们决定将通用脚本保持在单独的"版本"中,以便于版本控制和维护;伪";项目("TestWSScript-soapui-project.xml"(,具有一个测试套件/用例(Autotest/Test(,仅具有一个testStep(名为"Run"的Groovy脚本(。其想法是为每个WebService(比如WS1Soapui-project.xml(提供一个项目,该项目具有带有一个TestCase的testSuite。在该测试用例中将是
- Groovy测试步骤,用于设置特定于WS的属性,并从TestWSScript-soapui-project.xml调用通用脚本
- 请求测试步骤以调用Web服务并执行断言
- 结束Groovy测试步骤
这在SoapUI中起作用,但我想从Windows命令行运行测试(出于自动化目的的批处理文件(。在这里我遇到了一个问题:当使用从命令行调用testrunner时
set "SOAPUI_FOR_TEST_DIR=......programsSoapUI-5.6.0"
"%SOAPUI_FOR_TEST_DIR%bintestrunner.bat" -sAutoTest -r -a -j -I "..resourcesWS1-soapui-project.xml"
它不会用所有SoapUi项目加载整个工作区。因此,应该从项目TestWSScript-soapui-project.xml/AutoTest suite/Test-TestCase运行testStep的以下脚本(在WS1-soapui-project.xll/AutoTest suite/Test-TestCase中(返回Null(更具体地说,"无法在Null对象上调用方法getProjectByName(("(
import com.eviware.soapui.model.project.ProjectFactoryRegistry
import com.eviware.soapui.impl.wsdl.WsdlProjectFactory
def workspace = testRunner.testCase.testSuite.project.workspace
def testProject = (workspace==null) ?
ProjectFactoryRegistry.getProjectFactory(WsdlProjectFactory.WSDL_TYPE).createNew("TestWSScript.xml") :
workspace.getProjectByName("TestWSScript")
if(!testProject.open && workspace!=null) workspace.openProject(testProject)
// Connect to the test step in another project.
def prj = testRunner.testCase.testSuite.project.workspace.getProjectByName('TestWSScript')
tCase = prj.testSuites['AutoTest'].testCases['Test']
tStep = tCase.getTestStepByName("Run")
// Call the test runner and check if it can run the specified step.
def runner = tStep.run(testRunner, context)
被调用的脚本只是循环通过从csv文件读取的参数并调用请求步骤。这与我需要解决的问题无关,因为问题发生在调用脚本之前。
有没有办法实现我们想要的?我们正在使用SoapUI-5.6.0的免费版本。提前谢谢。
以下是我对您的建议。
- 与其只为一个groovy脚本创建一个单独的项目,不如用它创建一个库
- 根据需要创建一个类和方法。如果从调用方传递数据,请使用方法参数或类成员
- 使用现有的脚本,将它们转换为类、方法
- 根据需要创建类
- 它可以编程为
java
或groovy
- 编译类并创建库
- 将此库复制到
%SOAPUI_HOME%binext
目录下 - 现在,您可以在任何项目中调用这些方法。不需要更多的虚拟项目
- 好在所有的项目都是独立的
以下是SoapUI导出和作者之一Rupert Anderson创建的博客内容。
Steps
1.Create the following directory structure
soapuilib/src/main/groovy/custom
2.Get some Groovy code
For this example, I have knocked together a simple script to generate sequential ids. It may be of little practical use, but I wanted something with a simple public static method to call. Since the method is static, there will be no need to instantiate the class before calling it in step #8.
[groovy title=”SequentialIdGenerator.groovy”]
package custom
import java.util.concurrent.atomic.AtomicLong
public class SequentialIdGenerator {
public static final long counterSeed = 1000
public static final String prefix = "id"
private static AtomicLong counter = new AtomicLong(counterSeed)
public static String nextId() {
return prefix + counter.incrementAndGet()
}
}
[/groovy]
create the above script as a text file called SequentialIdGenerator.groovy
copy it to soapuilib/src/main/groovy/custom
3.Create Gradle build script
For this part, there are plenty of options to build the code and package it, such as Maven, Ant or just running the right shell commands! The following minimal Gradle script allows us to compile and package the code as a jar in one easy statement.
[code language=”groovy”]
apply plugin: ‘groovy’
version = ‘1.0’
jar {
classifier = ‘library’
manifest {
attributes ‘Implementation-Title’: ‘SoapUI Sample Groovy Library’, ‘Implementation-Version’: version
}
}
repositories {
mavenCentral()
}
dependencies {
compile ‘org.codehaus.groovy:groovy:2.1.7’ //Matches Groovy in SoapUI 5.2.1
}
[/code]
Create the above Gradle script as soapuilib/build.gradle
INFO: Groovy Version – (At time of writing) The current version of Groovy is v2.4.6, but SoapUI 5.2.1 ships with Groovy 2.1.7. If you try to compile with a Groovy version 2.3+ and use it with SoapUI, you will see an error popup and log message in like ‘org/codehaus/groovy/runtime/typehandling/ShortTypeHandling‘ – see http://glaforge.appspot.com/article/groovy-2-3-5-out-with-upward-compatibility for more details and options. Basically, you can still use the latest Groovy version, but will need to include an additional groovy-backports-compat23 dependency!
5.Compile it & Create jar file
Now we’re ready to use the Gradle script to compile the sample script from step #2 and package it as a jar file.
Open a shell/command prompt at soapuilib/
gradle clean build jar
You should then see output like:
[bash]
tests-MacBook-Pro:soapuilib test$ gradle clean build jar
:clean
:compileJava UP-TO-DATE
:compileGroovy
:processResources UP-TO-DATE
:classes
:jar
:assemble
:compileTestJava UP-TO-DATE
:compileTestGroovy UP-TO-DATE
:processTestResources UP-TO-DATE
:testClasses UP-TO-DATE
:test UP-TO-DATE
:check UP-TO-DATE
:build
BUILD SUCCESSFUL
Total time: 5.499 secs
This build could be faster, please consider using the Gradle Daemon: https://docs.gradle.org/2.12/userguide/gradle_daemon.html
[/bash]
and our new library jar file created under the directory:
soapuilib/build/soapuilib-1.0-sample.jar
6.Add jar file to SoapUI
To make our new Groovy library jar available for use in SoapUI, it should be added in SoapUI Home under the following external library directory:
SoapUI ext Directory
Or the Windows equivalent e.g. C:Program FilesSmartBearSoapUI-5.2.1binext
7.Verify jar file is imported
When SoapUI is restarted, you should see the following log entry indicating that the jar file has been successfully added to the SoapUI classpath:
SoapUI ext Lib Loaded
8.Call the code
Our SequentialIdGenerator has a public static method nextId() that we can call, so to do this we can either import the class (Example 1) or just prefix the class with its package (Example 2). See below:
Example 1 – Call from Groovy TestStep:
[code]
import custom.*
log.info SequentialIdGenerator.nextId()
[/code]
Gives output like:
[code]
Thu May 12 16:49:20 BST 2016:INFO:id1001
[/code]
Example 2 – Call from Property Expansion:
[code]
${= custom.SequentialIdGenerator.nextId()}
[/code]
编辑:以下是具有context, log
变量访问权限的示例代码。
<script src="https://gist.github.com/nmrao/c489a485bbe3418cf49d8442f9fb92eb.js"></script>