軟件測試方法的研究與應用

武昭宇，張月琴，閻 華

(太原理工大學 信息化管理與建設中心,太原 030024)

?

軟件測試方法的研究與應用

武昭宇，張月琴，閻 華

(太原理工大學 信息化管理與建設中心,太原 030024)

對軟件需求規格說明書的靜態測試方法、基于路徑的白盒測試方法和黑盒測試方法進行了討論和研究。針對圖形軟件的測試提出一種可視化測試方法,并給出了以印刷電路版圖為例進行測試的處理算法和操作步驟；通過實際案例“數字檔案系統”說明軟件需求規格說明書測試方法和基于路徑測試方法的應用。該研究對于軟件開發和測試人員在選擇和應用測試方法時提供一定的參考和幫助。

軟件質量;軟件測試;需求規格說明;基本路徑;決策表;可視化

軟件質量問題由來已久,軟件測試的目的是盡可能早和盡可能多的尋找軟件中存在的錯誤和缺陷。軟件測試作為軟件工程學科的分支之一,由于起步較晚,重視不夠,并且涉及的知識面也比較廣,如程序找錯、圖論應用、軟件質量保證、軟件管理以及軟件復雜性度量等,因此從軟件測試理論和現有的測試方法、技術和工具等來看都滿足不了現在軟件開發的實際要求。只有對軟件應用的所有運行環境、執行路徑、語句、以及判斷分支等進行完全測試才能確保軟件測試的徹底性,但完全測試用例數和時間都是一個天文數字。想要遍歷所有的執行路徑一般是很難做到,即使所有的路徑都測試過了,覆蓋率幾乎達到100%,但軟件在某種特定環境下仍然可能出錯。因此要在短時間內較好的完成測試必須收集資料,仔細研究,精心設計測試用例,掌握好測試度。

科學的測試是貫穿在整個軟件開發生命周期的測試,所以應該突破對故有測試的理解,著眼于軟件開發的整個生命周期,分析軟件開發過程中可能會出現的一些錯誤和錯誤源。特別注意編碼之前各個開發階段的測試工作,以此保證軟件的質量。

1 常用軟件測試方法的討論與研究

軟件測試方法主要分為兩種:靜態測試和動態測試。在測試過程中,測試人員可將靜態測試和動態測試同時交叉使用,盡早來發現軟件中的錯誤和缺陷。靜態測試方法是采用人工測試和計算機輔助靜態分析來查找軟件中的錯誤和缺陷,并不在計算機上實際運行被測程序。對模塊的源代碼進行分析、研讀、走查，對軟件產品的需求和設計規格說明書的評審、對代碼的復審等,是靜態測試中檢驗軟件質量常用方法。靜態測試的查錯和分析功能是其他方法所不能替代的。

動態測試方法是通過真正運行被測程序來發現軟件中的錯誤和缺陷,從而來檢驗軟件的運行過程中是否符合期望要求或者運行結果是否正確。一般意義上的測試大多數指動態測試。傳統意義上的動態測試分為兩種：白盒方法和黑盒方法。白盒方法是能夠看清楚事物的內部,即了解被測軟件產品的內部結構和運行機制來處理和解決問題;黑盒方法是把事物看成一個整體,來測試產品的外部功能。下面對幾種常用而又典型的軟件測試方法進行討論與研究。

1.1 軟件需求規格說明書測試方法

傳統軟件開發中的瀑布模型,把需求和測試劃分為兩個不同的階段,而且相距較遠,認為在軟件需求分析階段,測試還沒有開始,隨著軟件系統規模和復雜性的不斷擴大,這個觀點得到了糾正。DOROTHY[1]指出,在軟件的需求分析階段,測試就開始介入的話,能夠使得軟件的需求分析更加詳盡。需求分析的越詳盡,到軟件驗收時功能性錯誤會越少[2]。

對于軟件需求規格說明書(Software Requirement Specfication，SRS)的測試并沒有一個系統的方法,一般采用靜態測試方法。為了提高軟件的質量,可以采用比較嚴謹的沒有二義性的形式化方法來完成SRS,對于形式化的SRS即可采用形式化的測試方法。形式化方法的基礎是數學和邏輯學,其結果語義清晰,無二義性[3]。但目前大部分人為了簡單方便則采用一種半形式化方法即自然語言和邏輯模型(數據流圖、數據字典)或用例模型(用例圖)來描述,因此錯誤難免。衡量SRS質量的標準是準確、全面、適宜的描述用戶的功能需求和非功能需求。對于半形式化方法描述SRS,主要采用靜態測試方法即:正式的會議評審和非正式的面對面討論、走查等方法來發現與用戶需求不一致、描述不完整、不正確、不清楚及書寫不規范等錯誤。

1.2 基本路徑測試方法

基本路徑測試方法是在程序控制流圖的基礎上,通過對程序控制流圖分析和判斷來計算環路復雜性,導出基本路徑集中的獨立路徑條數,然后根據獨立路徑條數來設計測試用例。設計出的測試用例能保證被測程序的路徑至少能通過一次,即每條可執行語句至少被執行一次。 基本路徑測試方法是一種白盒測試方法[4]。

環路復雜性是定量度量程序邏輯復雜度的一種尺度[5]。從程序的環路復雜性可以計算出程序中基本路徑集中的獨立路徑條數。這是確定被測程序中每一條語句至少被執行一次所必須的最大測試用例數。根據獨立路徑條數來設計測試用例,設計出的測試用例要保證基本路徑集中的每一條路徑必須要執行一次。

獨立路徑是指至少引入被測程序的一個新的可執行語句集或者一個新的條件路徑。一條獨立路徑至少應該包含有一條在其它獨立路徑中從未有過的邊的路徑[6]。由獨立路徑組成的基本路徑集合并不唯一,但每條路徑是唯一的。對于給定的程序流程控制圖,可以得到不同的基本路徑集合。

1.3 決策表測試方法

決策表測試方法是一種黑盒測試方法也稱功能測試法[7]。決策表也叫判定表，通常判定表在需求分析階段可以描述數據流圖中的加工邏輯,也可以在詳細設計階段對模塊的算法和數據結構進行描述,同時還是一種動態的功能測試方法。決策表是從輸入條件的完全組合來滿足測試的覆蓋率要求,具有很嚴格的邏輯性,所以在所有功能測試方法中,基于決策表的測試用例設計方法是最嚴格的,測試用例具有很高的完整性。比較適合描述不同條件集合下采取行動的若干組合情況,即對各個條件的組合進行分析,從而設計測試用例來覆蓋各種組合。決策表可以清晰地表明復雜的邏輯關系。一張決策表由4部分組成[8]:左上部是條件樁,列出被測程序所有的條件類別;右上部是條件項,表示條件樁中所有條件可能取值的組合;左下部是動作樁,表示所要執行的操作即結果列表;右下部是動作項,列出在條件項(各種取值)組合情況下應該采取的動作。在決策表中貫穿條件項和動作項的一列就是一條規則。

1.4 可視化測試方法

可視化測試方法的基本思想是將某圖形軟件處理以前的數據以及設計規則和處理以后的結果轉化成一種圖形進行對比,這樣可以很快做出正確、直觀的判別方法。為保證充分利用有限的屏幕顯示任意復雜的圖形,在實際中要認真考慮圖形的大小和形狀與屏幕之間的對應關系,通過鼠標操作對任一窗口的某一部分圖形進行還原和放大處理,并可以自動調整該圖形顯示窗口的上下左右位置,使放大以后的圖形在比較窗口內保持一致。窗口放大除了考慮放大比例外,還必須考慮窗口內的圖形放大以后仍然在屏幕的視區之內,放大比例有縱向與橫向兩種,總的放大比例為:

以印刷電路版圖為例進行測試,其處理算法為:

1) 先設圖形在x,y方向最大的外輪廓尺寸為mx和my;

2) 比較外輪廓尺寸在x軸方向和y軸方向的寬度mx和my的大小關系,以確定屏幕顯示區域上下左右劃分及最大限度地利用顯示屏來顯示更多的圖形數據信息的圖形框。具體操作步驟如下:

a.Ifmx

b.Ifmxmy則把屏幕分為上下兩個顯示區域,即為橫圖在顯示窗口的設置;

c. 把設計規則及圖形軟件處理前、后的數據文件轉換到對應的圖形顯示窗口,然后再選擇可視區域內的圖形進行比較、放大和測試,進而來測試圖形軟件的質量。

2 “數字檔案系統”的測試

2.1 “數字檔案系統”概述

數字檔案系統是某校數字校園信息門戶軟件中其中一個比較復雜的子系統,功能多、安全性要求高。數字檔案系統主要包括信息管理和系統管理,其中系統管理包括權限管理(角色管理、用戶管理)和信息配置管理(代碼庫、教師信息類管理);信息管理包括:教師綜合查詢、組織機構、學歷學位和職務職級等。

這些功能相對獨立又相互聯系,必須進行認真細致的需求分析、評審、設計測試用例、執行測試用例、錯誤缺陷報告,為了避免測試中產生新的更嚴重的錯誤則要進行回歸測試,使軟件質量不斷提高。

2.2 “數字檔案系統系統(SRS)”需求規格說明書的測試

對于軟件需求規格說明書(SRS)的測試屬于靜態測試[9]，評審SRS是軟件測試基礎性工作且是最重要的活動之一。如果沒有需求評審，那么在測試執行階段就會發現比較嚴重的缺陷，還有不少缺陷會留到產品發布之后，那么產品質量就會明顯下降[10]。如圖1所示，在需求分析階段如果有良好的需求評審，產品從測試階段直到遞交給用戶缺陷數量會越來越少；但如果沒有進行需求評審，到了測試執行階段就會發現多而嚴重的缺陷。缺陷發現的越晚系統成本越高，質量就越低。

圖1 需求評審對缺陷分布的影響Fig.1 Influence of demand assessment on the distribution of defects

本系統采用正式的評審會議和非正式的面對面討論、走查相結合形式完成用戶需求文檔的評審。

某一次正式評審會議的記錄如下。

參加人有:1位主持人,4位作者,5位專家,1位咨詢顧問,2位具體操作人員,2位記錄員。開始時間為14∶50,結束時間為17∶35 .評審文檔的規模為42頁;會議前發現問題29個,會議中發現問題7個,合計問題36個。主要功能性需求問題記錄:a.系統沒有分享功能;b.檢索功能太簡單,只有關鍵詞和標題;c.沒有用戶反饋功能;d.缺少在線咨詢、留言板等等。另外還有一些非功能性問題,比如，全校教工同時報崗,每秒能接受多少人安全登錄；大負載高峰期情況下系統響應時間如何。這些在本系統的SRS中描述不清楚。

會議最后咨詢顧問對一些問題做了點評。

1) 對問題的描述要注意，不要有二義性,要問題準確,位置準確;

2) 不在一個問題上花費太多的時間;

3) 不討論個人對一些描述風格的偏好;

4) 立項時最好能確定參與項目的評審專家;

5) 大家要心平氣和的討論問題。

通過以上對數字檔案系統SRS的靜態測試總結出以下幾點,供同行參考。

1) 靈活應用正式評審和非正式評審,兩種形式相結合使用;

2) 精心挑選評審員。各個層次的人員都要有,但不易太多;

3) 功能性需求和非功能性需求要分層次評審;

4) 為了降低需求返工的風險,可以采用分階段評審辦法,最好在需求形成的過程中進行分階段評審;

5) 建立標準的評審流程,做好評審后的跟蹤工作。

2.3 “數字檔案系統”模塊的測試

下面是該系統中一個簡單模塊的被測代碼。

Procedure exp(a,b:real; varx,y:real);

Begin

If (a>1 ANDb=0) then

x=x/a;

end if

if (a=2 ORx>1)then

x=x+1;

end if;

y=a+b;

end;

對于系統模塊的測試一般由開發人員執行,主要采用白盒方法,根據前面介紹的基本路徑測試技術生成測試用例的方法如下:

1) 根據被測代碼導出對應的程序流程控制圖,如圖2所示。

圖2 程序流程控制圖Fig.2 Program flow and program control chart

2) 依據程序流程控制圖計算環形復雜度。環形復雜度的計算方法有3種,一是可以通過程序流程控制圖的邊數和節點數計算;二是通過程序流程控制圖的判斷節點個數進行計算;三是通過程序流程控制圖的區域數目來計算。對于給定的程序流程控制圖的環形復雜度的值為環形復雜度邊數減去節點數加2或者判斷節點個數加1或者程序控制流圖區域的數目。區域是由節點和邊圍成的面積。要注意的是計算區域數目時要包括控制流圖外部并沒有被包圍進來的區域，即實際區域加1.本例采用判斷節點個數來計算。被測代碼的程序流程控制圖有兩個判斷節點1和3再加1則得到該程序流程控制圖的環形復雜度為3.

3) 根據流程控制圖的環形復雜度確定程序的獨立路徑數,通過以上分析和計算其環形復雜度為3,因此共有3條獨立路徑。下面給出一組3條獨立路徑:

路徑1:1—3—5

路徑2:1—2—3—5

路徑3:1—2—3—4—5

1—3—4—5不是獨立路徑,因為沒有新的邊加入。

4) 設計測試用例,確保基本路徑集中每一條路徑被執行一次。只要測試用例確保基本路徑組的執行,就可以說明程序中相應的代碼和程序邏輯是正確的。測試用例如表1所示。

表1 測試用例

3 結束語

文中介紹了幾種常用而又典型的軟件測試方法,最后結合實際案例給出了系統需求規格說明書的測試和基本路徑測試方法的應用,希望對軟件開發和測試人員在選擇測試方法和應用時有一定的啟發和幫助。

隨著軟件開發的不斷更新擴大,軟件測試方法和技術也在不斷變化,新的測試任務還很繁重,像云服務或云計算的測試,物聯網的測試等,都需要我們在軟件測試實踐中不斷學習不斷提高,在實際應用中不斷完善改進測試技術和方法,提高軟件質量。

[1] DOROTHY GRAHAM.REQUIREMENTS:Requirements and testing:seven missing-link myths[J].IEEE Software,2002,19(5):15-17.

[2] ADITYA P MATHUR.Foundations of software testing[M].北京:機械工業出版社,2011.

[3] 劉竹林.軟件測試技術與案例實踐[M].北京:北京師范大學出版社,2011.

[4] 趙磊,倫立軍,徐士華.基于軟件體系結構測試路徑生成方法[J].微電子學與計算機,2008，25(1)：177-180.

[5] 王鐵辰.軟件測試從入門到精通[M].北京:電子工業出版社,2010.

[6] 高春艷.基本路徑測試法的應用[J].開封大學學報,2012,26(2):81.

[7] 李金鵬.軟件測試技術理論與方法高效率化研究[J].數字技術與應用,2012(2):203.

[8] 聶長海.關于軟件測試的幾點思考[J].計算機科學,2011,38(2):1-3.

[9] 陳明.軟件測試[M].北京:機械工業出版社,2011.

[10] 朱少民.軟件測試方法和技術[M].北京:清華大學出版社,2010.

(編輯：賈麗紅)

Study and application of software test method

WU Zhaoyu,ZHANG Yueqin,YAN Hua

(CenterofInformationManagementandDevelopment,TaiyuanUniversityofTechnology,Taiyuan030024，China)

This paper discussed and researehed the static testing method,path-based white-box testing method and black-box testing method for software requirements specification.A visual test method and its application were proposed on testing graphics software.The processing algorithm and operation steps with PCB(Printed Circuit Board) for instance were proposed. Finally, the application of the testing methods based on software requirement specfication and basic path is illustrated by an actual case named “Digital File System”.This research provides some reference and help to the software development and testing personnel in the selection and application of test methods.

software quality;software testing;requirement specification;basic path;decision tables;visualization visual

1007-9432(2016)03-0379-05

2015-07-29

山西省科技基礎條件平臺建設資助項目：基于物聯網的城市智慧水務云管理平臺(2015091003-0103)

武昭宇(1985-),男,太原人,碩士生,主要從事軟件開發與測試研究，(E-mail)wuzhaoyu@tyut.edu.cn

張月琴,教授,主要從事軟件開發環境與工具及軟件測試研究，(E-mail)zhangyueqin@tyut.edu.cn

TP311

A

10.16355/j.cnki.issn1007-9432tyut.2016.03.019