1947 年，發(fā)現(xiàn)了第一個(gè)計(jì)算機(jī) bug —— 被困在計(jì)算機(jī)繼電器中的飛蛾。

要是所有的 bug 都能如此簡(jiǎn)單地發(fā)現(xiàn)就好了。隨著軟件變得越來越復(fù)雜，測(cè)試和調(diào)試的過程也變得更加復(fù)雜。如今，軟件 bug 的生命周期可能會(huì)很長(zhǎng)，盡管正確的技術(shù)和業(yè)務(wù)流程可能會(huì)有所幫助。對(duì)于開源軟件，開發(fā)人員使用嚴(yán)格的工單服務(wù)和協(xié)作來查找和解決 bug。

確認(rèn)計(jì)算機(jī) bug

在測(cè)試過程中，發(fā)現(xiàn)的 bug 會(huì)報(bào)告給開發(fā)團(tuán)隊(duì)。質(zhì)量保證測(cè)試人員盡可能詳細(xì)地描述 bug ，報(bào)告他們的系統(tǒng)狀態(tài)、他們正在進(jìn)行的過程以及 bug 是如何表現(xiàn)出來的。

盡管如此，一些 bug 從未得到確認(rèn)；它們可能會(huì)在測(cè)試中報(bào)告，但永遠(yuǎn)無法在可控環(huán)境中重現(xiàn)。在這種情況下，它們可能得不到解決，而是被關(guān)閉。

有些計(jì)算機(jī) bug 可能很難確認(rèn)，因?yàn)槭褂玫钠脚_(tái)種類繁多，用戶行為也非常多。有些 bug 只是間歇性地或在非常特殊的情況下發(fā)生的，而另一些 bug 可能會(huì)出現(xiàn)在隨機(jī)的情況下。

許多人使用開源軟件并與之交互，許多 bug 和問題可能是不可重復(fù)的，或者可能沒有得到充分的描述。不過，由于每個(gè)用戶和開發(fā)人員也都扮演質(zhì)量保證測(cè)試人員的角色，至少在一定程度上，bug 還是很有可能會(huì)發(fā)現(xiàn)的。

確認(rèn) bug 后，修復(fù)工作就開始了。

分配要修復(fù)的 bug

已確認(rèn)的 bug 被分配給負(fù)責(zé)解決的開發(fā)人員或開發(fā)團(tuán)隊(duì)。在此階段，需要重現(xiàn) bug，發(fā)現(xiàn)問題，并修復(fù)相關(guān)代碼。如果 bug 的優(yōu)先級(jí)較低，開發(fā)人員可以將此 bug 分類為稍后要修復(fù)的問題，也可以在該 bug 具有高優(yōu)先級(jí)的情況下直接指派某人修復(fù)。無論哪種方式，都會(huì)在開發(fā)過程中打開一個(gè)工單，并且 bug 將成為已知的問題。

在開源解決方案中，開發(fā)人員可以進(jìn)行選擇他們想要解決的 bug，要么選擇他們最熟悉的程序區(qū)域，要么從優(yōu)先級(jí)最高的的開始。綜合解決方案，如 GitHub 使得多個(gè)開發(fā)人員能夠輕松地著手解決，而不會(huì)干擾彼此的工作。

當(dāng)將 bug 設(shè)置為需要修復(fù)時(shí)，bug 報(bào)告者還可以為該 bug 選擇優(yōu)先級(jí)。主要的 bug 可能具有較高的優(yōu)先級(jí)，而僅與外觀相關(guān)的 bug 可能具有較低的級(jí)別。優(yōu)先級(jí)確定開發(fā)團(tuán)隊(duì)解決這些問題的方式和時(shí)間。無論哪種方式，所有的 bug 都需要先解決，然后才能認(rèn)為產(chǎn)品已完成。在這方面，適當(dāng)?shù)幕厮莸絻?yōu)先級(jí)高的需求也會(huì)很有幫助。

解決 bug

一旦修復(fù)了 bug ，通常會(huì)將其作為已解決的 bug 發(fā)送回質(zhì)量保證測(cè)試人員。然后，質(zhì)量保證測(cè)試人員再次將產(chǎn)品置于其工作中，以重現(xiàn) bug。如果無法重現(xiàn) bug ，質(zhì)量保證測(cè)驗(yàn)人員將假定它已得到適當(dāng)解決。

在開源情況下，任何更改都會(huì)被分發(fā)，通常是作為正在測(cè)試的暫定版本。此測(cè)試版本分發(fā)給用戶，用戶再次履行質(zhì)量保證測(cè)試人員的職責(zé)并測(cè)試產(chǎn)品。

如果 bug 再次出現(xiàn)，問題將被發(fā)送回開發(fā)團(tuán)隊(duì)。在此階段，該 bug 將重新觸發(fā)，開發(fā)團(tuán)隊(duì)有責(zé)任重復(fù)解決該 bug 的循環(huán)。這種情況可能會(huì)發(fā)生多次，尤其是在 bug 不可預(yù)知或間歇性發(fā)生的情況下。眾所周知，間歇性的 bug 很難解決。

如果該 bug 不再出現(xiàn)，則該問題將被標(biāo)記為已解決。在某些情況下，最初的 bug 得到了解決，但由于所做的更改，會(huì)出現(xiàn)其他 bug。發(fā)生這種情況時(shí)，可能需要新的 bug 報(bào)告，然后重新開始該過程。

關(guān)閉 bug

在處理、識(shí)別和解決 bug 后，該 bug 將被關(guān)閉，開發(fā)人員可以轉(zhuǎn)到軟件開發(fā)和測(cè)試的其他階段。如果始終找不到 bug ，或者開發(fā)人員無法重現(xiàn) bug ，則該 bug 也將被關(guān)閉 —— 無論哪種方式，都將開始開發(fā)和測(cè)試的下一階段。

在測(cè)試版本中對(duì)解決方案所做的任何更改都將滾動(dòng)到產(chǎn)品的下一個(gè)版本中。如果 bug 是嚴(yán)重的，則在下一個(gè)版本發(fā)布之前，可能會(huì)為當(dāng)前用戶提供修補(bǔ)程序或修補(bǔ)程序。這在安全問題中很常見。

軟件 bug 可能很難找到，但通過遵循過程，開發(fā)人員可以使開發(fā)更快、更容易、更一致。質(zhì)量保證是這一過程的重要組成部分，因?yàn)橘|(zhì)量保證測(cè)試人員必須發(fā)現(xiàn)和識(shí)別 bug ，并幫助開發(fā)人員重現(xiàn)這些 bug 。在 bug 不再發(fā)生之前，無法關(guān)閉和解決 bug。

開源的解決方案分散了質(zhì)量保證測(cè)試、開發(fā)和緩解的負(fù)擔(dān)，這往往導(dǎo)致 bug 被更快、更全面地發(fā)現(xiàn)和緩解。但是，由于開源技術(shù)的性質(zhì)，此過程的速度和準(zhǔn)確性通常取決于解決方案的受歡迎程度及其維護(hù)和開發(fā)團(tuán)隊(duì)的敬業(yè)精神。

Rich Butkevic 是一個(gè) PMP 項(xiàng)目經(jīng)理認(rèn)證,，敏捷開發(fā)框架認(rèn)證（certified scrum master） 并且 維護(hù) Project Zendo，這是供項(xiàng)目管理專業(yè)人員去發(fā)現(xiàn)、簡(jiǎn)化和改進(jìn)其項(xiàng)目成果策略的網(wǎng)站?？梢栽?Richbutkevic.com 或者使用 LinkedIn 與 Rich 聯(lián)系。