既然我們這篇要說《xmind寫測試點》，那麼先來回顧一下，什麼情況下才寫測試點，而不寫測試用例。
其中就有寫測試點的前提條件：
測試人員少而上線時間緊；
緊急的小型任務；
需求頻繁變化，測試用例的更新速度永遠跟不上需求的變化速度，每天都在改用例；
團隊所有測試人員技能均衡，對業務也都熟，測試點能充分覆蓋需求。
如果你測試的業務符合以上4點中任意一項，那麼，用xmind寫測試點吧。
xmind，大家一般叫它腦圖。腦圖用來拆解需求，一層一層往下寫，的確是很給力，但是相比excel，用它來寫測試點的話，就不太容易下手了。用excel寫測試用例，格式已經規定好了：用例編號、功能模組名稱、前置條件、操作步驟等等。但是用xmind寫測試點，正因為沒人規定怎麼寫，所以才不好落地。所幸經過n多tester的實踐，最終確定出兩種風格。
eg：給產品新增「敏感詞檢測」的功能，多個敏感詞用英文逗號隔開。系統檢測到敏感詞會彈窗提示並建議修改。
推薦使用第二種格式。這種格式的用例，在做用例評審時，方便確認需求覆蓋率，而且對於用例執行者比較友好，執行者可以只關注用例的最後乙個節點，按照指定策略執行就行了，如果是第一種格式，需要每次都從頭看到尾，很容易出錯。
注意：分類是為了讓眾多測試點更清晰易懂，不要在分類標準的選取上糾結，最後面的測試點才是重點。不要在分類條件的選取上鑽牛角尖，如果選不出來概括性完美的分類標準，也可以不分類，或者選乙個能概括大部分測試點的分類條件即可，時間要花在刀刃上。
1.盡量不要把用例步驟寫到測試點裡面，要突出測試目的。操作步驟可以放在備註裡。
2.要提前構思好整體分類再動手寫測試點
拿到需求後，先要整體了解產品需求和實現邏輯，然後決定每乙個層級的分類標準，比如是按照質量模型的角度進行分類，或者按照修改點進行分類，前面層級的劃分標準，直接決定了接下來子節點的劃分標準。
1.寫測試點的前提
寫用例和執行用例的人，對需求要非常的清楚，如果忽略這個前提，我們寫出來的測試點很清晰，但是可讀性會很差。在專案有參與人只是純執行角色時，可以通過補充測試點備註的方式來完善對測試點的說明。
2.測試點是測試的指導，而不是用來做無腦執行
如果直接無腦執行，那麼目前用分類寫出的測試點確實無法順利執行，就算加上簡要的測試步驟描述，執行的過程中也會經常發現問題，怎麼好多測試點的執行步驟其實是一樣的，只是在不同位置的測試目的不同而已，對，這是正常情況。
測試點一定是我們測試的指導，而不僅僅是作為測試執行階段的依據這麼簡單看待。
好東西要和朋友一起分享哦
uat測試用例怎麼寫 Xmind寫測試點
既然我們這篇要說 xmind寫測試點 那麼先來回顧一下，什麼情況下才寫測試點，而不寫測試用例。之前寫過一篇 測試用例 20問20答 沒看過的朋友戳這裡 吉提 測試用例知識大全 測試用例所有疑問，只需這篇就夠了 其中就有寫測試點的前提條件，我摘錄出來 測試人員少而上線時間緊 緊急的小型任務 需求頻繁變...
移動測試測試點之功能測試測試點
4 資料更新 4.1 需要確定哪些地方需要提供手動重新整理 哪些地方需要自動重新整理 哪些地方需要手動 自動重新整理 4.2 確定哪些地方從後台切換回前台時需要進行資料更新 4.3 根據業務 速度及流量的合理分配，確定哪些內容需要實時更新，哪些需要定時更新 4.4 確定資料展示部分的處理邏輯，是每次...
登入測試點
測試點 使用者 密碼 登入按鈕 1.是否有長度限制 2.是否可以不輸入使用者名稱 3.是否可以使用特殊字元 4.是否可以使用空格 5.是否可以使用空白 6.是否可以英文 7.是否可以使用中文 8.是否可以大寫使用者名稱 9.是否可以小寫使用者名稱 10.密碼是否可以用大寫 11.密碼是否可以用小寫 ...