一、單元測試
單元測試是針對軟件設計的最小單位——程序模塊，進行正確性檢驗的測試工作。其目的在於發現每個程序模塊內部可能存在的差錯。
單元測試也是程序員的一項基本職責，程序員必須對自己所編寫的代碼保持認真負責的態度，這是也程序員的基本職業素質之一。同時單元測試能力也是程序員的一項基本能力，能力的高低直接影響到程序員的工作效率與軟件的質量。
在編碼的過程中作單元測試，其花費是最小的，而回報卻特別優厚的。在編碼的過程中考慮測試問題，得到的將是更優質的代碼，因為在這時您對代碼應該做些什么 了解得最清楚。如果不這樣做，而是一直等到某個模塊崩潰了，到那時您可能已經忘記了代碼是怎樣工作的。即使是在強大的工作壓力下，您也還必須重新把它弄清 楚，這又要花費許多時間。進一步說，這樣做出的更正往往不會那么徹底，可能更脆弱，因為您喚回的理解可能不那么完全。
通常合格的代碼應該具備以下性質：正確性、清晰性、規范性、一致性、高效性等(根據優先級別排序)。
1. 正確性是指代碼邏輯必須正確，能夠實現預期的功能。
2. 清晰性是指代碼必須簡明、易懂，注釋准確沒有歧義。
3. 規范性是指代碼必須符合企業或部門所定義的共同規范包括命名規則，代碼風格等等。
4. 一致性是指代碼必須在命名上(如：相同功能的變量盡量采用相同的標示符)、風格上都保持統一。
5. 高效性是指代碼不但要滿足以上性質，而且需要盡可能降低代碼的執行時間。
單元測試的方法：
在代碼編寫完成后的單元測試工作主要分為兩個步驟人工靜態檢查和動態執行跟蹤。
人工靜態檢查是測試的第一步，這個階段工作主要是保證代碼算法的邏輯正確性(盡量通過人工檢查發現代碼的邏輯錯誤)、清晰性、規范性、一致性、算法高效性。並盡可能的發現程序中沒有發現的錯誤。
第二步是通過設計測試用例，執行待測程序來跟蹤比較實際結果與預期結果來發現錯誤。經驗表明，使用人工靜態檢查法能夠有效的發現30%到70%的邏輯設計 和編碼錯誤。但是代碼中仍會有大量的隱性錯誤無法通過視覺檢查發現，必須通過跟蹤調試法細心分析才能夠捕捉到。所以，動態跟蹤調試方法也成了單元測試的重 點與難點。
二、集成測試
集成測試是指一個應用系統的各個部件的聯合測試，以決定他們能否在一起共同工作並沒有沖突。部件可以是代碼塊、獨立的應用、網絡上的客戶端或服務器端程序。這種類型的測試尤其與客戶服務器和分布式系統有關。一般集成測試以前，單元測試需要完成。
集成測試是單元測試的邏輯擴展。它的最簡單的形式是：兩個已經測試過的單元組合成一個組件，並且測試它們之間的接口。從這一層意義上講，組件是指多個單元的集成聚合。在現實方案中，許多單元組合成組件，而這些組件又聚合成程序的更大部分。方法是測試片段的組合，並最終擴展進程，將您的模塊與其他組的模塊一起測試。最后，將構成進程的所有模塊一起測試。此外，如果程序由多個進程組成，應該成對測試它們，而不是同時測試所有進程。
集成測試識別組合單元時出現的問題。通過使用要求在組合單元前測試每個單元，並確保每個單元的生存能力的測試計划，可以知道在組合單元時所發現的任何錯誤很可能與單元之間的接口有關。這種方法將可能發生的情況數量減少到更簡單的分析級別。
集成測試的方法：
自下向上集成
對任何系統幾乎都可以采用這一策略。該策略是從低層次的、相互之間依賴性最步的模塊開始的，可以用驅動程序來測試這些模塊。這種策略能用來逐步建立系統，或者首先並行地建立起子系統，然后集成為一個完整系統。這種集成可以從開發過程的早期就開始進行。當然，如果項目計划中模塊提交也是采用自下而上的方式，那么采用這種方法就能夠盡早檢測出接口問題，而且這些接口問題也比較容易被隔離，因此解決起來成本就低。其主要缺點是需要使用許多驅動程序來執行這一策略，而且因為測試需要迭代，所以也是一種非常耗時的策略。
自上向下集成
這種策略由系統的控制結構來引導。控制結構按照自上向下的順序開發，這也提供了從上層控制模塊開始，自上而下集成模塊的能力。對每一個新的層次，位於同一層次的相關模塊被集成起來並得到測試。還不存在的模塊角色可以用占位來實現。采用該集成策略的一個缺點是：如果需求發生了變化，變化對底層模塊產生影響，從而也將導致上層模塊需要更改。這可能導致需要(部分)重新開始集成以及測試過程。另一個缺點是用於測試每個集成步驟所必須用的占位數目很大。如果在早期從上層模塊開始集成測試，即使采用占位來替代系統的主要部件。仍然可以觀察到整個系統的概貌以及工作方式。
三、系統測試
系統測試是將已經確認的軟件、計算機硬件、外設、網絡等其他元素結合在一起，進行信息系統的各種組裝測試和確認測試，其目的是通過與系統的需求相比較，發現所開發的系統與用戶需求不符或矛盾的地方，從而提出更加完善的方案.。它的的任務是盡可能徹底地檢查出程序中的錯誤，提高軟件系統的可靠性，其目的是檢驗系統"做得怎樣？"。這階段又可分為三個步驟：模塊測試，測試每個模塊的程序是否有錯誤；組裝測試，測試模塊之間的接口是否正確；確認測試，測試整個軟件系統是否滿足用戶功能和性能的要求。該階段結束應交付測試報告，說明測試數據的選擇，測試用例以及測試結果是否符合預期結果。測試發現問題之后要經過調試找出錯誤原因和位置，然后進行改正。是基於系統整體需求說明書的黑盒類測試，應覆蓋系統所有聯合的部件。系統測試是針對整個產品系統進行的測試，目的是驗證系統是否滿足了需求規格的定義，找出與需求規格不相符合或與之矛盾的地方。
系統測試的對象不僅僅包括需要測試的產品系統的軟件，還要包含軟件所依賴的硬件、外設甚至包括某些數據、某些支持軟件及其接口等。因此，必須將系統中的軟件與各種依賴的資源結合起來，在系統實際運行環境下來進行測試
系統測試的方法：
１、恢復測試
恢復測試主要檢查系統的容錯能力。當系統出錯時，能否在指定時間間隔內修正錯誤並重新啟動系統。恢復測試首先要采用各種辦法強迫系統失敗，然后驗證系統是否能盡快恢復。對於自動恢復需驗證重新初始化（reinitialization）、檢查點(checkpointing mechanisms)、數據恢復(data recovery)和重新啟動 (restart)等機制的正確性；對於人工干預的恢復系統，還需估測平均修復時間，確定其是否在可接受的范圍內。
２、安全測試
安全測試檢查系統對非法侵入的防范能力。安全測試期間，測試人員假扮非法入侵者，采用各種辦法試圖突破防線。例如，①想方設法截取或破譯口令；②專門定做軟件破壞系統的保護機制；③故意導致系統失敗，企圖趁恢復之機非法進入；④試圖通過瀏覽非保密數據，推導所需信息，等等。理論上講，只要有足夠的時間和資源，沒有不可進入的系統。因此系統安全設計的准則是，使非法侵入的代價超過被保護信息的價值。此時非法侵入者已無利可圖。
３、強度測試
強度測試檢查程序對異常情況的抵抗能力。強度測試總是迫使系統在異常的資源配置下運行。例如，①當中斷的正常頻率為每秒一至兩個時，運行每秒產生十個中斷的測試用例；②定量地增長數據輸入率，檢查輸入子功能的反映能力；③運行需要最大存儲空間（或其他資源）的測試用例；④運行可能導致虛存操作系統崩潰或磁盤數據劇烈抖動的測試用例，等等。
４、 性能測試
對於那些實時和嵌入式系統，軟件部分即使滿足功能要求，也未必能夠滿足性能要求，雖然從單元測試起，每一測試步驟都包含性能測試，領測認為只有當系統真正集成之后，在真實環境中才能全面、可靠地測試運行性能系統性能測試是為了完成這一任務。性能測試有時與強度測試相結合，經常需要其他軟硬件的配套支持。