敏捷实践 (1) - 我们是如何自动化App验收标准

1. 问题背景

Scrum敏捷过程对交付质量有着严格的要求：零缺陷的增量发布。

要做到这一点意味着每个迭代发布都必须对 AC (Acceptance Criteria - 验收标准) 进行全回归，随着迭代中增量交付的增加，全回归的工作量与所需的时间也随之增加。

我们在做APP开发过程中，app开发人员 告诉我这app自动化测试搞不了，测试人员 也说，不好搞，很麻烦，而且还得靠录屏，blablabla.......

结果测试工作往往只能依赖人手进行测试，AC要靠人手来全回归测试，就会发生这样一种情景：

通常一个迭代的周期为两周10个工作日。

• 迭代1， 计划完成5个功能，相应的AC也就不多，如果1天就能全部回归，那么开发有9天时间来实现功能。
• 迭代2， 计划完成4个功能，相应的AC加上迭代1的AC，需要2天才能全部回归，那么开发有8天的时间来实现功能。
• 迭代3，计划完成3个功能，相应的AC加上两个迭代的AC，可能需要3天才能全部回归，那么开发有7天的时间来实现功能。
• ...

每次迭代AC全回归的所需的时间在不断增加，而能用于开发的时间不断在受到挤压而减少，能交付的功能也就不断在减少。

• 要质量就没速度，如此还能敏捷的起来吗？
• 不少团队(包括我们)采用了牺牲交付质量(仅部分回归甚至无回归)来确保开发进度，这样做既不符合敏捷过程的价值观，实际上也没有达到交付目标。
• 还有一个土豪的做法，就是增配测试。

我们一直在探索这个问题的解决方案，既想确保增量发布的速度，又想拥有交付质量。只能想办法把AC自动化起来，全回归就不需要占用太多人手，而且还能随时进行，所需要的时间也大大缩短。

---

2. 解决方案

在2017年1月份的ScrumMaster培训课中，聊起App自动化测试有什么工具，便有小伙伴提了一下Appium。回来后便查资料研究，发现有两个非常不错的自动化工具，一个就是Appium，另一个是阿里系的Macaca。这里不得不说，Macaca做的很不错，javascript写测试也相对容易上手。

然而，做了对比后，我决定还是选用Appium。原因很简单，Appium支持Ruby和Cucumber，我们的后端正好是用RubyOnRails写的，后端开发人员已经在写后端过程中积累了许多编写自动化测试用例的经验。正好也可以来写app的自动化测试。

---

2.1 环境准备

以下内容的运行环境为 MacOS 10.12 + Ruby 2.3.3 + NodeJS 7.x。
至于如何安装 Ruby 和 NodeJS，这个应当为基本技能，请自行搞定。

请不要问我如何在Windows上去搭建环境的有关问题，我只会建议要么白苹果，要么黑苹果，要么Ubuntu (不支持iOS)。要么走您。

由于npmjs.org rubygems.org都在国外，访问速度慢且不稳定，建议先搭好梯子，或者改用国内的源。

---

2.1.1 Appium 1.6.3 安装

npm -g appium
npm -g appium-doctor
# ios还需要安装两个工具 ios-deploy 用于安装app到真机；Carthage 用于安装app到模拟器
brew install carthage
brew install ios-deploy
# brew 是个什么鬼，如何安装的？没什么技术含量，请自行baidu

# 完成后可以运行appium-doctor诊断一下环境是否正常
# 如果没有android需求的，可以不用管 JAVA_HOME 与 android adb 等错误
appium-doctor

一切正常会得到类似这个信息

appium-doctor-screenshot.png

---

2.1.2 安装 Appium 的 Ruby 驱动，和appium ruby console

gem install appium_lib
gem install appium_console

至此，环境准备工作已经完成。

---

2.2 编写自动化测试用例

测试用例采用Cucumber方式编写，Feature 对应 用户故事，Scenario 对应 AC。
一个Feature包含多个Scenarios。
一个用户故事有多个 AC验收标准。

至于Cucumber, 有空我会再写一个文章。目前请先自行baidu之。

---

2.2.1 创建目录

mkdir app_test
cd app_test
# 创建测试用例目录
mkdir features 
# 创建测试用例步骤目录
mkdir features/steps
# 创建支持目录
mkdir features/support

---

2.2.2 准备Ruby Cucumber的Gemfile

$ cat Gemfile

source 'https://gems.ruby-china.org'

gem 'appium_lib',         '~> 9.3.0'
gem 'rest-client',        '~> 1.6.7'
gem 'rspec',              '~> 2.14.1'
gem 'cucumber',           '~> 1.3.15'
gem 'rspec-expectations', '~> 2.14.5'
gem 'spec',               '~> 5.3.4'
gem 'sauce_whisk',        '~> 0.0.13'
gem 'test-unit',          '~> 2.5.5' # required for bundle exec ruby xunit_android.rb

安装gem包

bundle install

---

2.2.3 cucumber env

$ cat features/support/env.rb

# This file provides setup and common functionality across all features.  It's
# included first before every test run, and the methods provided here can be 
# used in any of the step definitions used in a test.  This is a great place to
# put shared data like the location of your app, the capabilities you want to
# test with, and the setup of selenium.

require 'rspec/expectations'
require 'appium_lib'
require 'cucumber/ast'
require 'sauce_whisk'

# Create a custom World class so we don't pollute `Object` with Appium methods
class AppiumWorld
end

# Load the desired configuration from appium.txt, create a driver then
# Add the methods to the world
caps = Appium.load_appium_txt file: File.expand_path('./', __FILE__), verbose: true

Appium::Driver.new(caps)
Appium.promote_appium_methods AppiumWorld

World do
  AppiumWorld.new
end

# 结束时，推出驱动
at_exit { $driver.driver_quit }

# 在运行标有@reset_driver的Scenario前重启驱动
Before("@reset_driver") do
  $driver.restart
end

---

2.2.4 appium配置文件 appium.txt

关于appium.txt配置说明可以参考文档 appium-server-capabilities

$ cat features/support/appium.txt

[caps]
platformName = "ios"
deviceName = "iPhone 6s"
platformVersion = "10.2"
app = '../ios/build/Build/Products/Debug-iphonesimulator/PuKe.app'
automationName = 'XCUITest'
language = 'zh'
locale = 'zh_CN'

[appium_lib]
sauce_username = false
sauce_access_key = false

---

2.3 编写测试用例

每一用户故事的测试用例编写为一个feature。

---

2.3.1 编写邮箱登陆用户故事的AC

邮箱登陆用户故事只是登陆故事中的其中一个, 故事ID US004

$cat features/US004_login_by_email.feature

Feature: US_004 邮箱登录
  为了正常使用需要登录身份的功能
  作为一个已经用邮箱注册过的用户
  我想要用邮箱和密码登录系统

  @reset_driver
  Scenario: AC_US004_02 登录错误: 正确邮箱+错误密码登录
    Given 我已经用邮箱 test_user@mytest.com 与密码 test123 注册过账号
    When 我在 "主页面" 点击 "登录/注册" 进入 "登录页面"
    And 我在 "邮箱或手机" 输入 "test_user@mytest.com"
    And 我在 "密码" 输入 "b123456"
    And 我按下按钮 "登录"
    Then 我应当看到浮动提示 "用户密码不匹配"

  Scenario: AC_US004_03 登录错误: 没有输入用户名和密码
    Given 我已经用邮箱 test_user@mytest.com 与密码 test123 注册过账号
    And 我在 "邮箱或手机" 输入 ""
    When 我在 "密码" 输入 ""
    And 我按下按钮 "登录"
    Then 我应当看到浮动提示 "请填写完整"

  Scenario: AC_US004_04 登录错误: 输入用户名没有输入密码
    Given 我已经用邮箱 test_user@mytest.com 与密码 test123 注册过账号
    And 我在 "邮箱或手机" 输入 "test_user@mytest.com"
    And 我在 "密码" 输入 ""
    When 我按下按钮 "登录"
    Then 我应当看到浮动提示 "请填写完整"

  Scenario: AC_US004_01 正常邮箱+密码登录
    Given 我已经用邮箱 test_user@mytest.com 与密码 test123 注册过账号
    When 我在 "邮箱或手机" 输入 "test_user@mytest.com"
    And 我在 "密码" 输入 "test123"
    And 我按下按钮 "登录"
    Then 我应当到达 "主页面"
    And 等待 2 秒后退出

---

2.3.2 为feature编写相应的steps

Scenario 中的每个 Given When Then And 都在steps.rb 中有对应的定义。

$ cat features/step_definitions/steps.rb

# These are the 'step definitions' which Cucumber uses to implement features.
#
# Each step starts with a regular expression matching the step you write in
# your feature description.  Any variables are parsed out and passed to the
# step block.
#
# The instructions in the step are then executed with those variables.
#
# In this example, we're using rspec's assertions to test that things are happening,
# but you can use any ruby code you want in the steps.
#
# The '$driver' object is the appium_lib driver, set up in the cucumber/support/env.rb
# file, which is a convenient place to put it as we're likely to use it often.
# This is a different use to most of the examples;  Cucumber steps are instances
# of `Object`, and extending Object with Appium methods (through 
# `promote_appium_methods`) is a bad idea.
#
# For more on step definitions, check out the documentation at
# https://github.com/cucumber/cucumber/wiki/Step-Definitions
#
# For more on rspec assertions, check out
# https://www.relishapp.com/rspec/rspec-expectations/docs

Given(/^我已经用邮箱 (.*) 与密码 (.*) 注册过账号$/) do |email, password|
  # sleep(1)
  puts "DEBUG: email: #{email}"
  puts "DEBUG: password: #{password}"
end

When(/^我在 "主页面" 点击 "登录\/注册" 进入 "登录页面"$/) do
  # 等待主页面就绪, 主页面ID 为 home_page
  wait { id('home_page') }
  # 点击 主页面中的 '登录/注册' 按钮，按钮ID为 btn_to_login
  id('btn_to_login').click

  # 检查页面跳转到 登录页面， 登录页面ID为 page_login_account
  wait { id('page_login_account') }
end

When(/^我在 "(.*?)" 输入 "(.*?)"$/) do |input_field, input_value|
  input_id = case input_field
               when '邮箱或手机'
                 'input_username'
               when '密码'
                 'input_password'
               else
                 'unknown'
             end
  input_box = id(input_id)           # 定位指定的输入框
  input_box.clear                    # 清除原来的内容
  input_box.type "#{input_value}\n"  # 输入新内容并回车
end

And(/^我按下按钮 "登录"$/) do
  id('btn_login').click
end

Then(/^我应当看到浮动提示 "(.+)"$/) do |msg|
  msg.strip!
  puts "DEBUG: 期待 #{msg}"
  wait { find(msg) }
end

Then(/^我应当到达 "主页面"$/) do
  wait { id('home_page') }
end

And(/^等待 (\d+) 秒后.*/) do |seconds|
  sleep(seconds.to_i)
end

---

3. 运行测试用例

3.1 运行 Appium

运行测试用例前必须先启动appium,
新打开一个命令行窗口
$ appium

run_appium.png

---

3.2 运行测试用例

在 test_app 目录中

$ cucumber features/US004_login_by_email.feature

run_cucumber_feature.png

---

3.3 观看测试用例的运行录屏

http://v.youku.com/v_show/id_XMjUyMTkwODUzMg==.html

---

3.4 示例代码参考

https://github.com/appium/sample-code/

---

4. 总结

抛开复杂的appium、cucumber steps，发现没，测试用例是不是很容易理解？

  Scenario: AC_US004_01 正常邮箱+密码登录
    Given 我已经用邮箱 test_user@mytest.com 与密码 test123 注册过账号
    When 我在 "邮箱或手机" 输入 "test_user@mytest.com"
    And 我在 "密码" 输入 "test123"
    And 我按下按钮 "登录"
    Then 我应当到达 "主页面"
    And 等待 2 秒后退出

像上面的AC，就算是非技术人员也能分分钟写出来，我们的产品经理、UI设计师都在参与编写AC，这就是我们选择cucumber ruby的根本原因。

本来打算一篇写完的，写着写着，发现要写的内容太多了，决定还是写成一个系列：

• 首先、用Appium来测试，也存在一些坑要填。
• 上面的feature和steps，为了演示好理解，做了相当的简化。实际上，我们的steps经过一些重构，变得很通用灵活，后续放出来。
• Appium的配置与基本指令
• 辅助神器 Appium Ruby Console (ARC) 的使用
• 如何用Cucumber编写自动化测试
• React-Native类型的APP自动化有哪些坑需要绕过

有空的时候再接着写 （二）、（三）。。。。。。