<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怎么處理?

          • 發布:軟件測試培訓
          • 來源:軟件測試資源共享
          • 時間:2018-11-05 17:19

          大家好,今天達內軟件測試培訓分享給大家的是處理詭異bug的十八條經驗,詭異的bug,相信大家都有所耳聞,就是有bug,但又分析不出來是什么原因造成的bug,你平常都是怎么解決的呢?有什么好的分析思路嗎?今天我們來提供一些好的思路與見解,希望對你有所幫助!

          <a style='color:blue' href='http://www.9393pk.com/'>軟件測試</a>工程師,面對詭異bug怎么處理

          一編碼

          01、事件順序

          當處理事件時,問以下問題富有成效:事件是否可以以不同的順序到達?如果沒收到這些事件怎么辦?如果事件在同一行出現兩次怎么辦?即使這通常不會發生,在系統的其他部分(或交互系統)中的bug也會導致它發生。

          02、處理太早

          這是上述“事件順序”中的一個特殊情況,但是它已導致了一些棘手的bug,所以它自成一派。例如,如果信令信息接收得過早,在配置和啟動程序完成之前接收,許多奇怪的行為就會發生。另一個例子,當一個連接在被放入空閑列表之前就被標記為斷開。當我們處理這個問題時,我們通常假設它處在空閑列表狀態時被標記為斷開(但是當時它為什么沒有從這個列表上撤下?) 沒考慮到事情有時發生過早是由于我們沒有想到。

          03、隱蔽故障

          例如,一些最難找的的 bug 是由于出現了隱蔽故障而繼續執行而不是給出錯誤的代碼導致的。例如,系統調用(如綁定)返回未檢查的錯誤代碼。另一個例子:當遇到一個錯誤元素時,直接返回而不是給出錯誤的解析代碼。調用在故障的狀態下持續了一段時間,使得調試的難度加大。一旦故障被檢測出,最好要及時返回這個錯誤。

          04、If語句

          含有多個條件的If語句(if (a or b),尤其是當嵌套時,if (x) else if (y)),給我導致了許多 bug。即使If語句在概念上很簡單,當它有多個條件需要追蹤時,很容易出錯。最近我嘗試重新把代碼寫得簡潔,避免出現復雜的If語句。

          05、Else

          有一些bug的產生是由于沒有恰當地考慮如果條件為假,什么應該發生。在幾乎所有的情況下,每個If語句都應該有個else部分。而且,如果你在If語句的一個分支中設置了一個變量,你也許應該在其他分支也設置該變量。與此相關的是標志(flag)被設定的情況。僅僅添加設定標志的條件很容易,但是容易忘了添加應該重新設定標志的條件。任由永久性設定的標志留在那里可能會在將來導致 bug。

          06、改變假設

          一開始最難預防的許多bug是由不斷變化的假設引起的。例如,最初僅僅只有一個客戶,在這個假設下寫了很多代碼。后來某個時候,設計發生了變化,允許每天有多個客戶事件。當這種情況發生,就很難改變受到新設計影響的所有情況。很容易找到顯式依賴該變化的所有項,但是難的部分是,找到隱式依賴舊設計的所有情況。例如,可能有代碼讀取給定某一天的所有客戶事件。一個隱式的假設可能是,結果集中元素的數量絕對不會大于客戶數量。我沒有好的方法可以預防這類問題,歡迎讀者建議。

          07、日志記錄

          深入了解程序所做的任務是至關重要的,尤其是當邏輯復雜的時候。確保添加足夠的(但也別太多)日志記錄。那樣你就能弄清楚為什么程序在執行它執行的任務。讓一切運轉良好時,它無關緊要。但是只要問題發生(這不可避免),你會很慶幸你添加了合適的日志記錄。

          二測試

          作為一名開發者,除非進行了測試,否則我不會說完成一項功能。起碼這意味著每一行新代碼或更改后的代碼至少執行了一次。此外,單元測試或功能測試也很好,但不夠。新功能還必須在類似產品的環境下進行測試和探究。唯有這樣,我才可以說完成了一項功能。下面是 bug 在測試方面給予我的一些重要的經驗教訓:

          08、零(zero)和空(null)

          務必要以零和空(合適的情況下)來進行測試。對于字符串而言,這意味著既指長度為零的字符串,又指內容為空的字符串。另一個例子:在發送任何數據(零字節)之前,測試 TCP 連接的斷開。沒有使用這些組合來測試是 bug 悄然出現的頭號原因,我在測試時是原本可以發現這些 bug 的。

          09、添加和刪除

          新功能常常需要能夠為系統添加新配置,比如說用于電話號碼翻譯的新配置文件。我們會自然而然的添加一個配置文件,來驗證功能是否正常。然而,我發現很容易忘了還要測試配置文件的刪除。

          10、錯誤處理

          處理錯誤的代碼常常很難測試。最好由自動測試來檢查錯誤處理代碼,但有時這不可能。這種情況下,我有時采用的一招就是,臨時修改代碼,讓錯誤處理代碼運行。要做到這一點,最容易的方法就是反轉if語句,比如說將if語句由 error_count > 0反轉為 error_count == 0。另一個例子是誤拼數據庫列名,讓所需的錯誤處理代碼運行。

          11、隨機輸入

          另一種往往能夠發現 bug 的測試方法是進行隨機輸入。例如,H.323 協議的 ASN.1 解碼可處理二進制數據。通過發送有待解碼的隨機性字節,我們發現了解碼器中的幾個 bug。另一個例子是使用測試調用生成腳本,其中調用持續時間、回復延遲、第一方掛斷等都是隨機生成的內容。這些測試腳本暴露了無數 bug,尤其是接踵而至的事件引起的干擾。

          12、檢查什么不該發生

          通常測試包括檢查一些需要的行為發生。但是很容易忽略他的對立面——檢查不該發生的事確實沒發生。

          13、自制工具

          通常,我創建了自己的小工具來使測試更簡易。例如,當我處理面向 VoIP 的 SIP 協議時,我寫了一個小的腳本可以返回正標題和值。這個工具使得測試許多個別場景變得簡單。另一個例子是可以調用 API 的命令行工具。從小的開始,逐漸添加一些需要的功能,我最終有許多有用的工具,寫自己的小工具的優勢是我得到我想要的功能。

          三調試

          14、討論

          在過去對我幫助最大的調試方法就是與同事討論問題。我常常只要向同事描述問題,就足以認識到問題是什么。此外,即使同事不是很熟悉相應代碼,常常也能?出好主意,表明哪里可能有問題

          15、密切注意

          往往是當調試一個問題很長時間時,是因為我做了錯誤的假設。例如,我認為這個問題發生在一個特定的方法中,事實上,這個問題甚至根本不會出現在這個方法中。或者拋出的異常并不是我認為的那個。或者我認為最新版的軟件在運行,但它其實是較老的版本。

          16、最近的一次改動

          本該運行的程序停止了,它通常是由最后的一次變動導致。有一次,最近的一次變動僅僅是日志,但是日志中的一個錯誤導致了更大的問題。

          17、相信用戶

          有時當一個用戶反饋問題時,我的本能反應是:這不可能,他們一定搞錯了。但是我已經意識到我不應該這樣做。我也不想這樣,但更多次,事實證明他們報告的問題實際上發生了。

          18、測試修復的效果

          如果你已經修復了 bug,還需要再測試。首先運行修復前的代碼,然后觀察 bug。然后運用修復再次測試。現在 bug 的問題應該被消除了。繼續這些步驟確保它確實是一個 bug,確保你的修復已經修復這個問題。簡單但很必要。

          感謝您的閱讀,以上就是對詭異bug處理的十八條建議,你都學會了嗎?更多軟件測試相關的問題,歡迎您來達內網絡營銷培訓機構進行咨詢。

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

          預約申請免費試聽課

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

          上一篇:如何填寫軟件缺陷報告,才能讓我早點下班?
          下一篇:軟件測試如何驅動開發?軟件測試驅動開發的關鍵因素是什么?

          軟件測試必備的數據庫知識有哪些?(終)

          日志在快速定位自動化腳本故障中的重要性研究

          測試慣例是什么?怎么打破測試慣例?

          “用鼠標點點點”的測試,未來還有機會嗎?

          • 掃碼領取資料

            回復關鍵字:視頻資料

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

          • 視頻學習QQ群

            添加QQ群:1143617948

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

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

          選擇城市和中心
          黑龍江省

          吉林省

          河北省

          陜西省

          湖南省

          貴州省

          云南省

          廣西省

          海南省

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