各種類型的測試
1. 單元測試
是對軟件或硬件基本組成單元進行的測試。其測試對象是每個模塊下的實現具體功能的單元，一般對應詳細設計中描述的設計單位。在具體實現時，對應的是一個或一組函數，可能需要開發 測試驅動模塊或者測試工具。單元測試屬於早期測試，其側重點在於發現程序設計或實現的邏輯錯誤，主要屬於白盒測試的範疇。
2. 集成測試
對部分模塊的組合測試，驗證組成系統的各部件之間接口和集成問題，這裏不同模塊往往是分配給不同的程序設計開發人員。
3. 系統測試
針對全部需求說明進行黑盒測試，包括系統中所有部件。總體包括功能測試和性能測試兩部分，功能測試是驗證系統功能是否實現產品需求的測試過程，性能測試在驗證是否實現產品需求的基礎上，進一步測試系統的容錯性、穩定性、異常處理能力、高強度輸入處理能力等系統性能方面的測試過程。其側重點在於考察功能的需求規格符合性、功能設計或實現的用戶滿意度，以及系統性能的穩定性，主要屬於黑盒測試的範疇。
4. 驗收測試
確定系統是否滿足客戶驗收標準而執行的正式測試，測試的結果將決定客戶是否接收該系統。
5. 驗證和確認
按照CMMI的定義，驗證關注工作產品是否恰當的反映了對應的需求，而確認是證明所提交的產品實現了用戶的要求。據此，單元測試、集成測試和系統測試屬於驗證（Verification）的內容，而驗收測試屬於確認（Validation）的內容。
6. 迴歸測試
版本更改後重新進行的測試，測試時既要測試改動部分，也要測試受影響部分，迴歸測試的關鍵在於決定哪些測試必須被重複，以及測試工作的可重現性。
7. 冒煙測試
主要測試被測系統是否具有基本運行功能，如啓動、加載、執行基本操作等。冒煙測試在採用每日構建的開發策略中可以對構建結果進行即時驗證，也可以作爲驗證被測系統是否滿足測試入口條件、達到測試就緒狀態的方法。
8. 性能測試
一般情況下，軟件項目中的需求、開發和測試工作總是過於關注系統的功能，直到後期才關注系統的非功能性問題。實踐證明，這種方法會給系統帶來隱患，增大產品失敗的風險，在項目後期需要付出極大的努力進行改正。軟件的非功能方面包括軟件的性能、可維護性、可擴展性、安全性和可使用性等。其中性能測試在軟件的質量保證中起着重要作用，它主要包括三個方面的測試內容：客戶端性能測試、網絡性能測試、服務器端性能測試。通常情況下，三個方面有效結合，可以達到對系統性能起全面的分析和瓶頸的預測。
9. 白盒測試
白盒測試也稱爲結構測試或者邏輯驅動測試，它是在知道產品內部實現過程的情況下，通過測試來檢查產品內部動作是否按照規格說明書的規定正常進行。檢驗程序中的每條路徑是否都能按預定要求正確工作，而不管它的整體功能。白盒測試的方法主要有邏輯驅動、路徑測試等，主要用於產品驗證。
10. 灰盒測試
介於白盒和黑盒測試之間的一種測試，關注輸出對於輸入的正確性，同時也關注程序內部表現，但這種關注不象白盒那麼詳細完整，只是通過一些現象、事件、標誌來判斷內部的運行狀態，有時輸出是正確的，但內部其實已經發生錯誤，因此需要採取這樣的灰盒測試方法來發現此類問題。
12. 黑盒測試
也稱爲功能測試或數據驅動測試，它是在已知產品應該具有的功能的情況下，通過測試來檢測每個功能是否都能正常使用，在測試時完全不考慮程序內部結構，只檢查程序功能是否按照需求說明書的規定正常使用，程序是否能適當的接收輸入數據而產生正確的輸出信息，並保證外部信息（如數據庫或文件）的完整性。
13. 敏捷測試
這個目前沒有找到標準定義。一般理解，在採用敏捷開發模式的項目中進行的測試，稱爲敏捷測試。 需要大家再補充。
集成測試
1. 什麼是集成測試？
集成測試又稱爲“組裝測試”“聯合測試”。集成測試遵循特定的策略與步驟 將已經通過單元測試的各軟件單元（或模塊）逐步組合在一起進行測試，以期望通過測試發現各軟件單元接口之間存在的問題。
理論上，凡是兩個單元（如函數單元）的組合測試都可以稱爲集成測試。實際操作中，通常集成測試的對象爲模塊級的集成和子系統間的集成，其中子系統集成測試又稱爲組件測試。
2. 爲什麼要進行集成測試？
（1）在單元測試與系統測試間起到承上啓下的作用。
既能發現大量單元測試階段不容易發現的接口類錯誤，又可以保證在進入系統測試前 及早發現錯誤，縮短錯誤修復時間。
（2）對被測系統而言，接口錯誤是最常見的錯誤。
單元測試通常是單人執行，而集成測試通常是多人執行或第三方執行。集成測試通過模塊間的交互作用和不同人的理解和交流，更容易發現實現上、理解上的不一致和差錯。
3. 集成測試內容
集成測試需要關注：
（1）穿越接口的數據是否會丟失
（2）一個模塊的功能是否會對另一個模塊的功能產生不利影響
（3）實現子功能的模塊組合起來是否能夠達到預期的總體功能
（4）全局數據結構的測試
（5）共享資源訪問的測試
（6）單個模塊的誤差經過集成的累加效應
具體測試內容：
（1）集成功能測試
（2）接口測試（函數接口、消息接口）
（3）全局數據結構測試
（4）資源測試
（5）任務優先級衝突測試
（6）性能和穩定性測試
（7）軟硬件接口測試
3.1 集成功能測試
（1）集成單元實現的功能，集成後的功能，考察多個模塊間的協作，既要滿足集成後實現的複雜功能，也不能衍生出不需要的多餘功能（錯誤功能）。
（2）主要關注：
a. 被測對象的各項功能是否實現。
b. 異常情況是否有相關的錯誤處理。
c. 模塊間的協作是否高效合理。
3.2 接口測試
（1）模塊間的接口包括函數接口和消息接口。
（2）對函數接口的測試，需要關注函數接口參數的類型和個數的一致性、輸入/輸出屬性的一致性、範圍的一致性。
（3）對消息接口的測試，需要關注收發雙方對消息參數的定義是否一致、消息和消息隊列長度是否滿足設計要求、消息的完整性如何、消息的內存是否在發送過程中被非法釋放、有無對消息隊列阻塞進行處理等。
3.3 全局數據結構測試
全局數據結構往往存在被非法修改的隱患，測試時需要關注：
（1）全局數據結構的值在兩次被訪問的間隔是可預知的。
（2）全局數據結構的各個數據段的內存不應被錯誤釋放。
（3）多個全局數據結構間是否存在緩存越界。
（4）多個軟件單元對全局數據結構的訪問應採用鎖保護機制。
3.4 資源測試
資源測試包括共享資源測試和資源極限測試。共享資源測試常應用於數據庫測試和支撐的測試。
共享資源測試需要關注：
（1）是否存在死鎖現象。
（2）是否存在過度利用情況。
（3）是否存在對共享資源的破壞性操作。
（4）公共資源訪問鎖機制是否完善。
資源極限測試關注系統資源的極限使用情況以及軟件對資源耗盡時的處理，保證軟件系統在資源耗盡的情況下不會出現系統崩潰。
3.5 任務優先級衝突測試
多任務環境中，需要測試任務優先級的合理性，需要考慮以下因素：
（1）實時性要求高的功能是否在高優先級任務中完成。
（2）任務優先級設計是否滿足用戶操作相應時間要求。
3.6 性能和穩定性測試
測試某個部件的性能指標，及時發現性能瓶頸。穩定性測試關注：
（1）是否存在內存泄漏而導致長期運行資源耗盡。
（2）長期運行後是否出現性能的明顯下降。
（3）長期運行是否出現任務掛起。
4. 集成測試步驟
（1）測試計劃：策略、方案、進度計劃。
（2）設計和開發：測試規程、測試工具開發。
（3）測試執行：搭建環境、運行。
（4）測試評估：測試報告。
5. 集成測試注意事項
（1）集成測試活動必須納入項目計劃，並安排相應工作量。
（2）集成測試之前必須先做單元測試，而且單元測試對覆蓋率應該有比較高的要求。
（3）做好集成測試，良好的組織非常重要，需要指定一個稱職的集成測試組長。
（4）集成測試需要儘早考慮自動測試工具的開發。
系統測試
1. 什麼是系統測試？
爲了發現缺陷並度量產品質量，按照系統的功能和性能需求進行的測試。
（1）一般使用黑盒測試技術。
（2）一般由獨立的測試人員完成。
（3）對於模塊間交互性比較強的軟件，還會有單獨的集成測試，用來發現模塊接口之間的錯誤。
2. 爲什麼要進行系統測試？
（1）確保產品完成了它所承諾或公佈的功能，並且所有用戶可以訪問到的功能都有明確的書面說明。
（2）確保產品滿足性能和效率的要求。
（3）確保產品是健壯的和適應用戶環境的。
3. 系統測試內容
3.1 功能測試
目標：對產品的功能進行測試，檢驗是否實現、是否正確實現了產品功能。
方法：覆蓋產品的所有功能。
工具：迴歸測試時可以使用工具。
3.2 性能測試
目標：對產品的性能進行測試，檢驗是否達標、是否能夠保持產品性能。
方法：覆蓋系統的性能需求，一般和負載測試結合使用。
工具：在需要大訪問量時尤其需要使用工具。
3.3 負載測試
目標：在人爲設置的高負載（大數據量、大訪問量）情況下，檢查系統是否發生功能或性能上的問題。
方法：人爲生成大數據量，並使用工具模擬頻繁併發訪問。
工具：一般需要使用工具。
3.4 壓力測試
目標：在人爲設置的系統資源緊缺情況下，檢查系統是否發生功能或者性能上的問題。
方法：人爲減少可用的系統資源，如：內存、硬盤、網絡、CPU佔用、數據庫響應時間。。
工具：一般需要使用工具。
3.5 疲勞測試
目標：在一段時間內（至少72小時）保持系統功能的頻繁使用，檢查系統是否發生功能或者性能上的問題。
方法：人爲設置不同功能的連續重複操作。
工具：一般需要使用工具。
3.6 易用性測試
目標：檢查系統界面和功能是否容易學習、使用方式是否規範一致，是否會誤導用戶或者使用模糊的信息。
一般與功能測試結合使用。
方法：可以採用用戶操作、觀察、反饋並評估的方式。
3.7 安裝測試
目標：
a. 檢查系統安裝是否能夠安裝所有需要的文件/數據 並進行必要的系統設置；
b. 檢查系統安裝是否會破壞其他文件或配置；
c. 檢查系統安裝是否可以中止並恢復現場；
d. 檢查系統是否能夠正確卸載並恢復現場；
e. 檢查安裝和卸載過程的用戶提示和功能是否出現錯誤。
有時安裝測試作爲功能測試的一部分。
3.8 配置測試
目標：在不同的硬件配置下，在不同的操作系統和應用軟件環境中，檢查系統是否發生功能或者性能上的問題。
方法：一般需要建立測試試驗室。
3.9 文檔測試
目標：檢查系統的文檔是否齊全，檢查是否有多餘文檔，檢查文檔內容是否正確/規範/一致。
方法：一般由單獨一組測試人員實施。
3.10 安全測試（包括病毒、加密、權限）
目標：
a. 檢查系統是否有病毒；
b. 檢查系統是否正確加密；
c. 檢查系統在非授權的內部或外部用戶訪問或故意破壞時是否出現錯誤。
3.11 恢復測試
目標：在人爲使系統發生災難（系統崩潰、硬件損壞、病毒入侵等）情況下，檢查系統是否能夠恢復被破壞的環境或數據。
3.12 迴歸測試
目標：檢查系統變更之後是否引入新的錯誤 或者 舊的錯誤重新出現，尤其是在每次構建之後和穩定期測試的時候。
工具：一般需要工具，而且依賴於測試用例和缺陷管理系統。
3.13 健全測試
目標：檢查系統的功能和性能是否可以正常使用，來確定是否可以繼續進行系統測試的其他內容。
方法：正常安裝，並使用正常情況下的測試用例對主要功能進行測試，同時檢查系統文檔是否齊全。
3.14 交付測試
目標：關閉所有缺陷報告，確保系統達到預期的交付標準。
方法：一般需要結合迴歸測試，並謹慎處理新出現的故障。
交付測試也稱爲穩定期測試，有時候與系統測試獨立劃分。
3.15 演練測試
目標：在交付給用戶之前，利用相似的用戶環境進行測試。
3.16 背靠背測試
目標：設置一組以上的測試團隊，在互相不進行溝通的情況下獨立進行相同的測試項目，用來評估測試團隊的效果並發現更多的錯誤。
3.17 度量測試
目標：在系統中 人爲的放入錯誤，並根據被發現的比例來確定系統中遺留的錯誤數量。
3.18 比較測試
目標：與競爭產品及本產品的舊版本 測試同樣的內容，來確定系統的優勢與劣勢。
比較測試屬於系統測評的內容。
以上18種測試並不是每次進行系統測試都要執行的，而是在制定測試策略、測試計劃時有不同的側重點，這與測試目標、測試資源、系統特點和業務環境有關。
4. 一些有利於做好系統測試的提示
（1）所有的測試都應該追溯到用戶需求。
軟件測試的目標是發現錯誤，而最嚴重的錯誤（用戶角度）是那些導致程序無法滿足需求的錯誤。
（2）在測試工作真正開始之前，儘早開始測試計劃。
（3）測試設計（測試用例設計）是做好測試的關鍵要素之一。
（4）Pareto原則適用於軟件測試。Pareto原則表明測試發現的錯誤中的80%很可能起源於程序模塊中的20%.
（5）如果不善於思考 你就不知道怎樣有效進行測試，你不僅得不到功勞，也沒人欣賞你的苦勞，你擁有最多的將只是疲勞。
性能測試
1. 性能測試定義
在驗證是否實現軟件系統規格的基礎上，進一步驗證待測系統的容錯性、穩定性、異常處理能力、高強度輸入處理能力等軟件系統性能方面的測試過程。
- 性能測試類型
性能測試的目標主要是發現系統的性能瓶頸。根據性能測試所要達到的目標，性能測試可大體劃分爲如下幾類：負載測試、壓力測試、強度測試、大數據量測試、可靠性測試、競爭測試、配置測試、基準測試。
負載測試：用於在測試系統保持不變情況下，覈實和評估系統在不同負載下操作極限的可接受性，評測包括負載及響應時間的特徵，比如測試一個網站在不同負荷情況下的狀況，以確定在什麼情況下系統響應速度下降或是出現故障。
壓力測試：經常可以與負載測試互相代替。這種測試是用來檢查系統在下列條件下的情況：在非正常的巨大負荷下、某些動作和輸入大量重複、輸入大數、對數據庫進行非常複雜的查詢，等等。
強度測試：強度測試主要是爲了檢查程序對異常情況的抵抗能力。強度測試總是迫使系統在異常的資源配置下運行。
大數據量測試：分爲兩種，一種是針對某些系統存儲、傳輸、統計查詢等業務進行大數據量的測試，另一種是與併發測試相結合的極限狀態下的綜合數據測試。作爲專項的大數據量測試主要針對前者，後者儘量放在併發測試中。
可靠性測試：在給系統加載一定業務壓力的情況下，使系統運行一段時間，以此檢查系統是否穩定。例如，可以施加使CPU資源保持70~90%使用率的壓力，連續對系統加壓運行8個小時，然後根據結果分析系統是否穩定。
競爭測試：一種性能測試，側重於覈實測試對象對於多個用戶對相同資源（數據記錄、內存等）的請求的處理是否可以接受的測試，比如對數據庫操作的併發測試。
配置測試：在保持測試動作不變的條件下，測試 服務器性能隨配置變化的可接受程度。
基準測試：該測試比較（新的或未知的）測試對象與已知的參照負載和系統的性能。
性能測試參考指標
根據性能測試的一般調查顯示（性能參考）：
4秒以內： 用戶可以接受
4-9秒： 30%用戶選擇離開
8-10秒： 60%用戶選擇離開
10秒以上：90%用戶選擇離開。
對於訪問時間及併發有特殊要求的項目應明確提出要求，缺省情況下按照以上要求（50人併發）執行。性能測試場景設計
測試場景設計所要考慮的主要內容，就是模擬實際工作環境，以得到準確反映系統負荷量的模型，設計負荷量時需要考慮以下因素：
（1）負荷量時長：比如高峯時間的一小時或者一般工作日或者月末。
（2）測試變量：在性能測試中要改變的因子，比如改變用戶數以瞭解反映時間在工作量增加時如何變化，最好一次只改變一個變量，以便在性能變化時，可以知道有關變化是由哪一變量引起的。在制定運行計劃時設置測試變量。
（3）功能用戶分類（用戶組）：根據用戶執行活動的類別將其分組。對於每個用戶組，需要確定其用戶數或組用戶佔總用戶數的百分比。
（4）用戶工作配置：用戶進行的活動集和他們進行這些活動的頻率。
（5）用戶特徵：用戶執行一項事務前的暫停時間、輸入速率和連續執行事務的次數。性能測試用例設計
性能測試用例的輸入主要是補充性需求，補充性需求記錄功能用例中不容易體現出來的系統需求，包括：
（1）法律法規方面的需求及應用標準。
（2）系統的質量屬性，包括可用性、可靠性、性能需求及可支持性需求。
（3）其他需求，如操作系統、環境、兼容性以及設計約束。
在設計性能測試用例時，對於補充需求內闡明性能標準的各條說明都應確保至少要確定一個測試用例。
性能標準通常表示爲時間/事務、事務量/用戶或百分比的形式。此外，還需要確保已確定影響響應時間的特定條件，包括：
（1）數據庫大小：多少條記錄？
（2）工作量：同時執行操作的用戶數量和類型，以及要同時執行的事務的數量和類型
（3）環境特徵：硬件、網絡、軟件配置。
性能測試用例需要對測試執行場景進行描述，模擬實際生產環境的使用情況。
測試用例場景包括功能使用場景與環境模擬場景。功能使用場景是與系統測試用例中相對應的功能用例一致，而環境模擬場景則是描述執行性能測試的方式，比如採用多少用戶執行，是否併發操作，迭代幾次執行，執行多長時間等。
環境模擬場景又分爲模擬真實生產環境與虛構生產環境場景。模擬真實生產環境場景是指採用測試工具模擬正常的生產環境進行執行，以測試在正常的生產環境使用壓力情況下系統的表現；虛構生產環境場景則是指設計者設計特殊的場景專門用來發現系統瓶頸。
- 性能測試步驟
性能測試分爲以下幾個步驟：
（1）制定測試方案
（2）搭建測試環境
（3）準備測試數據
（4）編寫測試腳本
（5）執行性能測試並記錄測試結果
（6）分析測試結果，編寫測試報告
（7）優化系統性能
確定性能測試範圍：需要從項目當前的全部功能中抽取出部分常用功能或可能存在性能瓶頸功能作性能測試，必須是項目當前版本中已經實現的、且功能穩定的可測試內容。
確定性能測試目標：性能測試的目標是對被測功能的性能評價。性能目標的確定需要以下列條目爲參考依據：（1）系統結構、軟件架構（2）業務需求，需要詳細瞭解每個被測功能的使用情況，用戶數量及類型等，查詢類功能需要明確基準測試數據量。（3）明確測試環境與實際生產環境的硬件配置差異。
制定性能測試方案：包括如下內容：（1）測試資源（2）測試工具（3）測試方法（4）環境影響因素（5）測試內容及目標（6）進度計劃。
執行性能測試
（1）確定測試環境：環境穩定可用，只存在被測系統不允許其他系統部署使用，不允許其他人佔用環境。
（2）準備測試數據：數據量要達到測試方案中規定的要求。
（3）準備測試腳本。
（4）執行性能測試。
測試注意事項：
(1)測試人員對性能測試申請範圍內的功能進行相關設計、執行，需要注意的是對於測試範圍內的功能，提交性能測試前需要保證通過功能測試，不存在功能故障，否則將無法進行性能測試。
(2)軟件性能通常集中在關鍵功能部件上，最好首先提取出關鍵功能部件，進行重點測試。
(3)性能測試報告決定了後續軟件改進步驟的啓動/停止及執行深度，因此，測試人員需要對軟件有深刻了解，測試用例設計合理，在執行期間需嚴格認真，注意觀察數據，並覈對、補充、調整測試項。
(4)測試結果分析需要多方位人員參與，但以開發人員爲主。
(5)系統優化完畢後，新一輪測試中，可參照上一輪測試方案制定新的方案，對優化改進部分進行重點驗證，如果發現相同的測試用例與上一輪的測試結果有較大差別，需要進行分析並查找原因。
- 性能測試實踐
待補充.
