UI Automate Test on Mobile— Robot Framework

4 min readJun 11, 2017

บทความนี้ถูกเขียนเพื่อสรุปสิ่งที่ศึกษามาเกี่ยวกับการเริ่มต้นทำ UI Automate Test ด้วย Robot Framework จากโจทย์ที่ว่า “อยากจะทำ Automate Test บน iOS และ Andriod device ทำไงอ่ะ ?”

อันดับแรก ศึกษานิยามเบื้องต้นของสิ่งที่ต้องการก่อน

Test-Automation Framework คืออะไร ?

Test-Automation Framework อย่างง่ายนั้นประกอบไปด้วยส่วนที่ execute test ได้ สามารถสร้าง report ผลการทดสอบได้ และมี interface สำหรับ plug-in test functionality ที่เฉพาะเจาะจงเข้าไป

ลองเลือก Test-Automation Framework มาซักอัน — ในที่นี้เราเลือก Robot Framework มาศึกษาก่อน ขออธิบายองค์ประกอบที่เกี่ยวข้องดังนี้

http://blog.codecentric.de/files/2012/03/Overview_3.png

Standard Test Libraries — จะถูกติดตั้งมาด้วยในขณะที่ติดตั้ง Robot Framework นอกจากนี้ ยังมี External Test Libraries ให้เราติดตั้งเพิ่มเติมอีกด้วย โดยที่เราสามารถนำ keywords จาก libraries ต่างๆมาใช้ในการสร้าง keywords ของเราเองได้

Keyword-Driven Testing — keywords ในที่นี้หมายถึง function ที่เราใช้ในการเทสซึ่งมีทั้งส่วนที่เราเขียนขึ้นมาเอง และ predefined keywords ที่อยู่ใน Test Libraries

นอกจาก Core Functionality และ พวก Test Libraries ต่างๆแล้ว Robot Framework ยังมี graphic user interface ให้เราได้ใช้ในการเขียนเทสกัน — RIDE (Robot Integrated Development Environment)

Resource File เป็นแหล่งรวมของ (Higher-level) keywords ที่เราสร้างเอง

พอรู้ถึงองค์ประกอบเบื้องต้นไปแล้ว ต่อไปเราจะมาลงลึกอีกนิดเกี่ยวกับการเขียน Automate Test ด้วย Robot Framework

Robot Framework Quick Start

Robot Framework คือ generic test automation framework โดยมักใช้สำหรับ Acceptance Test โดยใช้วิธีการที่เรียกว่า Keyword-Driven Testing Approach เราสามารถใช้ Test Libraries ที่ถูกสร้างขึ้นมาด้วยภาษา Python หรือ Java ในการเพิ่มความสามารถของการเทสได้ และสามารถเขียน higher-level keywords ขึ้นมาเองจาก keywords ที่มีอยู่แล้วได้ ตัว Robot Framework สามารถรันได้โดยไม่ขึ้นกับระบบปฏิบัติการ อาทิเช่น สามารถรันบน Mac หรือ Window ก็ได้

แล้วภาษาที่ใช้เขียน Test Functionality หล่ะ ?

ตัว Robot Framework และ Core Libraries ของมันถูกพัฒนาด้วย Python จึงเป็นไปได้ที่จะเขียน keywords ด้วย Python แล้วภาษาอื่นหล่ะ ? ณ จุด นี้ Jython จึงเข้ามามีบทบาท Jyhton ทำให้ Python code สามารถรันใน Java Virtual Machine ได้ จึงสามารถเขียน Test Libraries ด้วย Java ได้ หรือเขียนด้วย programming language ใดๆที่สามารถคอมไพล์ออกมาเป็น Java Byte Code ก็ได้

Test cases

รูปแบบของการเขียน Test Case ใน Robot Framework มีดังนี้

Keyword-driven approach
Behavior-driven approach (BDD): Higher-level tests
Data-driven approach

Keyword

แบ่งออกเป็น 2 ประเภท Library Keyword และ User Keyword

1. Library Keyword

Standard — ใช้ได้เลย ไม่ต้องติดตั้งเพิ่ม
External libraries — ต้องติดตั้งเพิ่มเติม
Custom libraries — เป็น libraries ที่ทำขึ้นมาเอง

การใช้งาน

import เข้ามาในส่วนของ *** Settings ***โดยใช้ Library keyword

*** Settings ***
Library     AppiumLibrary

2. User Keyword

คือการที่เราเขียน keyword นั้นๆขึ้นมาเองภายใต้ *** Keyword ***

Variable

Variable ถูกประกาศภายใต้ *** Variables *** ดังตัวอย่างข้างล่าง หรือจะส่งผ่านจาก command line ในขณะที่รันเทสก็ได้

*** Variables ***
${USERNAME}    testuser

นอกจากนี้ก็ยังมี ฺBuiltin Variable ให้เราได้เรียกใช้กัน อาทิเช่น ${SUITE NAME} ${TEST NAME}

Setups and Teardowns

เราสามารถกำหนดสิ่งที่เราอยากจะทำก่อน/หลัง test suites หรือ test cases ได้โดยประกาศ Suite Setup, Suite Teardown, Test Setup, Test Teardown ในส่วนของ *** Settings *** ดังเช่น

*** Settings ***
Suite Setup       Call Some Keyword  #execute before the suite
Suite Teardown    Call Some Keyword  #execute after the suite
Test Setup        Call Some Keyword  #execute before each test case
Test Teardown     Call Some Keyword  #execute after each test case

เราใช้ตัว ‘#’ สำหรับ comment โค้ด (โค้ดในที่นี้หมายถึง test case ที่เราเขียนนั่นเอง) การ comment โค้ดส่วนใดออกไป หมายถึง การที่เราไม่ต้องการให้ตีความส่วนนั้นๆ โดยปกติเรา comment โค้ดเมื่อเราไม่ต้องการให้ code ส่วนนั้นทำงาน หรือใช้ comment เพื่อเป็นการ document สิ่งที่เกี่ยวกับ code

นอกจากนี้เราสามารถใช้ Run Keywords ในการเรียกใช้ keywords ที่มีอยู่แล้วได้ดังตัวอย่างด้านล่าง สังเกตได้ว่าวิธีนี้ไม่ reusable เลย มันเหมาะในกรณีที่ กลุ่ม ของ keywords เหล่านี้ถูกทำแค่ครั้งเดียว ไม่ได้ถูกใช้ที่อื่นอีก

*** Settings ***
Suite Setup      Run Keywords     Log    This is SUITE SETUP
...              AND    Open Application
...              AND    Close Alert

สำหรับกรณีที่ต้องการให้ Test Setup และ/หรือ Test Teardown ในบาง test case มันต่างออกไปจากที่กำหนดไว้ใน *** Settings *** เราสามารถกำหนด custom Test Setup/Test Teardown ได้ในแต่ละ test case เอง ดังนี้

*** Test Cases ***
Test Open Tutorial
    [Setup]    Custom Test Setup
    Log     this test case show how to customize Test Setup

การเขียน Test ที่ดี ควรคำนึงถึงอะไรบ้าง

Naming

Test suites names

สร้างโดยอัตโนมัติจากชื่อของไฟล์หรือชื่อของไดเรกทอรี
ถ้าชื่อเป็นตัว lower case หมด word จะถูก capitalized เช่น

login_invalid.robot ==> Login Invalid

Test names

ถ้า suite ใดๆมีเทสที่คล้ายกันหลายๆเทส และชื่อเทสมีความหมายที่ชัดเจนอยู่แล้ว เราสามารถตั้งชื่อเทสนั้นให้สั้นลงใด้ เช่น

Login With Invalid Password Should Fail ==> Invalid Password
Login With Empty Password Should Fail ==> Empty Password

Keyword names

อธิบายว่าทำอะไร ไม่ใช่ทำอย่างไร เช่น

Good: Login With Valid Credential
Bad: Input Valid Username And Valid Password And Click Login Button

ไม่มีการกำหนดตายตัวว่า keyword ควรจะเป็น title cased หรือ capitalize first letter โดยส่วนใหญ่แล้ว เคสแรกมักใช้กับ keyword สั้นๆ เช่น Input Text ส่วนเคสหลังมักใช้กับ keyword ที่มีลักษณะคล้ายประโยค เช่น User registers with email

Variable names

local variable ให้ใช้ lower case นอกนั้นให้ใช้เป็น Upper case
word separator จะใช้เป็น ‘_’ (underscore) หรือ ‘ ’ (space) ก็ได้

จิปาถะ

Path ของ Setting Configuration ของ RIDE

~/.robotframework/ride

Testing Pyramid

ขอสอดแทรกทฤษฎีเกี่ยวกับ Test Automation Strategy ซักนิด เพื่อให้เข้าใจภาพที่ใหญ่ขึ้นของการทำ Automation Test ว่ามันไม่ใช่งานที่จะต้องทำบน end product โดย QA เท่านั้น แต่มันเป็นงานที่ต้องถูกทำขณะเขียนโค้ดด้วย ที่อธิบายไปด้านบนทั้งหมดมันเป็นเพียงส่วนที่เกี่ยวข้องกับ UI Automation Test เท่านั้น

Test Automation Strategy ที่มีประสิทธิ์ภาพถูกแบ่งออกเป็น 3 ชั้นดังรูปข้างต้น Google แนะนำว่าควรแบ่งสัดส่วนเป็น 70/20/10 (70% Unit Test, 20% Integration Test, 10% End-to-End Test) สัดส่วนอาจจะเปลี่ยนแปลงได้แต่ยังต้องคงรูปปิรามิดไว้เช่นเดิม

จะเห็นได้ว่า Unit Test เป็นรากฐานเลยของ Test Automation Strategy และมันครอบคลุมพื้นที่ที่มากที่สุดของพีระมิด เพราะมันให้ข้อมูลที่ชัดเจนกับ developer เช่น มี bug ที่ line 46 อีกทั้ง Unit Test ถูกเขียนขึ้นมาจากภาษาเดียวกับที่โปรแกรมถูกเขียนขึ้น จึงเป็นการง่ายต่อ developer ในการเขียนเทส

ที่ยอดพีระมิดเป็นส่วนที่เล็กที่สุด นั้นก็คือ UI Test ที่ และการที่ชั้นนี้ครอบคลุมพื้นที่เป็นส่วนน้อยก็เพราะ

Time Consuming — การทำเทสผ่าน UI นั้นช้า
การเขียน/แก้ไข UI Test ที่เป็นประโยชน์ และปรับเปลี่ยนให้เข้ากับ UI เสมอมันย่อมใช้เวลามากพอควร
บางครั้งมีค่าใช้จ่าย เช่น สำหรับ Test Automation Software
Brittle — การปรับเปลี่ยนเล็กๆน้อยๆอาจ break Test Case ได้ ทำให้ลำบากที่จะต้องแก้ให้ test นั้นถูกต้องเสมอๆทุกๆครั้งที่มีการเปลี่ยนแปลง UI

จาก Test Pyramid เราควรเน้น Automate Test ผ่าน Unit Test มากกว่าที่จะทำ GUI based testing ทำไมหล่ะ ? คำตอบก็คือ ถ้าเจอ Bug จาก high-level test มันเป็นไปได้เหมือนกันที่เราอาจจะขาด Unit Test บางอย่างไป หรือ Unit Test ที่มีบางเคสอาจผิดก็เป็นไป ดังนั้นก่อนจะ fix bug ที่ถูกพบจาก high-level test ก็ควรจะนำ bug นั้นไปดูที่ level ของ Unit Test ก่อน

ถึงตรงนี้ คงเห็นกันแล้วว่า UI Automation Test มันมีโครงสร้างเบื้องต้นอย่างไร ถ้าเราเลือก Robot Framework มาใช้ เราจะเขียนเทสกันด้วยรูปแบบไหน และจริงๆแล้ว UI Automation Test มันเป็นองค์ประกอบหนึ่งของ Test Pyramid นะ ยังมีเพื่อนๆมันอีกสองส่วนให้เราได้ศึกษากัน ขอจบบทความเกี่ยวกับการทำ UI Automation Test บน mobile device แต่เพียงเท่านี้ หวังหว่าบทความนี้จะช่วยให้ผู้อ่านได้ทำความรู้จัก และเข้าใกล้ UI Automation Test กันบ้างไม่มากก็น้อย ^___^

Reference Link/Book

http://robotframework.org/
https://github.com/robotframework/QuickStartGuide/blob/master/QuickStart.rst
https://github.com/robotframework/HowToWriteGoodTestCases/blob/master/HowToWriteGoodTestCases.rst
https://github.com/robotframework/robotframework
https://bitbucket.org/robotframework/robotdemo
https://blog.codecentric.de/en/2012/03/robot-framework-tutorial-overview/
https://martinfowler.com/bliki/TestPyramid.html
https://testing.googleblog.com/2015/04/just-say-no-to-more-end-to-end-tests.html
Book: Succeeding with Agile