在g.j.myers
的經典著作《軟體測試之藝術》（
the art of software testing
）中，給出了測試的定義：「程式測試是為了發現錯誤而執行程式的過程」。這個定義，被業界所認可，經常被引用。除此之外，
g.j.myers
測試是為了證明程式有錯，而不是證明程式無錯誤；
乙個好的測試用例是在於它能發現至今未發現的錯誤；
乙個成功的測試是發現了至今未發現的錯誤的測試。
實際上，這裡暗示了「軟體測試」在不同側面上的含義，也就決定了對軟體測試不同的定義和不同的理解。根據作者多年的經驗和理解，軟體測試的不同視野，概括為如下5類：
軟體測試的狹義論和廣義論——靜態和動態的測試
軟體測試的辨證論——正向思維和反向思維
軟體測試的風險論——測試是評估
軟體測試的經濟學觀點——為盈利而測試
軟體測試的標準論——驗證和確認
1. 軟體測試的狹義論和廣義論
g.j.myers
所給出了測試定義——「程式測試是為了發現錯誤而執行程式的過程」，實際是乙個狹義的概念，因為他認為測試是執行程式的過程，也就是傳統意義上的測試——在**完成後，通過執行程式來發現程式**或軟體系統中錯誤。但是，這種意義上的測試是不能在**完成之前發現軟體系統需求、發現設計上的問題，把需求、發現設計上的問題遺留到後期，這樣就會可能造成設計、程式設計的部分返工。增加軟體開發的成本、延長開發的週期等。需求階段和設計階段的缺陷產生的放大效應會加大。這非常不利於保證軟體質量。這種狹義論是受軟體開發瀑布模型影響。
正是為了更早地發現問題，所以將測試延伸到需求評審、設計審查活動中去，也就是將「軟體質量保證」的部分活動歸為測試活動。實際上，在軟體開發實際操作中，常常將軟體測試和質量保證——這兩種努力（efforts
）合併起來。
延伸後的軟體測試，被認為是一種軟體測試的廣義概念。這就引出軟體測試的兩個概念「靜態測試」和「動態測試」，如測試方法的辯證統一 （1
）所述，這樣就由靜態測試和動態測試構成乙個全過程的、完整的軟體測試，而且靜態測試顯得更為重要。
2.軟體測試的辨證論
g.j.myers的第2
個觀點「測試是為了證明程式有錯，而不是證明程式無錯誤」，引出了軟體測試的另外乙個爭論，軟體測試究竟是證明所有軟體的功能特性是正確的呢？還是其反向思維——對軟體系統進行各種試探和攻擊，找出軟體系統中不正常或不工作的地方呢？從我個人理解，這兩個方面都有一定道理，前者（證明所有軟體的功能特性是正確的）是從質量保證的角度來思考軟體測試，後者（證明程式有錯）從軟體測試的直接目標和測試效率來思考，兩者應該相輔相成。在後者的思想背景下，我們認為，測試不是為了證明所有的功能可以正常工作，恰恰相反，測試就是為了找出那些不能正常工作、不一致性的地方。也就是說，測試的一般工作就是發現缺陷
(detect bug)
，即在軟體開發過程中，分析、設計與編碼等工作都是建設性的，而測試是帶有「破壞性」的工作。
對於不同的應用領域，兩者的比重是不一樣的，如國防、航天、銀行等軟體系統，承受不了任何系統失效，因為一次系統的失效完全有可能導致災難性的損失，所以強調前者以保證非常高的軟體質量。而一般的軟體服務應用則不同，強調後者，質量目標設定在「使用者可接受水平」，不要國度追求質量，從而可以降低軟體開發成本。作者建議，在我們實際操作中，可以分階段實施不同的測試思想，在早期階段集中在「證明程式有錯」——發現bug
，後期集中在驗證所有特性是否正常工作——降低風險，見作者的另外一篇討論：測試執行中非常有效的策略
下面就是這兩種觀點的基本描述：
驗證軟體是驗證軟體是「工作的」，以正向思維，針對軟體系統的所有功能點，逐個驗證其正確性。其代表人物是軟體測試領域的先驅dr. bill hetzel
（代表論著《
the complete guide to software testing》)
。 證明軟體是「不工作的」，以反向思維方式，不斷思考開發人員理解的誤區、不良的習慣、程式**的邊界、無效資料的輸入以及系統的弱點，試圖破壞系統、摧毀系統，目標就是發現系統中各種各樣的問題。其代表人物就是上面多次提到的g.j.myers
。他強調，乙個成功的測試必須是發現
bugbug
的測試，不然就沒有價值。
3.軟體測試的風險論
測試被定義為「對軟體系統中潛在的各種風險進行評估的活動」，這就是軟體測試的風險論。軟體測試自身的風險性是大家公認的，測試的覆蓋度不能做到100
％。測試的這種風險定義一方面源於這層含義，另外軟體測試的標準有時不清楚，「軟體規格說明書（
specification/ spec
）」是其中的乙個標準，但也不是唯一的，因為
spec
中有些內容完全有可能是錯誤的。所以，我們常常強調軟體測試人員應該站在客戶的角度去進行測試，除了發現程式中的錯誤，還要發現需求定義的錯誤、設計上的缺陷，可以針對
spec
去報bug
。但是，測試在大多數時間
/情況下
,是由工程師完成，而不是客戶自己來做，所以又怎麼能保證工程師和客戶想得一樣呢？
有人把開發比作打靶，目標明確，就是按照spec
去實現系統的功能。而把測試比作撈魚，目標不明確，自己判斷哪些地方魚多，就去哪些地方撈；如果只撈大魚（嚴重缺陷），網眼就可以大些、撒網區域相對比較集中（測試點集中在主要功能
-major features
）。如果想把大大小小的魚撈上來，網眼就要小、普遍撒網，不放過任何一塊區域（測試點遍及所有功能——
all features）。
在「風險」論的框架下，軟體測試可以被看作是乙個動態的監控過程，對軟體開發全過程進行檢測，隨時發現不健康的徵兆，發現問題、報告問題，並重新評估新的風險，設定新的監控基準，不斷地持續下去，包括回歸測試。這時，軟體測試可以完全看作是軟體質量控制的過程。
對應這種觀點，產生基於風險的測試策略，首先評估測試的風險，功能出問題的概率有多大？哪些是使用者最常用的20
％功能——
pareto
原則（也叫
80/20
原則）？如果某個功能出問題，其對使用者的影響有多大？然後根據風險大小確定測試的優先順序。優先順序高的測試，優先得到執行，一般來講，針對使用者最常用的
20％功能（優先順序高）的測試會得到完全執行，而低優先順序的測試（另外使用者不經常用的
80％功能）就不是必要的，如果時間或經費不夠，就暫時不做或少做。
4.軟體測試的經濟學觀點
「乙個好的測試用例是在於它能發現至今未發現的錯誤」，體現了軟體測試的經濟學觀點。實際上，軟體測試經濟學問題至今仍是業界關注的問題之一。經濟學的核心就是要盈利，盈利的基礎就是要有乙個清楚的商業性目標。同樣，商業性目標是否正確，直接決定了企業是否盈利的結果。多數情況下，軟體測試是在公司內的執行。正是公司的行為目的，決定了軟體測試含義或定義的經濟性一面。正如，對軟體質量的定義不僅僅局陷於「和客戶需求的一致性、適用性」，而且要增加其它的要求——「預算內、按時發布、易於維護」。
軟體測試也一樣，要盡快盡早地發現更多的缺陷，並督促和幫助開發人員修正缺陷。原因很簡單：平均而言，如果在需求階段修正乙個錯誤的代價是1
，那麼，在設計階段就是它的3～
6倍，在程式設計階段是它的
10倍，在內部測試階段是它的20～
40倍，在外部測試階段是它的30～
70倍，而到了產品發布出去時，這個數字就是 40～
1000
倍。修正錯誤的代價不是隨時間線性增長，而幾乎是呈指數級增長的。
5. 軟體測試的標準論
如果從標準論來看軟體測試，可以定義為軟體測試就是「驗證（verification
）」和「有效性確認（
validation
）」活動構成的整體，即軟體測試
= v&v。
「驗證」是檢驗軟體是否已正確地實現了產品規格書所定義的系統功能和特性。驗證過程提供證據表明軟體相關產品與所有生命週期活動的要求（如正確性、完整性、一致性、準確性等）相一致。相當於，以spec
為標準進行軟體測試活動，驗證軟體產品和
spec
的一致性。
「有效性確認」是確認所開發的軟體是否滿足使用者真正需求的活動。相當於，保持對軟體需求定義、設計的懷疑，一切從客戶出發，理解客戶的需求，發現需求定義和產品設計中的問題。這主要通過各種軟體評審活動來實現。
需要說明的是，軟體測試的物件是產品（包括階段性產品，如市場需求說明書、產品規格說明書、技術設計文件、資料字典、程式包、使用者文件等），而質量保證和管理的物件集中在軟體開發的標準、流程和方法等。
究竟什麼是軟體測試呢？綜上所述，軟體測試的定義為：
軟體測試是貫穿整個軟體開發生命週期、對軟體產品（包括階段性產品）進行驗證和確認的活動過程，
其目的是盡快盡早地發現在軟體產品中所存在的各種問題——與使用者需求、預先定義的不一致性。
軟體測試 測試的概念
1.什麼是軟體測試？軟體測試是為了發現錯誤而執行程式的過程。或者說，軟體測試是根據軟體開發各階段的規格說明和程式的內部結構而精心設計一批測試用例 即輸入資料及其預期的輸出結果 並利用這些測試用例去執行程式，以發現程式錯誤的過程。2.軟體測試的目的？測試的目的是想以最少的人力 物力和時間找出軟體中潛在...
軟體測試概念
一 應用伺服器的分類 1.1 web伺服器 1.2 資料庫伺服器 例如db2 1.3 ftp伺服器 1.4 郵件伺服器 1.5 檔案共享伺服器 例如雲盤 多層結構的劃分方式 使用者介面層 互動 表示邏輯層 介面和內容顯示 業務邏輯層 資料通訊 基礎框架服務層 資料通訊的其他支援 資料層 資料庫 資料...
軟體測試 概念
在開始軟體測試之前有必要先了解軟體的基本概念。這些基本概念將幫助我們更加明確工作的目標，以便於更快的融入測試團隊中去。我們需要明確的給出以下問題的答案 目的 驗證軟體有或者沒有問題 原則 以客戶為中心，遵循軟體測試的規範 流程 標準和要求。滿足使用者的期望 或 規定的文件 合同，標準，規範 所需要的...