原文在infoq已經發布，可以直接閱讀：http://www.infoq.com/cn/articles/road-of-agile-mind-map-practice/
傳統的黑盒測試用例比較繁雜，在實施敏捷的項目中會顯得水土不服，讓測試人員過度關注用例步驟的編寫、修改，甚至同一條用例經過多人執行得到相同結果，讓人想到一個呼之欲出的廣告詞：一次編寫，多人運行相同結果，沒有思考的過程。在經歷過這些痛楚之後，對用例進行改革，以便快速響應開發的交付節奏，同時形成用例評審規範，讓開發、測試知己知彼，也加強開發自測的環節。本文主要講敏捷中腦圖用例的實踐。
1 轉型測試掉進傳統用例坑
在《軟件測試轉型之路》（http://www.infoq.com/cn/articles/transformation-way-software-testing）中，經歷了無法忘記的幾個月：每天高強度測試、反覆編寫、修改用例步驟，深刻體會：
不寫測試用例或許測得更快，但絕不是一個測試人員的最佳素養，而現在的測試用例又過於繁雜，消耗了很多時間，怎麼辦呢？
先看看測試用例的定義：測試用例（Test Case）是爲某個特殊目標而編制的一組測試輸入、執行條件以及預期結果，以便測試某個程序路徑或覈實是否滿足某個特定需求。
還有測試用例編寫的一般原則：
? 測試用例要包括欲測試的功能、應輸入的數據和預期的輸出結果。
? 測試數據應該選用少量、高效的測試數據進行儘可能完備的測試。
按照定義和原則以及模板，實踐了三個月的備案系統，列舉一些簡單測試用例如下：
? 服務器、帳號信息
測試服務器地址：http://127.0.0.1/login.do
測試管理員賬號和密碼
管理員：admin
密碼：admin
? ICP備案信息錄入
測試數據參考：附錄-ICP信息錄入測試數據
步驟名稱 | 描述 | 預期結果 | 實際結果 |
步驟 1 | 打開瀏覽器，登錄系統，點擊左側"ICP備案信息管理"-"信息錄入" | 進入"信息錄入"頁面 | |
步驟 2 | 填寫詳細信息，數據參考當天測試數據的：第一步 填寫ICP主體備案信息 點擊"下一步" | 進入"第二步 填寫ICP備案網站信息"頁面 | |
步驟 3 | 點擊底部，中間按鈕"添加網站" | 進入"填寫ICP備案網站信息" | |
步驟 4 | 填寫詳細網站信息， 數據參考當天測試數據的：第二步 填寫ICP備案網站信息（要分清填寫的是測試數據幾）
點擊"提交"按鈕 | 返回"第二步 填寫ICP備案網站信息 "，並且看到剛剛填寫的網站 | |
步驟 5 | 在剛剛的新增網站右側，點擊[添加接入]按鈕 | 進入[ICP網站接入信息]頁面 | |
步驟 6 | 在[ICP網站接入信息]頁面，填寫錄入信息， 數據參考當天測試數據的：ICP網站接入信息 （要分清填寫的是測試數據幾）
點擊[提交]按鈕 | 返回[ICP備案網站接入信息]頁面，同樣還是看到剛剛新增的網站，表明成功 | |
步驟 7 | 點擊底部按鈕"提交" | 彈出對話框"信息錄入成功" | |
步驟 8 | 點擊"確認"按鈕， | 重新進入"第一步 填寫ICP主體備案信息" |
? ICP備案歷史信息查詢
步驟名稱 | 描述 | 預期結果 | 實際結果 |
步驟 1 | 打開瀏覽器，管理員登錄系統，點擊左側[ICP備案信息管理]-[歷史記錄查詢] | 進入[歷史記錄查詢]頁面 | |
步驟 2 | 在[歷史記錄查詢]-頁面，輸入查詢條件，點擊[開始搜索]按鈕 | 進入[歷史記錄]結果頁 | |
步驟 3 | 在[歷史記錄]結果頁，選中其中一條數據，點擊右側[詳細] | 進入[歷史信息瀏覽]頁面 | |
步驟 4 | 點擊[返回]按鈕 | 返回[歷史記錄]頁面 |
反思當時遇到的問題：
所有測試用例編寫完畢，都經歷了：第一次編寫後調試、發現問題重新修改步驟、再次調試發佈，過程相當繁瑣，而且當時測試人力不足，還得把這些用例分配給客服進行測試，客服按照測試用例也遇到非常多的問題：死機怎麼處理、瀏覽器掛了信息怎麼辦等等（實際上這裏有一些決策是客服無法做得，對業務不熟悉、沒有測試經驗）。說實在的，不是專業測試人員，這個用例無法執行下去了，就是每種情況寫的不夠明細，誰能保證所有可能路徑都寫出來呢？不懂業務的測試人員，有執行測試用例的價值嗎？測試用例應當是有思考活動存在的。
另外，在excel編寫用例，不是永遠的辦法，後來把測試用例遷移到testlink上，確實比較方便，依然還是傳統編寫步驟的方式：
圖-1-Portal測試用例
這個階段，問題暴露越來越嚴重了：
1、測試用例裏面寫死了數據、業務步驟
不同測試人員都按照具體步驟來測試，就好比車載導航，變成“導航測試”了，如果需要測試其他客戶、其他業務呢？有些測試人員就再複製一個用例出來，造成用例氾濫。
2、測試用例依然沒有思考的過程
負責第一次編寫的測試人員有思考，但負責執行的測試人員，沒有再繼續跟開發交互測試過程，沒有更深入的思考，而是僅僅按照用例執行，那這種效果等於走過場。
3、遇到十幾個、甚至幾十個步驟的功能，用例編寫耗時
例如：打開瀏覽器，輸入賬號密碼登錄，這些其實也是不必要展示的步驟，做測試就要熟悉業務，測試人員應當更加關注的是開發是否做了正確的功能，功能是否做了正確的事情，在一個測試、開發比例1:4（有些是1:10）的團隊裏面，測試人員的時間是有限的，不要陷入過分的步驟細節裏面去深究，要把重點思路放在運用哪些測試方法、如何組合更加有效覆蓋測試故事點。
例如簡潔的測試故事點：作爲主帳戶，輸入正確的用戶名和密碼登錄系統，以便能夠查看當日的帶寬數據。
2 不進則退-倒騰敏捷腦圖用例
傳統的軟件交付測試，可以簡單描述爲下圖所示：
圖-2-傳統交付測試
開發人員完成任務之後，最後交付給測試人員，這種模式下，測試人員不能及早發現需求階段的缺陷、及時編寫測試用例，用例評審滯後，發現缺陷同樣也會滯後。而整個過程中丟失最大的環節就是：溝通、反饋。在《全程軟件測試實踐：從需求到運營》中文：
http://www.infoq.com/cn/articles/whole-software-testing-practice-requirements-to-operational/也曾提過。
倘若要是使用傳統的用例編寫，把測試團隊人員的思維固化，這樣子下去不進則退，不利於團隊發展。鑑於此，創建了敏捷腦圖用例，有以下原則：
? 參與需求分析、記錄驗收要點
全程軟件測試，從需求階段開始參與，在sprint會議上對功能點進行評估，消除含混性的疑點，將明確的作爲驗收要點，作爲腦圖用例故事點的參考來源。
? 編寫腦圖用例，要與開發人員達成一致意見
開發過程中，測試人員可以根據原型圖設計腦圖用例（沒有實際系統，測試也可以先行），與開發人員進行查漏補缺（也就是用例評審環節），主要是確認測試功能點、測試故事，以及測試數據的準備，這幾個方面不可能一開始就明確下來，要不斷溝通、挖掘、完善腦圖用例。
3 腦圖用例演化
這裏的重點主要講一下腦圖用例（推薦使用Xmind工具：http://www.xmind.net）的演化（測試故事點以後再做介紹），從第一個大版本和第二個大版本的考慮，其中的小版本忽略。
? 第一版本腦圖用例
要點：
ü 所見所想
當時的想法很簡單，以需求爲思考出發點，把所有功能性、非功能性的列舉出來，然後再整理故事點。
圖-3-腦圖用例模板v1.0
? 第二版本的腦圖用例
要點：
ü 增加風險考慮
ü 增加局部決策考慮
例如：一個輸入框（或者叫元素），測試人員應當針對這個元素，結合數據，會考慮使用哪些測試方法進行操作呢？
ü 增加全局決策考慮
例如：一個業務查詢操作，在web上操作，會觸發一系列元素（輸入框、查詢按鈕），這些應當如何組合、使用什麼策略呢？
ü 遵循：重構->測試->重構->測試，的原則
圖-4-腦圖用例模板v2.0
腦圖的形式展現並不是最重要問題，關鍵問題是：思考的出發點，這個要整個團隊參與討論，達成共識，才能傳承。
引出思考點，大家就可以不斷補充腦圖，剛開始所有點可能是零散的，甚至一點關係都沒有，這個時候就需要重構了，抽取相關點，下面會講講我們用什麼方法來做。
4 腦圖用例實踐指引
腦圖編寫不是漫無目的去思考，正如探索式測試策略，並不是指無目的去做即興測試，有原則指引很重要。團隊採用SMART原則進行腦圖用例實踐：
? Specific（具體的）：測試需要一個具體的目標（甚至原型圖都可以），用來描述全景圖。
? Measurable（可度量的）：有明確的度量可以評估目標是否達成（也就是驗收條件作爲測試故事點的評判標準）。
? Achievable（可實現的）：當前的目標應該是可實現的。這潛在地要求將一個大的目標分解爲多個小目標，每個小目標也是具體的、可度量的。此外，跟蹤小目標的完成情況也提供了整體進度的可度量性（一個業務操作會經過很多路徑，每個路徑可以單獨存在或者組合存在，需要切分測試）。
? Relevant（相關的）：測試故事點從需求出發（包括功能性和非功能性），結合業務特性，以及相關上下文作爲切入點。
? Time-boxed（有時間限制的）：爲每一輪腦圖用例的構建設定一個合理的時間窗口，例如在固定的時間窗口（一些人的專注度是45分鐘，一些是60分鐘，中排除不相關干擾、專注工作）。
腦圖用例編寫流程：
? 參與持續需求分析（不僅僅是需求階段，開發階段的變化也需要及時捕獲）制定腦圖用例框架
? 將業務|功能測試目標分解成一系列測試任務，每個測試任務有明確的時間限制和退出條件。
? 測試計劃之後，優先選擇一個測試任務，在一個測程內執行探索式測試，測程以45|60分鐘爲一輪，執行多輪。
? 反思當前的測試進展，並優化測試計劃。增加或刪除一些測試任務，以更加準確地反應測試對象。
實際案例：
團隊通過結對測試，摸索了一套腦圖思考方向，給予參考：
? 業務功能需求
如下圖所示，根據選定的頻道查詢在可選時間範圍內的帶寬數據
圖-5-業務功能
由於版面問題，這裏舉簡單的例子：
? 腦圖用例分析第一步
圖-6-帶寬查詢用例v1.0
首先把業務需求分析結果填寫到目標中，然後分析功能（如果沒有系統，可以只看原型圖），找到頁面的相關元素，逐個列入腦圖中，再爲每個元素使用一些測試方法，例如：等價類、邊界值，進行局部決策，這樣子，所有元素的分析完畢，就進入第二步全局。
? 腦圖用例分析第二步
圖-7-帶寬查詢用例v1.1
第二步繼續完善，進行全局分析以及列舉一些非功能性需求：
全局分析：
找到需求描述或者跟開發溝通代碼有限制條件的地方，而不是針對某個元素；
對不同元素組合有依賴關係的，也需要列出來
非功能性：
這個在文檔中可能沒有給出，需要根據經驗來評估，可以參考團隊積累業務的測試經驗，通用的點：出錯的用戶體驗是否ok、查詢時間效率如何等等
風險：
儘可能琢磨需求，挖掘風險，例如需求說：根據選定頻道，但是沒有說這個頻道不屬於客戶怎麼辦？這個就是思考的強大力量了。
? 腦圖用例分析第三步
圖-8-帶寬查詢用例v1.2
第三步是最關鍵一步，產出測試故事點，根據風險、目標、要點分析得出，這裏舉了簡單例子，可以使用關鍵路徑組合的方法來做。
當然，做完一二三步，也只是在第一個時間窗口而已（這個時候也可以直接用於測試環境探索下，驗證一些關鍵思路，增強信心），後續還需要重構-測試，在下一個時間窗口，查漏補缺，不斷完善纔可以用於時間測試。
圖-9-腦圖用例指引
5 關於富腦圖及輕腦圖用例
允許團隊成員在模板基礎上進行變化，以發揮更多的思維空間，主要有兩種模式作爲參考：
? 富腦圖用例
個人認爲，大腦對於圖像的記憶，比文字更長久。富腦圖，注重以圖片、圖標、圖標、關聯關係等記憶爲主。
圖-10-富腦圖示例
? 輕腦圖用例
注重以簡潔文字記憶爲主：
圖-11-輕腦圖示例
團隊可以在不同場景，選擇合適的模板來發揮、擴散測試的思維點。
6 總結
傳統的用例編寫，團隊大概經歷了半年，就轉向敏捷腦圖用例，之後一直堅持了三年，期間也不斷完善用例的展現以及思考的出發點。其實，在整個開發、測試環節中，思考、溝通是最重要的環節，把產生的、達成共識的內容記錄下來，彙集在腦圖中展現，就可以看到整個需求點測試的全景圖，然後再不斷細化成測試故事點，這完全符合思維擴散以及總結的模式，大腦也容易接受，而且可以不斷重構->測試->重構->測試，不斷迭代下去。
當然，有些人會問：腦圖用例裏面的故事點怎麼保證人人都看懂，能做到100%覆蓋需求，bug爲0嗎？軟件測試不可能找到100%的bug，這是對測試的誤解，因此不建議實施腦圖用例的幾點：
1、抱着通過腦圖用例把需求覆蓋100%、bug爲0；
2、對業務不熟悉，看不到腦圖用例的故事點，因爲它有時候比較隱晦；
3、團隊及主管沒有耐心；
4、通過外包做測試，需要詳細用例執行步驟、測試報告；
5、研發、測試沒有溝通，只有研發完成交付，測試才介入；
腦圖用例，不僅對研發自身素質要求高，測試要求也高，不單單要有相關測試經驗，而且也要有相關開發經驗，可以理解開發過程遇到的問題甚至有時候需要滲入到開發代碼中去排查。最後一張圖，展示了腦圖用例在Scrum框架中所處的位置，實際是貫穿整個從需求到運營階段：
圖-12-Scrum流程框架