冶金自动化

接口自动化测试的“能”与“不能”、到底能不

 

关注我,让我成为你的专属小太阳吧

Hei~Guys

这里是“叨叨的软件测试分享台”

小编继续为大家讲

接口自动化测试的知识点

快眯上你的小眼睛,认真阅读吧

前言:

自动化测试,算是近几年比较火热的一个话题,当然,更是软件测试未来的一个发展趋势。未来,功能测试等非核心的测试工作,都将被外包。想要在软件测试这个行业继续前行,就必须拥有核心竞争力,掌握自动化测试技术,是必不可少的一个技能。

在《Google软件测试之道》一书中有介绍到:在Google,70%的自动化测试工作集中于单元测试,20%集中于接口测试,剩下10%才是UI测试。你悟到了吗?

虽然,我们没有Google那么完善的机制和工程师文化,没必要一切照搬Google,但Google作为互联网2.0时代最耀眼的一个公司,它的技术发展方向,流程管理等可以说是不久的将来,

我们也要到达的方向。选择适合自己的,落地应用,是当下我们应该做的。

目前国内的互联网行业,大环境来说,还处在一个快速发展,需要流程化标准化的时期,如何跟上不断变幻发展的节奏?除了不断了解接触新的东西,还需要不断学习,提升自身,以内在

的驱动力,去紧跟时代浪潮。即使做不了弄潮儿,也不能变成时代淘汰的那一批。说到这里,推荐乐搏学院的2节公开课:乐哥的《软件测试小白集训营》、《软件测试在职提升班》,都是免费的试听课,有直播课和录播课,非常鼓励大家去试听,快从课堂中Get到你的知识点。

一、接口自动化测试的"能”

接口自动化的目标:

用于项目的 API 层的 HTTP 接口的功能逻辑验证? 减少手工测试的工作(回归验证;跨模块的验证)? 实现手工验证不能做的验证(如接口涉及大量数据的排序比较)? 手工很难充分验证的功能逻辑(如接口的功能验证涉及大量的数据)

Ps:实际项目中,接口自动化的根本目的是什么?

个人认为是定时跑时,能监控接口,当接口功能失常时,可以及时发现,即发现 Bug。因此,可以使用代码覆盖率来评估接口自动化的完整性,但更重要的是发现问题。

接口自动化 Case 用例设计原则、切记:

不要为了做自动化而做自动化,做的首要目标是问题出现时,能第一时间发现;? 自动化中的代码覆盖率统计可以作为参考,但不能一开始就为了提高覆盖率,陷入 Case 设计之中;

注意:

好的接口自动化 Case 设计,依赖于 Case 设计者的功能理解程度(手工测试的功力)+ 功能覆盖点;

原则:

1.将手工测试点转换为自动化用例。Case 设计注意:验证用例通过的标准—参考一个功能点容易出问题的地方。或者说,一个用例的通过说明此功能点一定没问题;反之,一定有问题。

2.覆盖手工测试不易检查/太浪费时间的检查

比如:

一个 HTTP 接口设计大量的数据比较的时候;? 接口的 json 返回不能直接检查功能点是否正确(需要调用另一个接口的 json 来间接验证时);? 一个接口的 json 返回需要和其他模块的接口联合” 互相验证 “(需要调用其他模块的接口的 json,两个 json 相互来验证彼此的正确性)

3.”边缘性“的功能检查 这里主要指的是回归验证。如果系统涉及边缘性的功能验证,把此类功能设计层自动化用例

4.接口验证的程度 接口的验证:即判断一个接口是否正常的标准。注意:接口参数”合理的“组合;

5.DB 数据更新检查(如果有必要)注意从接口的角度检查 DB 数据的更新:

其他系统的数据更新到待测系统 DB 中的数据;每天待测系统由于用户操作更新到 DB 中的数据;

6.接口自动化的数据准备

关于是否需要为接口自动化,特意在 DB 中准备需要的数据,适需要程度而定。原则:除非必须,否则不用准备。如果不准备数据,无法完成对接口的验证,则自己准备数据即可。

注意:一旦自己准备数据,评估对其他功能验证的影响。确保DB 中数据量和真实性(模拟的数据需要充足,并且不能和真实数据差异性过大)。

接口自动化用例定时跑:

自动化一般会选择每天定时跑。这里需要注意的一点就是定时跑的时间选择。时间选择上注意几点:

在线上跑时,注意对线上接口的影响(一般要求:线上的回归验证可以随时跑);

如果要检查 DB 数据更新的有关逻辑,注意数据的稳定性 (如用户量少的时候);

在测试时(非生产环境),接口涉及读,写 DB,考虑是否需要定时跑;