測試架構師：6 版本測試策略和產品質量評估

測試架構師：6 版本測試策略和產品質量評估

2016-09-26

 

目錄

1　開始
2　第一個版本測試策略
  2.1　測試範圍以及和計劃相比的誤差
  2.2　本版本的測試目標
  2.3　須要重點關注的內容
  2.4　測試用例的選擇
  2.5　測試執行順序
  2.6　試探性的測試策略——須要你們分工合做的地方
  2.7　接收測試策略
  2.8　回顧
3　跟蹤測試執行
  3.1　跟蹤測試用例執行狀況
  3.2　每日缺陷跟蹤
  3.3　調整測試策略
4　版本質量評估
  4.1　使用軟件產品質量評估模型來進行質量評估
  4.2　版本質量評估中的缺陷分析
  4.3　調整測試策略
  4.4　創建特性版本質量檔案
5　後面的版本測試策略
  5.1　迴歸測試策略
  5.2　探索式測試策略
6　階段質量評估（包括髮布質量評估）
  6.1　階段質量評估項目
  6.2　非測試用例發現缺陷的緣由分析
  6.3　組合缺陷分析
  6.4　遺留缺陷分析
  6.5　臨近發佈時的缺陷修復策略
  6.6　非必然重現bug的處理
  6.7　總結

 

從如今開始，咱們的項目開始進入到測試執行階段，咱們的軟件測試架構師也要開始進入到測試執行策略的工做中了，如圖1所示。

圖1　制定測試執行策略

1　開始

---

 返回

此時軟件測試架構師手上應該有一份「版本計劃」和「測試計劃」（分別由開發人員和測試人員輸出）。

具體來講，此時開發人員提供的「版本計劃」應該是針對集成開發階段的功能集成計劃，包括劃分了幾個build、每一個build計劃合入哪些功能，以及每一個build須要開發集成的時間。

「測試計劃」是一個在集成測試、系統測試和驗收測試分別須要測試多少個版本，以及每一個版本包含的測試時間的計劃，見表8-1。

表1　測試計劃表

「測試計劃」中也有簡單的測試策略，主要用於標記每一個版本的主要測試目標。

咱們將「版本計劃」和「測試計劃」合併在一塊兒，就獲得了咱們的研發計劃全景圖，如圖2所示。

圖2　研發計劃全景圖

總的來講，軟件測試架構師在測試階段的工做，其實就是圍繞圖3所示的幾個活動循環展開的。

圖3　軟件測試架構師在測試階段的工做

而且在每一個測試分層結束的時候，軟件測試架構師須要評估這個測試層級的質量目標是否達到，是否能夠進入下一個層級的測試。在項目結束的時候，評估產品可否發佈。

2　第一個版本測試策略

---

 返回

如今軟件測試架構師要開始制定第一個版本測試策略了。因爲測試策略是用來指導該如何進行測試執行的，測試策略的內容會很細、很具體。可是咱們依然能夠按照四步測試策略制定法中目標—風險—流程—順序的思路來制定版本測試策略。

2.1　測試範圍以及和計劃相比的誤差

在版本測試策略中，軟件測試架構師首先要明確的就是測試範圍。須要注意的是，這裏的測試範圍，不是指開發計劃要合入哪些功能，而是指開發可以真正提交，而且測試可測的功能。

咱們仍是以俄羅斯方塊心項目的build1爲例，如圖4所示

圖4　俄羅斯方塊心項目的build1

假設在俄羅斯方塊心項目的build1中，軟件測試架構師經過評估，接收進行測試，他能夠在版本測試策略中按圖5所示這樣描述版本的測試範圍和誤差。

圖5　版本的測試範圍和誤差

2.2　本版本的測試目標

每個版本測試策略都須要描述版本的測試目標。

對和進行功能測試，發現單運行正常值和邊界值方面的缺陷。

對（本輪測試實際提交的是）只進行基本功能的驗證，可以保證與和的集成測試就能夠。
·對進行測試，發現、和在多運行方面的缺陷。

以測試對象–測試方法–測試結果這樣的方式來描述測試目標的好處是：強調了這個版本測試的要求，比數字指標更易於被測試團隊理解和執行。

2.3　須要重點關注的內容

軟件測試架構師須要在每一個版本測試策略中註明哪些是須要你們重點關注的內容。

• 首先，在版本測試策略中，須要對提交的功能進行分析，提出須要測試團隊重點關注的內容。
• 其次，須要肯定本版本須要測試的功能的優先級表。

咱們在制定整體測試策略的時候，已經根據質量目標和風險爲產品的全部功能特性肯定了測試優先級。可是到了實際測試執行的時候，特別是在功能集成開發階段，一些功能特性可能會被開發人員分爲幾回提交，這就須要軟件測試架構師根據版本的實際狀況更新功能特性的優先級，並在版本測試策略中向測試團隊說明。

例如，在「俄羅斯方塊心」項目的整體測試策略中功能特性的優先級列表見表2（爲了便於後文敘述，我在列表中加入了「計劃提交版本」列）。

表2　功能特性的優先級列表

在版本測試策略中，因爲build1中的功能，實際提交的是，咱們在build1中僅對它進行基本功能的驗證測試，所以在build1中咱們能夠考慮下降的測試優先級。

2.4　測試用例的選擇

咱們把測試用例分等級（level1~level？4）後，選擇測試用例就變得簡單多了。軟件測試架構師能夠根據版本的測試範圍和測試目標，制定出須要選擇哪些測試用例的策略，如表3所示。

表3　選擇測試用例

2.5　測試執行順序

不一樣的被測對象，在同一個版本中的測試執行順序可能會不一樣。這就要求軟件測試架構師，對不一樣的被測對象當前的質量狀況，有比較好的把握能力，而後根據質量狀況來肯定不一樣的測試執行順序，能夠遵循以下原則：

• 質量狀況越好，就能夠考慮將更多的測試方法組合起來執行。
• 對剛提交的功能，在質量狀況很差或質量狀況不明的狀況下，不建議使用組合測試方法進行測試。

來看一個相關的示例，見表4。

表4　肯定測試執行順序示例

除此以外，在版本執行策略中再強調一下階段測試策略中的測試執行策略也是有必要的：

• 先執行高優先級特性的測試用例，再執行中、低優先級的測試用例。
• 先執行復雜的、難的測試用例，再執行簡單的測試用例。

2.6　試探性的測試策略——須要你們分工合做的地方

2.7　接收測試策略

「接收測試」是指開發人員將版本轉給測試人員時（圖6），測試人員先對這個版本進行一次測試，確認版本沒有阻塞測試的問題，可以按照測試策略完成測試。

圖6 版本轉給測試人員

接收測試有兩種結果：「經過」和「不經過」。判斷階段測試是否經過的標準只有一個，就是「是否會阻塞後面的測試」。

• 接收測試「經過」意味着測試可以繼續進行，
• 而接收測試「不經過」，並不是意味着必定不能繼續測試——咱們須要考慮是否有規避問題的方法。若是存在規避方法，仍是建議繼續測試。

具體如圖7所示。

圖7　接收測試示意圖

2.8　回顧

到目前爲止，咱們已完成了第一個版本測試策略的制定。讓咱們一塊兒來回顧一下，在版本測試策略中須要考慮的主要內容：

• 測試範圍和計劃相比的誤差。
• 本版本的測試目標。
• 須要重點關注的內容。
• 測試用例的選擇。
• 測試執行順序。
• 試探性的測試策略。
• 接收測試策略。

3　跟蹤測試執行

---

 返回

軟件測試架構師跟蹤測試執行的目的有3個：

• 確保測試團隊是按照測試策略來執行測試的。
• 實時關注缺陷，經過缺陷分析來確認測試策略是否合適，是否須要調整。
• 關注項目中的實時風險，基於風險來調整測試策略。

3.1　跟蹤測試用例執行狀況

在版本測試時，不少人都會關注測試用例的執行狀況，如測試經理、項目經理等。測試用例的進度、測試用例的結果（包括測試用例執行的經過率、失敗率等）是他們主要關注的內容，咱們可使用表5~表6所示來收集和展現這些信息。

表5　按照每一個版本統計的測試用例的執行狀況表

表6 當前項目的總體進度表

這些表中的信息對軟件測試架構師而言一樣重要。要確保測試團隊是按照測試策略來執行測試的，須要保證如下三點：

• 測試內容和測試策略中肯定的範圍、深度和廣度一致。
• 測試執行的順序和測試策略一致。
• 計劃測試的內容可以被順利執行。

只要咱們選擇的測試用例和測試策略是一致的，就能保證第一點。對軟件測試架構師來講，須要在測試執行時保證第二點和第三點。顯然這方面的信息並不能從表中的內容來直接得到，還須要軟件測試架構師對錶中的內容再進行一些分析和加工。

1.測試團隊的測試執行順序是否和測試策略相符

軟件測試架構師能夠經過按照每一個版本統計的測試用例的執行狀況表和測試用例執行狀況詳表來分析測試團隊的測試執行順序是否和測試策略相符。

1）測試團隊是否按照特性的優先級順序來執行測試用例

2）測試團隊是否按照測試策略中的測試方法、測試順序來執行測試用例

2.被阻塞的測試用例

3.2　每日缺陷跟蹤

「缺陷」是測試的結果。對軟件測試架構師而言，天天跟蹤缺陷很是重要——由於他須要實時關注測試中的這幾個問題：

• 缺陷的趨勢是否正常？
• 是否存在由於缺陷修改引入的缺陷？
• 在本版本中必須解決哪些缺陷？
• 在本版本中須要解決哪些缺陷？

1.哪些缺陷必須在本版本中解決

在版本測試中，判斷「哪些缺陷必須在本版本中解決」的標準只有一個，就是「會不會對後續的測試形成阻塞」。

2.哪些缺陷須要在本版本中解決

圖8　幾個概念之間的關係

換句話說，除了那些在版本中必須解決的缺陷外，咱們還須要根據缺陷的嚴重性和缺陷的修改狀況來選擇一些缺陷，在本版本中優先解決：

• 缺陷的改動越大，越須要儘早解決。
• 若是缺陷涉及需求、方案、設計，須要儘早解決。
• 優先解決缺陷嚴重程度爲「致命」和「嚴重」的缺陷。

3.缺陷趨勢是否正常

1）預估「拐點」會在哪一個版本出現

圖9 預估缺陷趨勢圖

分析：

• 在集成開發和測試階段，build1~build4都會有新的功能合入，並且隨着功能的不斷集成，系統愈來愈完整和複雜，測試方法也會從單功能測試，逐步轉換爲單功能+多功能測試，因此在build1~build4階段，不該該出現拐點。
• build5是一個迴歸測試版本，此時沒有合入新的功能，測試方法和build1~build4相比，也沒有發生變化，因此集成開發和測試階段的拐點（圖9中的「拐點1」）應該出如今build5比較合適。
• 在系統測試階段，ST1雖然也是功能測試，被測對象也沒有發生變化，可是ST1在測試執行順序、功能測試的複雜度上都會與集成開發和測試階段有所不一樣，因此進入ST1階段應該會比較快速地出現一個拐點（圖9中的「拐點2」），開始又能大量發現系統的問題。
• ST2的測試方法和ST1的測試方法不一樣，不該該出現拐點。
• ST3和ST4都是探索式測試和迴歸測試，下一個拐點（圖9中的「拐點3」）應該出如今ST3後期或者ST4初期比較合適。
• 進入驗收測試階段後，因爲AT1的測試方法發生了變化，應該很快會出現一個新拐點（圖9中的「拐點4」），可是這種缺陷上升的趨勢不該該持續過久（畢竟咱們已經通過了大量的測試，若是在驗收測試階段還能發現大量的問題，是很是不符合預期的），在AT1後期或在AT2前期就應該出現拐點（圖9中的「拐點5」）。

2）判斷當前版本的缺陷趨勢是否正常

4.是否存在缺陷修改引入缺陷的問題

3.3　調整測試策略

圖10 調整測試策略的總體思路

4　版本質量評估

---

 返回

4.1　使用軟件產品質量評估模型來進行質量評估

但因爲版本質量評估的評估對象是版本，咱們的評估方法和關注重點仍是會與階段的質量評估或發佈時的質量評估有所不一樣。

圖11 複製質量評估模型

1.在版本質量評估中記錄需求和實現的誤差

圖12　功能有誤差的狀況

咱們每每會發現，除了這些在測試以前就能發現的誤差以外，還有不少誤差是在測試過程才能逐漸被發現的，如：

（1）需求理解方的錯誤致使功能實現上的錯誤。如圖13所示。

圖13 功能實現錯誤

（2）由於種種緣由，該功能對應的需求並無提交完，如圖14所示。

圖14　需求未提交完

不管是上述哪一種狀況，這些問題都只有在測試過程當中纔會被逐漸發現。這些問題在測試過程當作bug記錄。這些缺陷每每因爲不是當前版最緊急、必須解決的缺陷，而很容易被擱置下來，而後就被你們遺忘了。直到這些問題變得嚴重影響後續功能的集成，或是到了產品要發佈的時候，咱們才發現一些看起來「細枝末節」的功能模塊尚未被開發。

所以，對軟件測試架構師而言，在版本質量評估時對這類問題再進行梳理是很是有必要的。咱們就只須要將這類問題從bug報告中篩選出來，並按期跟蹤這些bug，關注它們的修復計劃就能夠了。對那些開發人員和測試人員爭議較大、須要SE再進行澄清的需求，咱們也須要進行記錄（至少須要記錄當前的進展），以便咱們在結論肯定後，第一時間知道該如何進行下一步的處理。
總的來講，在版本質量評估時，需求實現狀況應該包含的內容如圖15所示。

圖15 需求實現狀況包含的內容

舉例：「俄羅斯方塊心」項目build1版本質量評估示例

在「俄羅斯方塊心」build1中，需求和功能實現的誤差爲：

（1）功能在build1提交時爲,完整的功能將在build2中提交。
（2）功能的需求未徹底開發完，詳見bug0003二、bug00035。
（3）開發人員和測試人員對的需求實現存在爭議（開發人員實際開發的功能爲），通過SE對此功能需求進行再次澄清後，發現是開發人員在需求理解上存在一些誤解，須要在build2中更新此功能，詳見bug00047。

2.在版本質量評估中進行測試過程評估

實際上，咱們在跟蹤測試執行的過程當中，已經對測試過程，包括測試用例、測試方法和測試投入進行了跟蹤分析，在版本質量評估時，咱們能夠對版本的「測試過程」再進行回顧，總結經驗教訓。除此以外，在版本質量評估中，還有一項重要工做，就是對多個版本的測試用例執行狀況進行分析。整個測試過程分析如圖8-30所示。

圖16　測試過程分析 

1）測試用例的經過率

在版本質量評估時，咱們能夠對測試用例首次執行經過率、累積執行經過率和累積執行率進行統計，見表8-21。

表7　測試用例經過率統計結果

質量指標是否有效，和咱們在什麼時候進行評估、評估對象的粒度、評估的目的息息相關。若是咱們只是在版本發佈的時候、在系統的層面來統計各類質量指標，據此給出產品可否發佈的結論，確實不能讓人信服。但若是咱們可以在每一個版本都統計相關的質量指標，評估對象的粒度也細化到功能特性，將「質量指標」做爲「質量之尺」，讓你們知道咱們當前的質量離咱們的目標還有多遠，咱們還須要作怎樣努力，進行怎樣調整，才能達到咱們最終的質量目標，這樣進行質量評估，才真正有用，而且可以被你們信服。

2）測試用例在多個版本中的測試結果

咱們在進行測試用例累積經過率的統計時，並不能只關注50%、70%這樣的統計數字，還須要注意分析測試用例在多個版本中的測試結果。

表8 測試用例在多個版本中的測試結果

咱們對每一個build的測試策略說明以下：

• 在build1中，咱們的測試策略爲執行「測試用例1」~「測試用例4」，不執行「測試用例5」和「測試用例6」。
• 在build2中，咱們的測試策略爲執行build1中測試結果爲「失敗」和「不執行」的測試用例，選擇了「測試用例3」~「測試用例6」。
• 在build3中，咱們的測試策略爲執行build1和build2中測試結果爲「失敗」和「不執行」的測試用例，選擇「測試用例3」和「測試用例5」。另外，咱們還選擇部分測試結果爲「經過」的測試用例來進行「功能迴歸測試」，所以選擇了「測試用例4」。

測試用例4」的測試結果，在build2中爲「經過」，在build3中爲「失敗」，出現了反覆。是什麼緣由致使測試用例的執行結果出現了反覆？

比較常見的緣由有新功能的合入對舊功能形成了影響或缺陷修改引入。

對這兩種狀況，軟件測試架構師均可以從「開發修改」和「功能交互」的角度來有針對性地選擇測試範圍，由此來肯定build4的迴歸測試策略：對已經執行「經過」的「測試用例1」「測試用例2」和「測試用例6」，在build4中是否須要再進行迴歸測試。

3.在版本質量評估中進行缺陷分析

4.2　版本質量評估中的缺陷分析

每日缺陷跟蹤沒有分析過的內容包括缺陷密度、缺陷年齡（在每日缺陷跟蹤中只關注了缺陷修改引入方面）和缺陷觸發因素分析。

軟件測試架構師在版本質量評估中進行缺陷分析，須要重點關注以下幾個問題：

• 功能特性的缺陷密度是否正常？
• 缺陷年齡分析是否正常？
• 缺陷觸發因素分析是否正常？

4.3　調整測試策略

圖17　增長版本質量評估

4.4　創建特性版本質量檔案

一個產品可能會有不少功能特性，對軟件測試架構師而言，可能沒法保證對每一個功能特性都按照上述過程進行質量評估。因此對一個測試團隊而言，各個測試負責人一塊兒來創建一個特性版本質量檔案，在檔案中記錄各個功能特性在每一個版本中的質量狀況，是一個不錯的選擇。

產品的特性版本質量檔案，至少須要包含以下內容：

• 對當前測試覆蓋度方面的記錄，包括需求和實現的誤差。
• 對測試過程的分析和記錄。
• 缺陷分析。

最後測試責任人還能夠根據上面的狀況，對產品功能特性當前的質量進行評估，評估其是否達到質量要求，以及和質量要求的主要差距在哪裏，並據此總結出後續的測試建議。
在實際操做時，測試責任人能夠直接在以前制定的整體測試策略的基礎之上來創建特性版本質量檔案，見表9。

表9 特性版本質量檔案

5　後面的版本測試策略

---

 返回

到目前爲止，咱們的軟件測試架構師已經完成了制定測試策略—跟蹤測試執行—質量評估這樣的一個完整循環。可是測試項目尚未結束，緊接着咱們又會進入到下一個循環。

和第一個版本相比，後面的版本會考慮到實際的產品研發狀況和測試狀況，而對測試策略進行調整，所以，後面版本的測試策略除了考慮咱們在8.2.8節中總結的內容外，還須要增長迴歸測試策略和探索式測試策略的內容——本章咱們未來詳細討論須要如何制定它們。

5.1　迴歸測試策略

迴歸測試是一種「確認」性質的測試，測試目標有：

• 缺陷迴歸：確認測試中發現的缺陷被開發人員正確修復了。
• 功能迴歸：確認老功能不會由於新合入的功能而失效。
• 階段迴歸：確認產品當前的質量達到該階段的質量目標。

在項目不一樣的階段，迴歸測試的目標會有所側重，以「俄羅斯方塊心」項目爲例，迴歸測試在不一樣階段的重點如圖18所示。

圖18 迴歸測試的重點

說明：

• 在集成開發和測試階段，因爲功能還會不斷地添加進來，因此此時迴歸測試的重點爲「缺陷迴歸」和「功能迴歸」。
• 在系統測試階段，這時已經不會再添加新的功能了，因此迴歸測試的重點爲「缺陷迴歸」。
• 在每一個階段結束的時候，會產生一個專門的迴歸測試版本，咱們會在這個版本中對這個測試階段進行總體的迴歸，確認是否達到該階段的目標。

1.缺陷驗證策略

咱們將缺陷按照功能和非功能、是否有「用戶可見的輸入輸出接口」分爲三類，如圖19所示。

 圖19 缺陷的三類

較難於驗證的是那些「底層或中間層類的缺陷」。因爲它們位於系統的底層或中間層，不少功能均可能會調用它們，修改它們每每會影響較多的功能，還可能會影響系統的性能、可靠性等非功能。對這類問題，可使用以下策略：

• 控制這類缺陷在設計修改和編碼上的質量。例如，要求開發人員對修改方案進行討論和評審，對修改代碼進行走讀，等等。
• 軟件測試架構師（或由軟件測試架構師指定專門人員）根據缺陷的修改方案來肯定須要進行迴歸測試的內容

2.功能迴歸策略

• 1）新開發功能在合入版本後的迴歸測試
• 2）老功能迴歸測試

3.階段迴歸策略

表10 不一樣階段迴歸測試用例選擇

 

5.2　探索式測試策略

1.將探索式測試和傳統式測試結合起來

圖20　「俄羅斯方塊心」項目的測試

這個策略最大的壞處是缺陷可能會在探索測試階段再集中爆發一次，使得缺陷遲遲不能收斂，形成測試項目延期。

圖21　探索式測試

這個策略探索式測試會使得集成測試階段變長。

圖22　與圖21相比的結果

2.探索式測試方法的選擇策略

在4.5節中爲你們介紹了不少探索式測試方法。咱們能夠大體按照以下順序來選擇探索式測試方法：

• 在集成測試時，先使用商業區測試法和娛樂區測試法，再使用歷史區測試法和破舊區測試法。
• 在系統測試時，先使用歷史區測試法和破舊區測試法，再使用商業區測試法和娛樂區測試法，最後使用旅館區測試法和旅遊區測試法。

3.探索式測試策略在版本測試策略中

圖23　流程圖

6　階段質量評估（包括髮布質量評估）

---

 返回

6.1　階段質量評估項目

從前面的章節能夠得知咱們在跟蹤測試執行和版本質量評估中一直在進行質量評估。這使得質量評估從一個階段性的測試活動（不少測試團隊可能只在版本快要發佈的時候纔開始進行質量評估），變成了天天、每一個版本都在進行的活動，一旦發現了質量問題，就能在過程當中實時調整測試策略，使得最後產品可以達到發佈的質量目標。

雖然跟蹤測試執行、版本質量評估和階段質量評估都是根據質量評估模型在進行質量評估，可是它們各自的側重點仍是有所不一樣的。

• 跟蹤測試執行關注測試過程，經過過程來保證質量，是使咱們最終可以達到測試目標的基礎。評估項目也主要是一些定性的分析。
• 版本質量評估關注的是每一個版本的質量是否符合預期。評估項目包含定性分析和定量指標，但定性分析偏多。
• 階段質量評估關注的是每一個階段的質量目標是否完成。評估項目包含定性分析和定量指標，但主要是定量指標。

表11　質量評估項目總結

1.確認整體測試策略中的質量目標是否完成

一個思路是，將質量目標劃分爲重要的、必須達成的質量目標和通常性的質量目標（後文咱們統一稱那些重要的、必須達成的質量目標爲質量紅線）。

2.重要的質量目標（質量紅線）

表12 某產品質量紅線

3.對未達到的通常性質量目標制訂應對措施

• 1）非測試用例發現缺陷的緣由分析
• 2）缺陷分析

4.遺留缺陷分析

6.2　非測試用例發現缺陷的緣由分析

表13 分類參考

表14 測試團隊分析參考模板

6.3　組合缺陷分析

 

圖24 評估結果的決定

6.4　遺留缺陷分析

1. 缺陷對用戶的影響程度
2. 缺陷發生的機率
3. 缺陷風險評估和規避措施
4. 不能遺留的缺陷

原則上，知足下述條件的缺陷不該該成爲遺留缺陷：

• 「致命」缺陷不該該做爲遺留缺陷。
• 沒有「規避措施」的「嚴重缺陷」不該該遺留。

6.5　臨近發佈時的缺陷修復策略

咱們在肯定遺留缺陷的過程當中，一方面，因爲不一樣人員對缺陷遺留的標準可能會有差異，不免又會臨時決定要修改合入一些缺陷。另外一方面，越到臨近發佈的時候，越須要控制缺陷修復的數量。

6.6　非必然重現bug的處理

在進行遺留缺陷分析時，咱們討論了缺陷發生的機率，對那些非必然重現的bug（指「無規律重現」和「沒法重現」的bug），也須要按期進行跟蹤和處理。

軟件測試架構師和測試經理、開發表明等在測試團隊、開發團隊中對非必然重現的問題達成共識：

• 測試人員發現非必然重現的bug，也須要提bug。可是須要特別作好問題的記錄，並在問題出現的第一時間找開發人員定位。
• Bug復現不只僅是測試人員的工做，開發人員和測試人員能夠一塊兒復現bug。
• 未復現的bug不該該隨便關閉。

對最後一點，那些一直未能復現的bug，須要軟件測試架構師按期將這些bug彙總，選擇優先級高的缺陷，組織開發人員和測試人員專門投入到復現問題，若是通過這樣的專門復現依然不能復現，能夠下降問題的優先級，直到bug的優先級降至最低，該bug才能夠關閉。

在項目前期，對非必然重現bug的跟蹤週期能夠稍長一些，越到項目後期，越要增強對非必然重現bug的跟蹤、復現工做。

6.7　總結

圖25 發佈階段