我們都可以涉及的藉口清單

　　程式設計師和測試-絕對不是天堂。 儘管大多數程式設計師都瞭解測試的重要性及其用途，但有時我們只是不喜歡它。

　　為了避免發生一件事，有很多借口一直被利用：編寫測試。

　　您是否曾經使用此列表中的任何藉口？

　　9."這段程式碼太小了……它什麼都不會破壞"

　　每個開發人員都編寫了很小的程式碼，以至於無法破壞任何重大的東西。 但是，它仍然設法破壞了某些東西。 您新增的兩行程式碼成功打破了您無法預料的內容。

　　您怎麼知道您的程式碼完美地工作？

　　請讓您的話語得到一些實際測試的支援。 全面的測試可以過濾出關鍵的錯誤，確保程式碼按預期的方式工作。

　　8."客戶只想為可交付成果付費"

　　每個客戶都希望看到儘可能多的可交付成果，因為這使他們感到開發團隊正在做一些實際工作。 他們希望儘可能地降低成本。

　　這正是開發人員在不希望進行測試時告訴其經理的內容。

　　測試是軟體開發的重要組成部分，而這部分程式碼與任何其他程式碼一樣重要—因此，您應該將其視為這樣。 在編寫的估算中包括編寫測試的時間。

　　從長遠來看，編寫測試可降低維護成本並降低開發成本。

　　7."如果手動進行測試，可以更快地進行測試"

　　手動測試的問題是您必須一遍又一遍地進行測試。 然後再次。

　　是的，一次手動執行某個功能可能會更快。 但是，當您必須一遍又一遍地進行手動測試時，這非常耗時。 手動測試是無止境的，而且非常昂貴。

　　編寫測試會花費一些時間，但是一旦獲得測試，就可以無限次地執行它，並且與手動測試相比，它只花費很少的時間。 與開啟瀏覽器並輸入頁面地址相比，執行自動化測試所需的時間更少。

　　6."這段程式碼不變"

　　"測試程式碼沒有任何變化是沒有意義的。 那完全是浪費時間。"

　　好吧，我們在軟體開發中唯一可以確定的就是需求將會改變。 有時它們似乎在不斷變化。

　　人們出於多種原因改變主意，並且定期這樣做。 需求變化可能是由許多原因引起的。 有些人要求功能，但是他們實際上並不知道他們想要什麼。 不幸的是，這種情況經常發生。 需求可能發生變化的另一個原因是由於組織內部的政治因素。

　　每當您處理不斷變化的需求時，都應該優先測試最常見的流程。

　　5."需求不好"

　　不好的要需求不是跳過編寫測試的藉口。 您有很多選擇可以找出要求。 有時情況會變得更糟。 令人遺憾的是，未記錄的要求是我們大多數人面臨的比預期更多的現實。

　　在這兩種情況下，您都需要處理任何少量的文件。 嘗試瀏覽舊的電子郵件或您做過的一些筆記，以尋找一些線索。

　　您還想了解一下該應用程式的當前版本或較舊版本-當然可以。 您可能會在這裡找到很多隱藏的線索。 別忘了看一下測試。 它們可能充滿了可以幫助您的隱藏寶石。

　　最後但並非最不重要的一點是，嘗試與一些團隊成員交談。 他們可能對您要查詢的未記錄的要求瞭解更多。 想一想在您無法參加的會議中討論但未記錄的一件事。

　　4."測試增加了開發時間，而我們用光了時間"

　　當涉及到測試時，這是最大的誤解之一。 每當您第一次開始編寫測試時，都肯定會增加開發時間。 首先，您需要學習如何編寫可測試的程式碼以及如何進行適當的測試。 從長遠來看，這是一項投資。

　　一旦測試成為一種習慣，它將為您節省大量時間。 和頭痛。 進行測試將為您解決開發人員缺乏部署程式碼的信心的問題-儘管事實上您能夠輕鬆地單擊按鈕來執行整個測試套件。

　　3."我不知道要測試什麼"

　　您對要測試的內容有疑問嗎？ 全部測試！

　　一個好的開始就是測試所有可能的最常見的情況。 這將告訴您何時該部分程式碼中斷，影響最大。

　　但是，除了點選"幸福道路"場景之外，還需要進行更多測試。 您應該測試最複雜的部分程式碼或最有可能出錯的程式碼片段的極端情況。

　　每當發現錯誤時，編寫覆蓋該測試用例的新測試都被視為一種很好的做法。

　　將編寫測試作為日常工作的一部分-不要使其成為可選專案。

　　2."這段程式碼不可測試"

　　您的意思是您真的不知道如何測試該段程式碼。 可能是因為您的程式碼結構不好，因此無法測試。 如果只是一小段程式碼，請將其重構為可測試的小段。

　　當您處理的程式碼設計不佳且程式碼次優時，確實無法測試時，您會遇到一些更大的問題。 無法測試的程式碼維護和修改成本很高。 最重要的是，新團隊成員很難學習無法測試的程式碼。

　　如果您不測試程式碼，則最終會遇到開發人員缺乏部署程式碼信心的問題。 缺乏測試使他們感到焦慮，因為他們沒有確認自己所做的更改不會破壞任何東西。

　　1."我的程式碼可以正常工作-為什麼還要費心測試它？"

　　這種宣告通常由自大的開發人員做出。 充其量，認為一個人可以編寫完美的程式碼是幼稚的。 即使是最優秀的程式設計師也會犯錯。 他們一直都在製造它們。

　　沒有人是完美的-錯誤發生的頻率比應該發生的頻率高，這是完全可以的，因為我們可以從這些錯誤中吸取教訓。

　　對您的程式碼充滿信心是可以的。 但是，即使其他開發人員稽核了您的程式碼並批准了該程式碼，您也不應該…… 即使您已經手動測試了一些用例。 所有這些事情仍然存在危險。

　　所有這些都取決於人為因素。 這正是您不想要的，因為人為因素有時會失敗。 發生這種情況時，您需要進行適當的測試。

　　"除了我，沒有人真正在第一時間建立完美的程式碼。 但是我只有一個。"

　　萊納斯·託瓦爾茲

　　總結

　　您能談談這份清單上的任何藉口嗎？

　　我想我們以前都使用過其中一種。 下次，我們可能應該考慮編寫測試，因為我們都知道不測試我們的程式碼會在以後的某個時刻再次引起我們的注意。

　　謝謝閱讀！