目錄

假設現在有一個研發專案A開始了，我們的軟體測試架構師也要投入專案了。此時專案產品的包需求已經基本完成，產品概念已經初步成型，如圖1所示。

圖1　研發專案A示意圖

不過此時軟體測試架構師對專案的瞭解還非常有限：

• 知道專案叫什麼名字。
• 專案大致要做些什麼內容。
• 領導期望專案在什麼時候結束。

1　開始

 返回

此時，軟體測試架構師對專案的瞭解還非常有限，在制定測試策略之前，收集了解更多的專案資訊非常重要：

• 專案的範圍。
• 人力投入。
• 歷史情況。
• ……

2　初次使用“四步測試策略制定法”

 返回

當我們收集了一些專案資訊，對專案有一定的瞭解後，就開始準備制定測試策略了。這也是我們初次在專案中使用“四步測試策略制定法”，如圖2所示。

圖2　對專案使用“四步測試策略制定法”

2.1　產品質量等級

產品質量評估模型，只能告訴我們該從哪些角度去評估產品質量，並沒有告訴我們，怎樣的評估結果可以被認為是好的質量，怎樣的結果又是不好的質量。換句話說，我們還缺少一個評價質量的“刻度”，即產品質量等級。

從終端使用者使用的角度，我們將產品質量分為如下4個等級。

• 第1級完全商用：特性完全滿足使用者的需求，有少量（或者無）遺留問題，使用者使用時無任何限制。
• 第2級受限商用：特性無法滿足使用者的某些特定場景，有普通以上的遺留問題，但有規避措施。
• 第3級測試、演示或小範圍試用：特性只能滿足使用者部分需求，有嚴重以上的遺留問題，且無有效的規避措施，問題一旦出現就會影響使用者的使用，只能用於測試（如Beta）或演示，或者小範圍試用。
• 第4級不能使用：特性無法滿足使用者需求，存在嚴重以上的遺留問題，會導致使用者基本功能失效，且無規避措施，產品根本無法使用。

注意：產品質量等級雖然是在專案初期確定的，但定義的是產品在釋出時的質量，而不是產品在測試過程中的質量，如圖3所示

圖3　定義產品釋出時的質量

2.2　確定專案中各個特性的質量等級

按照四步測試策略制定法，我們先圍繞明確產品質量目標來展開分析

此時，軟體測試架構師需要對本專案中包含的特性，逐一確定它們的“產品質量等級”（表1）。

需要特別說明的是：

• 該項活動能夠順利進行的前提是產品的特性已經基本確定完成了。
• 這項活動不應該僅由軟體測試架構師來進行，需要需求工程師、研發經理等研發核心團隊共同進行，對不同特性的產品質量等級能夠達成一致。

2.3　對專案整體進行風險分析

按照四步測試策略制定法，在這個階段，軟體測試架構師需要從專案整體角度進行風險分析。

此時，我們可以按照7.1節中介紹的“風險評估清單”，來對專案整體進行一次風險評估，並參考“風險應對”來考慮應對措施，增加一些質量保證活動。

在確定風險應對措施的時候，需要區分這些活動是針對專案整體的，還是針對具體特性的。可以直接記錄在產品質量等級表中備忘（表1）。

表1　產品質量等級表

2.4　確定測試策略的結構

按照四步測試策略制定法，接下來我們將圍繞產品開發流程來進行分析。

圖4　總分式的測試策略結構

• 總體測試策略：確定產品質量目標，進行專案整體的風險識別，從產品層面來確定測試重點和測試難點、測試深度和測試廣度，是測試策略的總綱。
• 階段測試策略：確定測試設計策略和測試執行策略需要達到的質量目標（產品質量目標的分解）以及能夠進行這些測試活動的入口條件。
• 測試執行策略：確定每個版本的測試目標、測試內容和每個版本的入口條件。

總體測試策略從概念階段開始，在計劃階段前期完成比較合適。因為這時產品的需求、質量目標和整體形態都已經確定下來，已具備了制定總體測試策略的條件，而且也需要這樣一份文件來總領後面的測試活動，讓測試團隊成員心中有數。

階段測試策略在總體測試策略完成後隨即展開，保證在開發階段前期完成。這是因為，階段測試策略最重要的目的，就是明確各個階段的輸入輸出標準。在開發編碼之前（或在前期）就把要求說清楚，可以讓開發目標更明確，更有利於產品質量的提高。測試也可以根據雙方達成的標準，準備接收測試用例、自動化測試環境等。如果階段測試策略輸出得過晚，這些活動可能就會來不及進行或者達不到期望的效果。

測試執行策略在測試執行階段，每個版本轉測試之前輸出即可。測試執行策略除了對階段測試目標進一步進行分解到每個版本的粒度，還需要根據上一個版本的測試執行情況，對測試策略進行調整。

圖5　各類測試策略之間的關係

2.5　初步確定測試分層

按照四步測試策略制定法，接下來我們將進行與測試分層相關的分析。

對軟體測試架構師來說，此時我們可以結合研發流程，來初步確定一個測試分層。假設此時我們採取經典V模型中的測試分層，然後將測試分層和研發流程，以及測試策略的結構放在一張圖上，初步將三者的對應關係梳理出來了

圖6 測試分層、研發流程和測試策略結構的對應關係

2.6　回顧

們先來總結一下到目前為止，軟體測試架構師取得了哪些進展：

• 明確了特性的質量等級，並且和各個研發核心團隊的成員就質量目標達成一致意見。
• 從專案整體角度進行了風險分析，有了需要做哪些質量保證活動的初步計劃。
• 確定了測試策略的結構為總體測試策略—階段測試策略—測試執行策略。
• 初步確定了測試分層，並且梳理出了測試分層、研發流程和測試策略結構的對應關係，初步建立了一個測試的框架。

通過這次實踐，我們發現只使用一次四步測試策略制定法，是無法得到最終的測試策略的。

首先，這和專案所處的階段有關。一些和測試策略制定相關的、必要的、重要的資訊，只有到專案的某些階段才會清晰，所以我們需要按照測試策略的結構，在專案的不同階段多次使用四步測試策略制定法來制定測試策略，如圖7所示。

圖7　多次使用四步測試策略制定法制定測試策略

其次，四步測試策略制定法中的4個步驟之間並不是瀑布式的單向關係，而是全網狀的雙向關係。圖8更為準確地表達了這4個節點之間的關係。

圖8 4個節點間的關係

例如，產品質量目標變高了，對此我們可能會增加一些測試分層，這使得研發流程也發生變化，也引入了新的風險。

所以我們在使用四步測試策略制定法時，發現進行到某個步驟進行不下去了，可以將這個步驟停一下，進行下一個步驟，然後再回過頭來進行這個沒有做完的步驟，這時往往會有新的收穫。

3　制定總體測試策略

 返回

接下來我們將在之前分析的基礎之上，再次使用四步測試策略制定法來制定總體測試策略，如圖9所示。

圖9 制定總體測試策略

3.1　分解產品質量目標

我們可以對質量等級再進行分解，整體思路如圖10所示。

圖10分解質量等級

1. 根據質量等級來分解產品的質量目標

我們可以根據之前確定的產品質量等級，來為產品質量評估模型中的專案建立不同的質量標準，從而達到分解產品質量目標的目的。

我們可以根據專案的實際情況、歷史情況和公司整體基線，確定出一個分級的標準，作為產品質量目標的分解項，見表2。

表2　定量指標分級標準

注：

• “不涉及”指該專案可以不予關注；
• 可以根據專案和產品的實際情況選擇部分分析項。

表3　特性—質量等級表

軟體測試架構師不必對每個特性，都輸出一個質量目標分解表，而是在“特性—質量等級”表中加入一個超連結即可。

2. 為每個測試分層確定測試目標

接下來我們需要根據各個質量等級的質量目標，再確定每個測試分層需要達到的質量目標。以“完全商用”為例，見表4。

表4　完全商用示例表

3.2　使用老功能分析法來對特性進行分類

在現在這個階段，開發還沒有開始對特性中的功能進行設計，所以我們還無法使用老功能分析法來對每個功能特性進行詳細的分析，但是我們已經基本能夠知道：

• 哪些特性是新開發的。
• 哪些是從老版本上繼承而來的。
• 哪些特性的改動估計會比較大。
• 從老版本繼承而來的特性的歷史測試情況。

這時，軟體測試架構師可以根據專案的實際情況，考慮上述幾個方面，來將被測物件做一下分類，並對每一類確定一個測試策略。表5是一個例子，供大家參考。

表5 示例

3.3　基於質量和風險來確定測試深度與測試廣度

1. 使用產品質量評估模型來初步確定測試深度

我們使用產品質量評估模型中的測試過程—測試方法項，基於不同的質量要求，來確定測試深度，見表6。

表6　確定測試深度

2. 考慮用老功能分析來更新測試深度

我們再根據前面老功能分析中的測試策略，更新老功能中的測試深度（可以考慮先標記出需要調整的地方），見表7。

表7 更新老功能中的測試深度

3. 基於老功能分析來初步確定測試廣度

從產品質量評估模型的角度來說，無論產品的質量要求是高還是低，我們都希望在測試中能夠對需求進行100%的覆蓋，相應的所有測試廣度都應該是100%覆蓋。

但實際上，對一些老特性，特別是那些在新版本中沒有改動，並且歷史測試情況也不錯的特性，我們可以考慮縮小測試範圍，少測或者不測。不過畢竟現在我們還處於專案的概念或計劃階段初期，還沒有進行詳細的老功能分析，但這時我們還是可以初步分析出一些可以縮小測試範圍的特性。

3.4　確定測試優先順序

接下來軟體測試架構師可以根據質量目標和分類來確定測試優先順序。基本原則是質量等級越高，優先順序越高；在相同的質量等級下，全新特性比老特性的優先順序高；改動越多的老特性，優先順序越高。

確定測試優先順序的一個簡單的方法是使用評分表。我們首先對質量目標和分類分別設定一定的分值，見表8和表9。

表8 質量目標分值表 

表9 分類分值表

然後再準備一張優先順序的分數範圍表（表10）。

確定的測試優先順序，將主要用於測試投入的安排上。我們可以根據優先順序的等級，制定出一個測試投入的策略，見表11。

3.5　確定測試的總體框架

測試框架可以理解為如何組建測試。

們將測試框架構建為三層：策略層、活動層和保證層。

如果把測試整體看成一個“人”：

• 策略層就像是人的大腦，負責指揮測試該如何進行，確保測試做的是正確的事情；
• 活動層就像是人的身體，負責具體的執行；
• 保證層就像是人的五官，保證身體能夠順利地執行任務。

我們將測試策略和測試活動按照測試框架繪製出來，並按照研發流程和測試分層來組織這些測試活動的先後次序，作為測試的總體框架，如圖11所示。

圖11 測試總體框架

3.6　回顧

讓我們回顧一下，到目前為止我們取得的進展：

• 分解了產品質量目標。
• 基於風險對特性進行了分類。
• 確定了測試深度和廣度以及測試優先順序，確定了測試投入策略。
• 確定了測試的總體框架。

事實上，進行到現在，我們可以認為軟體測試架構師完成了總體測試策略的制定。

總體測試策略最後的輸出究竟是什麼呢？其實就是兩張表和一幅圖。

第一張表，是我們在文中一直模糊地稱其為“特性—質量等級”表並不斷向其中新增內容的那張表。現在我們終於可以為其正名了——其實它的真名叫“總體測試策略分析表”。

表12 總體測試策略分析表

第二張表是測試投入策略表，見表13。

最後的圖就是我們的測試總體框架圖，如圖12所示。

圖12 測試總體框架

4　制定階段測試策略

 返回

圖13 制定階段測試策略

軟體測試架構師在制定總體測試策略的時候基本處於“單打獨鬥”的狀態，整個測試團隊中可能就只有軟體測試架構師投入。到了制定階段測試策略的時候，測試團隊中的其他成員才會開始投入，進行測試分析和設計。因此階段測試策略需要能夠向上承接總體測試策略，立馬指導測試分析和設計，向下能夠指導後面的測試執行。

4.1　測試設計策略

在制定總體測試策略的時候，軟體測試架構師已經為產品特性確定了測試深度。但測試深度是從測試方法的角度去描述的，我們在測試執行的時候，並不會按照測試方法去測試，而是按照測試用例去測試。也就是說，我們需要按照測試深度來進行測試設計，然後我們再執行這些測試用例，以達到以特定的測試深度來進行測試執行的目的。

1. 使用“測試分析設計表”來保證測試設計符合測試策略

“測試分析設計表”是對每個功能或特性進行測試設計的輔助工具，使用測試分析表的好處是：

• 軟體測試架構師可以通過配置“測試分析準備表”來控制測試設計的深度。
• 測試設計者能夠在表中非常方便地記錄下測試分析的過程。
• 評審者很容易看出設計者考慮了哪些地方，沒有考慮哪些地方，考慮的深度是否合適。

“測試分析設計表”由3張表構成：“測試分析準備表”“測試型別分析表”和“功能互動分析表”。

1）測試分析準備表

“測試分析準備表”的主要作用是為被測物件配置在測試設計中需要考慮哪些“測試型別”（可以理解為測試方法，包括功能和非功能方面）和“功能互動”（可以理解為需要將哪些功能放在一起考慮，它們是否需要進行“多執行相互作用”和“多執行順序執行”的測試）。

圖14 示例

圖14是一個示例。以其為例，這樣配置的意思是：

• 被測物件需要從功能、配置、一致性、安全性、效能、壓力、穩定性、相容、升級、備份、易用性方面來考慮測試點。
• 被測物件需要分別和安全特性、VLAN等功能結合起來考慮測試點。

軟體測試架構師可以通過配置“測試分析準備表”來控制測試深度。

2）測試型別分析表

“測試型別分析表”如圖15所示。

圖15 測試型別分析表

其中的“列”為待分析的需求，“行”為測試型別。至於行表頭中會有哪些測試型別，這和我們在“測試分析準備表”中對測試型別表的配置有關——我們只對配置了的測試型別進行測試型別分析。

圖16 參考例項

圖17 分析結果彙總表

3）功能互動分析表

“功能互動分析表”和“測試型別分析表”類似，如圖18所示。

“行”表頭中顯示的需要進行功能互動分析的功能，依然和“測試分析準備表”中的“開發特性表”保持一致。而“列”的內容就不是“原始的需求”了，而是測試型別分析結束後，我們識別出的需要再進行功能互動分析的測試點。

圖18 功能互動分析表

圖19 參考示例

2. 四步測試設計法和測試廣度

通過“測試分析設計表”輸出測試點，完成了測試分析活動後，測試設計者就可以使用四步測試設計法來對測試點進行測試設計，輸出測試用例了。

此時，需要軟體測試架構師制定一個測試設計中的路徑覆蓋策略

前面已經介紹了路徑覆蓋度評估的基本方法，我們可以參考其中步驟1和步驟2，用總體測試策略中優先順序來定義不同的路徑覆蓋策略，見表14。

表14 用優先順序定義路徑覆蓋策略

3. 測試用例等級

設計好了測試用例之後，建議軟體測試架構師再讓測試設計者對測試用例分一下級。我習慣將測試用例分為四級，每一級的定義，對應的測試深度和對應的測試分析設計表，見表15。

表15 測試用例分級

測試用例分級將會為後面的分層測試、迴歸測試、驗收測試和自動化測試在如何選擇用例方面，帶來莫大的方便。

4.2　整合測試策略

整合測試位於產品研發流程的開發階段。所謂“整合”，可以理解為不斷開發功能並將功能整合到系統中，最後完成整個系統的開發過程。

1.“俄羅斯方塊心”專案的整合開發

假設使用者希望我們開發一款叫“俄羅斯方塊心”的產品，如圖20所示。

圖20 俄羅斯方塊心

通過分析，開發很快將產品劃分為如下幾個基本功能，如圖21所示。

圖21 基本功能

並制定了通過4個build來把功能開發完如圖22所示。

圖22 功能開發和系統整合計劃

這樣，每一個build後，產品的整合形態如圖23所示。

圖23 產品的整合形態

4個build完成後，我們的系統也就完全整合好了。

“俄羅斯方塊心”雖然是個虛擬專案，卻能幫我們很好地理解產品的整合開發過程，確定整合開發階段的測試策略。

2. 整合測試的物件和測試目標

讓我們再來仔細分析一下“俄羅斯方塊心”的整合開發過程：

開發者按照計劃，完成本build計劃要整合到系統的功能開發後，需要通過單元測試來測試功能的正確性；測試通過後，開發者將功能整合起來，構造系統（這個過程有時候又叫“聯調”）。構成完成之後的測試，就是我們的“整合測試”。

圖24 build2的整合開發過程

其中單元測試是為了測試“新開發的功能和模組是否符合設計”，是“白盒測試”，使用內部介面進行測試。

而整合測試相當於是在測試驗證“新合入功能能否在系統中被正確地裝配起來”，是“黑盒測試”，也是系統級的測試，應該使用系統提供給使用者的輸入介面來進行測試，使用提供給使用者的輸出介面來判斷介面的正確性。

“功能能夠在系統中被正確裝配”隱含了一個前提就是“功能是我們想要的那個功能”。而單元測試只能確認功能的實現是符合設計的，卻不能保證功能恰好就是我們想要的。因此，整合測試需要測試的內容包括如下幾項

• 使用黑盒測試的方法來確認新合入的功能是否正確。
• 驗證功能整合後系統功能的正確性。
• 確認原來的系統功能沒有被新合入的功能所破壞。

3. 入口準則——何時可以開始進行整合測試

整合測試的入口準則等同於“第一個整合計劃中提交的功能能否進行整合測試”。

• 條件1：第一個整合計劃中的功能開發完成，並完成了單元測試。
• 條件2：第一個整合計劃中的功能整合完成，並可測。條件2的重點在於“可測”，即開發需要提供基於使用者的輸入輸出介面，而不能是內部的函式介面，確保測試能夠進行系統級的黑盒測試。
• 條件3：測試團隊已經做好了測試準備。
  • 測試用例已經輸出，並通過了評審。
  • 測試資源已經到位。
  • 測試環境已經準備好。

4. 測試用例選擇

明確了測試內容，測試用例的選擇就變得容易了

• 針對功能確認的測試，可以選擇相關功能level 1的測試用例。
• 針對“測試新功能整合”的測試，可以選擇相關功能level 2的測試用例和部分level 3的測試用例。
• 針對“確認原系統”的測試，可以選擇相關功能中level 1的測試用例。

其中“部分level 3的測試用例”是指在整合測試後期，系統已經相對比較成熟和穩定的時候，也可以適當選擇一些效能、穩定性和壓力方面的測試用例來進行測試，以避免這些“非功能”方面的問題在系統測試階段密集爆發。

5. 出口準則

當我們達到了整合測試階段的目標後，就可以退出整合測試。

出口準則包括：

• 系統需要整合的功能已經全部開放、整合完成。
• 計劃執行的測試用例已經完成。
• 缺陷分析的結果符合預期。
• 達到了整合測試階段的產品質量目標。

4.3　系統測試策略

從系統測試開始，產品研發流程進入到測試階段。

1. 系統測試的物件和測試目標

我們可能會有這樣的疑問：在整合測試結束的時候，這個心形圖案就已經完成了，並且我們也進行了測試，為什麼還要再進行系統測試呢？或者說這個問題從測試的角度來看，就是已經在整合測試中執行了的測試用例，在系統測試中還需要再執行一遍嗎？整合測試和系統測試的差異主要在哪裡？

做整合測試的時候：

• 目光是緊盯著新開發的功能的。而且隨著功能的不斷整合，系統的複雜性開始急劇膨脹，我們很難（或者說沒有足夠的測試時間，或是說系統還不夠穩定）來把和功能相關的所有組合都驗證完。
• 更重要的是，整合測試主要還是針對功能的整合，在整合測試中我們無法（或者說沒有足夠的測試時間，或是說系統還不夠穩定）對被測物件的其他非功能方面的質量來進行測試驗證。、

在系統測試中需要測試的主要內容包括：

• 從系統角度來驗證測試功能的正確性。
• 從系統角度來驗證各種非功能的質量的正確性。

2. 入口準則——何時可以開展系統測試

系統測試的入口準則，就是整合測試的出口準則，再加上一條：測試團隊已經做好了測試準備，包括測試用例、測試資源和測試環境都已到位。

3. 測試用例選擇

現在我們來回答本節開頭提的問題：我們在整合測試中執行了的測試用例，在系統測試中還需要再執行一遍嗎？
答案是，系統測試和整合測試的測試用例肯定會有相同的部分，但並不是簡單地重複一遍，而是存在一定的選擇策略。

• 針對“系統角度的功能測試”：可以選擇level1和部分level2的測試用例。
• 針對“非功能的質量的正確性”：可以選擇level3的測試用例和level4的測試用例。

4. 測試執行順序

我們在整合測試中並沒有討論測試執行順序，是因為整合測試的測試物件很單一，就是“功能”。雖然後面我們提到在整合測試的後期，可以考慮增加一些“非功能方面”的測試，但是總的來說這並不會給測試帶來先執行什麼再執行什麼的困擾。

軟體測試架構師在考慮測試執行順序的時候，可以基於如下幾點：

• 有些測試方法本來就需要滿足一些條件才能進行。例如，滿規格測試需要在基本功能正常的情況下才能進行，否則將很難區分問題到底是出在規格上，還是功能上。這就需要我們按照測試方法本身的條件來安排測試執行順序。例如，先進行穩定測試，再進行壓力測試，然後進行恢復測試。
• 如果有兩種測試方法，都能對測試物件進行測試，先進行復雜的，再進行簡單的。或者說，儘量先執行復雜的、難的測試用例，再進行簡單的測試用例。這樣考慮的原因是，希望缺陷能夠儘量在測試的前期發現，另外先執行難的測試用例也能保證這些測試用例有充足的測試時間。
• 可以考慮組合多種測試方法，或者說讓測試者想辦法把一些測試用例放在一起執行。例如，可以將功能測試的測試用例和滿規格的測試用例放在一起進行，在滿規格的情況下測試功能。這種測試執行順序特別適合系統測試中需要重複執行、整合測試中已經執行過的那些測試用例，往往可以發現很多新的問題。

5. 出口準則

當我們達到了系統測試階段的目標後，就可以退出系統測試。

出口準則包括：

• 計劃執行的測試的用例已經完成。
• 缺陷分析的結果符合預期。
• 達到了系統測試階段的產品質量目標。

4.4　驗收測試策略

驗收測試是產品在釋出前的一種測試，它是對使用者需求的確認事實上，我們進行驗收測試已經不再是為了發現產品的問題，而是為產品能夠正常釋出建立信心。

驗收測試的物件是需求，需要基於使用者場景來測試。

驗收測試包含Alpha測試和Beta測試兩種。

1. Alpha測試

Alpha測試是由測試人員模擬使用者進行的測試。

1）誰來進行Alpha測試

理想的Alpha測試人員，應該是不太瞭解產品實現細節，但是對使用者非常瞭解的人。按照這個標準，市場人員、系統工程師或是技術支援人員都可以是理想的Alpha測試人員，他們可以站在使用者的視角，對產品質量再次進行審視。

讓測試組員相互進行交叉驗收，似乎是個不錯的選擇——這確實可以消除“審美疲勞”，發現一些問題，但是交叉驗收卻很難達到從使用者的角度再去審視一次產品的效果。與交叉測試相比，更有效的方法是，測試部專門成立一個“驗收測試組”，由測試部中比較有經驗、測試能力強，且對行業、對使用者都有一定了解的測試人員來擔任，讓他們來作為產品釋出前的最後一道防線，這無疑是最能保證Alpha測試效果的做法。

2）Alpha測試策略

Alpha測試不是系統測試的延續，它是產品交付的序曲，它的測試重點應該放在“確認在使用者真實的環境下，使用者的業務、使用者的使用習慣是否能夠滿足”需求上。模擬使用者的真實環境，把自己催眠為使用者，能夠以使用者的思路來看待產品，是Alpha測試不折不扣的難點。

下面的清單也許可以幫助我們進行Alpha測試分析，找到產品在Alpha測試中需要關注的重點內容：

• 使用者將會如何學習產品？
• 產品提供的資料（如手冊、指南、視訊）是否能夠對使用者提供切實的幫助？
• 使用者會將產品安裝部署在怎樣的環境中（包括使用者會使用到的硬體、作業系統、資料庫、瀏覽器等）。
• 在使用者的環境中能否正確升級？升級對業務的影響是否在使用者容忍的範圍內？升級對已有功能的影響是否符合使用者需求（如升級後不能丟特性）？
• 產品在使用者的環境中能否被正確移除？
• 產品在使用者環境中的上下游裝置是什麼？在這樣的環境中，產品能否正常使用？
• 使用者環境中可能會有哪些業務？哪些業務是我們產品需要關注的，哪些業務是我們產品不需要關注的？對那些我們不需要關注的業務，我們的產品會怎麼處理？
• 使用者的環境中可能會有哪些故障？對這些故障，我們的產品會怎麼處理？
• 使用者會怎麼管理、配置產品？
• 使用者會如何使用產品的日誌、告警、審計、報表等和運維相關的功能？

2. Beta測試

Beta測試是由使用者參加的測試。常見的方式有如下兩種：

• 在產品正式釋出之前將產品提前發給使用者，收集使用者的反饋。
• 在產品開發完成後，交由使用者對產品進行驗收。

第一種方式下的Beta測試的困難之處在於確定測試的時間和參與者。對測試者來說，倒不需要對上面兩個問題做出決策，而是分析、復現參與者發現的問題，將問題整理為bug報告，直至確認bug被解決。
第二種方式下的Beta測試，需要保證產品能夠通過使用者的驗收測試，能夠交付給使用者使用，這時的測試需要圍繞使用者的驗收方案進行，並結合使用者的使用習慣和使用者所在的行業特點，做好充分的準備。

3. 入口準則——何時開始進行驗收測試

驗收測試的入口準則，就是系統測試的出口準則再加上：

• Alpha測試的人員、方案已經選好。
• Beta測試的使用者已經確定。

4. 出口準則——何時可以退出測試，釋出產品

當我們根據產品質量評估模型，確認產品已經達到總體測試策略中的產品質量目標後，就可以退出測試。

4.5　回顧

現在軟體測試架構師已經走到了圖25中所示的位置

圖25　完成階段測試策略的制定

我們還是先來總結一下，到目前為止，軟體測試架構師已經確定了哪些內容：

• 確定了測試設計策略，通過《測試分析設計表》來保證測試團隊的測試設計都能符合測試策略，並確定了測試用例的等級。
• 確定了各個測試階段的測試策略。

從2節開始，我們就沒有說明當前的活動對應的是四步測試策略制定法中的哪個步驟了，而是在儘量按照四步測試策略制定法的思路來組織文章的內容。
到目前為止，還沒有進行產品測試，這使得我們的測試策略多少還是有點兒“紙上談兵”的意思。進入產品測試階段後，測試策略的效果立馬就可以通過缺陷分析呈現出來，這時軟體測試架構師的工作模式將變為圖7-42所示的樣子。

圖26 軟體測試架構師的工作模式