Star （測試開發工程師）瀏覽器
有道筆記組用敏捷開發兩年多了，對於敏捷，有不少的文章在寫，我就不班門弄斧了，我只說下和咱們測試相關的一些狀況。app
每次迭代，都有大量的測試用例，評審每每要花不少時間，效果很差；產品更新快，開發沒有合適的依據自測，提測的質量沒有預期的好；需求根據市場的需求不斷有改動，全部人都爲跟上需求而發愁；需求的內容量大，測試執行的時候會不記得有些功能的設計，若是找文檔速度每每比較慢；准入測試沒有很好的依據，不能在短期內發現block測試的問題。工具
像是個魔咒，又像一個怪圈，每次都在抱怨這些問題，然而卻遲遲得不到很好的解決，直到有一天，咱們遇到了思惟導圖…單元測試
思惟導圖是英國著名心理學家東尼.博贊在20世紀60年代發明的風靡世界的思惟工具。通俗地說，思惟導圖是一個簡單、有效、美麗的思惟工具。它依據全腦的概念，按照大腦自身的規律進行思考，全面調動左腦的邏輯、順序、條例、文字、數字以及右腦的圖像、想象、顏色、空間、總體思惟，使大腦潛能獲得最充分的開發，從而極大地發掘人的記憶、創造、身體、語言、精神、社交等各方面的潛能。測試
思惟導圖是一種將放射性思考具體化的方法。放射性思考是人力大腦的天然思考方式，每一種進入大腦的資料，均可以成爲一個思考中心，並由此中心向外發散出成千上萬的關鍵點，每個關鍵點表明與中心主題的一個鏈接，而每個鏈接又能夠成爲另外一箇中心主題，再再向外發散出成千上萬的關鍵點，呈現出放射性立體結構。this
一般的記錄方式都是線性的，一行一行，一頁一頁的下去，沒法體現出來關係，也不能突出中心和重點，更不方便記憶。而思惟導圖就是用圖形結構的方式，列出相關內容，並表示出內容之間的關係，並顯示出重點和核心，詳細特色以下：
1. 簡單，易用
2. 關聯，每一思想主意均可能有聯繫
3. 可視化，容易記憶
4. 線狀輻射，容許從各個角度展開工做
5. 提綱挈領，幫助咱們立足全局把握問題之間的聯繫spa
說了這麼多都是在說思惟導圖的思想和特色，那結合到咱們的應用中，就是使用思惟導圖的軟件（見附註），改善咱們測試的工做，走出測試的困境。操作系統
首先體如今測試用例評審的準備上。使用思惟導圖，按思惟導圖的思路，將整個功能做爲一箇中心，相關的做爲分支，分支本身又做爲一個新的中心，列出和它相關的部分，如此循環，直到窮盡。在列這些的時候，其實是測試技能自己和思惟導圖工具的一種結合。在寫case的時候，是一個從上到下的過程，每一層都進行分類，而後查看分類是否徹底，相似MECE的思想，當前層分類和覆蓋足夠之後，再進行下一層。
在使用思惟導圖以前的狀況是，在你對當前層進行細分的時候，突然發現上一層好像遺漏掉了什麼，因而又要各類的添加補充。固然用excel作這個事情也能夠，可是使用excel進行添加，每每須要仔細查找該添加到什麼地方，層級關係也很差對應，並且在查找的過程也會打斷原來的思路，不知道原來作到什麼地方了，並且後續添加不得不一再的調整格式，添加行，合併單元格…設計
可是使用思惟導圖就簡單多了，發現哪一層少了什麼，一眼就能找到，並且添加方便，添加以後並不會影響到以前想到的地方。這個思惟導圖列出來，就至關於介於產品文檔和case之間的一個產物，十分清晰的體現出各個功能之間的聯繫，以下圖：
而後是用在具體的用例評審。評審是必不可少的一個環節，由於產品、開發、測試三方的理解會有差別，因此須要在評審過程當中達成一致。以前的評審，是使用excel，對着一條條的用例進行說明。一般思惟導圖上列的一個功能至少對兩條測試用例，每一個測試用例至少有兩個操做步驟，當思惟導圖最下一層的分支量達到100個的時候， 測試用例 行數每每能達到400行。當一條一條過 測試用例的時候，參與者每每就會陷在具體的 測試用例裏，背景，大分類均可能不記得了，時間每每也要2個小時以上，並且若是是用例寫出來以後，過一段時間再作的評審，那麼寫用例的人須要很長時間才能記起當時寫用例的思路，可是看思惟導圖每每只須要很短的時間就能記起來，並且自己思惟導圖的內容也不容易忘記。
當使用思惟導圖評審的時候，思惟導圖的精簡，內容相關，結構清晰，關聯清楚的特色就一覽無遺了，雖然不是過測試用例（其實測試用例自己是測試同事的事情，若是功能點列的足夠全，又都達成一致的狀況下，你們寫出來的用例都是差很少的），可是全部該涉及到的地方都應該包含了。開會的時間每每也會少不少。在評審過程當中，若是有錯誤或不一致的地方，當時就能夠修改完成，添加修改很是方便。
第三是用在把思惟導圖轉換爲測試用例。思惟導圖是介於需求和測試用例之間的產物，思惟導圖會列出全部的功能點和各類組合，已是很全面了。可是測試用例要求的是有正向反向的測試用例，須要有具體的步驟，因此後面在寫測試用例的時候就根據思惟導圖所列的狀況，加上步驟，加上正向反向的測試用例，就能夠了，而不用像以前那樣，根據需求一條條的想測試用例，又怕漏掉，寫測試用例的工做變的簡單不少。在根據思惟導圖寫用例的時候，思路會很清楚，功能之間的關聯，寫過的和沒寫過的部分，剩餘多少工做，一目瞭然。
第四是評審結果的其它應用。評審過的思惟導圖能夠做爲開發自測和測試執行准入測試的依據。要求開發自測一方面是由於bug發現的越早，修改的成本越低，即便一樣是在產品發佈以前，由測試人員測試出來的bug仍是比開發自測出來的bug的代價要高（固然是指的用簡單的方式就能發現的bug，而不是要作不少嘗試才能發現的）；另外一方面，開發同事在提交一個測試版本的時候，每每是以爲本身作的已經很好了，而事實上經常會有明顯的遺漏，那根據思惟導圖進行自測一下，時間不長，並且又比較全面，比提供給開發的同事一些具體的測試用例效果要好的多。准入測試也和開發自測相似，要求快速，全面，抓住重點，因此按思惟導圖執行是個很好的選擇。
關於開發的自測，我還想多說一點。敏捷開發的一個核心實踐和技術是TDD（Test-Driven Development），即測試驅動開發。原理是在開發功能代碼以前，先編寫單元測試用例代碼，測試代碼肯定須要編寫什麼產品代碼。這固然是個理想的狀態，大部分狀況下都達不到。而咱們使用思惟導圖做爲參照並進行自測，實際上算是咱們走向TDD的過渡階段，一樣有助於產品的理解和開發質量的提升。
第五是咱們還但願這個思惟導圖能幫助開發的同事在開發的過程當中作一些檢查，看看是否有遺漏的地方，是否有沒有想到的地方（事實上，當咱們開發的同事在評審過咱們的思惟導圖以後，說的最多的就是「這個東西要是早出來就行了」），只是如今咱們出圖的時間比較落後，因此還須要進一步的努力。
在合適的場景下使用合適工具，對工做效率會有很大的提高；在不須要工具的場合勉強使用工具，只會讓你的工做更加痛苦。思惟導圖使用方便，功能強大，可是也不是在每一個場合都須要用到的。好比很小的功能的場合，硬要走這個流程，使用思惟導圖，浪費人力。不過對於小的零散的功能，能夠列在一個思惟導圖裏，持續更新，可是不走評審的流程，對於整個測試的積累仍是頗有用的。
趙本山有一句很經典的話：鞋合不合適，腳知道。套用到咱們這裏就是，工具好很差用，用的人知道，思惟導圖自己是一個頗有上手容易，又能給咱們帶來不少便利，不妨來嘗試一下吧。