文 | 趙哲鴻

　　關于MFQ，本文將從以下幾個方面一一道來：

why：為什么要學習MFQ

how：如何在團隊實踐MFQ

What：什么是MFQ

Some thoughtover MFQ：在實踐中的一點感悟

　　乍一看文章的結構，大多數讀者應該會說，這不就是著名的黃金圈法則嘛！的確，在接受一項任務之前，先思考為什么接這項任務，這項任務主要為了解決什么問題，達成什么目標，為了這個目標，我應該怎么去做，最后再由實踐對任務有一個更高層次的認識。整一套流程下來，能使我們事半功倍。下面，先介紹一下為什么學習MFQ。

　　Why

　　對于實踐敏捷開發流程的團隊，要求測試前移，因而對測試的要求更傾向于能夠指導開發的測試設計，而非由開發牽引的測試用例。

　　大部分團隊雖然有測試用例，但測試用例的設計沒有采用結構化的方法，在測試場景、異常場景上經常有欠缺和遺漏，而MFQ正是一種結構化的思維以及建模工具，能靈活應用于實際的項目之中。

　　How

　　談到how的話，不得不說一下MFQ的四部曲，KYM-TCO-MFQ&PPDCS-TCON，下面以一個實際需求來進一步講述這四部曲。

　　需求實例名稱：大數據平臺支持補丁升級功能

四部曲之一：KYM

　　KYM即Kown Your Mission的意思，了解自己的測試對象，對于需求承接者來說，需要從不同的維度去了解、分析需求，在分析過程中，有任何疑問均可以羅列出來。KYM通用的維度可用如下引導詞來標識：CIDTESTD，即Customer、Information、Developer Relations、Test Team、Equipment&Tools、Sheduler、Test Item、Deliverables。依據需求設計的KYM如下圖所示：

四部曲之二：TCO

　　TCO(Testing Coverage Outline)，即從測試的角度對原始需求進行提煉，提煉出對測試有用的測試點，并且對提取出的信息進行重組，識別出需求中的風險，做到對需求心中有數。KYM與TCO均不是一次性過程，并且需要各種角色成員一起梳理，其中TCO中最重要的是要識別出M、F、Q：

M：基于模型的單功能測試分析和設計

F：功能交互測試分析和設計

Q：質量屬性測試分析和設計

　　下面給出上述需求對應的TCO圖：

　　通過團隊成員的共同努力，對單功能和功能交互點進行了劃分，并識別出了后續建模需要用到的DATA屬性，接下來，就要開始實施四部曲中的第三部了。

四部曲之三：建模MFQ&PPDCS

　　通過TCO對需求的整理之后，劃分了單功能和功能交互點，這時，輸出物還只是測試點，不足以支撐整個測試，還需要對具體的單功能使用建模方法，經過分析，一致認為針對M，可以用PPDCS中的P(Process)來進行建模，這里，不使用別的建模方法(Parameter，DATA，Conbination，State)，因為劃分出來的單功能包含多個步驟，且每一個步驟有一定的前后約束關系。下面簡單介紹一下其余四種建模方法的適用場景：

Parameter：需求中或者劃分出來的單功能或者功能交互點有許多參數，且這些參數相互之間有一定的業務規則約束，即某些參數之間組合才能符合需求。

DATA：需求中或者劃分出來的單功能或者功能交互點有許多參數，但是這些參數之間沒有業務規則的約束。

State：需求中或者劃分出來的單功能或者功能交互點涉及多種狀態，且各種狀態之間由于某些業務規則，能夠相互轉換。

　　下面給出對單功能Model的建模圖：

　　在TCO步驟中，已經識別出幾個參數，下面對劃分出來的所有的Function的最末端的測試場景進行DATA方法建模，建模的結果用判定表表示如下圖所示：

　　當建模完畢，生成測試場景之后，需要對測試場景進行語言描述，即given-when-then用例描述方法，也即四部曲的最后一部TCON。

四部曲之四：TCON

　　根據上述的測試場景，生成TCON，用上述判定表的前兩個測試條件轉化，形成的TCON如下圖所示：

　　至此，整個MFQ的流程已經完畢，在這里，再次強調，MFQ需要團隊成員齊心協力，一起完成測試點的梳理，并且，MFQ以及PPDCS不是一次性過程，需要在迭代進行中，針對任務完成情況以及風險點對TCO進行糾正以及完善，后期，還要在測試執行以及自動化用例編寫，探索性測試上面做一些嘗試。

　　What

　　MFQ是邰曉梅提出的一套測試分析和測試設計方法，整個四部曲之間實質上是全貌到細節，整體到部分的關系。它運用啟發思維的方式讓大家從不同的維度對需求進行進一步澄清，從測試的角度重新定義需求，結構化的思維方式輔助圖形化工具使得場景遺漏概率降低。

　　Some thought over MFQ

　　最后，給出筆者關于MFQ的一些思考。

　　MFQ的學習對象不僅僅局限于測試，開發以及需求人員也需要學習，對于開發者，有助于理解需求，在做功能之前想清楚需要怎么做，可能有什么坑，也能及時把握風險，盡量把風險控制在能夠承受的范圍之內。MFQ的推行也需要每個團隊成員的齊心協力。當然MFQ要想做好，本質上也是要求目前的每個團隊成員能力的提升，比如測試，不僅僅只需要測試技能，還需要熟悉業務，了解一定的代碼相關的知識；而對于開發者，也需要具有測試思維，做功能不僅僅局限于只實現基本功能，要多考慮異常場景以及擴展性；而對于需求人員，不僅僅只是對接客戶，要能夠利用自己的專業知識盡最大可能澄清需求，并且能夠指導開發。最后，用敏捷里面提到的思想來作為文章的結尾，QA不是具體的一個人，是一個角色，每個人都要能是QA，只有大家的認識能夠保持一致，MFQ才能發揮最大的效果。