前幾天看了一篇性能測試相關的文章：性能測試模型初探及應用方法分析，其中提到了MFQ分析方法。專門去查閱了MFQ相關的一些資料，學習了一番。
之后想起了以前看《Google的軟件測試之道》這本書時，書中提到的一種測試分析方法：ACC分析方法。
還有我個人在工作學習中總結的一個分析方法：象限分析法。
這篇博客，對這三種方法進行一個簡單介紹，僅供參考。。。
參考資料：
一、MFQ方法
MFQ是由邰曉梅提出的一種結構化的思維以及測試分析和測試設計方法，分為四部曲。整個四部曲之間實質上是全貌到細節，整體到部分的關系。
它運用啟發思維的方式讓大家從不同的維度對需求進行進一步了解，從測試的角度重新定義需求，結構化的思維方式輔助圖形化工具使得場景遺漏概率降低。
MFQ的四部曲分別如下：
1、KYM
KYM（Kown Your Mission），即了解自己的測試對象。對於需求承接者來說，需要從不同的維度去了解、分析需求，在分析過程中，有任何疑問均可以羅列出來。
KYM通用的維度可用如下引導詞來標識：CIDTESTD，即：Customer、Information、Developer Relations、Test Team、Equipment&Tools、Sheduler、Test Item、Deliverables。
2、TCO
TCO(Testing Coverage Outline)，即從測試的角度對原始需求進行提煉，提煉出對測試有用的測試點，並且對提取出的信息進行重組，識別出需求中的風險，做到對需求心中有數。
KYM與TCO均不是一次性過程，並且需要各種角色成員一起梳理，其中TCO中最重要的是要識別出M、F、Q：
M：基於模型的單功能測試分析和設計；
F：功能交互測試分析和設計；
Q：質量屬性測試分析和設計；
3、建模MFQ&PPDCS
通過TCO對需求的整理之后，划分了單功能和功能交互點，這時的輸出物還只是測試點，不足以支撐整個測試，還需要對具體的單功能使用建模方法。
PPDCS(Process，Parameter，DATA，Conbination，State)建模方法從不同維度設立了建模思路，下面簡單介紹一下其中三種建模方法的適用場景：
Parameter：需求中或者划分出來的單功能或者功能交互點有許多參數，且這些參數相互之間有一定的業務規則約束，即某些參數之間組合才能符合需求。
DATA：需求中或者划分出來的單功能或者功能交互點有許多參數，但是這些參數之間沒有業務規則的約束。
State：需求中或者划分出來的單功能或者功能交互點涉及多種狀態，且各種狀態之間由於某些業務規則，能夠相互轉換。
4、TCON
根據上一步建模的測試場景，生成TCON，用上述判定不同情況下的測試條件轉變，TCON這里可以理解為TestCase。
總結：MFQ需要團隊每個成員參與完成測試點的梳理，並且，MFQ不是一次性過程，需要在迭代中針對任務完成情況以及風險點進行及時糾正及完善。
二、ACC分析方法
來源：《Google軟件測試之道》
具體可參考我之前的博客：《Google軟件測試之道》測試工程師
ACC（Attribute Component Capability）分析方法即：特質、組件、能力。這是從Google眾多測試團隊實踐中總結的一個優秀流程，受眾較多，搜索“Google Test Analytics”即可找到。
ACC指導原則如下：
①避免散漫的文字，使用簡明的列表；
②不必推銷（測試計划的受眾是工程師）；
③盡量簡潔（測試計划的大小和測試問題的規模有關，和作者的寫作欲望無關）；
④漸進式的描述（make it flow）：測試計划的每個部分應該是前面部分的延伸；
⑤指導者的思路（一個好的計划過程可以幫助計划者思考產品功能及其測試需求，有條不紊的從概念過度到直接實現的低層細節）；
⑥最終結果應該是測試用例（測試計划最直接的體現就是可以清楚的指導測試用例的編寫）；
A：代表特質（Attribute）
在設計測試計划或者做ACC分析時，必須先確定該產品對用戶、對業務的意義；比如：為什么開發它？能帶來什么價值？怎樣吸引客戶？核心競爭力是什么？等等。。。
特質代表了產品的品質和特色，是區別於競爭對手的關鍵。
C:代表組件（Component）
組件是構成待建系統的模塊，在特質被識別后確定，組件是使一個軟件之所以如此的關鍵代碼塊；實際上，它們是測試人員所要測試的對象。
C：代表能力（capability）
能力（功能點）代表系統在用戶指令下完成的動作。它們是對輸入的響應、對查詢的應答、以及代表用戶完成的活動。
能力一般是面向用戶的，表達用戶眼里系統的行為，它最重要的一個特點是它的可測試性。
關於能力點分析的一種方法：
上圖是一個以特質為X軸、以組件為Y軸的表格，通過這種方法將功能點映射到特質和組件上。其中有很多空格，它表示：只有部分組件對該特質有影響（不是每個組件都對特質有影響）；
能力表的每一行或列表示按某種方式相關聯一個功能點切片，這樣可以將應用功能分解為多個可測試點的辦法。單元格中數字表示該組件滿足此特質能力的數量，數字越大，該交叉點需要！
測試的測試點越多，這些能力點可以方便指定組件/特質對的需要的測試；可以以這些功能點直接涉及測試用例，或將它們組合成更大的用例或測試場景。
注意以下幾點：
①每個功能點至少對應一個用例
②重要的功能點對應多個用例
③並非所有的功能點都是同等重要的，區分優先級很重要
三、象限分析法
這個方法是我個人閱讀《高效能人士的七個習慣》這本書后總結出來的，可能不是首創，但也包含了個人的一些思考和總結。方法如下圖：
說明：
這個方法的原則就是將測試需求根據不同維度和等級划分為四個象限，然后進行對應的填充，在具體的測試執行過程中，根據具體情況（比如資源、時間等）進行優先級執行。
上圖是我去年這個時候畫的，按照需求的功能、非功能、重要、不重要四個維度划分。此刻寫這篇博客的時候，想到了其他的不同維度，比如：優先級、實現難易程度等。
有一定測試經驗的童鞋應該都了解，在國內目前的大環境下，測試的時間和資源往往都是不夠的，這種情況下如何做取舍，降低上線的風險程度是必須衡量的。
根據需求分析的結果，進行不同維度划分，可以更好地安排接下來的測試工作，做到合理取舍，降低上線風險。
PS：無論是MFQ還是ACC或者象限分析法，其實都需要根據具體情況（比如團隊成員構成，技術水平，職業素養，資源），進行合理的划分和分析，由簡入繁。
以上內容僅供參考，如有更好的意見，可以提出來，一起交流討論。。。