基于模型的測試：一個軟體工藝師的方法
The Craft of Model-Based Testing
［美］ 保羅·C.喬根森（Paul C. Jorgensen） 著
王轶辰 王轶昆 曹志欽 譯
第1章
基于模型測試概述
無論是軟體還是硬體，甚至是日常生活中，所有的測試都可以視為系統因某個激勵産生響應，然後對其進行檢查的過程。事實上，早期的需求方法也主要是針對激勵-響應進行研究的。在基于模型的測試（MBT）中，我們認為模型在某種程度上就是激勵-響應的一種表達方式。其中有一些說明性的詞彙有助于我們對這個問題的了解。
在軟體測試領域，有3種被廣泛接受的測試級别：單元測試、內建測試和系統測試。每個級别的測試都有明确的測試目标和測試方法。單元測試主要針對類或者過程進行測試，內建測試主要針對單元之間的互動進行測試，而系統測試則更加關注被測系統（SUT）的對外端口（也稱為端口邊界）。每個級别的測試都有一個測試覆寫矩陣（更詳細的讨論請見[Jorgensen 2013]），同時每個級别的測試用例都包含相似的要素：用例名稱和辨別（ID）、前置條件、輸入序列（也可能是互動輸入）及預期輸出、記錄的實際輸出、後置條件，以及通過準則。
1.1 基本術語
定義：被測系統通常縮寫為SUT，即将要被測試的系統。
SUT可能是：一個由軟體控制的硬體系統，一個僅有硬體的系統或者僅有軟體的系統，甚至可能是由若幹個SUT組成的大系統。SUT也可以是一個單獨的軟體單元或者是由多個單元組成的集合。
定義：被測系統的端口邊界，是被測系統中所有能夠施加輸入激勵以及接收輸出響應的端口集合。
無論是硬體、軟體還是固件抑或是3種的組合，每一類系統都有端口邊界。識别出SUT“真正的”端口邊界對于基于模型的測試（MBT）過程而言是至關重要的。為什麼說是“真正的”？因為在測試過程中我們很容易将使用者引起的實體事件與由此産生的電子信号（激勵）相混淆。在基于Web的應用中，使用者接口很可能就是系統級的輸入和輸出所在位置。在汽車刮水器控制器中，端口邊界通常包括控制杆、決定刮水器速度的撥盤以及驅動刮水器葉片的電機。本書中還用到了車庫門控系統（後面會詳述），該系統的端口邊界包括發送控制信号的裝置、安全裝置、末端傳感器，以及一個驅動電機。一個單元的端口邊界則是激活該單元的某種機制（可能是面向對象軟體中的消息，也可能是傳統軟體中的某個過程調用）。
定義：端口輸入事件是針對給定SUT端口邊界的一個激勵。同樣，端口輸出事件是發生在SUT端口邊界的一個輸出響應。
在看待系統的端口輸入事件上，開發人員和測試人員在觀念上有明顯的不同。測試人員的想法是針對SUT如何産生或引發一個輸入激勵，而開發人員考慮更多的是輸入激勵會導緻軟體産生什麼樣的行為和動作。這種差別也同樣明顯地反映在輸出事件上，測試人員需要知道如何觀察或者探知到系統的輸出響應，而開發人員則關心如何生成或者引發輸出響應。這些觀念上的不同，有一部分是由軟體開發團隊建構的設計和開發模型所造成的。設計和開發模型是從開發者的視角進行建構的，而測試用例的産生卻是從測試人員的視角建構的。這個不同之處可能會在基于模型的測試中産生一定的影響。
1.2 事件
下面的術語基本上都是同義詞，但略有不同：端口輸入事件、激勵、輸入。同樣，下面這些詞也基本上算是同義詞：端口輸出事件、響應、輸出。事件是一級一級發生的，當然，或許使用“按順序發生”會更好些。我們來看車庫門控系統（見1.8.2節詳述），重點是包含光束傳感器的安全裝置。當車庫門正在向下關閉的時候，如果任何事物阻斷了光束（在靠近地闆部分），那麼電機會立刻停止并反向打開車庫門。這個事件序列就是從某一個實體事件開始的，這個事件有可能是向下關門過程中有一個小動物恰巧穿過了光束。當光束傳感器探測到中斷時，它會給控制器發送一個信号。這就是端口輸入事件，而且是一個真實的電信号。内部的控制器軟體就會将此視為一個邏輯事件。
端口輸入事件可能發生在不同的邏輯場景中。“一隻貓穿過了光束”是一個實體事件，而這個實體事件有可能發生在好幾種場景中，例如車庫門已經打開的時候，正在打開車庫門的時候，或者正在關閉車庫門的時候。我們所關心的邏輯事件卻隻是發生在“正在關門”的時候。通常，事件發生環境在某些有限狀态機（FSM）中表示為狀态。在評估不同類型的模型對MBT的支援能力的時候，有一個很重要的名額就是該類型的模型能否表達和識别出對環境敏感的輸入事件。同樣，這也要求我們關注端口輸入裝置本身。假設一個測試人員想要測試光束傳感器，尤其是其失效模式。通常的裝置失效包括“在位置1失效”（SA-1）和“在位置0失效”（SA-0）。對于SA-1失效，光束傳感器在發送信号位置失效，即保持一直發送信号的狀态，無論實體輸入事件有沒有發生。請注意，在這種失效情況下是沒法關上車庫門的（請見下表中的EECU-SA-1用例）。而SA-0失效更加隐蔽一些，它表示光束傳感器始終保持不發送信号的狀态，這将導緻即使實體中斷發生之後，門也不會反向打開。我相信，如果律師得知在安全裝置中會産生SA-0失效之後，那麼他一定會非常郁悶。在第8章我們會對此進行模組化。
“在某個位置失效”這類故障以及其他失效模式是很難被定義的。它們可能不會出現在需求文檔中。就算是在需求文檔中有所說明，在很多基于模型測試的過程中也很難對其進行模組化。我們會在第8章詳述這一點。使用者有可能會提供類似EEUC-SA-1的用例嗎？基于以往的經驗，這是很有可能的。但在靈活開發中，這就是個挑戰了。
1.3 測試用例
對于一個測試用例而言，它有兩種基本的形式—抽象的和真實的，有些MBT團隊将後者稱為具體測試用例。抽象測試用例通常是從一個形式化模型中派生出來的。何為抽象？意指輸入通常是以變量方式來表達的。真實的（具體的）測試用例包含輸入變量的真實數值，以及預期的輸出數值。這兩種形式都包括前置和後置條件。
1.4 測試用例的執行架構
圖1-1是一個通用的自動化測試用例執行架構。它的基礎是我的團隊在20世紀80年代早期開發的一個針對電話交換機系統的回歸測試項目。圖中的計算機包括所有測試用例的處理器，這些處理器控制并觀察測試用例的執行過程。測試用例使用簡單的語言來描述，這個語言可以解釋執行。語言中包括CAUSE和
VERIFY語句，它們指代SUT的端口邊界。CAUSE語句一般都帶有參數，它們指代端口輸入事件和發生這些事件的裝置（它們還可能有附加參數）。同樣，VERIFY語句指代預期的端口輸出事件。在電話交換機的SUT中，一個測試用例可能有以下兩種語句：
在這些語句中，InputDigit指代Line12裝置上發生的帶有參數的端口輸入事件以及該裝置上發生的端口輸出事件。能夠實作這個架構的關鍵是開發一個能夠連接配接SUT與測試用例處理器的“?套件?”。套件主要完成的工作包括以下内容。在CAUSE語句中，将端口輸入事件從邏輯形式（抽象形式的用例）轉換為實體形式；在VERIFY語句中，将端口輸出事件從實體形式轉換為邏輯形式。
以上内容主要針對系統級測試。在單元測試中，類似nUnit family的自動測試工具很常見，其中CAUSE和VERIFY語句被ASSERT語句替代。ASSERT語句中包括被測單元的輸入和輸出，由此取代了系統測試中的測試套件。本書中我們忽略了內建測試，因為幾乎沒有MBT工具能夠支援內建測試。本章結尾部分給出的MBT例子也隻是包括了單元測試和系統測試。大家一定要記住，基于模型的測試要想成功，使用的模型必須能夠提供激勵和響應，不管它是單元級别還是系統級别。
1.5 MBT中的模型
軟體和系統設計模型通常包含兩種類型—針對結構的模型和針對行為的模型。在通用模組化語言（UML）中（UML已經成為一種事實上的标準），針對結構的模型集中于類、類的屬性、方法和類之間的連接配接（繼承、聚合、相關）。另外，主要有兩種針對行為的模型—狀态圖和活動（或者順序）圖。本書第一部分呈現了9種針對行為的模型：流程圖、決策表、有限狀态機、Petri網、事件驅動的Petri網、狀态圖、泳道型事件驅動的Petri網、UML（用例和活動圖）、業務流程模組化和辨別（BPMN）。在這些模型中，除了泳道型事件驅動的Petri網[Jorgensen 2015]和BPMN以外，都在[Jorgensen 2008]中有非常詳細的解釋。本書的重點是擴充這些模型，以支援基于模型的測試。在MBT中有一個不可避免的局限性，隻有原生模型（軟體和系統設計模型）比較好，派生出來的測試用例才能夠同樣好。是以在第一部分我們需要特别關注的就是不同模型的局限性以及它的表達能力。
1.6 ISTQB中的MBT擴充
本書意在與ISTQB基礎級大綱中關于MBT的内容保持一緻，該大綱于2015年10月釋出。ISTQB（國際軟體測試評定委員會）是一個非營利組織，截止到2013年，已經有超過100個國家的336?000名測試人員取得認證。本書的第二部分介紹了6個測試工具，以及使用這些工具對書中的例子進行測試的結果。
1.7 MBT的形式
基于模型測試的過程有3種基本形式：手動測試、半自動測試和全自動測試[Utting 2010]。在手動MBT中，建構并分析SUT的模型是為了設計測試用例。例如，在基于有限狀态機的MBT過程中，首先需要使用有限狀态機對SUT進行模組化，這樣一條從初始狀态到最終狀态的路徑就可以被形象地辨別出來并轉化成測試用例。接着需要确定一個可用準則，用來選擇哪些測試用例将予以執行。這些選擇測試用例的準則實質上就是某些覆寫矩陣。然後我們還需要對這些用抽象術語描述的測試用例進行“?具體化?”（這是一個在MBT領域常用的術語）。比如，将“?個人ID号碼?”這種抽象表達具體化為一個真實的數值“?1234?”。最後一步是在被測系統上執行具體的測試用例。這部分内容可以參考Craig Larman [Larman 2001]，資料中提到了用例的4個級别（第9章會詳述）。其中第三級稱為擴充的關鍵用例，包含了抽象的變量名；而Larman的第四級用例就是真實使用的用例，将抽象的術語和變量名稱替換為要測試的真實數值。這就是具體化過程。半自動MBT和手動MBT的差別是在測試過程的早期是否使用了工具。工具是指能夠運作某個合适模型并且生成抽象測試用例的引擎。下一步，從生成的測試用例集中挑選予以執行的測試用例，這個過程可以自動進行也可以手動進行。在有限狀态機例子中，挑選測試用例的準則可能是以下幾種：
1）覆寫所有狀态。
2）覆寫所有變遷。
3）覆寫所有路徑。
這個挑選過程也可以自動進行。另外，全自動MBT與半自動MBT的差別是測試用例是否自動執行，我們在第二部分會詳述這一過程。
1.8 案例集
1.8.1 單元級問題：保費計算
政策規定的汽車保費是根據考慮了成本的基本利率計算而成的。該計算的輸入如下所示：
1）基本利率是600美元。
2）保險持有者的年齡（16≤年齡< 25；25≤年齡< 65；65≤年齡<?90）。
3）小于16歲或者大于90歲的，不予保險。
4）過去5年中出險次數（0、1～3和3～10）。
5）過去5年出險次數超過10次的，不予保險。
6）好學生減免50美元。
7）非飲酒者減免75美元。
具體數值的計算見表1-1～表1-3。
1.8.2 系統級問題：車庫門控系統
車庫門控系統包括驅動電機、能夠感覺開/關狀态的車庫門輪傳感器以及控制裝置。另外，還有兩個安全裝置：地闆附近的光束傳感器和障礙物傳感器。隻有車庫門在關閉過程中，後面兩個安全裝置才會運作。正在關門的時候，如果光束被打斷（可能家中的寵物穿過）或者車庫門碰到了一個障礙，那麼門會立即停止動作，然後向反方向運作。為減少後續章節中的模型數目，本書中我們隻考慮光束傳感器。關于障礙物傳感器的分析，與之基本相同，不再贅述。一旦門處于運作狀态（要麼正在打開，要麼正在關閉），控制裝置發出信号，門就會停止運作。後續的控制信号會根據門停下來時的運動方向來起動門的運作。最後，有些傳感器會檢測到門已經運作到了某個極限位置，即要麼是全開，要麼是全關。一旦這種情況發生，門會停止動作。圖1-2是車庫門控系統的SysML上下文圖。
在絕大多數的車庫門控系統中，有如下幾個控制裝置：安裝在門外的數字鍵盤、車庫内獨立供電的按鈕、車内的信号裝置。為簡單起見，我們将這些備援的信号源合并為一個裝置。同樣，既然兩個安全裝置産生同樣的響應，我們隻考慮光束裝置，忽略障礙物傳感器。
1.8.3 其他案例
這裡給出其他幾個案例以說明和比較模組化理論和技術。表1-4描述了表1-5中的示例使用的不同的模組化方式。
1.9 MBT的技術現狀
從20世紀80年代起，MBT就以手動的方式開始為人所用。此後許多學術研究團隊開發的開源MBT工具，讓更多的人開始關注MBT。最近，商用MBT工具的出現使得這項技術進入到工業領域。從Robert V. Binder所做的兩份調查中可以看出使用MBT的一些原因。最早針對MBT使用者的調查是在2011年開展的，随後在2014年又做過一次。這些調查總結了早期MBT使用者的期待與顧慮。
Binder在2011年的調查[Binder 2012]中特别強調了以下幾點：
- MBT的應用有了長足發展，包括軟體過程、應用領域和開發團隊方面。
- MBT不僅可用而且可行。一半的被訪者回報說，隻需要80小時或者更少的時間就可以基本熟練掌握MBT技術，80%的受訪者需要最多100小時。
- 平均來說，受訪者回報MBT技術能夠減少59%的錯誤逃逸率。
- 平均來說，受訪者回報MBT技術能夠減少17%的測試開銷。
- 平均來說，受訪者回報MBT技術能夠減少25%的測試時間。
該調查項目在2014年再次開展，同時增加了兩個MBT的實踐者：Anne Kramer（見第18章）和Bruno Legeard（見第14章）[Binder 2014]。此次一共收到100份回報。下述内容顯示了此次調查的亮點（内容為直接引用或者部分引用）。
測試級别：
- 77.4%的人使用MBT進行系統測試
- 49.5%的人使用MBT進行內建測試
- 40.9%的人使用MBT進行驗收測試
- 31.2%的人使用MBT進行部件測試
生成的産品：
- 84.2%的産品是自動的測試腳本
- 56.6%的産品是手動測試用例
- 39.5%的産品是測試資料
- 28.9%的産品是其他文檔
最大的益處：
- 測試覆寫率
- 處理複雜度
- 自動測試用例的生成
- 重用模型和模型元素
最大的局限性：
- 工具支援
- 需要專門的MBT技能
- 不願意改變
通用觀察：
- 96%的人在功能測試中使用MBT
- 81%的人使用圖形化模型
- 59%的人針對行為特性模組化
- 大概需要80小時成為熟練使用者
- 72%的參與者非常願意繼續使用MBT
MBT使用者的期待：
- 73.4%的人期待更高效的測試設計
- 86.2%的人期待更有效的測試用例
- 73.4%的人期待更好地管理系統測試的複雜性
- 44.7%的人期待改進交流
- 59.6%的人期待盡早開始測試設計
MBT的整體效率：
- 23.6%非常有效
- 40.3%中等有效
- 23.6%稍微有效
- 5.6%幾乎無效
- 1.4%效率輕微下降
- 2.8%效率中等下降
- 2.8%效率極度下降
參考文獻