SUPPORTING TEST-DRIVEN DEVELOPMENT OF GRAPHICAL USER INTERFACES USING AGILEINTERACTION DESIGN

報告人 : 歐陽玉慧

Third International Conference on Software Testing, Verification, and Validation Workshops2010 IEEE ICSTW.

Theodore D. Hellmann, Ali Hosseini-Khayat, Frank Maurer

2011/5/30

outline

Abstract I. INTRODUCTION II. PROBLEM III. RELATED WORK IV. OUR APPROACH V. LIMITATIONS VI. FUTURE WORK REFERENCES

Abstract

TDD of GUIs 目前的兩難 :1. TDD 需要發展中的 app 有一定的穩定度 , 來

避免 tests 去頻繁變動 , 但 GUIs 在開發過程中卻很有可能要常變 .

2. 建立 GUI tests 最簡單的方法就是用 capture-replay tool , 但必須 GUI 先存在才能使用 .

本文介紹一種新的 user interface TDD (UITDD) 方法 , 利用 CRT 由 low-fidelity prototypes 紀錄 test scripts. 可使 GUI tests 更好寫 且 不需要先有 GUI

I. INTRODUCTION

TDD 的好處與欠缺 好處 :

encourages communication between customers and developers,

increases programmer confidence, increases software quality, decreases bug density without decreasing productivity [1][2]

欠缺 : 大部分的 TDD 研究仍未解決 TDD of graphical user interfaces (GUIs), 兩個最大的挑戰 : GUIs 在開發過程中很有可能要常變 使得 tests 要經常修改 ( 很不

直覺 ) 建立 GUI tests 最簡單的方法 capture-replay tool (CRT), 必須

GUI 先存在才能定義 tests.

I. INTRODUCTION (cont’)

本文的作法與好處 作法 : 利用 CRT 結合 low-fidelity prototyping

tool1. 收集 details of user stories2. 用這些 stories 建立系統的 low-fidelity prototype.3. 進行 prototype 的 usability evaluations 找出且修復

UI flaws4. 重複 repeated 上述流程直到 prototype 夠 stable.5. 用最後的 prototype 加上預期的 GUI behavior 資訊 ,

CRT 就能記錄複雜的 acceptance tests. 6. 此 tests 就能被發展中的 GUI 去 run 確保符合 user 期

待 ( 在 prototype 上的定義 )

I. INTRODUCTION (cont’)

本文的作法與好處 好處 : 利用夠明確的 prototype 進行 agile

interaction design 能得到兩大好處1. 開發初期就能找出 usability concerns, 最後的 GUI

就比較不用常改2. 若 prototype 能加上一些自動化資訊 ( 用來識別與確認

widgets), 同時這些資訊實際實作中又可維護 , tests就能用 prototype 紀錄 且 在實際 GUI 上 replayed .

II. PROBLEM

TDD 核心優勢與應用在 GUI-based app 之屏障 核心優勢 :

tests 不用 code 存在就可先寫 , 之後就可以寫讓 tests pass 的 code.

要能重整既有的 code, 而不用擔心會破壞 tests. 兩大屏障讓 TDD 無法有效應用在 GUI-based

app: 重整或修改 GUIs 就會破壞其 tests (even 改變跟

semantic 無關 ) GUI tests 很難用人工撰寫 , 雖可用 CRT 簡化但 GUI

一定要先存在 , 這代表 UITDD 一定只能靠人工撰寫 .

II. PROBLEM (cont’)

GUI tests 之問題與可能的 solutions 雙重負擔 : (GUI 常變 , 其 test suite 就要重複維護 )

1. 維護費用會持續不斷 (substantial)2. 若開發者視錯誤為“ the test’s fault” 而非程式可能

的 bugs 就會更不願意改程式且不會認真看待 failing tests ( 這比上一個問題更嚴重 , 因為 TDD 之核心 benefits 就是 developer confidence)

Solutions Team 可試著減小 GUI 及其 test suite 必要的改變 現已有可自動修改或夠簡單的方法可修改 broken GUI

tests ( 他人作法 : Section III, 作者方法 : Section IV)

III. RELATED WORK

A. Capture-Replay Tools CRTs:運用紀錄 GUI的interactions並且存成 a sequence of actions可

在GUI上replayed (但根本的難題就是 widgets 無法被 test code 存取)1. 初版CRTs解法: 只用 keyboard input 及 screen position of mouse

clicks 來紀錄的 test script可簡單的replay這些動作, 但卻無法驗證正確的系統行為, 且依賴screen coordinates有很大的缺點(對GUI之non-semantic changes非常敏感,如重排 widgets 都會造成 test failures)

2. 次版CRTs作法: 用object maps(存夠多的widget資訊測試時就可作fuzzy match [5], [3])的 testing, 可使tests應變力更強, test時可存取widgets去測試其behavior, 但此法很難寫code(因為要正確定位widget所需的資訊量太大)

3. Keyword-based testing是最近發展的GUI testing技術, 利用給每個widgets設定unique keyword(而非儲存大量的widgets資訊),好處就是測試時只要找一個keyword 且與特定widget之interact(可視為一個透過CRTs寫test的簡單且健全的方法)

III. RELATED WORK

B. User Interface Test Driven Development 近年來已有發展出可支援 UITDD 的工具

提供 framework 支援 widgets identification 與interaction 更簡單且健全作法 , 簡化人工 GUI test ( 更健全的做法還有把測試存到 intermediate form 及用來測試 widgets 的 intermediate representation 以輔助 test maintenance [6].)

缺點 : 雖可減少 UITDD 的 effort, 但仍要用人工撰寫 code( 容易產

生錯誤 , 且有 agile team 證實此法要一直修改 tests, 用CRTs 重新紀錄 tests 都比修改原本的 tests 還要快 )

III. RELATED WORK

C. Support for Test Script Maintenance 支援 test maintenance 的 tool 也是最近的研究

主題 : Compiler-inspired approach[9]: 不需要人工互動就能建立

一個 legal 的 test steps sequence 自動取代 broken test 事件 TIGOR system[5]: 利用加入明確的 GUI test scripts type

資訊來簡化 manual maintenance REST[3]: 產生 App 程式內 widgets 與 test 內的使用之 關聯資

訊來建議 test script where and why 可能 fail Actionable Knowledge Models [10]: 把 tests 存在中間

model 中 , 可把導致 test failure 的根源紀錄在 single location而不用人工放在 individual test scripts.

IV. OUR APPROACH

A. Tools ActiveStory Enhanced (supports agile interaction

design) 讓 usability engineers 能建立 low-fidelity

prototypes. 這些 prototypes 是由一組有各式各樣 UI states 及

“ hot zones”( 涵蓋了引起 states 間轉換的特定範圍的 clear transparent buttons) 的 pictures 所構成

可很便宜的建構及調整 low-fidelity prototypes, 讓ActiveStory Enhanced 可以用很便宜且分散進行多人的可用性測試 (usability tested)

IV. OUR APPROACH(cont’)

A. Tools LEET ( 利用 Microsoft’s User Interface Automation Framework

(UIAF) 所發開發的 CRT [12])

此 Framework 可提供 keyword-based testing ( 此法基本 )

唯一可用來辨識 widget 的屬性就是利用其AutomationID, 所以就可能從 ActiveStory Enhanced prototype 來記錄 test 並且可 replay在 actual GUI 上 .

這可利用在每個 hot zone 附加一個 AutomationID 並確定 GUI 上相對的 widget 也會使用同一個 ID 來達成 .

IV. OUR APPROACH(cont’)

B. Process Process1. 建 User stories: 用 ActiveStory Enhanced 建 GUI

low-fidelity prototype

2. Usability evaluations: 進行此 prototypes 的可用性評估 , 可減少最後的 GUI 所需的改變 (low-fidelity prototypes 可快速建構且少成本 , 對 iterated agile usability evaluations 最為理想 )

3. 加入自動化資訊 : 把 2. 得到的 stable prototype 加上自動化資訊就可進行複雜的 verifications

4. 建 tests: 用 LEET 紀錄 prototype 上的互動為一組 acceptance tests

5. Run: 此 tests 就能在開發 GUI-based app 過程中執行 testing

IV. OUR APPROACH(cont’)

B. Process 好處 :

UITDD 沒有了附加限制 : 可用最簡單的工具 CRT 來建立tests, 代表不用人工撰寫 test code-- 用既有工具就可建UITDD

降低維護成本 : 因為實作前已經先做了 usability testing, 這個部分來來回回的設計工作可因為這項好處及 user 購買量的增加來得到補償

減少 broken tests: 雖有工具可輔助修正 broken tests, 但最佳的作法還是在 broken tests第一次發生時就減少之 ( 這可避免上述其他 UITDD 方法的遇到的問題 )

IV. OUR APPROACH(cont’)

C. Example UITDD 以 Windows 7 calculator 為例 , 設計考

量含 : keys representing numbers, keys representing operators, a display 放在最上面顯示輸入的數字或運算結果

此例目前就只先考慮 addition feature. In this story, the five button, plus button, nine

button, and equals button are clicked in that order, and we expect that the display should read “14” at the end.

IV. OUR APPROACH(cont’)

C. Example

1. 建 storyboard (Fig1): 此 test sequence 可在 ActiveStory Enhanced 上的 prototype 建構出的 storyboard 2. 建 test(Fig2): 用 LEET 紀錄此prototype 之 sequence of interactions 作為 test script

AutomationID 會設成“ Five”( 當實際的 GUI 也把實際的“ 5” 按鍵 設為一樣的 ID, test 就會找到並且按下它 ( 如prototype 所設計 ))

hot zone

在 UIAF, 用來顯示 text 的 widgets 會設Name 屬性對應該 text

IV. OUR APPROACH(cont’)

C. Example

3. 實作 GUI: 用 WPF 實作可將每個widget name 屬性設定的值視為自動 AutomationIDs.

4. Run test: 先修改 Fig2. 的 Start 動作指向實際的 GUI 結果如 Fig3.

( 因為還沒寫邏輯所以再跑 Fig2 第二行到最後test 會先失敗 , 讓 test 可找到並執行動作是因為 keyword-based 的測試 , 容許 widgets resized, moved, even 改成相似 types 都不會破壞 test script,)

5. 當 interface 被完成後 , 此測試仍可適當地運作 Fig4.

V. LIMITATIONS

Evaluation is upcoming ( 本法可用在 UITDD 上 , 但尚未證實其 practicality or usefulness) 短期 : 要求開發者進行簡單應用系統的不同功能的 UITDD, 提供

本法對於個人是否實用及對應用系統發展有多少幫助之相關資訊 長期 : 實際用在業界一段時間確認本法對開發團隊的實際可用性

未可證實之假設 : 對 GUI 之 prototype 重複進行 usability evaluations, 開

發過程中開發者對 GUI 要修改的量就會比較少 本法測試所用之 low-fidelity prototype 有其限

制 : 除了 buttons, hyperlinks 其他如 text boxes, draggable

items, gestures 還沒有工具支援 , 還是必須人工撰寫測試

VI. FUTURE WORK

完成 evaluation 後 , 就開始探索 mixed-fidelity UITDD ( 結合 low-fidelity prototypes 的手繪元件與實際的 widgets)

建立 prototype widgets 與 app實際功能的橋梁

漸進式的替換 low-fidelity prototype 成 functional widgets, GUI 就能由這些 prototype 漸進地開發 ( 此法可避免用 low-fidelity prototype 紀錄的 tests 但卻在不同GUI 上執行的 gap)

REFERENCES

[1] R Jeffries and G. Melnik, "Guest Editors' Introduction: TDD - The Art of Fearless Programming," IEEE Software, pp. 24-30, 2007.

[2] N. Nagappan, E. M. Maximilien, T. Bhat, and L. Williams, "Realizing Quality Improvement through Test Driven Development: Results and Experiences of Four Industrial Teams," in Empirical Software Engineering, 2008, pp. 289-302.

[3] M. Grechanik, Q. Xie, and F. Chen, "Maintaining and Evolving GUIDirected Test Scripts," in IEEE 31st International Conference on Software Engineering, 2009, pp. 408-418.

[4] A. Holmes and M. Kellogg, "Automating Functional Tests Using Selenium," in AGILE 2006, 2006, pp. 270-275.[5] C. Fu, M. Grechanik, and Q. Xie, "Inferring Types of References to GUI Objects in Test Scripts," in International

Conference on Software Testing, Verification, and Validation, 2009, pp. 1-10.[6] W. Chen, T. Tsai, and H. Chao, "Integration of Specification-Based and CR-Based Approaches for GUI Testing," in

19th International Conference on Advanced Information Networking and Applications,2005, pp. 967-972.[7] A. Ruiz and Y. W. Price, "GUI Testing Made Easy," in Testing: Academic and Industrial Conference - Practice and

Research Techniques, 2008, pp. 99-103.[8] A. Ruiz and Price Y. W., "Test-Driven GUI Development with TestNG and Abbot," in IEEE Software, 2007, pp. 51-

57.[9] A. M. Memon and M. L. Soffa, "Regression Testing of GUIs," in ACM SIGSOFT International Symposium on

Foundations of Software Engineering, 2003, pp. 118-127.[10] Z. Yin, C. Miao, Z. Shen, and Y. Miao, "Actionable Knowledge Model for GUI Regression Testing," in

IEEE/WIC/ACM International Conference on Intelligent Agent Technology, 2005, pp. 165-168.[11] Ali Hosseini-Khayat, Yaser Ghanam, Shelly Park, and Frank Maurer, "ActiveStory Enhanced: Low-Fidelity

Prototyping and Wizard of Oz Usability Tool," in Agile Processes in Software Engineering and Extreme Programming, 2009, pp. 257-258.

[12] Theodore D. Hellmann. (2010) LEET (LEET Enhances Exploratory Testing) - CodePlex. [Online]. http://leet.codeplex.com/