我應該繼續註冊失敗嗎？

Question

我正在爲我維護的應用程序開發自動化迴歸測試套件。在開發自動化迴歸測試時，我遇到了一些幾乎肯定是bug的行爲。所以，現在，我已經修改了自動化迴歸測試，以避免註冊失敗 - 我故意故意允許這種不良行爲通過。

所以，我對這個網站上其他人的意見感興趣。顯然，我會在缺陷跟蹤中添加一個錯誤，以確保錯誤行爲得到解決。但是，是否有任何令人信服的理由（無論哪種方式）改變回歸測試以不斷表明失敗或者讓迴歸測試中斷，並且在我們能夠修復缺陷行爲之前不會失敗？我認爲這是另一類問題中的6個問題，但我在這裏問，因爲我認爲其他問題可能會有所不同。

---

@保羅湯布林，

只要是明確的 - 我從來沒有考慮刪除的考驗;我只是在考慮修改合格/不合格的條件，以便在我每次運行測試時都不會在我的面前拋出失敗。

我有點擔心從已知的原因反覆失敗，最終得到像C++警告一樣的待遇。我認識那些在C++代碼中看到警告的開發人員，他們會忽略它們，因爲他們認爲它們只是無用的噪音。我擔心在迴歸套件中留下已知的失敗可能會導致人們開始忽視其他可能更重要的失敗。爲了避免誤解，我認爲C++中的警告是構建強代碼的重要幫助，但從我遇到的其他C++開發人員判斷，我認爲我是少數。

Answer 1

我會說「地獄呀！」。簡單的事實是，它失敗了嗎？是!然後它應該被記錄。通過允許失敗的測試通過，你幾乎可以妥協你的測試。

我個人關心的一件事是，如果我這樣做，並且乘坐公共汽車，那麼「修補程序」可能不會被刪除，這意味着即使在「錯誤修復」後，該錯誤仍可能保留。

留在，更新項目的筆記，甚至移動的嚴重程度下降（如果可能），但肯定不打破正在檢查破事的事;）

Answer 2

如果您停止測試它，您將如何知道它何時被修復，更重要的是，您將如何知道它是否會再次被破壞？我反對進行測試，因爲您可能會忘記將其重新添加回來。

Answer 3

應該仍然是一個失敗，如果它不做預期的事情。

否則，這太容易忽視了。保持簡單 - 它可以工作，或者不需要。失敗或成功:)

- Kevin Fairchild

Answer 4

失敗的測試是一種光柵。破碎的代碼和未完成的代碼之間有區別，測試是否應立即解決取決於這種失敗測試揭露的情況。

如果它壞了，你應該儘快修復它，而不是晚些時候。如果未完成，請在有空時處理。

在這兩種情況下，顯然你可以忍受它表現不好（現在），所以只要問題被記錄下來，你可能不會對它感到厭煩，直到你有時間修復它。

Answer 5

雖然我同意保羅所說的大部分內容，但論證的另一方面是，嚴格來說，迴歸測試應該測試程序行爲的變化，而不是任何舊的錯誤。他們專門告訴你什麼時候你破壞了曾經工作過的東西。

我認爲這可以歸結爲在這個應用程序上運行其他類型的測試。如果你有某種單元測試系統，那麼對於這個測試來說，這可能是一個比較合適的地方，而不是迴歸測試（至少在bug修復之前）。但是，如果迴歸測試是您唯一的測試，那麼我可能會離開測試。

Answer 6

我們在單元測試中添加了「打盹」功能。這使得測試可以用基本上說'忽略從這個日期起的X周失敗'的屬性來註釋。開發人員可以註釋一個他們知道一段時間內不會修復的測試，但是在將來不需要任何干預來手動重新啓用它，測試會在指定時間回彈到測試套件中。

Answer 7

儘管最好在有錯誤時測試失敗，但這通常是不切實際的選擇。當首次將測試添加到某個區域時，特別容易陷入發現的錯誤，因此不能完成主要目標。而且，長時間失敗的測試變得非常噪音，更容易忽略。

編寫失敗的測試是修復錯誤的一部分，並且在修復這些錯誤時非常重要。這應該由您當前的產品和質量優先事項決定。如果您碰巧將測試作爲其他努力的副作用，那很好，但不應該被允許將您從實際的優先級中分散開來。

我會建議在發現任何bug的同時將測試改進爲警告並向他們提交錯誤。這是一種廣度優先的方法，可以幫助您完成當前的任務，同時還可以實際使用您學習的內容。當錯誤被安排修復時，測試可以很容易地變成真正的失敗。

與其他受訪者不同，我認爲失敗與警告一樣容易被忽視，而培訓團隊忽略失敗的成本太高而無法實現。如果您在此項工作中產生失敗的測試，那麼當任務正在改進時，您將摧毀迴歸測試套件的實用程序。