checklist文檔格式推薦使用思維導圖。比如 MindMaster 和 processon。我喜歡用這些平台或者軟件的思維導圖大綱模式來編寫 checklist。
checklist 需要包含的內容
checklist 最重要的當然是測試用例，除此之外，附上相關依賴文件和測試數據，包括：prd，技術文檔，測試賬號，測試數據，測試平台，測試環境，圖例（用紅色背景標記出 P0 的冒煙 case，藍綠色標記 checklist 評審時新增的 case ，疑問用黃色背景標注，深藍色標記checklist 評審后決定刪除的 case ）等等。
完備的測試用例設計
1.直觀的邊界值設計。這種一般是參數的取值存在范圍，邊界值是最可能出現問題的地方；
2.每種情況或者場景的枚舉。比如某個參數包含幾種枚舉值，在數量不多的情況下對每種枚舉進行測試驗證；再比如某個網站有多個頁面和組件，需要對每個頁面或者組件進行驗證；
3.操作直接結果的驗證。比如一個審核操作，最直接的結果就是會把審核結果落庫，所以需要驗證數據庫是否新增一條審核結果或者審核結果是否更新；
4.由於操作的直接結果產生的影響驗證。比如一個審核操作直接結果是產生一個審核結果，這個審核結果產生的影響可能有兩個：一是是產品上架售賣，這時需要驗證產品上架這個操作的直接結果（數據庫商品狀態變成可售或者下架）和直接結果產生的影響（站點能搜到這個商品）；二是給商品的提交者發送一條審核通過的郵件，這時需要驗證各種郵箱后綴的郵件能否正常發送且收到的郵件格式不亂碼，郵箱找不到情況下服務端不panic
注意：
多想想需不需要驗證數據庫或者查詢日志關鍵字來驗證鏈路節點的正確性，而不僅僅是關注黑盒入口數據和返回數據，這種是冒煙 case 的測試過程，但是對於正式測試來說這不夠精細。
編寫checklist 的一些好習慣
-
附上文檔依賴（PRD、技術文檔和其他背景解釋文檔）
-
附上測試賬號、測試平台、測試環境、數據准備方式
-
高亮標記疑問點、准入case
-
測試過程中如果有記錄測試數據，把測試數據文檔也放到這個checklist中
注意：
附上這些文檔依賴和測試數據可以方便自己來回反復找各個文檔和數據，同時也能方便后續回顧這個需求的測試過程時能很清楚知道這個checklist 是屬於哪個需求的，各種文檔依賴有哪些，使用哪些測試賬號測試的，測試結果是怎樣的，讓其他人看了有種一目了然的感覺，利人也利己。
一個 checklist 開頭 demo：
checklist 編寫時間
如果上個需求測試過程中開發同學改 bug 的時間較多，導致我們需要斷斷續續地測試，那可以在閑暇時間熟悉下個需求並輸出 checklist，如果上個需求開發同學改 bug 的時間較少，對我們來說主要是連續的測試，可以在上個需求的測試過程中暫停半天或者一天，輸出 checklist，盡量在需求提測前寫好 checklist，這樣主要是為了不讓寫 checklist 的時間占用提測之后的測試時間。
