銀行軟件的專業性、復雜性和銀行業務的特殊性質使得銀行軟件系統上線后面臨種種風險。防范軟件風險的重要手段之一是執行有效的軟件測試。在軟件測試過程中，對軟件缺陷的管理是發現軟件風險、保證軟件測試有效性的關鍵環節。對于商業銀行軟件項目來說，軟件缺陷管理與軟件風險防控是相輔相成的。科學的缺陷管理方法是提高軟件測試質量不可或缺的手段，也是減少軟件風險的一種可靠途徑。

一、銀行軟件缺陷管理的重要性

作為軟件測試活動的最終產出物，軟件缺陷反映了軟件存在風險的事實。銀行系統軟件之所以較一般軟件的風險更高，其主要原因在于：

1、銀行軟件運行錯誤可能造成非常高的經濟代價，因此對可靠性的要求更高；

2、銀行軟件測試除了需要基本的軟件領域知識外，還需要具備銀行業專業知識；

3、銀行軟件特別是核心業務系統通常規模龐大，模塊間耦合性強；

4、銀行軟件經常面臨需求變動、開發周期短等軟件工程中較為棘手的非技術性問題。

軟件測試的目的為了提前發現銀行系統軟件的潛在風險，而缺陷管理實質上就是對風險的管理。從某種意義上說，軟件缺陷可以看作是已經發現的風險，因此缺陷管理對銀行軟件風險防控來說有重要意義。

二、缺陷管理與風險防控的關系

軟件缺陷管理的任務主要包括缺陷發現、缺陷提交、缺陷修復、缺陷分析、缺陷驗證等。軟件缺陷反映了軟件存在風險的事實。軟件測試的目的就是發現缺陷，發現風險。然而，軟件測試的覆蓋范圍始終是有限的，任何一次測試活動都只能做到“盡可能”發現缺陷。因此，在缺陷管理的過程中，要特別注意防患于未然，總結歷史經驗，充分發掘缺陷背后隱藏的風險信息。

根據銀行軟件測試工作實踐經驗，我們認為軟件缺陷對風險的反映主要體現在缺陷的業務風險特性、缺陷的影響范圍和缺陷的工程等級。

1、缺陷的業務風險特性

缺陷的業務風險特性是指由于缺陷導致業務失敗所可能產生的風險后果。業務風險特性從銀行業務角度描述了缺陷發生后可能產生的后果，與軟件缺陷本身的嚴重等級無關。

2、缺陷的影響范圍

對銀行軟件系統的測試，特別是對核心業務系統的測試，經常需要涉及多個模塊甚至多個系統。因此，某一個模塊產生缺陷，其真正原因可能并不在模塊本身。同樣，修復該缺陷后所影響的也不僅僅是模塊本身。對缺陷影響范圍的合理定位有利于切實理解缺陷的風險所在。

3、缺陷的工程等級

缺陷的工程等級是軟件工程中根據缺陷對系統影響的嚴重程度劃分的評價等級。在評價銀行業務軟件風險時，區分業務風險與工程風險有利于定位、理解和應對風險。

發現風險和規避已知風險是軟件缺陷管理的目標。為了實現這一目標，對軟件缺陷的精細化管理是不可或缺的。一般的軟件缺陷管理方法和工具通常注重從流程和缺陷工程等級上實施精細化管理，對于銀行業務軟件來說，這樣做還不夠。由于銀行業務本身的風險高，又高度依賴于業務系統的運行，因此缺陷管理必須考慮業務層面的影響。在將業務風險納入后，我們在傳統模型的基礎上重新規劃了缺陷管理流程，并致力于解決如下問題：

1、如何設計多系統、多模塊的缺陷管理模型，使之更加符合銀行軟件項目實踐活動，并有助于提升風險管控能力；

2、如何將缺陷與業務特性結合，全面認識缺陷可能帶來的風險；

3、如何利用新的缺陷管理模型挖掘信息、評估風險。

三、軟件缺陷管理模型

缺陷的有效處理依賴于相關人員的緊密配合，從軟件工程角度看，缺陷處理相關人員包括開發人員、測試人員等，不同角色各司其職，充分發揮每一個角色的能力要靠合理的工作流程來保證。對于銀行軟件系統而言，因為經常涉及多個業務系統交叉，更加需要一套有效的缺陷管理流程。我們首先給出缺陷管理流程示意圖(如圖1)。

圖1 缺陷管理流程示意圖

我們希望能夠通過有效的缺陷管理工作防范風險。基于上述缺陷管理模型，我們試圖完成兩項任務：首先，分離系統的技術風險與業務風險，實現風險的精細化評估；其次，找到一種能夠評價多系統之間關聯風險的方法。

四、軟件缺陷的業務風險評估

軟件缺陷的業務風險是銀行軟件測試領域中一類不可忽視的風險，同時，銀行軟件測試人員還面對軟件工程的其它技術風險。區分這兩類風險有助于幫助測試人員更好地識別、應對風險。為此，我們引入四種缺陷管理角色，分別是測試人員、開發人員、測試經理、開發經理，這些角色的職責分別是：

測試人員的職責包括新建缺陷、復核缺陷和驗證缺陷。

開發人員的職責包括調查缺陷、修復缺陷。

測試經理的職責包括審核缺陷、評估缺陷。

開發經理的職責包括分配缺陷、流轉缺陷。

為了實現對風險的精細化評估，我們來進一步明確四類角色的職責。

對于測試人員來說，應當從“缺陷影響系統運行的程度”這一角度來評估缺陷的技術風險，例如是否會引起系統宕機、是否會損壞數據等；對于開發人員來說，應當給出缺陷的技術解決方案。換句話說，測試人員和開發人員互相配合，以盡量避免被測系統在技術上存在風險。

對于管理人員來說，這里特指測試經理和開發經理，他們應該關注的是缺陷的業務特性。測試經理的主要任務是評估缺陷的業務風險等級，包括缺陷是否存在業務上的風險、風險程度如何；開發經理的主要任務是確認缺陷屬于自己所負責的業務范圍內，并指定相關業務開發人員去解決缺陷，如果缺陷不屬于自己所管轄的范疇，開發經理應該將缺陷轉交給其它業務系統的開發經理。測試經理與開發經理互相配合，完成對缺陷業務風險的確認和解決。

在本文提出的風險評估體系中，測試經理是對業務風險進行評估的關鍵角色，必須具備過硬的業務能力和測試技術。有些缺陷從軟件工程角度講可能并不嚴重，然而一旦同銀行業務結合起來，就可能潛藏著很大的風險。“安全無小事”，保障客戶的財產安全是銀行的責任，在涉及到客戶財產安全的業務系統中，即使僅僅發現了一些極小的缺陷，也必須謹慎處理。根據我們的經驗，軟件缺陷所隱含的業務風險與以下幾個要素息息相關：

1、業務系統本身的重要性和可靠性要求，比如是否是核心系統，業務連續性要求如何，系統出錯后對銀行業務的影響覆蓋面的廣度如何等等。

2、缺陷是否涉及其它業務系統，如果一個缺陷是由于其它業務系統的問題所導致，或者這個缺陷與其它業務系統有關聯，那么它的風險就會提高。

3、缺陷產生是不是因為開發人員對業務需求的理解存在偏差。根據經驗，如果一個缺陷是因為業務理解不一致產生，那么很有可能存在更多的類似缺陷。

將業務風險與技術風險分開可以幫助我們更好地定位風險產生的原因，讓測試經理和開發經理專注于解決業務問題，有利于風險管控。

五、多系統關聯風險的評估

銀行業務系統之間具有較高的關聯性。系統之間的關聯程度高會增加系統風險。我們在實踐工作中發現，系統缺陷的統計數據是反映系統間關聯程度的重要依據。為此，我們對系統缺陷數據與系統關聯性展開了研究。

我們發現，軟件缺陷在其生命周期中的流轉過程提供了有價值的信息。每一個缺陷從最初的“新建”狀態到最終的“關閉”狀態，期間要經歷若干次狀態轉換(如圖1)，每次狀態轉換發生時，缺陷由某個系統/角色流轉到另一個系統/角色。從某個特定角色的角度看，缺陷的流轉可能僅僅代表任務的接受或完成。但從風險管理的整體視角看，缺陷的狀態轉換不單單只是任務的分配，更重要的是可以為系統風險的評估提供信息。發生系統間流轉的缺陷在這方面有著特殊意義：缺陷在系統間的流轉路徑反映了系統間的耦合程度，在同一測試階段，如果有大量缺陷都發生了在某兩個系統之間的流轉，那么可以認為這兩個系統的相關性很高。系統相關性高意味著其中一個系統的變化可能會影響另外一個系統，這樣的耦合型系統的業務風險也是要高于一般系統的，我們在本文中稱之為“業務耦合風險”。通過對缺陷流轉記錄的分析，可以發現業務耦合風險。

我們采取如下方法來計算業務耦合風險：

首先，篩選缺陷列表中所有的跨系統缺陷。所謂跨系統缺陷，是指缺陷的建立者(測試人員)和缺陷的修改者(開發人員)不隸屬于同一個系統的缺陷。篩選完成后，將每一個符合條件缺陷的建立系統和修改系統歸總為一個系統組。最后，合并成員相同的系統組，系統組合并的重復次數即為業務耦合風險指數。

業務耦合風險指數度量了業務耦合風險的大小，換句話說，實現了對多系統關聯風險的評估。當某個系統組的業務耦合風險指數較高時，意味著這個組內的系統之間關聯性高。在測試過程中，特別是多系統聯合測試時，要對業務耦合風險指數較高的系統組給予關注，執行更為細致和全面的測試。

總結

軟件缺陷是軟件測試工作的產出成果，是反映軟件風險的重要實踐依據。本文闡述了在銀行軟件缺陷管理過程中提高風險管控能力的三類措施，包括制定合理有效的缺陷管理角色和流程、分析利用缺陷的業務特性、充分挖掘缺陷流轉過程中的有效信息等。總之，在軟件缺陷管理流程中引入業務評估要素與關聯性度量要素，有助于進一步發揮軟件測試對系統風險的防范作用，積累與業務緊密結合的風險防控經驗，提升軟件測試工作的效率與效果。

版權聲明：本文出自51Testing會員投稿，51Testing軟件測試網及相關內容提供者擁有內容的全部版權，未經明確的書面許可，任何人或單位不得對本網站內容復制、轉載或進行鏡像，否則將追究法律責任。

總結

以上是生活随笔為你收集整理的银行系统软件测试的目的,商业银行软件缺陷管理与风险评估的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。