軟體測試用例的設計心得

1、了解軟體的原始需求（測試目的）

　　在編寫一個軟體或者子產品的測試用例時候，一定要明白這個功能的原始需求，也就是軟體的使用者（客戶）的需求。了解原始需求後，編寫的測試用例才更有目的性。

　　2、熟悉軟體的功能需求（測試點）

　　這個功能需求是指軟體的細化需求點，這個一般在需求文檔裡面都會展現。這裡要做的是把 “粗略”的需求，細化成一個個小需求點。熟悉功能需求後，要知道軟體是怎麼使用的，這也才能覆寫到各種操作。

　　總之，測試用例一定要全部覆寫所有的需求點，這是最基本的一點。

　　3、熟悉軟體的實作原理（測試點）

　　在了解原始需求和軟體的功能需求後，根據需求編寫的測試用例，基本上都能覆寫得比較全面了。

　　在此基礎上，熟悉軟體的實作原理，了解軟體的内部處理。

　　（1）熟悉原理的過程是進一步深入熟悉軟體的過程。如果單單是從需求點上面覆寫案例，測試用例隻能覆寫“表面”的一層。一些内部的處理流程也許沒有覆寫到，而這些沒有覆寫到的代碼很可能就是一個風險點。

　　（2）熟悉子產品原理後，還有一點就是易于分析軟體子產品的關聯性。一個大型的軟體，都是一些小子產品的組合而成。軟體越是大型，耦合就越大，“互相影響”就會越多，若設計用例單單從子產品本身考慮的話，很可能就會對其他子產品造成風險。

　　4、使用者場景和網上問題（測試點）

　　從使用者的使用場景考慮，這在一些網絡裝置比較重要，比如軟體後期在一些真實的使用環境中使用。

　　還要就是從一些網上問題總結出來的，那些地方容易出錯，在設計案例的時候需要考慮進去 。

　　5、測試用例的架構

　　一個測試用例的架構展現了一個測試人員在設計測試用例的整體思路。架構也是從大到小劃分下來，可以是：

　　ui界面，功能，容錯，相容，性能等幾大類，每個大類在根據軟體的邏輯等進行劃分成小類，最後細分到測試點。

　　6、測試步驟（測試技巧方法）

　　前面4點都是從測試點的角度考慮，測試用例在完成測試點外，接下來就是測試步驟和測試結果啦。

　　測試用例可以寫的很詳細，也可以寫的比較簡單。這要看公司的要求，有些公司要求測試步驟很細很細，包括測試結果和測試步驟一一對應。

　　要求測試步驟寫的很詳細的公司，一般是怕執行人員的執行力不到位，導緻沒有了解案例的目的，導緻漏測。一般出現在新員工對軟體系統的不熟悉。

　　如果測試步驟寫的很詳細的話，會很耗時間，而且過于詳細的會限制執行人員的思維。個人認為測試用例的重點在于測試點上。

　　7、測試用例的一些思路

　　在設計測試用例中，通常較多使用的是邊界值，等價類，通過和不通過測試。下面從單個子產品或者單個功能點考慮：（結合一些網上文章的觀點）

　　（1）ui界面：易用性，提示資訊，整體布局，按鈕圖示，色彩，中英文标點錯别字。

　　（2）資料的多樣性：有效資料，合法的無效資料（邊界值），非法的異常資料，産生錯誤輸出的合法資料組合等各種資料的組合。

　　（3）操作多樣性：添加删除編輯查詢 ，多使用者的操作。

　　（4）容量測試

　　（5）使用者權限：使用權限，各種操作的權限。

　　（6）更新安裝解除安裝：平滑更新

　　（7）日志相關（包括調試日志）

　　（8）軟體功能的邏輯劃分：功能上劃分未能覆寫的代碼邏輯，可以添加白盒灰盒用例。

　　（9）可靠性，容錯性

　　（10）相容性：浏覽器，系統，支撐軟體。

　　（11）安全性

　　（12）性能（這裡的性能是指，單個子產品或者子系統的性能）

　　總之測試用例首先要能覆寫所有功能需求點，然後搞懂軟體處理邏輯，可以找開發一起看測試用例，把沒有覆寫到的代碼流程相應的用例補充，至此，用例基本不會出現基本功能的問題。

　　在此基礎上，可以進行一些可靠性，容錯性，相容性等用例的設計，測試下軟體的穩定性。