測試用例制定原則和測試用例的重用 軟件測試
一、測試用例制定的原則
測試用例要包括欲測試的功能、應輸入的數據和預期的輸出結果。測試數據應該選用少量、高效的測試數據進行盡可能完備的測試；基本目標是：設計一組發現某個錯誤或某類錯誤的測試數據，測試用例應覆蓋方面：
1、 正確性測試：輸入用戶實際數據以驗證系統是滿足需求規格說明書的要求；測試用 例中的測試點應首先保證要至少覆蓋需求規格說明書中的各項功能，并且正常。
2、 容錯性（健壯性）測試：程序能夠接收正確數據輸入并且產生正確（預期）的輸出， 輸入非法數據（非法類型、不符合要求的數據、溢出數據等），程序應能給出提示 并進行相應處理。把自己想象成一名對產品操作一點也不懂的客戶，在進行任意操作。
3、 完整（安全）性測試：對未經授權的人使用軟件系統或數據的企圖，系統能夠控制的程度，程序的數據處理能夠保持外部信息（數據庫或文件）的完整。
4、 接口間測試：測試各個模塊相互間的協調和通信情況，數據輸入輸出的一致性和正確性。
5、 數據庫測試：依據數據庫設計規范對軟件系統的數據庫結構、數據表及其之間的數據調用關系進行測試。
6、 邊界值分析法：確定邊界情況（剛好等于、稍小于和稍大于和剛剛大于等價類邊界值），針對我們的系統在測試過程中主要輸入一些合法數據/非法數據，主要在邊界值附近選取。
7、 壓力測試：輸入10條記錄運行各個功能，輸入30條記錄運行，輸入50條記錄運行。。。進行測試。
8、等價劃分：將所有可能的輸入數據（有效的和無效的）劃分成若干個等價類。
9、錯誤推測：主要是根據測試經驗和直覺，參照以往的軟件系統出現錯誤之處。
10、效率：完成預定的功能，系統的運行時間（主要是針對數據庫而言）。
11、可理解（操作）性：理解和使用該系統的難易程度（界面友好性）。
12、可移植性：在不同操作系統及硬件配置情況下的運行性。
13、回歸測試：按照測試用例將所有的測試點測試完畢，測試中發現的問題開發人員 已經解決，進行下一輪的測試。
14、比較測試：將已經發版的類似產品或原有的老產品與測試的產品同時運行比較，或與已往的測試結果比較 。
說明：針對不同的測試類型和測試階段，測試用例編寫的側重點有所不同。
1、 其中第1、2、6、8、9、13項為模塊（組件、控件）測試、組合（集成）測試、系統測試都涉及并重點測試的方面。
2、 單元（模塊）測試（組件、控件）測試：重點測試第5項。
3、 組合（集成）測試：重點進行接口間數據輸入及邏輯的測試，即第4項。
4、 系統測試：重點測試第3、7、10、11、12、14項。
5、 其中壓力測試和可移植性測試如果是公司的系列產品，可以選用其中有代表性的產品進行一次代表性測試即可。
6、 GMPS基礎測試用例設計完成后，其他的測試項目只編寫設計與之不同部分的測試用例。
7、 對于每個測試項目測試的測試用例不是一成不變的，隨著測試經驗的積累或在測試其他項目發現有測試不充分的測試點時，可以不斷的補充完善測試項目的測試用例。
二、測試用例的重用
跟測試工程師打交道最多的可能就是測試用例了，先設計出一些測試用例，然后這些測試用例要經過評審，之后要執行這些測試用例，完了以后還有可能需要對這些測試用例進行更新。測試用例的重用是一個很有必要的活動。那怎么重用呢？很多人可能第一時間想到了一些測試管理工具能幫上忙，例如Quality Center，Test Link；又或者是一些保存測試用例的工具，例如Word，Excel。
不過這些東西真的能幫助我們重用測試用例么？我想未必。測試用例的重用，應該是測試用例里面的設計思想的重用，而不是具體某個測試用例的，因為對于功能測試的測試用例來說，大多數的測試用例都跟某個具體的被測應用有想到大的關聯性，例如要測試一個博客編輯器，對于MySpace的博客編輯器和 facebook的博客編輯器來說，它們的主要功能是相似的，都有發表博客，編輯博客，修改博客等……但是由于這是兩個不同公司的產品，他們的具體功能或者UI是完全不一樣的，所以拿到的兩套測試用例，也應該是不一樣的。如果分別提取出測試用例的核心思想（就是那些可以重用的部分），應該能看到很多的共同點，或許會有這么一條共同的用例思想。
1. 打開博客編輯器
2. 點擊插入視頻的按鈕
3. 粘貼視頻代碼
4. 點擊保存，發布
期望結果是該視頻能正確顯示在博客上。
這條用例可以提取為“驗證博客編輯器能夠插入視頻”，至于實現的細節，可能兩家的處理不一樣，可能前者用<object>標簽，后者用<embed>標簽�；氐綄嶋H的測試用例，前者可能要求將博客編輯器切換到HTML編輯模式下，要看到<object>….</object>的代碼，另外一個就是要檢查有<embed>….< /embed>的代碼。其實測試用例是測試工程師之間的很好的溝通交流工具。通常在一些研討會上，有人拋出一個問題“對于日期輸入框大家會怎么進行測試”，大家接著七嘴八舌地進行討論，這樣的討論結果就是大家都知道了一些，又好像不知道一些。如果這時候有人拿出自己的測試用例，那么會不會更加一目了然，更加有系統性？
舉個例子
CRUD模式（創建，獲取，更新，刪除）
1. 選擇并確定出一條記錄或者一個字段
2. 產生一個隨機的等價類item
3. 檢查這個新產生的item是沒有存在的
4. 添加一個新的item
5. 讀取并且驗證這個item的正確性
6. 修改該item并且驗證item確是已經被修改
7. 刪除該item并且驗證item缺少已經刪除
以上測試用例可以應用于不同的場景，例如MySpace中的一個帳號，也可以是一條歌單，還可以是一篇博客。這種類型的用例才是可重用的，而不是發布一篇博客，修改博客，刪除博客……測試用例的重用，也就是測試用例的精華部分，其設計思想，而不是一些存在QC,TD中的 01010100101001。
文章來源于領測軟件測試網 http://www.kjueaiud.com/