誤區(qū)一、好的用例是能發(fā)現(xiàn)未知BUG的用例首先必須說明，這句話其實是很有道理的，然而很多測試人員都曲解了這句話的原意。他們把測試用例看作孤立的個例，盲目追求設計“難于發(fā)現(xiàn)的缺陷”的用例，忘記了測試的目標是盡可能發(fā)現(xiàn)程序中存在的缺陷。
軟件測試用例是為了有效發(fā)現(xiàn)軟件缺陷而編寫的包含測試目的、測試步驟、期望測試結(jié)果的特定集合，對它的評價也只能對測試用例的集合來進行，測試本身是一種驗證加確認(validation &verification)的活動，測試需要保證程序做了它應該做的事情，且沒有做它不該做的事情。
測試用例的好壞應以是否完整有效覆蓋需求為依據(jù)，我們不應針對單個的測試用例去評判其好壞，而應對某次測試的用例集合總體作評價。
誤區(qū)二、測試用例應該詳盡，使得未接觸系統(tǒng)的人也能進行測試測試用例描述的詳細程度困擾著許多測試人員。描述簡單的用例不利于用例的傳遞，而描述復雜的用例的設計和維護需要耗費大量的時間。然而很多測試主管或者測試工程師本身，強調(diào)測試用例“越詳細越好”，全然不顧實際的測試資源不足的事實，一定要寫出“沒有接觸過系統(tǒng)的人員也能進行測試”的用例。
這種做法無疑會耗費了很多的時間和資源，從而極大的壓縮測試實施的時間和人力，沒有足夠的測試執(zhí)行時間，就無法發(fā)現(xiàn)更多的軟件缺陷，測試質(zhì)量也就無從談起。
測試活動應需要結(jié)合自身的資源(測試人員對系統(tǒng)熟悉程度、測試工程師數(shù)量、測試時間等)和項目的需求來進行綜合考量，以實現(xiàn)質(zhì)量、時間和成本的最佳平衡。我們建議給測試設計安排30%-40%左右的測試時間，測試工程師可以根據(jù)項目的具體情況確定測試用例的顆粒度，在測試用例的評審階段由相關人員對其把關即可。
誤區(qū)三、測試用例設計是一勞永逸的事情很多測試人員(尤其是對測試技術不太了解的主管)認為設計測試用例是一次性投入，片面追求測試用例設計一步到位，導致設計的測試用例與需求和設計不同步的情況在實際開發(fā)過程屢屢出現(xiàn)。
這種認識造成的危害性在于使得設計的測試用例缺乏實用性，誤報很多不是軟件缺陷的BUG，誤導測試用例執(zhí)行人員，同時也浪費了開發(fā)人員的解決BUG的精力和時間。
幾乎所有軟件項目的開發(fā)過程都處于不斷變化(隨著需求的變更)過程中。設計軟件測試用例與軟件開發(fā)設計并行進行，必須根據(jù)軟件設計的變化，對軟件測試用例進行內(nèi)容的調(diào)整和數(shù)量的增減，增加一些針對軟件新增功能的測試用例，刪除一些不再適用的測試用例，修改那些模塊代碼更新了的測試用例。
誤區(qū)四、測試用例不包含實際的數(shù)據(jù)和明顯的驗證手段測試用例是通常是一組輸入、執(zhí)行條件、預期輸出結(jié)果的組合，毫無疑問地應該包括清晰的輸入數(shù)據(jù)和預期輸出，沒有測試數(shù)據(jù)的用例最多只具有指導性的意義，不具備可執(zhí)行性。例如我們常用的邊界值法就對數(shù)據(jù)提出了明顯的要求。
很多測試工程師(尤其是測試新手)編寫的測試用例中，“預期輸出”僅描述為程序的可見行為，實際上，“預期結(jié)果”的含義并不只是程序的可見行為。例如，對一個代表信息管理系統(tǒng)，輸入代表信息，點擊“保存”按鈕后，系統(tǒng)提示“保存成功”，這樣是不是一個完整的用例呢?是不是系統(tǒng)輸出的“保存成功”就應該作為我們唯一的驗證手段呢?顯然不是，保存是否成功需要查看相應的數(shù)據(jù)記錄是否在數(shù)據(jù)庫中更新：在數(shù)據(jù)庫中執(zhí)行查詢語句進行查詢，看查詢結(jié)果是否與預期的一致。
因此，在測試用例中，還應該包含實際的測試數(shù)據(jù)和對測試結(jié)果的顯式驗證手段。
誤區(qū)五、測試輸入數(shù)據(jù)設計方法等同于測試用例設計方法現(xiàn)在流行的一些測試書籍認為，測試用例的設計方法包括：等價類、錯誤推測法、場景設計法、邊界值法、因果圖法等。這種表述是極其片面的，這些方法只是軟件功能測試用例設計中如何確定測試輸入數(shù)據(jù)的方法，而不是測試用例設計的全部內(nèi)容。
確定測試的輸入數(shù)據(jù)對于軟件功能測試和性能測試的重要性不言而喻，它決定了測試的有效性和效率。但是，測試用例中輸入數(shù)據(jù)的確定方法只是測試用例設計方法的一個很小的方面，除了確定測試輸入數(shù)據(jù)之外，測試用例的設計還包括如何根據(jù)需求和行業(yè)軟件的具體設計規(guī)范確定測試用例的設計策略、設計用例的表示方法以及測試用例組織管理形式等問題。
我們絕對不能從心理上忽視測試用例設計內(nèi)容的豐富性和技術的復雜性，而應綜合考慮被測軟件的功能、特性、組成元素、測試用例組織方法等內(nèi)容。
誤區(qū)六、讓測試新手設計測試用例很多測試新手被要求從測試用例的設計學起，往往感到無從下手。實際上，測試新手設計的測試用例往往存在設計出的測試用例對軟件功能和特性的覆蓋度不高、功能設計的顆粒度不合理、可復用性差等諸多缺陷。
軟件測試用例設計是軟件測試的中高級技能，不是每個人(尤其是測試新手)都可以編寫的，測試用例編寫者不僅要掌握軟件測試的技術和流程，而且要對被測軟件的需求、功能規(guī)格說明以及程序結(jié)構(gòu)等有比較透徹的理解。
我們建議安排經(jīng)驗豐富的測試人員進行測試用例設計，測試新手可以從執(zhí)行測試用例開始，隨著測試人員的測試技術的提高和對被測軟件的熟悉，可以學習測試經(jīng)驗豐富的測試人員的用例設計經(jīng)驗，嘗試編寫測試用例。
相關推薦：
考試吧策劃：2010年軟件水平考試完全指南
2010年11月計算機軟件水平考試備考寶典匯總
