1、測試的定義 

軟件測試是軟件工程過程的一個重要階段，是在軟件發布前對軟件開發各階段產品的最終檢查，是為了保證軟件開發產品的正確性、完全性和一致性而檢測軟件錯誤、修正軟件錯誤的過程。

軟件測試是：

① 程序測試是為了發現錯誤而執行程序的過程；

② 測試是為了證明程序有錯，而不是證明程序無錯誤；

③ 一個好的測試用例是在于它能發現至今未發現的錯誤；

④ 一個成功的測試是發現了至今未發現的錯誤的測試。

軟件開發的目的是開發出實現用戶需求的高質量、高性能的軟件產品，而軟件測試是以檢查軟件功能和其他非功能特性為核心，是軟件質量保證的關鍵，也是成功實現軟件開發目標的重要保障。

2、測試的種類

從測試方法角度，測試分為：

1．黑盒測試：是功能測試、數據驅動測試或基于規格說明的測試。在不考慮程序內部結構和內部特性的情況下，測試者依據該程序功能上的輸入輸出關系，或是程序的外部特性來設計和選擇測試用例，推斷程序編碼的正確性。

2．白盒測試：是結構測試、邏輯驅動測試或基于程序的測試。測試者熟悉程序的內部結構，依據程序模塊的內部結構來設計測試用例，檢測程序代碼的正確性

從測試發生的時間順序，測試分為：

1．單元測試：是對軟件基本單元的測試

2．集成測試：對由個模塊組裝而成的系統進行測試，檢查各模塊間的接口和通信

3．驗收測試：驗證軟件的功能和性能及其它特性是否與用戶的要求一致。

4．系統測試：是將通過驗收測試的軟件，作為整個基于計算機系統的一個元素，與計算機硬件、外設、某些支持軟件、數據等其它系統元素結合在一起，在實際運行環境下，對計算機系統進行一系列確認測試。系統測試的目的在于通過與系統的需求定義作比較,  發現軟件與系統的定義不符合或與之矛盾的地方。

在MSF中，測試分為2大類：

1．覆蓋測試：找出程序中的缺陷，即是否該找的地方都找了；單元測試、功能測試、檢入測試、構造驗證測試、回歸測試。

2．使用測試：找出程序中的失敗，即為什么使用不成功；配置測試、兼容性測試、強度測試、性能測試、文檔和幫助文件測試、α/β測試。

3、測試的執行過程 

測試主要由下面6個相互關聯、相互作用的過程組成：

1．測試計劃

確定各測試階段的目標和策略。這個過程將輸出測試計劃，明確要完成的測試活動，評估完成活動所需要的時間和資源，設計測試組織和崗位職權，進行活動安排和資源分配，安排跟蹤和控制測試過程的活動。

2．測試設計

根據測試計劃設計測試方案。測試設計過程輸出的是各測試階段使用的測試用例。測試設計也與軟件開發活動同步進行，其結果可以作為各階段測試計劃的附件提交評審。測試設計的另一項內容是回歸測試設計，即確定回歸測試的用例集。對于測試用例的修訂部分，也要求進行重新評審。

3．測試實施

使用測試用例運行程序，將獲得的運行結果與預期結果進行比較和分析，記錄、跟蹤和管理軟件缺陷，最終得到測試報告4．測試配置管理

測試配置管理是軟件配置管理的子集，作用于測試的各個階段。其管理對象包括測試計劃、測試方案（用例）、測試版本、測試工具及環境、測試結果等。一般會得到一個基線測試用例庫。

5．資源管理

包括對人力資源和工作場所，以及相關設施和技術支持的管理。如果建立了測試實驗室，還存在其他的管理問題。

6．測試管理

采用適宜的方法對上述過程及結果進行監視，并在適用時進行測量，以保證上述過程的有效性。如果沒有實現預定的結果，則應進行適當的調整或糾正。

4、幾種測試類型的介紹

4.1單元測試

單元測試是對最小的可測試軟件元素（單元）實施的測試，它所測試的內容包括內部結構（如邏輯和數據流）以及單元的功能和可觀測的行為。側重于單元內部結構的測試設計和實施依賴于對單元實施情況的了解（白盒方法）。為核實單元的可觀測行為和功能而進行的測試設計和實施并不依賴于對實施情況的了解，因而被稱為黑盒方法。

單元測試是一種非常高效的測試方法，并且是軟件測試周期中第一個進行的測試。加強單元測試力度有利于降低缺陷定位和修復難度，從而降低缺陷解決成本，同時加強單元測試也減輕了后續集成測試和系統測試的負擔。

單元測試一般是由開發工程師執行的。

4.1.2方法 

單元測試一般要做以下三項工作

a.設計測試用例

b.編寫測試代碼

c.執行待測程序

其中測試用例的設計是很重要的一步，好的測試用例的原則是：

a.能夠發現至今沒有發現的錯誤

b.測試用例應由測試輸入數據和與之對應的預期輸出結果這兩部分組成

c.應當包含合理的輸入條件和不合理的輸入條件。

可以依照以下方法來設計測試用例：

1、程序中每一條可執行語句至少被執行一次。

2、程序中每一個分支判斷的每一種可能結果(主要指switch-case情況)都至少被執行一次。

3、程序中每一個分支判斷中的每一個條件的可能結果都至少被執行一次。

4、程序中每一個分支判斷中的每一個條件的每一種可能組合結果都至少被執行一次。

5、程序中所有的可能路徑都至少被執行一次。

4.1.3常用的工具 

常用的單元測試工具有 NUnit 和 NUnitAsp。

注意：NUnit和NUnitAsp具體的用法見相關的文檔。 

4.2、回歸測試

4.2.1定義

回歸測試是指根據修復好了的缺陷再重新進行的測試。

回歸測試作為軟件生命周期的一個組成部分，在整個軟件測試過程中占有很大的工作量比重，軟件開發的各個階段都會進行多次回歸測試。

回歸測試的目的在于驗證以前出現過但已經修復好的缺陷不再重新出現。一般指對某已知修正的缺陷再次圍繞它原來出現時的步驟重新測試。

當軟件中所含錯誤被發現時，如果錯誤跟蹤與管理系統不夠完善，就可能會遺漏對這些錯誤的修改；而開發者對錯誤理解的不夠透徹，也可能導致所做的修改只修正了錯誤的外在表現，而沒有修復錯誤本身，從而造成修改失敗；修改還有可能產生副作用從而導致軟件未被修改的部分產生新的問題，使本來工作正常的功能產生錯誤。同樣，在有新代碼加入軟件的時候，除了新加入的代碼中有可能含有錯誤外，新代碼還有可能對原有的代碼帶來影響。因此，每當軟件發生變化時，我們就必須重新測試現有的功能，以便確定修改是否達到了預期的目的，檢查修改是否損害了原有的正常功能。

回歸測試一般是由測試工程師執行的。  

4.2.2方法 

一般進行回歸測試的步驟如下：

1.建立測試基線,這是回歸測試的前提。具體方式是將所有的測試用例放到配置庫中，打上版本標記。

2.從基線測試用例庫中提取合適的測試用例組成回歸測試包，必要時進行開發和重新設計整理。

3.在后續開發過程中，每次測試之前先運行回歸測試包。

保存在基線測試用例庫中的測試用例可能是自動測試腳本，也有可能是測試用例的手工實現過程。

4.2.3常用的工具 

在實際工作中，回歸測試需要反復進行，當測試者一次又一次地完成相同的測試時，這些回歸測試將變得非常令人厭煩，為了提高回歸測試的效率，我們可以使用些自動化回歸測試工具。常用的工具有WinRunner等，具體的用法見相關的文檔。

4.3性能測試

4.3.1目的

性能測試的目的是驗證軟件系統是否能夠達到用戶提出的性能指標，同時發現軟件系統中存在的性能瓶頸，優化軟件，最后起到優化系統的目的。

包括以下幾個方面：

一．評估系統的能力，測試中得到的負荷和響應時間數據可以被用于驗證所計劃的模型的能力，并幫助作出決策。

二．識別體系中的弱點：受控的負荷可以被增加到一個極端的水平，并突破它，從而修復體系的瓶頸或薄弱的環節。

三．系統調優：重復運行測試，驗證調整系統的活動得到了預期的結果，從而改進性能。檢測軟件中的問題：長時間的測試執行可導致程序發生由于內存泄露引起的失敗，揭示程序中的隱含的問題或沖突。

四．驗證穩定性（resilience）可靠性（reliability）：在一個生產負荷下執行測試一定的時間是評估系統穩定性和可靠性是否滿足要求的唯一方法。

4.3.2定義 

性能測試主要測試軟件的性能，包括負載測試，強度測試，數據庫容量測試，基準測試以及競爭測試。

負載測試：負載測試是一種性能測試,指當數據在超負荷環境中運行時程序是否能夠承擔。在這種測試中，將使測試對象承擔不同的工作量，以評測和評估測試對象在不同工作量條件下的性能行為，以及持續正常運行的能力。負載測試的目標是確定并確保系統在超出最大預期工作量的情況下仍能正常運行。此外，負載測試還要評估性能特征，例如，響應時間、事務處理速率和其他與時間相關的方面。

強度測試：強度測試是一種性能測試，它在系統資源特別低的情況下測試軟件系統運行情況。實施和執行此類測試的目的是找出因資源不足或資源爭用而導致的錯誤。如果內存或磁盤空間不足，測試對象就可能會表現出一些在正常條件下并不明顯的缺陷。而其他缺陷則可能由于爭用共享資源（如數據庫鎖或網絡帶寬）而造成的。強度測試還可用于確定測試對象能夠處理的最大工作量。

數據庫容量測試：數據庫容量測試指通過存儲過程往數據庫表中插入一定數量的數據，看看相關頁面是否能夠及時顯示數據。數據庫容量測試使測試對象處理大量的數據，以確定是否達到了將使軟件發生故障的極限。容量測試還將確定測試對象在給定時間內能夠持續處理的最大負載或工作量。

基準測試：基準測試是一種與已知現有的系統進行比較，主要檢驗是否與類似的產品具有競爭性的一種測試。

競爭測試：軟件競爭使用各種資源（數據紀錄，內存等），看他與其他相關系統對資源的爭奪能力。比如：一臺機器上既安裝您的財務系統，又安裝用友財務系統。當CPU占有率下降后，看看是否能夠強過用友財務系統，而是自己的系統能夠正常運行？

4.3.3 方法 

做性能測試一般可以通過一些三方的工具來實現

4.3.4常用的工具 

性能測試一般都是通過工具來完成的，常用的工具有 Microsoft Application Center Test(ACT)。

5、測試計劃的制定

5.1制定的階段

測試計劃是與軟件開發活動同步進行的。 在MSF的構想(Envisioning)階段,要制定測試策略和測試的驗收標準。在計劃(Planning)階段),要完成和評審測試計劃及所用到的資源。在開發(Developing)階段,要完成和評審單元測試計劃。對于測試計劃的修訂部分，需要進行重新評審。

5.2制定過程中要考慮的因素 

1.應明確的在測試計劃中確立好測試管理機制的關鍵事件,如。

a.匯報機制。確定好用周報制度還是日報制度，日報的反饋速度越快，定位解決問題越快，但信息處理工作量大。

b.例會制度。每周舉行一次例會，根據實際情況，考慮測試計劃的調整或滾動。

c.實施怎樣的實驗室管理制度，以做到責任明確。

d.在日報中的工作匯報。不僅要包括發現的問題，還應包括在測試時新創造的測試點，這些測試點應該補充到測試計劃中作為一個測試項；

e.人員情緒如何調整。在測試周期過長時，影響測試效率的一個重要因素是測試人員的情緒，一個人反復測試一個模塊，總是會出現厭倦情緒的。

2.應明確的在測試計劃中確立數據的管理和分析體系的辦法,如：專人對提交的過程文檔,周報報告中的數據予以整理和管理，以便后期在系統測試評審時作為數據來分析。

現在往往是在系統測試結束后才來收集數據，可能會造成數據的不同程度失真或滯后。收集的數據可以按不同種類來劃分。這可以依賴我們系統的CHECKLIST。有一種工具叫 SRES (軟件可靠性專家系統) 是很有用的，我們可以按照它的輸入數據來收集。