前幾天看了一篇效能測試相關的文章：效能測試模型初探及應用方法分析，其中提到了mfq分析方法。專門去查閱了mfq相關的一些資料，學習了一番。
之後想起了以前看《google的軟體測試之道》這本書時，書中提到的一種測試分析方法：acc分析方法。
還有我個人在工作學習中總結的乙個分析方法：象限分析法。
這篇部落格，對這三種方法進行乙個簡單介紹，僅供參考。。。
mfq在實踐中的應用
邰曉梅部落格
一、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軟體測試之道》測試工程師
acc（attribute component capability）分析方法即：特質、元件、能力。這是從google眾多測試團隊實踐中總結的乙個優秀流程，受眾較多，搜尋「google test analytics」即可找到。
acc指導原則如下：
①避免散漫的文字，使用簡明的列表；
②不必推銷（測試計畫的受眾是工程師）；
③盡量簡潔（測試計畫的大小和測試問題的規模有關，和作者的寫作慾望無關）；
④漸進式的描述（make it flow）：測試計畫的每個部分應該是前面部分的延伸；
⑤指導者的思路（乙個好的計畫過程可以幫助計畫者思考產品功能及其測試需求，有條不紊的從概念過度到直接實現的低層細節）；
⑥最終結果應該是測試用例（測試計畫最直接的體現就是可以清楚的指導測試用例的編寫）；
a：代表特質（attribute）
在設計測試計畫或者做acc分析時，必須先確定該產品對使用者、對業務的意義；比如：為什麼開發它？能帶來什麼價值？怎樣吸引客戶？核心競爭力是什麼？等等。。。
特質代表了產品的品質和特色，是區別於競爭對手的關鍵。
c:代表元件（component）
元件是構成待建系統的模組，在特質被識別後確定，元件是使乙個軟體之所以如此的關鍵**塊；實際上，它們是測試人員所要測試的物件。
c：代表能力（capability）
能力（功能點）代表系統在使用者指令下完成的動作。它們是對輸入的響應、對查詢的應答、以及代表使用者完成的活動。
能力一般是面向使用者的，表達使用者眼裡系統的行為，它最重要的乙個特點是它的可測試性。
關於能力點分析的一種方法：
上圖是乙個以特質為x軸、以元件為y軸的**，通過這種方法將功能點對映到特質和元件上。其中有很多空格，它表示：只有部分元件對該特質有影響（不是每個元件都對特質有影響）；
能力表的每一行或列表示按某種方式相關聯乙個功能點切片，這樣可以將應用功能分解為多個可測試點的辦法。單元格中數字表示該元件滿足此特質能力的數量，數字越大，該交叉點需要！
測試的測試點越多，這些能力點可以方便指定元件/特質對的需要的測試；可以以這些功能點直接涉及測試用例，或將它們組合成更大的用例或測試場景。
注意以下幾點：
①每個功能點至少對應乙個用例
②重要的功能點對應多個用例
③並非所有的功能點都是同等重要的，區分優先順序很重要
三、象限分析法
這個方法是我個人閱讀《高效能人士的七個習慣》這本書後總結出來的，可能不是首創，但也包含了個人的一些思考和總結。方法如下圖：
說明：
這個方法的原則就是將測試需求根據不同維度和等級劃分為四個象限，然後進行對應的填充，在具體的測試執行過程中，根據具體情況（比如資源、時間等）進行優先順序執行。
上圖是我去年這個時候畫的，按照需求的功能、非功能、重要、不重要四個維度劃分。此刻寫這篇部落格的時候，想到了其他的不同維度，比如：優先順序、實現難易程度等。
有一定測試經驗的童鞋應該都了解，在國內目前的大環境下，測試的時間和資源往往都是不夠的，這種情況下如何做取捨，降低上線的風險程度是必須衡量的。
根據需求分析的結果，進行不同維度劃分，可以更好地安排接下來的測試工作，做到合理取捨，降低上線風險。
ps：無論是mfq還是acc或者象限分析法，其實都需要根據具體情況（比如團隊成員構成，技術水平，職業素養，資源），進行合理的劃分和分析，由簡入繁。
以上內容僅供參考，如有更好的意見，可以提出來，一起交流討論。。。
從需求到測試
詳盡的需求是系統測試的基礎，反過來只能通過測試來判斷軟體是否滿足了需求。你必 須針對軟體需求規格說明中所記錄的產品的預期行為來測試整個軟體，而不是針對設計或編 碼。基於 的系統測試可以變成 自滿足的預見 self fulfilling prophecy 產品可以正確 呈現基於 的測試用例所描述的所有...
從需求到設計
從需求到設計分為 需求 分析 設計三個步驟。1 需求收集和整理階段 盡量詳盡的收集客戶的需求，把複雜的業務化成業務流程圖。需求整理就是把需求按客戶的業務模組進行整理，分模組把需求按業務邏輯整理一遍，去除雜質 規整業務 履順業務流程。2 需求分析 分析整理好的業務需求，把握業務的資料流，畫出業務流和資...
需求從0到1
軟體是一種工具，是用來輔助人們解決某些問題的 相關的問題，組成問題領域 因此解決問題是軟體存在的價值，所以軟體的價值是符合某個問題領域的需求，從問題領域出發找構建軟體系統的重要性由此而得。充分了解問題領域，能夠幫助你理解需求 涉眾分析報告 通過以上大類，對專案範圍的社眾進行調查和訪談，書寫成涉眾報告...