引入：
既然我們這篇要說《Xmind寫測試點》，那么先來回顧一下，什么情況下才寫測試點，而不寫測試用例。
之前寫過一篇《測試用例-20問20答》，沒看過的朋友戳這里：，其中就有寫測試點的前提條件，我摘錄出來：
- 測試人員少而上線時間緊；
- 緊急的小型任務；
- 需求頻繁變化，測試用例的更新速度永遠跟不上需求的變化速度，每天都在改用例；
- 團隊所有測試人員技能均衡，對業務也都熟，測試點能充分覆蓋需求。
如果你測試的業務符合以上4點中任意一項，那么，用Xmind寫測試點吧。
目錄：
一．Xmind寫測試點的兩種格式
二．如何寫測試點
三．幾個注意事項
一．Xmind寫測試點的兩種格式
Xmind，大家一般叫它腦圖。腦圖用來拆解需求，一層一層往下寫，的確是很給力，但是相比Excel，用它來寫測試點的話，就不太容易下手了。用Excel寫測試用例，格式已經規定好了：用例編號、功能模塊名稱、前置條件、操作步驟等等。但是用Xmind寫測試點，正因為沒人規定怎么寫，所以才不好落地。所幸經過n多Tester的實踐，最終確定出兩種風格。
Eg：給產品添加“敏感詞檢測”的功能，多個敏感詞用英文逗號隔開。系統檢測到敏感詞會彈窗提示並建議修改。
- 第一種格式，一個分支上所有節點串在一起，才是一條完整的測試點，前面的節點是后面節點的前置條件。
- 第二種格式，按照測試維度划分，逐級細化，測試點越來越明晰，每個分支的最后一個節點就是一個完整的測試點。
推薦使用第二種格式。這種格式的用例，在做用例評審時，方便確認需求覆蓋率，而且對於用例執行者比較友好，執行者可以只關注用例的最后一個節點，按照指定策略執行就行了，如果是第一種格式，需要每次都從頭看到尾，很容易出錯。
注意：分類是為了讓眾多測試點更清晰易懂，不要在分類標准的選取上糾結，最后面的測試點才是重點。不要在分類條件的選取上鑽牛角尖，如果選不出來概括性完美的分類標准，也可以不分類，或者選一個能概括大部分測試點的分類條件即可，時間要花在刀刃上。
二．如何寫測試點（按照上述第二種格式-分類）
1.盡量不要把用例步驟寫到測試點里面，要突出測試目的。操作步驟可以放在備注里。
2.要提前構思好整體分類再動手寫測試點
拿到需求后，先要整體了解產品需求和實現邏輯，然后決定每一個層級的分類標准，比如是按照質量模型的角度進行分類，或者按照修改點進行分類，前面層級的划分標准，直接決定了接下來子節點的划分標准。
三.幾個注意事項
1.寫測試點的前提
寫用例和執行用例的人，對需求要非常的清楚，如果忽略這個前提，我們寫出來的測試點很清晰，但是可讀性會很差。在項目有參與人只是純執行角色時，可以通過補充測試點備注的方式來完善對測試點的說明。
2.測試點是測試的指導，而不是用來做無腦執行
如果直接無腦執行，那么目前用分類寫出的測試點確實無法順利執行，就算加上簡要的測試步驟描述，執行的過程中也會經常發現問題，怎么好多測試點的執行步驟其實是一樣的，只是在不同位置的測試目的不同而已，對，這是正常情況。
測試點一定是我們測試的指導，而不僅僅是作為測試執行階段的依據這么簡單看待。
推薦閱讀：https://www.cnblogs.com/jitipaper/p/12152351.html
更多軟件測試文章，請關注公眾號：吉提