关于QCon2015感想与反思

  1. 云栖社区>
  2. 博客>
  3. 正文

关于QCon2015感想与反思

长征2号 2017-10-19 21:17:00 浏览648
展开阅读全文

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

 

    (一). 携程的无线App自动化

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

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

    (1). 移动设备真机自动化测试集群,及集群监控。

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

    (3). 基于Appium编写案例。

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

         Image

 

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

         Image(1),

 

    (二). 反思

    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种职责的。携程自动化测试有此进展,其有基础工具部门支撑是很大原因,而这也是恰恰公司所缺乏的。
 


本文转自hyddd博客园博客,原文链接:http://www.cnblogs.com/hyddd/p/4932595.html,如需转载请自行联系原作者。

网友评论

登录后评论
0/500
评论
长征2号
+ 关注