誤區一、好的用例是能發現未知BUG的用例
首先必須說明，這句話其實是很有道理的，然而很多測試人員都曲解了這句話的原意。他們把測試用例看作孤立的個例，盲目追求設計“難于發現的缺陷”的用例，忘記了測試的目標是盡可能發現程序中存在的缺陷。
軟件測試用例是為了有效發現軟件缺陷而編寫的包含測試目的、測試步驟、期望測試結果的特定集合,對它的評價也只能對測試用例的集合來進行，測試本身是一種驗證加確認(validation &verification)的活動，測試需要保證程序做了它應該做的事情,且沒有做它不該做的事情。
測試用例的好壞應以是否完整有效覆蓋需求為依據，我們不應針對單個的測試用例去評判其好壞，而應對某次測試的用例集合總體作評價。
誤區二、測試用例應該詳盡,使得未接觸系統的人也能進行測試
測試用例描述的詳細程度困擾著許多測試人員。描述簡單的用例不利于用例的傳遞，而描述復雜的用例的設計和維護需要耗費大量的時間。然而很多測試主管或者測試工程師本身，強調測試用例“越詳細越好”，全然不顧實際的測試資源不足的事實，一定要寫出“沒有接觸過系統的人員也能進行測試”的用例。
這種做法無疑會耗費了很多的時間和資源，從而極大的壓縮測試實施的時間和人力，沒有足夠的測試執行時間，就無法發現更多的軟件缺陷，測試質量也就無從談起。
測試活動應需要結合自身的資源(測試人員對系統熟悉程度、測試工程師數量、測試時間等)和項目的需求來進行綜合考量，以實現質量、時間和成本的最佳平衡。我們建議給測試設計安排30%-40%左右的測試時間，測試工程師可以根據項目的具體情況確定測試用例的顆粒度，在測試用例的評審階段由相關人員對其把關即可。
誤區三、測試用例設計是一勞永逸的事情
很多測試人員(尤其是對測試技術不太了解的主管)認為設計測試用例是一次性投入，片面追求測試用例設計一步到位，導致設計的測試用例與需求和設計不同步的情況在實際開發過程屢屢出現。
這種認識造成的危害性在于使得設計的測試用例缺乏實用性，誤報很多不是軟件缺陷的BUG，誤導測試用例執行人員，同時也浪費了開發人員的解決BUG的精力和時間。
幾乎所有軟件項目的開發過程都處于不斷變化(隨著需求的變更)過程中。設計軟件測試用例與軟件開發設計并行進行，必須根據軟件設計的變化，對軟件測試用例進行內容的調整和數量的增減，增加一些針對軟件新增功能的測試用例，刪除一些不再適用的測試用例，修改那些模塊代碼更新了的測試用例。
誤區四、測試用例不包含實際的數據和明顯的驗證手段
測試用例是通常是一組輸入、執行條件、預期輸出結果的組合，毫無疑問地應該包括清晰的輸入數據和預期輸出，沒有測試數據的用例最多只具有指導性的意義，不具備可執行性。例如我們常用的邊界值法就對數據提出了明顯的要求。
很多測試工程師(尤其是測試新手)編寫的測試用例中，“預期輸出”僅描述為程序的可見行為，實際上，“預期結果”的含義并不只是程序的可見行為。例如，對一個代表信息管理系統，輸入代表信息，點擊“保存”按鈕后，系統提示“保存成功”，這樣是不是一個完整的用例呢?是不是系統輸出的“保存成功”就應該作為我們唯一的驗證手段呢?顯然不是，保存是否成功需要查看相應的數據記錄是否在數據庫中更新：在數據庫中執行查詢語句進行查詢，看查詢結果是否與預期的一致。
因此，在測試用例中，還應該包含實際的測試數據和對測試結果的顯式驗證手段。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
