说到接口测试,想必大家一定不会陌生。接口测试就是测试系统组件间,接口对接是否顺畅的一种测试。包括测试数据能否交换、能否传递、能否正常控制管理过程,以及系统间的相互逻辑依赖关系,等等。
由于接口测试主要是检测系统与系统间(外部),以及系统内部各个子系统之间的交互点。所以,它会 要求测试人员对业务逻辑有一定的了解,知道企业各个系统运作流程间的联系,以及对数据流向定位有一个清晰的认知。
由此,我们也就不难理解,为什么很多测试新手在做接口测试时,会陷入苦恼之中了。下面,我们一起来盘一盘接口测试那点事儿。
正所谓先理清关系,才能更好的解决问题,下面,我们先来说说接口测试的目的。主要就这么几个:
与其说是接口测试的用途,不如说是接口测试可以带来的优势。我认为,主要包括这几点:
1)验证链接外部接口的性能
正如我们所知道的那样,它一般会用于多个系统间的交互开发,或者拥有多个子系统的软件开发测试中。这是因为它可以验证,这些系统在对外部提供的接口的正确性和稳定性。
2)高性价比
接口测试也适用于一个上层系统中的服务层接口。虽然,越往上层测试,难度会越大,但也正是有了可以实施在多系统、多平台构架下的测试方法,我们才会获得极为高效的成本收益比。
3)测试效果佳
接口测试为高复杂性的平台,带来高效的缺陷监测和质量监督能力。平台越复杂,系统越庞大,接口测试的效果越明显。
然而,值得注意地是,不是所有测试人员都具备,在一个隔离的测试环境中进行测试的条件,这就使得对接外部接口的测试变得困难了。另外,有时候其他部门的同事,只是人工、静态的审阅一次数据,而并不真正的用数据来做测试,这些都会增加实际测试执行中遇到的风险。
为了解决这些问题,规避接口测试中一些风险,下面,我们就来盘一盘接口测试的痛点及解决办法。
3、接口测试的痛点和解决办法
在做接口测试时,以下几个测试痛点,一定要仔细琢磨下:
痛点①:由于测试环境数据被改动,导致接口测试失败
这个问题,最好的办法就是重新调用数据库中的最新数据。在做测试用例时,也要考虑到实时调用数据的问题,确保不会因数据改动而测试失败。
痛点②:由于测试数据写死,导致接口用例执行失败
其实,这个问题是可以预见的。因为,在进行测试前,跟开发人员做相关问题的提示,是可以避免这个问题的发生的。但如果测试中,还是发生了这个问题,那么我们就需要对数据进行参数化。但切忌过多参数校验,因为这样会使得服务端变得很臃肿。
痛点③ 检查点不够充分
对于很多新手而言,在做接口测试时,往往只会考虑正常的校验点,而忽略异常校验点和不为空校验点。这也提醒我们,在进行测试前,一定要考虑全面,并且多提醒自己,注意一些容易忽略的细节。
痛点④ 执行后产生的数据,导致后面的用例执行失败
很多小伙伴可能都遭遇过类似的现象:前面用例执行的都挺好,后面再执行下个步骤,就显示执行用例失败了。这是什么原因造成的呢?对,就是执行结束后产生了新数据,这些新数据影响了整个后续用例的执行。所以,我们在做测试时,一定要注意清理掉执行过程中产生的特定数据。
痛点⑤ 由执行超时等因素造成的用例执行失败,非404错误
遇到这种问题,最简单也是最无懈可击的办法,就是重跑。哈哈哈~
痛点⑥ 单个接口测试通过,但业务还是有bug
遇到这种情况,一定要尝试组合多个接口,组成一个完整的业务场景,再重测,保证整体顺畅,否则后期使用过程中出现问题,就严重了。
①了解系统及内部各个组件之间的业务逻辑交互;
②了解接口的I/O(input/output:输入输出);
③了解协议的基本内容,包括:通信原理、三次握手、常用的协议类型、报文构成、数据传输方式、常见的状态码、URL构成等;
④常用的接口测试工具,比如:jmeter、loadrunner、postman、soapUI等;
⑤数据库基础操作命令(检查数据入库、提取测试数据等);
⑥常见的字符类型,比如:char、varchar、text、int、float、datatime、string等。
日常工作中,我们在做接口测试时,经常会遇到各种各样的问题,这些问题可能会使我们迷惑,也可能会让我们焦头烂额。面对这种情况,最好的办法,就是先冷静下来,根据自己撰写的用例步骤,一步一步来检查究竟问题出在哪个环节,进而探究这个问题是怎么造成的,应该怎么处理。最后,问题解决后,做好相应的笔记记录。
感谢每一个认真阅读我文章的人,礼尚往来总是要有的,虽然不是什么很值钱的东西,如果你用得到的话可以直接拿走:
这些资料,对于【软件测试】的朋友来说应该是最全面最完整的备战仓库,这个仓库也陪伴上万个测试工程师们走过最艰难的路程,希望也能帮助到你!有需要的小伙伴可以点击下方小卡片领取