记一次阿里MQC测试沙龙

天气不错啊，至少看起来，也就看起来不错。太热了！

阿里巴巴园区 去的路上

看到微博上这样一句话：

好了，抒情完毕。说技术，此次技术，我所看到的一些亮点。

技术点一：在做自动化测试的时候，一些游戏上的元素是如何定位到的？

在游戏的自动化测试中，有些时候，就不容易定位到元素的位置，比如说，选择游戏人物，或者将人物具体移动到草丛中去，一个游戏画面上，草丛哪来的什么id或者XPath，这时候就不能用传统的方法去定位了。对于这种情况，有两种解决方法：一个就是向腾讯一样弄个sdk进去；另外一种方法就是用图像识别技术。

注意图片中的红框，点击操作，就是点击的那个红框。
用到的技术是用的图像识别技术，我自己的想法是，应该有个UI设计师提供的人物的图片作为图片源作为参照，用图像识别技术识别出画面中的具体某个人物。但是这个就有个识别率的问题，而且屏幕有些分辨率也不同，这时候如果再拿来对比，可能识别率会是一个问题。
阿里MQC平台的一份测试报告模板。对了这个平台还有一个特点就是，对于bug，能重复的复现出来。

MQC平台

技术点二：我们经常说的性能测试，这些性能测试要测哪些指标？

技术点三：Java或者说Android经常出现的内存溢出是如何产生的？并且如何尽量避免？

其中的Cursor是连接数据库进行读写时的一个接口，连接数据库后摇记得关闭。
那什么又是WeakReferenc？可以参考这篇文章，理解Java中的弱引用（Weak Reference）这篇文章中引用部分有句话比较有意思。

弱引用对象的存在不会阻止它所指向的对象变被垃圾回收器回收。

刚一读这句话没明白过来，好，把句子分解下，“不会阻止”，双重否定表示肯定，把不会阻止去掉，这句话就好理解了。用弱引用对象就会被垃圾回收器回收掉，那么这就又有一个问题了，那什么样的引用不会被垃圾回收器回收掉？那就new来创建一个新对象时返回的引用就是一个强引用。弱引用的格式大概如下：

productA = new Product(...);
WeakReference<Product> weakProductA = new WeakReference<>(productA);

技术点四：关于GPU的过度绘制问题。

其实这个问题可以归结为测试产品的流畅度的问题上，说到产品的流畅度，看过腾讯出品的《移动App性能与优化》后，要说下历史。原来的测试产品的流畅度，FPS是一个重要的指标，

但是用了一段时间后，人们就发现了这样两个问题：
1）为什么有时候FPS很低，但是我们却不觉得App卡顿？
2）App停止操作之后，FPS还是一直在变化，这样的情况是否会影响FPS的准确度？
后来测试人员分析了系统获取FPS的原理后，找到了那两个问题的答案：
1）有时候FPS很低，我们却感觉不到卡顿，因为本来就用不到那么高的FPS，比如画一个动画只画了0.5秒就画完了，那么FPS最高也只有30帧/秒（标准是60帧/每秒），但这并不代表它是卡顿的，用0.5秒动画就画完了，不能为了凑够60帧/秒，在做个1s的动画吧。而如果屏幕根本没有绘制需求，即屏幕显示的画面是静止的，那FPS就为0。
2）App停止操作后FPS还一直变化，是因为屏幕每一帧的合成都是针对手机里的所有进程，那么即使你的App停止了绘制，手机里其他进程可能还在绘制，比如通知栏的各种消息，这会导致FPS继续变化。从这里我们也能看出，在测试的时候，其他的进程对FPS也是有影响的。

后来测试人员想了想还是别FPS了吧，咱们还是玩SM吧！

那什么是卡顿的主要原因呢？
Android 4.1（JB）引入了VSync机制，是Vertical Synchronization（垂直同步）的缩写

那其中的一个个小块可以看做是显示的一个任务，上面那张图片是正常情况下，也就是不卡的情况的，那么卡的情况是怎样的呢？

可以看到有的模块越到了下一个间隔里面去处理，本来下个间隔是要处理A这个任务的，但是B没处理完，只能去处理B，A的任务在这个间隔里也不能接手了。这种情况叫做
失贞，不是，叫丢帧（Skipped Frame，SF），还不如英文直接翻译为跳帧更形象。这种情况举个例子更好理解。
VSync机制就像是一台转速固定的发动机（60转/s），每一转带动着去做一些UI相关的事情，但不是每一转都会有工作去做（就像有时在空挡，有时在D档）。有时候因为各种阻力某一圈工作量比较重，超过了16.6ms，那么台发动机这秒内就不是60转了；当然也有可能被其他因素影响，比如给油不足（主线程里干的活太多）等，就会出现转速降低的状况，我们把这个转速叫作流畅度。

有了这个基本的概念之后呢，接下来就好理解了一些：

图片中有一点提到了“避免复杂重叠的视图”，举个例子，在安卓开发中，比如在xml文件中的background设置了一个绿色的背景，然后在这个背景上又放了张图片完全作为背景了，或者又设置了一个新的背景，相当于遮盖的地方就重复绘制了。图片中1x，2x，3x那些，指的是UI图中那些颜色的是重复绘制了1次2次3次。。。

技术点五：安卓启动时，启动了哪些进程？冷启动与热启动。

Zygoto进程孵化出其他进程。

技术点六：如何查看不同方法和进程的消耗时长？

重点啊，比如有的APP打开慢，那是什么原因导致的，是哪些方法或者进程启动时比较慢？用TraceView就能查看了

这张图片不清楚，看这张

可以看到其中调用了哪些方法，已经运行的时长。TraceView使用教程可以参考这篇文章正确使用Android性能分析工具——TraceView
MQC平台也有类似的功能，比它做的更好看，更实用些，不过照片忘拍了，哈哈哈哈哈，广告白做了。

技术点七：什么是StrictMode？

StrictMode应该是安卓提供的一个类，这个类里有一些方法，我们知道当安卓运行时是有一个主进程的，如果主进程阻塞了，那么这个系统就可能变得慢或者卡死，而我们的程序有时候运行时，有些比如读写磁盘请求啊，或者网络请求就需要用到主进程，为了避免主线程被阻塞的发生，主线程处理UI和动画在磁盘读写和网络操作时变得更平滑，所以可以用StrictMode。

它的代码在安卓开发文档上就有，使用教程可以参考这篇文章Android最佳实践之：StrictMode介绍

技术点八：一个比Monkey要好的，可定制的自动便利工具。

工程师是来干啥的？工程师就是来解决问题的，现在测试有什么问题？

那如何解决呢？

阿里用的是一个叫ripper的工具，类似monkey，也是用个命令就能跑，不过比monkey高级，monkey是乱点，ripper能够是自动便利，有句话叫“无法复现的bug没有价值”，monkey跑崩溃了，也没处找去，而ripper能够复现，不需要人工参与，能记忆跑过的路径。上面的图片中是，结合很多APP做分析，然后有点大数据思想的归纳出的可点击的控件。这种自动遍历有个好处就是能触发异常的场景，一个用例是只有精神病人才能想出来的，或者给猴子一个手机拿着玩才能触发的，这种用例正常人根本设计不出来好吗。

技术点九：思寒大神的AppCrawler框架

先占坑，内容太多，等社区发了ppt在说吧，总之很牛x很牛x，思寒大神的技术品味要学习啊，要用Jmeter，Londrunner只是古老的企业在用。断言是上个世纪的做法，这个世纪要想着用用机器学习。思寒大神肯定不是为了机器学习而机器学习的，而是真的利用到了机器学习的思想，比如AppCrawler非常有实用价值的diff功能，就是用的机器学习里面的一个基础的概念。

总结：现在用到了许多图像识别，大数据，还有机器学习的方法，尽管这些概念让媒体炒得有点多了，但是作为技术人员没关系的，这些东西确实能利用到。千言万语汇成一句话：