你有沒有想過爲什麼有時修復錯誤似乎比它應該花費更長的時間？當你終於找到問題時，事實證明你所需要的只是一個小小的改變。然而，花了很多時間才能找到正在發生的事情。這種情況比我想象的更頻繁。
另一方面，當您編寫代碼並進行測試並且無法正常工作時，修復錯誤非常快。你跳回編輯器，掀起一行代碼，問題就解決了。
爲什麼即使問題很簡單，有時修復錯誤也需要很多工作，有時候，修復問題的速度很快 - 甚至可能很難解決問題？我們可以從易於修復的錯誤中學到一些東西，這樣我們可以花更少的時間來修復bug嗎？
讓我們來談談這個問題，看看我們可以用什麼方法來解決這個問題，並且因爲很難找到錯誤而停止拔頭髮。
典型的錯誤修復過程
爲了確定在修復錯誤時花了這麼長時間，我們先來看看修復錯誤所涉及的步驟。
首先，我們需要了解這個問題。這意味着我們需要知道出了什麼問題，在哪裏，以及應該發生什麼。
接下來，我們需要重現這個bug。一個典型的案例可能是我們需要進入我們正在處理的應用程序並點擊一些事情來看看會發生什麼。
然後，我們需要弄清楚代碼的哪個部分導致了問題。我們通常可以通過使用調試工具來啓動它 - 例如使用Chrome的調試器在我們重現問題的頁面上逐步執行代碼。
一旦我們找到導致問題的代碼片段，我們就需要確定根本原因。根據問題的複雜性，這種困難可能會有很大的不同。
在確定了根本原因後，我們終於可以修復該錯誤了。
最後，我們需要確保錯誤實際修復。這通常是通過嘗試再次重現它來完成的。
嗯，我想我們已經開始在這裏看到一個問題了。修復bug本身只有六分之一！
但在我們得出結論之前，讓我們更詳細地看一下這些步驟。然後，我們可以看到每個步驟中的內容需要花費時間，並找到使它們更快的方法。
第1步：瞭解問題
錯誤修復過程的第一步是理解問題。我們需要收集足夠的信息，以便我們知道發生了什麼，以及應該發生什麼。
這個步驟花費很長時間的最大貢獻者是可怕的，糟糕的錯誤報告。
用戶從不提供好的錯誤報告。這是生活中無可否認的事實。
我可能會誇大一點，但我確信你已經比你想要的更頻繁地聽到“它不起作用”的字樣。
“X不起作用，它需要在昨天修復！”
然後你繼續問一些問題，希望你能從記者那裏收集一些比“它不起作用”更有用的信息。
當然，有時當行星和恆星正確對齊時，你會得到一個好的錯誤報告。您可以清楚地瞭解出現了什麼問題，重現它的精確步驟，甚至可以獲得有關用戶使用的瀏覽器和操作系統的信息！那時候你可以直接進入第2步並開始修復bug。
但在最糟糕的情況下，你只會對發生的事情有一個模糊的概念，這意味着在第2步中需要付出更多的努力。
第2步：重現錯誤
如果您在步驟1中獲得了良好的錯誤報告，則此部分可以很容易。您可以按照錯誤報告中的步驟操作，然後立即重現錯誤。太棒了！現在，您可以繼續查找損壞的代碼。
可悲的是，這一步往往不是那麼順利。
由於模糊的錯誤報告，這一步往往涉及很多猜測。
也許用戶使用的是Firefox，或者他們使用的是Chrome。在點擊此按鈕之前，他們不確定他們做了什麼。我想知道我是否應該隨意按下按鈕並希望最好？
有時，在嘗試重現問題後，您必須反覆執行步驟1和步驟2，而不會產生任何結果。希望您可以從用戶那裏獲得更多信息，然後再試一次。
在這一點上很清楚，爲了加快步驟1和2，我們需要收集儘可能多的信息。我們掌握的信息越多，理解和重現問題就越容易。
第3步：找到有問題的代碼片段
一旦我們再現了這個bug，我們就需要找到導致問題的代碼的特定部分。
此步驟的難度各不相同，主要取決於兩個因素：
您擁有的代碼量
您熟悉代碼庫
（在較小程度上，您對調試工具的瞭解）
代碼量會影響這一點，因爲每行代碼都會增加可能的錯誤數量。值得慶幸的是，熟悉代碼庫可以顯着縮小範圍。
找到問題通常從採取有根據的猜測開始。
“好吧，這就是問題，這就是我可以重現它的方式，所以我認爲問題出現在代碼的Y部分”
您對代碼庫的熟悉程度越高，您的猜測就越好。這使您可以縮小需要查看的代碼量，可能需要大量調整。
“好吧，我最近在處理函數Z，它有與此相關的代碼。我最好先檢查一下。“
根據問題的類型，您還可以使用調試工具來幫助您更輕鬆地找到有問題的代碼。
“是的，當我點擊它時會出現錯誤。我將在事件處理程序中設置一個斷點並從那裏開始。“
在此過程的這一步，最大的時間匯是找到問題發生的確切位置。它可能是行爲不當的功能，用戶的不良价值或任何數量的東西，您需要在繼續之前找到問題的根源。
第4步：確定根本原因
這可能是這個過程中最重要的一步，但它經常被完全跳過！
由於感知時間限制，或者僅僅因爲經驗不足的開發人員可能不知道他們應該這樣做，它可能會被跳過。無論哪種方式，跳過此步驟通常意味着您的代碼慢慢開始填充hacks和kludges。
注意，我說感覺時間限制。通常你可能會感到有壓力要快速修復。
“只需快速修復，客戶就在等待。你以後可以做好工作。“
因此，您可以使用一些代碼來修復損壞的代碼並跳過根本原因。當然，你很可能永遠無法妥善修復它，因爲總有一些東西需要完成。
但快速修復快速修復的結果與使用膠帶修復漏水管道相同。即使在芬蘭，我們稱膠帶爲“耶穌膠帶”，因爲它具有修復任何東西的神奇能力，在某些時候膠帶修復開始泄漏，你需要再使用一些膠帶。不久之後，你手上就會有一個巨大的混亂，你必須把它全部撕下來。
最後，您需要花費更多時間來修復快速修復，而不是花費更多時間來完成正確的工作。
但我離題了。
確定根本原因意味着您需要找到錯誤的真正來源。讓我給你舉個例子。
假設您網站上的某些價值顯示不正確。您可以通過更改顯示代碼來解決此問題，但更多時候，顯示症狀的代碼不是根本原因。
如果您更深入地研究問題，您可能會發現數據庫中的數據也是錯誤的。進一步深入研究，您會發現保存該值的代碼已被破壞。這是問題的根本原因。您找到的原始代碼只是在其他地方顯示問題的症狀。
如果您只是修復了症狀，那麼真正的問題就會存在。它將繼續在將來引起問題，同時你不斷修復更多的症狀。
與查找症狀不同，此步驟不需要太多猜測。你有一個起點，從那裏你可以追溯到根本原因，所以你不需要猜測。
儘管如此，這一步可能非常耗時，因爲您經常需要在幾個級別上深入研究代碼。多長時間在很大程度上取決於根本原因與症狀相比的位置 - 有時它們甚至可能是相同的，但如示例所示，它可能會降低幾個等級。
第5步：修復錯誤
最後我們可以解決這個問題。我們已經複製了這個錯誤，找到了症狀發生的地方並找到了根本原因。
在完成所有工作之後，這一步通常是相當微不足道的。我們有關於出了什麼問題，應該發生什麼以及出現什麼症狀的信息。錯誤通常不需要大的修改來修復，因此實現部分往往很快。
第6步：確保錯誤得到修復
作爲這個過程的最後一步，我們需要確保錯誤被徹底掩蓋。
這可以通過重複您之前重現問題的步驟來完成。
偶爾這個bug仍然會重現。在這種情況下，您通常需要返回步驟4或5並從那裏繼續。
如果對軟件測試、接口測試、自動化測試、性能測試、LR腳本開發、面試經驗交流。感興趣可以175317069，羣內會有不定期的發放免費的資料鏈接，這些資料都是從各個技術網站蒐集、整理出來的，如果你有好的學習資料可以私聊發我，我會註明出處之後分享給大家。
這個過程有什麼問題？
現在我們已經查看了錯誤修復過程中的每個步驟，我們可以確定這些關鍵難點：
缺乏有關該問題的信息：錯誤報告通常缺少重要信息，這使得很難理解問題並重現問題。我們擁有的信息越少，花費的時間就越多。
猜測：我們經常需要進行一些猜測。我們沒有解決問題所需的所有信息，也沒有辦法在代碼中查明問題。因此我們需要猜測，這本質上是容易出錯的
時間限制的壓力：我們經常需要快速修復錯誤，因爲用戶和客戶以及業務依賴於軟件的工作。反過來，這可能會使得不能正確分析問題，這會導致更多的錯誤和問題。
所有這些都有助於減緩錯誤修復並使其成爲一個繁瑣的過程。我們編寫代碼來修復bug的部分很少是最大的時間下沉！
但是，儘管如此，有時我們可以非常快速地修復錯誤。這通常發生在我們添加新功能和處理全新代碼時。
爲什麼是這樣？
如果我們在考慮使用全新代碼時的典型情況，我們通常會非常熟悉我們剛纔寫的內容。在這種情況下發現錯誤的人通常與編寫代碼的人相同。
這幾乎完全消除了猜測！
我們知道我們剛寫的代碼
我們經常以小的漸進步驟測試我們的代碼，因此可能導致錯誤的代碼更少
因此，修復錯誤是一件輕而易舉的事。通常情況下，您只需將alt-tab返回到編輯器，立即發現問題並進行更快的修復，而不是說“它不起作用”。
收集更好的信息
我們可以有把握地說，缺乏信息和由此產生的猜測是導致修復bug變慢的最大因素。
我們可以做些什麼來改善這種情況？
讓我們首先看一下我們可以做些什麼來從用戶那裏獲取更多信息並進入錯誤報告。邁出這一步的第一步是向用戶詢問一些具體問題。這有助於指導用戶爲我們提供更有效地解決問題所需的信息。
以下是您可以使用的一些問題。我不記得我第一次看到這些，但我傾向於自己使用這種格式並且效果很好。
問題的簡短描述
發生了什麼？
應該發生什麼呢？
如何重現這個問題？
第一個並不是絕對必要的，但是如果您使用像JIRA這樣的工具，因爲您需要該問題的名稱，這將非常有用。第二個是相當明顯的，第三個對於理解用戶期望發生的事情非常有用。雖然你可以自己解決這個問題，但最好事先了解一下 - 特別是有時它可能不是技術問題，而只是混亂的結果。
第四點可能是最重要的，但用戶並不總是知道如何填補這一點。如果可能的話，最好給他們一個小樣本，如你想要它填充，如“1。我在第X頁2.我點擊按鈕Y 3.我輸入值Z“。
特別是對於Web應用程序有用的其他信息是用戶的瀏覽器和操作系統。根據用戶的不同，他們可能並不總是知道這一點，因此能夠自動收集這些信息可能很有價值。爲此，您可以考慮集成Usersnap等服務，這有助於將更多數據收集到錯誤報告中。
在腳本錯誤的情況下，具有堆棧跟蹤通常也是有用的，儘管具有良好的再現步驟，您也應該能夠自己獲得它。像Loggly這樣的工具可用於自動收集有關錯誤的信息（即使在客戶端JavaScript代碼中），這樣您就可以更好地瞭解發生的情況。
這些步驟是改進流程的良好起點。但是他們並沒有真正解決所有問題。例如，無論您嘗試多少，用戶都可以並且將繼續發送令人困惑的錯誤報告。
我知道。我反覆告訴用戶他們需要包含重現問題的步驟，或者我們不能做任何事情，而且我仍然不斷得到可怕的“它不起作用”的錯誤報告。
“Jani，X破了修復它”
啊。
那麼還有什麼我們可以做到這一點並不依賴於那些挑剔的用戶呢？
記錄運行時信息
記錄經常被忽視作爲一種工具。也許這樣做缺乏好的庫，或缺乏使用日誌輸出的好工具 - 因爲讓我們面對它，誰想通過手工查找特定事件來瀏覽一個巨大的日誌文件？但是正確完成並使用好的工具，日誌可以提供有價值的信息。
大多數開發人員僅將日誌記錄用作臨時措施。很容易將一堆`console.log'打入我們的代碼只是爲了看看發生了什麼 - 我做了很多。
但是當我說伐木時，我不只是談論調試日誌或錯誤日誌。我正在談論一般的登錄 - 關於代碼中發生了什麼，正在發送什麼輸入等的信息。
以更系統的方式登錄需要一些工作。我們需要注意包括登錄我們的代碼，我們需要確保記錄可能有用的信息。那麼這有助於加快bug的修復速度呢？
有時，如果沒有用戶告訴我們，可能會出現問題。自動進程在沒有記錄的情況下基本上是不透明的，你永遠不會知道出了什麼問題。
如果您有良好的日誌，他們可以幫助您更快地找到問題。根據您記錄的內容和方式，他們可以指出問題的一般方向，甚至提供更具體的信息，例如向您顯示哪些值是錯誤的。
特別是在自動化流程的情況下，日誌記錄很重要。除非您有日誌，否則通常無法跟蹤此類進程中發生的情況。日誌應該足夠詳細，以便讓我們對發生的事情有一個合理的瞭解。
使用這樣的日誌有助於通過向我們提供更多有用信息來減少猜測工作量。
儘管我喜歡將Java變得糟糕，但日誌記錄是他們做得很好的一件事。它有許多庫和已建立的日誌實踐。如果您遇到過Java應用程序的問題，您可能會查看日誌甚至增加日誌詳細程度。他們中的許多人輸出了大量的日誌。
記錄有用的是什麼？對於每個應用程序來說，擁有日誌或記錄所有內容並不是絕對必要的，但這裏有一些例子：
記錄個人請求。例如，如果您使用過Apache或Nginx，它們都有一個日誌文件，該文件爲服務器執行的每個請求獲取一行，以及有關它的信息。僅此信息不一定有用，但如果您爲每個請求記錄多條信息，這可能是首先記錄的好信息。
記錄流程或事務中的步驟。我們假設您的用戶可以上傳圖片，但您可以調整圖片大小。您可以記錄流程中的每個步驟，例如“上傳的圖像”，“調整圖像大小”等。
記錄與外部工具/服務的交互。訪問數據庫，API或在我們的圖像大小調整示例中，如果您調用ImageMagick等工具來執行某些操作。
根據您查找日誌的有用程度，實現啓用/禁用某些類型的日誌或基於每個用戶啓用/禁用日誌的方法也是一個好主意。
更快地發現錯誤
到目前爲止我們所看到的所有這些措施都沒有解決我們的關鍵問題。錯誤報告和日誌雖然有用，但只會在事後提供更多信息。
還記得我們如何找到快速修復的錯誤之間的重要區別，以及需要很長時間才能修復的錯誤是我們檢測問題的時間。
每當我們積極處理一段代碼並在開發過程中發現錯誤時，它們的修復速度要快得多。我們對代碼有了全新的記憶，我們已經掌握了所有信息，因此我們不需要進行其他必要的考古。
到目前爲止，這些都沒有任何幫助，即使這是花費多少時間的最大貢獻者之一。
我們怎樣才能更快地發現更多的錯誤，甚至在我們的開發過程中？
顯然，我們可以聘請二十多位QA專家來用顯微鏡進行更改。然而，對於大多數團隊而言，這並不是很實用，即使使用質量保證流程，也可能需要一些時間來發現問題，此時我們已經轉向了其他方面，所以它無濟於事。
在開發過程中可以幫助我們發現錯誤的是測試自動化。
我們可以在開發機器上運行自動化測試
即使在小代碼更改後，單元測試套件也可以快速自動運行
精心設計的測試可爲我們提供有關問題的準確信息
測試自動化是一個更加現實的目標。它不需要大量的前期投資：您可以逐步開始使用它，並且每一步都可以獲得越來越多的好處。
單元測試如何加速bug修復？
每當我們更改代碼時，我們都會冒險引入錯誤。但是，如果我們新添加的代碼存在錯誤，我們通常會輕鬆地發現並修復它們。
新添加或更改的代碼很容易修復，因爲我們已經掌握了它 - 我們只是花時間研究它！這意味着可以輕鬆找到並修復其中的任何問題，因爲我們不需要開始挖掘代碼來找到它。我們仍然可以記住事情的發展方向。
因此，我們可以同意，我們越早發現錯誤，就越容易修復。
但單元測試如何幫助我們做到這一點？
首先，單元測試通常包含以下部分：
正在測試的內容的描述性名稱，例如“它應該驗證用戶的名稱”
用於初始化和運行測試的簡短代碼段
驗證。每個測試都有一個斷言來驗證代碼片段產生了正確的結果。
然後，如果這樣的測試失敗，我們會得到以下信息：
失敗測試的名稱
關於斷言如何失敗的具體信息，經常給我們一個特定的比較，例如“用戶名與預期格式不匹配”
堆棧跟蹤，它爲我們提供了導致失敗的特定代碼行
讓我們將這些與我們想要的錯誤報告進行比較：
名稱
發生了什麼的描述
應該發生什麼的描述
重現問題的步驟列表
你能看到我們從測試中得到的結果嗎？我們從一個好的錯誤報告中獲得了我們想要的信息！不僅如此，測試在開發過程中爲我們提供了這些信息！
當您仍在處理代碼時，單元測試可以爲您提供所需信息的即時反饋，因此您的想法一切都很新鮮。
所有這些都有助於確保我們有足夠的信息來快速修復錯誤。我們知道發生了什麼，應該發生什麼，我們可以通過再次運行測試來重現錯誤...我們甚至可以通過再次運行測試來驗證我們的錯誤修復代碼是否正常工作。
作爲額外的好處，測試也會捕獲代碼中其他地方的更多錯誤。通常由於我們的更改，我們會在其他地方意外地導致錯誤。這些很容易被忽視，最終難以修復，但如果你有單元測試，沒問題 - 一旦你編寫測試，你可以保持它，它不斷捕捉錯誤和有用。
結論
通過修復錯誤，最大的時間接收器不是編寫修復程序。在我們開始編寫任何代碼來修復bug之前，我們需要做的所有工作。其中大部分是由於缺乏信息 - 錯誤的錯誤報告，大量的代碼，甚至糟糕的代碼都可能導致錯誤。
我們可以通過嘗試在錯誤報告中獲取更多信息來改善這種情況，但更快地修復錯誤的最佳方法是更早地發現錯誤。
在開發過程中遇到的錯誤是最快修復的，因爲我們正在積極處理有問題的代碼，並且我們在頭腦中擁有所需的信息。這意味着我們不需要開始挖掘錯誤報告或代碼來弄清楚發生了什麼。
在測試期間捕獲更多問題的最佳方法是單元測試。他們解決了所有三個問題：
我們沒有足夠的信息。解決了 - 失敗的測試告訴我們出了什麼問題以及應該發生什麼，指出我們確切的功能。測試本身就是bug的再現。
除非我們對整個代碼庫非常熟悉，否則我們需要做一些工作來找到問題的根源。已解決 - 失敗的測試告訴我們哪個功能失敗，因此不會涉及任何猜測。更好的是，測試通常在開發過程中失敗，因此所有代碼在我們的記憶中仍然是新鮮的。
由於時間限制，有時會跳過查找根本原因，導致代碼錯誤。解決 - 測試將失敗的根本原因，而不是症狀，給我們確切的位置，我們需要解決。
您也不需要花費大量精力進行測試。您可以逐個開始添加測試，例如修復錯誤時。隨着您添加的每項測試，您將獲得越來越多的好處。
測試的主要問題是它可能很難入門。然而，一旦你學會了這些概念，它們就不會過時了 - 不像當下流行的圖書館，測試已經存在了很長時間，無論你使用什麼庫或語言，都可以使用完全相同的原理。
單元測試還有更多的好處，而不僅僅是更快地修復bug。