提交bug的方法及装置与流程

本发明涉及测试技术领域，特别是涉及一种提交bug的方法及装置。

背景技术：

随着互联网技术的快速发展，各类应用软件或者系统软件也随之快速发展，用于满足用户的需求。在各类应用软件或者系统软件公开使用前，通常会对应用软件或者系统软件进行测试，确保应用软件或者系统软件运行的正确性、完整性及安全性。

目前，常通过自动化测试的方法对应用软件或者系统软件进行测试，所谓自动化测试，是相对手工测试而言，其利用开发的软件测试工具、脚本等对应用软件或系统软件进行测试，以评估测试结果。若测试结果与预期结果相同，则测试通过；若测试结果与预期结果不同，则说明应用软件或系统软件出现bug,当确定应用软件或系统软件中存在bug时，需要测试人员手动的把bug提交到bug系统。

发明人在实现上述发明过程中，发现现有技术中虽然能够完成提交测试过程中发现的bug，但是，提交bug的操作需要测试人员手动完成，效率较低；此外，如果发现bug后，由于测试人员的人为因素，可能会导致无法将bug及时的提交到bug系统中，时效性差。

技术实现要素：

有鉴于此，本发明提供的一种提交bug的方法及装置，主要目的在于解决现有技术中手动提交bug的效率低、时效性差的问题。

为了解决上述问题，本发明主要提供如下技术方案：

一方面，本发明提供了一种提交bug的方法，该方法包括：

在测试用例对待检测程序执行测试时，若实际测试结果与预期结果不一致，则获取bug内容参数，所述bug内容参数包括所述预期结果、所述实际测试结果及测试用例的名称；

调用bug系统中预先创建的bug接口；

根据所述预先创建的bug接口将所述bug内容参数上传至所述bug系统中，以使所述bug系统根据所述bug内容参数在bug系统中创建bug。

优选的，获取bug内容参数，包括：

接收所述测试用例返回的所述实际测试结果；

从所述测试用例中获取预先设置的所述预期结果；

对所述测试用例进行解析，获取所述测试用例的名称。

优选的，在调用bug系统中预先创建的bug接口之前，所述方法还包括：

确定所述实际测试结果与所述预期结果存在差异的个数；

根据所述存在差异的个数与所述预期结果中的所有结果个数的比值，计算所述实际测试结果与所述预期结果之间的误差率；

根据所述误差率确定bug的优先级。

优选的，在调用bug系统中预先创建的bug接口之前，所述方法还包括：

接收所述待检测程序的开发人员在所述测试用例中输入的指派人信息，并将所述指派人信息进行存储；

获取所述指派人信息，以便将获取到的指派人信息发送至所述bug系统。

优选的，根据所述预先创建的bug接口将所述bug内容参数上传至所述bug系统中包括：

根据所述预先创建的bug接口将所述bug内容参数、所述bug的优先级、所述指派人信息传输至所述bug系统。

另一方面，本发明还提供一种提交bug的装置，该装置包括：

第一获取单元，用于在测试用例对待检测程序执行测试，且实际测试结果与预期结果不一致时，获取bug内容参数，所述bug内容参数包括所述预期结果、所述实际测试结果及测试用例的名称；

调用单元，用于调用bug系统中预先创建的bug接口；

上传单元，用于根据所述调用单元调用的所述预先创建的bug接口将所述获取单元获取的所述bug内容参数上传至所述bug系统中，以使所述bug系统根据所述bug内容参数在bug系统中创建bug。

优选的，所述第一获取单元包括：

接收模块，用于接收所述测试用例返回的所述实际测试结果；

第一获取模块，用于从所述测试用例中获取预先设置的所述预期结果；

解析模块，用于对所述测试用例进行解析；

第二获取模块，用于在所述解析模块对所述测试用例进行解析过程中，获取所述测试用例的名称。

优选的，所述装置还包括：

第一确定单元，用于在所述调用单元调用bug系统中预先创建的bug接口之前，确定所述实际测试结果与所述预期结果存在差异的个数；

计算单元，用于根据所述第一确定单元确定的所述存在差异的个数与所述预期结果中的所有结果个数的比值，计算所述实际测试结果与所述预期结果之间的误差率；

第二确定单元，用于根据所述误差率确定bug的优先级。

优选的，所述装置还包括：

接收单元，用于在所述调用单元调用bug系统中预先创建的bug接口之前，接收所述待检测程序的开发人员在所述测试用例中输入的指派人信息；

存储单元，用于在所述接收单元接收所述待检测程序的开发人员在所述测试用例中输入的指派人信息之后，将所述指派人信息进行存储；

第二获取单元，用于获取所述指派人信息，以便将获取到的指派人信息发送至所述bug系统。

优选的，所述上传单元，还用于根据所述创建bug接口将所述bug内容参数、所述bug的优先级、所述指派人信息传输至所述bug系统。

借由上述技术方案，本发明提供的技术方案至少具有下列优点：

本发明提供的一种提交bug的方法及装置，在测试用例对待检测程序执行测试时，若确定实际测试结果与预期结果不一致，则获取bug内容参数，并调用bug系统中的预先创建的bug接口，将bug内容参数中包含的预期结果、实际测试结果及测试用例的名称自动上传至所述bug系统中，bug系统可根据上述bug内容参数在bug系统创建bug；与现有技术相比，本发明在测试用例测试完成，并确定预期结果与测试结果不一致后，自动将与bug有关的bug内容参数上传至bug系统，提高了bug提交的效率，增强了提交bug的实时性。

上述说明仅是本发明技术方案的概述，为了能够更清楚了解本发明的技术手段，而可依照说明书的内容予以实施，并且为了让本发明的上述和其它目的、特征和优点能够更明显易懂，以下特举本发明的具体实施方式。

附图说明

通过阅读下文优选实施方式的详细描述，各种其他的优点和益处对于本领域普通技术人员将变得清楚明了。附图仅用于示出优选实施方式的目的，而并不认为是对本发明的限制。而且在整个附图中，用相同的参考符号表示相同的部件。在附图中：

图1示出了本发明实施例提供的一种提交bug的方法的流程图；

图2示出了本发明实施例提供的一种确定bug的优先级的方法的流程图；

图3示出了本发明实施例提供的一种提交bug的装置的组成框图；

图4示出了本发明实施例提供的另一种提交bug的装置的组成框图。

具体实施方式

下面将参照附图更详细地描述本公开的示例性实施例。虽然附图中显示了本公开的示例性实施例，然而应当理解，可以以各种形式实现本公开而不应被这里阐述的实施例所限制。相反，提供这些实施例是为了能够更透彻地理解本公开，并且能够将本公开的范围完整的传达给本领域的技术人员。

本发明实施例提供一种提交bug的方法，如图1所示，该方法包括：

101、在测试用例对待检测程序执行测试时，若实际测试结果与预期结果不一致，则获取bug内容参数。

所述bug内容参数包括所述预期结果、所述实际测试结果及测试用例的名称。

其中，所述测试用例是软件程序或系统软件是否通过的判断准则，它由一组条件或变量判断对应用软件或系统软件是否正确工作、运行；示例性的，假设，测试用例为2+3，其预期结果为5，若实际测试结果为5，说明预期结果与实际测试结果一致，则测试通过；若实际测试结果为4，说明预期结果与实际测试结果不一致，则测试不通过，即使用该测试用例测试的软件程序或系统软件存在bug。

在实际应用中，测试用例在对待检测程序(软件程序或系统软件)测试完成后，会有两种测试结果，第一种是：若预期结果与实际测试结果一致，则测试通过；第二种是：若预期结果与实际测试结果不一致，则测试不通过，本发明实施例提供的提交bug的方法，适用于测试用例对待检测程序测试未通过的情况下。若确定测试不通过，则测试用例可以直接将获取到的bug内容参数返回，并继续执行步骤102及步骤103。

作为本发明实施例的另一种实现方式，当确定测试用例测试未通过后，可将实际测试用例结果发送至第三方应用，由第三方应用获取bug内容参数，并继续执行步骤102及步骤103。具体包括：当测试完成后，测试用例会发出指令，触发第三方应用获得实际测试结果，由第三方应用作为执行主体完成后续操作步骤，本发明实施例对执行主体不作具体限定。为了便于表述，以下将以第三方应用为执行主体，对后续内容进行说明。

本发明实施例中，预期结果是将待检测程序预先在测试用例中设置结果，该预期结果是可知的、固定的。所述实际测试结果是测试用例在对待检测程序测试完成后，获得的实际测试结果，该实际测试结果为未知的，由待检测程序在测试用例中的运行情况确定。

比如，承由101步骤下示例中，加法算法，测试用例为2+3，具体的本发明实施例对测试用例不进行限制。

102、调用bug系统中预先创建的bug接口。

其中，所述预先创建的bug接口是在bug系统中存在的一个接口，用来作为一个传输通道将获取到的bug内容参数传输至bug系统中。在具体应用中，可通过调用算法调用预先创建的bug接口，以实现bug内容参数的传输。

103、根据所述预先创建的bug接口将所述bug内容参数上传至所述bug系统中。

其中，bug系统通过预先创建的bug接口接收到bug内容参数后，根据bug内容参数创建bug。在具体实现过程中，bug系统每接收到一个bug内容参数，在bug系统中根据每个bug内容参数生成一条bug，在生成bug时，可以以表格的形式存储bug，也可以以图的形式存储创建的bug，具体的，本发明实施例对bug系统中创建的bug的具体形式不作限定。

本发明实施例提供的一种提交bug的方法，在测试用例对待检测程序执行测试时，若确定实际测试结果与预期结果不一致，则获取bug内容参数，并调用bug系统中的预先创建的bug接口，将bug内容参数中包含的预期结果、实际测试结果及测试用例的名称自动上传至所述bug系统中，bug系统可根据上述bug内容参数在bug系统创建bug；与现有技术相比，本发明实施例在测试用例测试完成，并确定预期结果与测试结果不一致后，自动将与bug有关的bug内容参数上传至bug系统，提高了bug提交的效率，增强了提交bug的实时性。

进一步的，作为对本发明实施例的细化和扩展，本发明实施例的应用场景为预期结果与实际测试结果不一致，即测试未通过的情况，在步骤101执行获取bug内容参数之前，所述方法还包括判断实际测试结果与预期结果是否一致。在测试用例测试待检测程序前，在测试用例中预先设置预期结果，在测试完成后，该结果可以直接获取；所述实际测试结果是测试用例测试完成后，确定的测试结果，该实际测试结果可传输至第三方应用，或者，第三方应用对测试用例的测试过程进行监控，当测试用例完成，且预期结果与实际测试结果不一致时，获取实际测试结果。

若确定所述预期结果和所述实际测试结果不一致，则获取所述测试用例的名称；若确定所述预期结果和所述实际测试结果一致，则测试通过。在获取测试用例的名称时，通过对测试例进行解析，可直接获取其名称。

进一步的，当待检测的程序测试失败时，一般会说明测试失败的问题描述，该问题描述能说明bug的严重性，问题描述包括但不局限于以下内容，例如：待检测的程序不能执行正常工作功能或重要功能，因待检测的程序的原因导致系统死机等；或者，待检测的程序在一些显示上不美观、不符合用户习惯或者文字错误等等。在实际应用中，可将针对bug的问题描述，量化为实际测试结果与预期结果之间的误差率，通过误差率的大小确定处理bug的优先级，根据该优先级对bug进行修复。

为了确定bug对待检测程序运行的影响大小，本发明实施例提供一种确定bug的优先级的方法，如图2所示，该方法包括：

201、确定所述实际测试结果与所述预期结果存在差异的个数。

确定实际测试用例结果与预期结果存存在差异的个数，实质为查找两者的异同点。示例性的，假设，预期结果中包含有5个测试结果数据，实际测试结果中也有5个测试结果数据，但是，实际测试结果中有4个测试结果数据与预期结果中的测试结果数据存在差异，则确定实际测试结果与预期结果存在差异的个数为4个，以上仅为示例性的举例，本发明实施例对预期结果及实际测试结果中包含的测试结果数据的具体个数、及差异个数不作具体限定。

202、根据所述存在差异的个数与所述预期结果中的所有结果个数的比值，计算所述实际测试结果与所述预期结果之间的误差率。

承由步骤201的示例，该示例的误差率为4/5＝80％，本发明对误差率不作具体限定。

203、根据所述误差率确定bug的优先级。

bug的优先级由误差率确定，误差率越高，bug的优先级越高；误差率越低，bug的优先级越低。在实际应用中，bug的优先级越高，说明该bug对待检测程序运行影响越大。示例性的，本发明实施例给出bug的优先级确定的简要说明：bug的优先级可分为紧急、高、中、低。

其中，bug的优先级为紧急：待检测程序中的bug，导致该程序不能执行正常工作功能或重要功能，须马上修复，比如该bug导致系统死机；

bug的优先级为高：待检测程序中的bug，导致操作中经常发生不可避免的问题，在发版前必须修复，比如该bug导致系统不稳定、不安全、或破坏数据、或产生错误结果；

bug的优先级为中：程序虽然存在bug，但并不影响程序主要功能基本正常运行，次要功能运行不正常，只需要在执行某个特定环节结束前修复；

bug的优先级为低：待检测程序中的bug，对系统的影响较小，可以在没有时间限定下修复，比如显示上不美观，不符合用户习惯。

本发明实施例在根据误差率确定bug的优先级时，所述误差率与优先级的对应关系为一经验值，可根据不同的待测试程序制定相应的bug的优先级。示例性的，假设，100％≥误差率≥80％，bug的优先级为紧急；80％＞误差率≥60％，bug的优先级为高；60％＞误差率≥20％，bug的优先级为中；20％＞误差率，bug的优先级为低等等，本发明对bug的优先级分类个数、不同的bug的优先级对应误差率的范围等内容不作具体限定。

进一步的，使用测试用例对待检测程序进行测试的目的在于，确定待检测程序的运行是否正常，若该待检测程序运行不正常，即待检测程序出现bug，则需要对bug及时进行修复。在对bug进行修复时，一般情况下，会由确定存在bug的待检测程序的开发人员对该bug进行修复，即该开发人员作为bug修复的指派人。或者，在对bug进行修复时，也可能会由其他开发人员对待检测程序中的bug进行修复，具体的，本发明实施例对指派人的具体人员不作限定。

为了对bug进行有效、快速修复，在具体实施过程中，在测试用例对待检测程序测试前将该指派人信息配置到测试用例执行测试的简要说明中，待测试完成后，若实际测试结果与预期结果不一致，则第三方程序获取指派人信息，以便将获取到的指派人信息发送至所述bug系统。

本发明实施例中，在将指派人信息配置到执行测试的简要说明中时，可以将待检测程序的开发人员的姓名、邮箱等个人信息配置到执行测试的简要说明，本发明实施例对指派人信息不作具体限定。

进一步的，在由第三方程序获取了bug内容参数、bug的优先级、指派人信息后，需要将这些bug相关参数上传子bug系统中，以便后续对该bug相关的内容进行整理、存储、查知等等，因此，在向bug系统中上传bug相关参数时，可将bug内容参数、bug的优先级及指派人等全部上传至bug系统。

进一步的，作为对上述图1所示方法的实现，本发明另一实施例还提供了一种提交bug的装置。该装置实施例与前述方法实施例对应，为便于阅读，本装置实施例不再对前述方法实施例中的细节内容进行逐一赘述，但应当明确，本实施例中的装置能够对应实现前述方法实施例中的全部内容。

本发明实施例还提供一种提交bug的装置，如图3所示，所述装置包括：

第一获取单元31，用于在测试用例对待检测程序执行测试，且实际测试结果与预期结果不一致时，获取bug内容参数，所述bug内容参数包括所述预期结果、所述实际测试结果及测试用例的名称；

调用单元32，用于调用bug系统中预先创建的bug接口；

上传单元33，用于根据所述调用单元调用的所述预先创建的bug接口将所述获取单元获取的所述bug内容参数上传至所述bug系统中，以使所述bug系统根据所述bug内容参数在bug系统中创建bug。

本发明实施例提供的一种提交bug的装置，在测试用例对待检测程序执行测试时，若确定实际测试结果与预期结果不一致，则获取bug内容参数，并调用bug系统中的预先创建的bug接口，将bug内容参数中包含的预期结果、实际测试结果及测试用例的名称自动上传至所述bug系统中，bug系统可根据上述bug内容参数在bug系统创建bug；与现有技术相比，本发明实施例在测试用例测试完成，并确定预期结果与测试结果不一致后，自动将与bug有关的bug内容参数上传至bug系统，提高了bug提交的效率，增强了提交bug的实时性。

进一步的，如图4所示，所述第一获取单元31包括：

接收模块311，用于接收所述测试用例返回的所述实际测试结果；

第一获取模块312，用于从所述测试用例中获取预先设置的所述预期结果；

解析模块313，用于对所述测试用例进行解析；

第二获取模块314，用于在所述解析模块313对所述测试用例进行解析过程中，获取所述测试用例的名称。

进一步的，如图4所示，所述装置还包括：

第一确定单元34，用于在所述调用单元42调用bug系统中预先创建的bug接口之前，确定所述实际测试结果与所述预期结果存在差异的个数；

计算单元35，用于根据所述第一确定单元34确定的所述存在差异的个数与所述预期结果中的所有结果个数的比值，计算所述实际测试结果与所述预期结果之间的误差率；

第二确定单元36，用于根据所述误差率确定bug的优先级。

进一步的，如图4所示，所述装置还包括：

接收单元37，用于在所述调用单元42调用bug系统中预先创建的bug接口之前，接收所述待检测程序的开发人员在所述测试用例中输入的指派人信息；

存储单元38，用于在所述接收单元37接收所述待检测程序的开发人员在所述测试用例中输入的指派人信息之后，将所述指派人信息进行存储；

第二获取单元39，用于获取所述指派人信息，以便将获取到的指派人信息发送至所述bug系统。

进一步的，如图4所示，所述装置还包括：

所述上传单元33，还用于根据所述创建bug接口将所述bug内容参数、所述bug的优先级、所述指派人信息传输至所述bug系统。

所述一种提交bug的装置包括处理器和存储器，上述第一获取单元、调用单元、上传单元均作为程序单元存储在存储器中，由处理器执行存储在存储器中的上述程序单元来实现相应的功能。

处理器中包含内核，由内核去存储器中调取相应的程序单元。内核可以设置一个或以上，通过调整内核参数来解决现有技术中手动提交bug的效率低、时效性差的问题。

存储器可能包括计算机可读介质中的非永久性存储器，随机存取存储器(ram)和/或非易失性内存等形式，如只读存储器(rom)或闪存(flashram)，存储器包括至少一个存储芯片。

本申请还提供了一种计算机程序产品，在测试用例对待检测程序执行测试时，若实际测试结果与预期结果不一致，则获取bug内容参数，所述bug内容参数包括所述预期结果、所述实际测试结果及测试用例的名称；调用bug系统中预先创建的bug接口；根据所述预先创建的bug接口将所述bug内容参数上传至所述bug系统中，以使所述bug系统根据所述bug内容参数在bug系统中创建bug。

在本发明的上述实施例中，对各个实施例的描述都各有侧重，某个实施例中没有详述的部分，可以参见其他实施例的相关描述。

本领域内的技术人员应明白，本申请的实施例可提供为方法、系统、或计算机程序产品。因此，本申请可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本申请可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、cd-rom、光学存储器等)上实施的计算机程序产品的形式。

本申请是参照根据本申请实施例的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。

这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。

这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。

在一个典型的配置中，计算设备包括一个或多个处理器(cpu)、输入/输出接口、网络接口和内存。

存储器可能包括计算机可读介质中的非永久性存储器，随机存取存储器(ram)和/或非易失性内存等形式，如只读存储器(rom)或闪存(flashram)。存储器是计算机可读介质的示例。

计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括，但不限于相变内存(pram)、静态随机存取存储器(sram)、动态随机存取存储器(dram)、其他类型的随机存取存储器(ram)、只读存储器(rom)、电可擦除可编程只读存储器(eeprom)、快闪记忆体或其他内存技术、只读光盘只读存储器(cd-rom)、数字多功能光盘(dvd)或其他光学存储、磁盒式磁带，磁带磁磁盘存储或其他磁性存储设备或任何其他非传输介质，可用于存储可以被计算设备访问的信息。按照本文中的界定，计算机可读介质不包括暂存电脑可读媒体(transitorymedia)，如调制的数据信号和载波。

还需要说明的是，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、商品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、商品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括要素的过程、方法、商品或者设备中还存在另外的相同要素。

本领域技术人员应明白，本申请的实施例可提供为方法、系统或计算机程序产品。因此，本申请可采用完全硬件实施例、完全软件实施例或结合软件和硬件方面的实施例的形式。而且，本申请可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、cd-rom、光学存储器等)上实施的计算机程序产品的形式。

以上仅为本申请的实施例而已，并不用于限制本申请。对于本领域技术人员来说，本申请可以有各种更改和变化。凡在本申请的精神和原理之内所作的任何修改、等同替换、改进等，均应包含在本申请的权利要求范围之内。