譚李孟清 張瑩 王玉林

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

關(guān)鍵詞： 軟件回歸測試;故障樹;測試用例設(shè)計

中圖分類號： TP311.56 ???文獻(xiàn)標(biāo)識碼： A ???DOI：10.3969/j.issn.1003-6970.2020.09.002

本文著錄格式：譚李孟清，張瑩，王玉林. 軟件回歸測試中的故障樹技術(shù)應(yīng)用研究[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個交換站將遍及世界的當(dāng)?shù)仉娫捁具B接起來，每天可處理1.15億次美國境內(nèi)的呼叫和150萬次的海外呼叫，每個交換站每小時能處理將近75萬次呼叫。但是，1990年1月15日下午出現(xiàn)系統(tǒng)癱瘓，在接下來的9個小時內(nèi)有近6500萬個電話沒接通，造成約6000萬美元的損失。這次癱瘓問題的原因非常小，就是交換機(jī)新軟件在修改時將十六進(jìn)制數(shù)D/二進(jìn)制數(shù)1101誤打成了十六進(jìn)制數(shù)6/二進(jìn)制數(shù)0110，這種低級小錯誤對程序員來說是有情可原的，問題是軟件發(fā)布上線前沒進(jìn)行回歸測試，從而導(dǎo)致如此大的經(jīng)濟(jì)損失[1-3]。

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

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

一般，發(fā)生軟件回歸測試有兩種狀態(tài)：（1）在軟件出現(xiàn)錯誤/BUG后進(jìn)行了修改，應(yīng)做回歸測試; ??（2）軟件加入了新單元新功能后，應(yīng)做回歸測試。

故障樹是以研究對象（一般是出現(xiàn)的故障）作為頂層事件，以造成故障發(fā)生的事件為中間事件和末事件，并用邏輯門表示事件之間聯(lián)系的一種樹形結(jié)構(gòu)的邏輯圖形。故障樹分析是一種針對出現(xiàn)故障所進(jìn)行的演繹推理，是一種將系統(tǒng)故障的成因進(jìn)行由總體到部件按樹枝形狀分層細(xì)化的演繹分析法。故障樹分析既可用于裝備的故障分析，也可用于軟件系統(tǒng)的故障分析。本研究就是將故障樹應(yīng)用于回歸測試，分析回歸測試須測試的功能路徑和內(nèi)容以及測試用例的選用和設(shè)計。

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

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

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

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

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

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

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

1.2 ?軟件回歸測試應(yīng)用故障樹技術(shù)的一般步驟[6]

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

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

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

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

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

2.2 ?故障樹分析

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

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

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

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

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

相同地，我們?nèi)杂卯a(chǎn)品質(zhì)量監(jiān)控軟件簡體中文版V1.0作為分析實例，進(jìn)行故障樹運用討論。但這里加強(qiáng)了面向?qū)ο蟪绦蛟O(shè)計的要素。

3.1 ?新增變更的背景

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

了。因此有必要將此參數(shù)保存?！辈⒂纱俗尦绦騿T新增加此功能之后，提交回歸測試。

3.2 ?故障樹分析

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

3.3 ?新增變更回歸測試的測試用例設(shè)計

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

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

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

（2）功能與路徑標(biāo)識和集成測試用例選取/設(shè)計[7]

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

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

4 ?結(jié)論

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

參考文獻(xiàn)

[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]唐凌遙。軟件回歸測試管理技術(shù)[D]。長沙： 國防科學(xué)技術(shù)大學(xué)計算機(jī)學(xué)院， 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的測試用例復(fù)用方法研究[J]. 軟件， 2015， 36（9）： 117-120.