模板
教程
環境
性能
功能
管理
智能測試自動化——基于應用程序行為的模型驅動測試方法
通過建模來提高你的自動化測試的效率。
克服手動測試和靜態自動化測試的局限性 。
注意：你將要讀到的故事是虛構的――它很短小，但其寓意是真實的。
在產品周期中，有四位測試人員根據要求開始測試軟件。
? 測試員 1
立即開始手動測試，并發現一些細微的錯誤。開發團隊高興的修復了這些錯誤，然后提供一個新的軟件版本以供測試。測試的越多，發現的錯誤越多，修復的錯誤也就越多。
測試員1覺得很有成就感，也就會感到快樂――至少一段時間是這樣的。
經過幾輪這種發現、修復的循環，他開始由于一遍遍的手動重復運行實質上一樣的測試而感到乏味和反應遲鈍。當測試員1最終喪失積極性――同時也就意味著失去耐性――就會宣稱軟件可以發布了。
用戶發現它有太多的錯誤，于是購買了競爭者的產品。
? 測試員 2
從手動測試開始，但很快就判定創建自動執行按鍵的測試腳本更有意義。仔細找出那些會使用到軟件有用部分的測試后，測試員2將操作記錄到腳本中。這些腳本很快達到幾百個。按下一個按鈕后，這些腳本就被激活并按照步驟運行軟件。
測試員2覺得自己很聰明，也就會感到快樂――至少一段時間是這樣的。
當軟件發生變化時，這些腳本需要大量的維護。他花費數個星期和開發人員爭論，要求停止修改軟件，因為這破壞了自動化測試。最后，腳本需要太多的維護以致留下太少的時間來進行測試。
當軟件發布后，用戶發現太多腳本未覆蓋的錯誤。他們停止購買該產品而決定等待版本2的發布。
? 測試員 3
不想維護數以百計的自動化測試腳本。她編寫了一個測試程序來在應用程序中到處隨機點擊和按按鈕。這種“隨機”測試程序不需要一直查看，且發現了很多致命的錯誤。
測試員3很享受發現這些引人注目的缺陷，也就會感到快樂－－至少一段時間是這樣。
由于隨機測試程序只能發現那些毀壞應用程序的錯誤，因此測試員3仍然不得不做大量手動測試，并很快在這個過程中感到乏味和反應遲鈍。當軟件發布后用戶在軟件中發現如此多的功能性錯誤而對公司喪失信任，于是停止購買這種軟件。
? 測試員4
通過從手動測試、探索式測試開始熟悉了應用程序――用手動測試中所獲得的知識來為應用程序創建一個非常簡單的行為模型。測試員4接著使用一個測試程序來測試應用程序的行為是否和模型預測的一致。行為模型相比被測的應用程序要簡單的多，因此它很容易創建。由于測試程序知道應用程序應該怎樣做，因此當應用程序犯了錯誤時它能夠檢測到。
隨著產品周期的發展，開發人員為應用程序寫出了新的特性。測試員4很快更新了模型，測試得以繼續進行。程序白天和晚上都可以運行，持續生成新的測試序列。測試員4可以一次在多臺機器上執行測試，將多天的測試放到一個晚上來完成。
經過幾輪測試和錯誤修復后，測試員4的測試生成程序開始發現很少的錯誤。測試員4為了測試增加的行為更新了模型，然后繼續測試。測試4也會為應用程序中那些不值得建模的部分做一些手動的測試和靜態自動化測試。
當測試員4的軟件發布出來后，只有非常少的錯誤能被發現了。用戶感到高興。投資者感到高興。
測試員4感到高興。
? 評注
這四個場景展現出了當前軟件測試中可用的一些方法。
測試員 1 是一個典型的手動測試者，從鍵盤手動運行所有的測試。手動測試在當前的工業界很普遍――它能提供直接的好處，但長時間的運行會讓測試人員感到單調乏味，對公司來講成本高。
“我看到的最悲哀的景象之一就是一個人在鍵盤上手動操作一些可以自動運行的東西。這是悲哀的但也是有趣的?！?
－－Boris Beizer，黑盒測試：軟件和系統功能測試技術
測試員 2 實踐的是我稱為靜態測試自動化的測試。靜態自動化腳本每次根據同樣的次序執行同樣的命令序列。當應用程序發生變化時這些腳本的維護成本很高。測試是不斷重復的；但由于它們總是執行相同的命令，因此它們很難發現新的錯誤。
“高度重復的測試實際上將發現所有重要問題的幾率最小化了，這和沿著別人的足跡前行將發現自己的天地的幾率最小化的原因是一樣的”
－－James Bach，“騙人的測試自動化,”Windows技術期刊,1996.10
測試員 3 的操作接近于自動化測試的邊緣。這些類型的隨機測試程序被稱為蠢猴因為它們就是毫無目的的敲打鍵盤。它們生成非常規的測試執行序列并發現很多致命的錯誤，但是想控制它們到應用程序中你想測試的部分卻是很困難的。因為它們不知道自己在做什么，所以它們會漏過應用程序中很多明顯的錯誤。
“猴子式的測試不能是你測試的全部。猴子不明白你的應用程序，由于它們的無知它們漏掉了很多錯誤?！?
－－Noel Nyman，“使用猴子式的測試工具,”SQTE,2004.1/2
測試員 4 通過一種稱為“模型驅動測試”的智能測試自動化方法糅合了其它測試員的方法。
模型驅動測試并不像靜態測試自動化那樣逐字逐句的記錄測試序列，也不盲目的在鍵盤上敲打。模型驅動測試通過對應用行為的描述來判斷哪些操作是可能的、期望輸出是什么。這種方式不斷自動生成新的測試序列，很好的適應了應用程序的變化，能夠同時在多臺機器上運行，并能整天運行。
“一個藝術家用他的智慧畫畫，而不是用他的手?！?
－－Michelangelo Buonarroti
這個故事的寓意
手動測試是開始測試自動化過程的好的方法。我把這個階段稱為 “ 探索式建模 ” ，因為它綜合了探索式測試過程和用來生成測試的模型的發現過程。當你開始搞清每種操作的行為后，你就能創建能幫助建模和測試應用程序的規則。
測試員1的方法需要他的手不停的在鍵盤上工作。最后測試員1精疲力竭。
測試員2的靜態腳本重復他的手已經執行過的那些鍵盤操作。
測試員3的猴子式測試本質上是無目的的在鍵盤上亂敲。
測試員4,從另一方面，在其它技術上進行了補充：
1. 思考應用程序的行為，
2. 將行為描述給一個測試生成程序，
3. 讓測試生成程序來創建和運行測試用例。
通過根據應用程序行為描述生成測試，測試員4能夠執行那些在使用其它測試方法時不可實現的測試。
這個故事的寓意：自動化你的大腦，而不只是你的手。
? 使用你的大腦
讓我們看一個創建和使用行為模型來測試應用軟件的例子。
手動測試是開始測試自動化過程的好的方法。我把這個階段稱為“探索式建?！?，因為它綜合了探索式測試過程和用來生成測試的模型的發現過程。當你開始搞清每種操作的行為后，你就能創建能幫助建模和測試應用程序的規則。
這就是模型驅動測試的精髓：按照一種能夠被用來生成測試的方式來描述行為。針對你將要測試的每一種操作，問自己以下兩個問題：
1. 什么時候這種操作是可能的？
2. 當這種操作被執行時輸出是什么？
例如，假設你被要求測試Windows目錄下文件的行為。更確切一點，你要測試創建、刪除和反選取操作。
? 為創建操作建模
1. 什么時候創建是可能的？為了簡單，在這個例子中限制目錄中的文件數為1.這樣只有在目錄中有0個文件時可以創建。
2. 當創建被執行時輸出是什么？當你在一個目錄中創建一個新的文件時，這個目錄中的文件個數加1。這個新創建的文件默認是被選中的，因此在目錄中它是加亮的。實際上這個新文件是這個目錄中唯一被選的文件，不管在創建操作前有多少被選中。
? 為刪除操作建模
1. 什么時候刪除是可能的？只有當目錄中至少有一個被選中的文件時刪除才是可能的。
2. 當刪除被執行時輸出是什么？當你執行刪除操作時，目錄中任何被選中的文件都將消失。
? 為反選取建模
1. 什么時候反選取是可能的？在這個模型中反選取總是可能的，即使目錄中有0個文件。
2. 當反選取被執行時輸出是什么？當你執行反選取操作時，目錄中所有被選取的文件將都不再被選取，而所有沒被選取的文件將被選取。當目錄中有0個文件時，反選取讓目錄保持不變。
? 建立一個狀態模型
如圖1所示，現在你可以構建一個系統行為的“狀態模型”。它將上面描述的那些行為合在一起。注意反選取操作從0文件狀態回到0文件狀態的方式。它模擬出當沒有什么需要反選取時什么都不做的情況。
 |
圖1 狀態模型
很好，那接下來呢？
現在你明白應用程序是如何工作的，那么你就可以手動測試這些操作、檢驗Windows目錄是否按照你的預期變化。但是，由于你的理解都存在于你的大腦中，你的測試結果也就受你的時間和體力所限。
另一方面，如果你能將這個狀態模型從你的大腦完全的移植到計算機上，計算機將能替你為系統生成和執行測試。
幸運的是，這個模型可以通過計算機能識別的被稱為“狀態表”的形式進行表達。狀態表（見表1）的每一行表明某種操作用于處于開始狀態的應用程序后會到達的結束狀態。
| 開始狀態 | 操作 | 結束狀態 |
| 0個文件 | 反選取 | 0個文件 |
| 0個文件 | 創建 | 1個被選文件 |
| 1個被選文件 | 反選取 | 1個未選文件 |
| 1個被選文件 | 刪除 | 0個文件 |
| 1個被選文件 | 反選取 | 1個被選文件 |
表1 針對Windows目錄中文件行為的狀態表
也使用計算機的大腦
一旦我們將狀態模型轉換成計算機能理解的狀態表，計算機可以為我們做些什么呢？我們該如何使用我們有關應用程序行為的那些信息呢？
計算機能夠應用狀態表來生成測試序列以測試應用。你將在下面的例子中看到，可根據這些測試序列的新穎性、有效性或它們的全面性來選擇它們。這種測試生成是應用你對系統的理解的一種強有力的方式――這就是模型驅動測試的內容。
狀態模型上的隨機路線
生成測試操作的一個簡單的方法就是從應用當前狀態可用的操作中任意選擇一個。例如，如果你在0個文件開始狀態，你能夠選擇下面兩種操作中的任意一個：
1. 反選?。ㄗ屇闳酝Ａ粼?個文件狀態）
2. 創建（讓你停留在1個被選文件狀態）
按照這種方式隨機選取操作，你能生成許多非常規的序列（就象測試員3的隨機“猴子測試程序”那樣），而最后你將能執行模型中的所有操作。圖2顯示了一個典型的隨機路線。注意這個隨機路線在一輪中執行了四次同樣的操作（反選?。?，但是卻讓剩下的兩個其它的操作沒有執行到。這就是隨機測試的實際情況。
 |
圖2 一個隨機路線
| 執 行 的 操 作 | 結 束 狀 態 | |
| 1 | 創 建 | 1 個 被 選 文 件 |
| 2 | 反 選 取 | 1 個 未 選 文 件 |
| 3 | 反 選 取 | 1 個 被 選 文 件 |
| 4 | 反 選 取 | 1 個 未 選 文 件 |
| 5 | 反 選 取 | 1 個 被 選 文 件 |
狀態模型上一個有效的路線：中國郵遞員路線
當模型很大時要到達所有測試操作按照隨機路線是很低效的。我們怎樣才能有效的測試模型中的每種操作呢？
一個郵遞員在遞送信件時會遇到同樣的問題。設想模型中的每個操作是遞送郵件必須經過的街道――模型中每個狀態是郵遞員改變方向時的十字路口。就像郵遞員必須走過每一條街道來遞送郵件一樣，我們也必須測試模型中的每種操作。在這兩種情況下，我們都想將所需的路線長度減小到最短。
一個叫做管梅谷的中國數學家為這個問題提出了一個優秀的解決方案，這就是中國郵遞員算法（見圖3）。管梅谷的方法生成一條該狀態模型的路線，該路線用最少的步數執行到模型中所有的操作。下面列出的測試序列只用5步就覆蓋了模型中的5種操作。對于一個你要快速測試的、大的應用程序而言這種效率是很有用的。
 |
圖3 一個中國郵遞員路線
| 執 行 的 操 作 | 結 束 狀 態 | |
| 1 | 反 選 取 | 0 個 文 件 |
| 2 | 創 建 | 1 個 被 選 文 件 |
| 3 | 反 選 取 | 1 個 未 選 文 件 |
| 4 | 反 選 取 | 1 個 被 選 文 件 |
| 5 | 刪 除 | 0 個 文 件 |
一個更有效的路線：狀態改變的中國郵遞員路線
模型中的一些操作――如當目錄中有0個文件時點擊反選取――不會改變應用程序的狀態。如果你認為當應用程序的狀態發生變化時更容易出現錯誤，你可以優先測試狀態改變的操作。
一個簡單的方法是將不會改變狀態的操作從狀態表中過濾掉。對于表1，需要移除第一個操作（反選?。?。
在這個簡化的狀態模型上運行中國郵遞員算法生成一個用四步覆蓋模型中所有狀態改變的操作的測試序列――本質上就是將前一個例子中的第一步移除：
| 執 行 的 操 作 | 結 束 狀 態 | |
| 1 | 創 建 | 1 個 被 選 文 件 |
| 2 | 反 選 取 | 1 個 未 選 文 件 |
| 3 | 反 選 取 | 1 個 被 選 文 件 |
| 4 | 刪 除 | 0 個 文 件 |
回到開始狀態的最短路線
假設你想全面的測試所有讓Windows目錄從0個文件狀態經過幾步回到0個文件狀態的測試序列。這種不斷產生新的變化的測試序列對于測試員2的靜態自動化而言是不可想象的。
對于計算機而言根據狀態模型生成一系列這種路徑是微不足道的。你可以生成長度不斷增加的測試序列直到讓計算機死掉，這樣就能越來越深入的探索模型。
路徑A有一步：
A1：反選取
路徑B有兩步：
B1：創建
B2：刪除
路徑C有四步：
C1：創建
C2：反選取
C3：反選取
C4：刪除
 |
圖4 四步或更少的狀態回環
使用計算機的手
每種算法的輸出是需要執行的測試操作的序列。哪種是執行這些操作的最佳方法？你可以將操作列表交給一個測試人員去手動執行――但這肯定是緩慢的、單調乏味的和痛苦的。誰愿意把他們的時間都花費在執行這些操作上。這種重復性的工作就是那種讓測試員1如此痛苦的罪魁禍首。
作為替換，你可以編寫一個簡單的測試執行程序來讀取列表并執行針對列表中每種操作的測試代碼。
例如，使用Visual Test，創建操作的執行測試代碼為：
WToolbarButtonClick("@1","File") ' Open the File menu
WMenuSelect("New") ' Select New File
WMenuSelect("Text Document") ' Choose Text Document
Play "{Enter}" ' Aclearcase/" target="_blank" >ccept the default filename
在典型的靜態自動化中，這段代碼將嵌入腳本中――但在一個模型驅動測試程序中，這一小段代碼將只在列表中的測試操作需要執行創建操作時才會被調用。
使用計算機的眼睛
自動化測試操作只是戰斗的一半。你還需要一種自動判斷應用程序是否正確工作的方法。
這種方法――一種用來判斷應用程序是否正確響應測試操作的方法－－被稱為測試準則。一些測試方法，如測試員3的隨機猴子式測試程序，必須基于類似于應用程序是否崩潰的痛苦的測試準則。
模型驅動測試讓測試程序有能力檢查那些比“系統不崩潰”更細的行為指標。根據狀態表中的信息，模型知道每一個狀態下哪些操作是可用的以及每種操作的期望輸出。例如，模型指出測試程序在一個被選文件的狀態下可以執行刪除操作。模型同時也指出執行刪除操作的結果就是讓應用進入0個文件狀態。這些知識提供了兩種檢驗應用程序是否正確運行的方法。
第一，測試程序可以判斷是否能執行的操作不能執行。如果在應用處于1個被選文件的狀態下不能執行刪除操作，測試程序將上報一個錯誤，因為在無法找到菜單中的可選刪除項時測試程序會失敗。
第二，模型始終知道應用程序應該進入哪種狀態。知道每種操作的期望結束狀態也就意味著我們能夠創建測試準則程序來檢查（在每種操作結束后）目錄中是否有合適的文件數和被選文件數。例如，當上述的刪除操作被執行后，結束狀態就應該是目錄中有0個文件（當然也就是0個文件被選）。
程序化的測試語言通常提供可用于測試程序檢查應用程序各個方面的函數。兩個對當前模型有用的Visual Test函數是：
WviewCount()指出目錄中的文件數，
WviewItemSelected()指出目錄中有多少文件被選。
測試程序能夠驗證應用程序是否處在正確的狀態，如表2所示。| 應用程序的狀態 | WviewCount的期望返回值 | WviewItemSelected的期望返回值 |
| 0個文件 | 0 | 0 |
| 1個被選文件 | 1 | 1 |
| 1個未選文件 | 1 | 0 |
表2 顯示Visual Test函數WviewCount()和WviewItemSelected()的狀態表
上面討論的刪除操作將讓應用進入0個文件狀態。如果WviewCount()返回一個非0的值，測試程序準則將上報一個錯誤，因為目錄中的文件數不正確。
如何更新模型驅動測試
還記得測試員2的靜態測試自動化嘗試由于應用程序的改變而讓人灰心嗎？相反的是，測試員4能夠利用模型驅動測試自動化來很快適應應用程序的改變。
將新的操作合并到模型中
假設你的開發團隊告訴你他們實現了全選操作。你該怎樣為新的操作更新你的測試呢？很簡單――升級你的狀態模型來并入全選操作，然后重新生成測試。
第一，通過回答我們那兩個基本問題來為全選建模：
1. 什么時候全選是可能的？在這個模型中全選總是可能的，即使目錄中只有0個文件。
當全選被執行時輸出是什么？當你執行全選時，目錄中的所有文件變成了被選。如果目錄中有0個文件，全選將使得目錄沒有變化。這種情況在下面的圖示中指示了出來，全選操作從0個文件狀態回到0個文件狀態。圖5中顯示了合并全選之后的新的狀態模型。
 |
圖5 包含全選的狀態模型
在升級后的模型上（見圖6）運行中國郵遞員算法得到了一個九步的測試序列――用0個文件狀態作為開始狀態――執行了模型中所有操作，其中包括新加的全選操作：
 |
圖6 新狀態模型下的中國郵遞員路線
| 執 行 的 操 作 | 結束狀態 | |
| 1 | 反 選 取 | 0 個 文 件 |
| 2 | 創 建 | 1 個 被 選 文 件 |
| 3 | 反 選 取 | 1 個 未 選 文 件 |
| 4 | 全 選 | 1 個 被 選 文 件 |
| 5 | 反 選 取 | 1 個 未 選 文 件 |
| 6 | 反 選 取 | 1 個 被 選 文 件 |
| 7 | 全 選 | 1 個 被 選 文 件 |
| 8 | 刪 除 | 0 個 文 件 |
| 9 | 全 選 | 0 個 文 件 |
下一步就是確定用于調用全選操作的代碼，不管該操作在測試序列中何時發生。使用Visual Test該代碼如下：
WtoolButtonClick(“@1”,”EDIT”)
WmenuSelect(“Select All”)? 總結
弄清應用程序并為其建模需要相當大的努力。放棄路線簡單的手動測試和路線足夠長的靜態自動化測試，而花費時間思考如何對應用程序進行測試是困難的――就象我們在虛構的故事中所看到的四位測試員所進行的試驗和經歷的磨難那樣。
但是我們獲得的回報是豐厚的：
1. 模型驅動測試幾乎從開發的第一天起就開始創建靈活的、有用的測試自動化。
2. 模型的修改很簡單，因此模型驅動測試在項目的生命周期中進行維護是很經濟的。
3. 模型能夠根據你的需要來生成數不清的測試序列。
4. 模型讓你能夠在短時間內完成更多的測試，因為一個測試生成程序能整天在多臺機器上創建和驗證測試序列。
5. 模型驅動測試能對其它形式的測試進行補充，能夠執行那些在其它測試方法下不可實現的測試。
你和我都知道軟件測試不是虛構的故事，不可能保證整個過程中都是愉快的。但是在你的測試中加入模型驅動的智能將是幫助你找到通向快樂的終點的強大的工具。
作者簡介
Harry Robinson是微軟智能搜索組的軟件測試經理。他維護著模型驅動測試的主頁（www.model-based-testing.org）,是模型驅動測試長時間的倡導者和開拓者。
原文轉自：http://www.anti-gravitydesign.com
