----頭腦風暴完成后，就可以整理出一份測試思路，最好在設計測試用例模板時考慮到這點，只有把思路記錄下來，在后面的詳細用例編寫中才不會忘記，在后期的維護用例中也可以快速掌握用例情況。后面會有一份測試用例模板
對于測試用例編寫，本人用的是自己歸納的一個通用模式
解釋上面的圖：
由于本人測試的程序是C/S結構的，大部分都是在這三個操作系統下進行。如果產品是B/S結構的話，可能在winxp,win2000與win2003后面還要增加一列，就是各種不同的瀏覽器，
這樣編寫用例的好處就是層次分明，比如后面產品需要修改界面而不涉及到功能時，就可以快速找到進行用例修改。模塊功能的用例大部分就是來自第三點的測試思路，只是進行擴充編寫吧了。
其他的詳細編寫用例技巧就不說了，網絡上很多資料，肯定比我寫的好。我的宗旨就是用例編寫前先要做到層次分明，心中有數寫那些方面。其他就是慢慢擴充。
5、測試用例評審
---------這一步就不說了，如果有時間的話最好做詳細的用例評審，沒有時間的話也要進行測試內部人員相互查看各自的用例，提出各自的意見。
6、執行用例
--------這一步是最好檢驗測試用例編寫的水平了，交叉進行用例執行。
7、用例效率計算
-------這一步對有很好測試管理工具的公司來說，可能沒有用處。這里是根據公司進行設計的，由于公司不是很大，也沒有用大型商業測試管理工具，所以一下用例效率都可能必須手動，公司用JIRA管理BUG，用例和需求都是通過EXECL進行管理。在需求與用例之間暫時沒有想到好的方法，用例與BUG對應已經想出方法了，在下面的的用例模板中有。
雖然說對應比較簡單，但是比較實用，能夠快速反應出用例設計的質量，以及用例是否遺漏了。
這份文檔寫完了，既不能算是測試用例的管理，也不能算是用例設計技巧，管他呢?當作自己的總結。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
