測試用例是測試部門應該輸出的最關鍵文檔之一。敏捷開發提倡輕文檔重交流，很多傳統流程中的文檔都可以省去，但我認爲測試用例不在這個可以省去的文檔之列。相反，測試用例在某種程度上可以替代詳細設計和概要設計文檔，作爲一個接口性質的文檔。
相比於可以運行的代碼，文檔的優勢是可讀性，換個詞就是用戶體驗。好的文檔可以幫助人更好的思考，老話說的好，好記性不如好文檔。測試用例文檔的寫作目的一定是爲了幫助你和你的團隊更好的思考。因此，這裏提出第一個觀點：好的測試用例一定是以用戶爲中心的；壞的測試用例通常是以技術爲中心的。
如何定義用戶呢？用戶可分爲公司內部用戶及外部用戶，鑑於顧客是上帝的道理，測試部應該以最終用戶的代理定義部門功能。因此，我的第二個觀點：好的測試用例基於產品功能的用戶體驗；壞的用例通常基於功能的代碼實現。
如何在用例中體現出用戶體驗呢？一個測試用例的基本骨架由3部分內容組成：{測試步驟，輸入數據，觀察點}。在測試步驟的設計中，首要需要考慮的是用戶的使用場景。因此，我的第三個觀點：好的測試用例應按照使用場景來組織；壞的測試用例通常按照程序員的修改點組織。
一個優秀的團隊一定是一個有積累的團隊。打造一個後輩可以站在前輩肩膀上不斷攀登的團隊，組織才能夠衝刺更高的目標。優秀的組織應該是開放競爭的，激勵先來着人不斷探索和開拓新工具新方法，幫助後來者迅速融入和接受現有工具和現有方法。因此，我的第四個觀點：不應該以是否可以腳本化來取捨測試用例，不能因爲測試條件艱難而故意漏用例，好的測試用例按照需求挑選工具；壞的測試用例按照工具規避用例。
測試用例作爲一篇文檔，必須注意格式和可讀性。文檔格式不但要統一，而且應該要體現規律和邏輯，詳簡安排得當，測試點均勻的分佈，冗餘少。因此，我的第五個觀點：好的用例結構是平衡的，層次清晰；壞的用例忽長忽短，整篇文擋組織無規律可循。
測試環境的搭建，往往是測試執行過程中最耗時最麻煩的一個環節，用例作爲一個測試執行的指導說明，必須考慮測試執行過程中環境的易得性。因此我的第六個觀點：好的用例測試按照深層的技術實現，搭建至簡最優的測試環境；壞的測試用例照搬用戶環境。
測試用例是一個尋需要保持更新的文檔，應該定期將修改點，網上問題，測試中發現的問題等內容補充進去，並保持自動化甲苯和用例的同步。因此我的第七個觀點：好的測試用例容易維護，可以持續發現問題；壞的用例維護困難，很快會失去價值，變成垃圾文擋。