當我在我們的程序中找到某種方式來破壞某些功能時，我正在爲客戶做些事情。在你的程序中發現一些你不知道的事情的提示？
（代碼是真的遺留代碼，它已經開發了大約10年，我只在這裏工作了大約一年。）
它並不會導致錯誤或原因該程序崩潰，但如果用戶正在使用該程序並重復該行爲，我很確定他們會阻止他們的「WTF？」旗。
在我們的程序中，我們命名了可以與文本框鏈接的字段（文本框）和靜態文本（標籤）。當文本框未被填充時，與其鏈接的標籤消失。
當我改變已經有一個標籤或多個鏈接到它的文本框的名稱並保存文件時，我沒有重新關聯與文本框關聯的一個或多個標籤，當文本框爲空時，會出現以前關聯的標籤。
現在我的想法是，一個簡單的觀察者模式本來可以解決這個問題，但是之後我沒有編寫代碼。
我在想，如果我可以在店裏挖掘出更多像這樣的情況，也許我可以讓他們考慮單元測試，解耦，應用模式等等。
因此，對於這個原因，如果任何人在任何類型的應用程序的發現打破（但不是錯誤產生）功能的任何提示我想知道（基於Web，桌面等）
斷言（） 也可以使用覆蓋率分析進行單元測試。
測試，測試，測試。
做出意想不到的事情。開始做一項任務並切換另一項任務，看看是否有任何事情發生。當你不應該的時候使用後退按鈕。在兩個窗口中打開它。讓它超時。
在所有瀏覽器中測試，尤其是IE。
對於一個應用程序失敗的可用性，它必須有一組預定的行爲。
「當按下回車鍵時，這個文本框是否被SUPPOSED什麼也不做？」也許是的，也許不是。我看過一些應用程序，其中測試人員/評論人員報告ASSUME應以另一種方式工作，但實際上客戶明確要求他們不希望在返回鍵按下時提交表單，而只是點擊提交按鈕。
因此，基本上你必須定義適當的行爲，然後才能確定不正確的行爲。
絕對正確，你不能沒有規格測試。 +1 – whiskeysierra 2009-12-18 22:44:59
如果它有一個界面，那麼我最喜歡的一個非常規測試就是將5-10歲的孩子放在它的前面。你會驚訝他們能想出什麼（特別是年輕人）。雖然這可能聽起來像一個笑話，但事實並非如此 - 它確實有效，因爲孩子們不具備只通過「心態」路徑的心態。
是的，孩子們是「打破事情」xP的專家。
代碼檢查，即閱讀源代碼：如果你花時間閱讀/檢查源代碼，尋找「氣味」，甚至只是尋找你不能立即理解和同意的代碼，那麼你可能會阻止你的「WTF？」旗也是。
你可以找到數據庫連接/會話不會被公佈：
我曾經在一家公司工作，程序員經常忘記取消分配數據庫連接。標準答案是儘可能減少資源以查看是否存在泄漏 - 並嘗試通過重新啓動系統並重復運行不同場景來確定它的位置。
這是特別Visual Studio IDE中，儘管它可能也適用於其他人：在調試器的一些點運行與「時拋出一個異常中斷」
在測試過程中，始終處於打開狀態。
這通常可以幫助暴露錯誤地被錯誤地捕獲並且表示錯誤的異常，但否則可能不明顯。
代碼評論應該總是包含對單元測試代碼的評論。
問題是，通過即席測試，不可能知道開發人員測試代碼的程度。所以，你受到不同開發者對「完成」這個詞的定義的支配。
如果您在查看生產代碼的同時包含單元測試代碼的評論，則應該清楚代碼是否完整;其中「完整」包括「測試」。不只是「嘿，我會把它扔到牆上給測試人員！」「。
代碼審查的第一個小時，與第一個審查員，將發揮最大的質量問題。但事情就是這樣：你不需要說服質量問題的人。你需要說服他們修復錯誤的價值，並且只有當現在的質量完全合理時才能重寫。
我在這段時間裏處理了一些嚴重錯誤的代碼。但是你不能只重寫。在你甚至可以判斷改寫是否改進之前，你需要一個規範。
有時候，你必須從代碼中推斷規範，然後在某個地方對某個人進行檢查。但是當你做完這些之後，你就會明白編寫的代碼，並且現在可以更好地進行修復，而不是重寫 - 大部分時間。
修復是通過一個小的行爲保留修改過程來實現的，這些修改使代碼中的規範更清晰。然後，當你發現看起來不對的東西時，你不要只是改變它。你問問周圍，直到找到決策負責人，然後讓他們告訴你在規範中說行爲X是正確的。 （這種對話可以有多種形式。）如果你幸運的話，他們會告訴你X的行爲其實是不正確的，然後你已經獲得了工資。
將其交給用戶。那些混蛋會發現每一件出錯的小東西，並且像任何人的事情一樣wh about。 – 2010-08-15 15:18:39