本發(fā)明屬于軟件維護(hù)領(lǐng)域，特別涉及面向軟件修改的風(fēng)險(xiǎn)分析方法。
背景技術(shù)：
：由于軟件工程的復(fù)雜性，軟件開發(fā)與維護(hù)過程中常常會(huì)出現(xiàn)軟件漏洞，這些漏洞導(dǎo)致大量的人力、物力的損失，因此軟件質(zhì)量問題就成為軟件工程研究領(lǐng)域重要的分區(qū)之一。如今有很多研究著眼于軟件質(zhì)量的預(yù)測(cè)，許多軟件分析和預(yù)測(cè)工作提出了關(guān)于軟件度量、軟件模型的方法，用來準(zhǔn)確地分析和預(yù)測(cè)軟件質(zhì)量。但當(dāng)前的分析和預(yù)測(cè)技術(shù)的采納率非常低，針對(duì)軟件質(zhì)量的分析和預(yù)測(cè)仍是一個(gè)難題，因?yàn)槿狈ο鄳?yīng)的可以被實(shí)際操作的工具。另外，開發(fā)者在提交修改時(shí)，由于多方面的因素，可能會(huì)導(dǎo)致提交誘導(dǎo)出更多bug，從而造成開發(fā)人員的不斷維護(hù)，增加了軟件維護(hù)的成本。為了提高軟件維護(hù)質(zhì)量，降低軟件維護(hù)帶來的風(fēng)險(xiǎn)，目前軟件維護(hù)研究領(lǐng)域出現(xiàn)了很多相關(guān)技術(shù)，這些技術(shù)主要都集中于研究如何更準(zhǔn)確地分析和預(yù)測(cè)提交修改的風(fēng)險(xiǎn)，一般是通過相關(guān)的軟件度量和軟件模型對(duì)軟件項(xiàng)目進(jìn)行分析和預(yù)測(cè)，也有一些相關(guān)的工具給出了宏觀的缺陷分布情況。但是，這些技術(shù)并沒有考慮到開發(fā)人員的開發(fā)歷史以及相關(guān)bug評(píng)論中內(nèi)容，使得針對(duì)提交信息的分析并不完善，同時(shí)并沒有提供直觀的風(fēng)險(xiǎn)預(yù)測(cè)結(jié)果和缺陷產(chǎn)生的原因，開發(fā)人員并不能清晰地了解到當(dāng)前修改提交出現(xiàn)風(fēng)險(xiǎn)的原因，還需要自行根據(jù)統(tǒng)計(jì)數(shù)據(jù)予以確定，缺少對(duì)整個(gè)軟件提交的具體分析和解釋，使軟件維護(hù)的過程更加困難。技術(shù)實(shí)現(xiàn)要素：本發(fā)明的目的就在于克服上述缺陷，研制面向軟件修改的風(fēng)險(xiǎn)分析方法。本發(fā)明的技術(shù)方案是：面向軟件修改的風(fēng)險(xiǎn)分析方法，其主要技術(shù)特征在于如下步驟：(1)使用TF-IDF算法提取出關(guān)鍵詞并反饋給開發(fā)人員，用余弦函數(shù)對(duì)預(yù)處理后的提交信息與歷史提交信息庫和bug庫進(jìn)行相似度計(jì)算，識(shí)別與當(dāng)前提交相似度較高的歷史提交和bug，并根據(jù)提交信息和相關(guān)bug庫，提取出bug編號(hào)、bug相關(guān)狀態(tài)、bug的嚴(yán)重性、與其他bug的聯(lián)系等相關(guān)信息，形成一個(gè)修改提交，相關(guān)信息的對(duì)應(yīng)列表，作為后續(xù)步驟的參考，以及bug可能出現(xiàn)reopen的風(fēng)險(xiǎn)性的一個(gè)考察；(2)在當(dāng)前提交信息的開發(fā)人員的歷史提交信息庫中，通過統(tǒng)計(jì)，得出該開發(fā)者對(duì)于同一軟件漏洞的多次修改的次數(shù)，以及修改的漏洞出現(xiàn)reopen的次數(shù)，與該項(xiàng)目所有開發(fā)者的對(duì)于同一軟件漏洞的多次修改的次數(shù)，以及修改的漏洞出現(xiàn)reopen的次數(shù)平均值進(jìn)行比較，記比較后的偏移量為p；若統(tǒng)計(jì)次數(shù)高于平均值且p＞10％，開發(fā)者能力評(píng)估為低；統(tǒng)計(jì)次數(shù)高于平均值且p＜10％，開發(fā)者能力評(píng)估為中；統(tǒng)計(jì)次數(shù)低于平均值，開發(fā)者能力評(píng)估為高；若開發(fā)者能力評(píng)估較低，則表明針對(duì)同一軟件漏洞出現(xiàn)多次非計(jì)劃性的修改提交和reopen記錄，則表明該開發(fā)者可能經(jīng)驗(yàn)不足，當(dāng)前的提交信息具有較高的風(fēng)險(xiǎn)；(3)根據(jù)提交信息中的代碼，查看提交信息中的代碼變更，統(tǒng)計(jì)刪除，增加的代碼行數(shù)，查看修改涉及到的代碼中的文件、類、方法的具體信息，形成代碼更改的集合，規(guī)定一次修改提交文件、類、方法修改的次數(shù)的閾值分別為8，5，5，根據(jù)集合中的內(nèi)容，統(tǒng)計(jì)一次修改提交文件、類、方法修改的次數(shù)，將修改的文件、類、方法的個(gè)數(shù)與閾值進(jìn)行比較，若高于閾值，則說明該修改提交可能具有風(fēng)險(xiǎn)，且數(shù)值越高，風(fēng)險(xiǎn)性越大；統(tǒng)計(jì)它們?cè)跉v史修改庫中被開發(fā)人員重復(fù)修改的次數(shù)；如果被重復(fù)修改的次數(shù)過多，則說明該段代碼的穩(wěn)定性不高，而開發(fā)人員對(duì)此段代碼的修改提交也具有較高風(fēng)險(xiǎn)；(4)利用主題模型提取歷史相關(guān)bug中的評(píng)論，對(duì)評(píng)論中出現(xiàn)的bug報(bào)告評(píng)論中關(guān)鍵詞進(jìn)行分析，提取出一些主題特征；(5)將上述結(jié)果反饋給開發(fā)人員，根據(jù)bug可能出現(xiàn)reopen的風(fēng)險(xiǎn)，代碼的不穩(wěn)定性考察結(jié)果，開發(fā)者能力評(píng)估結(jié)果，bug報(bào)告的主題特征，形成風(fēng)險(xiǎn)特征說明，并給出相應(yīng)的風(fēng)險(xiǎn)解釋。附圖說明圖1——本發(fā)明流程示意圖。圖2——本發(fā)明相關(guān)修改提交信息示意圖。具體實(shí)施方式本發(fā)明的技術(shù)思路是：本發(fā)明從開發(fā)人員的工作能力，修改提交信息和修復(fù)的bug信息角度對(duì)修改提交進(jìn)行分析，為開發(fā)人員的修改提交提供了風(fēng)險(xiǎn)結(jié)果以及相應(yīng)的風(fēng)險(xiǎn)解釋。此方法不僅更準(zhǔn)確地對(duì)修改提交進(jìn)行了風(fēng)險(xiǎn)分析，而且結(jié)合了該開發(fā)人員的歷史提交信息和bug中的評(píng)論信息，供開發(fā)人員的修改提交進(jìn)行參考，并給出了缺陷產(chǎn)生的原因，有效地提高軟件維護(hù)質(zhì)量，降低軟件維護(hù)帶來的風(fēng)險(xiǎn)。如圖1所示：本發(fā)明步驟如下：步驟(1).使用TF-IDF算法提取出關(guān)鍵詞并反饋給開發(fā)人員，用余弦函數(shù)對(duì)預(yù)處理后的提交信息與歷史提交信息庫和bug庫進(jìn)行相似度計(jì)算，識(shí)別與當(dāng)前提交相似度較高的歷史提交和bug，，并根據(jù)提交信息和相關(guān)bug庫，提取出bug編號(hào)、bug相關(guān)狀態(tài)、bug的嚴(yán)重性、與其他bug的聯(lián)系等相關(guān)信息。形成一個(gè)<修改提交，相關(guān)信息>對(duì)應(yīng)列表，作為后續(xù)步驟的參考，以及bug可能出現(xiàn)reopen的風(fēng)險(xiǎn)性的一個(gè)考察。當(dāng)前bug信息的對(duì)應(yīng)列表就作為風(fēng)險(xiǎn)性的一個(gè)考察指標(biāo)，開發(fā)人員通過了解相關(guān)的bug信息，知道提交修改中的不足，降低對(duì)軟件漏洞的重復(fù)修復(fù)。例如：其中<bug_id>、<keywords>、<who>、<bug_status>被用來作參考。提取出的相關(guān)信息<bug_id>679494<keywords>patch，review<who>birunthan<bug_status>RESOLVEDFIXED其中<bug_importance>、<bug_priority>、<component>、<dependson>、<blocks>、<reported_time>、<modified_time>被用為作為bug可能出現(xiàn)reopen的風(fēng)險(xiǎn)性考察上述TF-IDF算法：詞頻(TF)＝某個(gè)單詞在修改提交中出現(xiàn)的總次數(shù)/修改提交的總詞數(shù)。逆文檔頻率(IDF)＝log(修改提交總數(shù)/包含該單詞的修改提交數(shù)+1)。TF-IDF權(quán)值w＝TF*IDF權(quán)值高低說明關(guān)鍵詞是否反映了修改提交的主題。步驟(2).在當(dāng)前提交信息的開發(fā)人員的歷史提交信息庫中，通過統(tǒng)計(jì)，得出該開發(fā)者對(duì)于同一軟件漏洞的多次修改的次數(shù)，以及修改的漏洞出現(xiàn)reopen的次數(shù)，與該項(xiàng)目所有開發(fā)者的對(duì)于同一軟件漏洞的多次修改的次數(shù)，以及修改的漏洞出現(xiàn)reopen的次數(shù)平均值進(jìn)行比較，記比較后的偏移量為p。若統(tǒng)計(jì)次數(shù)高于平均值且p＞10％，開發(fā)者能力評(píng)估為低；統(tǒng)計(jì)次數(shù)高于平均值且p＜10％，開發(fā)者能力評(píng)估為中；統(tǒng)計(jì)次數(shù)低于平均值，開發(fā)者能力評(píng)估為高。若開發(fā)者能力評(píng)估較低，則表明針對(duì)同一軟件漏洞出現(xiàn)多次非計(jì)劃性的修改提交和reopen記錄，則表明該開發(fā)者可能經(jīng)驗(yàn)不足，當(dāng)前的提交信息具有較高的風(fēng)險(xiǎn)。通過對(duì)開發(fā)者能力的評(píng)估，得出當(dāng)前提交信息具有風(fēng)險(xiǎn)性的可能，作為降低軟件維護(hù)風(fēng)險(xiǎn)的一個(gè)指標(biāo)。例如：對(duì)于同一軟件漏洞的多次修改的次數(shù)的平均值為2.46，該開發(fā)者修改次數(shù)為2，能力評(píng)估為高。修改的漏洞出現(xiàn)reopen的次數(shù)平均值為3.19，該開發(fā)者的次數(shù)為4，P≈0.2025＝20.25％＞10％，開發(fā)者此項(xiàng)能力評(píng)估為低。步驟(3).根據(jù)提交信息中的代碼，提取代碼變更。統(tǒng)計(jì)刪除，增加的代碼行數(shù)，查看修改涉及到的代碼中的文件、類、方法的具體信息，形成代碼更改的集合。規(guī)定一次修改提交文件、類、方法修改的次數(shù)的閾值分別為8，5，10，根據(jù)集合中的內(nèi)容，統(tǒng)計(jì)一次修改提交文件、類、方法修改的次數(shù)，將修改的文件、類、方法的個(gè)數(shù)與閾值進(jìn)行比較，若高于閾值，則說明該修改提交可能具有風(fēng)險(xiǎn)，且數(shù)值越高，風(fēng)險(xiǎn)性越大。統(tǒng)計(jì)它們?cè)跉v史修改庫中被開發(fā)人員重復(fù)修改的次數(shù)。如果被重復(fù)修改的次數(shù)過多，則說明該段代碼的穩(wěn)定性不高，而開發(fā)人員對(duì)此段代碼的修改提交也具有較高風(fēng)險(xiǎn)。根據(jù)提取的代碼變更集合，使開發(fā)者明確修改的代碼的穩(wěn)定性，供開發(fā)人員參考，避免重復(fù)修改。例如：修改提交號(hào)為4e9065b的統(tǒng)計(jì)信息如下：修改的方法個(gè)數(shù)高于閾值，修改的文件個(gè)數(shù)和修改的類個(gè)數(shù)低于閾值。修改的代碼段在歷史修改庫中被重復(fù)修改3次。步驟(4).利用主題模型提取bug中的評(píng)論，對(duì)評(píng)論中出現(xiàn)的bug報(bào)告評(píng)論中關(guān)鍵詞進(jìn)行分析，提取出一些主題特征。開發(fā)人員通過主題特征，了解當(dāng)前bug的修復(fù)狀況，了解當(dāng)前軟件提交所帶來的風(fēng)險(xiǎn)。例如：<bug_id>為701591的bug評(píng)論和相關(guān)的bug評(píng)論中，根據(jù)主題模型提取出的主題為failing。說明當(dāng)前的bug修復(fù)并沒有完成。https：//bugzilla.mozilla.org/show_bug.cgi？id＝701591步驟(5).將上述結(jié)果反饋給開發(fā)人員，根據(jù)bug可能出現(xiàn)reopen的風(fēng)險(xiǎn)，代碼的不穩(wěn)定性考察結(jié)果，開發(fā)者能力評(píng)估結(jié)果，bug報(bào)告的主題特征，形成風(fēng)險(xiǎn)特征說明，并給出相應(yīng)的風(fēng)險(xiǎn)解釋。方便測(cè)試人員更有針對(duì)的進(jìn)行回歸測(cè)試，從而提高軟件維護(hù)質(zhì)量，降低軟件維護(hù)帶來的風(fēng)險(xiǎn)。當(dāng)前第1頁1 2 3