* Alpha版: 此版本表示該軟體在此階段主要是以實現軟體功能為主，通常只在軟體開發者內部交流，一般而言，該版本軟體的Bug較多，需要繼續修改。
* Beta版: 該版本相對於α版已有了很大的改進，消除了嚴重的錯誤，但還是存在著一些缺陷，需要經過多次測試來進一步消除，此版本主要的修改對像是軟體的UI。
* RC版: 該版本已經相當成熟了，基本上不存在導致錯誤的BUG，與即將發行的正式版相差無幾。

*Candidate for Release 正式版釋出前的版本
*α（Alpha）版：內測版，內部交流或者專業測試人員測試用。Bug較多，普通使用者最好不要安裝。
*β（Beta）版：公測版，專業愛好者大規模測試用，存在一些缺陷，該版本也不適合一般使用者安裝。
*γ（Gamma）版：相當成熟的測試版，與即將發行的正式版相差無幾。
*RC版：Release　Candidate的縮寫，意思是釋出倒計時，候選版本，處於Gamma階段，該版本已經完成全部功能並清除大部分的BUG。到了這個階段 只會除BUG，不會對軟體做任何大的更改。從Alpha到Beta再到Gamma是改進的先後關係，但RC1、RC2往往是取捨關係。
*Final：正式版。
*GA:General Availability,正式釋出的版本，在國外都是用GA來說明release版本的。
*RTM：(Release to Manufacture)是給工廠大量壓片的版本，內容跟正式版是一樣的，不過RTM版也有出限制、評估版的。但是和正式版本的主要程式程式碼都是一樣的。
*OEM：是給計算機廠商隨著計算機販賣的，也就是隨機版。只能隨機器出貨，不能零售。只能全新安裝，不能從舊有作業系統升級。包裝不像零售版精美，通常只有一面CD和說明書(授權書)。
*RVL：號稱是正式版，其實RVL根本不是版本的名稱。它是中文版/英文版文件破解出來的。
*EVAL：而流通在網路上的EVAL版，與“評估版”類似，功能上和零售版沒有區別。
*RTL：Retail(零售版)是真正的正式版，正式上架零售版。在安裝盤的i386資料夾裡有一個eula.txt，最後有一行EULAID，就是你的版本。比如簡體中文*正式版是EULAID:WX.4_PRO_RTL_CN，繁體中文正式版是WX.4_PRO_RTL_TW。其中：如果是WX.開頭是正式版，WB.開頭是測試版。_PRE，代表家庭版；_PRO，代表專業版。
* Release版: 該版本意味“最終版本”，在前面版本的一系列測試版之後，終歸會有一個正式版本，是最終交付使用者使用的一個版本。該版本有時也稱為標準版。一般情況下，Release不會以單詞形式出現在軟體封面上，取而代之的是符號(R)。

2. 版本命名規範

軟體版本號由四部分組成，第一個1為主版本號，第二個1為子版本號，第三個1為階段版本號，第四部分為日期版本號加希臘字母版本號，希臘字母版本號共有5種，分別為：base、alpha、beta、RC、release。例如：1.1.1.051021_beta。

3. 版本號定修改規則

* 主版本號(1)：當功能模組有較大的變動，比如增加多個模組或者整體架構發生變化。此版本號由專案決定是否修改。
* 子版本號(1)：當功能有一定的增加或變化，比如增加了對許可權控制、增加自定義檢視等功能。此版本號由專案決定是否修改。
* 階段版本號(1)：一般是 Bug 修復或是一些小的變動，要經常釋出修訂版，時間間隔不限，修復一個嚴重的bug即可釋出一個修訂版。此版本號由專案經理決定是否修改。
* 日期版本號(051021):用於記錄修改專案的當前日期，每天對專案的修改都需要更改日期版本號。此版本號由開發人員決定是否修改。
* 希臘字母版本號(beta):此版本號用於標註當前版本的軟體處於哪個開發階段，當軟體進入到另一個階段時需要修改此版本號。此版本號由專案決定是否修改。

4. 檔案命名規範

檔名稱由四部分組成：第一部分為專案名稱，第二部分為檔案的描述，第三部分為當前軟體的版本號，第四部分為檔案階段標識加檔案字尾，例如：專案外 包平臺測試報告1.1.1.051021_beta_b.xls，此檔案為專案外包平臺的測試報告文件，版本號為：1.1.1.051021_beta。

如果是同一版本同一階段的檔案修改過兩次以上，則在階段標識後面加以數字標識，每次修改數字加1，專案外包平臺測試報告1.1.1.051021_beta_b1.xls。

當有多人同時提交同一份檔案時，可以在階段標識的後面加入人名或縮寫來區別，例如：專案外包平臺測試報告 1.1.1.051021_beta_b_LiuQi.xls。當此檔案再次提交時也可以在人名或人名縮寫的後面加入序號來區別，例如：專案外包平臺測試 報告1.1.1.051021_beta_b_LiuQi2.xls。

5. 版本號的階段標識

軟體的每個版本中包括11個階段，詳細階段描述如下：

階段名稱                            階段標識
需求控制                               a
設計階段                               b
編碼階段                               c
單元測試                               d
單元測試修改                           e
整合測試                               f
整合測試修改                           g
系統測試                               h
系統測試修改                           i
驗收測試                               j
驗收測試修改                           k

大型通用軟體，在正式釋出前，通常需要執行Alpha和Beta測試，目的是從實際終端使用者的使用角度，對軟體的功能和效能進行測試，以發現可能只有終端使用者才能發現的錯誤。

　　Alpha 測試(α測試)是由一個使用者在開發環境下進行的測試，也可以是公司內部的使用者在模擬實際操作環境下進行的受控測試，Alpha測試不能由程式設計師或測試員完成。Alpha測試發現的錯誤，可以在測試現場立刻反饋給開發人員，由開發人員及時分析和處理。目的是評價軟體產品的功能、可使用性、可靠性、效能和支援。尤其注重產品的介面和特色。Alpha測試可以從軟體產品編碼結束之後開始，或在模組(子系統)測試完成後開始，也可以在確認測試過程中產品達到一定的穩定和可靠程度之後再開始。有關的手冊(草稿)等應該在Alpha測試前準備好。

　　Beta測試(β測試)是軟體的多個使用者在一個或多個使用者的實際使用環境下進行的測試。開發者通常不在測試現場，Beta測試不能由程式設計師或測試員完成。因而，Beta測試是在開發者無法控制的環境下進行的軟體現場應用。在Beta測試中，由使用者記下遇到的所有問題，包括真實的以及主管認定的，定期向開發者報告，開發者在綜合使用者的報告後，做出修改，最後將軟體產品交付給全體使用者使用。Beta測試著重於產品的支援性，包括文件、客戶培訓和支援產品的生產能力。只有當Alpha測試達到一定的可靠程度後，才能開始Beta測試。由於Beta測試的主要目標是測試可支援性，所以Beta測試應該儘可能由主持產品發行的人員來管理。

　　由於Alpha和Beta測試的組織難度大，測試費用高，測試的隨機性強、測試周期跨度較長，測試質量和測試效率難於保證，所以，很多專業軟體可能不再進行Beta測試。隨著測試技術的提高，以及專業測試服務機構的大量湧現，很多軟體的Beta測試外包給這些專業測試機構進行測試。

　　α測試和β測試

　　在軟體交付使用之後，使用者將如何實際使用程式，對於開發者來說是無法預測的。

　　α測試是由一個使用者在開發環境下進行的測試，也可以是公司內部的使用者在模擬實際操作環境下進行的測試。

　　α測試的目的是評價軟體產品的FLURPS(即功能，局域化，可使用性，可靠性，效能和支援).尤其注重產品的介面和特色。

　　α測試可以從軟體產品編碼結束之時開始,或在模組(子系統)測試完成之後開始，也可以在確認測試過程中產品達到一定的穩定和可靠程度之後再開始。

　　β測試是由軟體的多個使用者在實際使用環境下進行的測試。這些使用者返回有關錯誤資訊給開發者。

　　測試時,開發者通常不在測試現場。因而，β測試是在開發者無法控制的環境下進行的軟體現場應用。

　　在β測試中,由使用者記下遇到的所有問題，包括真實的以及主觀認定的，定期向開發者報告。

　　β測試主要衡量產品的FLURPS。著重於產品的支援性，包括文件，客戶培訓和支援產品生產能力。

　　只有當α測試達到一定的可靠程度時，才能開始β測試。它處在整個測試的最後階段。同時，產品的所有手冊。

此文章內容來自http://www.360doc.com/content/13/0329/16/4186481_274720118.shtml與http://blog.sina.com.cn/s/blog_49a94d1b0100r7ih.html