之前一直给大家推荐技术文章,今天换个口味,推荐一篇我司测试团队明一同学写的文章,作为开发,我也经常会关心测试方面的进展,也买过一些测试的书专门学习,毕竟高质量的产品需要开发与测试共同保障,尤其是用户规模与质量要求非常高的一些产品,单靠开发很难高效地保证最终产品质量。
今天这篇文章虽是测试同学的总结与吐槽,相信不少开发同学也会感同身受,我司测试团队有一个测试相关的公众号在运营,里面有不少测试经验总结。坦白讲,作为开发我感兴趣的内容有限,不过相信大家也有一些做测试的朋友,不妨推荐给他们关注下,文末有公众号二维码。
由于安卓系统的开放性,OEM厂商和运营商都会对Android进行定制。
于是安卓的大航海时代来了。
Android设备五花八门,各种Android手机、平板、电视、手表层出不穷,Android电冰箱电饭锅乱入… ...
随着设备、品牌、系统版本、屏幕、分辨率碎片化的不断加深,兼容性测试一直在折磨着测试人员。
据统计,我们团队中做过兼容性测试的男性有2/3在已经开始谢顶,每做6个月兼容性测试寿命就会缩短半年。
So问题来了:挖掘机技术。。。兼容性问题一般跟啥有关?
排名不分先后,不吹不黑原因多到数不过来:
Android的API版本
屏幕尺寸 & 分辨率
任性的Launcher
特殊ROM行为
系统Webview差异
手机GPU
Open GL
其他软件
存储卡
输入法
网络
语言
X86
深度定制的魅族…
…
挑几个常见的唠唠吧。
应用需要判断运行时设备的系统版本,不能调用高于设备本身Level的API,也要做好低版本兼容实现, API Level的兼容性处理不好经常会导致FC。
尤其新的系统版本更新、新产品和新功能都需要考虑API版本的兼容性测试。
举个例子,我们前阵子做了一个吊炸天的动画,使用了比较新的API,但开发时没有注意到API Level,然后在2.3的设备上一旦播放这个动画就FC。
Android版本和API Level对应关系,可以参考:
http://developer.android.com/guide/topics/manifest/uses-sdk-element.html
Android设备的屏幕尺寸太多了,同尺寸手机分辨率也不尽相同。
一般尽可能使用线性或相对布局;统统使用绝对布局的开发人员建议乱棍打死。
另外就是dp和px单位换算的问题,不同的设备屏幕密度可能不一样,开发人员在coding的时候,直接使用px的话在小屏和屏幕密度特别大的设备上会特别难看。
问题会更多的出现在小屏设备上,瞅瞅240*320分辨率上俄语、阿拉伯语文案那酸爽…
新产品和新功能可以在模拟器上看过效果后、扩大范围组织一下Bug Bash;模拟器有时也会不靠谱,推荐云测试平台的截图功能。
关于屏幕分辨率信息,可以猛击我查询:http://screensiz.es/phone
众多系统厂商以及第三方定制的桌面(Launcher)在适配和兼容性方面常常不一样,就拿桌面快捷方式来说我们就遇到过这些问题:
不能添加快捷方式到桌面
不能删除快捷方式
买一送一添加了两个快捷方式
无法更新快捷方式图标
快捷方式图标被拉伸
快捷方式图标被替换
创建快捷方式时应用挂了
栽赃陷害,在程序启动之后Launcher让一个大大的广告弹出来糊满屏幕…
经过深度定制的Flyme确实有很多亮点,但其深度定制也产生了比其他机型多得多的兼容性问题,比如:
安装失败
卸载失败(这你能信?)
天杀的屏幕适配
文本框/输入法闹鬼
根本不能打开推送
出现两个底部菜单让人误以为眼花
如果只买三部测试机我一定买一部魅族…
除了依靠测试人员的经验保障产品质量,还可以用一些第三方的测试服务;在产品上线后,也要对线上数据充分地理解分析,与开发一起及时发现与定位问题。
早上产品往Testin、MTC、TestCloud、易测云、Testdroid、Test bird、TA云测 blabla一堆云测试平台上一挂,晚上收货满满一筐问题(什么?还要定位提单?老板今天平安夜我要搞对象好吗)
说到数据分析, Play Store最近更新了,能够看到分数最低的机型、语言、应用版本、系统版本和地区,这对于分析线上兼容性问题也是一个挺有效的手段。