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

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

可能你常會遇到領導攔著問你：我們測試結果如何，還有故障嗎？版本可以釋出了嗎？ 加我VX：atstudy-js 回覆“測試”，進入 自動化測試學習交流群~~

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

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

舉例說明

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

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

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

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

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

識別系統

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

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

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

測試準則

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

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

使用者需求一致性

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

可比產品一致性

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

歷史產品一致性

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

形象一致性

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

宣告一致性

這裡的宣告包括：文件、規範或廣告等。產品行為需要與宣告不一致，否則將會產生矛盾。宣告一致性常用於我們的文件測試。

標準或規定一致性

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

目的一致性

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

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

最後：

可以到我的個人V：atstudy-js，可以免費領取一份10G軟體測試工程師面試寶典文件資料。以及相對應的影片學習教程免費分享！其中包括了有基礎知識、Linux必備、Mysql資料庫、抓包工具、介面測試工具、測試進階-Python程式設計、Web自動化測試、APP自動化測試、介面自動化測試、測試持續整合、測試架構開發測試框架、效能測試等。

這些測試資料，對於做【軟體測試】的朋友來說應該是最全面最完整的備戰倉庫，這個倉庫也陪伴我走過了最艱難的路程，希望也能幫助到你！