面向软件修改的风险分析方法与流程

本发明属于软件维护领域，特别涉及面向软件修改的风险分析方法。
背景技术：
：由于软件工程的复杂性，软件开发与维护过程中常常会出现软件漏洞，这些漏洞导致大量的人力、物力的损失，因此软件质量问题就成为软件工程研究领域重要的分区之一。如今有很多研究着眼于软件质量的预测，许多软件分析和预测工作提出了关于软件度量、软件模型的方法，用来准确地分析和预测软件质量。但当前的分析和预测技术的采纳率非常低，针对软件质量的分析和预测仍是一个难题，因为缺乏相应的可以被实际操作的工具。另外，开发者在提交修改时，由于多方面的因素，可能会导致提交诱导出更多bug，从而造成开发人员的不断维护，增加了软件维护的成本。为了提高软件维护质量，降低软件维护带来的风险，目前软件维护研究领域出现了很多相关技术，这些技术主要都集中于研究如何更准确地分析和预测提交修改的风险，一般是通过相关的软件度量和软件模型对软件项目进行分析和预测，也有一些相关的工具给出了宏观的缺陷分布情况。但是，这些技术并没有考虑到开发人员的开发历史以及相关bug评论中内容，使得针对提交信息的分析并不完善，同时并没有提供直观的风险预测结果和缺陷产生的原因，开发人员并不能清晰地了解到当前修改提交出现风险的原因，还需要自行根据统计数据予以确定，缺少对整个软件提交的具体分析和解释，使软件维护的过程更加困难。技术实现要素：本发明的目的就在于克服上述缺陷，研制面向软件修改的风险分析方法。本发明的技术方案是：面向软件修改的风险分析方法，其主要技术特征在于如下步骤：(1)使用TF-IDF算法提取出关键词并反馈给开发人员，用余弦函数对预处理后的提交信息与历史提交信息库和bug库进行相似度计算，识别与当前提交相似度较高的历史提交和bug，并根据提交信息和相关bug库，提取出bug编号、bug相关状态、bug的严重性、与其他bug的联系等相关信息，形成一个修改提交，相关信息的对应列表，作为后续步骤的参考，以及bug可能出现reopen的风险性的一个考察；(2)在当前提交信息的开发人员的历史提交信息库中，通过统计，得出该开发者对于同一软件漏洞的多次修改的次数，以及修改的漏洞出现reopen的次数，与该项目所有开发者的对于同一软件漏洞的多次修改的次数，以及修改的漏洞出现reopen的次数平均值进行比较，记比较后的偏移量为p；若统计次数高于平均值且p＞10％，开发者能力评估为低；统计次数高于平均值且p＜10％，开发者能力评估为中；统计次数低于平均值，开发者能力评估为高；若开发者能力评估较低，则表明针对同一软件漏洞出现多次非计划性的修改提交和reopen记录，则表明该开发者可能经验不足，当前的提交信息具有较高的风险；(3)根据提交信息中的代码，查看提交信息中的代码变更，统计删除，增加的代码行数，查看修改涉及到的代码中的文件、类、方法的具体信息，形成代码更改的集合，规定一次修改提交文件、类、方法修改的次数的阈值分别为8，5，5，根据集合中的内容，统计一次修改提交文件、类、方法修改的次数，将修改的文件、类、方法的个数与阈值进行比较，若高于阈值，则说明该修改提交可能具有风险，且数值越高，风险性越大；统计它们在历史修改库中被开发人员重复修改的次数；如果被重复修改的次数过多，则说明该段代码的稳定性不高，而开发人员对此段代码的修改提交也具有较高风险；(4)利用主题模型提取历史相关bug中的评论，对评论中出现的bug报告评论中关键词进行分析，提取出一些主题特征；(5)将上述结果反馈给开发人员，根据bug可能出现reopen的风险，代码的不稳定性考察结果，开发者能力评估结果，bug报告的主题特征，形成风险特征说明，并给出相应的风险解释。附图说明图1——本发明流程示意图。图2——本发明相关修改提交信息示意图。具体实施方式本发明的技术思路是：本发明从开发人员的工作能力，修改提交信息和修复的bug信息角度对修改提交进行分析，为开发人员的修改提交提供了风险结果以及相应的风险解释。此方法不仅更准确地对修改提交进行了风险分析，而且结合了该开发人员的历史提交信息和bug中的评论信息，供开发人员的修改提交进行参考，并给出了缺陷产生的原因，有效地提高软件维护质量，降低软件维护带来的风险。如图1所示：本发明步骤如下：步骤(1).使用TF-IDF算法提取出关键词并反馈给开发人员，用余弦函数对预处理后的提交信息与历史提交信息库和bug库进行相似度计算，识别与当前提交相似度较高的历史提交和bug，，并根据提交信息和相关bug库，提取出bug编号、bug相关状态、bug的严重性、与其他bug的联系等相关信息。形成一个<修改提交，相关信息>对应列表，作为后续步骤的参考，以及bug可能出现reopen的风险性的一个考察。当前bug信息的对应列表就作为风险性的一个考察指标，开发人员通过了解相关的bug信息，知道提交修改中的不足，降低对软件漏洞的重复修复。例如：其中<bug_id>、<keywords>、<who>、<bug_status>被用来作参考。提取出的相关信息<bug_id>679494<keywords>patch，review<who>birunthan<bug_status>RESOLVEDFIXED其中<bug_importance>、<bug_priority>、<component>、<dependson>、<blocks>、<reported_time>、<modified_time>被用为作为bug可能出现reopen的风险性考察上述TF-IDF算法：词频(TF)＝某个单词在修改提交中出现的总次数/修改提交的总词数。逆文档频率(IDF)＝log(修改提交总数/包含该单词的修改提交数+1)。TF-IDF权值w＝TF*IDF权值高低说明关键词是否反映了修改提交的主题。步骤(2).在当前提交信息的开发人员的历史提交信息库中，通过统计，得出该开发者对于同一软件漏洞的多次修改的次数，以及修改的漏洞出现reopen的次数，与该项目所有开发者的对于同一软件漏洞的多次修改的次数，以及修改的漏洞出现reopen的次数平均值进行比较，记比较后的偏移量为p。若统计次数高于平均值且p＞10％，开发者能力评估为低；统计次数高于平均值且p＜10％，开发者能力评估为中；统计次数低于平均值，开发者能力评估为高。若开发者能力评估较低，则表明针对同一软件漏洞出现多次非计划性的修改提交和reopen记录，则表明该开发者可能经验不足，当前的提交信息具有较高的风险。通过对开发者能力的评估，得出当前提交信息具有风险性的可能，作为降低软件维护风险的一个指标。例如：对于同一软件漏洞的多次修改的次数的平均值为2.46，该开发者修改次数为2，能力评估为高。修改的漏洞出现reopen的次数平均值为3.19，该开发者的次数为4，P≈0.2025＝20.25％＞10％，开发者此项能力评估为低。步骤(3).根据提交信息中的代码，提取代码变更。统计删除，增加的代码行数，查看修改涉及到的代码中的文件、类、方法的具体信息，形成代码更改的集合。规定一次修改提交文件、类、方法修改的次数的阈值分别为8，5，10，根据集合中的内容，统计一次修改提交文件、类、方法修改的次数，将修改的文件、类、方法的个数与阈值进行比较，若高于阈值，则说明该修改提交可能具有风险，且数值越高，风险性越大。统计它们在历史修改库中被开发人员重复修改的次数。如果被重复修改的次数过多，则说明该段代码的稳定性不高，而开发人员对此段代码的修改提交也具有较高风险。根据提取的代码变更集合，使开发者明确修改的代码的稳定性，供开发人员参考，避免重复修改。例如：修改提交号为4e9065b的统计信息如下：修改的方法个数高于阈值，修改的文件个数和修改的类个数低于阈值。修改的代码段在历史修改库中被重复修改3次。步骤(4).利用主题模型提取bug中的评论，对评论中出现的bug报告评论中关键词进行分析，提取出一些主题特征。开发人员通过主题特征，了解当前bug的修复状况，了解当前软件提交所带来的风险。例如：<bug_id>为701591的bug评论和相关的bug评论中，根据主题模型提取出的主题为failing。说明当前的bug修复并没有完成。https：//bugzilla.mozilla.org/show_bug.cgi？id＝701591步骤(5).将上述结果反馈给开发人员，根据bug可能出现reopen的风险，代码的不稳定性考察结果，开发者能力评估结果，bug报告的主题特征，形成风险特征说明，并给出相应的风险解释。方便测试人员更有针对的进行回归测试，从而提高软件维护质量，降低软件维护带来的风险。当前第1页1 2 3