軟體測試架構師修煉之道 (一)

一. 軟體產品質量模型

1. 軟體產品質量六屬性：功能性、可靠性、易用性、效率、可維護性、可移植性。

1.1. 功能性：

軟體產品質量屬性中的功能性，是指軟體產品在指定條件下使用時，提供滿足明確和隱含要求的功能的能力。
從功能性的定義來看，產品的功能並不像表面上看起來那麼簡單 - 除了滿足 “明確” 的要求，還有更深一層的 “隱含” 的要求。“明確”+“隱含” 才構成了使用者對產品真正的、完整的功能要求。
功能性被分成了 5 個子屬性：

• 適合性：軟體產品為特定的任務和使用者目標提供一組合適功能的能力。
• 準確性：軟體產品提供具有所需精度的正確或相符的結果及效果的能力。
• 互操作性：軟體產品與一個或多個特性、系統相互配好的能力。
• 安全性：軟體產品保護資訊和資料的能力，以保證未授權的使用者或系統不能閱讀和修改這些資訊與資料，而合法使用者或系統不會被拒絕訪問。
• 功能順從性：軟體產品符合和該功能相關的標準、規範、規則或特定的能力。
  

1.2. 可靠性： 軟體產品質量屬性中的可靠性，是指在特定條件下使用時，軟體產品維持規定的效能級別的能力。

可靠性被分成了 5 個子屬性：
成熟性：軟體產品為避免因軟體故障而導致失效的能力。
容錯性：軟體產品在軟體發生故障或者違反指定介面的情況下，維持規定的效能級別的能力。
可恢復性：軟體產品在失效發生的情況下，重建規定的效能級別並恢復受直接影響的資料的能力。
可靠性順從性：軟體產品遵循與可靠性相關的標準、約定或規定的能力。

1.3. 易用性：

• 軟體產品質量屬性中的易用性，是指在指定條件下使用軟體產品時，產品被使用者理解、學習、使用和吸引使用者的能力。這個能力，簡單的說就是 10 個字：易懂、易學、易用、漂亮好看。 易用性被分成了 5 個子屬性：
• 易理解性：軟體產品使使用者能理解軟體是否適合以及如何能將軟體使用者特定的任務和使用環境的能力。
• 易學性：軟體產品使使用者能學習其應用的能力。
• 易操作性：軟體產品使使用者能夠操作和控制它的能力。
• 吸引性：軟體呢產品吸引使用者的能力。
• 易用性的依從性：軟體產品遵循與易用性相關的標準、約定、風格指南或法規的能力。

1.4. 效率： 軟體產品質量屬性中的效率，是指在規定條件下，相對於所用資源的數量，軟體產品可提供適當的效能的能力。通常，效率就是我們常說的產品選效能。

• 效率被分成了 3 個子屬性：
  • 時間特性：在規定條件下，軟體產品執行其功能時，提供適當的響應和處理時間及流量 (吞吐量) 的能力。
  • 資源利用率：在規定條件下，軟體產品執行其功能時，使用合適數量和類別的資源的能力。
  • 效率依從性：軟體產品遵循與效率相關的標準或約定的能力。

1.5. 可維護性： 軟體產品質量屬性中可維護性，是指　軟體產品可被修改的能力。這裡的修改是指糾正、改進軟體產品和軟體產品對環境、功能規格變化的適應性。

• 可維護性被分成了 3 個子屬性：
  • 可分析性：軟體產品診斷軟體中的缺陷、失效原因或識別待修改部分的能力。
  • 可修改性：軟體產品能被修改的能力。
  • 穩定性：軟體產品不會因為修改而造成意外結果的能力。
  • 可測試性：軟體產品已修改的部分能夠被確認修復的能力。
  • 可維護性的依從性：軟體產品遵循與維護性相關的標準或約定的能力。

1.6. 可移植性：

• 軟體產品質量屬性中的可移植性，是指軟體產品從一種環境遷移到另外一種環境的能力。這裡的環境，可以理解為硬體、軟體或組織等不同的環境。
• 可移植被分成了 3 個子屬性：　
  • 適應性：軟體產品無須採用額外的活動或手段就可適應不同指定環境的能力。
  • 可安裝性：軟體產品在指定環境中被安裝的能力。
  • 共存性：軟體產品在公共環境中同其分享公共資源的其他獨立共存的能力。
  • 易替換性：軟體產品在同樣的環境下，替換另一個相同用途的指定軟體產品的能力。
  • 可移植性的依從性：軟體產品遵循與可移植性相關的標準或約定的能力。　　　

2.常見測試型別及其與質量屬性關係：

• 2.1.功能性：驗證產品能否滿足特定功能要求並做出正確響應。

• 2.2.安全性測試：驗證產品是否有保護資料的能力，並能在合適的範圍內承受惡意攻擊。

• 2.3.相容性測試：驗證產品是否能夠和其它相關產品順利對接。

• 2.4. 配置測試：驗證產品是否能夠在推薦配置上流暢執行；驗證產品為了完成特定功能的輸入是否會出現故障。

• 2.5.可靠性測試：驗證產品在長時間執行下能否滿足保證系統的效能水平；在存在異常的情況下系統是否依然可靠。

• 2.6. 易用性測試：驗證產品是否易於理解、易於學習和易於操作。

• 2.7. 效能測試：測試產品提供某項功能時的時間和資源使用情況。

• 2.8. 安裝測試：測試產品能否被正確安裝並執行。

3.測試方法：

3.1. 產品測試車輪圖：

　　

3.2. 功能測試方法：

• 單執行正常值輸入法
• 單執行邊界值輸入法
• 多執行順序執行法
• 多執行相互作用法

3.3. 可靠性測試方法：

• 概念：產品在各種條件下維持規定的效能級別的能力。前提條件 - 基本功能要先正確。
• 異常值輸入法：一種使用系統不允許使用者輸入的數值 (即異常值) 作為測試輸入的 可靠性測試方法。
• 故障植入法：把系統放在有問題的環境中進行測試的一種 可靠性測試方法，主要能夠測試到的質量屬性是容錯性和成熟性。
• 穩定性測試法：在一段時間裡，長時間大容量執行某種業務的一種 可靠性測試方法，它能夠非常有效地測試到系統的 “成熟性”，是非常重要的一種 可靠性測試方法。
• 壓力測試法：在一段時間內，持續使用超過系統規格的負載，進行測試的一種 可靠性測試方法。
• 恢復測試法：指使用持續超過規格的負載，進行測試後，再將負載降到規格以內的測試方法。　　　

3.4. 效能測試方法：

測試出系統最好的效能值：
系統能夠正確處理新業務的最大能力
系統能夠同時正確處理的最大業務能力

分析會影響效能值的各種因素，測試它們對效能的影響
以場景為單位來測試效能　　　
　　

3.5. 易用性測試方法：

一致性測試法：
測試物件：使用者介面，如 Web 頁面、命令列等使用者和產品直接進行互動的地方。
關注產品的使用者介面：
風格、佈局、元素上是否一致、統一。
佈局的合理性、操作的合理性、提示等是否符合 UI 設計規範。

可用性測試法：
測試物件：使用者介面。
關注產品提供的功能：對使用者來說，是否易於學習理解、易於使用。
可用性測試，需要和功能測試結合，以場景作為測試粒度，以使用者的視角進行測試。

　　

4. 測試設計技術：

4.1.測試點不等於測試用例：測試用例是在測試點 “加工” 的基礎上得到的。

4.2.四步測試設計法：

4.2.1.建模：

• 型別 1-“流程”：對 “流程” 類，可以透過繪製 “流程圖”，來建立測試模型；
• 型別 2-"引數"：對” 引數 “類，可以透過” 輸入輸出表 “，來建立測試模型；
• 型別 3-"資料"：對 “資料” 類，可以透過 “等價類分析表”，來建立測試模型；
• 型別 4-“組合”：對 “組合” 類，可以透過 “因子表”，來建立測試模型；

4.2.2.設計基礎測試用例。

4.2.3.補充測試資料。

4.2.4.擴充套件。

4.3.對測試點進行分類：

4.3.1. 流程類測試點有哪些特徵: 流程類測試點，擁有流程方面的一些特徵。

4.3.2. 引數類測試點有哪些特徵：

• 特徵一：“引數值” 的個數是有限的，可以透過遍歷的方式來測試覆蓋到；

• 特徵二：系統會對不同的 “引數值”，作出不同的處理或響應。

4.3.3. 資料類測試點有哪些特徵：

• 特點一：資料的取值是一個範圍，通常不能用遍歷的方式來測試覆蓋。

• 特點二：系統對允許輸入的 “資料” 作出的處理或響應往往是一樣的。

　　　　　　

4.3.4. 組合類測試點有哪些特徵：

• 1. 測試點是可以 “組合” 的。在測試設計時，可以把流程類、資料類和引數類的測試點，組合在一起進行測試設計。
• 1. 和單純的流程類相比，它可能有多個 “輸入”，這個 “輸入” 可能為引數，也可能為資料。

4.4 流程類測試設計：

4.4.1. 路徑分析法：

• 透過繪製業務流程圖來建模：對流程類的測試點，建模就是繪製這些測試點代表的業務流程圖。
  • 注意點：
  • 測試者要充分理解和測試點相關的功能業務流程，確保流程圖的正確性。
  • 測試者要和 產品設計者充分交流，保證繪製出的流程圖能夠正確覆蓋產品的設計。
  • 如果開發已經提供該功能的流程圖，測試者需要仔細稽核流程圖的正確性，如有必要，可以重新繪製。

4.4.2. 路徑分析法：

• 對流程類的測試點，把模型建立好了之後 (即繪出了流程圖)，就會使用路徑分析法，來覆蓋這個流程圖，設計基礎測試用例。

• 路徑是指，完成一個功能，使用者所執行的步驟，即透過程式程式碼的一條執行軌跡。

• 路徑分析法：指對能夠覆蓋流程的各種路徑進行分析，得到一個路徑的集合。在測試時，只需要按照這個路徑進行集合測試即可。

• 不同的覆蓋策略，能夠得到不同的路徑集合。常見覆蓋策略：語句覆蓋、分支覆蓋、全覆蓋、最小線性無關覆蓋。

  • 語句覆蓋：指覆蓋系統中所有判斷和過程的最下路徑集合。
  • 缺點： 覆蓋程度較弱，不會考慮流程中的 “判定” 以及這些 “判定” 過程之間的相互關係，如果測試只按照 “語句覆蓋” 的方式來進行測試，很容易出現遺漏。
    
  • 分支覆蓋：指覆蓋系統中每個判定的所有分支所需的最小路徑數。
  • 缺點：分支覆蓋考慮了流程中的 “判定”，但是沒有考慮這些 “判定” 之間的關係。分支覆蓋也是一種不是很強的覆蓋。　
    
  • 全覆蓋：指 100% 的覆蓋系統，所有可能的路徑的集合。
  • 缺點：對普通系統來說，隨著判定增加而呈指數型別增長的路徑數，使得需要測試的路徑數目非常龐大，完成超出了一個測試團隊能夠承擔的正常工作量，在實際中很難按此執行。
  • 最小線性無關覆蓋：流程圖中每個路徑片段，能夠被至少執行一次，得到的最小路徑組合。
    • 計算一個流程中的最小線性無關路徑的數目 (三個等式是等效的)：
    • 等式 1：一個系統中的線性無關路徑 (IP) = 邊數 (E) - 節點數 (N) + 2
    • 等式 2：一個系統中的線性無關路徑 (IP) = 判斷數 (P) + 1
    • 等式 3：一個系統中的線性無關路徑 (IP) = 區域數 (R) + 1
    • 流程需遵循如下約定：
      
    • 約定 1：“流程圖” 的 入口和 “出口”，不作為邊數計算。
      
    • 約定 2：一個 “流程圖” 只有一個 “入口點” 和一個 “出口點”。
    • 存在 “多個輸入” 或輸出時，先要對流程圖進行分解，使其滿足 “約定 2”： 這時系統中最小線性無關路徑的總數，等於被分解的每個流程中最小線性無關路徑的總和：

4.4.3. 使用路徑分析法來設計基礎測試用例：

1. 單元測試階段：主要使用語句覆蓋或分支覆蓋的方式，來設計測試用例；

2. 整合測試和系統測試階段：主要使用最小線性無關覆蓋；

3. 特別重要的部分：使用全覆蓋；

4. 不那麼重要的部分：使用 語句覆蓋或者分支覆蓋。

4.4.4. 確定測試資料，完成測試用例：

• 如果流程的 “輸入” 是一些引數，選擇合適的引數值即可；如果 “輸入” 是一個取值範圍，使用 “等價類/邊界值” 來選擇一個輸入資料。

4.4.5. 根據經驗補充測試用例：

• 1. 是否要增加一些需要覆蓋的路徑？
• 2. 是否要增加一些測試資料？
• 3. 有哪些地方是容易出問題的，是否還需要補充一些測試用例？

4.5. 流程類測試設計 - “輸入 - 輸出表” 分析表：

• 使用四步測試設計法對引數類的測試點進行測試設計：
  

• 2.使用 “輸入 - 輸出表” 來建模：

• 3."輸入 - 輸出表"是一張分析測試點，在某種條件下，特定的 “輸入” 會有怎樣 “輸出” 的表。
  

• 4.覆蓋 “輸入 - 輸出表”，完成測試用例：

  • 4.1 在建立 “輸入 - 輸出表” 的時候，會充分考慮各個引數之間的關係和它們的約束條件，並據此進行逐一的分析，在覆蓋 “輸入 - 輸出表” 的時候，會進行 100% 的覆蓋，即將 “輸入 - 輸出表” 的每一行作為一個測試用例。

• 5.根據經驗補充測試用例：

  • 5.1. 是否需要要考慮一些別的 “條件”？
  • 5.2. 有哪些地方是容易出問題的，是否還需要補充一些測試用例？

4.6. 資料類測試設計 - 等價類和邊界值分析法：

　　　　

1. 等價類和邊界值：

• 1.1. 等價類是指，對輸入值按照測試效果進行劃分，將測試效果相同的測試資料歸為一類，然後在測試時，只需要在每類中選擇一些測試樣本來進行測試，而無測試所有的值。

  • 1.2. 邊界值：引數在輸入邊界上的取值。

• 2.使用 “等價類分析表” 來建模：

  • 2.1. 等價類分析表，是一張對資料在 “xxx 條件下”，“有效輸入” 和 “無效輸入” 進行分析的表。

• 3.覆蓋等價類分析表 - 完成測試用例：

  • 3.1. 在建立等價類分析表的時候，已經對輸入資料分好了類。將分析好的等價類進行 “邊界值” 分析，確定具體的測試資料，生成測試用例。

• 4.根據經驗補充測試用例：

  • 4.1. 是否要在 “等價類” 中增加一些除 “邊界值” 之外的測試資料？
  • 4.2. 有哪些地方是容易出問題的，是否需要補充一些測試用例？

4.7. 組合類測試設計 - 正交分析法：

• 1.使用 “因子表” 來建模：

  • 1.1. “因子表” 是一張分析測試點需要考慮哪些方面，並且這些方面要包含哪些內容的表。

• 2.使用 “PICT” 工具，生成測試用例：

  • 2.1. “PICT” 是針對 “Pairwise Testing” 實現的測試用例設計工具。可以直接將 “正交表” 轉換成測試用例。

• 3.根據經驗補充測試用例：　　

  • 3.1. 是否需要增加因子取值的組合？
  • 3.2. 有哪些地方是容易出問題的，是否還需要補充一些測試用例？

4.8. 控制用例粒度 - 測試點的組合和拆分：

• 1.控制用例粒度：用例粒度是對測試用例是精細還是籠統地描述測試點的通俗說法。測試用例越聚集到一個功能點上，這個功能點越小越細，用例粒度就越細；反之，如果一個測試用例包含了比較多的功能點，這個測試用例的用例粒度就會比較粗。

• 2.控制用例粒度，意味著要做以下兩件事：

  • 2.1. 第一，我們希望整個團隊的測試用例的總數，維持在一個比較合理的範圍內，同時很好地達到測試驗證產品的效果。這就需要我們控制測試用例的源頭 - 測試點：讓測試點不要過粗或者過細。如果測試點過粗或過細，就要去拆分或者組合它，保證設計出來的測試用例粒度比較統一。
  • 2.2. 第二，不同的用例粒度，可能會發現產品不同層次的問題 (細粒度的用例可能更容易發現產品功能的設計和實現方面的問題，而粗粒度的用例更容易從系統的角度去發現一些功能互動或是需求方面的問題)，所以需要在不同的測試階段，對測試點進行一些拆分或組合，以求可以從不同的層次去測試產品，發現問題。

• 3.策略覆蓋：

  • 3.1. 在測試設計時，經常會遇到以下情況：
  • 3.1.1. 有些因子，如作業系統、平臺等，除了那些可以分析到的對系統有影響的地方之外，對系統的其它功能可能沒有影響、影響很弱或者影響未知，沒有必要使用 Pairwise 來進行正交。
  • 3.1.2. 有些資料類的測試點，比如就是測試一個名稱，測試點比較細，但是它和其它的測試點可能沒有關係或者關係很弱，也沒有必要使用 Pairwise 來做正交。
  • 3.1.3. 這時，可以考慮使用策略覆蓋的方式，將這些因子或資料的取值，分配到其它測試用例中，作為其它測試用例的測試資料輸入或者是測試條件 (或預置條件)。

4.9.錯誤推斷法：

• 1.錯誤推斷法，是測試者根據經驗來判斷在哪些地方容易出現問題，然後針對這些地方來設計測試用例的方法。
• 2.錯誤推斷法，是一種基於經驗的測試設計方法。使用錯誤推斷法來設計測試用例，優點是測試用例的有效性會比較高 (所謂測試用例的有效性，就是指測試用例發現產品缺陷的能力)。
• 3.錯誤推斷法的缺點：這時測試專注於發現缺陷，可能會測試得很嚴苛，卻忽視或遺漏掉對一些基本功能和場景的測試驗證，造成測試遺漏。

5. 探索式測試：

• 1.探索性測試 (exploratory testing)，最早由測試專家 Cem Kanner 博士 在 1983 年提出，是一種強調測試人員同時開展測試學習、測試設計、測試執行，並根據測試結果反饋及時最佳化的測試方法。

• 2.探索式測試的基本思想-CPIE：

  • 2.1. 基本思想：
  • 2.1.1. 收集 (Collection)：收集所有關於測試物件的資訊並去理解這些資訊。
  • 2.1.2. 劃分優先順序 (Prioritization)：對所有需要測試的任務進行優先順序劃分。
  • 2.1.3. 分析調研 (Investigation)：對測試的任務進行仔細分析，預測可能輸出的結果。
  • 2.1.4. 實驗 (Experimentation)：進行測試實驗，確認測試結果和預期是否符合。分析是否需要修改策略和方法。如有需要，進入 “收集” 階段。
  • 2.2. CPIE 模型很好地總結了探索式測試的基本思想。和傳統式測試相比，探索式測試弱化了流程，強調實踐，邊學邊測，持續改進。使用探索式測試的優勢是顯而易見的:能夠更快地進行測試，能夠得到更有效的測試點，能夠更高效地發現產品缺陷。但是，探索式測試也有一定的侷限性:容易將焦點集中在缺陷發現上而偏離對需求的驗證，對基本測試點的測試和覆蓋容易不足，測試點不易複用，不易積累。 此外，探索式測試對人的要求很高，包括測試者的思維能力，分析能力，總結能力，持續改進、追求卓越的意願，等等。在實際專案中，以傳統式測試為主線，將探索式測試作為很好的補充是比較不錯的方式，兩種思想結合起來，能比較不錯地將探索式測試的思想運用到各種測試活動中。

• 3.選擇合適的探索式測試方法：

  • 3.1. 第一步： 對產品的特性進行 “分割槽”：
  • 3.1.1 將產品特性劃分為 “歷史區 (繼承特性)”、“商業區 (銷售特性)”、“娛樂區 (輔助特性)”、"破舊區 (問題高發區)"、“旅館區 (平臺、維護特性)”、“旅遊區 (噱頭特性)” 和 “其它區”。
  • 3.1.2 如果產品同時具備多個區域的特性，就將這個特性分別劃分到這些區域中去。
  • 3.2.第二步：根據不同的分割槽來選擇適合這個分割槽的探索式測試方法：
  • 3.2.1 歷史區測試法：
    • 含義：歷史區測試法針對的是 “老程式碼”，即在前幾個版本就已經存在的軟體特性。也包括那些用於修復已知缺陷的程式碼。
    • 包含的探索式測試法：
    • 惡鄰測試法：指那些缺陷橫行的程式碼段，測試人員應該在這些區域儘量多花時間。
    • 博物館測試法：重視老的可執行檔案和那些遺留程式碼，另外還包含累積許久沒有執行過的用例，確保它們和新增程式碼享受同等待遇。
    • 上一版本測試法：檢查那些在新版本中無法再執行的測試用例，以確保產品沒有遺留必需的功能，也就是說，如果當前產品構造是對先前版本的更新，必須先執行先前版本上支援的所有場景和測試用例。
  • 3.2.2 商業區測試法：
    • 含義：商業測試法針對的是銷售特性。所謂的銷售特性，就是指產品的重要功能和特性，是測試時需要重點測試的物件。
    • 包含的探索式測試法：
    • 指南針測試法：主要要求測試人員透過閱讀使用者手冊、場景及產品需求進行相關的測試。
    • 賣點測試法：對那些能夠吸引使用者的特性進行測試，至於哪些特效能夠吸引使用者，可以向銷售人員諮詢，或者拜訪客戶。
    • 地標測試法：主要是尋找測試點，明確測試項，這裡的測試點就是 “地標”。
    • 極限測試法：向軟體提出很多難以回答的問題。比如，如何使軟體發揮到最大限度？哪個特性會使軟體執行到其設計極限？哪些輸入和資料會耗費軟體最多的運算能力？等等。
    • 快遞測試法：要求測試人員專注於資料，即資料從輸入到輸出展現給客戶或頁面過程中，資料執行的流程。
    • 深夜測試法：當我們不對測試物件操作時，測試物件能否自動完成各種維護任務，將資料歸檔，自動記錄傳送的異常情況，等等。
    • 遍歷測試法：透過選定一個目標，然後使用可以發現的最短路徑來訪問目標包含的所有物件。測試中不要追求細節，只是檢查那些明顯的東西。

　　　　　　

• 3.2.3 娛樂區測試法：
  • 含義：娛樂區測試法，針對的是輔助特性，也就是那些並不是那麼重要的特性的測試。
  • 包含的探索式測試法：
  • 配角測試法：專注於某些特定的特性，它們雖然不是那種我們希望使用者使用的主要特性，但和那些主要的特性會一同出現。它們緊鄰那些主要功能，越容易被人注意，所以必須給予足夠的重視，不能忽視。
  • 深巷測試法：測試產品特性的使用情況中，排在最下面的幾項特性 (最不可能被用到的或是那些最不吸引使用者的特性)。它的變種是 “混合測試法”，試著把最流行和最不流行的特性放在一起混著測。因為開發人員可能從來沒有預想過它們會在這樣的場景中被混合在一起。
  • 通宵測試法：測試軟體長時間執行後，各功能模組是否正常，有點像穩定性測試。這個方法容易和 “深夜測試法” 混淆，但是測試側重點不同：“深夜測試法” 測試的是測試物件的自動處理能力。

　　　　　　

• 3.2.4 破舊區測試法：

  • 含義： 破舊區測試法針對的是問題高發特性。對這些讓人頭痛的問題高發特性，破舊區測試法的測試思想就是繼續 “落井下石”：如輸入惡意資料、破壞操作、修改配置檔案等，所有這些你能想到的 “有害” 的事情，都往這些特性上想就對了。
  • 包含的探索式測試法：　　
  • 破壞測試法：指那些缺陷橫行的程式碼段，測試人員應該在這些區域儘量多花時間。　
  • 反叛測試法：要求輸入最不可能的資料，或者已知的惡意輸入。要求輸入最不可能的資料。
  • 強迫症測試法：強迫軟體一遍又一遍接受同樣的資料，反覆執行同樣的操作。此種思維方式，常常打破了開發人員設計程式碼的思路，他們預想這你會按步驟操作，卻不曾考慮過你反覆地執行第一步應該如何處理。

• 3.2.5 旅館區測試法：

  • 含義：旅館區測試法針對的是平臺或維護特性。這些特性的特定容易被忽視，而旅館區測試法就是讓我們再回頭去測試一些經常被忽視的或在測試計劃中較少描述的次要輔助功能的方法。
  • 包含的主要測試方法：
  • 取消測試法：啟動相關操作，然後停止它，檢視測試物件的處理機制及反應。例如，在功能進行中使用 Esc 鍵、取消鍵、回退鍵、關閉按鍵或者徹底關閉程式等。
  • 懶漢測試法：做盡量少的實際工作，讓程式自行處理空欄位及執行所有預設值。

　　　　　　

• 3.2.6 旅遊區測試法：

  • 含義：旅遊區測試法針對的是噱頭特性。特點：關注如何快速訪問檔案的各種功能，測試目的就像方法的名稱一樣，只是為了到此一遊。
  • 包含的主要測試方法：
  • 收藏家測試法：測試人員透過測試去收集軟體的輸出，將那些可以到達的 “地方” 都到達一遍，並把觀察到的輸出結果記錄下來，收集得越多越好。
  • 長路徑測試法：訪問離應用程式的某個開始點儘可能遠的特性。哪個特性需要點選 N 次才能被用到？ 哪個特性需要經過最多的介面才能訪問？ 主要指導思想是到達目的地之前儘量多地在應用程式中穿行。
  • 超模測試法：要求測試人員去關心那些表面的東西，只測試介面。測試中注意觀察介面上各種元素。它們看上去怎麼樣？有沒有被正確地繪製出來？ 變化介面時，圖形使用者介面重新整理情況如何？ 如果軟體用顏色來傳達某種意思，這種 資訊是否一致？ 介面是否違反了任何慣例或標準？
  • 測一送一測試法：測試同一個應用程式多個複製的情況。測試程式同時處理多個功能要求時，是否正常，各功能之間同時處理時，是否會相互影響。

• 3.2.6 其它區測試法：

  • 含義：“其它區” 是指那些無法歸類在歷史區、商業區、娛樂區、破舊區、旅館區和旅遊區中的探索測試的區域。比如產品的一些可測試性、可維護性 (終端使用者不一定會使用，但是對測試或者開發、維護卻比較有用的內容)，再比如對當前有程式碼變動的一些地方的測試等。
  • 包含的主要測試方法：
  • 內部測試法：這個方法一般在你需要進行某項功能測試之前完成。首先收集這個功能有哪些部分是對確認測試結果、定位問題有用的 “內部輸出”(可能就是些中間結果，而不是最終的使用者可以看到的資訊)，然後確認這些地方是否有效。(如果你發現你的測試功能無法使用內部測試法，這時可以和開發人員、需求人員聊聊，也許這裡有新的需求)
  • 變動區測試法：首先分析當前版本和上個版本有哪些內容上的變化。然後只針對變化的內容進行探索測試。對 bug 的迴歸測試、驗證 bug 的修改是否正確，就是使用的這種方法。

4. 開展探索式測試：

1.確定探索式測試任務：

1.1 確定任務的範圍：

• 思路 1：進行全域性場景探索：指準備進行探索的物件是整個系統；
• 思路 2：進行特性漫遊探索：指準備進行探索的物件是整個特性；
• 思路 3：進行區域性功能點探索：是指準備進行探索的物件是某個具體的功能。

1.2 三者之間關係圖：

　　　　　　　　

1.3 根據範圍和方法來確定探索式測試的任務：

• 例如：使用 xxx 測試方法，對 xxxx 場景進行探索測試。

2. 設計探索地圖並執行探索式測試：

2.1 探索地圖，就是測試者根據被測物件的特定，使用探索式測試方法，分析得到的測試點，然後就可以按照測試點對被測物件進行探索式測試，並記錄測試結果。

　　　　　　　　

3. 探索性測試總結：

• 3.1 探索式測試者每執行完一個任務，都需要圍繞如何有效地發現產品缺陷，立即進行總結：
  • 3.1.1 總結使用哪些方法，能夠更有效發現產品的問題。
  • 3.1.2 總結本次探索式測試中的教訓。

6. 自動化測試：

1. 對軟體測試架構師來說，掌握自動化測試相關的知識和技術是必要的，但是掌握這些知識的目的不是設計自動化的架構或是具體來部署自動化，而是用好自動化：

• 第一，用好已有的自動化 - 讓現有自動化能在產品測試中發揮最大的功效；
• 第二，會根據產品的測試需要向自動化團隊提出合適的自動化需求，和自動化團隊保持良好的互動。

2. 自動化並不廉價，相反，自動化很貴：

• 2.1 時間成本、人力成本和技術成本，都是自動化中需要考慮的成本。

3. 自動化指令碼往往沒有想象中那麼可靠：

• 3.1 無論是正確的自動化測試結果，還是錯誤的自動化測試結果，都需要人再去確認。

4. 自動化測試不是單靠測試就能搞定的事：

• 4.1 自動化測試，需要 SE、開發、測試、自動化工程師緊密配合才能有效運作起來。
• 4.2 對軟體測試架構師來說，如果決定要部署自動化測試，可能需要調整測試策略，加強對自動化測試中的風險識別，做好風險控制，並有針對性地對測試設計做一些調整。

5. 如何評估自動化的收益：

1.自動化測試的實施成本：

• 1.1 計算公式：自動化實施成本 = 前期開發成本 + 後期的維護成本

• 1.2 前期開發成本：

  • 人力成本： 和自動化開發人員相關的費用成本。
  • 時間成本：自動化準備時間，自動化開發、除錯的時間成本。
  • 金錢成本：工具購買、開發、維護的費用成本。

• 1.3 影響後期維護的成本：

  • 產品變更引起的自動化測試指令碼變更的成本。
  • 定位、修復自動化執行環境引起的指令碼的健壯性問題的成本。
  • 定位、修復自動化執行環境的可靠性問題的成本。
  • 其它任何未知的引起測試指令碼變更的因素引發的成本。

2. 自動化測試的執行次數：

• 2.1 自動化測試的執行次數，是指自動化測試指令碼的生命週期內，這個指令碼能被執行的次數。
• 2.2 自動化測試的收益 = 自動化測試執行次數

　　

3. 自動化測試實施成本比：

• 3.1 計算公式：

• K ：手工執行自動化用例所花費的時間成本；
• n：自動化測試用例執行的次數；
• c1：花費在自動化測試前期的成本 (時間成本 + 人力成本 + 金錢成本);
• c2：花費在自動化測試後期的成本 (時間成本 + 人力成本 + 金錢成本)。

7. 軟體測試架構師的軟能力修煉：

1. 溝通和協商：

• 1.1 產品測試中的溝通原則：

  • 1.1.1 儘早溝通：
  • a.在進行一項測試活動 (如測試設計、測試執行等) 之前，需要把目標、要求、期望的結果和可能的問題儘早溝通清楚，防患於未然。
  • b.儘早溝通能夠幫助我們預防分歧。
  • 1.1.2 既要對事，也要對人：
  • a."對人"意在強調我們在溝通時，需要理解你的溝通物件，要學會換位思考，即使是同一件事情，在表達上也需要以對方能夠理解的方式來表達。
    

• 1.2 透過溝通來獲得對產品測試有用的資訊：

  • 1.2.1 以測試的視角來讀需求、設計文件，來準備溝通的問題：
  • 測試的視角：
    • a.需求是否可以測試？ 需求怎麼測試？ 怎樣才算驗證透過了？
    • b.設計是否可以測試？ 需要怎麼測試？ 怎樣才算驗證透過了？　　　
      　　　　　
  • 1.2.2 以需求工程師或開發的視角來問問題：
    
  • 1.2.3 總結、跟蹤和確認：
  • a. 有時候需要分多次進行溝通，這就需要我們及時總結本次溝通的結論和需要進一步跟蹤或確認的事情，並且確定下一次溝通的時間和主題。

• 1.3 和測試團隊成員溝通：

  • 1.3.1 對一個測試團隊來說，測試用例和產品缺陷是主要輸出。測試用例質量的好壞，會影響測試執行；測試執行又會影響到產品缺陷的發現，影響產品質量。
  • 1.3.2 軟體測試架構師，作為測試團隊的技術長，透過制定測試策略來保證測試活動的順序進行，測試策略制定好後，需要和測試團隊溝通，統一策略中的目標、思路和方法。

• 1.4 和領導或投資決策者溝通：

  • 1.4.1 對領導或決策者來說，它們一般不會太關注測試的細節，而會更關心下面所列的內容：
  • a.產品測試結果和產品的質量評估結論；
  • b.重要 bug；
  • c.重要風險；
  • d.進度。
  • 1.4.2 因此我們在和他們溝通時，首先要避免陷入溝通產品測試的細節中。在措辭方面，少用 “可能”、“感覺” 等這類不確定的詞語，在表達上也不要輕易下結論，儘量不讓不好的溝通習慣，在領導面前形成一種不夠成熟穩重的印象，使領導對你的基本素質產生懷疑。
  • 1.4.3 在溝通產品測試結果和產品的質量評估結論時，我們可以將測試覆蓋情況、質量目標的達成、遺留缺陷作為溝通重點。
  • 1.4.4 重要 bug 需要溝通的是當前進展、修改方式或規避措施。對典型的缺陷、後續改進計劃也可作為溝通內容。
  • 1.4.5 如果在溝通時，你發現你對某些資訊還不清楚，就承認自己不清楚，並聲稱自己馬上會去詢問相關資訊，並承諾反饋時間 (承諾反饋時間非常重要)。

2. 寫出漂亮的測試用例。