android测试-UIAnimator和Espresso的配合使用

这里不聊为什么android要进行UI测试,主要聊一下android studio集成的两种测试包的区别以及如何搭配使用。 

android studio集成了两种的UI测试包Espresso和UIAutomator,搭配使用起来也非常方便(一个测试类中两种测试代码可以混搭使用)。Espresso主要是用于应用内的测试;UIAutomator是用于跨应用的测试。个人觉得:

(1)Espresso非常适合用于单页面测试,之所以这么说,是基于以下原因:

     (a) Espresso测试有个很强大的功能是它在多个测试操作中是线程安全的。Espresso会等待当前进程的消息队列中的UI事件,并且在任何一个测试操作中会等待其中的AsyncTask结束才会执行下一个测试。这样就不用处理各种UI加载快慢导致的测试用例运行奔溃问题,这点要比基于Instrumentation的测试框架要简单的多,后者主要是通过设置适当的等待时间,来等待UI绘制完成在进行后续的测试动作,例如打开一个activity后要点击一个按钮,使用后者的测试代码需要在写完“打开activity”这个测试代码后,测试代码中要专门设置一个适当的等待时间,然后才能继续写“点击按钮”测试代码,否则直接执行“点击按钮”操作很容易出现测试奔溃的情况。

        (b) Espresso可以模拟页面间的跳转和数据通信。页面间跳转和数据传递,可以用模拟的方法进行测试,而不需要真正跳转到其他页面。比较典型的例子是,测试页面通过startActivityForResult()跳转到a页面,然后关闭a页面返回到测试的onActivityResult方法时,往往会携带Intent数据。这时就可以使用espress-intents包来模拟发送这个Intent数据,而不需要真正的跳转到a页面。因此,一个activity页面在使用Espresso测试时,最好是一个测试类对应一个activity页面,这样比较清晰明朗。

        (c) 基于第一点的UI事件驱动测试流程的原因,Espresso测试的运行速度很快。

(2)UIAutomator比较适合多页面或跨应用的功能测试。

      (a)所谓的功能测试通俗讲就是一连串的页面跳转,一个app一般都有几个主要的功能流程,例如注册流程、登陆流程等,这些流程都包含一系列的页面跳转,这种跳转可能要跳到其他app页面或者系统的页面。例如“蓝牙搜索”功能大致流程如下:启动页面->弹出用户权限对话框->弹出系统蓝牙开关对话框->蓝牙搜索页面。这当中涉及到系统的弹框,这时候使用Espresso就比较麻烦了,Espresso要实现IdlingResources接口,然后将这个实现类在app代码中(注意不是在测试代码中)实例化,通过阻断测试进程来等待用户弹框的操作结果,这样不能完全分离app代码和测试代码,而且阻断了自动化测试过程(因为要等待测试人员手动点击系统弹框),这是我们不希望看到的。使用UIAutomator可以非常简单的自动点击系统弹框,而且不需要在app页面中嵌入测试代码。

        (b) Espresso也可以进行多页面跳转测试,但是它只能获取入口activity的实例,一旦跳转到其他页面,就不能获取(或者说很难获取)到当前activity的实例,这对有些测试情况是很不友好的,例如异步加载数据然后刷新UI的情况。

因此,个人的做法是:

(1)单页面测试主要使用Espresso,这可以覆盖绝大部分页面的详尽测试。

(2)整个app梳理出几条主要的功能流程,针对这些功能流程,使用UIAutomator配合Espresso编写测试用例。

了解更多资料可以加我QQ: 1914532832  验证信息请注明:Android开发


©️2020 CSDN 皮肤主题: 大白 设计师:CSDN官方博客 返回首页