技术领域
[0001] 本
发明涉及一种基于本文混乱度的软件问题报告分类方法。随着开源社区的发展，开源社区中的问题管理工具中积累了海量的软件问题报告数据。这些报告包含多种类型，混合在一起难以区分，例如软件
缺陷、特征需求等。良好的问题分类对于开发任务的管理有着巨大的作用，但传统的人工分类方法开销巨大，所以自动化的方法对于降低维护开销，提高软件开发与维护效率有着巨大的帮助。
背景技术
[0002] 随着开源运动的推广，开发工具的支持，越来越多的人参与到开源软件的开发中来，并提供自己的贡献。在进行大众贡献时，向问题管理系统提交问题报告(issue)是开源用户进行的最多的活动之一。然而，在大型的软件项目中存在大量缺少分类标注的问题报告，需要花费巨大的人工成本进行维护和管理。因此，如何通过自动化的方法，帮助软件开发人员快速准确的明确用户提出的问题类型具有重要的意义。
[0003] 目前很多研究都关注了软件问题报告的分类技术。这类技术的一个基本思路基于问题报告的标题和内容通过
文本挖掘方法构建
特征向量，然后使用
机器学习方法来构建自动的问题报告分类器模型。目前取得性能较高的方法主要可以分为两类。第一类技术是的核心思想首先通过
网络爬虫技术，从流行的开源社区中的问题管理系统获取海量的问题报告，分析报告文本(包括标题、描述信息、讨论等)中的结构化语义特征，并建立相应的向量特征模型，然后通过传统的机器学习
算法来建立分类器模型。第二类技术是在上述过程的
基础上结合文本挖掘技术与
数据挖掘技术,充分利用问题报告中的文本语义和结构化信息来提高分类的准确率。
[0004] 上述的两类分类技术能够帮助软件项目管理者较好地识别传统软件的问题报告类型，但是由于目前开源社区(如GitHub、Bitbucket等)所使用的问题管理系统更加轻量级，只需要用户提供的简单的文本描述信息，就能完成问题的报告。这样一来，用户提交报告的成本虽然被降低了，但也使得在进行问题分类时能够利用的信息大大减少。除此之外，因为提交报告的
门槛降低了，问题报告的
质量也受到了一定的影响。这些因素使得传统分类器的训练过程受到了较大的影响，无法很好的适应现有问题报告的新特性。
[0005] 在当前流行的问题管理系统中积累的语义信息逐渐丰富，涉及到项目管理员、问题的汇报者、问题参与的讨论人员等，相应的文本的混乱度也越来越大。根据上述现象，本发明提出了一种基于文本混乱度的问题报告分类方法，辅助软件项目提升开发和维护的效率。
发明内容
[0006] 本发明要解决的技术问题是：提出一种基于文本混乱度的软件问题报告分类方法。
[0007] 为解决上述技术问题，本发明的技术方案如下：
[0008] 一种基于文本混乱度的软件问题报告分类方法，该分类方法具体包括以下步骤：
[0009] 步骤1：对GitHub平台进行
数据采集，所采集的数据包括大众提交的问题报告以及该报告的相关信息；
[0010] 步骤2：数据集标注，通过对问题报告的标签进行人工的抽样分析，从而实现对数据集的标注；
[0011] 步骤3：对数据集进行预处理，包括对文本信息进行预处理，去除不需要的信息，并通过文本信息数字化，将文本信息转化为可以进行计算处理的数字形式；
[0012] 步骤4：分类模型构建，利用已有的机器学习方法，构建一个两层的自动化问题报告分类器；
[0013] 其中，第一层利用问题报告的文本信息进行构建，并收集文本信息中的混乱度信息；第二层利用第一层的输出结果以及问题报告的结构化信息进行构建，并最终对问题报告进行自动化分类。
[0014] 作为本发明技术方案的进一步改进，所述步骤1包括：利用GitHub提供的API，通过脚本从GitHub中爬取软件项目与问题报告的全面信息，
抽取出报告中相关的数据；并通过所需的目标字段信息获取结构化的数据，构建token以实现持续爬取所需的数据信息。
[0015] 作为本发明技术方案的进一步改进，所述步骤2包括，
[0016] 步骤2.1：将具有额外信息的问题报告的标签进行拆分，形成二维向量形式，其中C表示这个标签属于的具体类别是什么，name则表示这个标签中的具体信息，将同属于一个类别(C)下的所有标签进行聚合形成一个标签组(Group)，完成问题报告标签的初步聚合；
[0017] 步骤2.2：通过计算不同类型标签的相似度，将相似度较高的类型进行聚合，其中相似度的计算方法为：
[0018] similarity＝Group1∩Group2/min(Group1，group2)
[0019] 当两个不同类型标签组(Group1，Group2)的相似度计算超过相似度
阈值时，将该两个不同的标签组进行合并形成一个组，从而进一步的将分散的类型标签进行聚合；
[0020] 步骤2.3：将人工分析能够表示问题报告类型的标签分为缺陷以及非缺陷，进而将具有这些标签的问题报告标注为响应的类型。
[0021] 作为本发明技术方案的进一步改进，所述步骤3包括，
[0022] 步骤3.1：对报告中的所有文本进行字母大小写转换，全部改成小写。
[0023] 步骤3.2：去除文本中的停用词，并进行词性转换。
[0024] 步骤3.3：利用空间向量模型将问题报告数字化，通过将问题报告进行分词处理，将每个问题报告转化为单词的向量形式，并通过TF-IDF算法计算每个词在向量中的权重。
[0025] 作为本发明技术方案的进一步改进，所述步骤4包括，
[0026] 步骤4.1：利用SVM模型，通过文本信息构建第一层分类器，选择概率输出，并收集文本混乱度信息；
[0027] 步骤4.2：收集问题报告的报告者信息，并与第一层中获取的文本混乱度信息综合作为第二层的输入，并以此使用线性回归方法构建分类模型。
[0028] 作为本发明技术方案的进一步改进，所述步骤4.1中，所述文本混乱度信息包括：
[0029] 缺陷概率：问题报告预测为缺陷的概率；
[0030] 句子数量：通过句子划分将问题报告划分为至少一个句子，并统计该问题报告中的句子数量；
[0031] 最大缺陷概率：最像缺陷的句子预测为缺陷的概率；
[0032] 最小缺陷概率：最不像缺陷的句子预测为缺陷概率；
[0033] 非缺陷
位置：最不像缺陷的句子在所有语句中的位置；
[0034] 缺陷句子数量：预测为缺陷的句子数量；
[0035] 非缺陷句子数量：预测为非缺陷的句子数量；
[0036] 语义转变次数：不同句子的语义信息从缺陷转变为非缺陷的次数；
[0037] 语义混乱度：首先，采用句子切分技术将问题报告进行拆分，形成句子序列。接着，将句子序列输入SVM模型，获得序列中每个句子预测为缺陷的概率Pi。最后，采用
自然语言处理领域的混乱度计算方法，计算该句子序列的语义混乱度，即问题报告对应的语义混乱度，计算公式如下:
[0038]
[0039] 作为本发明技术方案的进一步改进，步骤4.2中，具体的报告者信息包括：
[0040] 是否核心成员：如果是核心团队的成员，该特征置为1，否则，置为0；
[0041] 项目内问题报告数量：在该项目内报告者提交过的问题报告数量；
[0042] 社区内问题报告数量：在GitHub平台中报告者提交过的问题报告数量；
[0043] 项目内评论数量：在该项目内报告者提交过的问题报告评论数量；
[0044] 社区内评论数量：在GitHub平台中报告者提交过的问题报告评论数量；
[0045] 粉丝数量：在GitHub平台中报告者具有的粉丝(follower)数量；
[0046] 注册时间：报告者从注册至今的时间，转化为时间戳形式。
[0047] 与
现有技术相比，本发明具有以下有益效果：
[0048] 本发明面向开源社区中问题管理系统中混杂的问题报告，提出了一种基于文本混乱度的软件问题报告分类方法，帮助在项目开发过程中的项目管理人员更好地对软件开发任务进行分类管理，提高软件项目的开发和维护效率。
附图说明
[0049] 图1为本发明基于文本混乱度的自动分类模型结构图。
[0050] 图2为本发明基于文本混乱度的软件问题报告分类方法
流程图。
具体实施方式
[0051] 下面将结合本发明
实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。
[0052] 本发明具体实施方法提供一种基于文本混乱度的软件问题报告分类方法，如图2所示，该方法包括如下步骤：
[0053] 步骤1、数据收集。
[0054] 利用GitHub提供的API，通过脚本从GitHub中爬取软件项目与问题报告的全面信息，并抽取出报告中相关的数据，包括问题标题、描述内容、讨论内容、属性标签、报告者信息等。通过API获取的GitHub数据为Json格式，因此本发明通过所需的目标字段信息获取结构化的数据。此外，GitHub通过token的形式来限制API的使用时间和
频率，为此，本发明通过构建token池的方式实现持续爬取所需的数据信息。
[0055] 步骤2、数据集标注。
[0056] 通过对标签信息进行分析，从标签信息中抽取其类型信息，从而将扁平化的标签变为结构化的标签。进而在表示问题报告类型的标签属性中选择能够表示问题报告是否为缺陷信息的标签对问题报告进行标注，从而构建所需的标注数据集。
[0057] 具体步骤如下：
[0058] 步骤2.1：部分项目中问题报告的标签具有额外信息，如“[type]bug”，“[type]enhancement”。将具有额外信息的问题报告的标签进行拆分，形成二维向量形式，其中C表示这个标签属于的具体类别是什么，name则表示这个标签中的具体信息，然后将同属于一个类别(C)下的所有标签进行聚合形成一个标签组(Group)，完成问题报告标签的初步聚合。
[0059] 步骤2.2：通过计算不同类型(C)标签的相似度，将相似度较高的类型进行聚合，其中相似度的计算方法为：
[0060] similarity＝Group1∩Group2/min(Group1，Group2)
[0061] 当两个不同类型标签组的相似度计算超过相似度阈值时就将这两个组进行合并形成一个组，从而进一步的将分散的类型标签进行聚合。
[0062] 步骤2.3：人工分析能够表示问题报告类型的标签(如bug，feature，enhancement等)，将其分为缺陷以及非缺陷，进而将具有这些标签的问题报告标注为响应的类型。
[0063] 步骤3、对数据集进行预处理。
[0064] 步骤3.1：对报告中的所有文本进行字母大小写转换，全部改成小写。
[0065] 步骤3.2：去除文本中的停用词，并进行词性转换。
[0066] 步骤3.3：利用空间向量模型将问题报告数字化，通过将问题报告进行分词处理，将每个问题报告转化为单词的向量形式，并通过TF-IDF算法计算每个词在向量中的权重。
[0067] 步骤4、模型构建。
[0068] 如图1所示，本发明分类模型构建过程分为两个阶段，在第一个阶段，通过
预测模型的概率输出获取问题报告的混乱度信息。在第二阶段，除了收集第一阶段产生的混乱度信息，还需要收集问题报告人的开发信息，并将该混乱度信息和该开发信息合并，统一作为问题报告的特征构建第二层分类模型。
[0069] 具体步骤如下：
[0070] 步骤4.1：利用SVM模型，通过文本信息构建第一层分类器，选择概率输出，并收集文本混乱度信息，包括：
[0071] 缺陷概率：问题报告预测为缺陷的概率；
[0072] 句子数量：通过句子划分将问题报告划分为至少一个句子，并统计该问题报告中的句子数量；
[0073] 最大缺陷概率：最像缺陷的句子预测为缺陷的概率；
[0074] 最小缺陷概率：最不像缺陷的句子预测为缺陷概率；
[0075] 非缺陷位置：最不像缺陷的句子在所有语句中的位置，即第几句；
[0076] 缺陷句子数量：预测为缺陷的句子数量；
[0077] 非缺陷句子数量：预测为非缺陷的句子数量；
[0078] 语义转变次数：不同句子的语义信息从缺陷转变为非缺陷的次数；
[0079] 语义混乱度：首先，采用句子切分技术将问题报告进行拆分，形成句子序列。接着，将句子序列输入SVM模型，获得序列中每个句子预测为缺陷的概率Pi。最后，采用自然语言处理领域的混乱度计算方法，计算该句子序列的语义混乱度，即问题报告对应的语义混乱度，计算公式如下:
[0080]
[0081] 步骤4.2：收集问题报告的报告者信息，并与第一层中获取的文本混乱度信息综合作为第二层的输入，并以此构建分类模型。其中这里使用线性回归方法构建模型。具体的报告者信息包括：
[0082] 是否核心成员：如果是核心团队的成员，该特征置为1，否则，置为0；
[0083] 项目内问题报告数量：在该项目内报告者提交过的问题报告数量；
[0084] 社区内问题报告数量：在GitHub平台中报告者提交过的问题报告数量；
[0085] 项目内评论数量：在该项目内报告者提交过的问题报告评论数量；
[0086] 社区内评论数量：在GitHub平台中报告者提交过的问题报告评论数量；
[0087] 粉丝数量：在GitHub平台中报告者具有的粉丝(follower)数量；
[0088] 注册时间：报告者从注册至今的时间，转化为时间戳形式。
[0089] 需要说明的是，在本文中，诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……限定的要素，并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素”。
[0090] 尽管已经示出和描述了本发明的实施例，对于本领域的普通技术人员而言，可以理解在不脱离本发明的原理和精神的情况下可以对这些实施例进行多种变化、
修改、替换和变型，本发明的范围由所附
权利要求及其等同物限定。
