<pre id="ff7yo"></pre>

      <form id="ff7yo"><legend id="ff7yo"></legend></form>
        <nav id="ff7yo"><listing id="ff7yo"></listing></nav><nav id="ff7yo"></nav>

        <nav id="ff7yo"><listing id="ff7yo"></listing></nav>
        <small id="ff7yo"></small><nav id="ff7yo"><dd id="ff7yo"></dd></nav>
      1. <nav id="ff7yo"></nav>
          <form id="ff7yo"></form><nav id="ff7yo"></nav>
          <nav id="ff7yo"></nav>
          <sub id="ff7yo"></sub>
          更多課程 選擇中心

          軟件測試培訓
          達內IT學院

          400-111-8989

          軟件測試工程師都想知道:如何更快地修復Bug?

          • 發布:軟件測試培訓
          • 來源:掘金
          • 時間:2019-03-04 17:27

          作為一名軟件測試工程師,就跟一名醫生一樣,我想我失業,如果軟件測試工程師失業了,那么就證明軟件開發的正確率、與用戶需求的匹配程度已經很高了,這對社會資源是極大的節約不是嗎?如果醫生失業了,那么人們就不會再生命了,就再也沒有痛苦了不是嗎?但是,這又怎么可能?!我們能做的就是減少、降低,再減少再降低,所以就有了軟件測試工程師想要知道的問題:如何更快地修復Bug?

          軟件測試工程師都想知道:如何更快地修復Bug?

          你有沒有想過為什么有時修復錯誤似乎比它應該花費更長的時間?當你終于找到問題時,事實證明你所需要的只是一個小小的改變。然而,花了很多時間才能找到正在發生的事情。這種情況比我想象的更頻繁。

          另一方面,當您編寫代碼并進行測試并且無法正常工作時,修復錯誤非常快。你跳回編輯器,掀起一行代碼,問題就解決了。

          為什么即使問題很簡單,有時修復錯誤也需要很多工作,有時候,修復問題的速度很快 - 甚至可能很難解決問題?我們可以從易于修復的錯誤中學到一些東西,這樣我們可以花更少的時間來修復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變慢的最大因素。

          我們可以做些什么來改善這種情況?

          讓我們首先看一下我們可以做些什么來從用戶那里獲取更多信息并進入錯誤報告。邁出這一步的第一步是向用戶詢問一些具體問題。這有助于指導用戶為我們提供更有效地解決問題所需的信息。

          以下是您可以使用的一些問題。我不記得我第一次看到這些,但我傾向于自己使用這種格式并且效果很好。

          1.問題的簡短描述

          2.發生了什么?

          3.應該發生什么呢?

          4.如何重現這個問題?

          第一個并不是絕對必要的,但是如果您使用像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之前,我們需要做的所有工作。其中大部分是由于缺乏信息 - 錯誤的錯誤報告,大量的代碼,甚至糟糕的代碼都可能導致錯誤。

          我們可以通過嘗試在錯誤報告中獲取更多信息來改善這種情況,但更快地修復錯誤的最佳方法是更早地發現錯誤。

          在開發過程中遇到的錯誤是最快修復的,因為我們正在積極處理有問題的代碼,并且我們在頭腦中擁有所需的信息。這意味著我們不需要開始挖掘錯誤報告或代碼來弄清楚發生了什么。

          在測試期間捕獲更多問題的最佳方法是單元測試。他們解決了所有三個問題:

          1.我們沒有足夠的信息。解決了?- 失敗的測試告訴我們出了什么問題以及應該發生什么,指出我們確切的功能。測試本身就是bug的再現。

          2.除非我們對整個代碼庫非常熟悉,否則我們需要做一些工作來找到問題的根源。已解決?- 失敗的測試告訴我們哪個功能失敗,因此不會涉及任何猜測。更好的是,測試通常在開發過程中失敗,因此所有代碼在我們的記憶中仍然是新鮮的。

          3.由于時間限制,有時會跳過查找根本原因,導致代碼錯誤。解決?- 測試將失敗的根本原因,而不是癥狀,給我們確切的位置,我們需要解決。

          您也不需要花費大量精力進行測試。您可以逐個開始添加測試,例如修復錯誤時。隨著您添加的每項測試,您將獲得越來越多的好處。

          測試的主要問題是它可能很難入門。然而,一旦你學會了這些概念,它們就不會過時了 - 不像當下流行的圖書館,測試已經存在了很長時間,無論你使用什么庫或語言,都可以使用完全相同的原理。

          單元測試還有更多的好處,而不僅僅是更快地修復bug。

          感謝您的閱讀,相信通過今天的文章你已經了解了如何更快地修復Bug的方法,你在實際的工作中,還有別的好主意好方法嗎?快來達內軟件測試培訓機構跟我們分享吧!

          免責聲明:內容和圖片源自網絡,版權歸原作者所有,如有侵犯您的原創版權請告知,我們將盡快刪除相關內容。

          預約申請免費試聽課

          填寫下面表單即可預約申請免費試聽!怕錢不夠?可就業掙錢后再付學費! 怕學不會?助教全程陪讀,隨時解惑!擔心就業?一地學習,可全國推薦就業!

          上一篇:APP測試有哪些知識點?APP測試都測什么?
          下一篇:我們常用的軟件測試工具有哪些?不必抓瞎,給你準備好了!

          測試的工資永遠趕不上開發,是真的嗎?

          我們常用的軟件測試工具有哪些?不必抓瞎,給你準備好了!

          軟件測試工程師都想知道:如何更快地修復Bug?

          APP測試有哪些知識點?APP測試都測什么?

          • 掃碼領取資料

            回復關鍵字:視頻資料

            免費領取 達內課程視頻學習資料

          • 視頻學習QQ群

            添加QQ群:1143617948

            免費領取達內課程視頻學習資料

          Copyright ? 2021 Tedu.cn All Rights Reserved 京ICP備08000853號-56 京公網安備 11010802029508號 達內時代科技集團有限公司 版權所有

          選擇城市和中心
          黑龍江省

          吉林省

          河北省

          陜西省

          湖南省

          貴州省

          云南省

          廣西省

          海南省

          神马影院-战旗影院-首播影院-新视觉影院-在线观看中文字幕dvd播放 百度 好搜 搜狗
          <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <文本链> <文本链> <文本链> <文本链> <文本链> <文本链>