疏通Bug管道
（感謝Michael Bolton進行結構性編輯并幫助我發展了這個概念，這個概念源于我們最近的觀點。感謝RST Slack論壇上的Frances White和Marius Francu的評論。）
要進行良好的測試，就是在假設那些錯誤存在的情況下找到重要的錯誤（并且我們一直一直從該假設開始）。 這些錯誤始于黑暗。 我們將它們帶入光明。 我們通過以所有正確的方式操作產品來做到這一點。 有時我覺得這些Bug卡在了盒子里，我在晃那個盒子。 就像在蘇打水自動售貨機上丟了硬幣的人一樣敲打它。 請注意，我說的是我的感受。 我當然不認為，而且我很少說，因為它使測試看起來像是一種蠻力，而不是值得像我們這樣的聰明人考慮周到的設計過程。 （但是，是的，感覺就像是那個著名的行李箱廣告中的大猩猩。出來吧，Buuuugs！！）
我們稱其為測試過程的“動力學”模型。 該模型具有真實性，因為我們可以問：“為什么我們想要的時候才發現錯誤？” 答案很有趣而且很深刻。 產品，測試人員和測試過程本身（所有這些東西在一起）可以被視為具有不同過濾器的篩子，可以在測試報告上阻止good bugs。 測試的一部分是使這些過濾器保持暢通。 但是它們不僅是過濾器，而且是一系列證據中的步驟。 當你報告一個錯誤時，你所報告的是不間斷的推理鏈，其范圍從“這個問題很重要”到“這個存在”。
假設我們正在與開發人員交談，則此過程的邏輯如下：
你很高興知道此錯誤，因為你已經知道了它，因為在對它進行調查之后，我確定它是一個真正的錯誤之后才報告了它，從我在發現它后不久就注意到它，并觸發了它 通過一種我現在知道如何隨意執行的方法，這是有可能的，因為該錯誤已由你留在產品中。
那是一個令人費解的句子，不是嗎？ 忍受我 由于它既是篩子又是鏈子，所以我們稱它為兩種想法：錯誤報告管道。 讓我們仔細看看它以及它可能如何出錯：
要想報告是正確的，必須存在一個錯誤。
要報告實際錯誤，必須首先實際存在該錯誤。 所謂“錯誤”，是指有關產品在某人重要的觀點下會威脅其價值。 這意味著“錯誤”一詞是一個廣義的術語，涵蓋了錯誤，失敗，煩惱，甚至是改進機會。
即使用戶還沒有看到過錯誤，或者永遠不會看到錯誤，這意味著什么呢？ 從第一個原則開始：錯誤始終是產品，人員和環境之間的關系。 隨著人們對產品的了解越來越多，這種關系變得越來越清晰，他們對產品感到滿意或不滿意。 現在，想象所有重要的人都對產品具有上帝般的完美知識。 然后，無論他們同意產品有什么問題，都將是當時的“存在的錯誤”。 我正是這個意思。 當然，在遇到錯誤之前，您無法確定是否存在任何錯誤，但是錯誤的存在并不取決于您的知識或所看到的內容，而是取決于產品本身，相關人員以及 他們運作的環境。
測試的工作是探索那些事物的狀態。
要使錯誤影響到任何人，它必須是可生產的。
該錯誤必須能夠“發生”。 可生產性意味著必須有某種方式來表現行為，從而導致錯誤將引起的麻煩。 在代碼錯誤的情況下，“產生錯誤”意味著以觸發某種類型的錯誤的方式運行代碼。
開發人員和管理人員可以更容易地發現錯誤。 有時他們會告訴您不要報告你無法復現的bug。要讓他們打消這種念頭可以試試下面這段演講：
當然，在任何不平凡的情況下，我都會嘗試提供重現步驟，但是如果我嘗試了一段時間卻找不到重現該錯誤的方法怎么辦？ 如果發現它是一個非常重要的錯誤，該怎么辦？ 而且，如果您知道我看到它發生的那一次，該怎么辦？即使不重現該問題，您也已經意識到了問題所在？
如果我花太多時間嘗試重現它，那么我可能會花很少的時間進行其他測試。 如果我根本沒有提出這個bug，我甚至沒有給您修復的機會。 我認為，如果此類錯誤得到釋放，您將不會再對我說：“我們在該領域遇到了令人尷尬的尷尬，{在此處插入您的名字}，但請不要擔心，因為您正確地遵循了我們僅報告明顯錯誤的政策?。”
相反，為什么我們說漏洞的可重復性是可取的，但不是必需的呢？ 我建議：這是我們的政策，任何善意的提出任何bug的人都應被傾聽，而不應受到攻擊。 錯誤提出者應做出合理的努力，以清晰、簡潔、尊重且足夠詳細的方式報告給開發人員和管理人員。 我們的政策是歡迎任何此類bug提出，無論它們是否可復現（甚至是實際的錯誤），因為偶爾有不良報告比營造不利于甚至拒絕一份良好報告的敵對氣氛更好。
（我意識到這太長了，無法成為演講者，但請記住，演講者演講主要是針對那些不關心您的人的。）
錯誤可以存在但不能產生嗎？
是。 你可能會遇到無法訪問的代碼錯誤。 在該產品的未來開發會激活該代碼的情況下，這可能仍然很重要。 在無法訪問的代碼中查找錯誤的唯一方法是通過靜態分析（即不涉及運行代碼的方法）。
“Bug”是否可以被發現并且不存在？
是。 因為您可能會看到某些行為并認為是錯誤，所以后來意識到該行為實際上是正確的。
為了在測試期間引起您的注意，必須生成一個錯誤。
該錯誤必須“發生”。 在測試中，與code review（或任何形式的靜態分析）不同，您必須證明該錯誤的可觀察行為。 您可以通過在正確的條件下操作產品來完成此操作。 良好的測試是系統地覆蓋產品的各個方面（功能，數據，平臺配置，界面等）的過程，以便最大程度地產生每個重要漏洞的機會。
一個bug可以容易地產生但在測試過程中不產生嗎？
是。 您進行測試的方式可能與實際用戶使用產品的方式完全不同。 他們所見即所得，您可能在測試實驗室中從未遇到過。
可以產生“ bug”但不能生產嗎？
是。 您可能會使用輸入或系統配置觸發錯誤，而這些錯誤在實際使用中永遠不會可用。 否則您可能沒有測試產品的正確版本。
為了使錯誤在測試過程中引起您的注意，它必須是可觀察到的。
您必須能夠看到它。 可觀察性是可測試性的關鍵部分。 詳細的日志文件和對后端接口的訪問可以大大提高可觀察性。 晦澀的接口和滯留在JSON中的數據堆會減少它。
在測試過程中是否會產生錯誤，但無法觀察到錯誤？
從原理上講，所產生的任何錯誤都是可以觀察到的，但考慮到工具和方法發生時的實際情況，您實際上可能無法觀察到。 該錯誤可能破壞了數據庫，但是您無法檢查數據庫的整個狀態。
可以觀察到但沒有產生“錯誤”嗎？
可能吧 您的眼睛和記憶并不完美。 您可能會陷入視錯覺或錯誤的記憶中，以至于您認為自己看到了后來被證明從未出現過的東西。 測試人員需要欣賞人類感知的脆弱。
為了使錯誤在測試過程中引起您的注意，必須對其進行觀察。
您實際上必須看到它。 不能僅僅因為可以看到錯誤而看到錯誤。 以我自己進行視頻和重放測試的經驗，我為自己多么容易錯過那些眼前的錯誤感到震驚。
在自動化的情況下，您必須狹narrow而具體地觀察，因為您必須為要觀察的所有內容編寫代碼。 人類在進行任何給定的觀察時不那么可靠，但是能夠注意到意想不到的事情-沒有人告訴過您任何事情都重要，但是一旦您看到它們，您就意識到自己很重要。
在測試過程中是否有可以觀察到但未觀察到錯誤？
容易！ 可以減少發現錯誤的幾率之一是：相信可能沒有發現錯誤。 作為測試人員，說服自己很可能會發生錯誤非常重要。
另一個危險的現象稱為注意力不集中。當您嘗試注意一個特定因素（例如查看窗口標題是否正確）時，會發生這種情況，然后您會自動忽略其他因素（可能有些數字未加總）顯然是錯誤的。這就是為什么遵循詳細的測試過程可能會導致您遺漏重要錯誤的原因之一：遵循腳本往往會導致您的想法停滯。
為了最大程度地觀察，您可以成對進行測試，不止一次執行測試，對測試進行視頻錄制以便可以回放，不要在困倦時進行測試，或者至少不要進行測試：注意您可以輕松進行錯過只看到一次的重要錯誤。
是否有可以觀察到的“Bug”，但無法觀察到？
可能吧由于上述相同的原因：您的眼睛和記憶并不完美。另外，我們需要對錯誤敏感的非常精神的狀態（即認為它們很可能會發生錯誤），這也可能會欺騙我們的思維，使他們看到不存在的錯誤。例如，作為蜘蛛綱動物，我曾有過從眼角看到蜘蛛的經驗，這些蜘蛛原來是墻上的污跡，或者是地板上的絨毛。盡管如此，我的大腦還是希望我對蜘蛛過于敏感而不是不夠敏感，因此我同意我的想法。
為了使您的報告令人信服，您必須了解該錯誤。
您必須認為自己在某種程度上知道發生了什么。 您不一定必須了解所有發生的事情。 但是您要努力地理解它，以能夠對其進行描述，本地化并知道如何隨意復現它。
在測試過程中是否有可以觀察到但未理解的錯誤？
容易！ 您可能會看到任何給定的輸出（以天為單位），但不了解為什么產生了輸出，或者如何產生了輸出。 太多的測試人員常常對他們的產品如何運作只有很淺的了解。
有可以理解但不能觀察到“錯誤”嗎？
是。 您可能僅根據您對產品設計的了解或對類似產品中的錯誤的記憶而猜測或推斷出存在錯誤。 這稱為基于風險的測試設計。 這種理解可能會導致產生實際錯誤的方式，或者您可能會發現擔心的錯誤實際上并不存在。
要使您知道該行為實際上是一個錯誤，您必須使用一個好的Oracle對其進行身份驗證。
您必須有理由相信您正在查看的行為或屬性實際上是錯誤的。有些事情起初看起來可能是錯誤的，但經過進一步審查后才證明是正確的。有些事情在您看來可能錯了，但在重要人物的心中卻是正確的。這稱為“ oracle問題”。您怎么知道這是個錯誤？
作為測試人員，您是重要人員的代理。但是，讓所有這些人來觀看您的測試可能在經濟上不可行。因此，這意味著您必須內化他們的想法和想要的東西。當然，您可能有書面的要求或其他一些詳細的參考資料可以工作，但是對于多種技術和多種錯誤，通常沒有明確的預言。如果要實現自動化，這將是一個特別棘手的問題，因為從字面上看，您無法對產品可能無法正常運行的所有方面進行編碼，并且您會瘋狂地嘗試。
bug報告的底線是您必須能夠解釋為什么該bug是bug，以及為什么是重要的bug。
是否有可以理解但未通過身份驗證的錯誤？
是。 發生這種情況的通常方式是，理解“錯誤”的過程告訴您這是正確的行為。 您必須防止的是丟棄一個真正的錯誤，因為您使用的是弱預言或錯誤的預言。
是否有可以對“錯誤”進行身份驗證但不理解嗎？
是。 如果您誤解或錯誤地描述了某些輸出，則很容易看出您可能認為它是一個錯誤。 例如，如果某個報告僅以“訂閱計劃模式”創建，并且您看到它是在“基本計劃模式”下生成的，那將是一個錯誤-除非實際上是在基本計劃模式下并且您已經獲得了瀏覽器 標簽混淆。
為了使您的客戶了解該錯誤，必須對其進行報告。
您必須講述錯誤的故事。報告錯誤的方法有很多，從正式的（帶有重現步驟的Jira票）到極其非正式的（“嘿，看這個！”）。在您的報告中，您確定自己具有適當的知識水平，提供報告的論壇，應采用的形式以及所需的輔助材料等。
是否可以對錯誤進行身份驗證但尚未報告？
太頻繁！如果您對生氣的開發團隊或經理感到害怕，就會發生這種情況。也許項目太晚了，您不想讓他們感到沮喪。如果發現bug的速度如此之快，以至于您忘記了其中的一些錯誤，那么也會發生這種情況。我們稱其為“錢攤”綜合癥。
是否可以報告“錯誤”但尚未通過身份驗證？
是。如果對預言家有不同意見，但是您選擇無論如何都要舉報，則可能會發生這種情況。或者，如果不是測試員的人正在查看自動檢查產生的原始結果，則可能會發生。在后一種情況下，經常發生的問題是管理層聳聳肩說：“哦，這可能只是自動化中的小故障。” （我見過的任何項目都不能在沒有人為干預的情況下讓機器“報告錯誤”，除非有明顯的扣籃之類的事情，例如墜毀或違反安全性。即使如此，它也不是真正的錯誤報告，還是麻煩警報，正確進行操作后，人工身份驗證所帶來的價值是您認為未撰寫的報告絕對值得您花時間閱讀。）
總結
- 上一篇： List类系列（一）：list中各元素出
- 下一篇： 通俗易懂地搞懂决策树（Decision