軟件回歸測試中的故障樹技術應用研究

譚李孟清 張瑩 王玉林

摘 ?要： 回歸測試是軟件產品生產過程中比重很大的測試環節。對基于修改變更和基于新增變更的軟件回歸測試都可基于故障樹分析的縮減回歸測試策略進行。對錯誤/BUG修改變更的故障樹分析，可基于“軟件缺陷是一種故障”的思想進行套用。對新增變更的故障樹分析，須基于“產品質量控制和保證的全過程” 思想和程序員協作，決定軟件新增變更的影響部分。通過基于故障樹的相依性分析，對基線測試用例庫的測試用例進行縮減，選用有效的測試用例和設計新的測試用例構造成回歸測試包。

關鍵詞： 軟件回歸測試;故障樹;測試用例設計

中圖分類號： TP311.56 ???文獻標識碼： A ???DOI：10.3969/j.issn.1003-6970.2020.09.002

本文著錄格式：譚李孟清，張瑩，王玉林. 軟件回歸測試中的故障樹技術應用研究[J]. 軟件，2020，41（09）：0508+25

【Abstract】： In this paper， the fault tree technique for software regression testing is discussed in detail. There are two kinds of states to perform regression testing in software product evolution， and the reduction strategy based on fault tree can be applied to any state. For BUG alternation state， conditional fault tree can be used generally; for enhancement alternation state， the construction of fault tree should be considered along with the dependency of enhancement part， and analyzing completely based on cooperation between programmers and testers. Then， the regression test suite can be generated by selection of test case from baseline of test case base and newly designing of testing case for new enhancement part of software product.

【Key words】： Software testing; Regression testing; Fault tree; Test case design

0 ?引言

美國AT&T是世界著名的電話電報公司，它擁有115個交換站將遍及世界的當地電話公司連接起來，每天可處理1.15億次美國境內的呼叫和150萬次的海外呼叫，每個交換站每小時能處理將近75萬次呼叫。但是，1990年1月15日下午出現系統癱瘓，在接下來的9個小時內有近6500萬個電話沒接通，造成約6000萬美元的損失。這次癱瘓問題的原因非常小，就是交換機新軟件在修改時將十六進制數D/二進制數1101誤打成了十六進制數6/二進制數0110，這種低級小錯誤對程序員來說是有情可原的，問題是軟件發布上線前沒進行回歸測試，從而導致如此大的經濟損失[1-3]。

軟件產品生產過程中，程序員修改軟件之后，一定要做回歸測試，哪怕是針對很小的錯誤做了很小的修改[4-5]。尤其對國防和軍用軟件，更是值得注意。軟件變更之后必須進行回歸測試，主要基于以下原因：（1）程序員雖然已做了調試，但由于很難發現自己的錯誤，因此必需增加測試。（2）程序員由于疏忽易出現編程缺陷，因此必需增加測試。（3）程序員在呆板

操作和疲勞情況下易出現差錯，因此必需增加測試。（4）不可避免的松懈和懶惰，程序員易產生錯誤，因此必須增加測試。（5）在配置和負荷發生改變的條件下，軟件易出現錯誤。（6）不同的人看事物的重點和角度是不同的，專門的測試員做回歸測試是非常有意義的。

一般，發生軟件回歸測試有兩種狀態：（1）在軟件出現錯誤/BUG后進行了修改，應做回歸測試; ??（2）軟件加入了新單元新功能后，應做回歸測試。

故障樹是以研究對象（一般是出現的故障）作為頂層事件，以造成故障發生的事件為中間事件和末事件，并用邏輯門表示事件之間聯系的一種樹形結構的邏輯圖形。故障樹分析是一種針對出現故障所進行的演繹推理，是一種將系統故障的成因進行由總體到部件按樹枝形狀分層細化的演繹分析法。故障樹分析既可用于裝備的故障分析，也可用于軟件系統的故障分析。本研究就是將故障樹應用于回歸測試，分析回歸測試須測試的功能路徑和內容以及測試用例的選用和設計。

1 ?基于故障樹技術的軟件回歸測試策略和一般步驟

1.1 ?基于故障樹技術的軟件回歸測試策略

軟件回歸測試常用的測試策略有三種：（a）完全回歸測試，（b）局部選擇性回歸測試，（c）經相依性分析的縮減回歸測試。

（1）完全回歸測試策略完全回歸測試是選擇基線測試用例庫中全部測試用例組成回歸測試包。這是一種較安全的回歸測試方法，但測試成本太高。

（2）局部選擇性回歸測試策略局部選擇性回歸測試主要是在選擇測試用例組成回歸測試包時，根據測試用例的重要程度及其級別進行選取。此方法可減低成本，但增加了測試的風險。

（3）通過相依性分析的縮減回歸測試[5]此測試方法是通過進行相依性分析，決定哪些測試用例可用來覆蓋軟件變更所影響的部分。由此對回歸測試包進行縮減，提高測試效率，節省測試成本。

以通過相依性分析的縮減回歸測試為基礎，我們這里給出基于故障樹分析的縮減回歸測試策略：先用故障樹進行相依性分析[5]，選擇基線測試用例庫中已有測試用例覆蓋軟件變更部分，然后設計添加新的測試用例覆蓋軟件變更的影響部分，由此實現對回歸測試包的縮減，并提高測試效率，節省測試成本。

1.2 ?軟件回歸測試應用故障樹技術的一般步驟[6]

故障樹原是一種故障診斷工具，用來分析發生故障的原因和具體部位。將故障樹技術用于軟件回歸測試，主要是基于“軟件缺陷是一種故障”的思想。故障樹分析技術在回歸測試中的運用，主要用在測試用例設計。實際上就是通過分析軟件產生BUG/缺陷的原因，來分析軟件產生缺陷將對哪些部分產生影響，從而進一步以此為基礎設計測試用例。圖1是在回歸測試中應用故障樹技術的一般步驟。

2 ?基于錯誤/BUG修改變更的故障樹回歸測試技術

基于錯誤/BUG修改變更的回歸測試在軟件測試中的比重更大，因此首先做討論。更重要的原因是，從“產品質量控制和保證的全過程”思想出發，基于錯誤/BUG修改變更的回歸測試將貫穿軟件測試的全過程，并且只有程序員和測試員的全面合作才能夠真正保證軟件產品的質量。因回歸測試的流程的一般性，我們用產品質量監控軟件簡體中文版V1.0作為分析實例，進行討論。

2.1 ?錯誤/BUG和修改的背景

根據任務要求，對產品質量監控軟件簡體中文版進行系統測試。在對UChart進行測試時，出現啟動錯誤BUG，把BUG反饋給程序員，從程序員處得知原因是“為體現檢測量值對管控界限的影響，修改了UChart的數據位strSetting[2]和strSetting[3]的更新方式”。讓程序員重新進行修改之后，提交回歸測試。

2.2 ?故障樹分析

因軟件缺陷是一種故障，故障樹可作為基于錯誤/BUG修改的軟件回歸測試的分析工具，進行測試用例的選用和設計。依據圖1的一般步驟，以程序員對軟件進行的修改為基礎，我們將“修改UChart的數據位strSetting[2]和strSetting[3]的更新方式出現軟件BUG”作為頂層事件，相應發生或產生影響的單元和軟件要素作為中間事件和末事件，畫出如圖2所示的故障樹。圖中，A是頂層，Ai是中間層，Ci是條件，Xij是末層，各個事件編碼的意義，如表1所示。

2.3 ?基于功能與路徑標識的測試用例選取和添加[7]

因程序員的此次修改變更主要影響軟件的功能，因此先列出故障樹對應的功能與路徑標識。然后，依據功能與路徑標識所涉及的內容，決定測試用例選取。并通過功能與路徑標識及其涉及/影響的內容，設計哪些需重新設計的測試用例—用*標記。具體的處理結果，參見表2。

3 ?基于新增變更的故障樹回歸測試技術

對基于新增變更的回歸測試，需應用“新增者完全測試，影響者不完全測試”原則。因此，在其故障樹中有如下處理：（1）基于新增變更回歸測試的故障樹比基于錯誤/BUG修改變更的故障樹分支多，產生的測試用例也一般就多。（2）因為是新增單元，作為構造要素，門邏輯采用“邏輯與”構造。（3）對影響者的分析應和程序員一起合作，做具體分析。一般分析重點主要有：黑箱—數據/接口影響，功能/路徑影響;白箱—繼承/多態性影響，交互過程影響。（4）對影響者的篩選，應有經驗幫助。

相同地，我們仍用產品質量監控軟件簡體中文版V1.0作為分析實例，進行故障樹運用討論。但這里加強了面向對象程序設計的要素。

3.1 ?新增變更的背景

根據專家和用戶要求，對產品質量監控軟件中的Median圖增加樣本容量保存功能。其依據是：“質量監控中有一個參數n—樣本容量，在計量值控制圖計算時，它對控制界限有非常重要影響。雖然樣本容量在每個抽檢批中發生一些變化，但對制造工廠的某個抽檢工序來講，技術管控層面上決定了就基本保持不變

了。因此有必要將此參數保存。”并由此讓程序員新增加此功能之后，提交回歸測試。

3.2 ?故障樹分析

我們將“Median圖增加樣本容量n保存”作為頂層事件，相應發生或產生影響[5]的單元和軟件要素作為中間事件和末事件，畫出如圖3所示的故障樹。在圖中，故障樹的頂層和中間層事件表見表3，末層事件見表4。

3.3 ?新增變更回歸測試的測試用例設計

（1）回歸測試及其測試用例設計的起點

新增變更回歸測試的起點需從編程階段考慮。因這里增加的只是樣本容量的保存，因此可直接進入集成測試環節，進行集成測試用例的選用/設計。

若要增加單元測試，注意此處單元測試主要是樣本容量n的編輯框的輸入測試。先依據n的取值進行等價類劃分，再由等價類劃分設計測試用例。

（2）功能與路徑標識和集成測試用例選取/設計[7]

依據程序員進行的修改，分析軟件變更涉及的單元，列出故障樹對應的功能與路徑標識，再從基線測試用例庫中選取測試用例，見表5。然后再依據影響的單元列出故障樹對應的功能與路徑標識，設計新測試用例加入回歸測試包—用*標記，見表6[8，9]。

依據以上的故障樹分析和已有的經驗，我們可作總結：（a）新增變更回歸測試及其測試用例設計的起點應根據新增單元的性質進行確定。如是重新設計控件，宜從單元測試開始。（b）測試用例庫中沒有適用測試用例，必須添加新測試用例，重點可放在集成/確認測試用例的設計。（c）已有的測試用例已過時，須停止使用，并進行更新。

4 ?結論

在軟件產品的生產過程中，回歸測試占很大的比重。回歸測試一般基于兩種狀態：一是基于軟件錯誤/ BUG的修改變更，另外是基于軟件的新增變更。對此兩種變更的軟件回歸測試都可基于故障樹分析的縮減回歸測試策略進行。對錯誤/BUG修改變更的故障樹分析，可基于“軟件缺陷是一種故障”的思想進行套用。對新增變更的故障樹分析，應注意邏輯門的修改，并基于“產品質量控制和保證的全過程” 思想和程序員合作，在技術層面上消除誤解，完成統一協調，并以此決定軟件新增變更的影響部分。通過基于故障樹的相依性分析，對基線測試用例庫的測試用例進行縮減，選用有效的測試用例和設計新的測試用例構造成效率好成本合理的回歸測試包。

參考文獻

[1]B. W. Boehm. Classics in software engineering[M]. New Jersey： Yourdon Press Upper Saddle River， 1979.

[2]Per Runeson. Guidelines for conducting and reporting case study research in software engineering[J]. Empirical Software Engineering， 2009， 14（2）： 131-164.

[3]Jeremy S. Bradbury， James R. Cordy， Juergen Dingel. An Em pirical Framework for Comparing Effectiveness of Testing and Property-Based Formal Analysis[C]// Proceedings of the ACM SIGPLAN-SIGSOFT Work on Program Analysis for Software Tools and Engineering. Portugal： Lisbon， 2005： 160-170.

[4]A. Charan Kumari， K. Srinivas， M. P. Gupta. RegressAid – A

CASE Tool for Minimization of Test Suite for Regression Testing[J]. International Journal of Computer Applications， 2013， 71（18）： 30-34.

[5]Ms. Sujata， Nancy Dhamija. Test Cases Prioritization Using Model Based Test Dependencies： A survey[J]. International Journal of Information & Computation Technology， 2014， 4（10）： 1003-1010.

[6]唐凌遙。軟件回歸測試管理技術[D]。長沙： 國防科學技術大學計算機學院， 2005.

[7]Mengqing TanLi， Yan Jiang， Xiang Wang. Black-box Approach for Software Testing Based on Fat-property[C]// Proceedings of the 2019 International Conference on Computer Science， Communication and Network Security， Sanya： DEStech Publications， Inc.， 2019： 198-204.

[8]HyunSook Do， Gregg Rothermel， Sebastian Elbaum. Infrastructure Support for Controlled Experimentation with Software Testing and Regression Testing Techniques[C]// Proceedings of the 2004 International symposium on Empirical Software Engineering， Redondo Beach： IEEE， 2004： 60-70.

[9]許媛媛. 基于CBR的測試用例復用方法研究[J]. 軟件， 2015， 36（9）： 117-120.