顯然，這樣的測試對完善和提高軟體質量毫無價值。因為在程式中往往存在著許多預料不到的問題，可能會被疏漏，許多隱藏的錯誤只有在特定的環境下才可能暴露出來。如果不把著眼點放在儘可能查詢錯誤這樣一個基礎上，這些隱藏的錯誤和缺陷就查不出來，會遺留到執行階段中去。如果站在使用者的角度，替他們設想，就應當把測試活動的目標對準揭露程式中存在的錯誤。在選取測試用例時，考慮那些易於發現程式錯誤的資料。

　　有鑑於此，Grenford J．Myers就軟體測試目的提出以下觀點：

　　（1）測試是程式的執行過程，目的在於發現錯誤；

　　（2）一個好的測試用例在於能發現至今未發現的錯誤；

　　（3）一個成功的測試是發現了至今未發現的錯誤的測試。

　　測試的目標是想以最少的時間和人力找出軟體中潛在的各種錯誤和缺陷。如果成功地實施了測試，就能夠發現軟體中的錯誤。測試的附帶收穫是，它能夠證明軟體的功能和效能與需求說明相符。此外，實施測試收集到的測試結果資料為可靠性分析提供了依據。

　　根據這樣的測試目的，軟體測試的原則應該是：

　　（1）應當把“儘早地和不斷地進行軟體測試”作為軟體開發者的座右銘。

　　由於原始問題的複雜性，軟體的複雜性和抽象性，軟體開發各個階段工作的多樣性，以及參加開發各種層次人員之間工作的配合關係等因素，使得開發的每個環節都可能產生錯誤。所以不應把軟體測試僅僅看作是軟體開發的一個獨立階段，而應當把它貫穿到軟體開發的各個階段中。堅持在軟體開發的各個階段的技術評審，這樣才能在開發過程中儘早發現和預防錯誤，把出現的錯誤克服在早期，杜絕某些隱患，提高軟體質量。

　　（2）測試用例應由測試輸入資料和與之對應的預期輸出結果這兩部分組成。

　　測試以前應當根據測試的要求選擇在測試過程中使用的測試用例（Test case）。測試用例主要用來檢驗程式設計師編制的程式，因此不但需要測試的輸入資料，而且需要針對這些輸入資料的預期輸出結果。如果對測試輸入資料沒有給出預期的程式輸出結果，那麼就缺少了檢驗實測結果的基準，就有可能把一個似是而非的錯誤結果當成正確結果。

　　（3）程式設計師應避免檢查自己的程式。

　　測試工作需要嚴格的作風，客觀的態度和冷靜的情緒。人們常由於各種原因具有一種不願否定自己工作的心理，認為揭露自己程式中的問題總不是一件愉快的事。這一心理狀態就成為測試自己程式的障礙。另外，程式設計師對軟體規格說明理解錯誤而引入的錯誤則更難發現。如果由別人來測試程式設計師編寫的程式，可能會更客觀，更有效，並更容易取得成功。要注意的是，這點不能與程式的除錯（debuging）相混淆。除錯由程式設計師自己來做可能更有效。

　　（4）在設計測試用例時，應當包括合理的輸入條件和不合理的輸入條件。

　　合理的輸入條件是指能驗證程式正確的輸入條件，而不合理的輸入條件是指異常的，臨界的，可能引起問題異變的輸入條件。在測試程式時，人們常常傾向於過多地考慮合法的和期望的輸入條件，以檢查程式是否做了它應該做的事情，而忽視了不合法的和預想不到的輸入條件。事實上，軟體在投入執行以後，使用者的使用往往不遵循事先的約定，使用了一些意外的輸入，如使用者在鍵盤上按錯了鍵或打入了非法的命令。如果開發的軟體遇到這種情況時不能做出適當的反應，給出相應的資訊，那麼就容易產生故障，輕則給出錯誤的結果，重則導致軟體失效。因此，軟體系統處理非法命令的能力也必須在測試時受到檢驗。用不合理的輸入條件測試程式時，往往比用合理的輸入條件進行測試能發現更多的錯誤。

　　（5）充分注意測試中的群集現象。

　　測試時不要以為找到了幾個錯誤問題就已解決，不需繼續測試了。經驗表明，測試後程序中殘存的錯誤數目與該程式中已發現的錯誤數目或檢錯率成正比。根據這個規律，應當對錯誤群集的程式段進行重點測試，以提高測試投資的效益。

　　在所測程式段中，若發現錯誤數目多，則殘存錯誤數目也比較多。這種錯誤群集性現象，已為許多程式的測試實踐所證實。例如美國IBM公司的0s／370作業系統中，47 9／6的錯誤僅與該系統的4％的程式模組有關。這種現象對測試基於不同的立場，存在著兩種完全不同的測試目的。從使用者的角度出發，普遍希望通過軟體測試暴露軟體中隱藏的錯誤和缺陷，以考慮是否可以接受該產品。而從軟體開發者的角度出發，則希望測試成為表明軟體產品中不存在錯誤的過程，驗證該軟體已正確地實現了使用者的要求，確立人們對軟體質量的信心。因此，他們會選擇那些導致程式失效概率小的測試用例，迴避那些易於暴露程式錯誤的測試用例。同時，也不會著意去檢測、排除程式中可能包含的副作用。

　　顯然，這樣的測試對完善和提高軟體質量毫無價值。因為在程式中往往存在著許多預料不到的問題，可能會被疏漏，許多隱藏的錯誤只有在特定的環境下才可能暴露出來。如果不把著眼點放在儘可能查詢錯誤這樣一個基礎上，這些隱藏的錯誤和缺陷就查不出來，會遺留到執行階段中去。如果站在使用者的角度，替他們設想，就應當把測試活動的目標對準揭露程式中存在的錯誤。在選取測試用例時，考慮那些易於發現程式錯誤的資料。

　　（6）嚴格執行測試計劃，排除測試的隨意性。

　　測試計劃應包括：所測軟體的功能，輸入和輸出，測試內容，各項測試的進度安排，資源要求，測試資料，測試工具，測試用例的選擇，測試的控制方式和過程，系統組裝方式，跟蹤規程，除錯規程，以及迴歸測試的規定等以及評價標準。

　　對於測試計劃，要明確規定，不要隨意解釋。

　　（7）應當對每一個測試結果做全面檢查。

　　這是一條最明顯的原則，但常常被忽視。有些錯誤的徵兆在輸出實測結果時已經明顯地出現了，但是如果不仔細地全面地檢查測試結果，就會使這些錯誤被遺漏掉。所以必須對預期的輸出結果明確定義，對實測的結果仔細分析檢查，抓住徵候，暴露錯誤。

　　（8）妥善儲存測試計劃，測試用例，出錯統計和最終分析報告，為維護提供方便。

　　很有用。如果發現某一程式模組似乎比其他程式模組有更多的錯誤傾向時，則應當花費較多的時間和代價測試這個程式模組。