維護軟件測試的策略 軟件測試工具
上面描述的開發測試策略的技術，能夠直接用于新開發的系統。一個很自然的問題是：對于一個以前已經開發完畢或測試過的系統，上面所描述的步驟在多大范圍內仍然可以用于該系統的版本維護?
從測試策略的觀點來看，版本維護主要的不同點在于故障幾率。在維護的過程中，存在由于系統發生變化而gIA故障的風險。那些對系統行為的有意改變當然需要測試。但也有可能需要測試那些系統中沒有變化的功能，它們在以前的版本中表現正常，而在新版本中由于其他變化的副作用而出現問題。這種現象稱為回歸。在版本維護中，絕大部分的測試工作是測試以前的功能是否仍然工作正常，這被稱為回歸測試。因為一且產品進入維護階段，故障幾率會發生改變，所以相關的風險也會發生改變。接下來將改變子系統的相對重要性：例如當開發一個全新的子系統時，由于其商業要求高，因而其重要性就高。在版本維護中，這個子系統沒有發生改變，因此相關的風險就低，就可以將該子系統的重要性評定為低。
因此在開發測試策略時，通常將“子系統”的概念用“變更”來代替是有用的。這些變更通常是一組將實現的“變更需求”和一組需要解決的“已知缺陷”，要對每個變更需要對系統的哪些部分做修改，哪些部分會間接受到影響，哪些質量特性與之相關等進行分析。根據風險和預期進行的徹底測試，存在多種可能來測試每個變更：
一僅僅關注變更本身的有限測試；
一對變更的功能或部件的全面(再)測試；
一對變更的部件與其鄰近部件的一致性和交互性的測試。
實現每一個變更，都會引起回歸風險�；貧w測試是維護測試項目中的標準元素。通常要維護一組專門的測試用例來進行回歸測試。根據風險和可用的測試預算．需要在執行完整的回歸測試．還是測試那些最為相關的測試用例之間做出選擇。測試工具可以非常有效地支持回歸測試。當回歸測試的絕大部分能夠自動執行時，選擇放棄哪些回歸測試用例就不再必要了，因為無需多大努力就能夠執行完整的回歸測試。
決定按照變更需求而不是子系統來規劃測試策略，在很大程度上依賴于變更的數量。當只有相對很少的變更時，通過將這些變更作為風險評估、計劃和進度跟蹤的基礎，就能夠更好地管理測試過程。當子系統由于實現許多變更而進行重大修改時�？梢圆捎闷渥畛蹰_發時所用的方法來進行處理。通常人們更喜歡基于子系統來開發測試策略。如果一旦決定按照變更需求來規劃測試策略，則下面的步驟就可用來開發測試策略：
1確定變更(要實現的變更需求和要解決的問題)；
2確定變更和回歸的相對重要性；
3選擇質量特性；
4確定質量特性的相對重要性；
5確定每個變更(回歸)，質量特性聯合體的相對重要性；
6確定可用的測試技術。
表7 7是從前兩個步驟得出的—個矩陣例子。其他步驟和74節中描述的步驟類似。
表7 7變更和回歸的相對重要性矩陣
變更，回歸 相對重耍性(％)
文章來源于領測軟件測試網 http://www.kjueaiud.com/