python自动化测试 | 接口自动化测试脚本如何写好?

目录:导读

    • 前言
    • 一、测试用例目的
    • 二、接口信息
    • 三、基本原则
    • 四、接口断言
    • 五、脚本的维护
    • 六、测试数据准备
    • 七、总结


前言

接口测试可以在没有前端界面下进行测试

后端的功能校验在前端很难进行测试,因为前端已经有初步校验控制,所以接口测试可以发现很多在前端无法发现的问题

提升测试效率,降低人工回归测试的人力成本与时间成本,缩短测试周期。

真正的业务逻辑核心是后端。

例子说明:
有个登录页面,你要登上网站,就需要输入你的账号密码,把账号密码作为请求参数打登录接口,这时客户端会给服务器发个登录请求,服务器鉴权和校验通过之后,就登上去了。

到这里就完成了一次接口的请求,或者说跑完了一条接口测试用例。

大家关注更多的是哪个工具更优秀,更好用。但是很少人关注到接口测试用例的设计问题这样真的对么?我们是不是忽略了什么呢?回归测试的时候,成百上千个接口执行下来,没有报错,你就真的对系统放心了么?

除开脚本层面的编写外,接口用例的设计也是一项非常重要的测试活动。通过一定的接口用例设计,让我们编写的脚本更有目的性、更可靠,才能体现接口测试的价值的意义,而不是单纯以量取胜。

一、测试用例目的

在进行接口测试脚本的编写前,我们应该明确这批脚本的预期目标在哪里,是为了验证什么内容。

单接口验证:以验证接口参数、权限、返回值为主,保证接口“能用”,这类用例一般在接口设计定稿后,配合Mock服务就可以完成用例编写;

场景逻辑验证:以用户场景为基础,验证接口间的参数传递及业务流程能够正常流转,用例复杂度较高,需要非常熟悉业务与接口之间的关系。这是接口测试最核心的价值。

异常验证:主要验证参数异常、逻辑异常等情况下,接口是否能处理并给出友好的错误信息。通常情况下,关注参数异常的场景会比较多,可以用等价类、边界值等方式来处理。需要注意的是多关注下异常的返回信息是什么,信息是否明确,提示是否友好等等。

二、接口信息

当我们明确好测试目标后,再开始编写测试用例,会有更针对性的去设计测试数据和接口组合。

接下来的问题是什么呢?
去哪里确认你的接口信息是有效的?

基本上有两种路径:
接口文档:开发人员都不喜欢自己写文档,同时也很讨厌别人不写文档。所以测试人员如何获取一份真实有效的接口文档是件比较麻烦的事。一般团队内都会有一个统一的接口文档管理工具(如果没有,就找开发多磨麿,让他们弄个,并不难),我们需要关注接口文档的有效性和及时性。

现在也有很多的插件或者工具能够帮助研发人员自动生成接口文档,例如Swaager、apidoc等等。

接口抓包:如果什么都没有,那就自力更生,通过Fiddler之类的工具,通过抓包分析的方式来获取接口,这类的场景如果较多的话,可以把Fiddler抓到的接口导出,然后写个小程序,直接转成接口平台可以识别的脚本,效率会更高一些。

在获取到接口信息后,需要与开发人员多交流,明确参数的意义及来源,以便我们针对性的做测试用例设计,这个环节不要过多的自己猜(很多测试人员经常会自己猜想),直接找开发问就好了。

在这个接段,还要梳理并区分接口的重要程度和优先级。这样就可以确认哪些接口优先设计用例,哪些接口可以先放放,在有限制的时间内,做最大价值的事。

三、基本原则

拿到接口后,明确了参数说明,结合测试目标,我们就可以开始设计并编写测试用例了。区别于功能测试用例,接口测试用例(脚本)一些原则。

需要注意:
自动化:好像是废话,所有的用例应该是非交互试,最常见的就是Token之类的生成,需自动处理好(我见过每次执行用例前,需要自己手动生成Token再粘贴进去的脚本,特别是分环境执行的时候)。

独立性:每个用例应该是独立的,没有依赖的。需要在一个用例里处理好前置条件,而不是多个用例相互依赖。

可重复:用例测试可重复执行,所以需要注意参数的生成方式。

可持续性:如果代码修改导致已有接口测试执行失败,必须修复代码问题或者测试代码逻辑。

四、接口断言

在设计测试用例时,还需要关注的是针对断言的设计,好的断言能够帮助我们发现问题,没有断言的用例(脚本)就是耍流氓,完全没有意义。

在审核脚本时,会重点关注这个。

从接口层面看,我们至少需要验证两点:

数据结构验证:验证接口返回的数据结构是否与事先定义的一样。调用方在处理数据时,肯定是根据事先定义好的数据结构来解析数据的,如果数据结构发生变化,那对调用方来说,是灾难性的(契约测试考虑下)。

核心数值的验证:根据业务场景的不同,可以有目的性的验证某些key的值是否与预期的一样,可以结合数据库查询的方式来验证(不同的自动化测试框架有不同的实现方式)。这个就比较依赖测试人员对业务的了解。根据实际情况灵活的设计验证点。

除了以上两点外,还有一些额外的验证点在需要的时候可以进行,如涉及到其它方的数据流转、返回的URL是否可被访问,返回的数据是否真的是必要的(这点很重要,过多的返回会导致很多意外的问题),等等。根据实际情况进行补充。

这样,通过一系列的方法设计出来的接口用例,才会有一定的业务价值,能够真正的帮助到团队,提升测试效率,对于这样的测试脚本,全部PASS的结果才会让人安心。(你能想象没有断言的脚本全部PASS,你还放心的么)

五、脚本的维护

测试用例(脚本)编写完成后,并不意味着接口测试的成完。

在其它的测试环节中,如果发现因为接口问题而产生的BUG(如响应异常、无数据返回等情况),我们需要适当的补充到接口用例中,避免类似的情况再次发生而我们没有验证到。

在积累到一定高质量的用例(脚本)后,可以进一步挖掘这些东西的价值,如转化成线上业务监控的脚本,转换成精准测试的依据等。还有更高端的玩法,是借助混沌测试的思路,独立拉个分支,故意修改一些异常出来,让测试用例验证,能否发现这些BUG,以验证测试用例的有效性。

如果不能发现,那就需要我们去思考如何改进测试脚本(业内已经有类似的平台出现了)。

六、测试数据准备

多聊下测试数据准备的事,这其实是接口测试中很重要的一个环节,想要脚本可以在多个环境中运行,那么测试数据就不能写的太死,需要根据环境去自动获取一些数据值。

公共参数:通过不同作用域及标识的区分,有个专门的文件来处理一些共用数据的存放,例如不同环境下的用户名。

数据集合:通过特定的API或者SQL事先生成所需要的数据,然后放到一个指定的集合(参数或者文件都可以)中,在需要的时候,从这里获取对应的数据值。

数据模板:这个是数据集合的升级版,根据业务数据流,只需要填写一些简单的信息,就可以自动生成一整套的业务数据。

七、总结

如果你要想成功、要想追求所企望的美梦,就千万不可有这样的信念,因为那会扼杀你的潜能,毁掉你的希望。

目标的坚定是性格中最必要的力量源泉之一,也是成功的利器之一。没有它,天才也会在矛盾无定的迷径中徒劳无功。

做任何一件事,都要有始有终,坚持把它做完。不要轻易放弃,如果放弃了,你就永远没有成功的可能。如果出现挫折时,你要反复告诉自己:把这件事坚持做下去。

你可能感兴趣的:(自动化测试,软件测试,接口自动化测试,测试用例,自动化测试,软件测试,python自动化测试,接口自动化测试)