測試員自我提升第一步:清晰梳理缺陷管理流程

發表于:2021-4-12 09:39  作者:佚名   來源:今日頭條

字體: | 上一篇 | 下一篇 |我要投稿 | 推薦標簽: 缺陷管理

  實施測試活動過程中,針對缺陷開展有效跟蹤管理是測試工程師質量保證活動的重點,因此,在一個成熟的測試團隊或組織內,缺陷管理流程的完善與否直接決定測試活動的質量。
  缺陷管理流程通常由角色定義、流程定義、工具應用、缺陷分析模型等幾個關鍵因素構成。
  角色定義表述了在缺陷管理流程中所涉及的若干角色及其職責內容,從而清晰明確定義每個流程節點中角色所需完成的事務。流程定義規定了在項目或產品實施測試活動時所需遵循的流程規則。
  工具應用則從項目或產品規模、團隊流程、成本控制、風險防范等多個角度考慮,選擇何種缺陷管理工具更能提升測試效果,提高缺陷管理效率。缺陷分析模型是針對缺陷進行綜合判斷,分析缺陷風險的科學方法,目前業內常用的模型有ODC、四象限、Gompertz等。
  一、角色定義
  缺陷管理流程活動一般包括測試工程師、測試負責人、開發負責人、開發人員、項目經理等若干角色。
  1. 測試工程師
  測試工程師負責實施測試活動,發現缺陷,及時提交缺陷,確認校驗缺陷,實施回歸測試。
  2. 測試負責人
  測試負責人評審缺陷,檢查測試工程師新增的缺陷是否符合規范,是否因為不熟悉需求、理解偏差而引起的誤提,并負責缺陷產生爭議后的協調處理。
  3. 開發負責人
  開發負責人負責缺陷分配活動,將需修復的缺陷根據缺陷修復任務分配給對應的開發人員,協調解決爭議缺陷。
  4. 開發工程師
  當缺陷提交給開發人員后,開發人員負責缺陷的確認及修復活動。
  5. 項目經理
  當對提交的缺陷有分歧、被拒絕時,可由項目經理、測試負責人、開發負責人等進行缺陷評審活動,商定問題如何處理,是否保留或當前版本不做處理等結論。
  二、流程定義
  不同公司因組織結構不同,所采用的管理流程亦不相同。大部分公司使用流程如圖5-5所示。
圖5-5通用缺陷管理流程
  注:流程中操作關鍵詞以HP商用的項目管理工具Application Lifecycle Management為范例
  1. 測試工程師或其他人員發現缺陷,經過確認后提交缺陷,缺陷狀態設置為“新建(New)”,“指派(Assign)”下步處理人為測試負責人。
  2. 測試負責人針對需要自己處理的缺陷進行“評審(Review)”操作。檢查測試工程師提交的缺陷是否符合缺陷報告規范,如語言描述是否清晰、問題定位是否準確等,或者判斷該問題是否確實是一個缺陷,還是因測試工程師不熟悉需求、理解偏差而引起的誤提。如有問題,將該缺陷“指派(Assign)”至測試工程師,讓其修改后再提交,此時缺陷狀態為“新建(New)”。如無問題,確定是缺陷,則將該缺陷提交給開發負責人,缺陷狀態為“打開(Open)”。
  3. 如果測試負責人“評審(Review)”后,缺陷“指派(Assign)”至測試工程師處,測試工程師則需再次確認缺陷是否誤提,是則“關閉(Close)”缺陷,并注明缺陷關閉原因,否則再次“指派(Assign)”至測試負責人處,缺陷狀態為“新建(New)”,并注明原因。測試負責人重復步驟2。
  4. 開發負責人將測試負責人“評審(Review)”后的缺陷根據缺陷修復任務分配給相應的開發人員,開發負責人一般僅分配缺陷,不再過濾缺陷,此時缺陷狀態為“打開(Open)”。
  5. 開發人員根據缺陷描述確認是否是缺陷,如果是,則進行缺陷修復活動,修復完成后,缺陷狀態置為“修復(Fix)”,并將對應缺陷“指派(Assign)”至缺陷發現者。如果不是缺陷,則將缺陷狀態置為“拒絕(Reject)”,由測試工程師再次確認處理。
  6. 測試工程師針對“拒絕(Reject)”的缺陷進行再次確認驗證,如果確認缺陷屬于誤提或不再存在,則可“關閉(Close)”對應缺陷,并注明關閉原因,若確認是缺陷,則需“重新打開(Reopen)”缺陷至開發人員處,并注明“重新打開(Reopen)”原因。開發人員重復步驟5。
  7. 當缺陷無法確認或產生爭執時,由測試、開發負責人及項目經理評審確認并給出最終處理結果。測試工程師及開發人員原則上不直接溝通,避免產生無效溝通。一般來講,缺陷處理是一個循環反復的過程。當出現爭議時,必須由項目經理參與缺陷處理活動,而不能由開發組或者測試組單方面決定缺陷的處理方式。
  上述流程可根據測試流程及時間進度適當調整,一般適用于5~10人的團隊,可精簡為適合3~5人團隊的流程,也可細化為適合10~15人的中型測試團隊。
  三、工具應用
  缺陷管理早期最通用的工具是Excel,簡單方便,但隨著缺陷管理流程的復雜化,對缺陷管理工具的要求越來越高,一般而言,缺陷管理工具需要具備以下幾個特征。
  1. 缺陷提交便捷。
  2. 可細分角色、權限。
  3. 可定制流程。
  4. 可進行缺陷數據分析。
  5. 支持郵件收發功能。
  目前市面上大部分缺陷管理工具都具備上述特征,較為常用的工具有以下幾種。
  1. 開源免費工具
 。1)Bugzilla
  Bugzilla起源于UNIX,后續版本可安裝在Linux、Windows平臺,使用便捷,分析功能、流程定制功能一般。
 。2)BugFree
  BugFree借鑒微軟研發流程和Bug管理理念,使用PHP+MySQL獨立設計的Bug管理系統,簡單實用。
 。3)禪道
  禪道是國內一款優秀的項目管理工具,提供了完善的測試工作平臺,其中包括缺陷管理功能。目前國內眾多軟件研發公司在用。
  2. 商業工具
 。1)TestTrack
  TestTrack是SeaPine公司生產的軟件缺陷管理工具,除了常規缺陷管理功能外,流程定制是其一大特色,甚至優于HP的QualityCenter,是目前業內專業的缺陷跟蹤工具之一,支持B/S和C/S兩種架構。
 。2)Application Lifecycle Management(ALM)
  HP的Application Lifecycle Management(ALM),前身是Quality Center,采用B/S結構,可在廣泛的應用環境下自動執行軟件質量測試和管理,是目前應用較為廣泛的商用測試管理工具。
  四、缺陷分析
  針對缺陷的關鍵字段,運用數據分析的統計方法,發掘軟件系統的缺陷分布、密度及發展趨勢,在此基礎上追溯軟件生產過程中引發缺陷的根本原因,為軟件質量分析提供基礎真實的數據依據。
  缺陷分析活動中常用的度量字段有嚴重度、所屬模塊、產生原因、所屬版本、持續周期、缺陷性質等。常用的缺陷分析模型有ODC、四象限、Gompertz等。
  1. ODC
  ODC由IBM推出,將一個缺陷在生命周期各環節的屬性組織起來,從單維度、多維度來對缺陷進行分析,從不同角度得到各類缺陷的缺陷密度和缺陷比率,從而積累得到各類缺陷的基線值,用于評估測試活動、指導測試改進和整個研發流程的改進;同時根據各階段缺陷分布得到缺陷去除過程特征模型,用于對測試活動進行評估和預測。ODC結構如圖5-6所示。
圖5-6 ODC模型示意圖
  2. 四象限
  根據軟件內部各模塊、子系統、特性測試所累積時間和缺陷去除情況,與累積時間和缺陷去除情況的基線進行比較,得到各個模塊、子系統、特性測試分別位于的區間,從而判斷哪些部分測試可以退出,哪些測試還需加強,用于指導測試計劃和策略的調整。
  3. Gompertz
  根據測試的累積投入時間和累積缺陷增長情況,擬合得到符合自己過程能力的缺陷增長Gompertz曲線,用來評估軟件測試的充分性、預測軟件極限缺陷數和退出測試所需時間、作為測試退出的判斷依據、指導測試計劃和策略的調整。

      本文內容不用于商業目的,如涉及知識產權問題,請權利人聯系51Testing小編(021-64471599-8017),我們將立即處理

評 論

論壇新帖

頂部 底部


建議使用IE 6.0以上瀏覽器,800×600以上分辨率,法律顧問:上海信義律師事務所 項棋律師
版權所有 上海博為峰軟件技術股份有限公司 Copyright©51testing.com 2003-2021, 滬ICP備05003035號
投訴及意見反饋:webmaster@51testing.com; 業務聯系:service@51testing.com 021-64471599-8017

滬公網安備 31010102002173號

51Testing官方微信

51Testing官方微博

掃一掃 測試知識全知道

农村里的风流韵事