測試自動化的Programming Paradigms
Programming Paradigms in Test Automation
http://blogs.msdn.com/imtesty/archive/2009/05/14/programming-paradigms-in-test-automation.aspx
May 14, 2009
Published in I.M.Testy
不管大多數人的想法是什麼, 軟體測試人員對開發有效測試自動化的需求, 已經是日漸增加了. 但是由於每個人熟悉的方法不同, 所以他們可能會用他們最熟悉的方法, 去套用到各種類型的測試當中. 但是, 並非所有測試自動化的開發方式都相同, 他們有各自的優缺點.
雖然自動化測試個案的核心是程式碼, 但是用來開發測試自動化的programming paradigms, 和開發一般產品軟體的開發方式還是不太一樣. 用來開發測試自動化的programming paradigms, 有以下幾種:
Record and playback automation
Keyword or action-word driven automation
Scripted automation
Procedural automation
Model based automation
1. Record and playback automation
這種paradigm簡單說就是藉由紀錄一連串滑鼠和鍵盤的操作, 將他們轉化成一些專屬的script anguage, 以用來之後執行, 再執行.
這方法通常有一些限制, 並且它極度容易不再合乎使用, 需要重新錄製操作流程, 以讓script能再被正確的執行.
雖然有許多record/playback paradigm的工具, 允許測試開發人員去修改這些script, 以擴充成你想要的, 甚至只是簡單加上一些邏輯的控制在裡面(像是Yes/No等簡單的邏輯控制). 但是, 我想很多人認為 record/playback paradigm 在某些有限的狀況下, 只有比受過訓練的猴子強一點.
2. Keyword or action-word driven automation
Keyword 或 action-words 是一種簡單的script, 用表格形式來描述一連串受測程式的運作行為.
當然, keyword driven automtion的關鍵, 是依賴底層的架構, 如何來解譯(interpret)和執行(execute) keyword. 所以keyword drive automation架構漂亮的地方, 在於它隱藏了keyword被實際實作的細節, 類似像record and playback方法一樣, 可以讓需求分析人員或是領域專家, 可以在不知道內部細節狀況下, 去自動化某些測試.
我認為keyword driven testing的好處只侷限於某些範圍(特別對於某些公司依賴需求分析人員或是領域專家去做測試), 但實際上來說, 這些人並不是在做測試自動化, 他們只是單純地把資料填進這些表格, 然後餵給工具去執行這些規定好的流程.
測試人員唯一做的事情, 就是如何正確的使用這些keyword, 讓事情可以從步驟A循序執行到步驟Z, 除了這樣以外, 這些keyword的表格並沒有再發揮更大的效用.
3. Scripted automation (imperative programming)
Keyword和scrpted的差別在於, scripted是讓測試人員真的用程式語言在開發測試自動化; 而不是用一些abstract出來的keywords, 填寫一些要做的事情.
然而, 類似keyword的地方, scripted automation使用基本的控制流程敘述, 來操控受測軟體去執行一些是先定義好的動作. 以下是一個例子:
1: def test_b_googlenews
2:
3: #-------------------------------------------------------------------------
4: # Test to demonstrate WATIR select from drop-down box functionality
5: #
6:
7: #variables
8: test_site = 'http://news.google.com'
9:
10: puts '## Beginning of test: google news use drop-down box'
11: puts ' '
12:
13: puts 'Step 1: go to the google news site: news.google.com'
14: $browser.goto(test_site)
15: puts ' Action: entered ' + test_site + ' in the address bar.'
16:
17: puts 'Step 2: Select Canada from the Top Stories drop-down list'
18: $browser.select_list( :index , 1).select("Canada English")
19: puts ' Action: selected Canada from the drop-down list.'
20:
21: puts 'Step 3: click the "Go" button'
22: $browser.button(:caption, "Go").click
23: puts ' Action: clicked the Go button.'
24:
25: puts 'Expected Result: '
26: puts ' - The Google News Canada site should be displayed'
27:
28: puts 'Actual Result: Check that "Canada" appears on the page by using an assertion'
29: assert($browser.text.include?("Canada") )
30:
31: puts ' '
32: puts '## End of test: google news selection'
33:
34: end # end of test_googlenews
35:
36:
37: def test_c_googleradio
38:
Scripted automation大部分的例子, 都是一些事先規劃編寫好的一連串步驟, 僅足夠讓他們可以把想要做的事情給做完. 也就是說他們會用一些寫死的參數, 步驟間沒有做錯誤處理, 和單純的測試流程. 並不會讓系統有太多"彈性", 或是"智慧"在裡面.
Scripted automation最有用的地方, 是將"電腦輔助測試"(computer assisted testing)中, 某些特定工作給自動化
但是, scripted automation通常限定的太死, 所以在測試執行過程中, 它不能有太多錯誤發生的可能, 否則他將會無法執行下去
4. Procedural automation (procedural programming)
在procedural automation狀況下, 測試人員也撰寫一連串的程式, 來開發測試自動化.
但是和scripted automation差別的地方, 在執行測試個案的過程中, procedural automation提供較好的控制流程, 允許你設計較複雜的狀況, 並利用模組化(modularity)改進程式的再用性和減低維護上的花費. 它可以做事先定義好的測試(deterministic), 或是一些沒有固定, 探索式的測試(heuristic).
1: // Procedural programming example
2:
3: static void Main(string[] args)
4: {
5: string logResult = string.Empty;
6:
7: // Path to the data file passed as a string argument to the test case
8: string pictTestData = args[0];
9:
10: //Stopwatch to measure test case duration
11: Stopwatch sw = new Stopwatch();
12: sw.Start();
13:
14: // Launch the AUT
15: AutomationElement desktop = AutomationElement.RootElement;
16: AutomationElement myAutForm = null;
17: Process myProc = new Process();
18: myProc.StartInfo.FileName = myConstantAutFileName;
19: if (myProc.Start())
20: {
21: // Polling loop to find AUT window by window property
22: int pollCount = 0;
23: do
24: {
25: myAutForm = desktop.FindFirst(TreeScope.Children,
26: new PropertyCondition(AutomationElement.AutomationIdProperty,
27: myConstantAUTPropertyID));
28: pollCount++;
29: System.Threading.Thread.Sleep(100);
30: }
31: while (myAutForm == null && pollCount < 50);
32:
33: if (myAutForm == null)
34: {
35: throw new Exception("Failed to find dialog");
36: }
37:
38: // Get UI element collection here...
39:
40: // Call method to read in test data
41: string[] testData = ReadTabDelimitedFile(pictTestData);
42:
43: // iterate through each set of test data (data-driven test example)
44: foreach (string test in testData)
45: {
46: // Call method to execute each set of test data and assign the return
47: // value to the logResult variable; Oracle is separate method called
48: // from the test method
49: LogResultMethod(ExecuteCombinatorialTestMethod(test));
50: }
51:
52: // close AUT and clean-up
53: TimeSpan ts1 = sw.Elapsed;
54: // log test case duration...
55:
56: // Deal with situation if AUT failed to launch
57: }
Procedural automation可以用來測試任何東西, 像是API測試, 或是使用者介面測試. 範圍從功能(functional)測試到非功能(non-functional)測試(像是stress, performance, secutiry等等)都可以試任.
利用程式語言來撰寫, 而不用abstract出來keyword, 可以幫助團隊中其他成員, 去檢查你真正測試的方法為何, 可以增加測試個案被review的能力
5. Model based automation
相對而言, Model based automation是一個新的自動化paradigm, 它的複雜程度是遠超過這篇文章所能描述
基本上, model based autoation要先對受測系統, 建立一個state machines來model系統的行為. 然後利用一些圖學理論產生一些執行路徑, 以橫跨其中的states, 這些執行路徑可用來測試受測系統.
在某些種況下, model based automation是類似exploratory testing, 因為這個測試不是事先定義或規劃好的, 而且case的內容非常複雜, 不容易被描述的很清楚. 此外, 它可以藉由橫跨到一些非預期的state, 來測試例外處理的狀況.
個人來說, 我認為model based automation有很大的潛力, 但是目前業界才剛開始使用它, 並且還對它有很大的誤解. 這個automation paradigm要求比較高深的技術來設計測試自動化, 像是抽象化state machine的能力, 和將此state machine轉化成程式的能力
若要進一步知道更多有關model based 自動化的資訊, 你可以到這裡去看看: http://research.microsoft.com/en-us/projects/specexplorer.
所以哪一種方法最好?
根據我個人的意見, record/playback, keyword, 和 scripted的方式, 在某些環境下會有些限制. 但是, 一個堅固的自動化測試, 要能被執行在各種環境, 各種語言, 或是分散橫
跨各個環境中, 然後不用去修改它們以配合這些變型. 這是需要用procedural automation or model based automation, 來做一些好的設計, 以讓這件事比較容易達成.
留言列表
