敏捷腦圖測試用例實踐之路(3)

圖-1-Portal測試用例這個階段，問題暴露越來越嚴重了：測試用例里面寫死了數據、業務步驟不同測試人員都按照具體步驟來測試，就好比車載導航，變成“導航測試”了，如果需要測試其他客戶、其他業務呢?有些測試人員就再復制一個用例出來，造成用例泛濫。測試用例依然沒有思考的過程負責第一次編寫的測試人員有思考，但負責執行的測試人員，沒有再繼續跟開發交互測試過程，沒有更深入的思考，而是僅僅按照用例執行，那這種效果等于走過場。遇到十幾個、甚至幾十個步驟的功能，用例編寫耗時例如：打開瀏覽器，輸入賬號密碼登錄，這些其實也是不必要展示的步驟，做測試就要熟悉業務，測試人員應當更加關注的是開發是否做了正確的功能，功能是否做了正確的事情，在一個測試、開發比例1:4(有些是1:10)的團隊里面，測試人員的時間是有限的，不要陷入過分的步驟細節里面去深究，要把重點思路放在運用哪些測試方法、如何組合更加有效覆蓋測試故事點。例如簡潔的測試故事點：作為主帳戶，輸入正確的用戶名和密碼登錄系統，以便能夠查看當日的帶寬數據。2不進則退-倒騰敏捷腦圖用例傳統的軟件交付測試，可以簡單描述為下圖所示： 圖-2-傳統交付測試開發人員完成任務之后，最后交付給測試人員，這種模式下，測試人員不能及早發現需求階段的缺陷、及時編寫測試用例，用例評審滯后，發現缺陷同樣也會滯后。而整個過程中丟失最大的環節就是：溝通、反饋。這在《全程軟件測試實踐：從需求到運營》文中也曾提過。倘若要是使用傳統的用例編寫，把測試團隊人員的思維固化，這樣子下去不進則退，不利于團隊發展。鑒于此，創建了敏捷腦圖用例，有以下原則：參與需求分析、記錄驗收要點全程軟件測試，從需求階段開始參與，在sprint會議上對功能點進行評估，消除含混性的疑點，將明確的作為驗收要點，作為腦圖用例故事點的參考來源。編寫腦圖用例，要與開發人員達成一致意見開發過程中，測試人員可以根據原型圖設計腦圖用例(沒有實際系統，測試也可以先行)，與開發人員進行查漏補缺(也就是用例評審環節)，主要是確認測試功能點、測試故事，以及測試數據的準備，這幾個方面不可能一開始就明確下來，要不斷溝通、挖掘、完善腦圖用例。3 腦圖用例演化這里的重點主要講一下腦圖用例(推薦使用Xmind工具：http://www.xmind.net)的演化(測試故事點以后再做介紹)，從第一個大版本和第二個大版本的考慮，其中的小版本忽略。第一版本腦圖用例要點：所見所想當時的想法很簡單，以需求為思考出發點，把所有功能性、非功能性的列舉出來，然后再整理故事點。 圖-3-腦圖用例模板v1.0第二版本的腦圖用例要點：增加風險考慮

　　增加局部決策考慮例如：一個輸入框(或者叫元素)，測試人員應當針對這個元素，結合數據，會考慮使用哪些測試方法進行操作呢?增加全局決策考慮例如：一個業務查詢操作，在web上操作，會觸發一系列元素(輸入框、查詢按鈕)，這些應當如何組合、使用什么策略呢?遵循：重構->測試->重構->測試，的原則

圖-4-腦圖用例模板v2.0腦圖的形式展現并不是最重要問題，關鍵問題是：思考的出發點，這個要整個團隊參與討論，達成共識，才能傳承。引出思考點，大家就可以不斷補充腦圖，剛開始所有點可能是零散的，甚至一點關系都沒有，這個時候就需要重構了，抽取相關點，下面會講講我們用什么方法來做。4 腦圖用例實踐指引腦圖編寫不是漫無目的去思考，正如探索式測試策略，并不是指無目的去做即興測試，有原則指引很重要。團隊采用SMART原則進行腦圖用例實踐：Specific(具體的)：測試需要一個具體的目標(甚至原型圖都可以)，用來描述全景圖。

原文轉自：http://www.infoq.com/cn/articles/road-of-agile-mind-map-practice/