8 . 2 軟件缺陷的生命週期
與生物學的昆蟲不同，軟件的缺陷要經歷一組非常嚴格 的狀態（參見圖8-2）。在VSTS中，缺陷所允許的缺省的狀態和轉換依賴於你爲項目所選擇的過程模板。所選過程的那組規則決定了：選擇可允許的狀態；定 時、授權哪些用戶組可以將缺陷推進到下一個狀態；允許轉換的原因。如果有權限的話，你可以進一步定製這些規則，從而使它們與團隊的工作流相匹配。
圖8-2此狀態圖是用於CMMI過程改進的MSF中的軟件缺陷的生命週期
在VSTS 中
·在用於CMMI過程改進的MSF中，缺陷有4個狀態，開始狀態是已提出狀態。在變爲活動狀態之前，需要有個接受操作。
·在用於敏捷軟件開發的MSF中，缺陷只有3個狀態，開始狀態是活動狀態。
任何人都可以提出缺陷，也就是說，請求把它納入待修復的隊列。
項目經理可以激活一個缺陷，然後把它分配給一個開發人員。
在研究或修復了代碼後，開發人員會在下一次簽入時把缺陷標記爲已解決狀態（參見圖8-3）。不允許開發人員直接關閉缺陷。
圖8-3 在VSTS中，很少在check In對話框中核對缺陷，開發人員把將交付的變更集與待修復的缺陷相關聯。這種關聯是永久的，用於填寫構建報告和度量元倉庫
當相應的源代碼被簽入時，簽入過程自動解決了缺陷。
測試人員可以在相應的查詢中看到已修復的缺陷。只有在測試人員確認缺陷通過了測試從而證明它已被修復之後，才能由測試人員關閉缺陷（當然，如果測試失敗了，測試人員就會重新激活缺陷）。
實際上，工作流可能更簡單也可能更復雜。例如，在敏 捷MSF中，不要求在激活之前必須有個已提出狀態，也不強制使用不同的權限，反而要依靠信任。反過來，一些過程，尤其是在後期迭代中，在代碼被評審之前， 不允許簽入代碼。工作項可以通過一個新狀態或者一個單獨的字段來強制這一規則，簽入政策可以強制這一工作流。
無論這些規則是什麼，它們都是你當前項目的過程的可觸摸的形式。
8 . 2 . 1 報告缺陷就像寫新聞
凱列班有個故事講的是他最喜歡的缺陷。故事大概是這樣的：
我 一個月前在實驗室中發現了這個缺陷，然後報告了它。沒有人注意到；所以在優先分配中，他們把它標記爲被“推遲”。上個星期我們最大的客戶也發現了它，突然 之間，這個缺陷就引發了一場危機。現在，我們需要交付一個維護版本，這就意味着我要整個週末都呆在實驗室裏檢查所做的修復。爲什麼他們在我第一次報告的時 候沒注意到這個缺陷呢？
真正的原因是什麼呢？最常見的原因就是缺陷報告寫得 不清楚，沒有把影響充分傳達給優先分配小組，所以所報告的缺陷被關閉了。凱列班的經理普洛斯彼羅對於凱列班的故事則有着不同的看法：“爲什麼凱列班不能把 他的缺陷報告寫得清楚些，足以讓團隊能夠對它們有所行動呢？”（因此，和前面一樣，普洛斯彼羅在他的下一個項目中沒有選擇凱列班。）
從凱列班的經驗中得出的教訓可以用Kaner、Bach和Pettichord的名言來總結：
你的主張驅動你所報告的缺陷的修復
你所寫的任何一個缺陷報告都是一個呼喚修復此缺陷的宣傳文檔。
有的缺陷永遠也不會被修復。你的責任不是去保證所有的缺陷都被修復了。你的責任是以一種能讓讀者理解問題全部影響的方式精確地報告缺陷。
你研究得好不好，報告寫得好不好，這些通常都會對缺陷修復的概率有着很重大的影響。
詳細描寫缺陷就像是寫新聞報道（或者網頁）。它是新聞學。標題就像是頭條新聞，你應該希望大多數讀者從來也不看“下面的內容”。新聞記者的6個基本問題：什麼、哪裏、怎麼、誰、爲什麼和什麼時候，需要在一兩句摘要中都能覆蓋到。
瞭解你的讀者
你的缺陷報告的第一個讀者就是優先分配小組（優先分配已經在第4章中討論過）。他們會看到一個看起來像圖8-4那樣的查詢。
圖8-4要持續關注讀者在優先分配時看到的是什麼。讀者所看到的並不是所有的細節，他們僅能看到那些適合查詢結果列表的內容。你應當根據缺陷的顯示格式編寫缺陷
優先分配小組中包括了項目中最忙的人。通常他們都只 花不到1分鐘的時間來評審每個缺陷（每日進行優先分配的一個重要原因就是爲了保持列表的長度，從而使每個工作項都能獲得它們所應獲得的關注）。在那個時 候，你的缺陷報告的命運也就註定了和凱列班的缺陷報告的命運一樣。如果凱列班能夠在缺陷報告的質量上再多花一點時間的話，他的工作價值（和他的績效打分） 就能提高很多。
從歷史中學習
閱讀缺陷報告，尤其是在它們已經被優先分配之後閱讀它們，是向你的項目和讀者學習的一個好辦法。優先分配的審計會議是另一個方法，你瞭解到在實踐中什麼對於涉衆是重要的。下面是一些在使用你的缺陷數據庫時的提示：
·執行你感興趣的缺陷的重現步驟。這是一個很好的方法，你能夠從中學習到受測軟件的一些更有趣的情形（還能學習如何編寫清晰的步驟）。
·閱讀註釋，注意其他團隊成員是如何回答缺陷報告的，從中學習他們認爲什麼重要以及如何改進你的報告風格。
·研究已關閉的缺陷報告，注意從缺陷報告的方式來看，哪些缺陷被修復了，哪些缺陷沒被關閉，基於它們被報告的方法。如果希望你的缺陷也被修復，那麼就要像歷史上的那些得到修復的缺陷那樣報告缺陷。
·如果你在做一個已有的解決方案，應該閱讀技術支持日誌，查看其中記載的應檢查的錯誤和支持你的缺陷的故事。
SOAP ：一個來自醫學的類推
軟件領域借用了醫療實踐中的“優先分配”這一術語，因此看一下它用於醫療時的情景也是合適的。醫學人士掌握了一個描述臨牀報告的首字母縮寫SOAP（它與Web服務無關）。這是從馬里蘭大學藥學學校的醫學課程提綱中的摘錄：
對於每個病人……護理問題（一個或多個），應寫進展註釋（以SOAP格式），並且應包括以下內容（參見圖8-5）。
圖8-5 在思考表格和健康交談歷史的字段時，SOAP記憶法是個有用的方法。標題（Title）和症狀（Symptom）是主觀信息（S）；發現的構建版本 (Found In /[Build/])、發現的環境（Found-in Environment）和重現步驟（Steps to Reproduce）等字段是客觀信息（O）；優先級(Priority)、嚴重程度(Severity)、區域路徑(Area Path)和根本原因(Root Cause)是評估（A），而迭代(Iteration)和修復(Fix)是計劃（P）
主觀（Subjective ）信息： 支持所確定的問題的主觀信息；
客觀(Objective) 信息： 支持所確定的問題的客觀信息；
評估（Assessment ）： 對於問題的評估，包括病源、嚴重性、當前治療的高效性/毒性、治療學上替代方案的列表、每個方案（治療學上和經濟上）的優點和缺點的討論以及推薦的根本原因；
計劃（Plan ）： 對所確定的問題進行管理的計劃，包括實現和後續對問題的監控和治療學響應的特定大綱。
好工匠會觀察其他好工匠(包括其他學科的工匠)做什麼。在你報告缺陷和評審缺陷報告時，SOAP是一個應當使用的好模型。讓我們看一看VSTS在用於CMMI過程改進的MSF中所提供的標準缺陷報告表單。
8 . 2 . 2 主觀數據
對報告的讀者而言,最重要的問題是：對用戶的影響是什麼？大多數時候，回答這一問題，需要進行一番思考。問自己一些與下面這些問題相類似的問題：
·當客戶看到這一問題時，他會對產品支持人員說什麼？
·根據客戶對其他軟件（包括競爭者的產品）的體驗，這次他們將有什麼樣的期待？
·如果銷售代表或培訓師在演示時遇到了這種情況的話，會說什麼呢？
·這一缺陷會對應用場景產生什麼樣的影響？
·這一缺陷會對下游環節產生什麼樣的影響？
·會涉及多少用戶，頻繁程度如何？
·這是一個孤立的事件嗎？
·這裏有安全性的風險嗎？
·其他服務質量會受到影響嗎？
首先要編寫這個故事。你對這些問題的答案將會決定應花多少時間來研究這一缺陷，又會決定應爲此報告收集什麼樣的數據。
標題問題
正如你在圖8-4中所看到的，標題通常是讀者所看到的唯一信息。如果標題不清晰，當被截斷到適合字段寬度時，信息的剩餘部分可能永遠也不會讀到。
描述困惑
關於缺陷的永久的下一級信息是描述。變更歷史可能會很長，但是描述應當是關於缺陷的、簡潔的細節。
每個缺陷一個報告
如果你有2個缺陷，就應該寫2個報告。保持每個觀察到的缺陷都在它自己的報告中，這會讓所有報告都更易於理解。
8 . 2 . 3 客觀數據
在編寫了關於此缺陷的主觀數據之後（參見圖8-6），就到了收集客觀數據的時候了。
圖8-6這裏所說的缺陷工作項類型，來自於用於CMMI過程改進的MSF，它捕獲了用戶在查詢、跟蹤和分析缺陷時所需要的所有信息
服務質量
要清楚你所報告的問題的類型——服務質量受到了什麼影響。
相關特性或代碼
如果你能把缺陷與你所測試的特定特性或受測源代碼的特定區域關聯起來，那就這麼做。
重現測試
如果你有一個測試來重現這個缺陷，那就標識出它。
附件
你可以附加什麼樣的數據到缺陷報告上，從而演示這一缺陷發生在怎麼樣的條件下？如果適用的話，所有這些都會有用的：
·屏幕快照
·數據文件
·配置文件
·跟蹤文件
·服務器日誌
·Dr.Watson日誌
重現步驟
你如何在最小的設置中以最少的步驟來重現這一缺陷？在開發者針對缺陷的工作中，80%的工作量往往就在於重現步驟——你能把缺陷發生過程簡化到什麼程度？任何不必要的東西顯然都是浪費。要確保重現步驟精確和清晰。在提交缺陷之前，要檢查它們。
前置條件
重現這一錯誤，比如加載一個特定的數據庫，是否需要特殊的設置？如果問題能夠通過產品數據或客戶數據演示出來，這就特別有說服力。
8 . 2 . 4 評估數據
在缺陷的生命週期中，評估會發生多次變化，因爲人們需要精細化診斷和觀察、調試源代碼、努力修復和測試修復、研究相關的缺陷等等。你的任務就是要保證缺陷歷史的精確性和全面性，因爲對於缺陷及其條件你所知甚多。
在初始報告中，你能夠做一些評估，而更多的評估會隨着缺陷的歷史和會話而演進。
它是不是重複的
應花一點時間查詢整個數據庫，從而確定這到底是關於已發現缺陷的更多的信息呢，還是一個新發現的缺陷。但是不要過分沉迷。稍後別人將你報告的缺陷標爲重複，這也很容易。顯然，如果你發現了關於已有的缺陷的更多信息，就應該把發現更新到該缺陷報告中。
它的一般性如何
去除你的邊際情形（corner case）的邊際性。通常，你會使用極限數值、不常見的配置或者長輸入序列來發現缺陷。理解缺陷重要性的根本就是要知道缺陷發生所必須的特殊性條件或一般性條件。這裏是一些提示：
·使用不同的數據。 如果你是用一組特定的輸入值發現的缺陷，那麼就嘗試一下不同的輸入值。尤其是要嘗試不同的等價類。缺陷的表現對特定值或特定等價類的依賴程度如何？
·使用不同的配置。 如果你是在硬件和軟件構件的一個特殊配置下發現的缺陷，那麼應該在一組非常不同的機器上試一下。
·使用不同的流。 如果缺陷出現在一個特殊的操作序列（尤其是很長的序列）下，那麼看看是不是有其他（最好是更短的）路徑可以得到同樣的結果。
·尋找可疑的交互。 如果有的事情好像是一個奇怪的副作用，但你又不確定，要繼續刺探。例如，在你使用了一個程序之後，另一個可能突然變慢了。可能它們依賴一些相同的部件、數據或者OS服務。
·還有更多的嗎？ 猜測類似的缺陷還會潛伏在哪裏。尋找它們。
它的嚴重性如何
當你第一次發現一個缺陷時，會有一種巨大的誘惑讓你感到滿意並要報告它。實際上，可能還有很多更嚴重的問題。注意初始的症狀並繼續使用受測軟件。你可能會發現沒有被妥善處理的錯誤路徑和異常，以及未預料到的交互和其他會給用戶（或技術支持人員）造成困惑的問題。
8 . 2 . 5 計劃
在初始報告中，你手中主要的計劃工具是優先排序和歸屬關係。根據你的不同過程，這些可能只能由優先分配小組來設定，或者在不太正規的組織中，也可能由提交者直接填報。處理優先排序的方式應當與它在項目管理中所採用的方式相同。
迭代
仔細考慮計劃中的迭代。在早期迭代中，所提出的缺陷往往都集中在那些現在還不能工作的功能上。優先分配的目的之一正是從開發人員的直接隊列中清除這種噪音。