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. 背景知識
A 大型嵌入式軟件系統的特點
如今，嵌入式軟件佔據軟件的很大一部分比例。例如在日本，“嵌入式軟件佔據軟件行業的很大比例，主要是因爲很多大公司生產電子、汽車等。”
對比傳統的胖客戶端或者給予瀏覽器的桌面應用軟件，大型嵌入式軟件系統有下面特點：
大量和複雜的功能：典型產品的代碼量大小經常達到百萬行，包括每個版本的新特性，涉及軟件和硬件功能，包括O&M（操作和維護）和服務處理模塊等等。
大量的功能交互：因爲嵌入式軟件經常運行在實時操作系統上，任何一個功能在任何時刻可能被其他事件所影響，例如被其他正在運行的功能模塊，定時的任務，非預期的時間（例如交換和重置某些硬件）
非常嚴格的質量要求：除了追求準確的高質量功能特性，嵌入式軟件還要提供高質量的非功能性特性，包括可靠性，可擴展性，靈活性和健壯性等等。
高質量的要求使得測試者的角色尤其重要，軟件系統的複雜性也讓測試工作變得很有挑戰。
B 測試分析和設計的問題調查
通常情況下，編碼後開發人員會在提交產品給測試人員前進行低級別測試（LLT：Low Level Test），一般包括單元測試（UT：Unit Test）和集成測試（IT：Integration Test）等，提交後，測試人員採用高級別測試（HLT：High Level Test）例如系統測試。LLT在單一功能上關注很多，而HLT主要關注功能交互和質量屬性特點。LLT階段和HLT階段要測試的內容以及這兩個測試階段的負責人明顯是不同的。
簡單功能的測試設計，儘管開發或者測試已經做了，但是效果很差，因爲對如何應用測試設計技術比如等價類劃分、邊界值、決策表等理解不夠透徹。可能是因爲在這些技術上缺乏足夠的培訓，即使有一些培訓，這些培訓經常都是一次聚焦於一兩個技術，而且這些培訓課程涉及的案例都太簡單了。所有這些因素使得測試規範技術的使用變得困難。真實場景是，人們經常依賴自己的經驗來做測試設計，所以測試用例集離完整性和有效性還差很遠。
另外一個測試設計的問題是功能交互點和非功能質量特徵在測試分析的時候沒有被很好的考慮。基於經驗的測試設計過分依賴人們的測試經驗不容易將要測試的功能交互要點和質量屬性考慮全面。
C 論文的內容
該論文試圖針對大型嵌入式軟件系統，提出一種基於新的建模方法和測試分析設計框架，通過系統化和層次化的方法，快速選擇合適的測試規範技術來高效地創建測試分析模型，達到相對有效和完整的測試用例，提供一種指南。
這篇論文的組織如下：
第I章講述一些背景信息；
第II章澄清測試分析和測試設計的概念
第III章提出針對大型嵌入式軟件系統的MFQ框架
第IV章提出幫助選擇測試規範技術的指南PPDCS方法
II. 測試分析和測試設計
A 不同的觀點
我們經常稱“測試分析和設計”，一定程度上，混淆了“測試分析”和“測試設計”。因爲最後測試用例是測試設計活動的直接結果而不是測試分析活動的結果，測試分析傾向於忽略測試分析活動的重要性。
MikeSmith指出“人們傾向於參考‘測試分析和設計活動’。我更傾向於主張測試分析和測試設計作爲不同的活動，引出不同組織結構的工作作品。這個更好的反映存在的需求和已經實施的系統之間的複雜邏輯的自然聯繫。”Mike Smith認爲“測試分析”解決“是什麼”。比如測試的目標和方法是什麼？他認爲“測試設計”解決“怎麼做”，例如這些方法和目標怎麼實現。
另一個觀點，Torbjorn Ryber將測試簡化爲“一個持續問問題的過程”，就像圖1. 從這個模型可以推導出“測試分析”實際上是“怎麼做---我怎麼問問題？”，“測試設計”實際上是“是什麼--我要問什麼問題？”
實際上，兩個觀點都強調測試分析活動的重要性。接下來就是怎麼做測試分析的問題了。
B 測試分析和模型
在早期的測試中，測試設計過程基本上就像“需求/規格-->測試用例”。也就是說，測試分析從需求/規格文檔，大部分基於測試經驗直接生成測試用例。
後來，人們開始學習特定特定的測試規範技術來設計測試用例，例如EP（等價類劃分），BV（邊界值），決策表等。這些測試規範技術更像工具，方法或者測試者得到最後用例的途徑。測試分析和測試設計活動並沒有明顯地區分。也可以說，測試分析和測試設計活動是並行的。當一個完成了，另一個也跟着結束了。測試設計過程更像是“需求/規格-->測試分析和測試設計-->測試用例”。
當被測軟件變得越來越複雜，越多的測試分析工作需要在完成最後測試用例的時候完成。例如，對於大型嵌入式通信軟件系統，測試分析師不得不努力將他們精力投向學習測試對象，描繪整個圖，將測試對象分解到很多小組件使得每個組件都足夠小到可以設計，然後分析使用不同的規範技術測試各個組件。在所有這些分析工作結束後，測試用例設計工作開始。因此，測試設計過程變成“需求/規範-->測試分析-->測試設計-->測試用例“。
毋庸置疑，一個有創造性和經驗豐富的測試者做測試分析工作會比普通測試者做得好，因爲“分析”是一種可以通過工作經驗獲得的能力。然而，並不是說“分析能力”是不能通過確定的方法和理論獲得和加強的。實際上，基於模型的測試對幫助提高改進測試分析工作的質量有很大的幫助。Torbjorn Ryber這樣定義模型:“我們的模型可以是描述系統如何工作的表格形式，流程圖或者其他圖表。”它就像是通過地圖展示一座城市；測試對象也可以通過模型展現出來。模型可以通過一種抽象和簡單的方法顯示測試對象的內在聯繫。實際上，建立模型的過程就是測試分析的過程。
實踐證明，使用模型做測試分析至少有三個好處：
通過建模的這個過程，測試分析者變得越來越熟悉測試對象，很多早期對測試對象的懷疑也變得清晰了。在建模的過程中，很多在需求描述出現的不確定問題，測試分析者要不斷同軟件設計者交流來找到這些問題的答案。因此，很多潛在的問題會在他們被真正成爲缺陷之前被發現。這就是預防bug而不是發現bug的活動。
基於更容易的理解特性的原因，模型是作爲測試者和設計者，以及測試設計作者和他們的評審者的很好的媒介。
模型通常很容易被測試用例覆蓋。通過圖形的知識展現，測試者總是更容易從模型派生用例的方法，結果是模型覆蓋的測試設計方法比傳統的基於經驗測試設計方法更好。
下面章節將介紹基於模型的測試分析和測試設計技術--MFQ&PPDCS
III MFQ-測試分析和測試設計框架
A MFQ介紹
就如上面提到的大型嵌入式軟件系統有三個明顯的特徵：多和複雜的功能，數量衆多的功能交互，高質量特性要求，相應地，大型嵌入式軟件系統的MFQ測試分析和設計框架包括三個部分：M-基於模型的簡單功能測試分析和設計；F-功能交互測試分析和設計；Q-質量屬性測試分析和設計。
針對上述3個部分的每個部分，基於4-step模型的測試分析和測試方法都會用到，詳細內容在B章節介紹。
上述的三個部分可以被用在任何測試級別（單元測試、集成測試、或者系統測試），但是下面是一些有用的建議：
在單元測試或者組件測試級別，第一個部分“M-基於模型的簡單功能測試分析和設計”始終都應該使用。目的是保證獨立的單個功能在集成到其他組件進行高級別測試之前已經被完全測試。
在系統測試級別，第二部分F和第三部分Q應該儘可能使用。這是保證整個系統的功能準確性和質量屬性。
在低級別測試應用M和Q取決於項目和人力技術技能的情況，一些質量屬性在項目中可以被提早驗證。例如，健壯性是組件測試非常重要的部分。
當測試軟件從低級別測試轉向高級別測試的時候（通常是從開發團隊到測試團隊），測試者驗證基本功能測試已經完成。因此，第一部分M在高級別測試也需要。
B 4-step測試分析和測試設計過程
MFQ框架使用4-step 測試分析和測試設計過程，詳細資料可以在參考文獻【2】中找到。這裏簡單介紹一下。
Step1：爲測試對象建模
成功測試的關鍵在於好的分析模型，但是好的模型建立在對測試對象的熟悉程度的基礎上。這在大型嵌入式軟件系統尤其適用，因爲商業公司背景知識永遠是好的測試分析和設計工作的基礎。所以在做任何測試分析的第一個步驟是收集關於測試對象的足夠多的信息，從而獲得對產品更深的瞭解。這些信息可以是手邊的所有設計文檔，例如特性設計規格，軟件規格說明書，高級別設計規格和低級別設計規格等等。在對測試對象有一個充分的瞭解後，測試分析者可以嘗試選擇一個合適的模型來描繪測試對象。有很多流行有效的測試規範技術例如等價類劃分、邊界值，決策表，業務流程圖、基於狀態的測試等等，測試分析者常常發現在建模的時候面對很多的選擇，他們很快陷入不知道選擇哪個的情形。很多模型可用被用來描繪一個測試對象，但是經常情況下只有其中一種最適合我們使用。PPDCS在下一個章節就是要解決這個問題的構想。
Step2: 設計基礎測試用例（有時候叫做合邏輯的或者抽象的測試用例）來覆蓋這個模型
所謂的基礎測試用例指的是比較泛的用例，在測試用例中沒有測試數據的值。跟傳統一步測試用例生成過程不同，測試用例4-step過程的產生需要兩個步驟：第一設計基礎測試用例，第二針對每個測試用例更多的測試數據來產生最後可執行的測試用例。
設計基礎用例的目的是更好的進行模型覆蓋。不同的模型有不同的測試覆蓋方法。最近幾年，很多學者在研究根據確定的生成規則或者算法自動生成測試用例的基於模型的測試。這篇論文更多地關注建模過程和觀察從模型手動生成用例的過程,因爲在我經驗中，建模的工作花費較多時間，而從模型生成測試用例的過程相對簡單且不耗時。
此外，在該篇論文中，"模型“的概念是廣義的，例如，一個模型不一定得是通過UML或者其他確定的語言的表達。實際上，一個模型可以是任何一種表格，圖表，樹等等，只要它能幫助我們清楚地描述測試對象。基於我的經驗，絕大多數的的測試對象可以通過簡單地模型表示。我認爲在大多數場景下，測試規範技術不需要非常複雜。在人們爲特定的測試對象開始測試設計的過程如果需要一個很難學習的測試規範技術，我認爲這個對象的系統設計或者需求設計需要重來。
Step3：考慮測試數據的變化來敲定測試用例（有時叫做具體的測試用例）
如果第一步驟是用模型覆蓋需求，那麼第二步是用基本測試用例覆蓋模型，然後第3步是用測試數據覆蓋每個基本測試用例。有一些測試數據在基本的測試用例已經包括，所以第一件事要做的是識別出測試數據，然後第二件事要做的是考慮測試數據的變化，比如使用等價類劃分和邊界值。（備註：等價類和邊界值有點特殊因爲他們也可以用在第1步驟的建模）。針對每個測試數據的變化，設計一個測試用例。第3步以後，最後可執行的用例已經完成。
Step4：進一步測試
沒有一種類型的模型可以有效地描述測試對象的所有方面。儘管上面三個步驟已經使用，仍然會存在測試對象的一些其他方面需要測試。例如，一些特殊的規格變量限制關係很難放進模型，所以需要另外一個分開的測試設計。另一方面是，人們的經驗，測試分析者對測試對象有他們自己的理解，而且很難放到模型中，所以更進一步的測試設計過程是需要的。
好的測試=正式的測試+非正式的測試。前面三個步驟是正式測試過程，最後的步驟“高級測試”是非正式的測試過程。實際上，非正式測試並不意味着沒有任何規則可遵循的隨機測試。有很多成熟的非正式測試的方法，比如基於錯誤的測試，探索性測試等等，這些測試不在這篇文章詳細展開。
C M-基於模型的簡單功能測試分析和設計
上述“基於4-step模型的測試設計過程"是最適合簡單功能測試設計的，因爲簡單功能的合適粒度，所以這部分用M（Model)表示。
在爲簡單功能測試設計和分析應用4-step過程中，首要做的是將測試對象分爲不同的”簡單功能“（單元或者組件）。根據我的經驗，一個簡單功能的可以是幾十行到幾百行代碼的大小，但是最好不要超過一千行。一個簡單的功能在單元測試裏可以對應1個或者幾個組件，或者1個或幾個SRS的需求，或者一個或者兩個用戶場景。沒有明確的規則規定那個文檔需要被引用，那個需求或者規格需要對應一個簡單功能。因此，測試分析者需要收集足夠多的材料來做測試分析來識別需要測試的合適的簡單功能。
在面向對象的程序裏，簡單功能可能相對比較容易識別。一個對象負責實現的方法（成員函數）或者一個類可以被看成整個系統的一個簡單功能。但是在其他語言，例如C語言，識別簡單功能不是那麼容易。通常情況下，一個簡單功能擁有兩個特徵：
從需求的角度看，一個簡單功能是相對獨立的。一個軟件系統由很多特性組成，一個簡單的特性可以分解爲很多分開的功能。
從實現的角度看，內在邏輯和簡單功能是相干的。例如，一個對象的行爲可能通過很多方法（很多功能）實現，一個方法可能包含很多步驟。
同Bill Wake描述的的用戶故事的INVEST模型類似，一個簡單功能應該是獨立的、可測試的、有價值的（實現特定功能）、比較大的（根據上下文情況，沒有固定的大小）、可調整的（簡單功能的分發可以適應測試分析和測試設計的活動的調整）
從系統特性中識別出簡單功能後，下一步就是對每個簡單功能使用4-step過程進行測試分析和設計。第IV章將詳細描述。
D F-功能交互的測試分析和設計
”F“代表功能交互。
在簡單功能的測試分析和測試設計完成後，怎麼處理簡單功能間的交互關係？我們可以使用下面的4-step過程來做功能交互分析。
注意：在下面表格中用單詞”特徵“來替代”簡單功能“，因爲”F“和”Q"部分在特性級別頻繁使用。
Step1：建立模型
列出跟所要測試功能有關的遺留功能。他們的關係是“交互”或者“修改”。“交互”以爲遺留功能和被測功能需要共同配合做某些事。“修改”意味着遺留功能因爲新增的被測功能需要修改。
列出跟被測功能相關的新功能。他們的關係是時間關係（先後運行，或者同時運行），空間關係（使用共同資源例如定時器、內存、或者交互的信息等）或者其他任何關係。
將遺留功能和其他新功能放到表格的第一行，將測試功能放到第一列
將有交互的單元格標誌”X"
Step2：設計基礎測試用例
針對表格中每個有交互的內容，我們設計一個或者結果基本測試用例-每個測試用例清晰描述兩個有交互功能的關係。表格II闡述了這個步驟：
Step3：填充測試數據
識別每個FIP基本測試用例的變量，然後使用的EP（等價類劃分）和BV（邊界值）獲得更多的數據，完成測試用例。
Step4：擴展測試
嘗試基於測試者的經驗得到更多的測試用例。JamesBach's Heuristic測試方法【12】有非常好的參考文檔。
E Q-質量屬性的測試分析和設計
Q代表質量屬性.
除了功能測試分析和測試設計，其他質量屬性也需要考慮。
Step1：建模
選擇和定義要測試的產品的相關非功能質量屬性。ISO9126【13】有對質量屬性和子屬性的非常好的定義。
將所有的質量屬性寫入表格的一行中，將每個組件、功能或者特性寫在第一列中。
將有交互的地方畫上"x",表示這個組件、功能或者特性需要考慮這個質量屬性。這個分析粒度在這裏不固定，不管是組件級別、功能級別、甚至特性級別都可以。下表是基於功能級別的例子：
Step2：設計基礎測試用例
針對每個表格每個交互點，設計一個或者幾個基本測試用例，描述清楚要驗證的質量屬性。
Step3：補充測試數據
找出每個QCIP基本測試用例中的變量，使用等價類劃分和邊界值得到更多的數據，完成測試用例。
Step4：拓展測試
嘗試基於測試者的經驗獲得更多的測試用例，【12】將很有幫助。
在”F“和”Q"中使用"表格“作爲模型的好處是它使得測試分析者不會那麼容易忘記一些測試的相關點。
這個章節主要將MFQ框架。“表格”用來描繪功能交互和質量屬性的測試分析模型。但是針對簡單功能測試分析，模型的類型會是不同的，下一章節會講到這個。
IV PPDCS-選擇合適的測試技術來建模
A PPDCS介紹
就像上面說的，4-step過程在每個M，F和Q測試分析和測試設計過程都會用到。在4個過程中，step1是關於測試分析的，也是最重要的步驟的。在F和Q部分，step1比較簡單就是用表格作爲模型。但是M部分，step1可能是大多數測試分析者認爲最困難的。面對衆多測試設計技術和麪對不同特徵的測試對象，測試者經常思考要選擇哪種技術來建立一個好的模型。
測試設計的關鍵問題是“所有可能的測試用例中哪些子集有最高可能性發現最多的錯誤？”。熟悉如何選擇合適的測試分析模型有助於解決這個問題。這個章節闡述PPDCS方法，是一個在一個或者多個測試技術中選擇的技術。
一方面，當分析不同的測試設計技術，可以發現絕大多數的測試設計技術可以被歸爲主要的五大類，每類有一個明顯的特點。比如："商業流程圖“技術是處理流程特性的。通常一個過程由很多步驟組成，這個技術可以使用活動圖表或者流圖來表示整個過程。
另一方面，當分析不同的測試對象（經常通過需求規格說明書），可以發現測試對象有相似的特性。例如，關於ATM機器的規格會描述關於取錢的整個情形，“從插入銀行卡，數據校驗，檢查密碼，處理傳輸，退卡”。所以這種規格同樣也是處理流程的特性。
當這兩個特性匹配，測試分析者可以使用特定的測試設計技術來爲這個規則建模。這就是PPDCS最早的想法，每個字母代表一個特定的特性。第一個字母“P”是“流程”的意思，第二個字母“P”是“參數”的意思，第三個字母“D”是“數據”的意思，第四個字母“C”是“組合”的意思，最後一個字母”S“是”狀態”的意思。這些每一個特性和簡單功能的基於模型的測試分析和設計在論文的接下去部分會詳細講述。
B P-Process （P流程）
1）應用條件
如果在測試對象的設計規範中有存在相關“流程”的特徵，“P-Process”方法可以用來建模。
流程的特徵包括：
很多步驟構成一個流程，且步驟之間有順序關係
涉及超過一個角色或者觸發條件
P-Process特徵的設計規範經常包括一系列的步驟或者用戶場景。
2）應用步驟
Step1：建模
“P-Process”特性可用流圖或者活動流圖，使用“商用流程圖【2]"測試技術。
在建模過程中，測試分析者需要跟產品設計者頻繁交流。任何該流程中可能異常的分支都必須被考慮到。測試分析者要確保設計規格書已經被模型準確描述。如果流圖已經在測試規格文檔說明了，測試分析者需要仔細地審查甚至重新描繪它，因爲建模的過程對完全理解整個測試對象很有幫助。下面流圖使用"取錢"功能作爲例子。
Step2：設計基礎測試用例
使用基礎測試用例有兩種方法可以覆蓋模型。一種方法是流圖比較簡單的情況，設計基礎用例來覆蓋流圖的每個路徑。另一種方式是當流圖很複雜的時候，設計基礎用例覆蓋“主要流程+重要的二選一流程”。每條路徑或者流程都是使用一個基礎用例表示。
ATM取錢的簡單功能的基礎用例如下表：
Step3：補充測試數據
針對每個基礎測試用例，識別相關的變量，通過等價類劃分和邊界值增加更多的測試數據，獲得最終的可執行性測試用例。
Step4：拓展測試
有其他流程的可能性？除了流圖顯示的，還有其他需要的考慮的嗎？
C. P參數
1）應用條件
如果在測試對象的設計規格中存在“變量或者參數”含義的特性，“P-Parameter”方法可以用來建模。
“參數”特性包括：
設計規格中沒有明顯地流程，但是涉及“很多參數”。
設計規格中包含很多規則，每條規則有很多不同的變量和不同的值組成。
參數的數量是有限的。測試分析者可以容易地識別參數間的邏輯關係。
2）應用步驟
Step1：建模
帶有“P參數”特性的測試對象可以使用表格、樹圖和座標圖建模，可參看決策表、決策樹或域測試【2】測試技術。
Step2：設計基礎測試用例
使用基礎測試用例覆蓋模型有兩種方法。一種是100%規則覆蓋，例如爲決策表的每條規則設計一個基礎用例。在決策表較簡單的情況下（沒有涉及太多參數），這個方法很有效。另外一種方法是，轉換決策表到決策樹，爲樹的每個葉設計一個基礎用例。這個方法在決策表比較複雜的時候有效。將決策錶轉換爲決策樹的另一個好處是在轉換過程中可以比較容易地發現遺留或者錯誤的需求。
當在一個決策裏包含很多條件的時候，ECT【2】（初級對照決策覆蓋）可以被用來生成基礎測試用例。
Step3：填充測試數據
針對每個基礎測試用例，識別相關的變量，使用等價類劃分和邊界值填充數據。
Step4：拓展測試
基於經驗補充特殊的測試用例。
D. D-數據
1）應用條件
如果在測試對象的設計規範中存在“數據”特徵，“D-數據”方法可以用來建模。
“數據”特性包括：
每個數據有它特殊的範圍值
跟”參數“不一樣，數據之間沒有明顯的”規則“或者邏輯關係
不同的數據的範圍可能存在限制
涉及的數據個數是有限的
例如，在這樣規格描述“當建造建築物的時候，一個房間最多4個窗戶”，可以識別2種數據，就是“房間數量”和“窗戶數量”。
2）應用步驟
Step1: 建模
帶有“D-數據”特徵的測試對象可以使用表格建模，等價類劃分和邊界值測試技術可以提供幫助。
Step2：設計基礎測試用例
設計基礎測試用例覆蓋每個有效和無效地組，同時考慮有效邊界值和無效邊界值。
Step3：補充測試數據
針對每個測試用例，針對每個數據標識特定的值。
Step4：拓展測試
基於經驗補充特殊的測試用例。
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：拓展測試
基於經驗補充特殊的測試用例。
F S-State
1) 應用條件
如果測試對象的設計規格中存在”狀態“特徵，”S-狀態“方法可以被用來建模。
”狀態“的特性包括：
測試對象的行爲變化基於它內部的狀態
確定的事件觸發測試對象的狀態
2）應用步驟
Step1：建模
”S-狀態“可以通過”狀態圖“建模，可參看”基於狀態測試“的技術。
在一個狀態圖中，狀態可以通過節點表示，事件可以通過連接節點的弧表示。
建模步驟如下：
從規格中識別行爲對象
對這些行爲對象確定所有可能的狀態
對每個狀態，畫出節點
識別所有在狀態之間的節點傳輸
針對每個傳輸，確定觸發的事件
針對每個事件，畫出相關節點的鏈接
Step2：設計基礎用例
很多方法可以用來設計基礎用例覆蓋狀態圖。其中之一就是Chow的方法【10】
TableXI列舉了用Chow's的0-Switch的覆蓋方法針對上圖生成的基礎測試用例。TableXII列舉了使用Chow的1-Switch覆蓋方法的基礎測試用例。注意，基礎測試用例的增加是考慮單個傳輸還是成對的傳輸路徑。
Step3:補充測試數據
針對每個基礎數據，我們識別涉及的相關變量然後通過等價類劃分和邊界值定義測試數據。這個結果在每個抽象的測試用例裏可以被擴展成一個或者多個可執行的具體測試用例。
Step4：拓展測試
基於經驗補充特殊的測試用例。
這個章節講述的是關於PPDCS方法。簡單功能的測試分析和測試設計，第一件事就是識別簡單功能（或稱爲單元或組件）的數目。針對每個簡單功能，需要哪種測試分析：通過PPDCS方法建模，設計基礎用例來覆蓋模型，針對每個測試用例補充更多的測試數據，然後通過基於經驗設計其他的測試用例。
V 結果
在華爲，一些實驗性質的項目開發者被教導使用MFQ&PPDCS方法。表格XIII在產品的一個特性使用傳統設計方法和使用PPDCS方法比較了M 部分（MFQ框架的簡單功能部分）的結果。
開發人員使用傳統的測試方法（主要是基於經驗的測試方法）設計了86個測試用例。由於在測試用例設計過程之前沒有明顯的測試分析過程，該特性的2個部件在開發人員設計測試用例過程被忽視了。（識別簡單功能的數量的步驟沒有施行好）。運行這86個用例後，只有1個缺陷被檢測出來。
爲了比較傳統測試設計方法和PPDCS的新的測試方法的效用，一個新的測試者被指派重新使用PPDCS方法來進行這個特性的設計。結果是，設計了102個測試用例。4個部件全部被識別到，而且該特性的更多功能點被測試用例覆蓋。測試分析和測試設計過程結束後，即便那個時候還沒有測試用例執行，已經檢測到5個缺陷。
結論：
開發人員可以很快學會，然後在PPDCS的幫助下，單元測試分析和測試設計做得很好，即使之前只有一點點的測試設計知識基礎。
很多潛在的缺陷在建模階段就被發現和預防了，而傳統的測試需要測試者在軟件實現完成以後發現。這是因爲建模的過程同時也是測試分析的過程，測試規範通常在測試分析階段會被審查一遍，然後潛在問題在早期就被發現。
因爲PPDCS是黑盒測試方法，當結合白盒測試方法（例如：通過白盒測試技術比如狀態覆蓋、分支覆蓋、路徑覆蓋等等來補充測試用例），可以獲得更好的覆蓋率。
開發人員可以很容易將測試分析過程合併到軟件分析過程，使得軟件設計更加完善。
VI 總結
綜上所述，針對大型嵌入式軟件系統的測試分析和測試設計過程是：
在低級別的測試，比如單元測試，簡單功能（“M”Part）要徹底測試。在高級測試級別，比如系統測試、功能交互（“F”part）和質量屬性（“Q”部分）需要徹底地測試。然後，這並不是絕對的。
在每個M,F或者Q部分，4-step測試分析和測試設計過程需要使用到。
針對M部分，我們從測試對象分解未特性和獨立的功能開始。我們使用PPDCS框架幫助我們選擇合適的規格技術來對每個功能建模。
針對F和Q部分，功能交互表格用來建模。James Bach的啓發式測試策略模型是這個的有用補充。