MFQ&PPDCS大型嵌入式軟件系統的測試分析和測試設計

MFQ&PPDCS大型嵌入式軟件系統的測試分析和測試設計

原創做者：邰曉梅

翻譯：wzhj132

原創來源：2009年ICSEA大會上的論文《MFQ & PPDCS - Test Analysis and TestDesign for Large Embedded Software Systems》

內容簡介：

MFQ & PPDCS是由邰曉梅提出的一套測試設計框架：其中MFQ針對大型系統中的功能多且複雜、功能之間的交互多、質量屬性要求高的特色，結合Model Based Testing的思路，按照4-step的步驟開展測試分析和測試設計；PPDCS是針對不少測試人員面對衆多的測試設計技術無從選擇的問題而提出的一種選擇測試設計技術的思路。MFQ & PPDCS方法曾在華爲內部開展過多期培訓，在多個產品線內獲得實踐應用。

本人只是在學習之餘，簡單將其翻譯成中文，方面學習，共享之，關於MFQ&PPDCS這個方法（不論中文、英文）版權都屬於邰曉梅做者。

說明：未經容許，請勿轉載。如需轉載，請於做者邰曉梅及本人聯繫。

摘要：大型嵌入式軟件系統有三個重要特色：數量巨大和複雜的功能、很是多的功能交互和嚴格的質量要求。這篇論文包括

兩個部分，部分1提出了一個結合MBT（基於模型的測試）和Torbjorn Ryber's的4步測試設計的方法，MFQ；部分2提出了一個新的技術PPDCS，選擇合適的測試規範技術來構建模型。

關鍵字- 測試分析；測試設計；基於模型測試；測試方法論。

I. 背景知識

1. A 大型嵌入式軟件系統的特色

現在，嵌入式軟件佔據軟件的很大一部分比例。例如在日本，「嵌入式軟件佔據軟件行業的很大比例，主要是由於不少大公司生產電子、汽車等。」

對比傳統的胖客戶端或者給予瀏覽器的桌面應用軟件，大型嵌入式軟件系統有下面特色：

• 大量和複雜的功能：典型產品的代碼量大小常常達到百萬行，包括每一個版本的新特性，涉及軟件和硬件功能，包括O&M（操做和維護）和服務處理模塊等等。

• 大量的功能交互：由於嵌入式軟件常常運行在實時操做系統上，任何一個功能在任什麼時候刻可能被其餘事件所影響，例如被其餘正在運行的功能模塊，定時的任務，非預期的時間（例如交換和重置某些硬件）

• 很是嚴格的質量要求：除了追求準確的高質量功能特性，嵌入式軟件還要提供高質量的非功能性特性，包括可靠性，可擴展性，靈活性和健壯性等等。

高質量的要求使得測試者的角色尤爲重要，軟件系統的複雜性也讓測試工做變得頗有挑戰。

1. B  測試分析和設計的問題調查

一般狀況下，編碼後開發人員會在提交產品給測試人員前進行低級別測試（LLT：Low Level Test），通常包括單元測試（UT：Unit Test）和集成測試（IT：Integration Test）等，提交後，測試人員採用高級別測試（HLT：High Level Test）例如系統測試。LLT在單一功能上關注不少，而HLT主要關注功能交互和質量屬性特色。LLT階段和HLT階段要測試的內容以及這兩個測試階段的負責人明顯是不一樣的。

簡單功能的測試設計，儘管開發或者測試已經作了，可是效果不好，由於對如何應用測試設計技術好比等價類劃分、邊界值、決策表等理解不夠透徹。多是由於在這些技術上缺少足夠的培訓，即便有一些培訓，這些培訓常常都是一次聚焦於一兩個技術，並且這些培訓課程涉及的案例都太簡單了。全部這些因素使得測試規範技術的使用變得困難。真實場景是，人們常常依賴本身的經驗來作測試設計，因此測試用例集離完整性和有效性還差很遠。

另一個測試設計的問題是功能交互點和非功能質量特徵在測試分析的時候沒有被很好的考慮。基於經驗的測試設計過度依賴人們的測試經驗不容易將要測試的功能交互要點和質量屬性考慮全面。

1. C 論文的內容

該論文試圖針對大型嵌入式軟件系統，提出一種基於新的建模方法和測試分析設計框架，經過系統化和層次化的方法，快速選擇合適的測試規範技術來高效地建立測試分析模型，達到相對有效和完整的測試用例，提供一種指南。

這篇論文的組織以下：

• 第I章講述一些背景信息；

• 第II章澄清測試分析和測試設計的概念

• 第III章提出針對大型嵌入式軟件系統的MFQ框架

• 第IV章提出幫助選擇測試規範技術的指南PPDCS方法

II. 測試分析和測試設計

1. A 不一樣的觀點

咱們常常稱「測試分析和設計」，必定程度上，混淆了「測試分析」和「測試設計」。由於最後測試用例是測試設計活動的直接結果而不是測試分析活動的結果，測試分析傾向於忽略測試分析活動的重要性。

   MikeSmith指出「人們傾向於參考‘測試分析和設計活動’。我更傾向於主張測試分析和測試設計做爲不一樣的活動，引出不一樣組織結構的工做做品。這個更好的反映存在的需求和已經實施的系統之間的複雜邏輯的天然聯繫。」Mike Smith認爲「測試分析」解決「是什麼」。好比測試的目標和方法是什麼？他認爲「測試設計」解決「怎麼作」，例如這些方法和目標怎麼實現。

另外一個觀點，Torbjorn Ryber將測試簡化爲「一個持續問問題的過程」，就像圖1. 從這個模型能夠推導出「測試分析」其實是「怎麼作---我怎麼問問題？」，「測試設計」其實是「是什麼--我要問什麼問題？」

實際上，兩個觀點都強調測試分析活動的重要性。接下來就是怎麼作測試分析的問題了。

1. B 測試分析和模型

在早期的測試中，測試設計過程基本上就像「需求/規格-->測試用例」。也就是說，測試分析從需求/規格文檔，大部分基於測試經驗直接生成測試用例。

後來，人們開始學習特定特定的測試規範技術來設計測試用例，例如EP（等價類劃分），BV（邊界值），決策表等。這些測試規範技術更像工具，方法或者測試者獲得最後用例的途徑。測試分析和測試設計活動並無明顯地區分。也能夠說，測試分析和測試設計活動是並行的。當一個完成了，另外一個也跟着結束了。測試設計過程更像是「需求/規格-->測試分析和測試設計-->測試用例」。

當被測軟件變得愈來愈複雜，越多的測試分析工做須要在完成最後測試用例的時候完成。例如，對於大型嵌入式通訊軟件系統，測試分析師不得不努力將他們精力投向學習測試對象，描繪整個圖，將測試對象分解到不少小組件使得每一個組件都足夠小到能夠設計，而後分析使用不一樣的規範技術測試各個組件。在全部這些分析工做結束後，測試用例設計工做開始。所以，測試設計過程變成「需求/規範-->測試分析-->測試設計-->測試用例「。

毋庸置疑，一個有創造性和經驗豐富的測試者作測試分析工做會比普通測試者作得好，由於「分析」是一種能夠經過工做經驗得到的能力。然而，並非說「分析能力」是不能經過肯定的方法和理論得到和增強的。實際上，基於模型的測試對幫助提升改進測試分析工做的質量有很大的幫助。Torbjorn Ryber這樣定義模型:「咱們的模型能夠是描述系統如何工做的表格形式，流程圖或者其餘圖表。」它就像是經過地圖展現一座城市；測試對象也能夠經過模型展示出來。模型能夠經過一種抽象和簡單的方法顯示測試對象的內在聯繫。實際上，創建模型的過程就是測試分析的過程。

實踐證實，使用模型作測試分析至少有三個好處：

• 經過建模的這個過程，測試分析者變得愈來愈熟悉測試對象，不少早期對測試對象的懷疑也變得清晰了。在建模的過程當中，不少在需求描述出現的不肯定問題，測試分析者要不斷同軟件設計者交流來找到這些問題的答案。所以，不少潛在的問題會在他們被真正成爲缺陷以前被發現。這就是預防bug而不是發現bug的活動。

• 基於更容易的理解特性的緣由，模型是做爲測試者和設計者，以及測試設計做者和他們的評審者的很好的媒介。

• 模型一般很容易被測試用例覆蓋。經過圖形的知識展示，測試者老是更容易從模型派生用例的方法，結果是模型覆蓋的測試設計方法比傳統的基於經驗測試設計方法更好。

下面章節將介紹基於模型的測試分析和測試設計技術--MFQ&PPDCS

III  MFQ-測試分析和測試設計框架

1. A MFQ介紹

就如上面提到的大型嵌入式軟件系統有三個明顯的特徵：多和複雜的功能，數量衆多的功能交互，高質量特性要求，相應地，大型嵌入式軟件系統的MFQ測試分析和設計框架包括三個部分：M-基於模型的簡單功能測試分析和設計；F-功能交互測試分析和設計；Q-質量屬性測試分析和設計。

針對上述3個部分的每一個部分，基於4-step模型的測試分析和測試方法都會用到，詳細內容在B章節介紹。

上述的三個部分能夠被用在任何測試級別（單元測試、集成測試、或者系統測試），可是下面是一些有用的建議：

• 在單元測試或者組件測試級別，第一個部分「M-基於模型的簡單功能測試分析和設計」始終都應該使用。目的是保證獨立的單個功能在集成到其餘組件進行高級別測試以前已經被徹底測試。

• 在系統測試級別，第二部分F和第三部分Q應該儘量使用。這是保證整個系統的功能準確性和質量屬性。

• 在低級別測試應用M和Q取決於項目和人力技術技能的狀況，一些質量屬性在項目中能夠被提前驗證。例如，健壯性是組件測試很是重要的部分。

• 當測試軟件從低級別測試轉向高級別測試的時候（一般是從開發團隊到測試團隊），測試者驗證基本功能測試已經完成。所以，第一部分M在高級別測試也須要。

1. B 4-step測試分析和測試設計過程

   MFQ框架使用4-step 測試分析和測試設計過程，詳細資料能夠在參考文獻【2】中找到。這裏簡單介紹一下。

Step1：爲測試對象建模

成功測試的關鍵在於好的分析模型，可是好的模型創建在對測試對象的熟悉程度的基礎上。這在大型嵌入式軟件系統尤爲適用，由於商業公司背景知識永遠是好的測試分析和設計工做的基礎。因此在作任何測試分析的第一個步驟是收集關於測試對象的足夠多的信息，從而得到對產品更深的瞭解。這些信息能夠是手邊的全部設計文檔，例如特性設計規格，軟件規格說明書，高級別設計規格和低級別設計規格等等。在對測試對象有一個充分的瞭解後，測試分析者能夠嘗試選擇一個合適的模型來描繪測試對象。有不少流行有效的測試規範技術例如等價類劃分、邊界值，決策表，業務流程圖、基於狀態的測試等等，測試分析者經常發如今建模的時候面對不少的選擇，他們很快陷入不知道選擇哪一個的情形。不少模型可用被用來描繪一個測試對象，可是常常狀況下只有其中一種最適合咱們使用。PPDCS在下一個章節就是要解決這個問題的構想。

Step2: 設計基礎測試用例（有時候叫作合邏輯的或者抽象的測試用例）來覆蓋這個模型

所謂的基礎測試用例指的是比較泛的用例，在測試用例中沒有測試數據的值。跟傳統一步測試用例生成過程不一樣，測試用例4-step過程的產生須要兩個步驟：第一設計基礎測試用例，第二針對每一個測試用例更多的測試數據來產生最後可執行的測試用例。

設計基礎用例的目的是更好的進行模型覆蓋。不一樣的模型有不一樣的測試覆蓋方法。最近幾年，不少學者在研究根據肯定的生成規則或者算法自動生成測試用例的基於模型的測試。這篇論文更多地關注建模過程和觀察從模型手動生成用例的過程,由於在我經驗中，建模的工做花費較多時間，而從模型生成測試用例的過程相對簡單且不耗時。

此外，在該篇論文中，"模型「的概念是廣義的，例如，一個模型不必定得是經過UML或者其餘肯定的語言的表達。實際上，一個模型能夠是任何一種表格，圖表，樹等等，只要它能幫助咱們清楚地描述測試對象。基於個人經驗，絕大多數的的測試對象能夠經過簡單地模型表示。我認爲在大多數場景下，測試規範技術不須要很是複雜。在人們爲特定的測試對象開始測試設計的過程若是須要一個很難學習的測試規範技術，我認爲這個對象的系統設計或者需求設計須要重來。

Step3：考慮測試數據的變化來敲定測試用例（有時叫作具體的測試用例）

若是第一步驟是用模型覆蓋需求，那麼第二步是用基本測試用例覆蓋模型，而後第3步是用測試數據覆蓋每一個基本測試用例。有一些測試數據在基本的測試用例已經包括，因此第一件事要作的是識別出測試數據，而後第二件事要作的是考慮測試數據的變化，好比使用等價類劃分和邊界值。（備註：等價類和邊界值有點特殊由於他們也能夠用在第1步驟的建模）。針對每一個測試數據的變化，設計一個測試用例。第3步之後，最後可執行的用例已經完成。

Step4：進一步測試

沒有一種類型的模型能夠有效地描述測試對象的全部方面。儘管上面三個步驟已經使用，仍然會存在測試對象的一些其餘方面須要測試。例如，一些特殊的規格變量限制關係很難放進模型，因此須要另一個分開的測試設計。另外一方面是，人們的經驗，測試分析者對測試對象有他們本身的理解，並且很難放到模型中，因此更進一步的測試設計過程是須要的。

好的測試=正式的測試+非正式的測試。前面三個步驟是正式測試過程，最後的步驟「高級測試」是非正式的測試過程。實際上，非正式測試並不意味着沒有任何規則可遵循的隨機測試。有不少成熟的非正式測試的方法，好比基於錯誤的測試，探索性測試等等，這些測試不在這篇文章詳細展開。

1. C M-基於模型的簡單功能測試分析和設計

上述「基於4-step模型的測試設計過程"是最適合簡單功能測試設計的，由於簡單功能的合適粒度，因此這部分用M（Model)表示。

在爲簡單功能測試設計和分析應用4-step過程當中，首要作的是將測試對象分爲不一樣的」簡單功能「（單元或者組件）。根據個人經驗，一個簡單功能的能夠是幾十行到幾百行代碼的大小，可是最好不要超過一千行。一個簡單的功能在單元測試裏能夠對應1個或者幾個組件，或者1個或幾個SRS的需求，或者一個或者兩個用戶場景。沒有明確的規則規定那個文檔須要被引用，那個需求或者規格須要對應一個簡單功能。所以，測試分析者須要收集足夠多的材料來作測試分析來識別須要測試的合適的簡單功能。

在面向對象的程序裏，簡單功能可能相對比較容易識別。一個對象負責實現的方法（成員函數）或者一個類能夠被當作整個系統的一個簡單功能。可是在其餘語言，例如C語言，識別簡單功能不是那麼容易。一般狀況下，一個簡單功能擁有兩個特徵：

• 從需求的角度看，一個簡單功能是相對獨立的。一個軟件系統由不少特性組成，一個簡單的特性能夠分解爲不少分開的功能。

• 從實現的角度看，內在邏輯和簡單功能是相干的。例如，一個對象的行爲可能經過不少方法（不少功能）實現，一個方法可能包含不少步驟。

同Bill Wake描述的的用戶故事的INVEST模型相似，一個簡單功能應該是獨立的、可測試的、有價值的（實現特定功能）、比較大的（根據上下文狀況，沒有固定的大小）、可調整的（簡單功能的分發能夠適應測試分析和測試設計的活動的調整）

從系統特性中識別出簡單功能後，下一步就是對每一個簡單功能使用4-step過程進行測試分析和設計。第IV章將詳細描述。

1. D F-功能交互的測試分析和設計

」F「表明功能交互。

在簡單功能的測試分析和測試設計完成後，怎麼處理簡單功能間的交互關係？咱們可使用下面的4-step過程來作功能交互分析。

注意：在下面表格中用單詞」特徵「來替代」簡單功能「，由於」F「和」Q"部分在特性級別頻繁使用。

Step1：創建模型

• 列出跟所要測試功能有關的遺留功能。他們的關係是「交互」或者「修改」。「交互」覺得遺留功能和被測功能須要共同配合作某些事。「修改」意味着遺留功能由於新增的被測功能須要修改。

• 列出跟被測功能相關的新功能。他們的關係是時間關係（前後運行，或者同時運行），空間關係（使用共同資源例如定時器、內存、或者交互的信息等）或者其餘任何關係。

• 將遺留功能和其餘新功能放到表格的第一行，將測試功能放到第一列

• 將有交互的單元格標誌」X"

Step2：設計基礎測試用例

針對表格中每一個有交互的內容，咱們設計一個或者結果基本測試用例-每一個測試用例清晰描述兩個有交互功能的關係。表格II闡述了這個步驟：

Step3：填充測試數據

識別每一個FIP基本測試用例的變量，而後使用的EP（等價類劃分）和BV（邊界值）得到更多的數據，完成測試用例。

Step4：擴展測試

嘗試基於測試者的經驗獲得更多的測試用例。JamesBach's Heuristic測試方法【12】有很是好的參考文檔。

1.    E Q-質量屬性的測試分析和設計

   Q表明質量屬性.

除了功能測試分析和測試設計，其餘質量屬性也須要考慮。

Step1：建模

• 選擇和定義要測試的產品的相關非功能質量屬性。ISO9126【13】有對質量屬性和子屬性的很是好的定義。

• 將全部的質量屬性寫入表格的一行中，將每一個組件、功能或者特性寫在第一列中。

• 將有交互的地方畫上"x",表示這個組件、功能或者特性須要考慮這個質量屬性。這個分析粒度在這裏不固定，無論是組件級別、功能級別、甚至特性級別均可以。下表是基於功能級別的例子：

Step2：設計基礎測試用例

針對每一個表格每一個交互點，設計一個或者幾個基本測試用例，描述清楚要驗證的質量屬性。

Step3：補充測試數據

找出每一個QCIP基本測試用例中的變量，使用等價類劃分和邊界值獲得更多的數據，完成測試用例。

Step4：拓展測試

嘗試基於測試者的經驗得到更多的測試用例，【12】將頗有幫助。

在」F「和」Q"中使用"表格「做爲模型的好處是它使得測試分析者不會那麼容易忘記一些測試的相關點。

這個章節主要將MFQ框架。「表格」用來描繪功能交互和質量屬性的測試分析模型。可是針對簡單功能測試分析，模型的類型會是不一樣的，下一章節會講到這個。

IV PPDCS-選擇合適的測試技術來建模

1. A PPDCS介紹

就像上面說的，4-step過程在每一個M，F和Q測試分析和測試設計過程都會用到。在4個過程當中，step1是關於測試分析的，也是最重要的步驟的。在F和Q部分，step1比較簡單就是用表格做爲模型。可是M部分，step1多是大多數測試分析者認爲最困難的。面對衆多測試設計技術和麪對不一樣特徵的測試對象，測試者常常思考要選擇哪一種技術來創建一個好的模型。

測試設計的關鍵問題是「全部可能的測試用例中哪些子集有最高可能性發現最多的錯誤？」。熟悉如何選擇合適的測試分析模型有助於解決這個問題。這個章節闡述PPDCS方法，是一個在一個或者多個測試技術中選擇的技術。

一方面，當分析不一樣的測試設計技術，能夠發現絕大多數的測試設計技術能夠被歸爲主要的五大類，每類有一個明顯的特色。好比："商業流程圖「技術是處理流程特性的。一般一個過程由不少步驟組成，這個技術可使用活動圖表或者流圖來表示整個過程。

另外一方面，當分析不一樣的測試對象（常常經過需求規格說明書），能夠發現測試對象有類似的特性。例如，關於ATM機器的規格會描述關於取錢的整個情形，「從插入銀行卡，數據校驗，檢查密碼，處理傳輸，退卡」。因此這種規格一樣也是處理流程的特性。

當這兩個特性匹配，測試分析者可使用特定的測試設計技術來爲這個規則建模。這就是PPDCS最先的想法，每一個字母表明一個特定的特性。第一個字母「P」是「流程」的意思，第二個字母「P」是「參數」的意思，第三個字母「D」是「數據」的意思，第四個字母「C」是「組合」的意思，最後一個字母」S「是」狀態」的意思。這些每個特性和簡單功能的基於模型的測試分析和設計在論文的接下去部分會詳細講述。

1. B P-Process （P流程）

   1）應用條件

若是在測試對象的設計規範中有存在相關「流程」的特徵，「P-Process」方法能夠用來建模。

流程的特徵包括：

• 不少步驟構成一個流程，且步驟之間有順序關係

• 涉及超過一個角色或者觸發條件

  P-Process特徵的設計規範常常包括一系列的步驟或者用戶場景。
   2）應用步驟

Step1：建模

「P-Process」特性可用流圖或者活動流圖，使用「商用流程圖【2]"測試技術。

在建模過程當中，測試分析者須要跟產品設計者頻繁交流。任何該流程中可能異常的分支都必須被考慮到。測試分析者要確保設計規格書已經被模型準確描述。若是流圖已經在測試規格文檔說明了，測試分析者須要仔細地審查甚至從新描繪它，由於建模的過程對徹底理解整個測試對象頗有幫助。下面流圖使用"取錢"功能做爲例子。

Step2：設計基礎測試用例

使用基礎測試用例有兩種方法能夠覆蓋模型。一種方法是流圖比較簡單的狀況，設計基礎用例來覆蓋流圖的每一個路徑。另外一種方式是當流圖很複雜的時候，設計基礎用例覆蓋「主要流程+重要的二選一流程」。每條路徑或者流程都是使用一個基礎用例表示。

   ATM取錢的簡單功能的基礎用例以下表：

Step3：補充測試數據

針對每一個基礎測試用例，識別相關的變量，經過等價類劃分和邊界值增長更多的測試數據，得到最終的可執行性測試用例。

Step4：拓展測試

有其餘流程的可能性？除了流圖顯示的，還有其餘須要的考慮的嗎？

1. C. P參數

   1）應用條件

若是在測試對象的設計規格中存在「變量或者參數」含義的特性，「P-Parameter」方法能夠用來建模。

「參數」特性包括：

• 設計規格中沒有明顯地流程，可是涉及「不少參數」。

• 設計規格中包含不少規則，每條規則有不少不一樣的變量和不一樣的值組成。

• 參數的數量是有限的。測試分析者能夠容易地識別參數間的邏輯關係。

   2）應用步驟

Step1：建模

帶有「P參數」特性的測試對象可使用表格、樹圖和座標圖建模，可參看決策表、決策樹或域測試【2】測試技術。

Step2：設計基礎測試用例

使用基礎測試用例覆蓋模型有兩種方法。一種是100%規則覆蓋，例如爲決策表的每條規則設計一個基礎用例。在決策表較簡單的狀況下（沒有涉及太多參數），這個方法頗有效。另一種方法是，轉換決策表到決策樹，爲樹的每一個葉設計一個基礎用例。這個方法在決策表比較複雜的時候有效。將決策錶轉換爲決策樹的另外一個好處是在轉換過程當中能夠比較容易地發現遺留或者錯誤的需求。

當在一個決策裏包含不少條件的時候，ECT【2】（初級對照決策覆蓋）能夠被用來生成基礎測試用例。

Step3：填充測試數據

針對每一個基礎測試用例，識別相關的變量，使用等價類劃分和邊界值填充數據。

   Step4：拓展測試

基於經驗補充特殊的測試用例。

1. D. D-數據

   1）應用條件

若是在測試對象的設計規範中存在「數據」特徵，「D-數據」方法能夠用來建模。

「數據」特性包括：

• 每一個數據有它特殊的範圍值

• 跟」參數「不同，數據之間沒有明顯的」規則「或者邏輯關係

• 不一樣的數據的範圍可能存在限制

• 涉及的數據個數是有限的

例如，在這樣規格描述「當建造建築物的時候，一個房間最多4個窗戶」，能夠識別2種數據，就是「房間數量」和「窗戶數量」。

   2）應用步驟

Step1: 建模

帶有「D-數據」特徵的測試對象可使用表格建模，等價類劃分和邊界值測試技術能夠提供幫助。

Step2：設計基礎測試用例

設計基礎測試用例覆蓋每一個有效和無效地組，同時考慮有效邊界值和無效邊界值。

Step3：補充測試數據

針對每一個測試用例，針對每一個數據標識特定的值。

Step4：拓展測試

基於經驗補充特殊的測試用例。

1. E C-組合

   1）應用條件

在「P-過程」和「D-數據」的案例中，若是參數或者數據的數量太多以至很難手工列出來，「C-組合」方法能夠用上。

   "組合「特性包括：

• 存在大量的參數（數據）

• 每一個參數有不少值

• 參數之間可能存在一些邏輯關係

   2）應用步驟

Step1：建模

」C-組合「可使用因子狀態表，組合測試【2】或者正交測試技術能夠參考。

例如，給定四個因素，測試全部組合須要72個測試用例。咱們能夠經過確保每一個因素的每一個值和其餘任何一個值的組合至少被測試過一次的方法來減小測試用例數量同時儘量帶來的風險。

Step2：設計基礎用例

在http://www.pairwise.org/tools.asp站點裏有不少關於結對測試的工具。其中，PICT是一款很是好用的工具。

使用PICT設計基礎用例的的過程，就是使用PICT特殊的」語言「造成的表格。一旦咱們定義這些規則，咱們能夠在DOS環境下運行這些腳本。全部的基礎測試用例自動生成。

舉例說明，在」model_test.txt"文件中定義了下面的規則：

      Factor A：A1，A2

      Factor B：B1，B2，B3

      Factor C：C1，C2，C3，C4

      Factor D：D1，D2，D3

當咱們執行下面命令：

      C:\>pict model_test.txt > output.xls

下面12個基礎測試用例會被自動保存在output.xls中：

這12個組合就是咱們所須要測試的確保每一個因子的每一個值都至少跟其餘因子的值組合測試過一次。

Step3：補充測試數據

針對每一個基礎測試用例，爲涉及到的每一個參數定義一個值。例如，若是「A1"表明」>50"，那麼用60代替。

Step4：拓展測試

基於經驗補充特殊的測試用例。

1. F S-State

   1) 應用條件

若是測試對象的設計規格中存在」狀態「特徵，」S-狀態「方法能夠被用來建模。

」狀態「的特性包括：

• 測試對象的行爲變化基於它內部的狀態

• 肯定的事件觸發測試對象的狀態

   2）應用步驟

Step1：建模

」S-狀態「能夠經過」狀態圖「建模，可參看」基於狀態測試「的技術。

在一個狀態圖中，狀態能夠經過節點表示，事件能夠經過鏈接節點的弧表示。

建模步驟以下：

• 從規格中識別行爲對象

• 對這些行爲對象肯定全部可能的狀態

• 對每一個狀態，畫出節點

• 識別全部在狀態之間的節點傳輸

• 針對每一個傳輸，肯定觸發的事件

• 針對每一個事件，畫出相關節點的連接

Step2：設計基礎用例

不少方法能夠用來設計基礎用例覆蓋狀態圖。其中之一就是Chow的方法【10】

   TableXI列舉了用Chow's的0-Switch的覆蓋方法針對上圖生成的基礎測試用例。TableXII列舉了使用Chow的1-Switch覆蓋方法的基礎測試用例。注意，基礎測試用例的增長是考慮單個傳輸仍是成對的傳輸路徑。

Step3:補充測試數據

針對每一個基礎數據，咱們識別涉及的相關變量而後經過等價類劃分和邊界值定義測試數據。這個結果在每一個抽象的測試用例裏能夠被擴展成一個或者多個可執行的具體測試用例。

Step4：拓展測試

基於經驗補充特殊的測試用例。

這個章節講述的是關於PPDCS方法。簡單功能的測試分析和測試設計，第一件事就是識別簡單功能（或稱爲單元或組件）的數目。針對每一個簡單功能，須要哪一種測試分析：經過PPDCS方法建模，設計基礎用例來覆蓋模型，針對每一個測試用例補充更多的測試數據，而後經過基於經驗設計其餘的測試用例。

1. V 結果

在華爲，一些實驗性質的項目開發者被教導使用MFQ&PPDCS方法。表格XIII在產品的一個特性使用傳統設計方法和使用PPDCS方法比較了M 部分（MFQ框架的簡單功能部分）的結果。
開發人員使用傳統的測試方法（主要是基於經驗的測試方法）設計了86個測試用例。因爲在測試用例設計過程以前沒有明顯的測試分析過程，該特性的2個部件在開發人員設計測試用例過程被忽視了。（識別簡單功能的數量的步驟沒有施行好）。運行這86個用例後，只有1個缺陷被檢測出來。

爲了比較傳統測試設計方法和PPDCS的新的測試方法的效用，一個新的測試者被指派從新使用PPDCS方法來進行這個特性的設計。結果是，設計了102個測試用例。4個部件所有被識別到，並且該特性的更多功能點被測試用例覆蓋。測試分析和測試設計過程結束後，即使那個時候尚未測試用例執行，已經檢測到5個缺陷。

結論：

• 開發人員能夠很快學會，而後在PPDCS的幫助下，單元測試分析和測試設計作得很好，即便以前只有一點點的測試設計知識基礎。

• 不少潛在的缺陷在建模階段就被發現和預防了，而傳統的測試須要測試者在軟件實現完成之後發現。這是由於建模的過程同時也是測試分析的過程，測試規範一般在測試分析階段會被審查一遍，而後潛在問題在早期就被發現。

• 由於PPDCS是黑盒測試方法，當結合白盒測試方法（例如：經過白盒測試技術好比狀態覆蓋、分支覆蓋、路徑覆蓋等等來補充測試用例），能夠得到更好的覆蓋率。

• 開發人員能夠很容易將測試分析過程合併到軟件分析過程，使得軟件設計更加完善。

1. VI 總結

綜上所述，針對大型嵌入式軟件系統的測試分析和測試設計過程是：

• 在低級別的測試，好比單元測試，簡單功能（「M」Part）要完全測試。在高級測試級別，好比系統測試、功能交互（「F」part）和質量屬性（「Q」部分）須要完全地測試。而後，這並非絕對的。

• 在每一個M,F或者Q部分，4-step測試分析和測試設計過程須要使用到。

• 針對M部分，咱們從測試對象分解未特性和獨立的功能開始。咱們使用PPDCS框架幫助咱們選擇合適的規格技術來對每一個功能建模。

• 針對F和Q部分，功能交互表格用來建模。James Bach的啓發式測試策略模型是這個的有用補充。