遭遇GANK！
在实际自动化项目开发过程中总会遇到各种各样的问题或者想法，在此我记录一下我遇到的一些问题；
1.改名的问题
当我们项目开发到一定阶段时候，我们通常需要改一些名字来适应最新项目的变更；基本上所有的TestSuite/testStep均有rename的功能，但有一个没有！如下图所示：
还记得我们新建项目时的情景吧 REST Service的名字http://192.168.1.100是自动生成，在其上点击右键是没有Rename选项的；有两种方法修改这个名字：
第一种就是重新建立一个REST Service在创建时候就输入你要修改成的名字；
第二种就是打开创建项目的xml文件，找到http://192.168.1.100修改名字然后保存，重新加载就行啦；
多说一点，soapui创建的项目保存起来是个xml格式文件，打开这个xml文件，通过观察我们可以发现它通过不同类型的标签识别testSuit/testStep等；
诚然我们可以直接在这个xml文件里修改任何东西，甚至直接在xml文件里进行开发工作,但我想只有人才才会这么做；
2.中文乱码--网上找的解决办法
soapUI中几个设置编码的地方：
1.在方法的属性框中，选择get还是post方式，这个对请求的参数编码是有影响的
2.在请求的属性框中，将 post QueryString 打钩，这个对请求参数采用post方式
3.在左边的树中，点击请求，在下方出现的属性框中，将encoding的值设置成 UTF-8，与我的服务器采用的编码一样，这样中文乱码的问题就拜拜啦
3.Josn格式数据显示问题
如下图所示-response中json格式数据显示在HTML框内是不是令人费解：
打开Raw看到如下图所示:
看到Content-Type:text/html;charset=UTF-8没有，就因为服务器返回的数据类型是txt/html所以数据显示在HTML框内
假设Content-Type: application/json;charset=utf-8,则服务器返回的数据在JSON下显示，如下图所示。当然对于上种情况可以当一个优化的BUG提给开发人员
4.移动的TestCase
在自动化项目开发过程中，避免不了进行测试用例的重组，创建新的测试结果集；
1.在一个Test Steps下的步骤，只要用鼠标拖拽就能改变test step的位置
2.在两个Test Case之间，也是通过鼠标拖拽来移动test step的位置，只是要求确认而已；
3.在两TestSuite之间可以直接选定TestCase,通过鼠标拖拽的方式来移动其位置；
4.当然前边的拖拽都是剪切操作，要是想复制一份TestCase，你需要在那个TestCase上右键Export，然后在另一个TestSuite下Import Test Case
5.在Test Steps下添加REST请求
在REST Service下新添了一个REST接口，这时候我们需要在Test Steps中添加上这个接口
1.在Test Steps上右键--Add Step选择REST Request；2.输入名字后确定后，弹出选择REST接口列表（下图），找到你刚刚添加的REST接口，确定即可；
6.公用的TestCase
假设一个场景！购买一张电影票的流程
1.选影院-选影片-选座位-下订单-付款
2.选影院-选影片-选座位-下订单-取消订单
明显的看到前边选影院-选影片-选座位的操作是一个公共部分，从IT角度看就是一个数据准备的过程；所以我们要把它放在一个公共的TestCase里（当我没发现如下方法的时候，我是将上边的公共部分每个TestSuit下复制一遍的）
步骤1.新建一个TestSuite,这个定义为存放公共TestCase的结果集
步骤2.在该TestSuite下新建一个TestCase，并将选影院、选影片、选座位的操作添加到该TestCase下
步骤3.在另建立两个TestSuite，分别封装下订单-付款和下订单-取消订单；注：一个TestSuite为一个测试逻辑
步骤4.我们只需要在另外两个TestSuite-TestCase中创建一个Groovy Scritp去调用公共的TestCase就行了，脚本如下
import com.eviware.soapui.support.types.StringToObjectMap def testproject = testRunner.testCase.testSuite.project //def teststep = testproject.testSuites['orderCancelTestSuite'].testCases['planTestCase'].testSteps['t'] // teststep.run(testRunner, context) def testcase = testproject.testSuites['planTestSuite'].testCases['planTestCase'] def contextMap = new StringToObjectMap(context) testcase.run(contextMap, false)
7.调用另一个TestSuite中的Groovy脚本及问题
调用另一个TestSuite中的groovy脚本或者REST Requset的脚本如下
def testproject = testRunner.testCase.testSuite.project def teststep = testproject.testSuites['planTestSuite'].testCases['membercard'].testSteps['end'] teststep.run(testRunner, context)
如果是调用REST Request的话没有问题，如果是调用Groovy Script的话有需要注意的几点
1.被调用的脚本中不能有testRunner.****/context.expand('${#TestCase#test}')等命令
2.如果只是纯粹的groovy方法脚本，不包含与上下文有关的指令是没问题的
注：
之所以不能有testRunner.***/context.expand('${#TestCase#test}')等命令是因为testRunner指的当前运行环境，想一下你现在的运行环境是这个TestSuites，当它去获取另一个TestSuites下的TestStep时候会找不到这个TestStep的因此运行不过去；
context.expand('${#TestCase#test}')写在原脚本的目的是读取那个脚本所在的TestSuite-TestCase的数据，而现在的上下文是当前运行的TestSuite-TestCase的，所以他会读取你当前运行的TestSuite-TestCase里的值；假设你要写的是context('${#Project#test}')那就无所谓啦。
8.多种会员卡处理方法
场景：上边我们说过一种场景选影院-选影片-选座位-下订单-付款出票，在付款这步骤我们需传入会员卡信息支付。而支付之前需要先查询一下会员卡（类似于先刷一下卡）。
解决办法1：一个会员卡对应一个影院，每个影院建立一套测试用例；
解决办法2：将会员卡查询集中放在一个TestCase里，在另一个TestSuite中单独调用该TestCase中的某一个TestStep
有喜欢用第一种方法的我就不多说了，来介绍一下第二种方法的实践：
步骤1.首选在REST Service中将这些会员卡查询接口通通加上
步骤2.还记得我们有一个公共的TestSuite吗，在这个下边创建一个TestCase命名为A将这些会员卡查询接口通通添加上
步骤3.每一个接口都需要进行数据准备（如,不同的会员卡号、密码、生成加密信息等），所有每一个会员查询接口前配备一个groovy脚本命名为C.groovy，测试一下能查询出会员卡信息则通过；
步骤4.在会员卡查询接口前的脚本最后加上testRunner.runTestStepByName('会员卡查询接口')，这样我们就可以通过仅仅调用这个脚本就执行查询了，而不是要调用两个testStep;
步骤5.我们在下订单-付款出票那个TestCase(命名为B)中调用C.groovy，如果这样调用的话会报错，还记得我们上边说过的吗，跨越TestSuite的调用被调用groovy脚本中不能有当前运行环境和上下文有关的指令，显然这个被调脚本符合了这个条件；
步骤6.出现这样的情况我们需要变通一下，上边我还写到调用另一个TestSuit-TestCase是没有问题，那我们就在B（下订单-付款出票那个TestCase）中调用A(有很多会员卡接口的TestCase)，当然这还有一个问题，即A中有很多会员卡接口，不能我们测试一个影院的要把这个会员卡在所有影院查询一遍；
步骤7.为了解决上述问题，我们需要在Project级别加一个参数D里边写着你要测试的哪个影院，然后在A(有很多会员卡接口的TestCase)开头加一个脚本让他根据参数D来运行指定的会员卡查询接口，脚本内容如下：
def project = context.expand('${#Project#project}')
testRunner.runTestStepByName(project)
testRunner.gotoStepByName('end')
log.info project
步骤8.上边脚本中有一句跳转到end步骤，所以在A(有很多会员卡接口的TestCase)最后加一个end.groovy,内容可以是空的或者log.info 'end'
在实际的自动化执行过程中，还是有各式各样的问题，就不一一赘述了。