軟件bug問題在軟件開發(fā)與維護(hù)過(guò)程中不可避免。隨著軟件項(xiàng)目規(guī)模的擴(kuò)大及軟件復(fù)雜性的增加,不斷出現(xiàn)新的bug問題,bug修復(fù)成了一項(xiàng)充滿難度和挑戰(zhàn)的工作。軟件歷史庫(kù)中bug報(bào)告與commit提交信息數(shù)量越積越多,對(duì)這些信息進(jìn)行管理和搜索也變得越來(lái)越困難。由于bug報(bào)告與commit信息被管理在分開的兩個(gè)系統(tǒng)中,且它們之間常常存在著關(guān)聯(lián)關(guān)系缺失等問題。因此,當(dāng)開發(fā)人員在bug庫(kù)中對(duì)bug信息進(jìn)行搜索時(shí),不僅會(huì)耗費(fèi)許多時(shí)間且得到的信息并不全面。在問答網(wǎng)站中尋求答案,也不能及時(shí)得到回復(fù),這都導(dǎo)致bug問題不能及時(shí)被修復(fù)。本文針對(duì)這些問題,構(gòu)建了 bug知識(shí)庫(kù)。后又在此基礎(chǔ)上構(gòu)建了 bug知識(shí)圖譜幫助開發(fā)人員搜索bug問題。不僅能為開發(fā)人員提供更全面的信息,更提高了開發(fā)人員解決bug問題的效率。本文工作主要集中在以下幾個(gè)方面:（1）對(duì)bug庫(kù)及commit庫(kù)中數(shù)據(jù)進(jìn)行分析,整合bug報(bào)告及commit信息,挖掘bug報(bào)告及commit中的顯示關(guān)系、隱式關(guān)系,構(gòu)建bug知識(shí)庫(kù)。（2）針對(duì)數(shù)據(jù)更新時(shí)間隨bug數(shù)量增加而越來(lái)越長(zhǎng)的問題,利用一種終身主題模型技術(shù)實(shí)現(xiàn)對(duì)bug知識(shí)庫(kù)的自動(dòng)更新。（3）針對(duì)現(xiàn)... 

【文章來(lái)源】：揚(yáng)州大學(xué)江蘇省

【文章頁(yè)數(shù)】：73 頁(yè)

【學(xué)位級(jí)別】：碩士

【部分圖文】：

buy報(bào)告裁圖

４?揚(yáng)州大學(xué)碩士學(xué)位論文???時(shí)描述修改的內(nèi)容，以便其他開發(fā)人員查看交流。因此，Ｇｉｔ庫(kù)中的ｃｏｍｍｉｔ詳細(xì)地記錄了??ｂｕｇ修復(fù)的相關(guān)信息，其中包括ｃｏｍｍｉｔ的標(biāo)題信息、ｃｏｍｍｉｔ?ＩＤ、提交人、提交日期及源??代碼中修改的內(nèi)容。ＧｉｔＨｕｂ［１４］＊管理的Ｍｏｚｉｌｌａ＠Ｂｕｇｚｉｌｌａ項(xiàng)目的ｃｏｍｍｉｔ信息截圖如圖１．３??所不。本文通過(guò)分析挖掘這些ｃｏｍｍｉｔ信息建立ｂｕｇ報(bào)告、開發(fā)人員與ｃｏｍｍｉｔ間的ｂｕｇ知??，ｕ。??

與搜索的內(nèi)容相似或相關(guān)，參評(píng)者將會(huì)判定該ｂｕｇ信息是相關(guān)的。然后，他們將會(huì)對(duì)相關(guān)??ｂｕｇ信息進(jìn)行計(jì)數(shù)。最終通過(guò)統(tǒng)計(jì)會(huì)分別計(jì)算出兩種方法的查準(zhǔn)率。??圖３．２和表３－１顯示了兩種方法查準(zhǔn)率的比較。在圖３．２中，藍(lán)色折線代表了本文方法??的查準(zhǔn)率整體情況，橘色折線代表了使用聚類方法實(shí)現(xiàn)丁具搜索結(jié)果的查準(zhǔn)率的整體情??況，每個(gè)點(diǎn)都代表了一個(gè)ｂｕｇ問題搜索結(jié)果的查準(zhǔn)率。正如圖３．２所顯示的，本文使用ＬＴＭ??模型構(gòu)建知識(shí)庫(kù)的方法的大部分查準(zhǔn)率相比于使用聚類方法的要更高。在表３－１中，我們??可以發(fā)現(xiàn)本文方法實(shí)現(xiàn)的工具的平均查準(zhǔn)率為６４．５３％，而使用聚類方法實(shí)現(xiàn)的工具的平均??查準(zhǔn)率為２０．３０％。造成這一結(jié)果的原因是，本文方法是結(jié)合ＬＴＭ模型對(duì)ｂｕｇ庫(kù)進(jìn)行構(gòu)建??的，ＬＴＭ模型是從ｂｕｇ報(bào)告、ｃｏｍｍｉｔ數(shù)據(jù)中提取主題，并根據(jù)主題的分布對(duì)這些ｂｕｇ信??


本文編號(hào)：3409110