Can you summarize the following document?
        
  

  Alpha測試通常是階段性的開發完成後所開始進行,一直持續到進入Beta測試階段前的階段。Alpha測試是一種驗證測試,在模擬的環境中以模擬的資料來執行。  在這個階段中,通常是在開發單位由開發人員與測試的測試人員,以模擬或實際操作性的方式進行驗證測試。

  在系統測試中通常先進行Alpha測試以驗證資訊系統符合使用者以及設計需求所期望的功能。當Alpha階段完成後,開發過程進入到Beta階段,由公眾參與的測試的階段。Beta測試可稱為確認測試,在一個真實的環境中以實際的資料來執行測試,以確認效能,系統執行有效率,系統復原與備份作業正常,透過測試讓資訊系統日後可以更趨完善。

  封閉測試(Closed Beta,常簡作封測或CB)是軟體或服務等產品在開發完成後、將公開上市前的測試過程。相對於公開測試,封閉測試的主要用途是測試軟體的功能和檢查程式錯誤等等,因此通常只提供給少數人進行測試。有些公司會要求參與測試者簽署保密協定,以避免測試的產品提前外流。MMORPG的封測結束之後,遊戲公司常會將角色資料刪除,但也有少數不刪的。  公開測試(Open Beta,常簡作公測或OB),一般常指軟體或服務等產品在正式上市前開放給不特定人試用,雖然原意是希望試用者能夠提報bug,但並不是把試用者當做真正的驗證人員。由於通常為免費性質,故常常能夠吸引到大批的試用者參與,可視為另一種行銷策略。另一方面也節省下測試人員的成本,和驗證穩定度(對於多人使用的頻寬及機器是否能負載,又稱壓力測試)的時間。

  Gamma測試是一個很少被提及的非正式測試階段,該測試階段對應的是對“存在缺陷”產品的測試。考慮到任何產品都可以被稱為“存在缺陷”的產品(測試只能發現產品中存在的問題,不能說明產品不存在問題),因此這個概念存在一定的不確定性。 對Alpha和Beta測試常見的一個誤解是「Beta測試=黑盒測試」。實際上,Alpha和Beta測試對應在軟體產品釋出之前的Alpha和Beta階段,而白盒、黑盒和灰盒測試技術是從技術和方法層面對測試的描述,不應該將這兩部分概念混淆。

  軟體測試一般分為黑盒測試和白盒測試。

  黑盒測試(black-box testing),也稱黑箱測試,是軟體測試方法,測試應用程式的功能,而不是其內部結構或運作。測試者不需具備應用程式的程式碼、內部結構和程式語言的專門知識。測試者只需知道什麼是系統應該做的事,即當鍵入一個特定的輸入,可得到一定的輸出。測試案例是依應用系統應該做的功能,照規範、規格或要求等設計。測試者選擇有效輸入和無效輸入來驗證是否正確的輸出。  此測試方法可適合大部分的軟體測試,例如整合測試(integration testing)以及系統測試(system testing)。

  白盒測試(white-box testing,又稱透明盒測試glass box testing、結構測試structural testing等)是一個測試軟體的方法,測試應用程式的內部結構或運作,而不是測試應用程式的功能(即黑箱測試)。在白盒測試時,以程式語言的角度來設計測試案例。測試者輸入資料驗證資料流在程式中的流動路徑,並確定適當的輸出,類似測試電路中的節點。  白箱測試可以應用於單元測試(unit testing)、整合測試(integration testing)和系統的軟體測試流程,可測試在整合過程中每一單元之間的路徑,或者主系統跟子系統中的測試。儘管這種測試的方法可以發現許多的錯誤或問題,它可能無法檢測未使用部分的規範。

  

  壓力測試常常和效能測試相混淆。它們主要不同點是,壓力測試要求進行超過規定效能指標的測試。例如一個網站設計容量是100個人同時點選,壓力測試就要是採用120個同時點選的條件測試。  壓力測試的通常判斷準則:

  

  單元測試是對軟體組成單元進行測試,其目的是檢驗軟體基本組成單位的正確性,測試的物件是軟體設計的最小單位:函式。

  整合測試也稱綜合測試、組裝測試、聯合測試,將程式模組採用適當的整合策略組裝起來,對系統的介面及整合後的功能進行正確性檢測的測試工作。其主要目的是檢查軟體單位之間的介面是否正確,整合測試的物件是已經經過單元測試的模組。

  系統測試主要包括功能測試、介面測試、可靠性測試、易用性測試、效能測試。 功能測試主要針對包括功能可用性、功能實現程度(功能流程&業務流程、資料處理&業務資料處理)方面測試。

  迴歸測試指在軟體維護階段,為了檢測程式碼修改而引入的錯誤所進行的測試活動。迴歸測試是軟體維護階段的重要工作,有研究表明,迴歸測試帶來的耗費佔軟體生命週期的1/3總費用以上。  與普通的測試不同,在迴歸測試過程開始的時候,測試者有一個完整的測試用例集可供使用,因此,如何根據程式碼的修改情況對已有測試用例集進行有效的複用是迴歸測試研究的重要方向,此外,迴歸測試的研究方向還涉及自動化工具,物件導向迴歸測試,測試用例優先順序,迴歸測試用例補充生成等。

  程式碼覆蓋率原本是種白箱測試活動。目標軟體通過特殊選項或者函式館編譯並且/或者在特殊環境(程式裡每個函式都被對映回原始碼裡函式起點)下執行。這個過程允許開發員與品管員檢視系統中在正常情況下極少或從未被讀寫的部分(例如:例外處理之類)並且幫助測試員確認最重要的情況(函式點)都被測過了。  測試員可檢視程式碼覆蓋率測試結果來設計測試個案、相對應的輸入或者設定組以增加重要函式的程式碼覆蓋率。兩種測試員常用的程式碼覆蓋率形式:陳述式覆蓋率(或稱行覆蓋率)以及路徑覆蓋率(或稱邊覆蓋率)。行覆蓋率回報到測試完成時,執行過哪些行,或者記憶體大小。邊覆蓋率回報到測試完成時,哪些分支,或者程式決定點被執行過。正如覆蓋率的「率」字所言,這兩個都以百分比為單位。  通常程式碼覆蓋率的工具與函式館要求的效能、記憶體、或者其他資源開銷不為正常的軟體營運接受。因此它們通常只存在實驗室裡。又,你可能會想到軟體裡的許多類無法一一通過這些程式碼覆蓋率測試,雖然程式碼覆蓋程度可通過分析但不是直接測試。  有些瑕疵也會受這些工具的影響。個別來說某些競態條件(race condition)或者類似的對即時(real time)敏感度高的操作幾乎不可能在程式碼覆蓋率測試環境下偵知;相反的這類的瑕疵只會帶來更多的測試碼開銷。

  測試自動化是使用軟體工具和既定程式,對軟體所進行的測試活動。
軟體測試(英語:software testing),描述一種用來促進鑑定軟體的正確性、完整性、安全性和品質的過程。據此,您可能會想,軟體測試永遠不可能完整的確立任意電腦軟體的正確性。然而,在可計算理論(電腦科學的一個支派)一個簡單的數學證明推斷出下列結果:不可能完全解決所謂「當機」,指任意計算機程式是否會進入無窮迴圈,或者罷工併產生輸出問題。換句話說,軟體測試是一種實際輸出與預期輸出間的稽核或者比較過程。