作為測試人員，你對自己的測試結果有信心嗎？

作為一個測試人員，報告相關人員影響系統的功能和威脅系統性能的問題是我們工作中的任務。

可能你常會遇到領導攔著問你：我們測試結果如何，還有故障嗎？版本可以發布了嗎？

但是如果你作為測試人員不知道系統的邊界呢？如果你把測試結果的信心只是建立在應該一小部分測試的內容上，該怎么辦？如果你不知道系統/解決方案如何或何時更改了怎么辦？如果你缺乏這種控制，你怎么能說你對測試結果有信心呢？

其實這些問題與我們產品的可測性相關。如果我們獲取知識的平臺不穩定，我們怎么能夠確保所學的東西是正確的呢？

舉例說明

一個系統由許多子系統組成，解決方案由許多不同的參與者更新，一些人手動執行，一些人通過持續部署執行。

更大的解決方案經常改變，端到端測試人員有時需要花費相當多的時間來執行測試。通常情況下，他們開始一個測試，在此期間解決方案被更新或更改為新的組件或子系統。在測試的結果中很難得到任何確定性。

當你測試一個系統并記錄測試結果時，你需要能夠以多種引用該系統。

如果系統不斷地發生變化，你需要以某種方式知道它什么時候發生了變化，變化是什么以及在哪里發生的。

如果你不知道哪里發生了什么變化，這將使你更難計劃你的測試范圍，也很難相信測試的結果。

識別系統

識別系統的一種方法是首先識別系統由什么組成，考慮系統的邊界和包括什么、是否應該將環境配置作為系統的一部分……

世上沒有完美的準則。你只能在一定程度上定義系統。當你定義系統的部分或組件時，你就能獲得相應的測試準則（也可以叫“神諭“）。

但是，試想一下，如果沒有權威的準則，你怎么測試呢？或者說你怎么指導一個初級測試人員運行測試用例，并告訴他是否通過了呢？本文討論的核心就是：測試人員的信心來源——權威的測試準則。

測試準則

其實測試準則的問題簡單來講，就是“一致性”問題。期望結果與實際結果是否一致的問題。

我們已經說過：世界上沒有完美的準則。權威的測試準則只在局部有效，即只能與我們定義的系統相一致才有效。那么，我們在定義權威的測試準則時，需要考慮哪些方面呢？

用戶需求一致性

我們設計的產品要符合用戶需求，因此滿足用戶需求是我們首要考慮的測試準則。模擬用戶真實的部署環境、參考用戶的行為習慣、模擬用戶的數據等制定測試用例，將用戶需求與測試結果進行一致性對比，從而判定測試是否通過。

可比產品一致性

在可比產品中，類似的功能行為一致。這通常在對標中經常出現。比如，windows系統我們習慣性使用ctrl+c表示復制，ctrl+v表示粘貼。若是在linux系統中定義ctrl+v表示復制，ctrl+c表示粘貼，則會造成許多習慣性使用沖突。

歷史產品一致性

現在的行為與過去的行為一致。可能有的人會對此提出異議：如果我得產品功能發生變更，這一準則是否毫無意義或者起了反作用。在這里，我們說的是，如果相同的功能未發生變化的時候，需要與歷史產品保持一致。這經常出現在回歸測試中。

形象一致性

這一點很少被提及，或者說很容易被忽略。但對于大公司來說，這一準則又潛在影響著其公司發布的產品。例如，阿里巴巴集團旗下產品設計喜歡用橙黃色，這與其最初產品定調是相一致的。

聲明一致性

這里的聲明包括：文檔、規范或廣告等。產品行為需要與聲明不一致，否則將會產生矛盾。聲明一致性常用于我們的文檔測試。

標準或規定一致性

這里的標準或規定指的是基礎標準，如數學運算規則、數學運算結果，或國家安全法例條文等規定。我們設計的產品不能違反這些基本標準或規定，例如：如果計算結果2+2=5，我們則能快速判定產品出現了錯誤。

目的一致性

產品功能與表面表現一致性。例如，某個應用下拉框或輸入框我們選擇或輸入“A”，但產品內部功能并沒有接收到或正確傳遞這一選項，則屬于目的一致性。

以上所述，只是制定測試準則的一部分要求或思考。或許，你還有更好的建議呢？歡迎討論。

最后：在我的V：atstudy-js，可以免費領取一份10G軟件測試工程師面試寶典文檔資料。以及相對應的視頻學習教程免費分享！其中包括了有基礎知識、Linux必備、Shell、互聯網程序原理、Mysql數據庫、抓包工具專題、接口測試工具、測試進階-Python編程、Web自動化測試、APP自動化測試、接口自動化測試、測試高級持續集成、測試架構開發測試框架、性能測試、安全測試等。