軟件回歸測(cè)試中的故障樹(shù)技術(shù)應(yīng)用研究

譚李孟清 張瑩 王玉林

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

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

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

本文著錄格式：譚李孟清，張瑩，王玉林. 軟件回歸測(cè)試中的故障樹(shù)技術(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? 引言

美國(guó)AT&T是世界著名的電話電報(bào)公司，它擁有115個(gè)交換站將遍及世界的當(dāng)?shù)仉娫捁具B接起來(lái)，每天可處理1.15億次美國(guó)境內(nèi)的呼叫和150萬(wàn)次的海外呼叫，每個(gè)交換站每小時(shí)能處理將近75萬(wàn)次呼叫。但是，1990年1月15日下午出現(xiàn)系統(tǒng)癱瘓，在接下來(lái)的9個(gè)小時(shí)內(nèi)有近6500萬(wàn)個(gè)電話沒(méi)接通，造成約6000萬(wàn)美元的損失。這次癱瘓問(wèn)題的原因非常小，就是交換機(jī)新軟件在修改時(shí)將十六進(jìn)制數(shù)D/二進(jìn)制數(shù)1101誤打成了十六進(jìn)制數(shù)6/二進(jìn)制數(shù)0110，這種低級(jí)小錯(cuò)誤對(duì)程序員來(lái)說(shuō)是有情可原的，問(wèn)題是軟件發(fā)布上線前沒(méi)進(jìn)行回歸測(cè)試，從而導(dǎo)致如此大的經(jīng)濟(jì)損失[1-3]。

軟件產(chǎn)品生產(chǎn)過(guò)程中，程序員修改軟件之后，一定要做回歸測(cè)試，哪怕是針對(duì)很小的錯(cuò)誤做了很小的修改[4-5]。尤其對(duì)國(guó)防和軍用軟件，更是值得注意。軟件變更之后必須進(jìn)行回歸測(cè)試，主要基于以下原因：（1）程序員雖然已做了調(diào)試，但由于很難發(fā)現(xiàn)自己的錯(cuò)誤，因此必需增加測(cè)試。（2）程序員由于疏忽易出現(xiàn)編程缺陷，因此必需增加測(cè)試。（3）程序員在呆板操作和疲勞情況下易出現(xiàn)差錯(cuò)，因此必需增加測(cè)試。（4）不可避免的松懈和懶惰，程序員易產(chǎn)生錯(cuò)誤，因此必須增加測(cè)試。（5）在配置和負(fù)荷發(fā)生改變的條件下，軟件易出現(xiàn)錯(cuò)誤。（6）不同的人看事物的重點(diǎn)和角度是不同的，專(zhuān)門(mén)的測(cè)試員做回歸測(cè)試是非常有意義的。

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

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

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

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

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

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

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

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

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

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

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

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

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

2.1? 錯(cuò)誤/BUG和修改的背景

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

2.2? 故障樹(shù)分析

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

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

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

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

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

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

3.1? 新增變更的背景

根據(jù)專(zhuān)家和用戶要求，對(duì)產(chǎn)品質(zhì)量監(jiān)控軟件中的Median圖增加樣本容量保存功能。其依據(jù)是：“質(zhì)量監(jiān)控中有一個(gè)參數(shù)n—樣本容量，在計(jì)量值控制圖計(jì)算時(shí)，它對(duì)控制界限有非常重要影響。雖然樣本容量在每個(gè)抽檢批中發(fā)生一些變化，但對(duì)制造工廠的某個(gè)抽檢工序來(lái)講，技術(shù)管控層面上決定了就基本保持不變了。因此有必要將此參數(shù)保存?！辈⒂纱俗尦绦騿T新增加此功能之后，提交回歸測(cè)試。

3.2? 故障樹(shù)分析

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

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

（1）回歸測(cè)試及其測(cè)試用例設(shè)計(jì)的起點(diǎn)

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

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

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

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

（3）新增變更測(cè)試用例設(shè)計(jì)的總結(jié)

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

4? 結(jié)論

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

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