MVP：軟件測試的三個主流方式

編輯導語：在產品項目的最后推進過程中，會經過一系列的測試來判斷以及優化產品，在測試中使產品的屬性特征最優化，最終達到吸引更多客戶的目的；本文作者分享了三種軟件測試的主流方式，我們一起來了解一下。

在產品概念階段，開展“電梯測試”是為了確定定位策略，將產品特征轉化成顯著的客戶利益；在產品設計階段，只有產品模型，測試目的是如果使產品的屬性特征最優化，從而更吸引客戶。

當產品最終完成但還沒有引入市場時，實施產品測試是為了控制產品質量，維持產品生命。在產品正式上市前進行小范圍的市場測試，目的在于識別競爭對手的實力和弱勢（如果產品有做進一步改進的潛力的話，還可進行改進測試），確定產品在目標市場中的位置。

產品測試的目的隨著被測試產品的發展或生命周期的不同階段而不同，決定采用哪種測試研究方式是建立在研究的目的之上的，所以并沒有一種測試可以稱得上是最好的。

阿爾法α（Alpha）、貝塔β（Beta）、伽馬λ（Gamma）測試常用來表示軟件測試過程中的三個階段，用于在開發流程中和上市前夕測試新產品：

• α是第一階段，一般只供內部測試使用；
• β是第二個階段，已經消除了軟件中大部分的不完善之處，但仍有可能還存在缺陷和漏洞，一般只提供給特定的用戶群來測試使用；
• λ是第三個階段，此時產品已經相當成熟，只需在個別地方再做進一步的優化處理即可上市發行。

由于樣本選擇缺乏統計基礎，這種市場研究方式不提供具體的統計置信度，即這種方式不是嚴格意義上的定量分析，但它確實能夠提供客戶在使用產品后的詳細反饋；此處，客戶面對的是最終產品，或非常接近最終形態和功能的產品，測試有助于對產品進行驗證和改進修正。

以下為大家詳加介紹阿爾法、貝塔、伽馬和試銷主流測試方式：

一、阿爾法測試

阿爾法測試類似于可用性測試（在軟件領域稱之為軟件測試），通常由內部測試人員完成；在極為少見的情況下，阿爾法測試是由客戶過外部人員完成的，阿爾法測試發布的版本被稱之為阿爾法版本（在軟件領域常被稱之為DAT開發測試[張樂飛1] 環境應用）。

阿爾法測試是由一個用戶在開發環境下進行的測試，也可以是公司內部的用戶在模擬實際操作環境下進行的受控測試，試圖發現錯誤并修正，阿爾法測試由程序員或測試員完成。

阿爾法測試的關鍵在于——盡可能逼真地模擬實際運行環境和用戶對軟件產品的操作，并盡最大努力涵蓋所有可能的用戶操作方式。

阿爾法測試的目的是評價軟件產品的FLURPS（即功能、局域化、可用性、可靠性、性能和支持），尤其注重產品的界面和特色。

阿爾法測試可以從軟件產品編碼結束之時開始，或在模塊（子系統）測試完成之后開始，也可以在確認測試過程中產品達到一定的穩定和可靠程度之后再開始，有關的“測試用例”應該在阿爾法測試前準備。

軟件測試是在軟件交付用戶使用或投入運行前，對軟件需求規格說明、設計規格說明和編碼的最終復審，是軟件質量保證的關鍵步驟，軟件測試是為了發現錯誤而執行程序的過程。

軟件測試在軟件生命周期中橫跨兩個階段：通常在編寫出每一個模塊之后就需要對它做必要的測試（稱為單元測試），編碼和單元測試屬于軟件生命周期中的同一個階段；在結束這個階段后對軟件系統還要進行各種綜合測試，如集成測試、系統測試、性能測試和配置測試等，這是軟件生命周期的另一個獨立階段，即測試階段。

只有當阿爾法測試達到一定的可靠程度時，才能開始貝塔測試，阿爾法測試即為非正式驗收測試，經過Alpha測試調整的軟件產品稱為貝塔版本。

二、貝塔測試

貝塔測試是一種驗收測試，所謂驗收測試是軟件產品完成了功能測試和系統測試之后，在產品發布之前所進行的軟件測試活動，它是技術測試的最后一個階段。

通過了驗收測試，產品就會進入發布階段，貝塔測試后發布的版本被稱為貝塔版本（在一些企業稱之為UAT用戶測試[張樂飛2] 環境應用）；可以說，貝塔測試是“預發布測試”。

軟件的貝塔測試版本將會被在網上發布，提供給廣大用戶，從而使該程序進人“真實世界”測試，并為下一個發布版本提供部分預覽。貝塔測試的主要目的在于，獲得不同客戶群體的反饋以及檢查在不同類型的網絡和硬件下產品的兼容性。

貝塔測試由軟件的最終用戶們在一個或多個客戶場所進行。與阿爾法測試不同，開發者通常不在貝塔測試的現場，因貝塔測試是軟件在開發者不能控制的環境中的“真實”應用。

用戶貝塔測試過程中遇到的一切問題（真實在或想像的），并且定期把這些問題報告給開發者。接收到在貝塔測試期間報告的問題之后，開發者對軟件產品進行必要的修改，并準備向全體客戶發布最終的軟件產品。

在B2B環境中，貝塔測試通常包含以下4個方面。

• 確定一小群“種子”客戶，這群客戶常被稱為領先客戶或領先用戶。
• 構建一個測試計劃，并確定產品開發、市場營銷、銷售和產品管理中的關鍵角色和職責。測試計劃要包含試驗的持續時間和試驗后處置結果。
• 客戶與產品公司之間的合同包含項目計劃，以便客戶能明白目標、持續時間和延期補償。另外，保密條款也應該包括在內。
• 客戶應該了解要測試什么及如何反饋結果。團隊需要確保能收集客戶數據，能組織任何最后的訪談，并能把產品帶回實驗室。

驗收測試要通過一系列黑盒測試。驗收測試一般根據產品規格說明書嚴格檢查產品，逐行逐字地對照說明書上對軟件產品所做出的各方面要求， 確保所開發的軟件產品符合用戶的各項要求。

通過綜合測試之后，軟件已完全組裝起來，接口方面的錯誤也已排除，軟件測試的最后一步——驗收測試即可開始；驗收測試應檢查軟件能否按合同要求進行工作，即是否滿足軟件需求說明書中的確認標準。

驗收測試同樣需要制訂測試計劃和過程，測試計劃應規定測試的種類和測試進度，測試過程則定義一些特殊的測試用例，旨在說明軟件與需求是否一致。

無論是計劃還是過程，都應該著重考慮軟件是否滿足合同規定的所有功能和性能，文檔資料是否完整、準確人機界面和其他方面（例如，可移植性、兼容性、錯誤恢復能力和可維護性等）是否令用戶滿意。

驗收測試的結果有兩種可能，一種是功能和性能指標滿足軟件需求說明的要求，用戶可以接受；另一種是軟件不滿足軟件需求說明的要求，用戶無法接受。項目進行到這個階段才發現嚴重錯誤和偏差一般很難在預定的工期內改正，因此必須與用戶協商，尋求一個妥善解決問題的方法。

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

三、伽馬測試

伽馬測試是終級測試，測試之后，該軟件幾乎就是上市的最終版本了；此時，不再進行軟件的功能開發或改進。

在這一階段唯一可能修改的是限定范圍內的代碼錯誤，當該軟件已經準備好發布且能夠滿足各類要求后，就開始進行伽馬測試，測試時無須進行其他任何內部測試。

除了在開發周期時間極短、上市速度要求極快的高壓情境下（由于伽馬測試并不常見，因此在此不做太多贅述）。

 

作者：長乘，公眾號：MVP-PM，歷任兩家世界500強企業產品專家！內容摘自：人民郵電出版社《獨具匠心：做最小可行性產品（MVP）方法與實踐》

本文由 @長乘 原創發布于人人都是產品經理，未經許可，禁止轉載

題圖來自 Unsplash，基于 CC0 協議