軟件bug的確認(rèn)和解決

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

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

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

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

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

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

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

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

分配要修復(fù)的 bug

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

在開(kāi)源解決方案中，開(kāi)發(fā)人員可以進(jìn)行選擇他們想要解決的 bug，要么選擇他們最熟悉的程序區(qū)域，要么從優(yōu)先級(jí)最高的的開(kāi)始。綜合解決方案，如 GitHub 使得多個(gè)開(kāi)發(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í)確定開(kāi)發(fā)團(tuán)隊(duì)解決這些問(wèn)題的方式和時(shí)間。無(wú)論哪種方式，所有的 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。如果無(wú)法重現(xiàn) bug ，質(zhì)量保證測(cè)驗(yàn)人員將假定它已得到適當(dāng)解決。

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

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

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

關(guān)閉 bug

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

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

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

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

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