既然我們這篇要說《xmind寫測試點》，那麼先來回顧一下，什麼情況下才寫測試點，而不寫測試用例。之前寫過一篇《測試用例-20問20答》，沒看過的朋友戳這裡：
吉提：《測試用例知識大全》----測試用例所有疑問，只需這篇就夠了
其中就有寫測試點的前提條件，我摘錄出來：
測試人員少而上線時間緊；緊急的小型任務；需求頻繁變化，測試用例的更新速度永遠跟不上需求的變化速度，每天都在改用例；團隊所有測試人員技能均衡，對業務也都熟，測試點能充分覆蓋需求。
如果你測試的業務符合以上4點中任意一項，那麼，用xmind寫測試點吧。
xmind，大家一般叫它腦圖。腦圖用來拆解需求，一層一層往下寫，的確是很給力，但是相比excel，用它來寫測試點的話，就不太容易下手了。用excel寫測試用例，格式已經規定好了：用例編號、功能模組名稱、前置條件、操作步驟等等。但是用xmind寫測試點，正因為沒人規定怎麼寫，所以才不好落地。所幸經過n多tester的實踐，最終確定出兩種風格。
eg：給產品新增「敏感詞檢測」的功能，多個敏感詞用英文逗號隔開。系統檢測到敏感詞會彈窗提示並建議修改。
推薦使用第二種格式。這種格式的用例，在做用例評審時，方便確認需求覆蓋率，而且對於用例執行者比較友好，執行者可以只關注用例的最後乙個節點，按照指定策略執行就行了，如果是第一種格式，需要每次都從頭看到尾，很容易出錯。
注意：分類是為了讓眾多測試點更清晰易懂，不要在分類標準的選取上糾結，最後面的測試點才是重點。不要在分類條件的選取上鑽牛角尖，如果選不出來概括性完美的分類標準，也可以不分類，或者選乙個能概括大部分測試點的分類條件即可，時間要花在刀刃上。
1.盡量不要把用例步驟寫到測試點裡面，要突出測試目的。操作步驟可以放在備註裡。
2.要提前構思好整體分類再動手寫測試點
拿到需求後，先要整體了解產品需求和實現邏輯，然後決定每乙個層級的分類標準，比如是按照質量模型的角度進行分類，或者按照修改點進行分類，前面層級的劃分標準，直接決定了接下來子節點的劃分標準。
1.寫測試點的前提
寫測試點和執行它的人，對需求要非常的清楚，否則我們寫出來的測試點很清晰，可讀性卻很差。如果專案中有純執行角色，可以打備註來完善測試點。
2.測試點不是用來做無腦執行的
如果無腦執行，那麼目前用分類寫出的測試點確實無法順利執行，就算加上簡要的測試步驟描述，執行的過程中也會經常發現問題。因為測試點一定是測試的指導，而不僅僅是作為測試執行階段的依據。
---------end----------
測試用例怎麼寫？
測試用例 為了特定的目的 證明軟體存在某問題 而設計的一組由測試輸入 執行條件 預期結果構成的文件 要做這個登入頁面的測試用例，你會從哪些方面思考進行測試呢？看似簡單的頁面功能能夠設計多少條測試用例完成較全面的測試呢？10條以內？20條？測試用例簡單來說就是指導如何做測試的文件，該文件主要記錄需要驗...
Xmind 編寫測試用例的新工具
以前寫測試用例，都是在excel上完成的。excel基本能滿足寫用例的大多數需求，但是如果測試的業務系統比較龐大，各個模組之間又有比較緊密的業務聯絡時，那麼excel可能無法滿足。經過一段時間的探索實踐，我發現使用xmind可以解決部分問題。xmind中的思維導向圖可以很好地梳理用例，對用例進行劃分...
怎麼匯出測試用例 怎麼編寫自動化測試用例
本文介紹如何編寫自動化測試用例 記得收藏，哦 下面分享一篇關於自動化用例編寫的文章。用例選型注意事項 1 不是所有的手工用例都要轉為自動化測試用例。2 考慮到指令碼開發的成本，不要選擇流程太複雜的用例。如果有必要，可以考慮把流程拆分多個用例來實現指令碼。3 選擇的用例最好可以構建成場景。例如乙個功能...