其他测试框架 浅谈分享一下接口测试,望指正。~

yangchengtest · 发布于 2015年06月05日 · 最后由 jinggzhao 回复于 2016年04月14日 · 530 次阅读

最近一个多月在回归补充接口测试的一些内容。这里总结分享一下。~
我们的设备有大量的前后台交互内容,主要是RPC接口和SOAP接口。RPC是通用的JSON报文,SOAP是自定义端口的HTTP报文。
代码主要是通过PYTHON实现。目标是通过接口测试自动化覆盖基本功能。
代码采用下面的结构:
1.传输层,调用PYTHON内部提供的HTTPLIB,UDP等库,进行固定端口的报文封装,XML封装,XML解封装等。
2.接口层,主要是接口联调,封装接口参数,供用例层调用。
3.用例层,按模块进行接口组合和入参应答判断,返回测试结果。
4.JENKINS集成每天跑一遍,输出个报告出来,这部分我还比较懒,反正自己一个人看,写个TXT就拉倒了。。。

同时在用例层还引入了不少第三方库,我们的设备有不少如SAMBA的远程传输方式,验证时,需要自己编写CLIENT验证功能的完善性。
写得过程中发现PYTHON还是挺强大的,很多的功能第三方库都支持,如这两天在调的BTSYNC库。
感觉接口测试也没有那么高大上,有一定的编码能力多抄抄。。。
PS:最后吐槽下,和开发联调接口,哎,开发接口文档有误就得自己取抓包,看的多了,有些眼花。。。还有些同学爱理不理的。。。
没啥干货,凑合看吧。。。不少细节都是搜索出来的,PYTHON有的第三方库用起来跟版本是强相关的(坑,如3和2的类继承等等),实在不行的还是需要查查改改才能用。

共收到 14 条回复
3815

请问一下接口组合测试有没有好的方案,目前正纠结着一块

1706

@sam_insist 不知道你的需求是什么,功能的自动化用例也完全可以由接口组合啊?
或者换个维度,用户故事算么?

3815

就是现在单个接口的各种用例已经测试过了。。那流程性的组合要不要测试呢,比如一个用户完成一个事务操作需要调用10个接口,,那我要不要对这个10个接口做各种情况的组合测试呢。。或者说这个10个接口的组合测试有没有必要呢

1706

@sam_insist 你这个是关键字组合的问题了。。。这个和自动化关系感觉不大。
我个人的意见是简单组合,复杂组合除非出过问题,没有必要专门进行接口组合覆盖。
当然还要看你们项目的要求,自动化到底要实现到什么程度。自动化不是万能的。。。~
PS:我能吐槽一下么,用户一个操作调10个接口,这个操作还不封装一下,这10个接口之间会没有顺序么?这要不封装的话,这用户体验,代码结构也算是奇葩了,个人建议结合业务流程,不要做太多无用用例~到最后还是要考虑执行时间的问题。

2606

#4楼 @yangchengtest @sam_insist的意思可能是一个测试点需要调用10个接口才能达到目的吧,而不是点一个操作调用10个接口

1706

_,吐槽有点多~以下是我个人的观点,供吐槽~
我个人是这样理解的,10个接口,接口组合感觉这种就不是接口测试讨论的范畴了。这个应该是测试方法,测试架构讨论的内容。如关键字驱动之类的。
大家可能接触测试理论都会说要覆盖要完善,但怎么说呢,完备是需要成本的,有些覆盖在代码中是有约束的,比如条件A触发以后才会运行B,某些完备是没有意义的。我们看到开发提供的接口可能有10个,你组合多少合适呢。这个感觉还是经验和项目需要或者是用户来驱动。呵呵,有不少东西,我知道自己项目怎么玩,但是别人的项目适用不适用就很难讲了。
我感觉自动化不是万能的,有很多内容比如DB同步,异常测试的一些内容,就需要自己去想办法挖掘组合。目前我感觉自动化把基本的跑跑通,降低回归测试的成本就很不错了,个人建议不要想太多,手工也是不可能完全替代的。
接口测试个人认为最大的优势就是UI改起来太痛苦,接口简单很多,也更贴近代码,更好操作。~
题外话:领导最后要看的是成果,至少最基本的内容要能跑过,接口最终还是要变成一个一个可呈现出来的东西~适当的组合还是必须的。

3815

谢谢您的细心解答,或许我理解的接口不只是针对单个接口的各种用例测试,比如一个常见的网上购物的完整流程,要调用登录接口,获取商品信息接口,添加商品到购物车的接口,新增订单的接口.... 就是一般这种整个流程性的接口组合测试有没有必要呢。

1706

@sam_insist 你上面说得都是一些基本的功能,我个人理解还是需要整合一下的,测试归根结底还是要验证功能。做完之后心理有底,给领导交差时也会好看些~个人建议只做简单的整合,不要搞得太复杂。

3815

@yangchengtest 谢谢,我也觉得应该要测试一下,只是这种组合接口测试的深度和广度自己还是不知道怎么掌握,或许还是要公司具体的业务来吧。

2155

“PS:最后吐槽下,和开发联调接口,哎,开发接口文档有误就得自己取抓包,看的多了,有些眼花。。。还有些同学爱理不理的。。。“这个需要规范API啊,比如restful,而且有BUG就上PMS提给开发,BUG和开发绩效挂钩吧。希望对你有用。

2155

对了,你们接口测试的压力测试是怎么做的?

1706

@halo_lan 目前还没有考虑压力测试,我们是家庭产品,一般来说不会有超过5个用户同时登录,目前只考虑了常规的一些性能测试,请问压力测试这部分有什么可以建议的么?多谢!~
呵呵,我们就是因为考核开发BUG数目,所以API都是扯皮的事情~必须要有实际操作异常,才会理会你。API改了,只要实际功能能跑通,测试脚本跑不跑的通那是测试的事,和开发无关。。。这里槽点比较多,就不细说了~

4104

#7楼 @sam_insist 这个属于业务层的测试,在底层单个接口功能测试完毕之后,是有必要增加一些场景测试的,比如业务场景。这些场景就要根据各自系统的实际进行设计咯。这是我的经验。

96

@sam_insist 我们这边做接口组合测试,是先从比较重要的场景入手,使用3组合覆盖来模拟上层使用的场景,但是也有问题,就是会出现不少无效的场景,不过对无效和有效的定义也是因人而异的

需要 登录 后方可回复, 如果你还没有账号请点击这里 注册