1.
什麼是軟體測試
在g.j.myers
的經典著作《軟體測試之藝術》（
the art of software testing
）中，給出了測試的定義：「程式測試是為了發現錯誤而執行程式的過程」。這個定義，被業界所認可，經常被引用。除此之外，
g.j.myers
還給出了與測試相關的三個重要觀點，那就是： l
測試是為了證明程式有錯，而不是證明程式無錯誤； l
乙個好的測試用例是在於它能發現至今未發現的錯誤； l
乙個成功的測試是發現了至今未發現的錯誤的測試。
實際上，這裡暗示了「軟體測試」在不同側面上的含義，也就決定了對軟體測試不同的定義和不同的理解。根據作者多年的經驗和理解，軟體測試的不同視野，概括為如下5類：
l軟體測試的狹義論和廣義論——靜態和動態的測試
靜態：文件的測試。
動態：為了發現錯誤而執行程式的過程。 l
軟體測試的辨證論——正向思維和反向思維
正向思維：驗證軟體是驗證軟體是「工作的」。
針對軟體系統的所有功能點，逐個驗證其正確性。其代表人物是軟體測試領域的先驅
dr. bill hetzel
（代表論著《
the complete guide to software testing》)
逆向思維：證明軟體是「不工作的」。
不斷思考開發人員理解的誤區、不良的習慣、程式**的邊界、無效資料的輸入以及系統的弱點，試圖破壞系統、摧毀系統，目標就是發現系統中各種各樣的問題。其代表人物就是上面多次提到的
g.j.myers
。他強調，乙個成功的測試必須是發現
bug的測試，不然就沒有價值。 l
軟體測試的風險論——測試是評估
測試被定義為「對軟體系統中潛在的各種風險進行評估的活動」，這就是軟體測試的風險論。
既然不能做到完美，那麼就應該根據明確的目標（例如：規格說明書），加上恰當的策略（例如：二八原則、專案週期約束、成本約束、資源約束等），按照優先順序進行評估活動。 l
軟體測試的經濟學觀點——為盈利而測試
「乙個好的測試用例是在於它能發現至今未發現的錯誤」，體現了軟體測試的經濟學觀點。實際上，軟體測試經濟學問題至今仍是業界關注的問題之一。經濟學的核心就是要盈利，盈利的基礎就是要有乙個清楚的商業性目標。同樣，商業性目標是否正確，直接決定了企業是否盈利的結果。多數情況下，軟體測試是在公司內的執行。正是公司的行為目的，決定了軟體測試含義或定義的經濟性一面。正如，對軟體質量的定義不僅僅局陷於「和客戶需求的一致性、適用性」，而且要增加其它的要求——「預算內、按時發布、易於維護」。
軟體測試也一樣，要盡快盡早地發現更多的缺陷，並督促和幫助開發人員修正缺陷。原因很簡單：平均而言，如果在需求階段修正乙個錯誤的代價是1
，那麼，在設計階段就是它的3～6倍，在程式設計階段是它的10倍，在內部測試階段是它的20～40倍，在外部測試階段是它的30～70倍，而到了產品發布出去時，這個數字就是40～1000倍。修正錯誤的代價不是隨時間線性增長，而幾乎是呈指數級增長的。
l軟體測試的標準論——驗證和確認
如果從標準論來看軟體測試，可以定義為軟體測試就是「驗證（
verification
）」和「有效性確認（
validation
）」活動構成的整體，即軟體測試
= v&v
。「驗證」是檢驗軟體是否已正確地實現了產品規格書所定義的系統功能和特性。
驗證過程提供證據表明軟體相關產品與所有生命週期活動的要求（如正確性、完整性、一致性、準確性等）相一致。相當於，以
spec
為標準進行軟體測試活動，驗證軟體產品和
spec
的一致性。
「有效性確認」是確認所開發的軟體是否滿足使用者真正需求的活動。
相當於，保持對軟體需求定義、設計的懷疑，一切從客戶出發，理解客戶的需求，發現需求定義和產品設計中的問題。這主要通過各種軟體評審活動來實現。
需要說明的是，軟體測試的物件是產品（包括階段性產品，如市場需求說明書、產品規格說明書、技術設計文件、資料字典、程式包、使用者文件等），而質量保證和管理的物件集中在軟體開發的標準、流程和方法等。
軟體測試基本理論
一 軟體的開發階段劃分 1 需求分析階段 由需求分析師完成 產出物 需求文件 2 設計階段 1 概要設計 產出物 概要說明書 2 詳細設計 產出物 詳細說明書 一般是由系統架構師 分析師 完成 3 編碼階段 程式設計師注 一般公司只有產品文件和原型，所以如果你的公司這些文件都有，那麼請珍惜吧。常見面...
軟體測試基本理論 一
從即日起,關於 軟體測試 基礎教程正式開篇.本教程適合想學習軟體測試方面的同學.完全從0開始,由淺入深開始學習.本教程持續更新,歡迎關注.是線性模型的一種，在所有模型中占有重要地位，是所有其他模型的乙個基礎.每乙個階段執行一次，按線性順序進行軟體開發.測試階段在軟體實現後,必須在 完成後留出足夠多的...
軟體測試基本理論 IBM模式
ibm 從菜鳥到測試架構師 乙個測試工程師的成長日記 warning ibm的業務性質是做大型企業的it解決方案，仍然屬於比較中規中矩的傳統企業。所以對傳統的軟體企業有比較大的借鑑意義，但是對於網際網路等新興企業的從業人員，還是採取保留式的態度，取其精華即可。1968年nato會議提出了 軟體危機 ...