关于QCon2015感想与反思

QCon2015专场有不少关于架构优化、专项领域调优专题，但能系统性描述产品测试方向只有《携程无线App自动化测试实践》。

 

（一）. 携程的无线App自动化

    《携程无线App自动化测试实践》主要介绍了 携程在App自动化方向 进展。

1. 先总结下他们做到了些什么：

（1）. 移动设备真机自动化测试集群，及集群监控。

（2）. 集群中设备可提供远程人工控制服务（远程操作手机屏幕）。

（3）. 基于Appium编写案例。

（4）. 建立基本的自动化测试模式（自动化案例：手工案例 为 3:7）。

2. App自动化测试的产出效果：

,

（二）. 反思

1. 携程的可改进之点：

（1）. PC利用率低下：携程1台PC只挂2台移动设备。

adb查找设备/模拟器 端口是5555~5585，每个设备/模拟器占2个端口，所以PC一般可以挂15个设备/模拟器。当时我们做移动自动化测试时，就是一台PC挂6~8台移动设备。

当然，携程不这么做肯定有原因：

a）adb-server与移动设备 I/O 时，会不定期出现卡死。

原因：移动设备没有返回，导致adb-server一直read()不到数据。另外，adb-server和设备I/O时，是加锁并且没timeout的，这将导致：一台设备读卡死，其他设备也别想干活了……

解决方案：adb监控，发现异常adb，干掉并重启。重启adb会有副作用（执行中案例会失败），但可通过：案例执行的幂等 与 重复执行失败案例 解决。

b）adb无法承受大量 I/O 并发

            adb设计目标并不是为了高并发（从 锁+子进程数限制 可见）……所以当15台设备同时进行高频指令传输时，是很慢的……但单PC负载6~8台移动设备，还是可以的。

       

            所以，恶意猜测下，携程只挂2台目的就是为了省事。

（2）. 测试结果 不具备 功能正确性  结论

携程的某些测试类型（如：可达性测试、及所谓的冒烟测试......）不能给出功能正确性判断。这在业界是有争议的，一部分人认为：可测试Activity页是否崩溃/Webpage是否加载成功；另一部分则认为：需要人手返工测试，保证功能正确性，所以它没必要存在。个人更倾向后者。另外，这也从侧面反应出一个问题：UI级别的自动化测试实施不容易，这里就不扯远了。

2. 携程的可取之处：

（1）. 提供设备远程人工控制服务（远程操作手机屏幕）。

该功能其实并不新鲜，Testin早在2012年已对外提供类似服务，只不过13年后屏蔽对外。它的优点在于统筹资源，可减少设备冗余。

（2）. 基于Appium编写案例。

我之前也负责过YY的移动端测试框架"TestAgent"的实现与维护，之所以认为 基于Appium实施自动化测试 可取，原因有二：

a）能提供良好的 案例编写/编程 风格。

UI自动化测试框架实施，我认为有3个重点：

1. 操作 被测试应用 UI元素 的方法。

2. 提供易读，易用API。

3. 提供方便，完备的 元素索引 方式。

其中2，3是编写优雅测试案例的基础。当然，对于2，3，Appium和TestAgent都是具备的。

b）开源社区支持。

Appium与其他测试框架（包括：阿里，百度，还有YY……）差别就在这里。

                开源社区提供了：大量经验交流，技术支持与持续改进； 

 

                另外，开源工具的广泛普及也降低了日后人员招聘和业务交接的难度。

（3）. 携程拥有独立的基础工具研发部门支撑各上层业务测试

以上说的优与劣，皆技术层面问题。但这个非技术性问题，才是我最大感触。

                自从测试中心分拆到各个项目组后，带来了更高效的项目团队，但我感觉存在一些副作用：知识与工具共享比以前困难。我想这也可能是测试中心拆分后，自动化测试方面突破有所减缓的原因之一，业务测试人员在日常测试中是很难兼顾 工具开发+自动化平台运营 与 案例编写+维护 2种职责的。携程自动化测试有此进展，其有基础工具部门支撑是很大原因，而这也是恰恰公司所缺乏的。