接口测试场景化设想(一)

• 　　传统的接口测试一般会如下进行,注:这里的接口测试仅只http请求.
  • 　　　　拿到开发的接口,包括了url,type,参数.设计测试用例,一般设计测试用例靠数据驱动.假设设计用户注册接口,一般测试用例会设计成如下　　

• • 根据设计好测试用例放到工具上进行接口的测试,工具一般可以使用如下
    • 　HttpRequester
    • 　PostMan
    • 　Swagger
    • 　Curl
    • 　Python
    • 　Jmeter
    •     LoadRunner
    • 　Robotframework
  • 录制完请求以后,查看接口的返回,对比返回的数值,一致则表明此接口测试通过,否则失败
  • 缺点
    • 　　目前大多数的接口测试还停留在工具上录入接口以后点击执行,查看返回接口.每次测试的都需再次输入请求,点击执行.执行时间慢,回归所有的用例时耗费时间长.
    • 　　和开发单元测试的工作重合.做单元测试是一个开发的基本素养,我们假定所有的开发都会对自己的开发接口做单元测试.开发在做单元测试的时候是一定会对这个接口做主流程测试,分支测试,而在这种情况下测试再按照传统的方式设计测试用例除了完成一个double check以外则没有其他方面的意义了.再这样的场景下再分析我们发现开发的单元测试,对于一个接口依赖另外一个接口的情况下,开发的单元测试一般会采用Mock的方式来解决此问题.也就是说他们并不会测试两个接口之间的数据传递,因为他们已经假定了另外一个接口返回的数据.而很多情况下BUG的产生就会在于数据的传递
    • 　　测试用例的设计没有从用户的角度思考.对于接口的设计我们测试人员往往会局限于这一个API,首先需要考虑的是用户的使用场景,这种设计用例的方式就不应该是数据驱动,应该是场景驱动.同样如上用户的用户注册测试CASE,从用户的使用场景思考应该修改如下:
• 　通过以上分析,我们需要解决如下问题
  • 　　在测试用例的设计中,依靠场景驱动去设计测试用例.而场景的完成,主要依靠一个个的API串联.这种情况下设计的测试用例会解决传统测试中缺点二和三.
  • 　　需要工具将场景测试用例转换为程序能理解的测试用例
  • 　　需要工具将转化以后的测试用例转化为一个Http请求
  • 　　需要工具一键运行这些Http请求,并且能够断言返回结果