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

　　當被測軟件變得越來越復雜，越多的測試分析工作需要在完成最后測試用例的時候完成。例如，對于大型嵌入式通信軟件系統，測試分析師不得不努力將他們精力投向學習測試對象，描繪整個圖，將測試對象分解到很多小組件使得每個組件都足夠小到可以設計，然后分析使用不同的規范技術測試各個組件。在所有這些分析工作結束后，測試用例設計工作開始。因此，測試設計過程變成“需求/規范–>測試分析–>測試設計–>測試用例“。

　　毋庸置疑，一個有創造性和經驗豐富的測試者做測試分析工作會比普通測試者做得好，因為“分析”是一種可以通過工作經驗獲得的能力。然而，并不是說“分析能力”是不能通過確定的方法和理論獲得和加強的。實際上，基于模型的測試對幫助提高改進測試分析工作的質量有很大的幫助。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步以后，最后可執行的用例已經完成。

原文轉自：http://hejiajie.cn/archives/472