一种定位程序代码中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的装置结构示意图。

具体实施方式

为了使本技术领域的人员更好地理解本发明方案，下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分的实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都应当属于本发明保护的范围。

以下分别进行详细说明。

本发明的说明书和权利要求书及所述附图中的术语“第一”、“第二”、“第三”和“第四”等是用于区别不同对象，而不是用于描述特定顺序。此外，术语“包括”和“具有”以及它们任何变形，意图在于覆盖不排他的包含。例如包含了一系列步骤或单元的过程、方法、系统、产品或设备没有限定于已列出的步骤或单元，而是可选地还包括没有列出的步骤或单元，或可选地还包括对于这些过程、方法、产品或设备固有的其它步骤或单元。

在本文中提及“实施例”意味着，结合实施例描述的特定特征、结构或特性可以包含在本发明的至少一个实施例中。在说明书中的各个位置出现该短语并不一定均是指相同的实施例，也不是与其它实施例互斥的独立的或备选的实施例。本领域技术人员显式地和隐式地理解的是，本文所描述的实施例可以与其它实施例相结合。

“多个”是指两个或两个以上。“和/或”，描述关联对象的关联关系，表示可以存在三种关系，例如，a和/或b，可以表示：单独存在a，同时存在a和b，单独存在b这三种情况。字符“/”一般表示前后关联对象是一种“或”的关系。

下面结合附图对本申请的实施例进行描述。

请参见图1，图1为本发明实施例提供的一种定位程序代码中bug的方法方法的流程示意图。如图1所示，该方法应用于任何具有计算能力和程序处理能力的终端或者服务器。该方法包括：

s101、接收用户的程序调试指令，确定需要调试的程序。

当程序运行出现故障时，说明程序有bug。此时需要对程序进行调试，找出bug并修复。因此，当用户发现程序运行故障时，可以通过点击或触控操作界面的程序调试指令或者通过语音的方式告知终端需要对有故障的程序进行调试。

s102、确定需要调试的代码。

当确定需要调试的程序后，说明调试程序有bug。由于随着程序的复杂程度越来越高，程序的代码越来越长。因此，为了快速定位bug，需要确定其中的某一部分代码作为调试代码进行测试。

其中，确定需要调试的代码，具体包括：

确定所述需要调试的程序的代码特性参数；

根据所述代码特性参数按照预设规则确定需要调试的代码。

其中，代码特性参数包括但不限于代码长度、代码功能模块分布。

优选的，当代码特性参数为代码长度时，根据所述代码特性参数按照预设规则确定需要调试的代码，具体包括：根据所述代码长度将所述需要调试的程序分段，确定其中的一段分段代码为需要调试的代码。

具体的，当需要调试的程序的代码长度为m(m≥1)行时，可以将该m行代码按照预置的规则分成n(n≥1)段。该分段规则可以由用户自行设置，可以是平均分段，也可以按照代码的逻辑结构分段。此时可以选取第i(i＝1，2，3……n)段代码确定为需要调试的代码。例如，当需要调试的程序的代码长度为1000行时，可以将1000行代码平均分成10段(当然也可以平均分成50段，100段)或者按照代码的逻辑结构分成10段(当然也可以分成50段，100段)，之后选取其中的第1段代买或者第5段代码(当然也可以是其他段代码)确定为需要调试的代码。

优选的，当代码特性参数为代码功能模块分布时，根据所述代码特性参数按照预设规则确定需要调试的代码，具体包括：根据代码功能模块分布确定bug对应的功能模块代码段；确定所述bug对应的功能模块代码段为需要调试的代码。

例如，程序代码段可以按照程序运行过程中的功能阶段进行分段，如启动、显示、运算、结果反馈等。首先将程序代码按照各功能阶段进行分段，然后初步确定出现故障是在哪个阶段，则可以将该阶段的代码确定为需要调试的代码。例如，当程序启动停滞，无法进入下一阶段时，说明启动阶段有bug，此时只需要将启动阶段对应的代码段作为调试代码进行调试即可。还比如，当程序运算过程中出现闪退，说明运算阶段有bug，此时需要将运算阶段对应的代码段作为调试代码进行调试。

优选的，当代码特性参数为代码长度和代码功能模块分布时，根据所述代码特性参数按照预设规则确定需要调试的代码，具体包括：根据代码功能模块分布确定bug对应的功能模块代码段；确定所述bug对应的功能模块代码段的代码长度，根据该代码长度将功能模块代码段分段，确定其中的一段分段代码为需要调试的代码。

具体的，在确定需要调试的代码时，可以先按照代码功能模块分布如启动、显示、运算、结果反馈等进行分段，然后根据bug出现的阶段确定bug对应的功能模块代码段，如显示闪屏等则说明bug出现在显示功能模块代码段；之后再根据该bug对应的功能模块代码段的代码长度按照平均分段或者逻辑结构进行分段，如将100行的bug对应的功能模块代码段平均分成10段或者按照逻辑结构分成5段，最后确定其中的一段分段代码作为需要调试的代码。

s103、将所述调试代码命名为测试文件并保存进临时目录。

确定需要调试的代码段后，将调试代码复制形成一个新的文件，并命名为测试文件。为避免与源代码混淆，将该测试文件保存进临时目录。例如，可以在临时目录/tmp目录下建立一个文件，把需要调试的代码拷贝进去，如保存文件名为测试文件test.php。

s104、调用执行指令运行所述测试文件。

确定测试文件后，调用相应的执行指令运行该测试文件。例如调用phptest.php指令运行测试代码。

s105、将所述测试文件的运行结果与程序运行结果进行匹配。若完全匹配，则继续步骤s106；若不匹配，则跳转至步骤s102重新确定需要调试的代码。

运行后，将测试文件的运行结果与有bug的程序运行结果进行匹配，如果完全匹配，说明bug就在这一测试文件里。如果不匹配，说明bug不在该测试文件，需要返回到步骤102重新确定需要调试的代码。

s106、修改所述测试文件。

测试文件的运行结果匹配，说明bug就在该测试文件。此时可以通过进一步的修改测试文件进行调试来实现bug的精准定位。修改测试文件，既可以是对测试文件的代码段继续按照分段规则进行代码分段，缩小分段代码的长度；也可以是修改测试文件中某一具体的代码，例如在所述临时文件目录下增加一个自定义类使其继承需调试的程序文件的目标类，然后保存该文件，继续调用执行指令运行修改后的测试文件。

s107、调用执行指令运行修改后的测试文件。

修改完测试文件后，调用执行指令继续运行修改后的测试文件。

s108、将所述修改后的测试文件的运行结果与期望结果进行匹配。若完全匹配，则继续步骤s109；若不匹配，则跳转至步骤s106重新修改所述测试文件。

运行后，将修改后的测试文件的运行结果与期望的程序运行结果进行匹配，如果完全匹配，说明bug就在测试文件的修改部分。如果不匹配，说明bug不在测试文件的修改部分，需要返回到步骤106继续修改测试文件。

具体而言，修改测试文件时会根据该修改得到一个预期的程序运行结果，该预期的程序运行结果即为期望结果。例如，修改测试文件后预期运行的结果是输出一个sql语句，但如果运行后输出的不是sql语句则说明定位的方向有错，bug不在测试文件的修改部分。

s109、完成bug定位。

若修改后的测试文件的运行结果与期望的程序运行结果完全匹配，则说明bug就在测试文件的修改部分，此时可以实现bug定位。

s110、输出bug定位结果。

输出bug的位置以供用户查阅。

可以看出，在本发明实施例的方案中，在接收用户的程序调试指令后，确定需要调试的程序和需要调试的代码，将所述调试代码命名为测试文件并保存进临时目录，调用执行指令运行所述测试文件，将所述测试文件的运行结果与程序运行结果进行匹配，若完全匹配，则修改所述测试文件，调用执行指令运行修改后的测试文件，将所述修改后的测试文件的运行结果与期望结果进行匹配，若完全匹配，则完成bug定位，输出bug定位结果。通过上述方式，解决了现有技术中应用程序bug定位效率低下的问题，能实现bug的快速定位，提高程序调试效率。

请参见图2，图2是本发明实施例提供的另一种定位程序代码中bug方法的流程示意图。在图2中，该方法包括：

s201、接收用户的程序调试指令，确定需要调试的程序。

该步骤与s101相同，此处不再赘述。

s202、确定需要调试的代码。

该步骤与s102相同，此处不再赘述。

s203、将所述调试代码命名为测试文件并保存进临时目录。

该步骤与s103相同，此处不再赘述。

s204、将所述调试代码的接口代码保存进所述临时目录。

为了能正确的引用原程序目录下的文件，需要把调试代码的接口代码拷贝到临时目录下，使其能正确引用原目录下的文件。

s205、检测所述接口代码的引用路径是否正确。若正确，则跳转至步骤s207；若不正确，则执行步骤s206。

s206、修改接口代码的引用路径，使其能正确引用所述程序的目录文件。

当检测到接口代码的引用路径不正确时，需要修改接口代码中的引用路径，使其能正确引用所述程序的目录文件。

s207、调用执行指令运行所述测试文件。

s208、将所述测试文件的运行结果与程序运行结果进行匹配。若完全匹配，则执行步骤s209；若不匹配，则跳转至步骤s202重新确定需要调试的代码。

s209、修改所述测试文件。

该步骤与s106相同，此处不再赘述。

s210、调用执行指令运行修改后的测试文件。

该步骤与s107相同，此处不再赘述。

s211、将所述修改后的测试文件的运行结果与期望结果进行匹配。若匹配，则执行步骤s212；若不匹配，则跳转至步骤s209重新修改测试文件。

该步骤与s108相同，此处不再赘述。

s212、完成bug定位。

该步骤与s109相同，此处不再赘述。

s213、输出bug定位结果。

该步骤与s110相同，此处不再赘述。

可以看出，在本发明实施例中，在接收用户的程序调试指令后，确定需要调试的程序和需要调试的代码，将所述调试代码命名为测试文件并保存进临时目录，将所述调试代码的接口代码保存进所述临时目录，检测所述接口代码的引用路径是否正确，若正确则修改接口代码的引用路径，使其能正确引用所述程序的目录文件，调用执行指令运行所述测试文件，将所述测试文件的运行结果与程序运行结果进行匹配，若完全匹配，则修改所述测试文件，调用执行指令运行修改后的测试文件，将所述修改后的测试文件的运行结果与期望结果进行匹配，若完全匹配，则完成bug定位，输出bug定位结果。通过上述方式，使测试文件仅通过修改接口代码的引用路径即可以引用原程序的所有文件，实现了调试代码范围小，调试效率高的效果，同时解决了现有技术中应用程序bug定位效率低下的问题，能实现bug的快速定位，提高程序调试效率。

参见图3，图3是本发明实施例提供的一种定位程序代码中bug的装置的结构示意图。该装置可以应用于具有计算能力和程序处理能力的终端或服务器中。如图3所示，该装置包括：

接收单元301，用于接收用户的程序调试指令，确定需要调试的程序。

当程序运行出现故障时，说明程序有bug。此时需要对程序进行调试，找出bug并修复。因此，当用户发现程序运行故障时，可以通过点击或触控操作界面的程序调试指令或者通过语音的方式告知装置需要对有故障的程序进行调试。

确定单元302，用于确定需要调试的代码。

当确定需要调试的程序后，说明调试程序有bug。由于随着程序的复杂程度越来越高，程序的代码越来越长。因此，为了快速定位bug，需要确定其中的某一部分代码作为调试代码进行测试。

其中，确定单元302具体用于：

确定所述需要调试的程序的代码特性参数；

根据所述代码特性参数按照预设规则确定需要调试的代码。

其中，代码特性参数包括但不限于代码长度、代码功能模块分布。

优选的，当代码特性参数为代码长度时，确定单元302具体用于：根据所述代码长度将所述需要调试的程序分段，确定其中的一段分段代码为需要调试的代码。

具体的，当需要调试的程序的代码长度为m(m≥1)行时，可以将该m行代码按照预置的规则分成n(n≥1)段。该分段规则可以由用户自行设置，可以是平均分段，也可以按照代码的逻辑结构分段。此时可以选取第i(i＝1，2，3……n)段代码确定为需要调试的代码。例如，当需要调试的程序的代码长度为1000行时，可以将1000行代码平均分成10段(当然也可以平均分成50段，100段)或者按照代码的逻辑结构分成10段(当然也可以分成50段，100段)，之后选取其中的第1段代买或者第5段代码(当然也可以是其他段代码)确定为需要调试的代码。

优选的，当代码特性参数为代码功能模块分布时，确定单元302具体用于：根据代码功能模块分布确定bug对应的功能模块代码段；确定所述bug对应的功能模块代码段为需要调试的代码。

例如，程序代码段可以按照程序运行过程中的功能阶段进行分段，如启动、显示、运算、结果反馈等。首先将程序代码按照各功能阶段进行分段，然后初步确定出现故障是在哪个阶段，则可以将该阶段的代码确定为需要调试的代码。例如，当程序启动停滞，无法进入下一阶段时，说明启动阶段有bug，此时只需要将启动阶段对应的代码段作为调试代码进行调试即可。还比如，当程序运算过程中出现闪退，说明运算阶段有bug，此时需要将运算阶段对应的代码段作为调试代码进行调试。

优选的，当代码特性参数为代码长度和代码功能模块分布时，确定单元302具体用于：根据代码功能模块分布确定bug对应的功能模块代码段；确定所述bug对应的功能模块代码段的代码长度，根据该代码长度将功能模块代码段分段，确定其中的一段分段代码为需要调试的代码。

具体的，在确定需要调试的代码时，可以先按照代码功能模块分布如启动、显示、运算、结果反馈等进行分段，然后根据bug出现的阶段确定bug对应的功能模块代码段，如显示闪屏等则说明bug出现在显示功能模块代码段；之后再根据该bug对应的功能模块代码段的代码长度按照平均分段或者逻辑结构进行分段，如将100行的bug对应的功能模块代码段平均分成10段或者按照逻辑结构分成5段，最后确定其中的一段分段代码作为需要调试的代码。

保存单元303，用于将所述调试代码命名为测试文件并保存进临时目录。

确定需要调试的代码段后，保存单元303将调试代码复制形成一个新的文件，并命名为测试文件。为避免与源代码混淆，将该测试文件保存进临时目录。例如，可以在临时目录/tmp目录下建立一个文件，把需要调试的代码拷贝进去，如保存文件名为测试文件test.php。

运行单元304，用于调用执行指令运行所述测试文件。

确定测试文件后，调用相应的执行指令运行该测试文件。例如调用phptest.php指令运行测试代码。

匹配单元305，用于将所述测试文件的运行结果与程序运行结果进行匹配。

运行后，将测试文件的运行结果与有bug的程序运行结果进行匹配，如果完全匹配，说明bug就在这一测试文件里。如果不匹配，说明bug不在该测试文件，需要由确定单元302重新确定需要调试的代码。

修改单元306，用于若匹配单元的结果为完全匹配，则修改所述测试文件。

测试文件的运行结果匹配，说明bug就在该测试文件。此时可以通过进一步的修改测试文件进行调试来实现bug的精准定位。修改测试文件，既可以是对测试文件的代码段继续按照分段规则进行代码分段，缩小分段代码的长度；也可以是修改测试文件中某一具体的代码，例如在所述临时文件目录下增加一个自定义类使其继承需调试的程序文件的目标类，然后保存该文件，继续调用执行指令运行修改后的测试文件。

所述运行单元304，还用于调用执行指令运行修改后的测试文件。

修改完测试文件后，运行单元304调用执行指令继续运行修改后的测试文件。

所述匹配单元305，还用于将所述修改后的测试文件的运行结果与期望结果进行匹配。

运行后，将修改后的测试文件的运行结果与期望的程序运行结果进行匹配，如果完全匹配，说明bug就在测试文件的修改部分。如果不匹配，说明bug不在测试文件的修改部分，需要由修改单元306继续修改测试文件。

具体而言，修改测试文件时会根据该修改得到一个预期的程序运行结果，该预期的程序运行结果即为期望结果。例如，修改测试文件后预期运行的结果是输出一个sql语句，但如果运行后输出的不是sql语句则说明定位的方向有错，bug不在测试文件的修改部分。

定位单元307，用于若匹配单元的结果为完全匹配，则完成bug定位。

若修改后的测试文件的运行结果与期望的程序运行结果完全匹配，则说明bug就在测试文件的修改部分，此时可以实现bug定位。

输出单元308，用于输出bug定位结果。

输出bug的位置以供用户查阅。

可以看出，在本发明实施例的装置中，在接收用户的程序调试指令后，确定需要调试的程序和需要调试的代码，将所述调试代码命名为测试文件并保存进临时目录，调用执行指令运行所述测试文件，将所述测试文件的运行结果与程序运行结果进行匹配，若完全匹配，则修改所述测试文件，调用执行指令运行修改后的测试文件，将所述修改后的测试文件的运行结果与期望结果进行匹配，若完全匹配，则完成bug定位，输出bug定位结果。通过上述方式，解决了现有技术中应用程序bug定位效率低下的问题，能实现bug的快速定位，提高程序调试效率。

请参见图4，图4是本发明实施例提供的另一种定位程序代码中bug的装置的结构示意图。该装置是在图3实施例的基础上进行优化得到的。

所述保存单元303还用于将所述调试代码的接口代码保存进所述临时目录。

该定位程序代码中bug的装置还包括：

检测单元309，用于检测所述接口代码的引用路径是否正确。

所述修改单元306还用于若检测单元309检测的结果是所述引用路径不正确，则修改接口代码的引用路径，使其能正确引用所述程序的目录文件。

可以看出，在本发明实施例的装置中，在接收用户的程序调试指令后，确定需要调试的程序和需要调试的代码，将所述调试代码命名为测试文件并保存进临时目录，将所述调试代码的接口代码保存进所述临时目录，检测所述接口代码的引用路径是否正确，若正确则修改接口代码的引用路径，使其能正确引用所述程序的目录文件，调用执行指令运行所述测试文件，将所述测试文件的运行结果与程序运行结果进行匹配，若完全匹配，则修改所述测试文件，调用执行指令运行修改后的测试文件，将所述修改后的测试文件的运行结果与期望结果进行匹配，若完全匹配，则完成bug定位，输出bug定位结果。通过上述方式，使测试文件仅通过修改接口代码的引用路径即可以引用原程序的所有文件，实现了调试代码范围小，调试效率高的效果，同时解决了现有技术中应用程序bug定位效率低下的问题，能实现bug的快速定位，提高程序调试效率。

在本实施例中，定位程序代码中bug的装置是以单元的形式来呈现。这里的“单元”可以是程序段，也可以是指特定应用集成电路(application－specificintegratedcircuit，asic)，执行一个或多个软件或固件程序的处理器和存储器，集成逻辑电路，和/或其他可以提供上述功能的器件。

本发明实施例还提供一种计算机存储介质，其中，该计算机存储介质可存储有程序，该程序执行时包括上述方法实施例中记载的任何一种定位程序代码中bug方法的部分或全部步骤。

需要说明的是，对于前述的各方法实施例，为了简单描述，故将其都表述为一系列的动作组合，但是本领域技术人员应该知悉，本发明并不受所描述的动作顺序的限制，因为依据本发明，某些步骤可以采用其他顺序或者同时进行。其次，本领域技术人员也应该知悉，说明书中所描述的实施例均属于优选实施例，所涉及的动作和模块并不一定是本发明所必须的。

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

在本申请所提供的几个实施例中，应该理解到，所揭露的装置，可通过其它的方式实现。例如，以上所描述的装置实施例仅仅是示意性的，例如所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，装置或单元的间接耦合或通信连接，可以是电性或其它的形式。

所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。

另外，在本发明各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。

所述集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储器中。基于这样的理解，本发明的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的全部或部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储器中，包括若干指令用以使得一台计算机设备(可为个人计算机、服务器或者网络设备等)执行本发明各个实施例所述方法的全部或部分步骤。而前述的存储器包括：u盘、只读存储器(rom，read－onlymemory)、随机存取存储器(ram，randomaccessmemory)、移动硬盘、磁碟或者光盘等各种可以存储程序代码的介质。

本领域普通技术人员可以理解上述实施例的各种方法中的全部或部分步骤是可以通过程序来指令相关的硬件来完成，该程序可以存储于一计算机可读存储器中，存储器可以包括：闪存盘、只读存储器(英文：read－onlymemory，简称：rom)、随机存取器(英文：randomaccessmemory，简称：ram)、磁盘或光盘等。

以上对本发明实施例进行了详细介绍，本文中应用了具体个例对本发明的原理及实施方式进行了阐述，以上实施例的说明只是用于帮助理解本发明的方法及其核心思想；同时，对于本领域的一般技术人员，依据本发明的思想，在具体实施方式及应用范围上均会有改变之处，综上上述，本说明书内容不应理解为对本发明的限制。