本文翻譯自 http://www.amibug.com/iamabug/p01.html

非常有趣，同時能夠?qū)W習(xí)到很好的方法。

bug1.png

為了使我們的工作更有趣，當(dāng)我們的軟件中有一個問題的時候，我們叫它 Bug。

我比較支持在軟件工程中給予Bug以更廣的定義，我喜歡把它定義為和項目相關(guān)的所有事物。大部分人定義Bug使用特定的定義，比如Bug是缺陷，問題，軟件開發(fā)交付件（需求，設(shè)計，代碼等等）中被植入的異常，或是被弄錯的或者被忽略的，以軟件故障的形式呈現(xiàn)出來。有些異常/問題不一定會因為缺陷或者錯誤而導(dǎo)致的，有時候它只是意外行為，這種Bug的特定定義我認(rèn)為是比較狹義的，因為重要的關(guān)注點是沒有被定義進去的。

這些都是關(guān)注我（bug）的人

bug2.png

Audrey 是我們的SQA主管--他的團隊負責(zé)找到Bug！

Yves-Alain 是我們的開發(fā)主管，他保證軟件中不引入Bug，但如果有Bug引入了，他的團隊處理他們。

Oliver是我們的產(chǎn)品經(jīng)理，他和客戶一起確定我們程序需要做的事情。Oliver幫助我們確定哪些Bug需要處理，哪些不需要。

在這種做決策的團隊中三個不同的視角是非常有必要的，這些角色是SQA主管，開發(fā)主管，產(chǎn)品經(jīng)理。

在這個決策會議中，決定Bug是否需要修復(fù)，決定保留這個Bug不修復(fù)（遺留問題），這種決定通常是修復(fù)這個Bug容易對軟件引發(fā)破壞，決定把這些Bug遺留在產(chǎn)品中，通常是客戶容易忽視和不會碰到的情況。一個決策團隊?wèi)?yīng)該是小型的，有效的團隊，它的人員組成都是有能力做決策的人員。一個差的Bug決策團隊充滿了沒有能力做決策的人，這些人需要叫上更多的人來一起做決定。盡管一個好的決策團隊優(yōu)勢也需要另外的輸入，但是他們很少需要其他人介入一起才能夠做決策。

SQA 主管是QA的代表，他提供Bug的客觀信息，同時，開發(fā)主管和產(chǎn)品經(jīng)理討論這些信息并作出決定，SQA主管不應(yīng)該去插手決定Bug是否需要修改，他必須是中立的。

開發(fā)主管是開發(fā)團隊的代表，他的工作是評估修改Bug的技術(shù)風(fēng)險。

產(chǎn)品經(jīng)理代表客戶，他的工作是評估修改Bug對客戶的風(fēng)險。如果開發(fā)主管和產(chǎn)品經(jīng)理經(jīng)常吵哪些Bug應(yīng)該修改，哪些不用修改，那么這個團隊是低效率的。偶爾的爭吵是正常的，正常情況下都應(yīng)該很快達成一致。在偶爾的沒能達成一致情況下，我偏重于考慮產(chǎn)品經(jīng)理的意見，因為他是代表客戶的，他才知道客戶的需求。

Bug沒有好壞

bug3.gif

當(dāng)我們發(fā)現(xiàn)Bug，我們不問這個Bug是好是壞。我們確定它是否重要，我們考慮他對系統(tǒng)會造成多大影響。

Bug的重要性（優(yōu)先級）和對系統(tǒng)造成的影響（嚴(yán)重性）是獨立的，優(yōu)先級和重要性是分別定義的。遺留Bug的優(yōu)先級和重要性評估通常是軟件能否發(fā)布的重要條件。因此人們把他們放到了重要的位置，以至于不能夠讓實習(xí)生來填這些信息，我經(jīng)常遇到這樣的狀況，測試人員提出優(yōu)先級和重要性，但這不是最終解決辦法。每個Bug適用于4象限中的一種。

Q1 緊急，重要
Q2 緊急，不重要
Q3 不緊急，重要
Q4 不緊急，不重要

對于Bug數(shù)量四象限分布的正確理解有利于測試人員有效評估測試活動的有效性。如果發(fā)現(xiàn)Q3，Q4的Bug分布遠超Q1，Q2，那么測試團隊?wèi)?yīng)該轉(zhuǎn)移戰(zhàn)場測試其他模塊或者轉(zhuǎn)換一下測試方法。

但是一些Bug是重要的

bug4.png

我們直接關(guān)注重要的Bug我們怎么來報告一個重要的Bug，答案是他系了領(lǐng)帶。優(yōu)先級的劃分取決于人員，資源，時間等等的約束。一個一般嚴(yán)重程度的Bug在項目中貌似是致命的，對于項目干系人來說它是高優(yōu)先級的但是不嚴(yán)重。Bug的優(yōu)先級隨著商業(yè)環(huán)境或者技術(shù)的環(huán)境變化而變化。在上周覺得這個Bug很重要但是在這周就變得不重要了。如果客戶已經(jīng)決定不再需要某個特性，這個特性相關(guān)的Bug可能之前很重要但這之后就變得沒有意義了。Bug的優(yōu)先級和嚴(yán)重性要考慮商業(yè)環(huán)境。他們必須知道利益干系人是誰，客戶是誰，技術(shù)限制是什么，設(shè)計驅(qū)動是什么等等。這時候他們需要用現(xiàn)有的知識來調(diào)整他們對新Bug的看法和刷新對老Bug的看法。

一些Bug容易對系統(tǒng)造成很大影響

bug5.png

我們經(jīng)常關(guān)注這些危險的Bug

這些危險的Bug是嚴(yán)重等級高的Bug,這些Bug會使程序崩潰，更嚴(yán)重的是會破壞數(shù)據(jù)。就像優(yōu)先級一樣，嚴(yán)重等級隨著商業(yè)環(huán)境而改變。

被蚊子咬也許沒什么傷害

bug6.png

單一的小Bug看起來沒什么危險

但是成群的蚊子就很可怕了

bug7.png

成百上千的小Bug同時出現(xiàn)就很可怕

大量Bug會激怒用戶甚至使程序不可用，盡管單個Bug來說并不嚴(yán)重。

嚴(yán)重級別低的Bug如果影響了大量用戶就會引發(fā)大量客服投訴。

被一個蜜蜂扎了只是一點點疼

bug8.png

同樣的Bug可以在不同計算機程序中找到。在一個程序中這個Bug沒什么破壞性
在幫助系統(tǒng)中文法錯誤不會影響任何人甚至不會讓人覺察。

但如果你對蜜蜂過敏，那么它將會殺死你

bug9.png

但同樣的Bug在不同程序中就是致命的。

在醫(yī)療軟件中，一個語法錯誤比一個系統(tǒng)死機更具有災(zāi)難性的影響。如果醫(yī)療軟件死機了，醫(yī)生最多不用這個軟件來診斷了，沒人會受傷害。但是如果是一個語法錯誤，比如過去式和現(xiàn)在式混淆了，意味著影響了患者的就診歷史記錄讀取，這可是關(guān)乎生死的事情。

Bug喜歡聚集在潮濕骯臟的環(huán)境中

bug10.png

當(dāng)我們急匆匆的開始夠條件新的軟件時，我們的辦公室和程序就會陷入混亂。我們知道這會帶來很多Bug。
糟糕的軟件工程實踐會陷入圖中所示的困境，Bug滿地。

Bug也存在于家附近，院子附近。

bug11.png

當(dāng)我們愿意花些時間做一些清潔，我們的辦公室和程序就會更加干凈和整潔。
也許還會有一些友好的Bug。

修復(fù)Bug是一個業(yè)務(wù)上的決定，有時候修復(fù)Bug不見得會讓你收益。
友好的Bug是那種不會影響到用戶使用的Bug。只是這些Bug和需求不太相符合，但它并不壞。有時候客戶非常熟悉的特性也許會是一個Bug,因為它不符合需求，其他一些只是程序中的細小差別并不影響客戶使用，我們認(rèn)為是友好的Bug。
AVT-710病人詳情記錄含有很多的Bug，但是人們可以避免它們。就算是包含有這些Bug，他也是一個可靠的產(chǎn)品。

有些Bug已經(jīng)沉睡了很久

bug12.png

有時候我們是在程序用了很久之后才發(fā)現(xiàn)Bug的。
我們稱這些Bug是沉睡的Bug。

在一定的時間內(nèi)軟件內(nèi)部含有Bug，但這些Bug并沒有暴露，當(dāng)有一天軟件上下文改變時Bug就暴露了。
經(jīng)過經(jīng)典的例子是Visio97， 他是在硬盤空間比當(dāng)前需要的空間小的時候發(fā)生的，當(dāng)在新的電腦（新電腦有很大的硬盤空間）安裝Visio97時，安裝程序會提示空間不足。為什么？因為Visio97采用32位的算法來計算剩余空間，在產(chǎn)品發(fā)布的時候，一點都沒有問題。但是當(dāng)新的有更大的硬盤空間出現(xiàn)的時候（此時已經(jīng)硬盤空間已經(jīng)不是32位算法），就出現(xiàn)問題了，數(shù)位被截斷了，計算方法錯誤。這個Bug是沉睡的，因為它是因為在技術(shù)限制被突破后暴露的問題。

有時候軟件的使用用途也會變，比如，Windows 的打印機（LaserJet2惠普打印機 ）驅(qū)動是設(shè)計成打印表格的，驅(qū)動中的代碼并不能處理彩色照片，這些驅(qū)動在那個時代是好用的，但是現(xiàn)在已經(jīng)不可用了。

又或者軟件的用戶群是會變換的，比如今天軟件是專家在用，沒準(zhǔn)有一天就是一般的民眾在使用，這兩個群體的需求和興趣點可以不一樣的哦，因此當(dāng)專家用的時候并不是bug而在普通大眾來說可能就是一個嚴(yán)重bug。

令人驚奇的是---我們幸運的發(fā)現(xiàn)一個蝴蝶

bug13.png

有時沉睡的Bug被喚醒來了。
如果我們幸運，這個Bug不會對系統(tǒng)有任何影響。
有時當(dāng)沉睡的Bug被喚醒時，我們叫他“特性”。

當(dāng)沉睡的Bug被喚醒時，他們成為系統(tǒng)的特性，不管你喜歡不喜歡。

當(dāng)沉睡的Bug被喚醒時，它會有向后兼容性的問題，特別是Bug本身被依賴時。一個經(jīng)典的例子是微軟word的頁白計算，在老版本中是計算錯誤的。當(dāng)微軟已經(jīng)修復(fù)了這個Bug時，所有老版本的文件頁邊都會有些許的偏差。

我們的網(wǎng)很容易捕獲這些蝴蝶。

bug14.png

當(dāng)我們測試一個電腦程序時我們制定一個測試計劃。
測試計劃就像捕獲Bug的網(wǎng)。
一些測試計劃只能捕獲明顯的Bug。

測試計劃聚焦不同粒度的Bug，取決于測試時間和預(yù)算，有時候我們希望發(fā)現(xiàn)盡可能多的風(fēng)險盡管不是很深入，而不是深入的測試每個風(fēng)險。網(wǎng)越細，測試的深度越深。

有些測試套叫做FAST，全稱是 Functional Acceptance Simple Tests。這個測試只測試系統(tǒng)處理正常輸入數(shù)據(jù)的能力，讓我們對系統(tǒng)對正常輸入的處理有信心，但是它不保證系統(tǒng)能夠處理其他情況。**

但是這并不是我們的老朋友蚊子

bug15.png

一些測試計劃 ---“網(wǎng)”非常好，能夠捕獲很小的蚊子（Bug）。

我們應(yīng)該用什么樣的網(wǎng)呢？

bug16.png

有時我們用一個測試計劃來捕獲大Bug，然后，如果我們還有時間，我們使用更細的網(wǎng)來捕獲小Bug。

當(dāng)我們被蚊子咬疼的時候，我們會拍打它，抓它

bug17.png

當(dāng)Bug能否以簡單直接的方式處理的時候，我們感覺是小小的。

抓一下能夠減少疼痛但是也許藥物可以更好解決問題。

bug18.png

Bug造成的小小影響通常可以通過改變?nèi)藗兊氖褂梅椒▉斫鉀Q。
Bug能夠被修復(fù)，避免和忽略，如果Bug不能被修復(fù)，應(yīng)該引導(dǎo)用戶改變使用方法來避免Bug的發(fā)生。**
**

驅(qū)蚊水能夠使蚊子遠離我們

bug19.png

有時我們找到了很好地辦法來避免一類的Bug。
有很多專用的技術(shù)可以發(fā)現(xiàn)特種類型的Bug。
一種好的辦法是自我數(shù)據(jù)嚴(yán)重機制，對于特定數(shù)據(jù)輸入，理解軟件后能夠定義出測試oracle。這是一種非常好的發(fā)現(xiàn)數(shù)據(jù)完整性Bug的辦法。

但是如果蚊子是成群結(jié)隊的，那么驅(qū)蚊水也無濟于事。

bug20.png

然后我們發(fā)現(xiàn)這些特定類型的Bug有很多很多兄弟姐妹。
找到緩沖區(qū)溢出Bug的技術(shù)是很好的一種找Bug方式，但是他們不能找到計算錯誤類型的Bug。Bug的類型可遠遠不止緩沖區(qū)溢出一種類型。
同樣的，通過自驗數(shù)據(jù)完整性的校驗技術(shù)，在有很多界面Bug或者業(yè)務(wù)邏輯Bug阻礙了數(shù)據(jù)達到數(shù)據(jù)處理模塊時，不是最有效率和最有效果的。

網(wǎng)可以讓蚊子隔離在網(wǎng)外。

bug21.png

我們知道很多在最開始的時候就阻止Bug進入到我們程序的辦法。

所謂的辦法包含軟件工程中的三個重要工作流：配置管理，需求管理，測試管理。他們同時包含了開發(fā)規(guī)則，靜態(tài)分析，代碼檢視，新代碼的交叉檢視，單元測試，好的開發(fā)實踐，好的架構(gòu)和一大堆其他的。

一些人使用昂貴的微波滅蟲器。

bug22.png

很久以前有個騙子銷售員賣給我們一個新鮮刺激的玩具，叫做“bug zapper”。

我們深信用了它所有bug都被消滅干凈了。

工具提供商的銷售人員有時會誤導(dǎo)我們，讓我們忽視了成本和收益以及它的易用性。
比如：他們會聲稱測試自動化工具會捕獲動作和回放這些動作，并能夠解決你的所有問題。
他們會說，用這個工具吧，他們能夠發(fā)現(xiàn)程序的所有問題。最初這會打動你，但是這些類型的工具要求大量的編程并且不能解決任何問題，甚至帶來很大的維護成本，簡直是一個噩夢。

工具提供商還會聲稱你需要一個需求跟蹤工具，它將減少成本，但是工具本身就需要錢購買。減少成本的應(yīng)該是建立起需求管理的規(guī)則。

微波滅蟲器看起來很酷

bug23.png

最開始“bug zapper”貌似能夠處理一些重要的Bug。

但是實際上并不能確保趕走蚊子。

bug24.png

但是Bug很快就有免疫力了，他們避開了bug zapper，我們連買bug zapper的錢都收不回來。

噴霧殺蟲劑也許是個解決辦法。

bug25.png

當(dāng)我們修改Bug的時候一定要小心。

但是這樣可能不僅僅的蚊子受到傷害了

bug26.png

但我們修改Bug的時候我們也許會引入其他Bug。

有時候解決辦法比問題還糟糕，修改一個Bug也許會引入其他Bug，導(dǎo)致錯誤的系統(tǒng)行為。又或者Bug在功能層面完美的解決掉了，但是像性能，可靠性，可用性，可維護性等等受到了影響。

我們通過設(shè)計擺脫困境

bug27.png

但我們開始新的項目，我們深入思考如何避免引入Bug。
我們能夠一開始就在一個干凈整潔的辦公室，開始新的想法嗎？

軟件工程的三個基本流程非常重要：需求管理，配置管理，測試管理。
如果這些被深入理解并遵循執(zhí)行了，那么因為流程混亂導(dǎo)致的Bug將會很少，盡管因為項目風(fēng)險造成的缺陷還是有，但是因為糟糕的項目管理造成的Bug將會很少。

或者搬到離森林更遠的地方

bug28.png

我們用新的方式來編程。

嘗試用新的技術(shù)和方法來規(guī)避問題是一個雙刃劍的做法，比如，為了規(guī)避開發(fā)一個高風(fēng)險模塊，有時我們使用了第三方的中間件。這個可以完全規(guī)避開發(fā)中的問題，但是結(jié)果是引入了集成其他軟件帶來的風(fēng)險。

當(dāng)然，我們可以躲在里面，度過冬天

bug29.png

當(dāng)我們不知道該做些什么的時候，我們可以坐下來,等到一切都平息了下來

有時候最好的辦法是停下來，看看我們的全景圖。取代****靜待和編碼，還有揮之不去的擔(dān)憂,我們應(yīng)該花時間去理解需求和識別有用的技術(shù),工具,技巧,和過程。否則你會解決錯誤的問題。

有時一個項目本身是沒必要的，曾經(jīng)我?guī)椭粋€開發(fā)團隊理清了需求，里面有很多不符合的需求，最終項目取消了。這個項目一開始就不應(yīng)該啟動，如果他們在最開始就花時間了解了這些問題的話，項目就不會啟動了。

用煙熏走蜜蜂

bug30.png

我們用很多方法來處理Bug
我們可以把它嚇走，它們并沒有死，但是已經(jīng)被規(guī)避了。

有時候暴露越多的Bug是一個好事情因為我們能否感知他們的存在。
有時候你可能無法隔離或修復(fù)它們,并且會存在很長時間,但是你知道他們在什么地方。
比如，有些公司在產(chǎn)品發(fā)布之前會開展激動人心的活動叫做Bug追擊活動。員工周末加班利用****所有他們能想到的辦法來****發(fā)現(xiàn)產(chǎn)品缺陷；這些Bug很可能在產(chǎn)品發(fā)布前不會修復(fù)或者隔離開，但是公司知道這些Bug存在。
Noel Nyman 發(fā)明了一種測試叫做猴子測試，一種隨機測試技術(shù)，****探討了應(yīng)用程序隨機輸入,并用隨機輸入的方法找出Bug。這種測試一般是自動化執(zhí)行的，****它能找到生僻的Bug,測試人員可能從來不會發(fā)現(xiàn)。

擺脫了地毯

bug31.png

我們擺動一下，使得這些Bug被甩到其他地方。

給房子消毒

bug32.png

這個比較好的處理他們的方法。
我們修復(fù)它并且確保他們不會爬到其他地方。

蜘蛛利用網(wǎng)來捕獲Bug

bug33.png

我朋友James通過設(shè)置assertions執(zhí)行程序來捕獲Bug。

斷言測試方法不管程序是在執(zhí)行中處于什么狀態(tài)，比如，當(dāng)一個文件在被寫入之前是opened狀態(tài)，如果斷言是否定的判決，那么開發(fā)人員就會認(rèn)為是一個Bug。
在單元測試和早期的系統(tǒng)測試中，斷言是快速發(fā)現(xiàn)Bug的有效方法。但是，斷言并不能提供業(yè)務(wù)決策需要的信息。如果斷言跳出來了，程序也就停止運行了。在系統(tǒng)測試的后期中，這意味著直到Bug被修復(fù)我們才能繼續(xù)測試，如果這些Bug是一般的缺陷，那么時間將耗費在這個上面，因此斷言在這個階段應(yīng)該退出舞臺，斷言更不適合存在于要發(fā)布的一個商用版本中。

青蛙喜歡Bug

bug34.png

人們在工作中積極的關(guān)注Bug，我們熱衷于尋找Bug。

青蛙吃掉Bug

bug35.png

當(dāng)我們真正的找到Bug時，我們修復(fù)他們。

是否需要修復(fù)Bug取決于業(yè)務(wù)環(huán)境。就像青蛙的胃只能容納一定量的Bug，我們的開發(fā)團隊也沒有那么多的時間，精力，錢來修復(fù)所有的Bug。因此Bug的重要性和優(yōu)先級需要定義以便做投入產(chǎn)出比分析以便確定哪些Bug是值得修改的。

不修復(fù)Bug的成本是對用戶電腦的影響，大量投訴電話，公司的聲譽等等。一些深藏的缺陷的修復(fù)帶來的是 另一個Bug被植入的風(fēng)險或是發(fā)現(xiàn)更多的缺陷的機會丟失，開發(fā)時間和精力的耗費，降低可用性，性能等質(zhì)量目標(biāo)的機會。

青蛙只能吃那么點Bug

bug36.png

我們一次修復(fù)一個Bug，當(dāng)Bug很多的時候，我們分發(fā)給很多人來一起修復(fù)。

Bug想躲開青蛙

bug37.png

顯然的，當(dāng)我們修復(fù)Bug的時候，Bug嘗試避開我們。

Bug通過迷彩色來偽裝自己

bug38.png

有時候我們就算Bug近在眼前，卻不能找到Bug的解決方法。

有很多種Bug偽裝的方法。一種是普通模式，比如，在登陸之前拋出異常的Bug，在測試中，測試人員會直接登錄系統(tǒng)而忽視這個Bug，不知不覺就漏過去了。這種情況下測試人員沒有把這個當(dāng)成一個Bug，長此以往，就被忽略了。
另一種是一個Bug被另一個Bug給掩蓋了，比如，在一個數(shù)據(jù)庫系統(tǒng)中，返回了一個錯誤的查詢的Bug可以被查詢報告的Bug給掩蓋了。
還有一種是小Bug（或者是眾多小Bug）掩蓋了大的Bug，比如一個災(zāi)難性的錯誤被用戶接口的錯誤掩蓋，因為程序執(zhí)行中根本跑不到這段代碼。這也是為什么在bug修復(fù)之后需要重新測試的原因，他確保沒有其他的Bug還遺留在系統(tǒng)中

但是青蛙也可以

bug39.png

有時候我們也需要默默地等待Bug現(xiàn)身

一些bug可以很好被系統(tǒng)檢測到，對于這些Bug，比如BoundsChecker 安裝了就可以觀察到系統(tǒng)的行為，包括不適合的系統(tǒng)資源侵入使用和內(nèi)存泄露等。
還有一些Bug可以通過模糊測試來發(fā)現(xiàn)，為了找出瀏覽器兼容性的Bug，只要通過不同瀏覽器來測試就可以暴露這些Bug。

越多的青蛙可以處理越多的Bug

bug40.png

曾經(jīng)我們確信可以通過增加人手就可以找出和修復(fù)所有的Bug。

但是這么多的青蛙在同一個地方是一個大問題。

bug41.png

但是這無濟于事，因為這讓我們陷入混亂和困惑。

當(dāng)發(fā)現(xiàn)一個Bug的時候你應(yīng)該怎么辦

bug42.png

當(dāng)我們發(fā)現(xiàn)一個Bug，或者一籮筐的Bug，我們集合起來開個Bug評審會。

我是一個Bug：把它收集到一個罐子里，頂部有孔，我們研究它。

bug43.png

我們仔細的研究Bug。

我們怎么抓住Bug，他重要嗎？他的破壞性有多大？

bug44.png

我們觀察：我們是如何發(fā)現(xiàn)這個Bug的？是否需要現(xiàn)在就修復(fù)它？它的破壞性有多大？

有些Bug是我們的朋友

bug45.png

如果我們足夠幸運的話，我們可以把這些友好型的Bug放在程序里面很長一段時間。

有些Bug是只要我們遠離它就可以的。

bug46.png

如果我們用不同的方式來使用這個程序，我們可以避免這些Bug的觸發(fā)。

有時候我們可以提供更好的程序使用方式，而不是去修復(fù)Bug，在沒有時間回歸測試的情況下這一點特別對，因為修復(fù)一個Bug很可能帶來更多的Bug。

踩住螞蟻山尖可以避免螞蟻過來。

bug47.png

有時候是堵住洞迫使螞蟻出來。

然后一段時候后放開

bug48.png

讓問題轉(zhuǎn)移到另外的地方。

熱補丁并不能解決問題，第一次就應(yīng)該修復(fù)它。

和螞蟻共存并不見得就是很壞的情況。

bug49.png

在我們決定把Bug遺留的時候。

一般我們在桌上吃晚餐，而不是在地上。

bug50.png

我們必須清楚地知道程序?qū)绾伪皇褂谩?/p>

考慮程序?qū)⒈蝗绾问褂茫退闶峭粋€程序也可能被不同的人用不同的方式使用。一個Bug對一種用戶來說是致命的，對于另一類用戶來說是無關(guān)緊要的。

如果你必須處理它們。

bug50.png

當(dāng)我們決定處理一個bug

處理好它

bug51.png

我們很自豪的修復(fù)這個Bug，我們專業(yè)的，嚴(yán)格的檢查Bug已經(jīng)修復(fù)。

回歸測試經(jīng)常用于確保Bug已經(jīng)被修復(fù)了，并且沒有其他Bug被引入程序。

你想著你已經(jīng)完成了。

bug52.png

最重要的問題是我們要問自己我們是不是已經(jīng)完成了我們的工作。
是時候讓某些人使用的我們的程序了嗎？
能發(fā)布了嗎？
我們看著我們的已知的Bug。

我發(fā)現(xiàn)軟件工程師的一個基本問題：如何知道你已經(jīng)完成任務(wù)了。很多開發(fā)人員開始開發(fā)的時候并不知道這個問題的答案。

答案有好有壞，一種情況是開發(fā)人員覺得要下班回家的時候就是完成任務(wù)了，他們快速的完成任務(wù)就進入到開發(fā)的下個環(huán)節(jié)，我發(fā)現(xiàn)這樣的結(jié)果就是糟糕的質(zhì)量。如果我們獲取到需求管理，配置管理，測試管理的相關(guān)信息再來回答這個問題可能會更好。
回答好這個問題也許需要獲取到某種程序的代碼覆蓋率，靜態(tài)分析結(jié)果，質(zhì)量屬性情況如可用性，可靠性，可維護性等的信息。

但是為了問出這個基本的問題，準(zhǔn)出標(biāo)準(zhǔn)必須精確定義并且達成共識。比如，用單元測試來作為準(zhǔn)出條件，會問到"我已經(jīng)實現(xiàn)了這個單元/模塊的代碼了嗎？準(zhǔn)備好移交給其他人員了嗎" 如果單元測試的很模糊的，它很可能（大多數(shù)情況下就是）是不可控的準(zhǔn)出條件，因為開發(fā)人員沒有正確理解這個單元代碼意圖。這種情況下，當(dāng)開發(fā)人員使用單元測試的結(jié)果來決定這個單元的代碼是否開發(fā)完成，他是基于一個錯誤的假定的。

這也就是我們需要在項目或者一個特定任務(wù)中要有共同的語言，有套共同遵循的規(guī)則，比如準(zhǔn)入準(zhǔn)出條件，通過這種方式，項目中的人都知道在項目中扮演什么角色，應(yīng)該遵循哪些規(guī)則。

當(dāng)有一個Bug遺留時

bug53.png

我們問自己它的重要性如何，它對系統(tǒng)影響有多大。
同樣Bug也在看著我們。

Bug確定是可以和我們共存的。

bug54.png

當(dāng)我們確定遺留的Bug可以和我們共存的時候，我們確定我們的工作已經(jīng)完成了

至少到現(xiàn)在為止

bug55.png

至少到現(xiàn)在為止
我們停止測試并且可以洗洗睡了。
晚安！

bug56.png