開(kāi)源程序的軟件缺陷分布特征的量化分析研究

劉柯宏，劉曉建

（1.西安市第26中學(xué)，陜西 西安 710001；2.西安科技大學(xué) 計(jì)算機(jī)學(xué)院，陜西 西安 710054）

0 引言

在航天、核電、金融、軍事等安全攸關(guān)領(lǐng)域，人們對(duì)軟件的安全可靠性提出了很高要求[1,2,3]。軟件安全性是指避免危險(xiǎn)條件發(fā)生，保證人員、設(shè)施等免于遭受災(zāi)難性事故或重大損失的能力，軟件可靠性是指軟件在規(guī)定條件下，在規(guī)定的時(shí)間內(nèi)完成規(guī)定任務(wù)的能力[4,5]。軟件缺陷是影響軟件安全性和可靠性的重要因素。研究軟件缺陷的基本性質(zhì)，發(fā)掘軟件缺陷的內(nèi)在規(guī)律，對(duì)于提高軟件的安全性和可靠性，對(duì)于保障軟件系統(tǒng)的安全可靠運(yùn)行具有重要意義。

目前為止，人們對(duì)軟件缺陷的性質(zhì)以及內(nèi)在規(guī)律的研究仍具有一定局限性。主要原因是，關(guān)于軟件缺陷的一手?jǐn)?shù)據(jù)資料很不全面。傳統(tǒng)的軟件開(kāi)發(fā)局限在特定的機(jī)構(gòu)中，軟件缺陷的記錄、跟蹤和排除作為機(jī)構(gòu)的技術(shù)資料一般并不對(duì)外公開(kāi)。對(duì)于不成熟的開(kāi)發(fā)機(jī)構(gòu)，開(kāi)發(fā)過(guò)程中軟件缺陷的記錄和跟蹤資料并不完整。由于軟件缺陷數(shù)據(jù)的欠缺和不完整，使得人們很難從宏觀和統(tǒng)計(jì)的角度發(fā)掘軟件缺陷的基本性質(zhì)和基本規(guī)律[12,13]。近年來(lái)，由于開(kāi)源代碼和軟件庫(kù)的出現(xiàn)，使得開(kāi)源程序的缺陷得以記錄和跟蹤，并通過(guò)缺陷庫(kù)對(duì)外公開(kāi)，這就為有關(guān)軟件缺陷的研究提供了第一手?jǐn)?shù)據(jù)資料，并為使用定量分析手段發(fā)現(xiàn)軟件缺陷的宏觀性質(zhì)和規(guī)律提供了數(shù)據(jù)基礎(chǔ)[6,11]。

本文首先明晰軟件缺陷的基本概念，然后分析互聯(lián)網(wǎng)上幾個(gè)重要的軟件缺陷庫(kù)，然后在這些缺陷庫(kù)的基礎(chǔ)上使用數(shù)據(jù)分析方法試圖發(fā)現(xiàn)一些軟件缺陷的性質(zhì)和規(guī)律。這一研究工作對(duì)于人們認(rèn)識(shí)軟件缺陷的規(guī)律，并在開(kāi)發(fā)中避免和排除軟件缺陷具有重要意義。

1 軟件缺陷

SW-CMM對(duì)軟件缺陷的定義是：“系統(tǒng)或系統(tǒng)成分中使得這些系統(tǒng)無(wú)法實(shí)現(xiàn)其所要求的功能的缺點(diǎn)；如果在執(zhí)行過(guò)程中遇到缺陷,它可能導(dǎo)致系統(tǒng)的失效”[7]。軟件錯(cuò)誤(Error)、軟件故障(Fault)、軟件失效(Failure)、Bug、問(wèn)題(Problem)等概念不完全等同于軟件缺陷：軟件錯(cuò)誤一般指在軟件開(kāi)發(fā)過(guò)程中的一些人為的技術(shù)性錯(cuò)誤；軟件缺陷，即通常提到的Bug，表示軟件存在不足，不能完全符合軟件開(kāi)發(fā)要求；軟件故障一般指在軟件運(yùn)行過(guò)程中出現(xiàn)了執(zhí)行錯(cuò)誤，使軟件不能正常運(yùn)行，而軟件失效是指軟件在運(yùn)行過(guò)程中不能完全執(zhí)行既定的操作。軟件故障和失效都是軟件缺陷的一種外在表現(xiàn)[8,17]。

軟件缺陷開(kāi)始時(shí)處于休眠狀態(tài)，只有在特定條件下，軟件缺陷才能被激活。在構(gòu)件化或模塊化軟件中，一個(gè)構(gòu)件（或模塊）中的缺陷被激活后，會(huì)在構(gòu)件內(nèi)部引起狀態(tài)偏差，這種偏差隨著程序的運(yùn)行在構(gòu)件內(nèi)部不斷傳播，最終傳播到構(gòu)件的輸出接口。當(dāng)另一些構(gòu)件使用這些輸出接口時(shí)，這些狀態(tài)偏差就會(huì)進(jìn)一步傳播到這些構(gòu)件中，導(dǎo)致這些構(gòu)件或軟件系統(tǒng)發(fā)生故障或失效。我們把軟件缺陷的這一傳播過(guò)程成為軟件缺陷的“威脅鏈”[18,19]。

軟件缺陷的分類(lèi)方法主要有：Putnam等人提出的簡(jiǎn)單分類(lèi)法；國(guó)家軍用標(biāo)準(zhǔn)GJB2437的軟件錯(cuò)誤分類(lèi)方法；Thayer等人提出的利用軟件錯(cuò)誤性質(zhì)分類(lèi)方法，以及美國(guó)IBM公司提出的正交缺陷分類(lèi)法等[9]。簡(jiǎn)單分類(lèi)方法一般將軟件缺陷分為需求缺陷、設(shè)計(jì)缺陷、算法缺陷、性能缺陷、文檔缺陷和界面缺陷等六大類(lèi)；國(guó)家軍用標(biāo)準(zhǔn)GJB2437根據(jù)軍用軟件的軟件錯(cuò)誤來(lái)源，將軟件缺陷分為程序錯(cuò)誤、文檔錯(cuò)誤、設(shè)計(jì)錯(cuò)誤三類(lèi)；IBM正交缺陷法（ODC）從七個(gè)方面對(duì)缺陷進(jìn)行了分類(lèi)，即賦值、檢驗(yàn)、算法、時(shí)序、接口、功能、關(guān)聯(lián)。根據(jù)軟件缺陷對(duì)軟件所產(chǎn)生的影響程度的不同，把軟件缺陷的嚴(yán)重性級(jí)別分為輕微、一般、嚴(yán)重和致命。

2 軟件缺陷數(shù)據(jù)庫(kù)

為了記錄開(kāi)發(fā)過(guò)程中的軟件缺陷，并進(jìn)行有效的分析，需要形成軟件缺陷數(shù)據(jù)庫(kù)。比較典型的軟件缺陷數(shù)據(jù)庫(kù)有：NIST、Bugtrap和Bugzilla[10]。NIST是由美國(guó)國(guó)家標(biāo)準(zhǔn)與技術(shù)研究院提供的一個(gè)軟件缺陷數(shù)據(jù)庫(kù)，提供了通用缺陷列表以及為部分代碼缺陷模式所編寫(xiě)的測(cè)試用例。BugTrap軟件缺陷數(shù)據(jù)庫(kù)是由Security Focus公司開(kāi)發(fā)并維護(hù)的軟件缺陷數(shù)據(jù)庫(kù)，為用戶(hù)提供了5種檢索方式[15]：軟件提供商、標(biāo)題、關(guān)鍵字、BugTrap ID和CVE ID。Bugzilla軟件缺陷庫(kù)，是一個(gè)開(kāi)源的軟件缺陷跟蹤系統(tǒng)，為開(kāi)發(fā)和測(cè)試工作以及產(chǎn)品質(zhì)量的度量提供數(shù)據(jù)支持，可以很好的管理軟件開(kāi)發(fā)過(guò)程中軟件缺陷的整個(gè)生命周期[16,20]。

為了更好的分析軟件缺陷的性質(zhì)，發(fā)掘其規(guī)律，需要了解軟件缺陷的描述。下面以Bugzilla為例，介紹描述軟件缺陷的各個(gè)屬性，如表1所示。

在上述屬性中，嚴(yán)重性級(jí)別、提交后的狀態(tài)和最終處理狀態(tài)對(duì)于分析軟件缺陷具有特別重要的意義。

軟件缺陷的嚴(yán)重性級(jí)別分為5類(lèi)： normal（正常）、low（低級(jí)）、high（高級(jí)）、blocking（阻塞）和enhancement（增強(qiáng)）；軟件缺陷的提交狀態(tài)被分為5類(lèi)：New（該缺陷有效，但未進(jìn)行處理）、Assigned（該缺陷將由特定的維護(hù)者處理）、Reopened（新維護(hù)者對(duì)已經(jīng)修改的缺陷進(jìn)行再次處理）、Resolved（該缺陷已被某維護(hù)者處理并且沒(méi)有新的缺陷產(chǎn)生）和Needinfo（表示需要提供更多的信息才可以妥善解決該軟件缺陷）；而最終處理狀態(tài)也被分為5類(lèi)：Fixed（該缺陷被認(rèn)為有效且被維護(hù)者進(jìn)行了有效處理）、Wontfix（表示缺陷無(wú)法修復(fù)，可以忽略，不會(huì)對(duì)系統(tǒng)產(chǎn)生影響）、Invalid（表示缺陷是無(wú)效的）、Duplicate（表示相同的缺陷報(bào)告被不同的維護(hù)者重復(fù)提交）和Worksforme（表示不會(huì)重復(fù)出現(xiàn)的缺陷）。

表1 軟件缺陷的屬性Table 1 The properties of software defects

3 研究方法

采用統(tǒng)計(jì)方法研究開(kāi)源軟件的缺陷基本特征和規(guī)律。研究步驟包括：（1）選擇具有代表性的開(kāi)源軟件作為研究對(duì)象；（2）獲取這些開(kāi)源軟件的軟件缺陷數(shù)據(jù)；（3）對(duì)缺陷數(shù)據(jù)進(jìn)行處理，得到軟件缺陷的分布以及演變狀況；（4）試圖通過(guò)軟件開(kāi)發(fā)過(guò)程以及軟件結(jié)構(gòu)來(lái)解釋統(tǒng)計(jì)結(jié)果，形成對(duì)軟件缺陷基本規(guī)律的認(rèn)識(shí)。下面分別對(duì)前三個(gè)步驟進(jìn)行展開(kāi)。

選取Linux、Firefox和Tomcat三種大型開(kāi)源軟件作為研究對(duì)象，一是它們具有較強(qiáng)的代表性，分別代表了操作系統(tǒng)、瀏覽器和Web服務(wù)器這三類(lèi)最常用的基礎(chǔ)軟件；二是規(guī)模較大，開(kāi)發(fā)過(guò)程較成熟，因此從中獲取的缺陷數(shù)據(jù)具有較好的代表性；三是它們的缺陷數(shù)據(jù)較為豐富，便于發(fā)揮統(tǒng)計(jì)分析方法的優(yōu)勢(shì)。

采用Bugzilla作為獲取缺陷數(shù)據(jù)的主要來(lái)源。Bugzilla保存的缺陷數(shù)據(jù)較為完整，數(shù)據(jù)查詢(xún)接口易于使用。實(shí)際上，對(duì)于很多軟件缺陷，都有統(tǒng)一的CVE編號(hào)，這就使得軟件缺陷可以跨越不同數(shù)據(jù)庫(kù)得到標(biāo)識(shí)和共享。

軟件缺陷數(shù)據(jù)處理主要包括兩個(gè)維度：缺陷數(shù)量統(tǒng)計(jì)和軟件版本。缺陷數(shù)量統(tǒng)計(jì)分為總數(shù)統(tǒng)計(jì)和分屬性統(tǒng)計(jì)，即按照缺陷的嚴(yán)重性、提交后的狀態(tài)以及處理狀態(tài)分別進(jìn)行數(shù)量統(tǒng)計(jì)。另外，為了分析缺陷數(shù)量的動(dòng)態(tài)變化規(guī)律，還需要統(tǒng)計(jì)各個(gè)版本的缺陷數(shù)量。

圖1 Tomcat、Firefox與Linux三者缺陷數(shù)量隨版本變化的趨勢(shì)Fig.1 The number of software defects of Tomcat, Firefox and Linux, and their variations with version change

4 分析結(jié)果

根據(jù)研究步驟，從Bugzilla中獲取了Linux、Firefox和Tomcat各個(gè)版本的缺陷數(shù)量總計(jì)約13,420條。圖1是這三類(lèi)開(kāi)源程序的缺陷數(shù)量隨版本變化的情況。

從中可以看到三者的缺陷數(shù)量整體上逐漸降低并最終逐漸趨于平穩(wěn)，即隨著軟件版本的不斷升級(jí)、產(chǎn)品的不斷穩(wěn)定，軟件的缺陷率會(huì)呈下降趨勢(shì)，但是局部仍存在波動(dòng)。

選取了Status、Resolution和Severity三個(gè)屬性，分別統(tǒng)計(jì)了不同屬性的缺陷數(shù)量，如表2所示。

表2 分屬性缺陷數(shù)量統(tǒng)計(jì)Table 2 Statistics for the typical properties of software defects

從統(tǒng)計(jì)數(shù)據(jù)可見(jiàn)，三種開(kāi)源程序中，約90%的缺陷已經(jīng)得到了解決（Resolved），約50%的缺陷確認(rèn)為有意義并得到了修改（Fixed），還有約50%的缺陷是無(wú)效的（Invalid和其他）。這一數(shù)字與實(shí)際開(kāi)發(fā)是吻合的。比如在一個(gè)大型商業(yè)軟件的第三方測(cè)試中，軟件缺陷報(bào)告中的547條缺陷中最終只有265條被開(kāi)發(fā)部門(mén)認(rèn)同并修改，這個(gè)比例為48%[11]。另外，大約只有50～70%的軟件缺陷都是中等嚴(yán)重性的（Normal），高嚴(yán)重性的缺陷只占10～20%，剩下的缺陷都是低嚴(yán)重性的。

通過(guò)上面這些統(tǒng)計(jì)數(shù)據(jù)，大致可以得出結(jié)論：在軟件產(chǎn)品的軟件缺陷報(bào)告中通常有近乎50%的軟件缺陷是處于無(wú)效狀態(tài)的，即這些缺陷不需要修復(fù)，也不會(huì)對(duì)軟件造成大的影響。因此，如果能夠?qū)浖毕輬?bào)告數(shù)據(jù)先進(jìn)行一定的數(shù)據(jù)預(yù)處理，去除掉重復(fù)或無(wú)效的軟件缺陷，將會(huì)有利于軟件開(kāi)發(fā)周期的縮短和軟件開(kāi)發(fā)成本的降低。

通過(guò)對(duì)Bugzilla缺陷庫(kù)中13,420條軟件缺陷報(bào)告的分析和總結(jié)，研究發(fā)現(xiàn)造成軟件缺陷的原因有很多，主要?dú)w結(jié)為以下幾點(diǎn)：

（1）軟件構(gòu)件的變化。主要有軟件構(gòu)件數(shù)目、規(guī)模大小等因素。即使構(gòu)件本身沒(méi)有缺陷，當(dāng)它被引入時(shí)，在一定程度上可能會(huì)引起缺陷。比如，在版本7.0以前，Tomcat的Connectors構(gòu)件的缺陷數(shù)目一直保持著0水平，而在版本7.0之后開(kāi)始呈現(xiàn)出正常的波形狀態(tài)，這是由于版本7.0之前Connectors這個(gè)構(gòu)件并沒(méi)有被引入，而是在此之后新加入的軟件構(gòu)件，這引起了軟件構(gòu)件數(shù)量和規(guī)模的變化，一定程度上引入了新的缺陷。

（2）程序代碼編寫(xiě)錯(cuò)誤。這與開(kāi)發(fā)人員的能力和經(jīng)驗(yàn)有關(guān)，即便能力再高、經(jīng)驗(yàn)再豐富的開(kāi)發(fā)人員所編寫(xiě)的軟件也一定會(huì)有程序缺陷出現(xiàn)。

（3）程序編寫(xiě)不規(guī)范。在軟件程序的編寫(xiě)過(guò)程中，需要大量的開(kāi)發(fā)人員和測(cè)試人員相互配合，因此需要程序編寫(xiě)有統(tǒng)一的規(guī)范，否則就會(huì)帶來(lái)相互不理解、“各編各的”現(xiàn)象，帶來(lái)不必要的軟件缺陷。

（4）軟件功能模塊的復(fù)雜化。由于軟件的功能不斷增多，致使軟件的結(jié)構(gòu)也在不斷增大，變得越來(lái)越復(fù)雜，進(jìn)而會(huì)給軟件的質(zhì)量產(chǎn)生影響。例如，在100行的程序代碼中，程序缺陷的數(shù)量和代碼的行數(shù)是成線性的關(guān)系，但如果超過(guò)100行，程序缺陷的數(shù)量則和代碼的行數(shù)成指數(shù)的關(guān)系。因此，軟件越龐大，軟件缺陷也就越多。

5 結(jié)論

本文首先介紹了Bugzilla、NIST、BugTrap等三種軟件缺陷庫(kù)及其查詢(xún)接口，針對(duì)Tomcat、Firefox和Linux三個(gè)開(kāi)源軟件，分析了軟件缺陷總數(shù)隨不同版本的變化過(guò)程，統(tǒng)計(jì)了軟件缺陷幾項(xiàng)重要屬性的分布規(guī)律，在此基礎(chǔ)上歸納了造成軟件缺陷的幾項(xiàng)重要原因。通過(guò)對(duì)軟件缺陷性質(zhì)和規(guī)律的研究，為軟件缺陷的預(yù)防和發(fā)掘起到指導(dǎo)性作用，從而在一定程度上提高軟件可靠性和軟件安全性。下一步的工作將集中于兩點(diǎn)：一是獲取大量的一手缺陷數(shù)據(jù)，在此基礎(chǔ)上更細(xì)粒度的分析軟件屬性的分布及變化規(guī)律；二是研究軟件結(jié)構(gòu)變化與軟件缺陷之間的關(guān)系，從而能夠?qū)σ鹑毕莸能浖?nèi)部結(jié)構(gòu)因素得出有意結(jié)論。

[1] 竇真蘭，杜鳳青. 電力系統(tǒng)節(jié)能策略和方法分析[J]. 新型工業(yè)化. 2015，5（10）：1-6.DOU Zhen-lan;DU Feng-qing，Research on the Energy-saving Strategies and the Methods for Power System[J].The Journal of New Industrialization. 2015，5（10）：1-6.

[2] 牛成林. 基于數(shù)據(jù)倉(cāng)庫(kù)的數(shù)據(jù)挖掘的電站決策支持系統(tǒng)[J]. 新型工業(yè)化. 2017，17（7）：62-67.NIU Cheng-lin. Operation Optimization Decision Support System in Power Plant Based on Data Warehouse and Data Mining[J]. The Journal of New Industrialization. 2017，17（7）：62-67.

[3] 王峰. 物聯(lián)網(wǎng)數(shù)據(jù)處理若干關(guān)鍵問(wèn)題[D]. 吉林：吉林大學(xué)，2016.WANG Feng. Research on Several Key Issues in Data Processing in the Internet of Things[D]. Jinlin：Jinlin University，2016.

[4] 朱媛媛.軟件安全性測(cè)試與評(píng)估方法研究[D].江蘇：江蘇大學(xué)，2013.ZHU Yuan-yuan. Research on software security testing and evaluation method[D]. Jiangsu：Jiangsu University，2013.

[5] 黃錫滋.軟件可靠性、安全性與質(zhì)量保證[M].北京：電子工業(yè)出版社，2002.HUANG Xi-zi. Software reliability，security and quality assurance[M]. Beijing：Electronic Industry Press，2002.

[6] 周明輝，郭長(zhǎng)國(guó). 基于大數(shù)據(jù)的軟件工程新思維[J]. 中國(guó)計(jì)算機(jī)學(xué)會(huì)通訊，2014，10（3）：37-42.ZHOU Ming-hui，GUO Chang-guo. New thinking of software engineering based on big data[J]. Communications of Chinese Computer Society. 2014，10（3）：37-42.

[7] Park C Paulk，et al. Capability Maturity Model for Software[R].Pittsburgh，Pennsylvania：Carnegie Mellon University，1993.

[8] Avizienis A，Laprie J C，Randell B，et al. Basic concepts and taxonomy of dependable and secure computing[J]. IEEE Transactions on Dependable and Secure Computing. 2004，1（1）：11-33.

[9] Ram Chillarege，et al. Orthogonal Defect Classification：A Concept for In-process Measurements[J].IEEE Transactions on Software Engineering. 1992，18（11）：943-956.

[10] https：//www.bugzilla.org/

[11] 李寧，李戰(zhàn)懷.軟件缺陷數(shù)據(jù)處理研究綜述[J].計(jì)算機(jī)科學(xué).2009，36（8）：21-25.LI Ning，LI Zhan-huai. Overview of Software Defect Data Processing Research[J]. Computer Science. 2009，36（8）：21-25.

[12] 郁抒思，周水庚，關(guān)佶紅.軟件工程數(shù)據(jù)挖掘研究進(jìn)展[J].計(jì)算機(jī)科學(xué)與探索. 2012，6（1）：1?31.YU Shu-Si，ZHOU Shui-geng，GUAN Ji-hong. Software engineering data mining：A survey[J]. Journal of Frontiers of Computer Science and Technology. 2012，6（1）：1?31.

[13] 原子，于莉莉，劉超.面向細(xì)粒度源代碼變更的缺陷預(yù)測(cè)方法[J].軟件學(xué)報(bào). 2014，25（11）：2499?2517.YUAN Zi，YU Li-li，LIU Chao. Bug prediction method for fine-grained source code changes[J]. Journal of Software. 2014，25（11）：2499?2517.

[14] 王青，伍書(shū)劍，李明樹(shù).軟件缺陷預(yù)測(cè)技術(shù).軟件學(xué)報(bào)[J]. 2008，19（7）：1565?1580.WANG Qing，WU Shu-jian，LI Ming-Shu. Software defect prediction[J]. Journal of Software. 2008，19（7）：1565?1580.

[15] 哈清華，姜瑞凱，劉邏. 軟件缺陷的生成因素分析[J]. 計(jì)算機(jī)技術(shù)與發(fā)展，2016，26（1）：1-5.HA Qing-hua，JIANG Rui-kai，LIU Luo. Analysis of Forming Factors in Software Defect[J]. Computer Technology and Development，2016，26（1）：1-5.

[16] 王婧宇，張欣，鄒衛(wèi)琴. 基于分類(lèi)的軟件缺陷嚴(yán)重性預(yù)測(cè)[J]. 計(jì)算機(jī)與數(shù)字工程. 2016，44（8）：1532-1536.WANG Jing-yu，ZHANG Xin，ZOU Wei-qin. Severity Predication of Software Defects Based on Classification[J]. Computer and Digital Engineering. 2016，44（8）：1532-1536.

[17] 陳翔，顧慶，劉樹(shù)龍等. 靜態(tài)軟件缺陷預(yù)測(cè)方法研究[J]. 軟件學(xué)報(bào). 2016，27（1）：1-25.CHEN Xiang，GU-Qing，LIU Shu-long. Survey of Static Software Defect Predication[J]. Journal of Software. 2016，27（1）：1-25.

[18] Ricky，Michael Yoseph，F(xiàn)redy Purnomo，and Budi Yulianto. Mobile Application Software Defect Prediction[C]. Service Oriented Software Engineering（2016）：307-313.

[19] Lanza，Michele，Andrea Mocci，and Luca Ponzanelli. The Tragedy of Defect Prediction，Prince of Empirical Software Engineering Research[J]. IEEE Software，2016，33（2016）：102-105.

[20] Vashisht，Vipul，Manohar Lal，and G. Sureshchandar. A Framework for Software Defect Prediction Using Neural Networks[J]. Journal of Software Engineering and Applications. 2015，28（8）：384-394.