方法定義

錯誤推測法是指：在測試程序時，人們可以根據經驗或直覺推測程序中可能存在的各種錯誤，從而有針對性地編寫檢查這些錯誤的測試用例的方法。

主要還是一個慢慢積累的過程。一般來說，常見的錯誤推測法都是有一些慣例的，也就是比較容易出錯的地方。我們可以從這方面可以入手，比如在輸入年齡的時候，有個年齡輸入框，輸入一個超長的混合字符串，這個是很容易出錯的。

該方法強調的是對被測試軟件的需求理解以及設計實現的細節把握，當然還有個人的能力。那么顯而易見地，這個方法的缺點就是太過依賴個人能力，難以系統化。因此，這個方法一般是作為測試用例設計的補充，而不是單獨用來設計測試用例。

優點

錯誤推斷法是一種基于經驗的測試設計方法。使用錯誤推斷法來設計測試用例，測試用例的有效性（測試用例發現缺陷的能力）會比較高，但也容易引發過度測試——測試者可能會為了發現缺陷而測試得過于嚴苛，卻忽視對一些基本功能和場景的測試驗證，造成測試遺漏。

一般來說，我們建議把錯誤推斷法和基于模型的測試設計法放在一起使用，在保證測試用例對場景、功能、設計有一定覆蓋度的基礎上，進一步增加測試用例的有效性。

錯誤推斷法中的“經驗”，主要源于對產品缺陷的分析。

與等價類劃分法和邊界值分析法的區別
錯誤推測法其實它不同于等價類劃分法或者邊界值分析法，它是對有效等價類和邊界值分析法的一個補充。因為錯誤推測法從這個里面我們也可以看出，從這句話也可以看出它注重的是一個推測。所謂的推測就是你要有自己的經驗，就是在寫了很多的測試用例之后，積累了很多的經驗。

遇到一個產品之后，就根據自己的經驗，在有效等價類和邊界值分析法之外，仍能想到一些測試它的方法，這就是錯誤推測法。這個方法主要還是靠經驗，個人經驗比較豐富的話，這個方法可以寫很多測試用例。

操作步驟

錯誤推斷法的操作步驟如下：

對非測試用例發現的缺陷進行分析時，用了很多啟發式的問題，我們可以一邊給自己提問題，一邊記錄下想到的“靈感”；也可以由一個團隊來進行上述過程，大家一起來激發靈感，拓展思路，提高測試用例設計的有效性。

舉例

那很有可能這個引號作為一個數字判斷也是容易出錯的，所以這都是容易忽略的，忽略的狀態下，所以一個單引號也是容易會出現問題的。所以通過錯誤推測法的話，寫測試用例的時候，對于輸入條件就可以寫比如說年齡輸入的話就是 20 到 99 的整數。

我們就可以對它進行分析，在輸入框輸入超長字符串，也有可能報錯。錯誤推測的取值可以寫一個很長的一個字符串，把這個字符串作為一個測試用例，輸入到輸入框里面，看它是否出錯。還有全角，我們把這些全角的字符串也輸入進去，作為一個測試用例。

還有 0，還有單引號都一樣，都作為測試用例。當然錯誤推測法不止這幾種羅列的可能性，只不過這幾種比較常見，還有更多的一些常見的可能性，還需要自己去探索一下。

案例總結

強調：沒有出現過此bug，不代表這個場景不會出問題

元素類型遍歷

當一個元素有不同種類型時，需要遍歷該元素所有需要支持的元素，比如手機號運營商有移動、電信、聯通，測試手機號相關的功能，需要遍歷到這3個運營商

根據以往經驗，港股是大家比較容易忽略的點，剛開始是港股，后來是ETF，現在已經有多起類似bug

聯動場景&展開收起后跳轉&跳轉頁面后返回的記憶場景

一般一個功能，多個頁面之間交互上是有關聯的，不同頁面、不同操作之間的聯動

不同技術棧協議測試

客戶端與H5：此處協議是刷新機制，H5添加/編輯/刪除操作后需要看客戶端是否刷新；

服務端與前端/客戶端：前端添加/編輯/刪除后，前端需要發起請求告訴服務端，此時響應結果應該是添加/編輯/刪除后的結果，為了驗證數據庫的保存操作正常，需要驗證退出再進入頁面，數據是修改后的，而不會恢復成修改之前的。

涉及到客戶端與H5交互的，需要測試協議之間是否是通的，比如添加流水之后，返回原生是否刷新等，我們需要從開發方案上理解，為什么會產生此種bug，一般情況是開發忘記請求接口。

元素/頁面依賴驗證

當前頁面的展示，依托于一些添加的記錄，比如交易流水、記賬買入流水、記賬指出流水等，當把所有記錄都刪除時，當前頁面預期是無法展示數據的，此時頁面是否正常顯示，如果沒有兼容，可能會出現空白、數據都顯示–、null、NaN%等，比較好的用戶體驗是，先跳回到該頁面，再返回到上一級頁面。而停留在該頁面是不好的用戶體驗，因為當前頁面已經沒用了，不應展示。

不同頁面對于同一元素操作的聯動性

能夠不斷切換不同元素的場景，那我想導航欄和下面的內容是否可以及時聯動，比如頻繁快速切換，頁面內容與標題能否對應，（需要了解開發方案）

當兩個頁面都有同一個切換功能，比如頂部導航欄切換元素1，可以先在A頁面多次切換，再查看B頁面的內容是否是當前元素1的內容

交互的邊界場景

注意：不是只有數值才有邊界值，交互場景也有邊界場景，比如可以左右滑動的Colum，滑動到最左邊和左右邊，是否有合適的間隔，比如一般都會在左側會設置間隔，但是滑動到最右側忘記加間隔，會導致整體不協調

比如頁面支持上下滑動是，滑動到某欄懸浮、滑動到最底部，顯示是否正常，有時候底部按鈕會被底部的操作欄遮擋一部分，具體解決方案是，增加距離底部的間距

日期的邊界值

除了數值邊界值、頁面交互邊界場景，涉及到日期的還需要日期的邊界值，具體如下：

年份：歷史年份、當年、未來年份

月份：去年月份、今年歷史月份、當月、未來月份

日：去年日期、今年歷史日期、昨日、當日、未來日期

日期的特殊性：工作日、非工作日、節假日、短節假日、長節假日、交易日、非交易日、紀念日、普通日等，涉及具體業務，業務場景不一致，可以自己選擇列舉

歷史業務耦合

此項對業務經驗掌握要求很高，業務越熟悉越能發現問題，那么對于經驗不足的同學怎么辦呢？可以在編寫用例時進行實操，查看現有應用當前頁面有哪些元素和功能，然后聯想需求更改可能產生的問題，或者產品、開發可能遺漏的點。

新業務支持

當一個業務歷史支持了類型A,B，此次需求新增C類型，雖然模型是復用的，但肯定是部分通用的，或者我們需要通過測試來發現應用到新類型上的不兼容性，需要開發專門針對此種類型做兼容

比如：支付寶支持買普通基金，如果后續支持港基、QDII基金，需要針對該基金做完全測試

為什么要考慮這么多？

因為線上不支持一定是有原因的，一般頁面是通用的，想要支持多賬戶類型難度不大，主要是依賴的流水不同，導致算法的兼容性存在難度，所以一般剛開始會先支持A種賬戶，有更多時間再支持B種賬戶（兩融的用戶少，優先級低），所以具體流程就是：確定歷史不支持原因—>確定特殊性（特殊流水）—>現有其他功能是否有應用—>開發實現方案—>確定測試顆粒度

匯總的聚合和去重

涉及到匯總，我們要想到多個子元素如果存在相同的元素，聚合后按照業務進行聚合去重，我們重點看下聚合的場景

需要理清楚開發的方案是通過什么去聚合的，避免不同元素的記錄會產生覆蓋的情況

極限測試

這個和邊界值有點類似，但又有不同。

比如限制只能添加30個賬戶，那么我們需要測試30和31的情況，但是這并不是真正意義上的極限測試，因為這個為了避免數量多有問題，特意設置了最大值，但在實際測試情況中，會有沒有設置閾值或者最大值的情況，產品并不知道閾值到底在哪里，同時也想盡量支持到最大的情況，不想給用戶太多限制，比如記錄交易記錄、記賬等情況。

如果只是讓添加流水就好了，重點是后續的根據流水進行全量計算和增量計算，如果你添加足夠久的流水，就會出現超時、報錯、計算出錯等情況，這里包含了壓測的測試手段。要求不是很高的情況下，可以根據當前經驗以及查到的現有用戶數據進行評估，一般用戶最多只會添加多久的數據，支持一個大致的最大值就行。當然如果性能要求高的，肯定是要進行完備的壓測。

順/逆狀態轉換

測試中還有一個高頻的測試場景：狀態轉換

一般測試中會有多個狀態，相鄰的狀態之間、非相鄰的狀態之間都能正常轉換

比如正常流程是狀態1—>狀態2—>狀態3—>狀態4，如果業務允許，逆序狀態測試狀態4—>狀態3—>狀態2—>狀態1，以上為相鄰狀態轉換，非相鄰狀態如果業務支持也需要遍歷轉換場景，比如狀態4—>狀態1

案例1：淘寶下單，狀態流有，待付款—>待發貨—>待收貨—>待評價—>退貨退款，其中待發貨、待收貨、待評價3個狀態都可以直接到退貨退款狀態。當然這個案例中所有狀態是不可逆的。

參考文檔：https://www.cnblogs.com/northeast/p/15817894.html

參考書籍：《測試架構師修煉之道：從測試工程師到測試架構師（第2版）》

總結

以上是生活随笔為你收集整理的【经验】软件测试用例设计之错误推测法的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。