第 2 章 本机应用程序的 UI 自动化测试

第 2 章 本机应用程序的 UI 自动化测试

使用 Calabash 编写跨 Android/iOS 平台的测试

山内沙瑛 YAMAUCHI Sae

贾成锴 JIA Chengkai

小俣裕一 OMATA Yuichi

DeNA 股份有限公司

译 / 刘卓

在对智能手机的本机应用程序实施 UI 自动化测试的时候,会出现测试框架或使用的语言因手机系统的平台而异、开发资源受到限制等多个问题。在本章中,我们将要介绍如何使用 Calabash 测试框架解决这些问题,实现跨平台的 UI 自动化测试。

Calabash 简介

Calabash 的特点

首先来简单介绍一下 Calabash 的特点。

同时支持 Android/iOS

Calabash 可以同时支持 Android/iOS 两个平台的真机和模拟器,将两个平台的测试开发语言和测试代码等通用化,实现高效的测试开发。

支持最新的操作系统

由于目前框架也处在积极开发的阶段,所以用 Calabash 编写的测试代码不论是现在还是将来,都可以运行在最新版本的操作系统上。

支持 Web 视图

由于通过组合 Calabash API 的查询和 CSS 选择器可以指定 Web 视图(WebView,分为 iOS 的 UIWebView 和Android 的 WebView)中的元素,因此可以完成点击链接或向文本域内输入字符等操作。

query("webView css:'#header'")
touch("webView css:'a'")
set_text "webView css:'login", "hoge"

支持定制视图组件

支持单独实现的定制视图组件。

使用 Ruby 编写测试代码

如果在测试时,既要使用非主流的开发语言,又要使用特殊的框架,那恐怕要花费很多学习成本。Calabash 的默认开发语言是 Ruby,因此使用时完全不需要有这样的担心 1

1预计在将来也会支持 Ruby 之外的语言。

可以分别编写测试场景和测试代码

Calabash 框架的主要目的是验收测试,因此使用了在 Rails 开发中常用的 BDD(Behavior Driven Development,行为驱动开发)工具 Cucumber2。使用 Cucumber 可以让测试人员等非开发人员编写测试场景,来分担开发人员的工作,而开发人员只需编写测试代码即可。

2也可以和 Cucumber 之外的工具配合使用。

提供实现测试的支持功能

开发测试的方法有两种,一是从头开始编写测试代码,二是按照测试场景对用户操作进行录制和回放。Calabash 可以利用录制和回放功能作为测试开发过程的一部分 34

3在本文发布时只有 calabash-iOS 中包含此功能。

4这句话的意思是 Calabash 可以先用录制和回放功能录制测试场景的代码,然后再通过编程的方式修改前面录制好的代码,以此完成测试的开发。——译者注

支持 UI 语义查询

在描述测试场景和测试代码时,用于指定目标操作元素(视图组件和页面等)的 API 在 Calabash 中被称为查询(Query)。

例如,页面上有 3 个按钮,如果想要指定页面上第 2 个、坐标为(100, 200)、标签显示为“登录”的按钮,有如下几个方法。

  • 语义指定

    以“(点击,下面省略这个动作)登录按钮”的形式,通过组件的名称或标签等功能自身含义的相关信息来指定。

  • 模拟指定

    通过“坐标(100, 200)”的方式,使用模拟坐标信息间接指定。这种方式不能保证在不同 分辨率的设备上正常工作。

  • 元素顺序指定

    通过“第 2 个按钮”的方式指定元素。即使屏幕分辨率有所不同也可以正常工作,但如果页面设计出现变更,增加按钮数量或是改变按钮顺序的话,就无法保证该方式能正常工作了。

  • 图像指定

    通过“与图像 A 匹配的按钮”的方式指定元素。不易受页面上显示的坐标和组件顺序的影响,但准备图片时使用的设备和实施测试时使用的设备之间如果存在差异,就无法保证该方式能正常工作了。这种方式并不被 Calabash 的标准 API 所支持,而是使用了 Ruby 的一个外部程序库。

一般来说,语义指定方式受设备和页面修改的影响最小,可读性、易用性也最佳。

交互式控制台

配置 console 选项并启动后,会显示 irb shell 命令提示符窗口(Prompt),表示 Calabash 的 API 为可用状态。在这个窗口中可以进行查询元素、触发触摸事件等操作,因此可以一边尝试着操作应用程序,一边编写测试代码。此功能提高了开发测试的效率。

irb(main):001:0> label "button"
=> ["First", "Second", "Third", "Fourth"]
irb(main):002:0> touch("button index:1")

使用 Calabash 开发测试的 注意点

到目前为止,我们已经讨论了 Calabash 的优点,但也有一些应该注意的地方。

测试的目标系统为 iOS 时必须要将框架嵌入后重新构建应用程序

因为要使用 Xcode,所以最好事先准备一个用于 Calabash 的 scheme。

iOS 版和 Android 版的实现有所差异

Calabash 虽然 Android 和 iOS 都能支持,但由于操作系统或实现情况不同,同样的测试代码不一定能同时在两个平台上都成功执行。如果发生了不能执行的情况,则需要修改测试代码或增加宏等方式。

使用 Cucumber 编写的测试场景有时候会显得冗长

在笔者的团队中,虽然也认为由非开发人员编写测试场景(Feature 文件)、开发人员编写测试代码(Step 文件)这种分担作业的模式具有优势,但是在只由开发人员开发 UI 测试的案例中,使用 Cucumber 编写的测试场景可能很冗长,对于测试的执行起到负作用。在这种情况下不要拘泥于 Cucumber,而应与 RSpec 等其他框架一起使用。

Cucumber 简介

Calabash 中使用的工具 Cucumber 用接近自然语言的格式(称为 Gherkin)描述软件的动作,并与用 Ruby 编写的测试代码文件分离开来。

对于 Cucumber 中分离的两个文件,作为测试场景、描述软件动作的文件叫作 Feature 文件,实现测试的文件叫作 Step 文件。

下面,我们来简单说明 Cucumber。

描述动作的 Feature 文件

Cucumber 支持多国语言,当然也包括中文。Feature 文件保存为以 .feature 为扩展名的文件。下面给出了描述测试场景的 Feature 文件示例。

Feature 文件的示例( 英文)
Feature: login to Twitter

  Scenario: login using email address
    Given I have moved to top screen
    When I press login button at bottom
    Then I have moved to login page
    When I enter "abc@test.com" to the email field
    And I enter "hoge" to the password field
    And I press login button at top
    Then I should see timeline

Feature 文件的示例( 中文)
# language: zh-CN
功能 : 登录Twitter

    场景: 使用邮箱登陆
        假如 我在启动页面
        当 我按下下面的登录按钮
        那么 我会移动到登录页面
        当 我向email 字段中输入"abc@example.com"
        而且 我向密码字段中输入"hoge"
        而且 我按下上面的登录按钮
        那么 我会看到时间轴

如果想要定义中文 Feature 文件,要为 Cucumber 定义下面的关键字 5

5引自 ZoOl 的博客:http://zool.iteye.com/blog/737806

$ script/cucumber --i18n zh-CN
| feature          | " 功能"         |
| background       | " 背景"         |
| scenario         | " 场景"         |
| scenario_outline | " 场景大纲"     |
| examples         | " 例子"         |
| given            | "* ", " 假如"   |
| when             | "* ", " 当"     |
| then             | "* ", " 那么"   |
| and              | "* ", " 而且"   |
| but              | "* ", " 但是"   |
| given (code)     | " 假如"         |
| when (code)      | " 当"           |
| then (code)      | " 那么"         |
| and (code)       | " 而且"         |
| but (code)       | " 但是"         |

实现测试的 Step 文件

为了将用接近自然语言的格式编写的测试场景进行编程实现,需要创建叫作 Step 文件的实现代码。Step 文件中不止可以使用 Ruby 内嵌的程序库,还可以使用外部模块中的函数。Step 文件保存为以 .rb 为扩展名的文件。

下面是一个使用了 Calabash iOS 版 API 的示例。

# 确认在启动页中存在标签为login 的按钮
Given /^I have moved to top screen$/ do
  wait_for_elements_exist(
    [ "button accessibilityLabel:'login'" ],
    :timeout => WAIT_TIMEOUT)
end

# 因为只有一个按钮, 所以可以指定页面下面的第一个按钮
When /^I press login button at bottom$/ do
  touch("button index:1")
end

# 确认存在id 为login 的文本域
Then "I have moved to login page" do
  wait_for_elements_exist(
    [ "textField marked:'login'" ],
    :timeout => WAIT_TIMEOUT)
end

# 定义向文本域内输入任意字符的步骤
When /^I enter "([^\"]*)" to the (email|password)\
field$/ do |field, text_to_type|
  set_text("textField marked:'#{field}'",
           text_to_type)
  sleep(STEP_PAUSE)
end

执行 Feature 文件

准备好了 Feature 文件(.feature)和 Step 文件(.rb)后,就可以使用 cucumber 命令执行测试了。

$ cucumber features/twitter_login.feature

使用 Calabash 测试本机应用程序

从本节开始将要讲解如何使用 Calabash 制作并执行实际的测试。这个测试的对象是,使用了操作系统或 SDK 中标准包含的按钮和文本域等高级 UI 组件的本机应用程序。例如,Twitter 或 Facebook 等应用程序的页面多以高级 UI 组件构成,这样的应用程序就可以使用本节中介绍的方法来进行测试开发。

使用 Calabash 制作测试的基本知识

首先,我们来说明在制作测试时必不可少的、由 Calabash 提供的具体功能和 API。

Step 文件模板

Calabash 中除了 Cucumber 包含的 Step 文件之外,还单独提供了大量可以用于 Android/iOS 应用测试的 Step 文件模板。使用这些 Step 文件模板,测试人员就不必再从头开始实现测试了,从而大大减轻了创建测试时的负担。

不过,现在的 Calabash 版本中只提供了英文版的 Step 文件模板,因此如果要使用中文版的 Feature 文件的话,翻译 Step 文件等工作还是必不可少的。

关于 Step 文件模板和其中包含的函数的详细信息,可以参考官方文档 6 和源代码。

6Android https://github.com/calabash/calabash-android/blob/master/ruby-gem/lib/calabash-android/canned_steps.md
iOS https://github.com/calabash/calabash-ios/wiki/02-Predefined-steps

Calabash API

当然,我们也可以使用 Calabash 提供的 API 来单独定义步骤。

Calabash 提供以下这些 API。

  • 查询(Query)

    查询是指定应用程序页面中包含的高级 UI 组件及组件属性的检索 API。与 Web 开发中的 CSS 或 jQuery 选择器相似

  • 待机(Wait)

    在满足特定条件前保持待机状态的函数。与上面说的查询和助手函数组合,在满足条件前保持待机状态,这样一来便可以确保在后续步骤执行时满足该步骤所必需的前提条件

  • 断言(Assertion)

    与查询 API 组合使用,在没有满足指定的条件时,判断测试用例执行失败并保存屏幕截图

  • 硬件(Device)

    页面的触摸、模拟键盘的输入、屏幕截图的保存、设备的旋转、文件的发送和接收,等等

更多详细信息请参考官方文档 7

7Android Android https://github.com/calabash/calabash-android/blob/master/documentation/ruby_api.md
iOS https://github.com/calabash/calabash-ios/wiki/03.5-Calabash-iOS-Ruby-API

查询

使用频率最高、需要最先了解的 Calabash API 莫过于查询 API 了。查询 API 有如下使用方式。

# 取得满足条件的UI 组件的数组
query("button") # 取得页面上的所有按钮
query("button index:0") # 取得第0 个按钮
query("button marked:'submit'") # 通过标签取得按钮

# 取得满足条件的UI 组件的属性
query("button", :accessibilityLabel)

# 结合Ruby 语法
query("label").count # 取得元素数
query("button", :accessibilityLabel)[1] # 取得第2个按钮

更多详细信息请参考官方文档 8

8Android https://github.com/calabash/calabash-android/wiki/05-Query-Syntax
iOS https://github.com/calabash/calabash-ios/wiki/05-Query-syntax

触摸

使用 touch 函数可以触发页面或 UI 组件的触摸事件。指定 UI 元素的方式与 query 函数相同。

# 触摸标签为submit 的按钮, 坐标位置为(50, 0)
touch("button marked:'submit'",
      :offset => {:x => 50, :y => 0})

关于函数的详细信息,请参考注 6 的官方文档或源代码。

编写 Step 文件的示例

使用 Step 文件模板中包含的函数和 Calabash 的 API,可以编写出像下面这样独有的 Step 文件 9

9由于篇幅所限,这里省略了 sleep 函数和一部分正则表达式。

Feature 文件: 点击 submit 按钮
Then I touch the "submit" button

对应的 Step 文件
# 利用正则表达式定义出可以点击任意按钮的Step。
Then /^I touch the "([^\"]*)" button$/ do |name|
  # 点击指定标签的按钮
  touch("button marked:'#{name}'")
end

Feature 文件: 点击坐标(100, 250)
Then I touch on screen 100 from the left and \
250 from the top

对应的 Step 文件
Then /^I touch on screen (\d+) from the left and \
(\d+) from the top$/ do |x, y|
  touch(nil, {:offset => {:x => x.to_i, :y => y.to_i}})
end

Feature 文件: 获取屏幕截图
Then take picture

对应的 Step 文件
Then /^take picture$/ do
  screenshot_embed
end

Feature 文件: 向第一个文本域中录入文字text
Then I enter "text" into input fi eld number 1

对应的 Step 文件模板
Then /^I enter "([^\"]*)" into input fi eld number \
(\d+)$/ do |text, index|
  index = index.to_i
  set_text("textField index:#{index-1}",text)
end

Feature 文件: 等待登录按钮出现
Then I wait for the "login" button to appear

对应的 Step 文件
Then /^I wait for the "([^\"]*)" button to \
appear$/ do |name|
  wait_for(WAIT_TIMEOUT) {
    element_exists( "button marked:'#{name}'" ) }
end

Feature 文件: 向左滑动
Then I swipe left

对应的Step 文件模板
Then /^I swipe (left|right|up|down)$/ do |dir|
  swipe(dir)
end

实际测试示例应用

本节让我们以前面介绍的知识点为基础,测试一个简单的示例应用。下面的讲解都基于一个用户在表格中输入字符并点击按钮提交(输入的字符)的话,就会显示提交结果的应用。

图 1 输入前、输入中、输入后的状态

创建测试场景

首先要考虑的就是测试场景。

确认应用是否已经启动

通过键盘向标签为 sampleText 的文本域中输入 HelloWorld

点击标签为 submit 的按钮,将字符串提交

确认提交结果,即确认页面上是否显示了 HelloWorld

编写 Feature 文件

上面的测试场景用 Feature 文件来描述的话就会如下所示。

功能: 测试示例应用
Feature: Sample app test
  # 场景 : 提交文本测试
  Scenario: Submit a text
    # ❶ 确认应用是否已经启动
    Given I have launched the app
    # ❷ 向标签为sampleText的文本域中输入HelloWorld
    When I use the native keyboard to enter \
    "HelloWorld" into the "sampleText" textfield
    # ❸ 点击submit按钮
    And I touch the "submit" button
    # ❹ 确认显示了Hello World
    Then I should see "HelloWorld"

编写 Step 文件

与上面的 Feature 文件对应的 Step 文件如下所示。

定义步骤
# ❶ 如果view 组件存在的话
# 确认应用是否已经启动
Given /^I have launched app$/ do
  element_exists("view")
  sleep(STEP_PAUSE)
end

# ❷ 向标签为sampleText 的文本域中输入HelloWorld
When /^I use the native keyboard to enter \
"([^\"]*)" into the "([^\"]*)" textfield$/ do
  |text_to_type, field_name|
  touch("textfield marked:'#{field_name}'")
  keyboard_enter_text(text_to_type)
end

# ❸ 点击submit 按钮
And /^I touch the "([^\"]*)" button$/ do |name|
  touch("button marked:'#{name}'")
end

# ❹ 确认显示了HelloWorld
Then /^I should see "([^\"]*)"$/ do |expected_mark|
  element_exists( "view marked:'#{expected_mark}'" )
end

上面我们展示了从编写 Feature 文件到编写 Step 文件的过程。但实际上,在 Step 文件模板中已经存在与上文中测试步骤❷~❹相似的内容,甚至不需要我们去定义步骤。

在 Step 文件模板中提供了大多数情况下的测试步骤,没有必要再自己实现了。Calabash 提供的众多 Step 文件模板使测试实现效率得到了极大的提升。

确认测试结果

接着,让我们来确认测试执行的结果。在 Calabash 中使用 Cucumber 的功能,测试结果就会如下所示 10。这个结果也可以输出为 HTML。

10由于篇幅的限制省略了一部分。

Feature: Submit test

  Scenario: Submit a text
    Given I have launched the app
    When I use the native keyboard to enter \
    "HelloWorld" into the "sampleText" textfield
    And I touch the "submit" button
    Then I should see "HelloWorld"

1 scenario (1 passed)
4 steps (4 passed)

把键盘输入的值从 HelloWorld 变为 hoge 的话,则会出现下面这样的错误提示。

  Then I should see "HelloWorld"
    No element found with marked or text: \
    Hello World (Runtime Error)
    features/my_first.feature:20: in `Then I should \
    see "HelloWorld""

Failing Scenarios:
cucumber features/my_first.feature:14 # Scenario: \
Submit a text
1 scenario (1 failed)
4 steps (1 failed, 3 passed)

难以自动化的测试场景

使用了高级 UI 组件的应用比较容易执行 UI 的自动化测试。在本节中出现的示例应用和创建的测试场景中,从用户提交操作到确认结果,全部的测试步骤仅仅通过测试框架就可以实现和执行。例如如果仅要确认标签或者表格是否正常显示,只需要获取屏幕截图后与事先准备好的正确图像比较即可实现全自动测试。

但在有些情况下,即使使用了高级 UI 组件也很难实现自动化测试。

  • 确认动画等动态内容的显示和变化的测试

    • 点击表格视图(Table View)的单元格(Cell)后跳转页面的动作

    • 警告视图(Alert View)在显示和消失过程中页面显示上的变化

  • 确认声音数据播放结果的测试

即使使用了 UI 测试框架,针对上面的这些情况想要执行自动化测试难度还是很大。另外,由于 UI 的事件处理是在同一线程内执行的,所以包括 Calabash 在内的众多 UI 测试框架,都不能同时测试 1 个以上的 UI 操作。因此,诸如确认在触摸时页面显示发生的变化这样的用例,就必须根据需要由人工手动确认了。

另外,对于难以实现自动化的测试场景,也不是必须要全部手动测试,使用半自动测试这个概念来设计并实现测试,也可以在一定程度上提高效率、减少测试资源。

半自动测试

假设我们要确认在本节示例应用的测试步骤❸中,按下按钮时的动画是否会正确显示。想要自动完成确认非常困难,因此这次我们并不在测试框架内确认测试结果,而是获取连续的屏幕截图,或者是获取动画(如果可能的话)。虽然需要在自动测试之后人工确认屏幕截图或动画的结果,但还是省去了人工执行测试步骤的麻烦。

使用 Calabash 测试 游戏应用

本节所说的游戏应用是指使用 OpenGL 的 低级绘图 API,快速更新显示画面的应用。本节将要讲解针对这类游戏应用的自动化测试方法。

测试游戏应用时的注意点

在使用 Calabash 测试游戏应用时有一些需要注意的地方。那就是用 OpenGL 绘制的元素,在绘制后便不能指定了,也无法获取。因此,为了确认绘制结果,需要直接通过画面上的坐标指定目标区域。但是指定坐标属于模拟的方式,在终端设备或画面尺寸发生变化后就有可能取不到期待的图像数据了。出现诸如此类的问题时,就需要把赋予坐标的值由固定值变为通过计算得出的值,采用手动测试或半自动测试等方式去应对问题。

另外,也有可能在 Calabash 中执行并没有发生问题,但是测试框架却不能获取到使用 OpenGL 绘制的区域。想要制定这个问题的规避策略与应对策略非常困难,因此在最初就要对测试框架的选型十分注意并确认清楚。

实际测试示例应用

那么,就让我们开始使用实际的游戏应用来实施测试吧。这次要使用的是 Android 平台,并且要利用 calabash-android 中的 Step 文件模板。

设计

该示例应用的设计如下所述(图 2)。

图 2 示例游戏应用

  • 己方(飞机)通过在屏幕上触摸和拖曳进行移动

  • 绿色的敌人从屏幕的上方向下方移动

  • 在触摸屏幕的时候,飞机会向上方发出激光

  • 激光打中的敌人会被消灭掉

编写测试场景

要想确认动画的绘制结果是否正确,只获取 1 张屏幕截图显然不够。在可能的情况下应该将动画录制下来或是多次获取静态的屏幕截图。

针对该应用程序的示例测试场景定义如下。

等待应用启动(等待进度条消失)

以 A 为文件名前缀,保存 3 次屏幕截图

从坐 标(50,50)开 始,分 500 步拖曳到坐标(30,50)

以 B 为文件名,保存 1 次屏幕截图

从坐 标(30,50)开 始,分 500 步拖曳到坐标(70,50)

以 C 为文件名,保存 1 次屏幕截图

从坐 标(70,50)开 始,分 500 步拖曳到坐标(50,50)

以 D 为文件名,保存 1 次屏幕截图

编写 Feature 文件

与上面测试场景对应的 Feature 文件如下所示。

Feature: SampleGame
Scenario: Test shooting laser
    # ❶确认启动
    Then I wait for progress
    # ❷获取屏幕截图(3 次)
    Then I take 3 screenshot with name prefix "A"
    # ❸从(50, 50) 拖曳到 (30, 50)
    Then I drag from 50:50 to 30:50 \
    moving with 500 steps
    # ❹获取屏幕截图
    Then I take screenshot with filename "B"
    # ❺从(30, 50) 拖曳到 (70, 50)
    Then I drag from 30:50 to 70:50 moving with \
    500 steps
    # ❻获取屏幕截图
    Then I take screenshot with filename "C"
    # ❼从(70, 50) 拖曳到 (50, 50)
    Then I drag from 70:50 to 50:50 moving with \
    500 steps
    # ❽获取屏幕截图
    Then I take screenshot with filename "D"

编写 Step 文件

测试步骤的定义如下所示。由于利用了几个 Step 文件模板,所以这次我们只需要实现 ❷❹❻❽ 4 个步骤即可。

# 对应步骤❹❻❽
Then /^I take screenshot with filename \
"([^\"]*)"$/ do |filename|
  # 用既定的文件名获取屏幕截图
  screenshot({:name => filename})
end

# 对应步骤❷
Then /^I take ([\d\.]+) screenshot with name prefix \
"([^\"]*)"$/ do |num, name_prefix|
  num = num.to_i
  num < 1 ? 1 : num
  # 使用带序号的文件名保存屏幕截图
  count = 0
  while count < num do
    count += 1
    filename = name_prefix + "_" + count.to_s
    screenshot({:name => filename})
  end
end

与步骤❶❸❺❼对应的 calabash-android 的 Step 文件模板,其定义如下。

# 与步骤❶对应的模板
Then /^I wait for progress$/ do
  performAction('wait_for_no_progress_bars')
end

# 与步骤❸❺❼对应的模板
Then /^I drag from (\d+):(\d+) to (\d+):(\d+) \
moving with (\d+) steps$/ do
  |fromX, fromY, toX, toY, steps|
  performAction('drag',fromX,toX,fromY,toY,steps)
end

确认测试结果

得到测试结果的屏幕截图如图 3 所示。

{%}

图 3 所有获取的屏幕截图

对于动态的屏幕显示来说,并不一定能够在期待的时机获取到屏幕的截图。如果执行一下本次的测试代码就会发现,并没有获取到发射激光时的屏幕截图。因为激光发射后的动作被记录了下来,所以还是可以在某种程度上预想到激光的发射,但是却没有激光被绘制出来的实证。

像这样,因为对于动态绘制的画面很难把握获取其截图的时机,所以每次执行测试的结果也可能会不稳定。

测试动态屏幕显示

针对这次的失败,要考虑如下的对应方式。

  • 获取更多的屏幕截图

  • 缩短获取屏幕截图的时间间隔

  • 编写长时间显示激光的测试场景并变更步骤的实现

  • 可能的话录制动画

根据应用或终端设备的能力、测试框架的功能或 API 的设计的不同,上述的应对方式有可能实现,也有可能无法实现,在这种不确定的情况下,也可以考虑改变身为测试对象的应用本身。

在 Calabash 中除了录制动画之外的其他应对方式都可以由标准功能实现。而对于动画录制,则可以通过导入外部工具来自行实现。

如果说这次失败的原因是屏幕的触摸(拖曳)时间太短的话,那么应对方法有两个,一个是通过修改测试代码来增加触摸(拖曳)的时间,另一个是通过修改应用来增加触摸时绘制激光的时间。

请注意,如果以修改应用的方式来应对的话,即使顺利地执行了测试,也无法证实将测试对象的应用复原后是否还能正确地绘制激光。

考虑到自动 UI 测试的应用及测试设计

结合前面讲解的内容,在导入自动 UI 测试的时候,我们应该事先考虑到下面几点。

  • 在应用中实现用于测试的调试功能
  • 在测试场景中总结出哪些部分使用了 OpenGL 绘制,哪些部分没有使用

前者可以作为本次这种失败的对策。例如,通过设置一个用于测试构建的标志,或变更调试时的绘制 FPS(Frame Per Second,每秒传输帧数)等,就可以使依赖于屏幕截图的测试能够更稳定地执行并顺利获取结果。不过,就像前面说到的,一定要注意某些只有在测试时才会出现的行为。

后者适用于那些最终还是放弃了实现自动测试或半自动测试念头的测试场景中,通过明确地区分出可以实现自动测试的场景和需要手动测试的场景,使得自动测试程序和测试人员能够有明确的分工。

本章小结

本章说明了智能手机应用程序自动化测试的独特之处以及存在的问题。请读者朋友们务必要自己动手尝试一下 UI 测试的自动化,因为只有这样做才能够更深一层地理解 UI 测试的特点及局限性。有了真正的实战经验,再结合本章中介绍的内容,相信各位可以设计或开发出效率更高的 UI 测试。

祝测试愉快!

目录

  • 编委会
  • 分栏目录
  • 第 4 回 众多亮点的游戏设计世界
  • 特辑 1 智能手机测试最前沿
  • 第 1 章 智能手机测试的基本知识
  • 第 2 章 本机应用程序的 UI 自动化测试
  • 第 3 章 浏览器自动化测试
  • 第 4 章 JavaScript 自动化测试
  • 第 5 章 服务器端自动化测试
  • 第 6 章 自动构建与发布应用程序
  • 特辑 2 Amazon Web Services 最新技巧
  • 第 1 章 Amazon Web Services 的分层比较
  • 第 2 章 使用 EC2 和 VPC 构建系统
  • 第 3 章 有效利用 RDS 构建数据库
  • 第 4 章 利用 CloudFormation 实现自动化的系统环境构建
  • 特辑 3 Sass/Compass 实战
  • 第 1 章 Sass/Compass 简介
  • 第 2 章 构建开发环境
  • 第 3 章 Sass 的基本语法以及 Compass
  • 第 4 章 写出现代化的 CSS
  • 第 5 章 实践中的 Sass/Compass
  • 第 9 回 使用 Boxen 进行 Mac 的环境搭建和配置管理
  • 第 9 回 通过重构改善数据库设计
  • 第 10 回 移动设备环境下的调试技术用方法
  • 第 4 回 使用 Grunt 实现前端开发的自动化
  • 第 9 回 用程序性能分析来分析性能问题
  • 第 9 回 通过 Doctrine Annotations 实现的声明式编程
  • 第 23 回 Perl 应用的测试与高速 CI 环境的构建方法
  • 第 18 回 致力于改善响应速度的“特命”小组
  • 图灵访谈 CSS 只是进化的一部分