軟件測試之“軟件測試用例設計原則”

　　不管是從個人角度還是從公司角度，根據我這幾年的經驗我覺得case的設計應該符合以下幾點：

　　1、一個case一個功能點：每個case都要有個測點，找準一個測點則可，不能同時覆蓋很多功能點，否則執行起來牽連太大;

　　2、case的易讀：從執行者的角度去寫case，最好不要有太多的術語在里面，如果要有最好指明具體位置;

　　3、case的執行粒度：粒度越小越好;軟件

　　4、步驟清晰：一個case多個步驟，可一個重點，步驟指名人們怎么去操作，expect則指明這樣操作之后應該看到什么結果---最好不要用正確，正常，錯誤之類的含糊主觀的字眼。

　　5、總體設計：先正常，后異常，這樣可以確保正常情況下功能能夠走通。

　　總之：對于一個新來的tester，給他個case和我們的軟件，他就能順利取執行case，這是最佳狀態，也是我們case設計的標準，按照這個標準，我想出了以上幾點要求。

　　這樣做的好處是：

　　1、執行者不會因為case看不懂再三的去煩擾你，你也不會因為時間長了，業務忘了，看不懂case;

　　2、如果原來的designer有事，公司可以很快請人頂上，測試可以繼續進行，不會被block住;

　　3、執行case的人能更快的去掌握業務系統流程，不會因為要看懂一個case而大傷腦筋，更別說去真正的執行它了。

　　那么對于日常軟件測試每個新功能，我們該怎么去構筑我們堅固的質量堡壘呢。

　　根據開發過程的特點，總結了我們設計測試用例六個方面。

　　一、功能

　　關注頁面單個功能點驗證，充分考慮開發改動的每個點。這個是保證開發每個已知的修改點都能改對。

　　二、關聯

　　重點考慮修改點對其他模塊的影響，包括代碼的影響和操作數據引起的影響。

　　比如新增加的功能增加了數據庫表的字段，必須關聯的驗證每個使用該表的該字段的模塊是否正常工作。難點在于需要分析出已知和未知的影響模塊，考慮的越多，往往遺漏的問題就越少。

　　三、流程

　　很多系統是有流程的，比如工作流系統。當修改了一個點的時候，我們必須考慮整個流程是否能夠正常運轉起來。

　　四、升級

　　我們大部分系統都是對已有的系統進行升級。對于升級前的數據，我們必須保證能夠正常工作。升級之前，需要模擬好各種情況。也需要對升級的數據庫腳本進行充分的檢查。

　　五、安全

　　比如菜單功能權限等。

　　六、性能

原文轉自：http://www.anti-gravitydesign.com