發現：

　　人來了，又走了！

　　有篇博文如是說，大體意思是有些的程序員，中途轉測試，但很快又轉回程序員。為何會這樣，難道說測試不值得他們一試嗎？普遍流行說測試工作如何如何簡單，就是會點點鼠標、按鈕就能做的工作；然而，事實恰恰相反，這些老到的程序員卻是因為測試工作的復雜而沒有既來之，則安之的。

　　軟件測試乍看起來是件簡單的工作，深入其中后，發現并不如所想，程序中各個模塊之間的接口調用錯綜復雜（特別是大型程序），加之程序員的編寫代碼技巧以及個人習慣，使得一個程序有多種編程思路，只為實現功能，而不考慮代碼的優化、效率、易讀性以及接口之間的耦合關系，這樣就會造成各種意想不到的bug，諸多因素都可能產生bug，應該怎么去測試，一個覆蓋面比較全的測試用例文件是必不可少的；當然，程序中的各種復雜關系都是要在用例中考慮和體現的；

　　測試用例是軟件測試的核心，重要性是毋庸置疑的。但如何以最少的人力、資源投入，在最短的時間內完成測試，發現軟件系統的缺陷，保證軟件的優良品質，則是軟件公司探索和追求的目標。每個軟件產品或軟件開發項目都需要有一套優秀的測試方案和測試方法。

　　之前我理解的測試用例僅僅是覆蓋程序面廣的測試方案表，后來知道作為白盒測試的腳本也稱作測試用例，因為腳本的執行過程其實就是測試用例的執行過程，每個具體功能的腳本都是一個用例；

　　定義：

　　測試用例（TestCase）目前沒有經典的定義。比較通常的說法是：指對一項特定的軟件產品進行測試任務的描述，體現測試方案、方法、技術和策略。內容包括測試目標、測試環境、輸入數據、測試步驟、預期結果、測試腳本等，并形成文檔。

　　特點，

　　1、原理上可以完美的全面覆蓋，但不具有顯示意義；

　　2、測試用例不能避免系統帶來的問題，如內存等等；

　　3、隨需求變動；

　　好的用例：

　　不同的軟件要設計不同的用例，以達到資源最優分化，諸如銀行、醫療、航天、政府、科研類似軟件具有高度安全性、保密性的軟件，測試工作的工作量較其他軟件相要大的多；對于一些個人應用軟件相對優先級就會小很多；

　　1、要讓不懂程序的人能看懂，能根據用例進行程序測試工作；

　　2、覆蓋面全

　　3、冗余步驟少

　　4、簡潔明了

　　如何寫？

　　1、根據需求分析結果，編寫每個小功能的測試用例；

　　2、小功能－>模塊->模塊間－>系統；

　　3、長流程；

　　4、路徑；

　　5、特殊操作；

　　設計方法：

　　可以采用軟件測試常用的基本方法：等價類劃分法、邊界值分析法、錯誤推測法、因果圖法、邏輯覆蓋法等設計測試用例。

　　獨具匠心的考慮方法；

　　測試用例中的信息：

　　簡潔信息：編寫時間、測試目的、定義術語、程序名稱、程序說明、參考文檔、版本號；

　　正文內容：用例編號、模塊名稱、測試前提（環境）、用例級別、測試目的、操作步驟、預期結果、備注信息等等；

　　測試的幾個關鍵點：

　　1、臨界點

　　2、互斥操作（touch）

　　3、條件限制

　　4、層次影響（一個界面的操作影響了之前木塊的頁面或者操作）

　　測試用例不是一勞永逸的事情，但是最好的測試方案參考，因為程序不可能永遠不變；

　　對于腳本用例子，可以嘗試為測試腳本編寫測試用例，已確保腳本的正確性，提高測試準確度；

　　評審與維護：

　　1、評審，

　　測試用例的覆蓋面全不全，有無冗余，要有一個專門的機制進行評審，以確定測試用例的可用性；（項目經理、測試組、客戶）

　　2、維護

　　包括了對用例的漏洞補充與及時更新；

　　想法：如果對每次出現問題的位置在用例表上做標記，那么就能在長期使用中做到對模塊設計者的評估；