RM新时代网站-首页

0
  • 聊天消息
  • 系統(tǒng)消息
  • 評論與回復
登錄后你可以
  • 下載海量資料
  • 學習在線課程
  • 觀看技術視頻
  • 寫文章/發(fā)帖/加入社區(qū)
會員中心
創(chuàng)作中心

完善資料讓更多小伙伴認識你,還能領取20積分哦,立即完善>

3天內不再提示

進行編碼、測試和調試三個階段時如何減少bug

Q4MP_gh_c472c21 ? 來源:cc ? 2019-02-11 16:52 ? 次閱讀

這十年來我做過小的嵌入式系統(tǒng),大的電信系統(tǒng)以及基于web的系統(tǒng)。使用過C ++,Ruby,JavaPython等。這篇文章中的經驗教訓旨在幫助減少編碼、測試和調試三個階段的bug。

會導致難點bug的問題

1.事件順序。

在處理事件時,提出下列問題會很有成效:事件可以以不同的順序到達嗎?如果我們沒有接收到此事件會怎么樣?如果此事件接連發(fā)生兩次會怎么樣?哪怕通常不會發(fā)生,但系統(tǒng)(或交互系統(tǒng))其他部分的bug可能會導致事件發(fā)生呢。

2.過早。

這是第一點“事件順序”的一個特例,但它確實會引起一些棘手的bug,因此我把它單獨拎出來說明。例如,如果信令消息在配置和啟動程序完成之前就被過早接收,那么可能就會有很多奇怪的行為發(fā)生。另一個例子:連接在被放進空閑列表之前就被標記為down。在調試這類問題時,我們總是假定在空閑列表中的時候連接被設置為down(但當時為什么不把它放到列表外面呢?)。這是我們思考的不足,沒有考慮到有時候事情會過早發(fā)生。

3.悄無聲息的故障。

一些最難跟蹤的bug有部分是由那些靜靜失敗并擴展而不是拋出錯誤的代碼所導致的。例如,沒有檢查代碼卻返回錯誤的系統(tǒng)調用(如bind)。又如:解析代碼在它遇到錯誤元素的時候只是返回而非拋出錯誤。在錯誤狀態(tài)中持續(xù)了一段時間的調用,會使調試變得更難。最好一旦檢測到故障就返回錯誤。

4.If。

有若干條件的if語句,if (a 或 b) ,特別是當有鏈接的時候, if (x) else if (y),都給我引發(fā)了很多bug。即使if語句在概念上很簡單,但當有多個條件要跟蹤的時候依然很容易出錯。這些天,我嘗試重寫代碼使之更簡單,以避免處理復雜的if語句。

5.Else。

有一些bug是因為沒有正確考慮到如果條件為false時會發(fā)生什么而引起的。幾乎在所有的情況下,都應該有一個else部分來應對每一條if語句。此外,如果你在if語句的分支中設置變量,那么或許你在另一個分支中也要設置。與此種情況相關的是標記被設置的情況。只添加用于設置的標記的條件不難,但是很容易忘了添加當標記應該再次重置時的條件。留下一個永遠設置的標志可能會導致之后接連不斷的bug。

6.改變假設。

許多一開始最難預防的bug是因為改變了假設所造成的。例如,在開始時,可能每天只有一個客戶事件。于是很多代碼是在這樣的假設下寫下的。但是后來,設計改變了,允許每天有多個客戶事件了。發(fā)生這種情況時,很難改變新設計影響到的所有情況。找到關于改變的所有顯式依賴關系不難,難的是要找到所有隱性依賴于舊的設計的情況。例如,可能會有獲取給定某一天所有客戶事件的代碼。其中的隱含假設是結果集永遠不會超過客戶的數量。關于這方面的問題我也沒有很好的策略方法,如果各位有的話,還請不吝賜教。

7.日志記錄。

可視化程序做什么至關重要,特別是當邏輯很復雜的時候。確保補充足夠多的(但不要太多)日志記錄,這樣你就可以說明為什么程序要這么做。如果一切正常,那也沒關系,但要是有問題發(fā)生,你會很慶幸自己添加了這些日志。

測試

作為一個開發(fā)人員,直到要測試了我才會去處理功能。至少,這意味著每一行新的或改變了的代碼行至少已經被執(zhí)行過一次。此外,單元測試和功能測試都很不錯,但還不夠。新的功能也必須進行測試,并在類似于產品的環(huán)境中探索。只有這樣,我才能說我完成了一個功能。下面是我經歷過的bug所教會我的關于測試的一些重要的經驗教訓:

1.零和null。

如果可行的話,確??偸怯昧愫蚽ull來測試。對于字符串,這意味著要測試長度為零的字符串以及字符串為null兩種情況。又如:測試TCP連接的斷開,要在發(fā)送數據給它發(fā)送之前。不使用這些組合方法測試是導致bug出現的首位原因。

2.添加和刪除。

通常,新的功能包括能夠添加新的配置到系統(tǒng)中——例如,一個用于手機號碼轉換的新的配置文件。測試它能否添加新的配置文件是很自然的。但是,我發(fā)現我們很容易忘記去測試刪除配置文件是不是同樣ok。

3.錯誤處理。

處理錯誤的代碼往往是難以測試的。最好有能檢查錯誤處理代碼的自動測試,但有時這是不可能的。我有時會使用的一招是臨時修改代碼,使得錯誤處理代碼運行起來。要做到這一點最簡單的方法是反轉if語句——例如,從if error_count > 0改成error_count == 0。另一個例子是拼錯數據庫列名,從而導致期望的錯誤處理代碼運行。

4.隨機輸入。

通常,揭露bug測試的一種測試方法是使用隨機輸入。例如,H.323協議的ASN.1解碼使用二進制數據操作。通過發(fā)送隨機字節(jié)去解碼,我們發(fā)現了解碼器中的幾個bug。另一個例子是用測試呼叫來生成腳本,此時呼叫持續(xù)時間,接聽延遲,第一方掛斷等等都是隨機生成的。這些測試腳本會暴露許多bug,特別是一起發(fā)生的事件會產生并攏干擾。

5.檢查不應該發(fā)生的動作。

通常測試包括檢查期望動作是不是發(fā)生了。但我們很容易忽視相反的情況——忘記檢查不應該發(fā)生的動作是不是的確沒有發(fā)生。

6.擁有工具。

我創(chuàng)建了自己的小工具,以使得測試更加簡單。例如,當我用VoIP SIP協議工作時,我寫了一個能夠用正是我想要的標題和值回復的小腳本。這個工具使得測試很多邊界情況變得容易起來。另一個例子是可以進行API調用的一個命令行工具。通過啟動逐漸添加所需小功能,我得到了一些非常有用的工具。自己寫工具的好處是,我得到的正是我想要的。

在測試中發(fā)現所有的bug,那絕對是不可能的。有一個案例中,我更改了數字相關性的處理,數字由兩個部分組成:路由地址前綴(通常是不變的),以及從000到999動態(tài)分配的數字。問題在于當找到相關性時,動態(tài)分配的數字的第一個數字會在呈現在表格中之前遭到誤刪。也就是說637變成了37。這意味著,到100之前它都是可以工作的,因此,前面100個電話是正常的,但是接下來的900個都是失敗。所以,除非我在重新啟動之前能夠測試超過100次(事實是我沒有),否則我在測試時就不會發(fā)現這個問題。

調試

1.討論。

幫助我最多的調試技術是與同事討論問題。通常情況下,只是和同事說明問題,就會讓我意識到問題的癥結。此外,即使他們不是很熟悉有問題的代碼,他們也往往能提出一些好點子。與同事討論在處理最難的bug時特別有效。

2.密切關注。

通常,如果調試問題花了很長時間,往往是因為我做了錯誤的假設。例如,我認為問題發(fā)生在某一方法中,但事實卻是它甚至從來沒有到達那個方法?;蛘?,被拋出的異常不是我以為的那個?;蛘?,我認為軟件的最新版本上正在運行,但其實是一個舊版本。因此,一定要核實細節(jié),而不是假設。人們更容易看到自己希望看到的東西,而不是事實。

3.最近的變化。

當曾經可以正常工作的東西停止工作,那么這通常是因為最近改變的東西所導致的。在一個案例中,最近的改變只是日志記錄,但是日志中的錯誤卻導致了一個更大的問題。為了更容易找到這種回歸,承認不同的提交會導致不同的變化,以及清楚說明這些更改會有所裨益。

4.相信用戶。

有時,當用戶報告問題的時候,我的本能反應是,“這是不可能的。一定是他們做錯了什么事”。但我學會了不再用這種方式去回應。更多的時間,事實往往證明,他們所報告的的確是實際發(fā)生的情況。因此,這些天,我開始接受他們所報告的內容的表明價值。當然,我依然會仔細檢查一切是否被正確地設置等等。我見過很多這樣的情況,讓我明白,因為不尋常的配置或意料之外的用法而導致不可思議的事情的發(fā)生,而我默認的假設是,他們是正確的,程序是錯誤的。

5.測試修復。

如果bug修復已準備就緒,那就必須進行測試。首先在修復前運行代碼,并觀察該bug。然后應用修復并重復測試案例。到此為止錯誤行為應消失。遵循這些步驟可以確保它確實是一個bug,并且此次修復的確可以解決這個問題。簡單而有必要。

其他觀察結果

現在工作于C++時所遇到的幾類bug已經完全消失,像堆棧溢出,內存損壞,字符串問題和某種形式的內存泄漏。

其他問題,如循環(huán)錯誤和邊界情況,我看到的要少得多。但是,這并不意味著那里沒有bug。如果大家有什么有用的預防和發(fā)現bug的技術方法,歡迎留言。

作為過來人,最后的心靈雞湯

1.“學歷代表過去、能力代表現在、學習力代表未來?!?/p>

2.一定要確定自己的發(fā)展方向,并為此目的制定可行的計劃。

3.軟件開發(fā)團隊中,技術不是萬能的,但沒有技術是萬萬不能的!

4.詳細制定自己軟件開發(fā)專業(yè)知識學習計劃,并注意及時修正和調整(軟件開發(fā)技術變化實在太快)。

5.書籍是人類進步的階梯,對軟件開發(fā)人員尤其如此。

6.不要僅局限于對某項技術的表面使用上,哪怕你只是偶爾用一、二次。

7.在一種語言上編程,但別為其束縛了思想。“代碼大全”中說:“深入一門語言編程,不要浮于表面”。

8.養(yǎng)成總結與反思的習慣,并有意識地提煉日常工作成果,形成自己的個人源碼庫、解決某類問題的通用系統(tǒng)體系結構、甚至進化為框架。

9.理論與實踐并重,內外雙修。

10.心態(tài)有多開放,視野就有多開闊。

11.盡量參加開源項目的開發(fā)、或者與朋友共同研制一些自己的產品,千萬不要因為沒有錢賺而不做。

12.書到用時方恨少,不要將自己的知識面僅僅局限于技術方面。

總結與反思

1.不要去做技術上的高手,除非你的目標如此。

2.提高軟件知識和技術只是問題的表面,本質是要提高自己認識問題、分析問題、解決問題的思想高度。軟件專業(yè)知識的很多方法和原理,可以很容易地延伸、應用到生活的其它方面。

3.在能勝任工作的基礎上,立即去涉獵其它領域的專業(yè)知識,豐富自己的知識體系、提高自己的綜合素質,尤其是那些目標不在技術方面的朋友。

聲明:本文內容及配圖由入駐作者撰寫或者入駐合作網站授權轉載。文章觀點僅代表作者本人,不代表電子發(fā)燒友網立場。文章及其配圖僅供工程師學習之用,如有內容侵權或者其他違規(guī)問題,請聯系本站處理。 舉報投訴
  • 編碼
    +關注

    關注

    6

    文章

    940

    瀏覽量

    54813
  • BUG
    BUG
    +關注

    關注

    0

    文章

    155

    瀏覽量

    15665

原文標題:如何減少編碼、測試和調試三個階段的bug?

文章出處:【微信號:gh_c472c2199c88,微信公眾號:嵌入式微處理器】歡迎添加關注!文章轉載請注明出處。

收藏 人收藏

    評論

    相關推薦

    工程師13年編碼、測試調試經驗大匯總

    最近,我回顧了我所有的194條目(從13歲開始),看看有什么經驗教訓是我可以學習的。下面是我總結的最重要的經驗教訓,包括編碼,測試調試三個
    發(fā)表于 07-17 22:41 ?2021次閱讀

    芯片的設計制造,大體分這三個階段

    我們知道,芯片的設計制造要經過一非常復雜的過程,可大體分為三個階段:前端設計(邏輯代碼設計)、后端設計(布線過程)、投片生產(制芯、測試與封裝)。
    發(fā)表于 03-03 14:59 ?6933次閱讀

    轉: 13年棘手Bug調試總結18條教訓

    有什么經驗教訓是我可以學習的。下面是我總結的最重要的經驗教訓,包括編碼,測試調試三個方面。編碼下面這些都是我經歷過的會導致難點
    發(fā)表于 07-11 18:07

    華為5G的三個戰(zhàn)略階段

    三階段“基于獨立組網的5G核心網關鍵技術與業(yè)務流程測試”。這三個階段測試,華為均以100%通過率順利完成。除了
    發(fā)表于 04-22 21:33

    嵌入式Bug調試的經驗匯總

    基于web的系統(tǒng)。使用過C ++,Ruby,Java和Python等。這篇文章中的經驗教訓旨在幫助減少編碼,測試調試三個
    發(fā)表于 10-22 09:39

    如何進行編程可以減少程序的bug?

    ?如何進行編程可以減少程序的bug?有人認為單片機將被ARM等系列結構的嵌入式系統(tǒng)所取代。單片機的生命期還有多長?
    發(fā)表于 03-10 06:11

    鋰離子電池進行充電時有哪三個階段策略?為什么需要進行3階段

    鋰離子電池進行充電時有哪三個階段策略?為什么需要進行3階段?
    發(fā)表于 03-11 07:10

    淺談物聯網成熟的三個階段

    2018年必將是物聯網爆發(fā)的元年,從開始誕生到成熟,成熟的物聯網將會經歷三個階段:第一階段:利用物聯網數據簡化流程;第二階段:創(chuàng)造新的收入來源;第
    發(fā)表于 12-26 15:17 ?4715次閱讀

    工程師跨度13年、回顧194bug總結的18條編碼測試調試經驗教訓

    工程師跨度13年、回顧194bug總結的18條編碼測試調試經驗教訓。
    發(fā)表于 02-27 16:50 ?1074次閱讀

    嵌入式大牛的10年Bug調試經驗分享

    作者十年來做過小的嵌入式系統(tǒng),大的電信系統(tǒng)以及基于web的系統(tǒng)。使用過C ++,Ruby,Java和Python等。這篇文章中的經驗教訓旨在幫助減少編碼,測試調試
    的頭像 發(fā)表于 01-01 09:03 ?3201次閱讀

    蘋果發(fā)布iOS13第三個測試版更新 以修復Bug為主

    今天,蘋果發(fā)布了iOS 13第三個測試版更新,之前已經在測試版的用戶,都可以進行OTA更新。
    的頭像 發(fā)表于 07-03 10:17 ?2572次閱讀

    嵌入式大牛10年調Bug經驗總結

    這十年來我做過小的嵌入式系統(tǒng),大的電信系統(tǒng)以及基于web的系統(tǒng)。使用過C ++,Ruby,Java和Python等。這篇文章中的經驗教訓旨在幫助減少編碼,測試調試
    發(fā)表于 02-10 10:07 ?1次下載
    嵌入式大牛10年調<b class='flag-5'>Bug</b>經驗總結

    嵌入式開發(fā)老手總結編碼,測試調試三個階段bug

    有若干條件的if語句,if (a 或 b) ,特別是當有鏈接的時候, if (x) else if (y),都給我引發(fā)了很多bug。即使if語句在概念上很簡單,但當有多個條件要跟蹤的時候依然很容易出錯。這些天,我嘗試重寫代碼使之更簡單,以避免處理復雜的if語句。
    發(fā)表于 10-10 10:53 ?306次閱讀

    常見的PLC系統(tǒng)BUG有哪些?如何減少這些BUG的產生?

    、邏輯錯誤或變量命名錯誤導致的。為了減少邏輯錯誤的產生,建議進行嚴謹的程序設計和測試,使用清晰的變量命名和注釋,并進行詳盡的測試
    的頭像 發(fā)表于 10-31 11:30 ?1102次閱讀
    常見的PLC系統(tǒng)<b class='flag-5'>BUG</b>有哪些?如何<b class='flag-5'>減少</b>這些<b class='flag-5'>BUG</b>的產生?

    人機交互的三個階段 人機交互的常用方式

    機交互經歷的三個階段:命令行界面交互階段、圖形用戶界面交互階段、自然和諧的人機交互階段。
    的頭像 發(fā)表于 03-13 17:25 ?3027次閱讀
    RM新时代网站-首页