【功能測試】測試過程中如何提升測試質量

用例

一. 用例設計

1. 什么是好的測試用例？

我們舉一個“池塘捕魚”的例子，來理解什么是“好的”測試用例。
如果把被測試軟件看作一個池塘，軟件缺陷是池塘中的魚，建立測試用例集的過程就像是在編織一張漁網。“好的”測試用例集就是一張能夠覆蓋整個池塘的大漁網，只要池塘里有魚，這個大漁網就一定能把魚給撈上來。如果漁網本身是完整的且合格的，但是撈不到魚，就證明池塘中沒有魚，而漁網的好壞與池塘中是否有魚無關。

1. 定義

   好的測試用例是一個完備的集合，它能覆蓋所有等價類及各種邊界值及邊界條件，而與是否能發現缺陷無關。

2. 好的測試用例的特征

   1. 整體完備性
   2. 等價類劃分的準確性
   3. 保證所有可能的邊界值和邊界條件（包括各種極端情況和特殊場景，此類不是很少出現就不測試了，很多出現的問題都在此列）

2. 寫出好的測試用例的前提是什么？

1. 深入理解需求

   寫出好的測試用例的前提必須是深入的理解業務需求，只有真正的理解了業務的原始需求，才能從業務角度設計出針對性明確，從終端用戶場景考慮的測試用例集。

   測試雖然是最后一環，但不僅僅是只做執行者，對于需求的不明確和不理解都需要提出質疑，通過產品的解答和多方探討，這樣才能更加深入的了解需求及背景。

   一些感悟：
   1. 需求理解的 "記憶斷層" 問題
   	需求及背景了解不深入的話，很難形成記憶，后續迭代測試過程中很容易產生漏測。【缺乏業務上下文支撐的記憶，本質是碎片化的信息堆砌】
   2. 模糊需求的 "觀察盲區" 風險
   	產品需求存在定義不明確的功能點或未明確的兼容問題，在測試過程通過現象來觀察，發現的潛在問題未及時轉化為為明確的需求，那么這個點在后續測試過程中很容易忽略掉。【未被系統化沉淀的臨時認知】
   
   不管產品需求還是技術設計，同理。
   

2. 需要了解開發設計及表結構，其好處是什么？

   產品思維，開發思維是不一樣的，在開發過程中總是存在很多隱性需求。但是這些需求prd中不會呈現。

   1. 能更加深入的了解系統內部的交互，數據讀取和存儲過程。測試過程中更加具有針對性，減少漏測和重復測試。

   2. 提bug的時候能更加精準的定位bug產生的原因，并準確的對bug進行描述，從而提高開發修復bug的效率。

   3. 由于對bug產生的原因更加清楚，能更加精準的復現問題并快速的回歸驗證。避免了bug復現困難的或者不知道這個bug怎么產生的問題。

   4. 測試完成后，自己內心對質量也是有底氣的，這個時候假設給你提出一個沒有測試的場景，你可能已經知道這個場景的預期結果是什么了。這個是由于足夠了解開發設計和內部實現的原因。

   我的做法：
   1. 大型項目一般有技術設計評審會議，測試會提前介入了解設計。【但是細節還需要找對應的開發了解】
   2. 沒有進行技術評審的需求，會在編碼階段找開發了解，并根據設計提出自己的疑問，防范于未然。
   3. 根據需求及技術設計來編寫用例。
   4. 提測前用例評審。
   

3. 應該站在不同的角度進行測試，如用戶角度，測試角度，開發角度。最終目標必須是以用戶為前提。

   在了解開發設計和深入理解需求的前提下，還要站在用戶的角度考慮問題，比如這樣設計是否合理，作為用戶是否會存在什么樣疑問等。

3. 好的測試用例的設計方法是什么？

基本要求：

1. 等價類劃分法

2. 邊界值分析法

3. 錯誤推斷法（探索性測試）：

   定義：在執行測試過程中，也是在不斷的學習被測系統，基于對被測軟件的理解以及過往經驗，直覺，同時結合自己的猜想和邏輯推理來推斷軟件可能存在的缺陷。

   優點：能低成本的精準測試。

   以此，可以根據以往經驗建立缺陷檢查表。

更高的要求：

(1)只有深入理解被測試軟件的架構，才能設計出有的放矢的測試用例集，去發現系統邊界以及系統集成上的潛在缺陷。作為測試工程師，切忌把整個被測系統看作一個大黑盒，必須對內部的架構有清楚的認識，比如，數據庫連接方式、數據庫的讀寫分離、消息中間件 Kafka 的配置、緩存系統的層級分布、第三方系統的集成等。

(2)必須深入理解被測軟件的設計與實現細節，深入理解軟件內部的處理邏輯。單單根據測試需求點設計的測試用例，只能覆蓋“表面”的一層，往往會覆蓋不到內部的處理流程、分支處理，而沒有覆蓋到的部分就可能出現測試遺漏。在具體實踐中，測試人員可以通過代碼覆蓋率指標找出可能的測試遺漏點。同時，切忌以開發代碼的實現為依據設計測試用例。因為開發代碼實現的錯誤會導致測試用例也出錯，所以應該根據原始需求設計測試用例。

(3)需要引入需求覆蓋率和代碼覆蓋率來衡量測試執行的完備性，并以此為依據來找出遺漏的測試點。

作為測試人員，需要注意以下幾點。
(1)需要明白，“好的”測試用例一定是一個完備的集合，它能夠覆蓋所有等價類以及各 種邊界值，而能否發現軟件缺陷并不是衡量測試用例好壞的標準。
(2)設計測試用例的方法有很多種，但綜合運用等價類劃分方法、邊界值分析方法和錯誤推測方法，可以滿足絕大多數軟件測試用例設計的需求。
(3)在設計時，“好的”測試用例需要從軟件功能需求出發，全面地、無遺漏地識別出測試需求。
(4)如果想設計一個“好的”測試用例，必須要深入理解被測軟件的架構設計，深入理解軟件內部的處理邏輯。

【引】《測試工程師全棧技術進階與實踐》茹炳晟

4. 測試策略，即測試的優先級是什么？

1. 功能測試

   1. 主流程冒煙測試，首先保證主流程可用，防止有阻塞問題導致無法測試。
   2. 優先測試業務或代碼復雜程度高的，以及需求點不是足夠明確的或者出現爭議討論的點，往往最容易出問題。對于這些進行優先測試，好處是遇到問題能夠提前暴露（中間可能存在未考慮的場景或方案重新設計等），防止問題過晚的暴露而延誤工期。
   3. 服務層優先于頁面，優先保證數據的業務邏輯正常。數據正常后，這個時候只需要關注不同的用戶端即可。

   缺點：
   越是簡單的越是容易漏掉。
   用例設計的時候容易遺漏產品沒有提及的且過于簡單的。
   有時候容易陷進復雜的邏輯里邊持續驗證，以求在復雜的邏輯里邊發現更多的問題。
   
   例如：質檢重構（新增物品描述）需求
   拍品獲取質檢模版的時候，僅僅給質檢傳了分類品牌，沒有傳系列導致獲取的模版內容缺失。
   

2. 兼容性測試

3. 性能測試

二. 用例評審

1. 統一理解

   1. 需求文檔可能存在描述模糊的地方，評審階段可以提前澄清，避免返工。
   2. 測試和開發可能會存在理解不一致的地方，提前發現能盡早避免因理解差異導致的問題。

2. 用例查漏補缺，確定測試范圍

   站在開發的角度可能會提出更多細節的點需要驗證，以及告知可能影響的范圍。

3. 精簡用例，可以避免重復測試

   根開發設計相關，但是對于測試工程師來說可能就是黑盒，用例設計會出現重復驗證的情況，這個時候也可以部分了解開發設計。

三. 回歸測試

1. 為什么要回歸？

   1. 技術再牛的測試也有未考慮到的點，可能考慮的問題比較深入，但是考慮的不一定全面，因此需要整體回歸測試。

   2. 測試用例本身沒有什么好壞，但是測試用例在編寫和評審過程中難免有遺漏的點，測試用例集不一定完備。

2. 回歸需要劃定回歸范圍

   1. 為了節省成本，基于代碼變更的影響需要評估風險并縮小回歸范圍
   2. 重點業務流程全場景回歸。

3. 自動化支持

   如果采用人工完全回歸的方式，時間和人力成本過高。因此平時需要將核心業務加入到自動化中。

軟件測試領域常見的一些理論

1. 殺蟲劑效應

   1. 本質：

      測試人員按 “慣性思維” 執行測試，長期使用固有的測試用例，即使反復的執行，也很難發現新缺陷或變異缺陷。

   2. 場景：

      1. 長期使用固定的自動化測試腳本，未根據需求變更或代碼修改更新用例。
      2. 手工測試人員依賴經驗，反復執行相同的操作路徑，忽略邊界條件或異常場景。

   3. 避免方式：

      1. 探索性測試：不依賴預設用例，隨機模擬用戶操作，發現意外缺陷。
      2. 逆向測試：故意輸入非法數據、中斷網絡連接等，驗證系統容錯性。
      3. 交叉測試：不同團隊或人員交叉執行測試，避免 “慣性思維” 導致的漏測。

2. 缺陷集群性效應

   1. 本質：

      軟件中的缺陷往往不是隨機分布的，而是集中出現在少數高風險模塊或代碼區域，也就是常說的二八原則。

   2. 表現：

      測試中常發現，在某個功能點首次發現缺陷后，深入測試該模塊往往能挖掘出更多缺陷。

   3. 避免方式：

      聚焦高風險模塊，加強專項測試，對于功能設計復雜的模塊出現的bug需要深度排查。

其他（以往具體測試經驗分享）

1. 用例及時調整

1. 不管在項目的什么階段，用例都需要及時調整
2. 測試過程也是對系統深入學習了解的過程，因此在對開發設計更加了解的情況下，用例也可能需要進行相應的調整

2. 數據安全方面

1. 接口并發請求，模擬用戶連續快速操作以及后端是否需要加鎖處理

   場景：訂單重復支付，訂單重復寄出等

   實現：可以使用接口并發工具，如fiddler，charles，jmeter等工具

2. 訂單不同狀態下，進行非該狀態下操作，后端是否需要添加錯誤提示或者冪等

   場景：如訂單競價中狀態下操作寄出

   實現：通過調用API實現

   當然上邊這個情況普通用戶不可能操作到，如果時間緊的情況下僅考慮用戶能操作到的場景即可，如交易完成時取消訂單等。

3. 分布式事物最終一致性

   如一個對外接口里邊同時調用了第三方接口并進行了數據存儲，如果第三方接口失敗，代碼會怎么處理？

   是否有重試或者調整實現方式來保證數據一致性等？

   場景：下單完成后扣減庫存

   實現：可以讓開發協助mock接口調用失敗情況。

4. 修改一些重要參數提交檢查是否校驗（接口數據與數據庫不一致）

   場景：類似于電商提交訂單的時候，通過修改API金額參數后進行提交等。

   實現：通過調用API實現

3. 快速提高測試效率

1. APP端數據mock

   如果造數據繁瑣而想要快速驗證app的頁面展示，可以使用fiddler，charles工具進行請求或響應攔截，并修改響應數據。

2. 在了解開發設計及數據庫的情況下，修改數據庫數據達到快速驗證的目的

3. 通過接口自動化的方式快速造數據并測試對應的功能點

4. 查看代碼或者跟開發確認邏輯

   如上邊提到的訂單不同狀態下進行非該狀態下操作問題，例如寄出狀態是3，那么代碼是否!=3的情況下直接報錯提示，這個時候只需要看一個操作攔截即可。

最后

以上，雖然只是功能測試 過程中如何提高軟件質量的方式。

但是測試介入其實涵蓋了項目的不同階段。除此之外，還要養成業務邏輯整理的習慣，及時更新接口和UI自動化腳本進行輔助測試等等。

整個測試架構還包含更多，如代碼覆蓋率工具如JaCoCo，微服務模式的灰盒測試，性能與安全測試等等。