隨著軟件開發技術的發展，軟件測試技術也開始得到人們越來越多的重視，但人們普遍的觀念認為測試活動是在軟件開發的中后期才需要介入的研發步驟，有的開發人員甚至認為測試活動不屬于研發過程，而僅僅是軟件開發完成后依賴黑盒測試…來保證軟件產品質量的一個過程。事實證明，軟件測試是軟件開發過程中的重要階段，是確保軟件質量的關鍵，尤其越是早期的測試活動，對軟件產品質量的影響越是事半功倍。因此，軟件開發階段的測試活動是軟件開發中不容忽視的一個重要環節。

　　一、軟件測試的概念

　　軟件測試是發現錯誤的過程。或者說，軟件測試是根據軟件開發各階段的規格說明和程序的內部結構而精心設計一批測試用例j，利用這些測試用例去運行程序，以發現程序錯誤的過程。

　　從實際測試過程來看，軟件測試過程是由一系列不同的測試階段所組成。軟件開發階段的測試可分為：需求分析審查、設計審查、代碼審查、單元測試、集成測試和系統測試等。需求分析審查、設計審查、單元測試中的代碼評審及各階段測試用例的評審都是通過對相關文檔或代碼的走讀活動來實現的，這種評審活動稱之為靜態測試。靜態測試能發現文檔中存在的問題（也只能通過靜態測試實現），通過對文檔存在問題的分析或其他軟件評審方法來發現需求分析、軟件設計等中的問題。它能有效地檢查代碼是否具有可讀性和可維護性，是否遵守編程規范，包括代碼風格、變量／對類的命名、注釋行等。靜態測試已被當做一種自動化的、主要的代碼校驗方法，它的查錯和分析功能是其他方法所不能替代的。

　　單元測試、集成測試及系統測試等是通過運行軟件來檢驗軟件的動態行為和運行結果正確性的測試方法，它們稱之為動態測試。

　　二、測試活動在軟件開發各個階段的應用與目標

　　1．需求分析審查

　　需求分析是對用戶需求進行確認和整理后對用戶的需求進行性能、安全性、可維護性等項的劃分，并將其細化為多個實現點，將用戶的需求與軟件的設計目標進行關聯，生成需求規格說明書。它不僅是系統測試和用戶文檔的基礎，也是所有子系統項目規劃、設計和編碼的基礎。因此，它描述的準確性至關重要，對其評審即靜態測試活動是不可掉以輕心的。軟件需求規格說明書的評審是由評審專家組在對其仔細研讀的基礎上，站在各自的角度全方位地查找缺陷的過程。主要看其是否盡可能完整地描述系統預期的外部行為和用戶的可視化行為；在功能點的描述上是否具有二義性；在實現上是否具有可行性；通過會議方式將缺陷確認、整理、修改到評審專家組認可。

　　2．設計審查

　　軟件設計分為概要設計和詳細設計，它依據需求規格說明書對系統的具體實現進行描述。概要設計是站在較高的層面上將整個系統進行模塊劃分，并將各功能項盡可能合理地安排在各個模塊中來實現；根據系統的復雜度，可在每個模塊中再進行下一級子模塊的劃分。詳細設計則深入到每一級子模塊當中，涉及到每個功能的具體實現流程、使用的數據結構乃至函數級的具體實現流程。它不但要考慮是否能更好地完成需求規格中向用戶承諾的性能，還要兼顧其可靠性等質量保障。對軟件設計的審查是通過評審專家對設計文檔進行預審后，在評審會議上與設計人員將問題一一確認來實現。

　　評審專家依據需求規格說明書審查設計是否覆蓋到用戶提出的每個功能點，對每個函數流程或偽代碼進行邏輯與語句的審查，更重要的、也是最容易忽視的是要求評審專家要以自己的經驗，重點對設計中使用的數據結構、函數執行效率、資源訪問沖突風險等進行合理評估，以便盡早地把這些對系統開發有著顛覆性影響的問題在編碼及單元測試之前排除。

　　3．代碼審查

　　代碼審查是通過代碼走讀的方式來實現的。代碼走讀是開發人員在對某個模塊的代碼（必須編譯通過）依據設計說明書完成編碼后，進行的代碼評審活動。代碼走讀前要在內部統一標準，明確質量目標。評審中，除了看編碼是否緊扣設計外，走讀還應兼顧三個層面：第一個層可稱之為單元走讀，關注的是“單元”，一般是一個方法或一個類，需要查找代碼層面的錯誤，比如數據庫網絡資源的回收、一些異常的捕捉、空指針的檢查及關鍵字的使用是否正確等；第二個層面可稱之為集成走讀，關注的是接口和流程，包括傳人的參數檢查、返回值檢查及流程能否順利地進行和正確串聯等；第三個層面可稱之為系統走讀，關注的是功能層面和業務邏輯，這時發現更多的應該是邏輯錯誤和功能缺陷。

　　當然，在走讀過程中這三個層面不是截然分開的，很多時候是并行的、互相交織和滲透的。代碼走讀的另一個重要內容是看代碼是否遵守編程規范引，是否具有可讀性和可維護性，注釋是否充足等。按編程規范編碼對提高代碼的可讀性以及降低編碼的出錯率至關重要，在大型項目中，具備可讀性、規范性的代碼更是日后進行有效維護的保障。因此，代碼走讀不僅可以保證代碼的質量，更能有效地促進整個項目的編碼水平。

　4．單元測試

　　單元測試是對軟件中的基本組成單位進行測試，檢驗其函數的正確性（包括功能正常，輸出正確）。

　　一般來說，單元測試用例的編寫最早可以在設計評審完成后就啟動，和編碼可以同時進行。但如果在時間允許的情況下，單元測試用仞』的編寫最好放在編碼后進行，這樣能更好地覆蓋代碼的各個分支。若是以設計文檔為唯一的編寫依據，那么對于代碼走讀時發現的缺陷將在用例評審中被再次發現，造成重復勞動，用例的維護期也將提前開始。

　　單元測試用例編寫的目的是函數覆蓋，覆蓋的方法有：語句覆蓋、分支覆蓋、條件覆蓋、條件組合覆蓋和路徑覆蓋等。為了以最少的資源做最多的測試檢查，首選路徑覆蓋的方法。路徑覆蓋是設計足夠的測試用例，運行所測程序并覆蓋程序中所有可能的路徑。

　　5．集成測試

　　集成測試是軟件系統在集成過程中所進行的測試。其主要目的是檢查軟件單位之間的接口是否正確。其接口主要包括通信協議、調用關系、與文件或數據庫等第三方中間件的交互。

　　集成測試用例的編寫要緊扣與程序相關的各個接口，使每類接口的數據流或控制流均通過接口，從而實現接口測試的完全性。注意：對同一數據流要分別進行正確數據流與錯誤數據流的用例設計，對邊界值的輸入最好有單獨的用例。集成測試還應關注接口的性能問題，根據系統的性能需求還要設計相關的接口性能測試用例。集成測試的執行主要是借助測試工具——樁程序來實現。樁程序的編寫最好由他人來完成，以防止一個人對接口定義理解有偏差而使意外發生。

　　6．系統測試

　　系統測試是對已經集成好的軟件系統進行徹底的測試，以驗證軟件系統的正確性以及性能等是否滿足各系統的需要。換言之，系統測試就是對系統所提供的業務流程進行測試，同時關注軟件的強壯性和易用性等。系統測試應該由若干個不同的測試組成，其目的是充分地運行系統，驗證系統各部件是否都能正常工作，并完成所賦予的任務。除業務測試外，還包括：

　　（1）恢復測試主要檢查系統的容錯能力。恢復測試首先要采用各種辦法強迫系統失敗，然后驗證系統是否能盡快恢復。如拔掉與系統外界通信的網線再插上時，系統各功能能否自動恢復。

　　（2）安全測試檢查系統對非法侵入的防范能力。如測試人員用非法通信程序與系統通信，驗證是否能被系統發現并制止。

　　（3）強度測試檢查系統對異常情況的抵抗能力。強度測試總是迫使系統在異常的資源配置下運行。如在CPU或內存使用率過高或硬盤空間過低時，系統能否有良好的自我保護能力。

　　（4）性能測試雖然集成測試包含性能測試，但只有當系統真正集成之后，在真實環境中才能全面、可靠地進行系統性能測試。性能測試有時與強度測試相結合，經常需要其他軟硬件的配套支持。

　　三、結束語

　　測試活動不是軟件開發后的一個階段，測試的對象也不僅是程序本身。測試活動應貫穿于軟件開發的整個過程，只有這樣，才能更有效率地的開發出有質量保障的優質軟件系統。