MTSC 2017 技术为辅,思维主导——中国移动互联网测试开发大会有感

dragonking0318 for 第三届中国移动互联网测试大会 · 发布于 2017年07月21日 · 最后由 Ningxw 回复于 2017年08月14日 · 最后更新自管理员 Lihuazhang · 3826 次阅读
本帖已被设为精华帖!

中国移动互联网测试开发大会有感

昨日应领导之要求参加了由 TesterHome 主办的中国移动互联网测试开发大会,说实话我本来不喜欢参加这类大会的,因为一般这类大会很多时候都类型于做广告。我们公司有一个产品A,这个产品有什么功能,能解决什么问题,吹嘘一番,然后要使用我们的产品不是办会员,就是要去购买。然后换一个人,再去介绍产品B,同样的思路,到头来没有什么收获。不过昨天的大会还是出乎我的意料呢,不能说收获满满吧,还是开阔了思路,增加了不少见识。

现在就我个人的感触总结一下,仅供大家参考。

一 保持传统,广告宣传

传统的这类大会都会有不少公司来介绍自己的产品,本次也不例外,介绍了不少类似的东西,如:Google Mobile Testing,工信终端操作系统测试评,华为云测试,去哪儿去测试体系,以及所打的广告腾讯WeTest,迪原云测试平台,还有百度MTC云测试中心等等。

此类关注提供测试平台,测试服务的公司在很早的时候就出现了,可是市场前景并不好。具体原因我没有太过关注,就我个人分析:这类公司的客户一般是小的创业公司,他们没有太多的财力去组建自己的测试团队,而又需要保证自己产品的质量一般会供助于此类平台或是公司。而稍微有能力的公司都会组建自己的测试团队,一是出于商业机密和安全考虑,尚未投入市场的产品就交给第三方来测试,这是不妥的。二是,产品,开发和测试都是自己的团队,优化和修改起来也比较快捷,而不用等第三方的测试结果。

这类广告一般不会有相应的设计思路分析,只会了解到有什么相应的功能 ,酷玄的界面和详细的报表,这倒是可以借鉴的。不也不用太介意此类的分享,听听即可。

二 深入分析,全面测试

当我看了下午各个会场的分享目录后,第一感觉是:其实大家做的东西都差不多嘛,接口测试,UI测试,持续集成,好像也没有太多新鲜的东西。但是我也要去学习一下,看一下同样的东西大家是怎么做的。听过之后发现自己还是有点儿浅薄的,具体表现如下:

(1)接口测试

通常我们做接口测试是通过 python requests 模块来编写相关的代码,加上 unittest 模块,HTMLTestRunner 来进行检测和生成报告。如果做的大一些儿,就是编写接口自动化测试平台,进行接口文档管理,测试用例生成,用例集管理,日志记录和环境切换等功能。个人感觉还是不错的,至少比仅仅写代码高级多了。听了搜狗和饿了吗他们做的接口自动化测试,感觉还是有很多需要考虑的地方:

  1. 环境切换方法的不同:我是通过在执行服务器上添加相应的 host 来进行切换;而他们是通过对测试环境进行相应 IP,域名配置,解析请求的 DNS 来进行环境的切换。
  2. 测试数据来源的不同:通常的接口测试数据是通过数据文件,如 TestNG 的 dataprovider 或是数据文件 XML 来提供;当然也有通过 mock 平台来提供的。而他们主要是通过 mock 平台来提供数据,正向的数据通过 mock 线上接口,逆向数据可以修改 mock 数据提供。也有分析请求日志来解析相应的测试参数数据,进行进行测试。
  3. 测试用例生成不同:通常的接口测试用例都是自己通过相应的编码语言来编写的,不过感觉目前的测试平台的开发趋势和市场上其他产品越来越类似了。操作越简化越好,通过简单的点击几个,填写几个数据就能完成相应的测试操作。所以测试用例也趋向于自动生成,通过填写参数与预期结果,自动生成测试用例;还有就是他们分享的通过解析线上请求日志来自动生成测试用例,总之就是操作越少越好。
  4. 后续统计操作:在我日常做的接口自动化过程中,如果用例出错会记录相应的出错日志,以便查看报告的时候排查错误;没有做相应的统计工作。现在其他公司在接口自动化的时候,对报错日志执行结果做了相应的统计与展示。

(2)UI自动化测试

移动端自动化测试,主流还是通过 Appium, Robotium, UIAutomator 等开源框架,接口用例也是通过 Java 或是 Python 编写相应的自动化测试用例。也有通过相应的录制工具进行测试用例录制,而后改写而成,自动化的检测也是设置相应的检测点,检测预期结果。而如去哪儿网的移动端自动化测试,做的就比较有特色:

  1. 用例自动生成,通过相应的测试工具进行测试用例录制,然后通过相应的框架转化成具体可执行用例。
  2. 图片对比验证:通过设置的检测点是普通文字,至于图片只检测存在与否。而去哪儿则是通过保存屏幕截图,对比两个不同版本的相同页面的截图进行检测;也可以对要对比的图片进行裁剪,而后指定对比的对象。这一点倒是思路奇特,图片对比还是比较复杂的。
  3. 后端数据对比:在录制测试用例的时候,不担保存相应的屏幕截图,也保存相应接口的后端返回数据;检测执行结果的时候,同时对比相关的数据。后端数据通过 mock 进行保存或是修改相应接口数据,修改接口数据为异常数据,检测页面异常展示。
  4. 测试数据与执行机型对应存储:在我们编写或是生成测试用例的时候,如果有座标定位的时候,往往因为执行机型不同而至测试用例兼容性较差。而去哪儿在自动生成测试用例的时候,对测试数据与执行机型做对应保存,执行时候比对机型而去取数据。这点儿做的非常巧妙,值得借鉴。

(3)专项测试要深入

在移动端测试的过程中,对app需要进行专项测试,如果首屏加载时间 ,app下载,安装时间,用电量等方面进行测试。我们通常的做法是借助于第三方工具,或是android studio等进行相关的测试;我没有做过太多相关的测试,不过好像也没有了解过太多的其他方法。而腾讯在这方面的专项测试还是比较厉害的,听也还是挺有感触的:

  1. 安装包瘦身:他们会从冗余代码或是jar包,方法数和代码混淆,资源优化,极限压缩和插件化等方面进行优化。这些方面已经超过我们测试考虑的范围,可是这些儿确实是优化的最好办法。
  2. 启动优化:从UI层优化,避免过度绘制,view延迟加载,布局不合理,逻辑层优化,本地任务执行,网络协议优化等方面进行相应的测试以提出优化建议。
  3. 电量测试方法,通常电量测试方法也是非常多的,我们测试的时候也会用到。不过腾讯还是提出了一个非常好的方法,直接调用android获取电量信息的方法,用来展示我们要检测的应用的用电量以及获取大量耗电的方法,此点倒是让人眼前一亮。

在我们以后做专项测试的时候,不能只局限于表面或是现成的工具;要深入了解产生问题的原因或是要测试对象的底层现象。而后再去做相应的信息汇总或是排查,以达到我们测试的目的,迅速定位问题所在。

三 结合自身,深刻反思

我做测试开发已经五年了,在工作过程中也做了不少相关的东西,接口自动化测试,服务自动化测试,页面自动化测试,测试平台的开发,解决实际问题的脚本也写过不少。结合我们公司现在做的很多东西,也让我提升了不少,对此我深怀感激。听了这次大会分享,深刻地感觉到技术还是那多么技术,可是在通过不同的思维方式,可以设计出非常多独具匠心的好东西的。同时也深深地感到自己有不少不足之处:

  1. 考虑问题不够全面深入。在解决具体的问题的时候,针对问题设计好了详情的解决方案,也能很好地解决问题。不过对周边相关的考虑不够全面,如果没有对执行数据,出错信息进行相关的统计或是汇总。
  2. 缺乏对困难的挑战和深入的探讨。在做页面自动化时候,一直认为图片对比比较困难,也就没有再做深入的探讨,就只是判断相应的图片位是否存在。这只是一个例子,还有其他的方面需要进行反思。
  3. 数据统计和展示方面欠缺。在做自动化测试或是其他方面测试的时候,没有做深入的统计工作,还有就是展示统计结果,在这方面前端知识就比较欠缺,还是需要设定相应的目标补充相关知识。
  4. 开阔眼界,时常补充新知识。在平时的工作中,由于需求迭代比较快,积极响应需求,保质保量地完成工作。最近有点儿疏忽关注新知识的发展,这样不好,导致思维不够开阔,对于解决具体的问题还是有阻碍的,以后得改进。
共收到 12 条回复
110

感谢楼主的思考和总结。我帮你改了几点:

  1. testin这次没有赞助,所以没有他们的广告,这次是我们的金牌赞助——迪原
  2. 排版格式进行了调整
  3. 节点进行了调整

楼主说到的广告问题,

  1. Google Mobile Testing
  2. 工信终端操作系统测试评
  3. 华为云测试
  4. 去哪儿去测试体系

这几个其实应该是软广,他们介绍了自己公司使用的测试技术以及自己公司对移动测试做的努力。谷歌的topic让外人了解了谷歌内部的测试。工信部的topic可能对一般一线的测试工程师没有帮助,但是对我这种做过操作系统的人其实是很有感触的,这个很有可能就是一个指导性的ppt。华为的有点硬广,不过华为的实验室的实力不容小觑,对标谷歌,体现了国内的测试水平。去哪儿没研究过。😵

当然后面的是硬广,但是他们没有topic,在外面的展台上,

  1. 广告腾讯WeTest
  2. 迪原云测试平台
  3. 百度MTC云测试中心
110 Lihuazhang 将本帖设为了精华贴 07月22日 08:48
8d5594

非常认同,之前还被人怼了说策略什么的都是虾扯,技术才是关键,其实我比较向往用产品思维来做测试的方法,就是思维主导的意思,技术再牛,没有好的策略和思维,空谈

56d552

总结的很不错,我做测试也几年了,功能、自动化、接口都有做,感觉在测试结果的统计和展示方面投入的比较少,一直没有形成一些简明扼要的模板,拿给业内人看还好,给外行展示就比较麻烦了

E5e79f
110Lihuazhang 回复

好厉害的样子~
求问大会有没有录制视频?或者其他的材料可以分享给离北京很远没能参加的tester?付费也是可接受的

1406
E5e79fippppp 回复

关注他们的公众号,他们有分享当天的PPT,不过一直没有看到相关的视频的

1406
56d552YangClyde 回复

前两年测试开发只需要写相关的代码,解决我们遇到的具体问题即可。最近一年多要求我们测试开发必须会前端的东西,如果你的东西做的非常牛,可是很难给其他人展示也是硬伤的。

56d552
1406dragonking0318 回复

哈哈,倒不是有多牛,只是觉得在工作中技术上的问题都能解决,哪怕麻烦点、查些东西、请教下别人,但是遇到需要展示测试结果产物的时候,会遇到不少麻烦。还是没有形成一个很好的前期规划思维,后期各项产物不规范,所以,展示起来麻烦比较大

342

说实在话,这次大会的内容有些重叠,碎片化这个概念都听了4,5遍,反正说云测的基本都是在做广告,参会为了开阔视野,拓展思路,这些云测在各个官网上都可以看到,不必要讲解这么细;

110
1406dragonking0318 回复

视频剪辑需要时间。请耐心等待。

7c6fd9

这就好比战略与战术吧

852
1406dragonking0318 回复

感觉说的很对。。现在测试需要懂前端了,感觉随便做个什么工具就得靠前端来展示

110 Lihuazhang 关闭了讨论 08月10日 14:20
110 Lihuazhang 重新开启了讨论 08月10日 14:20
16120

总结得很到位,对我有启发~之前处于瓶颈,不知道在自动化上还能怎么开展下去,现在看来,我还是有很多未做到位的地方~共同努力吧!

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