文 | 趙哲鴻

　　關(guān)于MFQ，本文將從以下幾個(gè)方面一一道來：

why：為什么要學(xué)習(xí)MFQ

how：如何在團(tuán)隊(duì)實(shí)踐MFQ

What：什么是MFQ

Some thoughtover MFQ：在實(shí)踐中的一點(diǎn)感悟

　　乍一看文章的結(jié)構(gòu)，大多數(shù)讀者應(yīng)該會說，這不就是著名的黃金圈法則嘛！的確，在接受一項(xiàng)任務(wù)之前，先思考為什么接這項(xiàng)任務(wù)，這項(xiàng)任務(wù)主要為了解決什么問題，達(dá)成什么目標(biāo)，為了這個(gè)目標(biāo)，我應(yīng)該怎么去做，最后再由實(shí)踐對任務(wù)有一個(gè)更高層次的認(rèn)識。整一套流程下來，能使我們事半功倍。下面，先介紹一下為什么學(xué)習(xí)MFQ。

　　Why

　　對于實(shí)踐敏捷開發(fā)流程的團(tuán)隊(duì)，要求測試前移，因而對測試的要求更傾向于能夠指導(dǎo)開發(fā)的測試設(shè)計(jì)，而非由開發(fā)牽引的測試用例。

　　大部分團(tuán)隊(duì)雖然有測試用例，但測試用例的設(shè)計(jì)沒有采用結(jié)構(gòu)化的方法，在測試場景、異常場景上經(jīng)常有欠缺和遺漏，而MFQ正是一種結(jié)構(gòu)化的思維以及建模工具，能靈活應(yīng)用于實(shí)際的項(xiàng)目之中。

　　How

　　談到how的話，不得不說一下MFQ的四部曲，KYM-TCO-MFQ&PPDCS-TCON，下面以一個(gè)實(shí)際需求來進(jìn)一步講述這四部曲。

　　需求實(shí)例名稱：大數(shù)據(jù)平臺支持補(bǔ)丁升級功能

四部曲之一：KYM

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

四部曲之二：TCO

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

M：基于模型的單功能測試分析和設(shè)計(jì)

F：功能交互測試分析和設(shè)計(jì)

Q：質(zhì)量屬性測試分析和設(shè)計(jì)

　　下面給出上述需求對應(yīng)的TCO圖：

　　通過團(tuán)隊(duì)成員的共同努力，對單功能和功能交互點(diǎn)進(jìn)行了劃分，并識別出了后續(xù)建模需要用到的DATA屬性，接下來，就要開始實(shí)施四部曲中的第三部了。

四部曲之三：建模MFQ&PPDCS

　　通過TCO對需求的整理之后，劃分了單功能和功能交互點(diǎn)，這時(shí)，輸出物還只是測試點(diǎn)，不足以支撐整個(gè)測試，還需要對具體的單功能使用建模方法，經(jīng)過分析，一致認(rèn)為針對M，可以用PPDCS中的P(Process)來進(jìn)行建模，這里，不使用別的建模方法(Parameter，DATA，Conbination，State)，因?yàn)閯澐殖鰜淼膯喂δ馨鄠€(gè)步驟，且每一個(gè)步驟有一定的前后約束關(guān)系。下面簡單介紹一下其余四種建模方法的適用場景：

Parameter：需求中或者劃分出來的單功能或者功能交互點(diǎn)有許多參數(shù)，且這些參數(shù)相互之間有一定的業(yè)務(wù)規(guī)則約束，即某些參數(shù)之間組合才能符合需求。

DATA：需求中或者劃分出來的單功能或者功能交互點(diǎn)有許多參數(shù)，但是這些參數(shù)之間沒有業(yè)務(wù)規(guī)則的約束。

State：需求中或者劃分出來的單功能或者功能交互點(diǎn)涉及多種狀態(tài)，且各種狀態(tài)之間由于某些業(yè)務(wù)規(guī)則，能夠相互轉(zhuǎn)換。

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

　　在TCO步驟中，已經(jīng)識別出幾個(gè)參數(shù)，下面對劃分出來的所有的Function的最末端的測試場景進(jìn)行DATA方法建模，建模的結(jié)果用判定表表示如下圖所示：

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

四部曲之四：TCON

　　根據(jù)上述的測試場景，生成TCON，用上述判定表的前兩個(gè)測試條件轉(zhuǎn)化，形成的TCON如下圖所示：

　　至此，整個(gè)MFQ的流程已經(jīng)完畢，在這里，再次強(qiáng)調(diào)，MFQ需要團(tuán)隊(duì)成員齊心協(xié)力，一起完成測試點(diǎn)的梳理，并且，MFQ以及PPDCS不是一次性過程，需要在迭代進(jìn)行中，針對任務(wù)完成情況以及風(fēng)險(xiǎn)點(diǎn)對TCO進(jìn)行糾正以及完善，后期，還要在測試執(zhí)行以及自動化用例編寫，探索性測試上面做一些嘗試。

　　What

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

　　Some thought over MFQ

　　最后，給出筆者關(guān)于MFQ的一些思考。

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