本篇內容全部蒐集整理自網絡資源
程序測試(program testing)是指對一個完成了全部或部分功能、模塊的計算機程序在正式使用前的檢測，以確保該程序能按預定的方式正確地運行。
軟件測試所追求的是以儘可能少的時間和人力發現軟件產品儘可能多的錯誤。
測試方法：
白盒測試：又稱結構測試，前提是測試者完全知道程序的結構和處理算法，可以把程序看成在一個透明的白盒子裏。按照程序內部邏輯設計測試用例，檢測程序中的主要執行通路是否能按照預定要求正確工作。
黑盒測試：根據關鍵需求說明書所規定的功能來設計測試用例，它不考慮軟件的內部結構和處理算法。
灰盒測試：是一種介於白盒測試與黑盒測試之間的測試方法。灰盒測試關注輸出對於輸入的正確性，同時也關注內部表現，但這種關注不象白盒那樣詳細、完整，只是通過一些表徵性的現象、事件、標誌來判斷內部的運行狀態，有時候輸出是正確的，但內部其實已經錯誤了，這種情況非常多，如果每次都通過白盒測試來操作，效率會很低，因此需要採取這樣的一種灰盒的方法。測試流程：
從測試流程的角度劃分，軟件測試可分爲單元測試、集成測試和確認測試。
單元測試：也稱模塊測試，通常放在編程階段，由程序員對自己編寫的模塊自行測試，檢查模塊是否實現了詳細設計說明書中規定的功能和算法。
單元測試計劃應該在詳細設計階段制定。
集成測試：集成測試（integrationtesting），也稱組裝測試，它是對由各模塊組裝而成的程序進行測試，主要目標是發現模塊間的接口和通信問題。
集成測試計劃應該在概要設計階段制定。
確認測試：主要依據軟件需求說明書檢查軟件的功能、性能及其他特徵是否與用戶的需求一致。
確認測試計劃應該在需求分析階段制定。
單元測試：
單元測試（unit testing），是指對軟件中的最小可測試單元進行檢查和驗證。單元測試是在軟件開發過程中要進行的最低級別的測試活動，軟件的獨立單元將在與程序的其他部分相隔離的情況下進行測試。
誰來做：單元測試是由程序員自己來完成，最終受益的也是程序員自己。可以這麼說，程序員有責任編寫功能代碼，同時也就有責任爲自己的代碼編寫單元測試。
目的：
執行單元測試，就是爲了證明這段代碼的行爲和我們期望的一致。
進行充分的單元測試，是提高軟件質量，降低開發成本的必由之路。程序員通常邊編寫代碼邊測試結果，只 是進行臨時單元測試，針對代碼的測試很不完整，代碼測試的覆蓋率超過70%都很困難，未覆蓋的代碼可能遺留大量的細小的錯誤，這些錯誤還會互相影響，當BUG暴露出來的時候難於調試，大幅度提高後期測試和維護成本，也降低了軟件開發商的競爭力。
對於程序員來說，如果養成了對自己寫的代碼進行單元測試的習慣，不但可以寫出高質量的代碼，而且還能提高編程水平。
要進行充分的單元測試，應專門編寫測試代碼，並與產品代碼隔離。比較簡單的辦法是爲產品工程建立對應的測試工程，爲每個類建立對應的測試類，爲每個函數（很簡單的除外）建立測試函數。
單元測試的好處：
提高開發速度——測試是以自動化方式執行的，提升了測試代碼的執行效率。
提高軟件代碼質量——它使用小版本發佈至集成，便於實現人員除錯。同時引入重構概念，讓代碼更乾淨和富有彈性。
提升系統的可信賴度——它是迴歸測試的一種。支持修復或更正後的“再測試”，可確保代碼的正確性。
單元測試的時機：
單元測試越早越好，根據極限編程（Extreme Programming,或簡稱XP）所推崇的測試驅動開發的思想，即先編寫測試代碼再進行開發。從經驗來看，先編寫產品函數的框架，然後編寫測試函數，針對產品函數的功能編寫測試用例，然後編寫產品函數的代碼，每寫一個功能點都運行測試，隨時補充測試用例。所謂先編寫產品函數的框架，是指先編寫函數空的實現，有返回值的直接返回一個合適值，編譯通過後再編寫測試代碼，這時，函數名、參數表、返回類型都應該確定下來了，所編寫的測試代碼以後需修改的可能性比較小。
成本效率：
一個特定的開發組織或軟件應用系統的測試水平取決於對那些未發現的Bug的潛在後果的重視程度。這種後果的嚴重程度可以從一個Bug引起的小小的不便到發生多次的死機的情況。這種後果可能常常會被軟件的開發人員所忽視（但是用戶可不會這樣），這種情況會長期的損害這些向用戶提交帶有Bug的軟件的開發組織的信譽，並且會導致對未來的市場產生負面的影響。相反地，一個可靠的軟件系統的良好的聲譽將有助於一個開發組織獲取未來的市場。
很多研究成果表明，無論什麼時候作出修改都需要進行完整的迴歸測試，在生命週期中儘早地對軟件產品進行測試將使效率和質量都得到最好的保證。Bug發現的越晚，修改它所需的費用就越高，因此從經濟角度來看， 應該儘可能早的查找和修改Bug。在修改費用變的過高之前，單元測試是一個在早期抓住Bug的機會。
相比後階段的測試，單元測試的創建更簡單，維護更容易，並且可以更方便的進行重複。從全程的費用來考慮，相比起那些複雜且曠日持久的集成測試，或是不穩定的軟件系統來說，單元測試所需的費用是很低的。
優點：
1、它是一種驗證行爲。程序中的每一項行爲都是用來測試和驗證被測程序的正確性。它爲以後的開發提供了支援和保障，就算是開發後期，依舊可以輕鬆的增加功能或改進程序結構，而不用擔心這個過程中會破壞重要的東西；而且它爲代碼的重構提供了保障，這樣可以更自由的對程序進行改進。
2、它是一種設計行爲。編寫單元測試將使我們從調用者的角度觀察、思考、設計以及編寫我們的程序；特別是先寫測試，將迫使我們把程序設計成易於調用和可測試的形式，可以幫助我們軟件中獨立單元之間的耦合性。
3、它是一種編寫文檔的行爲。單元測試是一種無價的文檔，它是展示函數或類如何使用的最佳文檔；這份文檔是可編譯、可運行的，並且它保持最新，永遠與代碼同步。
4、它具有迴歸性。自動化的單元測試可避免代碼出現迴歸，編寫完成之後，可以隨時隨地的快速運行測試。