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

昨日应领导之要求参加了由 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. 开阔眼界，时常补充新知识。在平时的工作中，由于需求迭代比较快，积极响应需求，保质保量地完成工作。最近有点儿疏忽关注新知识的发展，这样不好，导致思维不够开阔，对于解决具体的问题还是有阻碍的，以后得改进。