大家應該都有過寫測試用例的經歷。
我的經歷大概是這樣的。
之前剛入行的時候是用excel寫用例。大概就是往模版裏填充一些必填字段，比如用例編號，名稱，步驟，預期等等。那時候啥都不懂，預期裏基本上是隨心寫，填的都是"應該正常執行", "結果應該正確"之類的寫了等於沒寫的話語，無非就把格子填滿，顯得很有工作量的樣子。執行用例的時候基本上是看需求文檔，自己寫的用例也不看，測完了就無腦打勾，顯得工作是按時按量完成了的。
後來很多年用例管理也一直沒有改善，無非就是excel換模版，然後用打勾的形式去表明工作已經完成。這是手工執行的方式。
也經歷過很長一段時間用自動化的方式去運行用例的情況，這時候用例基本是代碼，代碼是經常要去更新的，以便增強穩定性和更新業務邏輯。這時候報告和日誌比較重要，因爲跑出問題之後需要通過報告和日誌迅速去定位問題，提bug或者再人肉驗證一下。
如果對軟件測試、接口測試、自動化測試、性能測試、LR腳本開發、面試經驗交流。感興趣可以175317069，羣內會有不定期的發放免費的資料鏈接，這些資料都是從各個技術網站蒐集、整理出來的，如果你有好的學習資料可以私聊發我，我會註明出處之後分享給大家。
再後來便是開發了一些測試用例的管理系統，自己用起來還行，無非就是把excel填格子的過程改成了從網頁上填表單，但是推廣的時候遇到了很大的阻力，畢竟大家還是習慣於用excel去管理，在寫好了execl之後導入到系統裏，整個系統除了執行的時候可以體現用例狀態之外，其他的話意義不是很明顯，而且很多時候，用例的執行狀態並不是大家關注的重點，所以用例管理系統後來也沒太多任用，荒廢掉了。
近些年很多同學用腦圖的方式來管理測試用例，等於就是把需求換個維度整理了一番，變成了一個個的場景或者檢查點，測試的時候可以對照着檢查點來，比excel有不錯的提升，可以推薦大家試一下。
腦圖其實是整理+記錄的過程，很像是我們之前初高中時候老師寫的板書，好發散，格式比填格子靈活。我建議可以不用在腦圖裏寫預期結果，執行完成之後再補充也行。
寫腦圖可以用場景導向，枚舉大部分的異常場景可能會比較的有價值。
如果寫了用例但是測試的時候不去對照着看或者執行，那麼寫不寫都無所謂了。真正有價值的用例可能是
自己測試的時候會去對照着看或執行
大家都能看懂
保持跟最新的需求同步
最後給一張最近關注度比較高的個稅腦圖，這個圖基本上算是非常全面的測試檢查點了，大家可以參考一下。
