軟件系統的開發包括一系列生產活動，其中由人帶來的錯誤因素非常多。錯誤可能出現在程序的最初…，其時目標可能是錯誤的或描述不完整，也可能在后期的設計和開發階段…，因為人們不能完好無缺地工作和交流，軟件開發過程中必須伴有質量保證活動。
軟件測試是軟件質量保證的關鍵元素，代表了規約、設計和編碼的最終檢查。
軟件作為系統元素的可見性不斷增加軟件故障帶來的代價太高使得人們注重于規劃良好的徹底測試，軟件開發組織將30%—40%的項目精力花在測試上并不為怪。另一方面，人命悠關的軟件(如飛行控制和核反應堆)測試所花的時間往往是其他軟件工程活動時間之和的三到五倍。
以下討論軟件測試基礎和設計軟件測試用例的技術。軟件測試基礎定義了軟件測試的目標，測試用例的設計討論符合整體目標的測試用例創建技術。
1.1軟件測試基礎
測試為軟件工程師帶來了很有趣的意外。在軟件過程的早期，軟件工程師試圖由抽象概念到具體實現來建立軟件，現在來了測試，工程師創建測試用例試圖“摧毀”已經建立的軟件。事實上，在軟件工程過程中，測試可以看成(至少心理上)摧毀性的而不是建設性的。
軟件開發者就其本性而言是建設者，測試要求開發者放棄剛開發的軟件是正確的觀念，并克服發現錯誤時的心理矛盾。Beizers［BEI90］如下描述了這種情況：
如果我們真正擅長編程，就應當不會有錯誤，但這只是一個神話。如果我們真的很認真，如果每個人都使用結構化方法，自頂向下設計而且使用決策表，如果程序是用SQUISH寫的，如果我們有合適的銀彈，就不會有錯誤了，這樣，神話就不存在。因為我們并不擅長所做的事，所以有錯誤，如果不擅長，就應當感到內疚。因此，測試和測試用例設計是對失誤的承認，它注入了一針內疚劑。測試的枯燥是對我們錯誤的處罰，為什么處罰？為了人？為什么內疚？為了沒能達到人類的完美境界？為了沒有區別另一個程序員所想的和所說的？為了沒有心靈感應？為了沒有解決人類四千年來尚未解決的相互通信問題？
測試真的應當注入內疚感？測試真的是摧毀性的？這些問題的回答是“不！”，然而，測試的目標可能和我們所期待的不同。
1.1.1測試目標
Glen Myers［MYE79］在他的軟件測試著作中陳述了一系列關于測試目標的規則：
1.測試是一個為了尋找錯誤而運行程序的過程。
2.一個好的測試用例是指很可能找到迄今為止尚未發現的錯誤的用例。
3.一個成功的測試是指揭示了迄今為止尚未發現的錯誤的測試。
上述目標蘊含了一個觀點上的戲劇性變化，他們轉向通常的觀點，即一個成功的測試是指沒有找到錯誤的測試。我們的目標是設計這樣的測試，它們能夠系統地揭示不同類型的錯誤，并且耗費最少時間與最小工作量。
如果成功構造了測試(根據上述目標)，則能夠在軟件中揭示錯誤。測試的第二個好處在于它證實了軟件依據規約所具有的功能及其性能需求，此外，構造測試時的數據收集提供了軟件可*性以及軟件整體質量的一些信息。但是，有一件事測試無法完成：
測試無法說明錯誤不存在，它只能表示軟件錯誤已經出現。
在構造測試時必須牢記這一點。
文章來源于領測軟件測試網 http://www.kjueaiud.com/