已經很久沒有寫過case了，結合以前編寫用例的一些經驗，其實覺得編寫用例也還是有流程可走的(當然不是按照教科書上說的那樣進行用例設計，姑且不說有多少企業會有那麼詳細的需求書，會有多少時間讓你去寫完善，非常詳細的測試用例，反正我是感覺專案中寫用例的時間非常短)，總結自己的一些經驗，不單單是用例設計，還涉及到一些其他方面。
簡單7個步驟：
1、理清模組需求：
----由於專案需求說明書不詳細，而且沒有進行需求評審的情況下，在拿到上級lead給的測試任務後，一拿到先別著急去寫測試用例，首先你應該做的是，根據有限的模組需求說明進行深入理解模組的功能，流程，以及涉及到的其他功能，記錄下來。傳送給該模組的開發人員，詢問他你理解的是否和他設計的有差錯，雖然說開發人員可能對整個需求不情況，但是對自己要開發的模組肯定還是能說出個大概來。
2、測試需求提起
-----在經過和相對應的開發人員簡單交流後，就可以根據得到文件進行測試需求提起了，原則是從大到小，大模組一直分解到最小部分模組。整理乙份模組測試需求書
3、設計測試思路
-----測試需求書完成後，就可以設計測試思路，這裡的設計思路並不是說寫測試用例，而是乙個總的思路說明；
舉個例子：
如大家都熟悉的軟體公升級功能，可以向下面一樣簡單列出測試思路。
正常情況：
1、軟體在網路鏈結好的情況下公升級正常
2、最新版本的軟體不能進行公升級，公升級會有提示
3、試用期的軟體不能公升級
4、公升級過程中能正常取消，而且不會影響到軟體
異常情況：
1、在網路速度非常緩慢情況下的公升級
2、在網路時斷時續情況下進行公升級
3、系統電腦系統資源消耗嚴重情況下公升級
4、公升級過程中進行斷電，斷網，關機等操作
6、多個客戶同時進行公升級，檢視公升級伺服器的效能
上面只是簡單列出一些思路，還有很多。在列出測試思路後，如果時間的話可以組織測試人員和開發人員進行頭腦風暴，因為乙個人的思路是有限的，開發人員可以從開發的角度考慮有那些地方需要重點考慮的，其他人員也會有自己的想法。
4、測試用例編寫
----頭腦風暴完成後，就可以整理出乙份測試思路，最好在設計測試用例模板時考慮到這點，只有把思路記錄下來，在後面的詳細用例編寫中才不會忘記，在後期的維護用例中也可以快速掌握用例情況。後面會有乙份測試用例模板
對於測試用例編寫，本人用的是自己歸納的乙個通用模式
解釋上面的圖：
由於本人測試的程式是c/s結構的，大部分都是在這三個作業系統下進行。如果產品是b/s結構的話，可能在winxp，win2000與win2003後面還要增加一列，就是各種不同的瀏覽器。
這樣編寫用例的好處就是層次分明，比如後面產品需要修改介面而不涉及到功能時，就可以快速找到進行用例修改。模組功能的用例大部分就是來自第三點的測試思路，只是進行擴充編寫吧了。
其他的詳細編寫用例技巧就不說了，網路上很多資料，肯定比我寫的好。我的宗旨就是用例編寫前先要做到層次分明，心中有數寫那些方面。其他就是慢慢擴充。
5、測試用例評審
---------這一步就不說了，如果有時間的話最好做詳細的用例評審，沒有時間的話也要進行測試內部人員相互檢視各自的用例，提出各自的意見。
6、執行用例
--------這一步是最好檢驗測試用例編寫的水平了，交叉進行用例執行。
7、用例效率計算
-------這一步對有很好測試管理工具的公司來說，可能沒有用處。這裡是根據公司進行設計的，由於公司不是很大，也沒有用大型商業測試管理工具，所以一下用例效率都可能必須手動，公司用jira管理bug，用例和需求都是通過excel進行管理。在需求與用例之間暫時沒有想到好的方法，用例與bug對應已經想出方法了，在下面的的用例模板中有。
雖然說對應比較簡單，但是比較實用，能夠快速反應出用例設計的質量，以及用例是否遺漏了。
這份文件寫完了，既不能算是測試用例的管理，也不能算是用例設計技巧，管他呢?當作自己的總結。
測試用例設計與管理思路經驗總結
已經很久沒有寫過case了,結合以前編寫用例的一些經驗，其實覺得編寫用例也還是有流程可走的 當然不是按照教科書上說的那樣進行用例設計，姑且不說有多少企業會有那麼詳細的需求書，會有多少時間讓你去寫完善，非常詳細的 測試用例 反正我是感覺專案中寫用例的時間非常短 總結自己的一些經驗，不單單是用例設計，還...
設計測試用例的經驗總結
設計測試用例的過程中，選擇設計方法十分關鍵 方法錯了，肯定會大大影響測試效率。而在選擇設計方法的時候，理解需求是第一步，理解設計方法是第二步。需求往往寫的模糊 不夠條理，所以無法直接判斷使用何種設計方法。這時需要將需求分解 梳理，將需求切分成多個小的需求 然後根據各個需求的特點 設計方法的使用場景，...
測試用例文件 銀行測試用例設計經驗總結
測試用例是軟體測試核心，好的測試用例會提高測試效率和軟體質量，並指導測試人員的行為，避免遺漏掉測試的功能點。所以在測試之前必須設計好測試用例是非常重要的。經驗1 要參與需求評審，評審需求的過程實際也是熟悉業務需求的過程。只有對產品的業務理解到位，才能更好 更充分地設計出高質量的測試用例。經驗2 對於...