第一部分-第2章:如何美丽的对接接口(基于移动端测试系列知识沉淀)

这几年的移动端测试,不单纯在做移动app的测试,也导致了更多测试观念比较笼统。对移动端测试技术不够专精。

真正开始移动端分层的想法也是在最近几个月,因此本章只是留下最近一些所知所得。用来以后回顾与扩展使用。

分层的概念看了一些文章,大部分都是放在整体系统层面进行分层。类似服务端-接口-客户端之类的。然后再对后端做具体的分层。但是到app这边,就写一个app。

以目前小组的水平对移动端分层主要分为:

对接接口,既然服务端要做接口测试,那我们的也要来个对接接口的测试吧,主要是验证接口使用的美不美丽,这个也后面细说。

接着是UI功能测试,现在大多数同学都在这一层。虽然都说小白没有技术含量。但是还是有一点料的。

接着是组件测试,目前的app是由很多组件配置、拼接起来的。目前这个层面主要还是使用功能进行覆盖。这个部分主要讲一些配置、资源、组件依赖的测试技巧。

然后是sdk测试,这个部分主要是我们组的测试开发再做。主要说明我们如何测试底层提供给别人的sdk测试。我仅知一点皮毛。正在学习中就被项目变更掐断了。希望回来的时候还能跟上移动互联网的节奏。写的时候估计要找外援。

第三方依赖测试,这个其实现在基本没做。是最近开发优化了一个第三方依赖库折腾了所有QA一圈后,让我想起来这个测试的必要性。

在这样 的分层体系下,还是半黑盒。如果大家想要看一些更加深入的分层理念,目前我们在这块还是有所局限。可以关注下腾讯测试的公众号TMQ。


第一部分:对接接口

很多人可能比较了解服务端的接口测试,所以会有疑问,接口设计的美不美丽需要评判。为什么要去评判接口使用的美不美丽。

正确合理的使用服务端提供的接口不仅可以为服务端减少许多不必要的压力,也可以侧面看出系统设计的是否合理,更有甚者,有时前后端开发沟通之间出现问题,可能还会出现接口错误使用导致功能问题。下面举一个简单的栗子:

假设服务端给客户端提供了一个抽取红包的接口。客户端在对接接口时的处理逻辑是,用户每次点击红包。都连续发送五次抽取请求(一般开发不会这么干,这里只是夸张)那么不仅给服务端接口造成了压力,还浪费流量。

如何评判接口使用的是否美丽呢。笔者总结了以下几个点:

1、设计层面

        设计层面主要是通过了解客户端具体如何对接接口输出出整个功能实现的骨架。这部分可以通过后端开发提供的wiki。或者开发实现的app抓包来获取。

如果是通过wiki来输出实现骨架,后续也要注意验证前端开发确实是按照这个骨架去设计的,这部分在功能层面会介绍。

如何通过具体接口对接输出业务骨架呢。这里还是举个栗子。

某个群文件功能,开发提供了接口如下:

【获取文件目录接口】【删除文件接口】【增加文件接口】【修改文件接口】

有经验的测试只需要看到这几个接口名称接口yy出一套功能。抽象出这个功能模块主要包含功能获取文件列表、删除文件、增加文件、修改文件信息。

那么在使用app抓包的过程中。则将这些功能具象化。

(1)用户点击入口按钮--触发请求【获取文件目录接口】

(2)用户点击右上角增加文件按钮后选择文件--触发请求【获取文件目录接口】

(3)用选中文件并选择删除按钮--触发请求【删除文件接口】

(4)用户选中文件并选择重命名按钮--触发请求【修改文件接口】

结合每个接口的请求后,则有了更深的,每次请求之前客户端做什么数据准备,请求后客户端做什么展示准备的了解。

通过以上的方法了解到开发的设计后去评估这套设计是否合理。当然,我们更加推荐在开发设计接口时就去了解设计并提出建议来减少返工。

2、性能层面

        性能层面指接口是否得到合理的利用,例如一开始举的那个栗子就是存在流量的冗余损耗。且短时间多次请求,对服务端也会有压力。


3、功能层面(正确使用)

        功能层面主要是指开发是否按照约定的那样合理使用接口,举一个项目中的栗子:

某个群文件功能,后端开发a提供了接口如下:【获取文件目录接口】,并说明了接口支持分页加载。例如

url:xxxx/file/groupid?offset =n &limit= m 。其中offset表示开始条数。limit表示每次取的个数。建议每次取50条

正确的获取方法为:

xxxx/file/groupid?offset =0 &limit= 50  第一页

xxxx/file/groupid?offset =51 &limit= 50 第二页 

那么移动开发b在对接的使用觉得麻烦。那我一次取1000条好了。于是就。。。

xxxx/file/groupid?offset =0 &limit= 1000

好了。后端根本不支持1000条一次性取。xxxx/file/groupid?offset =0 &limit= 1000 的现象为只给返回200条。

那么在这个场景下就很容易漏测,因为我们的测试场景比较少涉及文件超过200条的请求。


另外还有万一开发这样请求了呢?

xxxx/file/groupid?offset =0 &limit= 50  第一页

xxxx/file/groupid?offset =52 &limit= 50 第二页  这样中间遗漏掉一条也是不容易被发现的。


本部分结束,以上都是血和泪的教训,后面又想起来别的案例再做补充。

最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 205,386评论 6 479
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 87,939评论 2 381
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 151,851评论 0 341
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 54,953评论 1 278
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 63,971评论 5 369
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 48,784评论 1 283
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 38,126评论 3 399
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 36,765评论 0 258
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 43,148评论 1 300
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 35,744评论 2 323
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 37,858评论 1 333
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 33,479评论 4 322
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 39,080评论 3 307
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 30,053评论 0 19
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 31,278评论 1 260
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 45,245评论 2 352
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 42,590评论 2 343

推荐阅读更多精彩内容