chinese直男口爆体育生外卖, 99久久er热在这里只有精品99, 又色又爽又黄18禁美女裸身无遮挡, gogogo高清免费观看日本电视,私密按摩师高清版在线,人妻视频毛茸茸,91论坛 兴趣闲谈,欧美 亚洲 精品 8区,国产精品久久久久精品免费

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

完善資料讓更多小伙伴認(rèn)識(shí)你,還能領(lǐng)取20積分哦,立即完善>

3天內(nèi)不再提示

進(jìn)行編碼、測(cè)試和調(diào)試三個(gè)階段時(shí)如何減少bug

Q4MP_gh_c472c21 ? 來源:cc ? 2019-02-11 16:52 ? 次閱讀
加入交流群
微信小助手二維碼

掃碼添加小助手

加入工程師交流群

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

會(huì)導(dǎo)致難點(diǎn)bug的問題

1.事件順序。

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

2.過早。

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

3.悄無聲息的故障。

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

4.If。

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

5.Else。

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

6.改變假設(shè)。

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

7.日志記錄。

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

測(cè)試

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

1.零和null。

如果可行的話,確保總是用零和null來測(cè)試。對(duì)于字符串,這意味著要測(cè)試長(zhǎng)度為零的字符串以及字符串為null兩種情況。又如:測(cè)試TCP連接的斷開,要在發(fā)送數(shù)據(jù)給它發(fā)送之前。不使用這些組合方法測(cè)試是導(dǎo)致bug出現(xiàn)的首位原因。

2.添加和刪除。

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

3.錯(cuò)誤處理。

處理錯(cuò)誤的代碼往往是難以測(cè)試的。最好有能檢查錯(cuò)誤處理代碼的自動(dòng)測(cè)試,但有時(shí)這是不可能的。我有時(shí)會(huì)使用的一招是臨時(shí)修改代碼,使得錯(cuò)誤處理代碼運(yùn)行起來。要做到這一點(diǎn)最簡(jiǎn)單的方法是反轉(zhuǎn)if語句——例如,從if error_count > 0改成error_count == 0。另一個(gè)例子是拼錯(cuò)數(shù)據(jù)庫(kù)列名,從而導(dǎo)致期望的錯(cuò)誤處理代碼運(yùn)行。

4.隨機(jī)輸入。

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

5.檢查不應(yīng)該發(fā)生的動(dòng)作。

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

6.擁有工具。

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

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

調(diào)試

1.討論。

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

2.密切關(guān)注。

通常,如果調(diào)試問題花了很長(zhǎng)時(shí)間,往往是因?yàn)槲易隽隋e(cuò)誤的假設(shè)。例如,我認(rèn)為問題發(fā)生在某一方法中,但事實(shí)卻是它甚至從來沒有到達(dá)那個(gè)方法?;蛘?,被拋出的異常不是我以為的那個(gè)。或者,我認(rèn)為軟件的最新版本上正在運(yùn)行,但其實(shí)是一個(gè)舊版本。因此,一定要核實(shí)細(xì)節(jié),而不是假設(shè)。人們更容易看到自己希望看到的東西,而不是事實(shí)。

3.最近的變化。

當(dāng)曾經(jīng)可以正常工作的東西停止工作,那么這通常是因?yàn)樽罱淖兊臇|西所導(dǎo)致的。在一個(gè)案例中,最近的改變只是日志記錄,但是日志中的錯(cuò)誤卻導(dǎo)致了一個(gè)更大的問題。為了更容易找到這種回歸,承認(rèn)不同的提交會(huì)導(dǎo)致不同的變化,以及清楚說明這些更改會(huì)有所裨益。

4.相信用戶。

有時(shí),當(dāng)用戶報(bào)告問題的時(shí)候,我的本能反應(yīng)是,“這是不可能的。一定是他們做錯(cuò)了什么事”。但我學(xué)會(huì)了不再用這種方式去回應(yīng)。更多的時(shí)間,事實(shí)往往證明,他們所報(bào)告的的確是實(shí)際發(fā)生的情況。因此,這些天,我開始接受他們所報(bào)告的內(nèi)容的表明價(jià)值。當(dāng)然,我依然會(huì)仔細(xì)檢查一切是否被正確地設(shè)置等等。我見過很多這樣的情況,讓我明白,因?yàn)椴粚こ5呐渲没蛞饬现獾挠梅ǘ鴮?dǎo)致不可思議的事情的發(fā)生,而我默認(rèn)的假設(shè)是,他們是正確的,程序是錯(cuò)誤的。

5.測(cè)試修復(fù)。

如果bug修復(fù)已準(zhǔn)備就緒,那就必須進(jìn)行測(cè)試。首先在修復(fù)前運(yùn)行代碼,并觀察該bug。然后應(yīng)用修復(fù)并重復(fù)測(cè)試案例。到此為止錯(cuò)誤行為應(yīng)消失。遵循這些步驟可以確保它確實(shí)是一個(gè)bug,并且此次修復(fù)的確可以解決這個(gè)問題。簡(jiǎn)單而有必要。

其他觀察結(jié)果

現(xiàn)在工作于C++時(shí)所遇到的幾類bug已經(jīng)完全消失,像堆棧溢出,內(nèi)存損壞,字符串問題和某種形式的內(nèi)存泄漏。

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

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

1.“學(xué)歷代表過去、能力代表現(xiàn)在、學(xué)習(xí)力代表未來?!?/p>

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

3.軟件開發(fā)團(tuán)隊(duì)中,技術(shù)不是萬能的,但沒有技術(shù)是萬萬不能的!

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

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

6.不要僅局限于對(duì)某項(xiàng)技術(shù)的表面使用上,哪怕你只是偶爾用一、二次。

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

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

9.理論與實(shí)踐并重,內(nèi)外雙修。

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

11.盡量參加開源項(xiàng)目的開發(fā)、或者與朋友共同研制一些自己的產(chǎn)品,千萬不要因?yàn)闆]有錢賺而不做。

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

總結(jié)與反思

1.不要去做技術(shù)上的高手,除非你的目標(biāo)如此。

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

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

聲明:本文內(nèi)容及配圖由入駐作者撰寫或者入駐合作網(wǎng)站授權(quán)轉(zhuǎn)載。文章觀點(diǎn)僅代表作者本人,不代表電子發(fā)燒友網(wǎng)立場(chǎng)。文章及其配圖僅供工程師學(xué)習(xí)之用,如有內(nèi)容侵權(quán)或者其他違規(guī)問題,請(qǐng)聯(lián)系本站處理。 舉報(bào)投訴
  • 編碼
    +關(guān)注

    關(guān)注

    6

    文章

    1034

    瀏覽量

    56798
  • BUG
    BUG
    +關(guān)注

    關(guān)注

    0

    文章

    156

    瀏覽量

    16247

原文標(biāo)題:如何減少編碼、測(cè)試和調(diào)試三個(gè)階段的bug?

文章出處:【微信號(hào):gh_c472c2199c88,微信公眾號(hào):嵌入式微處理器】歡迎添加關(guān)注!文章轉(zhuǎn)載請(qǐng)注明出處。

收藏 人收藏
加入交流群
微信小助手二維碼

掃碼添加小助手

加入工程師交流群

    評(píng)論

    相關(guān)推薦
    熱點(diǎn)推薦

    工程師13年編碼、測(cè)試調(diào)試經(jīng)驗(yàn)大匯總

    最近,我回顧了我所有的194個(gè)條目(從13歲開始),看看有什么經(jīng)驗(yàn)教訓(xùn)是我可以學(xué)習(xí)的。下面是我總結(jié)的最重要的經(jīng)驗(yàn)教訓(xùn),包括編碼,測(cè)試調(diào)試三個(gè)
    發(fā)表于 07-17 22:41 ?2170次閱讀

    芯片的設(shè)計(jì)制造,大體分這三個(gè)階段

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

    轉(zhuǎn): 13年棘手Bug調(diào)試總結(jié)18條教訓(xùn)

    有什么經(jīng)驗(yàn)教訓(xùn)是我可以學(xué)習(xí)的。下面是我總結(jié)的最重要的經(jīng)驗(yàn)教訓(xùn),包括編碼,測(cè)試調(diào)試三個(gè)方面。編碼下面這些都是我經(jīng)歷過的會(huì)導(dǎo)致難點(diǎn)
    發(fā)表于 07-11 18:07

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

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

    嵌入式Bug調(diào)試的經(jīng)驗(yàn)匯總

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

    如何進(jìn)行編程可以減少程序的bug

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

    鋰離子電池進(jìn)行充電時(shí)有哪三個(gè)階段策略?為什么需要進(jìn)行3個(gè)階段?

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

    淺談物聯(lián)網(wǎng)成熟的三個(gè)階段

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

    工程師跨度13年、回顧194個(gè)bug總結(jié)的18條編碼、測(cè)試調(diào)試經(jīng)驗(yàn)教訓(xùn)

    工程師跨度13年、回顧194個(gè)bug總結(jié)的18條編碼、測(cè)試調(diào)試經(jīng)驗(yàn)教訓(xùn)。
    發(fā)表于 02-27 16:50 ?1327次閱讀

    嵌入式大牛的10年Bug調(diào)試經(jīng)驗(yàn)分享

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

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

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

    嵌入式大牛10年調(diào)Bug經(jīng)驗(yàn)總結(jié)

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

    嵌入式開發(fā)老手總結(jié)編碼,測(cè)試調(diào)試三個(gè)階段bug

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

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

    、邏輯錯(cuò)誤或變量命名錯(cuò)誤導(dǎo)致的。為了減少邏輯錯(cuò)誤的產(chǎn)生,建議進(jìn)行嚴(yán)謹(jǐn)?shù)某绦蛟O(shè)計(jì)和測(cè)試,使用清晰的變量命名和注釋,并進(jìn)行詳盡的測(cè)試
    的頭像 發(fā)表于 10-31 11:30 ?1936次閱讀
    常見的PLC系統(tǒng)<b class='flag-5'>BUG</b>有哪些?如何<b class='flag-5'>減少</b>這些<b class='flag-5'>BUG</b>的產(chǎn)生?

    人機(jī)交互的三個(gè)階段 人機(jī)交互的常用方式

    機(jī)交互經(jīng)歷的三個(gè)階段:命令行界面交互階段、圖形用戶界面交互階段、自然和諧的人機(jī)交互階段
    的頭像 發(fā)表于 03-13 17:25 ?5618次閱讀