本文非原創，翻譯自https://qahiccupps.blogspot.com/2021/09/693-ok.html
“我們的測試用例中有多少是自動化的？”
這個問題有很多內容，特別是當它是監控測試狀態的指標的時候。這也不是我第一次被問到。根據我的經驗，當有人提出這個問題時，可能是因為（a）他們聽說過它，（b）測試用例的數量是可數的，並且（c）他們的任務是提供一個管理層可以接受的數字，並且每月向大量不會看它的人發郵件做 ppt，然后闡述自動化“測試”的價值。
如果這聽起來很憤世嫉俗……好吧，我想是的。
但是，並不意味着我對了解您的需求並試圖幫助你獲得可以你需求的東西不感興趣。
我們能談談你的追求嗎？為什么？
我們可以？太好了！
我會開始。我對這個問題的一些考量是：
- 自動化測試覆蓋率似乎被認為是我們測試的一種衡量標准
- 這樣的數字不會說明做過的測試的價值
- 測試用例的定義沒有實際意義
- ...而且，不管它們是什么，測試用例只是我們測試的一部分
- 有一個隱含的假設，即自動化程度越高越好
- ...但自動化有其自身的風險
- ...而且，無論自動化意味着什么，自動化測試用例只是我們測試自動化的一部分
如果我看看我們的測試方式，以及我們可能稱之為測試用例的內容，我現在可以想到三種方式來回答您的問題：
- 從我認為問題的意圖來看，我們沒有測試用例。我們所有正在進行的測試都是探索性測試，雖然我們可能會用自動化的方式記錄測試結果，測試完成以后我們把現存的用例轉換成自動化是沒有意義的，我們標記為得分為 0%。
- 出於練習的目的，我准備將回歸測試用例集中的每個斷言描述為一個測試用例。因為它們將是我們唯一的測試用例，而且它們都是自動化的。得分100%！
- 好的，我們在測試用例管理系統中有一些項目。這些是歷史的發布驗證記錄，（大多數）測試團隊以外的人在我們發布之前會進行這些檢查。我更喜歡將它們視為檢查點，但我很現實，並且知道我的一些同事只是想遵循步驟。相對於“自動化測試用例”的數量，它們很少，但如果我們將它們包括在我們的計算中，我們會將分數降低到 99%。
這些答案對我們中的任何一個來說似乎都不是很令人滿意，是嗎？
對我來說，這種指標充其量只涵蓋了我們所做工作的一小部分，其背后的假設非常值得懷疑。對您而言，該指標的重要性不及某個合理的數字，該數字可以在ppt中用來量化測試的最終效果。對此我也有一些想法：
- 對我來說，測試是知識性的工作，因此很難用簡單的數字來衡量
- 測試不是獨立於其他產品開發活動而存在的
- 如果沒有創建測試用例等人工產出物的話我們也可以完成良好的測試
- 沒有經過對話交流和正當理由而強加的指標可能會受到懷疑
- 強加的指標可能會有被造假的風險
- 從產出物（bug列表，用例設計）開始是本末倒置
- ... 最好先問你想測量的指標是什么以及為什么
那么，例如，是否希望衡量客戶對產品的滿意度？是為了衡量測試的貢獻嗎？是否要查看時間花在了企業想要停止的活動上？是尋找瓶頸嗎？或者是其他東西？如果我們同意使用某種指標，我們如何向測試人員保證他們沒有受到不公正的評價，並且他們不應該為了使數字看更好而修飾或者歪曲他們的工作實踐？
我們需要的不僅僅是花言巧語。想象一下，你被告知你的表現將根據你發送的電子郵件數量來衡量，你會如何反應？你會在譏諷它的同時但還是發送更多的電子郵件嗎？您會發送電子郵件而不是進行丁丁或者是企業微信的溝通嗎？您會關心對您、他人和企業的潛在不利影響嗎？別人怎么能說服你采取不同的行為？最后，您是否真的希望以良好的意圖研究合理的指標並根據結果采取行動？如果是這樣，那么我將盡我所能幫助獲得一些合理的東西，有明確的警告，公平的，透明的，承認其收集涉及的混亂，可以有效地從數據中得出我們有，這在商定的誤差范圍內，這反映了我們正在做的工作。如果沒有，那么我會問你什么樣的數字會更好的反映出實際的工作效果？我會簡單地告訴你：讓我們說 69.3%，好嗎？
作者使用的英文沒有那么通俗，加上翻譯能力有限，所以最后可能需要簡單的提煉一下文章的觀點
- 自動化測試的覆蓋率應該不能作為匯報測試效果的指標
- 測試的目的不是為了產出好看的數據或者指標
- 不合理的指標會造成不合理的結果而忽略了測試工作的實質