5.3RobotFramework接口自动化（三）--token的应用

一.解决方法思考

前面获得了token，我们得到token是为了在相关的接口请求头中应用这一“通行证”，那么如何将token应用到其他的接口里面呢？我想到了以下几种方法：

A.直接在获取token的用例中接着往下写，接口1用例、接口2、接口3......。

    优点：这样简单粗暴，各接口也能够正常跑起来；

    缺点：所有的用例写在一个脚本下，看得人头大；几百个变量看得人头大，后期维护时要花比较多的时间

    [感觉不好用，不建议]

B.新建测试套件（suite）时，新建suite下的scalar变量header00；获取到token之后，将token的值存入变量header00；那么在后面的case中，我们就可以直接使用全局变量header00.

    然而，通过         ${header00}    set variable    ${token}    这种方式，并不能解决问题。

C.新建测试套件（suite）时，新建suite下的scalar变量header00，并初始化它的值为${token1}，即把得到的token值赋给全局变量header00；

    然而，结果也是不行的

 

D.通过set suite variable关键字，将${token1}设置为suite级变量，在该suite下可任意使用。这个方法是比较早想到的，但后面的接口用例出现了一些问题一直没成功，以为是这个关键字没起作用。。。。

    该方法可行。

  

   二.具体应用----以######为例

查看结果报告如下：

  

三.后续展望

按照目前的思路可以将一体化项目的接口通过RF+Jenkins实现持续集成，与jmeter得到的效果一样；更高级的做法可以应用“用户关键字”，使用例更加简洁，后面会继续研究。

RobotFramework+Jenkins框架与Jmeter+Ant+Jenkins框架比较：

优点：1.RF的测试报告结果更为详细直观，且当case执行失败时，报告中可以看到详细的错误原因。

 

             

            2.RF在Jenkins中还会生成统计报告，可以明了的看到失败的用例与成功用例的结果走向

               

缺点：

         1.RF只能看到最近一次的结果报告，jmeter那一套是每执行一次就生成一个结果报告并保存【RF能否实现执行一次就生成一个结果报告有待研究，思路为改写xml文件，目前暂未证实】