测试方法和测试装置与流程

本发明涉及软件测试领域，具体而言，涉及一种测试方法和测试装置。
背景技术：
：在软件测试的过程中，对软件代码的修改往往牵一发而动全身，尤其是在快速迭代过程中，不仅需要对新功能的正确性进行测试，还要保证不影响原有功能。但目前在对软件进行测试时，都需要编写测试用例，并预先设置返回的结果。现有的这种方法需要编写大量的测试用例，需要消耗大量的人力资源，而且如果预先设置的结果发生了变化，则需要及时修改之前的测试用例，因此，增大了维护软件的成本。针对上述现有技术中在对代码进行测试时需要编写测试用例，从而增大了维护软件的成本的问题，目前尚未提出有效的解决方案。技术实现要素：本发明实施例提供了一种测试方法和测试装置，以至少解决现有技术中由于测试代码需要编写测试用例而造成软件维护成本大的技术问题。根据本发明实施例的一个方面，提供了一种测试方法，包括：获取至少一个请求消息，其中，请求消息用于对程序进行测试；将至少一个请求消息发送至程序的待测试版本得到第一测试结果，以及发送到程序的稳定版本得到第二测试结果，其中，稳定版本的程序是对请求消息能够反馈正确结果的程序；对比第一测试结果和第二测试结果，得到对比结果，其中，对比结果用于确定待测试版本的功能稳定性。根据本发明实施例的另一方面，还提供了一种测试装置，包括：获取模块，用于获取至少一个请求消息，其中，请求消息用于对程序进行测试；发送模块，用于将至少一个请求消息发送至程序的待测试版本得到第一测试结果，以及发送到程序的稳定版本得到第二测试结果，其中，稳定版本的程序是对请求消息能够反馈正确结果的程序；对比模块，用于对比第一测试结果和第二测试结果，得到对比结果，其中，对比结果用于确定待测试版本的功能稳定性。在本发明实施例中，采用对比测试结果的方式，通过获取至少一个请求消息，并将至少一个请求消息发送至程序的待测试版本得到第一测试结果，以及发送到程序的稳定版本得到第二测试结果，最后通过对比第一测试结果和第二测试结果得到对比结果，达到了不需要编写测试用例便可得到软件测试结果的目的，从而实现了节省软件测试的人力资源、降低软件维护的成本的技术效果，进而解决了现有技术中在对代码进行测试时需要编写测试用例，从而增大了维护软件的成本的技术问题。附图说明此处所说明的附图用来提供对本发明的进一步理解，构成本申请的一部分，本发明的示意性实施例及其说明用于解释本发明，并不构成对本发明的不当限定。在附图中：图1是根据本发明实施例的一种测试方法的流程图；图2是根据本发明实施例的一种可选的测试方法的流程图；图3是根据本发明实施例的一种可选的测试方法的流程图；图4是根据本发明实施例的一种可选的测试方法的流程图；图5是根据本发明实施例的一种优选的测试方法的流程图；图6是根据本发明实施例的一种可选的测试方法的流程图；图7是根据本发明实施例的一种可选的测试方法的流程图；图8是根据本发明实施例的一种可选的测试方法的流程图；以及图9是根据本发明实施例的一种测试装置的结构示意图。其中，上述附图包括以下附图标记：901、获取模块；903、发送模块；905、对比模块。具体实施方式为了使本
技术领域：
的人员更好地理解本发明方案，下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分的实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都应当属于本发明保护的范围。需要说明的是，本发明的说明书和权利要求书及上述附图中的术语“第一”、“第二”等是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便这里描述的本发明的实施例能够以除了在这里图示或描述的那些以外的顺序实施。此外，术语“包括”和“具有”以及他们的任何变形，意图在于覆盖不排他的包含，例如，包含了一系列步骤或单元的过程、方法、系统、产品或设备不必限于清楚地列出的那些步骤或单元，而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它步骤或单元。实施例1根据本发明实施例，提供了一种测试方法的实施例。图1是根据本发明实施例的测试方法流程图，如图1所示，该方法包括如下步骤：步骤S102，获取至少一个请求消息，其中，请求消息用于对程序进行测试。在上述步骤S102所限定的方案中，上述程序包括待测试程序和与该待测试程序相对应的已经测试过的稳定版本的程序，上述请求消息可以通过协议请求得到，例如可以通过HTTP的协议请求构造出请求消息。具体的，执行测试软件任务的任务调度平台可以从每天的系统日志中获取请求，并根据获取的请求得到请求消息。通过上述步骤S102可以得到对软件测试时的请求消息，并根据该请求消息对程序进行测试，而不需要再对测试的程序编写输入消息，从而可以进一步降低测试人员的工作量。步骤S104，将至少一个请求消息发送至程序的待测试版本得到第一测试结果，以及发送到程序的稳定版本得到第二测试结果，其中，稳定版本的程序是对请求消息能够反馈正确结果的程序。在上述步骤S104所限定的方案中，上述程序包括两个版本的程序，即待测试版本和稳定版本，其中，待测试版本为对稳定版本进行了修改后的版本。在一种可选的实施例中，仅对稳定版本进行了性能上的修改，例如，在一款预订酒店的应用软件中，开发人员对该应用软件的程序进行了修改，但该应用软件所实现的功能并未发生变化，预期的效果是该应用软件运行的更稳定或占用更少的移动设备的内存。需要说明的是，上述第一测试结果和第二测试结果是通过同一个请求消息获得的，此外，第一测试结果和第二测试结果可以为图像格式，通过图像比较服务可以得到第一测试结果和第二测试结果的差异。通过上述步骤S104，并以执行稳定版本的程序的第二测试结果作为基准来对程序的待测试版本进行评估可以节省测试人员的时间，提高测试效率。步骤S106，对比第一测试结果和第二测试结果，得到对比结果，其中，对比结果用于确定待测试版本的功能稳定性。在上述步骤S106所限定的方案中，根据上述对比结果可以生成测试报告，测试人员通过该测试报告至少可以得到如下信息：第一测试结果与第二测试结果之间是否存在差异、与第一测试程序相对应的被测服务是否存在异常日志以及被测服务的代码覆盖率是否在预设的范围之内等。在一种可选的实施例中，如果第一测试结果与第二测试结果之间存在差异，则说明程序的待测试版本的功能不稳定，反之，则说明程序的待测试版本的功能比较稳定。在另一种可选的实施例中，执行测试软件任务的任务调度平台可以对不同的请求消息赋予不同的权值，然后通过执行步骤S102至步骤S104的方法，得到每个请求消息对应的第一测试结果和第二测试结果，并对比第一测试结果和第二测试结果，得到对比结果，然后再根据对比结果确定请求消息的成功与失败，最后根据每个请求消息的权值以及每个请求消息的成功与失败确定待测试版本的整体情况。其中，如果第一测试结果和第二测试结果之间存在差异，则说明请求消息失败；否则，说明请求消息成功。需要说明的是，可以根据待测试程序在请求消息下使用的频率来确定请求消息的权值，例如，在请求消息A中使用该程序的频率比在请求消息B中使用的频率多，则可以为请求消息A赋予比请求消息B更大的权值。该权值表征了该请求消息的使用频率，即该请求消息对于该程序的重要性。如果在请求消息为请求消息A的情况下，第一测试结果与第二测试结果之间不存在差异，而在请求消息为请求消息B的情况下，第一测试结果与第二测试结果之间存在差异，则说明在请求消息A下测试的程序比在请求消息B下测试的程序稳定，该待测试程序比较稳定。基于上述步骤S102至步骤S106所公开的方案，可以获知通过获取至少一个请求消息，并将至少一个请求消息发送至程序的待测试版本得到第一测试结果，以及发送到程序的稳定版本得到第二测试结果，最后通过对比第一测试结果和第二测试结果得到对比结果，容易注意到的是，由于程序的待测试版本和稳定版本是在同一个请求消息下执行的，并且以稳定版本的第二测试结果为基准来确定程序的待测试版本的稳定性，因此，测试人员无需再编写测试用例，对测试结果进行猜测，达到了不需要编写测试用例便可得到软件测试结果的目的，从而实现了节省软件测试的人力资源、降低软件维护的成本的技术效果，进而解决了现有技术中在对代码进行测试时需要编写测试用例，从而增大了维护软件的成本的技术问题。图2示出了一种可选的测试方法的流程图，如图2所示，具体的，通过该流程图可以获取至少一个请求消息，该方法包括如下步骤：步骤S202，获取多个请求；步骤S204，根据多个请求的代码覆盖情况从多个请求中筛选出至少一个请求；步骤S206，根据至少一个请求构造至少一个请求消息。在上述步骤S202至步骤S206所限定的方案中，执行测试软件任务的任务调度平台从线上日志中获取每天的请求，并获取这些请求的代码覆盖率，根据代码覆盖率从多个请求中筛选出至少一个请求，例如，从这些请求中选取出代码覆盖率大于预设阈值的请求，最后根据请求构造出请求消息，例如通过对请求进行解析得到请求消息。需要说明的是，上述代码覆盖率用于描述程序中源代码被测试的比例和程度，可以用来作为衡量测试好坏的指标。上述请求可以为协议的请求，例如HTTP、DUBBO等。图3示出了一种可选的测试方法的流程图，如图3所示，具体包括如下步骤：步骤S302，获取多个请求中的每个请求覆盖的代码；步骤S304，根据每个请求覆盖的代码从多个请求中筛选出至少一个请求。在上述步骤S302至步骤S304所限定的方案中，可以通过软件测试中的路径覆盖方法得到多个请求中的每个请求覆盖的代码，并计算覆盖的代码与程序中所有的代码的比例，即得到该请求下的代码覆盖率。例如，如表1所示的多个请求与其对应的代码覆盖率。表1请求BACED代码覆盖率78％80％86％86％90％图4示出了一种可选的测试方法的流程图，如图4所示，在得到每个请求下的代码覆盖率之后，从多个请求中筛选出至少一个请求还需要执行如下步骤：步骤S402，获取当前请求覆盖的代码量；步骤S404，判断当前请求覆盖的代码量是否大于上一请求覆盖的代码量；步骤S406，在当前请求覆盖的代码量大于上一请求覆盖的代码量的情况下，保存当前请求。在一种可选的实施例中，所有请求位于请求队列中，通过步骤S302得到每个请求的代码覆盖率之后，所有请求的代码覆盖率以递增的形式在队列中排列，其中，位于队头的请求为当前请求(例如，在表1中，请求B为当前请求)。如图5所示的一种优选的测试方法的流程图，待测试程序的代码覆盖率初始化为0，当前请求B作为请求队列中的未发送请求，位于请求队列的队头。当检测到请求队列中存在未发送请求时，发送该请求，并获取当前请求的代码覆盖率78％。由于78％＞0％，因此请求B被筛选出，并保存；当发送完请求B之后，请求A作为当前请求，其代码覆盖率为80％，大于78％，因此，请求A也将被筛选出，并保存。同样，请求C的代码覆盖率86％＞80％，请求D的代码覆盖率90％＞86％，因此，请求C和请求D被筛选出，并保存；而请求E的代码覆盖率86％不大于请求C的代码覆盖率86％，因此，请求E不会被筛选出。图6示出了一种可选的测试方法的流程图，如图6所示，在得到每个请求下的代码覆盖率之后，从多个请求中筛选出至少一个请求还需要执行如下步骤：步骤S602，从多个请求中筛选出第一请求，并获取第一请求覆盖的代码量；步骤S604，根据第一请求未覆盖到的代码，从多个请求中筛选出能够覆盖第一请求未覆盖到的代码的请求。在一种可选的实施例中，通过步骤S302得到每个请求的代码覆盖率之后，选取代码覆盖率最大的请求作为第一请求，在表1中，选取请求D作为第一请求。如果请求A所覆盖的代码中覆盖了请求D剩余的10％的代码，而其他请求所覆盖的代码覆盖请求D剩余代码的百分比均小于10％，则从上述5个请求中筛选出请求A和请求D。如果请求A所覆盖的代码中只覆盖了请求D剩余的2％的代码，而请求B所覆盖的代码中覆盖了请求D和请求A剩余的8％的代码，而请求C和请求E均只覆盖了请求D剩余的1％的代码，则请求A、请求B和请求E被筛选出。需要说明的是，如果至少两个请求的代码覆盖率相同，并且该代码覆盖率是最大的，此时，从这些请求中任意选择一个请求作为第一请求。图7示出了一种可选的测试方法的流程图，如图7所示，在得到每个请求下的代码覆盖率之后，从多个请求中筛选出至少一个请求需要执行的步骤还包括如下步骤：步骤S702，根据多个请求中的每个请求覆盖的代码判断多个请求中的一组请求覆盖的代码是否覆盖程序的全部代码；步骤S704，在一组请求覆盖的代码覆盖程序的全部代码的情况下，至少两个请求被筛选出。在一种可选的实施例中，对所有的请求进行组合，如果组合后的请求能够覆盖程序的所有代码，则组合后的请求将被筛选出。需要说明的是，如果存在多种组合均能覆盖程序的所有代码，则选择组合中包含请求数量最少的请求被筛选出。例如，表1中的请求A和请求B可以覆盖程序中的所有代码，而请求A、请求C和请求D也可以覆盖程序中的所有代码，则请求A和请求B被筛选出。通过上述方法，可以选择请求数量最少的请求组合，可以有效的节省测试时间，提高测试效率。图8示出了通过对比第一测试结果和第二测试结果，得到对比结果的方法流程图，如图8所示，该方法具体包括如下步骤：步骤S802，删除第一测试结果由于预定原因导致失败的测试结果；步骤S804，将删除后的第一测试结果和第二测试结果进行比对，得到对比结果。在上述步骤S802至步骤S804所限定的方案中，当对第一测试结果和第二测试结果进行比对时，由于第一测试结果中可能包含时间戳或者随机数字等字段，使得第一测试结果和第二测试结果之间存在差异，对比结果为待测试版本的程序不稳定。在一种可选的实施例中，第一测试结果和第二测试结果中均包含时间戳，由于两个测试版本可能不在同一时间同步进行，所以两个测试结果中的时间戳不相同，例如，第一测试结果中的时间戳可能为“4634637715”，而第二测试结果中的时间戳可能为“4635501715”，由于两个测试结果中的时间戳不相同，因而使得对待测试版本的程序的测试失败。需要说明的是上述预定原因包括如下至少：由于时间戳导致的失败、由于随机数导致的失败。此外，在执行步骤S202，即获取多个请求的过程中，可以从日志文件中获取预定时间段中的请求作为多个请求，例如可以从每天的线上日志中获取多个请求。在得到上述多个请求后在对其进行智能筛选，得到对代码覆盖率有贡献的请求。实施例2根据本发明实施例，提供了一种测试装置的实施例，其中，上述实施例1中的方法可以在本实施例中所提供的装置中运行。图9是根据本发明实施例的测试装置，如图9所示，该装置包括：获取模块901、发送模块903和对比模块905。获取模块901，用于获取至少一个请求消息，其中，请求消息用于对程序进行测试。在上述获取模块901中，上述程序包括待测试程序和与该待测试程序相对应的已经测试过的稳定版本的程序，上述请求消息可以通过协议请求得到，例如可以通过HTTP的协议请求构造出请求消息。具体的，执行测试软件任务的任务调度平台可以从每天的系统日志中获取请求，并根据获取的请求得到请求消息。通过上述获取模块901可以得到对软件测试时的请求消息，并根据该请求消息对程序进行测试，而不需要再对测试的程序编写输入消息，从而可以进一步降低测试人员的工作量。发送模块903，用于将至少一个请求消息发送至程序的待测试版本得到第一测试结果，以及发送到程序的稳定版本得到第二测试结果，其中，稳定版本的程序是对请求消息能够反馈正确结果的程序。在上述发送模块903中，上述程序包括两个版本的程序，即待测试版本和稳定版本，其中，待测试版本为对稳定版本进行了修改后的版本。在一种可选的实施例中，仅对稳定版本进行了性能上的修改，例如，在一款预订酒店的应用软件中，开发人员对该应用软件的程序进行了修改，但该应用软件所实现的功能并未发生变化，预期的效果是该应用软件运行的更稳定或占用更少的移动设备的内存。需要说明的是，上述第一测试结果和第二测试结果是通过同一个请求消息获得的，此外，第一测试结果和第二测试结果可以为图像格式，通过图像比较服务可以得到第一测试结果和第二测试结果的差异。通过在发送模块903中执行实施例1中的步骤S104，并以执行稳定版本的程序的第二测试结果作为基准来对程序的待测试版本进行评估可以节省测试人员的时间，提高测试效率。对比模块905，用于对比第一测试结果和第二测试结果，得到对比结果，其中，对比结果用于确定待测试版本的功能稳定性。在上述对比模块905中，根据上述对比结果可以生成测试报告，测试人员通过该测试报告至少可以得到如下信息：第一测试结果与第二测试结果之间是否存在差异、与第一测试程序相对应的被测服务是否存在异常日志以及被测服务的代码覆盖率是否在预设的范围之内等。在一种可选的实施例中，如果第一测试结果与第二测试结果之间存在差异，则说明程序的待测试版本的功能不稳定，反之，则说明程序的待测试版本的功能比较稳定。在另一种可选的实施例中，执行测试软件任务的任务调度平台可以对不同的请求消息赋予不同的权值，然后通过执行实施例1中步骤S102至步骤S104的方法，得到每个请求消息对应的第一测试结果和第二测试结果，并对比第一测试结果和第二测试结果，得到对比结果，然后再根据对比结果确定请求消息的成功与失败，最后根据每个请求消息的权值以及每个请求消息的成功与失败确定待测试版本的整体情况。其中，如果第一测试结果和第二测试结果之间存在差异，则说明请求消息失败；否则，说明请求消息成功。需要说明的是，可以根据待测试程序在请求消息下使用的频率来确定请求消息的权值，例如，在请求消息A中使用该程序的频率比在请求消息B中使用的频率多，则可以为请求消息A赋予比请求消息B更大的权值。该权值表征了该请求消息的使用频率，即该请求消息对于该程序的重要性。如果在请求消息为请求消息A的情况下，第一测试结果与第二测试结果之间不存在差异，而在请求消息为请求消息B的情况下，第一测试结果与第二测试结果之间存在差异，则说明在请求消息A下测试的程序比在请求消息B下测试的程序稳定，该待测试程序比较稳定。由上可知，通过获取至少一个请求消息，并将至少一个请求消息发送至程序的待测试版本得到第一测试结果，以及发送到程序的稳定版本得到第二测试结果，最后通过对比第一测试结果和第二测试结果得到对比结果，容易注意到的是，由于程序的待测试版本和稳定版本是在同一个请求消息下执行的，并且以稳定版本的第二测试结果为基准来确定程序的待测试版本的稳定性，因此，测试人员无需再编写测试用例，对测试结果进行猜测，达到了不需要编写测试用例便可得到软件测试结果的目的，从而实现了节省软件测试的人力资源、降低软件维护的成本的技术效果，进而解决了现有技术中在对代码进行测试时需要编写测试用例，从而增大了维护软件的成本的技术问题。此处需要说明的是，上述获取模块901、发送模块903和对比模块905对应于实施例1中的步骤S102至步骤S106，三个模块与对应的步骤所实现的示例和应用场景相同，但不限于上述实施例1所公开的内容。可选的，获取模块901包括：第一获取模块、筛选模块和构造模块。其中，第一获取模块，用于获取多个请求；筛选模块，用于根据多个请求的代码覆盖情况从多个请求中筛选出至少一个请求；构造模块，用于根据至少一个请求构造至少一个请求消息。作为一种可选的实施例，执行测试软件任务的任务调度平台从线上日志中获取每天的请求，并获取这些请求的代码覆盖率，根据代码覆盖率从多个请求中筛选出至少一个请求，例如，从这些请求中选取出代码覆盖率大于预设阈值的请求，最后根据请求构造出请求消息，例如通过对请求进行解析得到请求消息。需要说明的是，上述代码覆盖率用于描述程序中源代码被测试的比例和程度，可以用来作为衡量测试好坏的指标。上述请求可以为协议的请求，例如HTTP、DUBBO等。此处还需要说明的是，上述第一获取模块、筛选模块和构造模块对应于实施例1中的步骤S202至步骤S206，三个模块与对应的步骤所实现的示例和应用场景相同，但不限于上述实施例1所公开的内容。可选的，筛选模块包括：第二获取模块和第一筛选模块。其中，第二获取模块，用于获取多个请求中的每个请求覆盖的代码；第一筛选模块，用于根据每个请求覆盖的代码从多个请求中筛选出至少一个请求。作为一种可选的实施例，可以通过软件测试中的路径覆盖方法得到多个请求中的每个请求覆盖的代码，并计算覆盖的代码与程序中所有的代码的比例，即得到该请求下的代码覆盖率。例如，如表3所示的多个请求与其对应的代码覆盖率。表2请求BACED代码覆盖率78％80％86％86％90％此处需要说明的是，上述第二获取模块和第一筛选模块对应于实施例1中的步骤S302至步骤S304，两个模块与对应的步骤所实现的示例和应用场景相同，但不限于上述实施例1所公开的内容。可选的，第一筛选模块包括第三获取模块、判断子模块以及存储模块。其中，第三获取模块用于获取当前请求覆盖的代码量；判断子模块用于判断当前请求覆盖的代码量是否大于上一请求覆盖的代码量；存储模块用于在当前请求覆盖的代码量大于上一请求覆盖的代码量的情况下，保存当前请求。在一种可选的实施例中，所有请求位于请求队列中，在得到每个请求的代码覆盖率之后，所有请求的代码覆盖率以递增的形式在队列中排列，其中，位于队头的请求为当前请求(例如，在表1中，请求B为当前请求)。如图5所示的一种优选的测试方法的流程图，待测试程序的代码覆盖率初始化为0，当前请求B作为请求队列中的未发送请求，位于请求队列的队头。当检测到请求队列中存在未发送请求时，发送该请求，并获取当前请求的代码覆盖率78％。由于78％＞0％，因此请求B被筛选出，并保存；当发送完请求B之后，请求A作为当前请求，其代码覆盖率为80％，大于78％，因此，请求A也将被筛选出，并保存。同样，请求C的代码覆盖率86％＞80％，请求D的代码覆盖率90％＞86％，因此，请求C和请求D被筛选出，并保存；而请求E的代码覆盖率86％不大于请求C的代码覆盖率86％，因此，请求E不会被筛选出。此处还需要说明的是，上述第三获取模块、判断子模块以及存储模块对应于实施例1中的步骤S402至步骤S406，三个模块与对应的步骤所实现的示例和应用场景相同，但不限于上述实施例1所公开的内容。可选的，第一筛选模块包括代码量获取模块以及第二筛选模块。其中，代码量获取模块，用于从多个请求中筛选出第一请求，并获取第一请求覆盖的代码量；第二筛选模块，用于根据第一请求未覆盖到的代码，从多个请求中筛选出能够覆盖第一请求未覆盖到的代码的请求。在一种可选的实施例中，在得到每个请求的代码覆盖率之后，选取代码覆盖率最大的请求作为第一请求，在表2中，选取请求D作为第一请求。如果请求A所覆盖的代码中覆盖了请求D剩余的10％的代码，而其他请求所覆盖的代码覆盖请求D剩余代码的百分比均小于10％，则从上述5个请求中筛选出请求A和请求D。如果请求A所覆盖的代码中只覆盖了请求D剩余的2％的代码，而请求B所覆盖的代码中覆盖了请求D和请求A剩余的8％的代码，而请求C和请求E均只覆盖了请求D剩余的1％的代码，则请求A、请求B和请求E被筛选出。需要说明的是，如果至少两个请求的代码覆盖率相同，并且该代码覆盖率是最大的，此时，从这些请求中任意选择一个请求作为第一请求。此处还需要说明的是，上述代码量获取模块以及第二筛选模块对应于实施例1中的步骤S602至步骤S604，两个模块与对应的步骤所实现的示例和应用场景相同，但不限于上述实施例1所公开的内容。可选的，第一筛选模块包括判断模块以及第三筛选模块。其中，判断模块，根据多个请求中的每个请求覆盖的代码判断多个请求中的至少两个请求覆盖的代码是否覆盖程序的全部代码；第三筛选模块，在至少两个请求覆盖的代码覆盖程序的全部代码的情况下，至少两个请求被筛选出。在一种可选的实施例中，对所有的请求进行组合，如果组合后的请求能够覆盖程序的所有代码，则组合后的请求将被筛选出。需要说明的是，如果存在多种组合均能覆盖程序的所有代码，则选择组合中包含请求数量最少的请求被筛选出。例如，表2中的请求A和请求B可以覆盖程序中的所有代码，而请求A、请求C和请求D也可以覆盖程序中的所有代码，则请求A和请求B被筛选出。通过上述方法，可以选择请求数量最少的请求组合，可以有效的节省测试时间，提高测试效率。此处需要说明的是，上述判断模块以及第三筛选模块对应于实施例1中的步骤S702至步骤S704，两个模块与对应的步骤所实现的示例和应用场景相同，但不限于上述实施例1所公开的内容。可选的，对比模块905包括：删除模块和第一对比模块。其中，删除模块，用于删除第一测试结果由于预定原因导致失败的测试结果；第一对比模块，用于将删除后的第一测试结果和第二测试结果进行比对，得到对比结果。在上述对比模块中，当对第一测试结果和第二测试结果进行比对时，由于第一测试结果中可能包含时间戳或者随机数字等字段，使得第一测试结果和第二测试结果之间存在差异，对比结果为待测试版本的程序不稳定。在一种可选的实施例中，第一测试结果和第二测试结果中均包含时间戳，由于两个测试版本可能不在同一时间同步进行，所以两个测试结果中的时间戳不相同，例如，第一测试结果中的时间戳可能为“4634637715”，而第二测试结果中的时间戳可能为“4635501715”，由于两个测试结果中的时间戳不相同，因而使得对待测试版本的程序的测试失败。需要说明的是上述预定原因包括如下至少：由于时间戳导致的失败、由于随机数导致的失败。此处还需要说明的是，上述删除模块和第一对比模块对应于实施例1中的步骤S802至步骤S804，两个模块与对应的步骤所实现的示例和应用场景相同，但不限于上述实施例1所公开的内容。此外，在第一获取模块中可以执行实施例1中的步骤S202的方法，从日志文件中获取预定时间段中的请求作为多个请求，例如可以从每天的线上日志中获取多个请求。在得到上述多个请求后在对其进行智能筛选，得到对代码覆盖率有贡献的请求。上述本发明实施例序号仅仅为了描述，不代表实施例的优劣。在本发明的上述实施例中，对各个实施例的描述都各有侧重，某个实施例中没有详述的部分，可以参见其他实施例的相关描述。在本申请所提供的几个实施例中，应该理解到，所揭露的技术内容，可通过其它的方式实现。其中，以上所描述的装置实施例仅仅是示意性的，例如所述单元的划分，可以为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，单元或模块的间接耦合或通信连接，可以是电性或其它的形式。所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。另外，在本发明各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。所述集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本发明的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的全部或部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可为个人计算机、服务器或者网络设备等)执行本发明各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：U盘、只读存储器(ROM，Read-OnlyMemory)、随机存取存储器(RAM，RandomAccessMemory)、移动硬盘、磁碟或者光盘等各种可以存储程序代码的介质。以上所述仅是本发明的优选实施方式，应当指出，对于本
技术领域：
的普通技术人员来说，在不脱离本发明原理的前提下，还可以做出若干改进和润饰，这些改进和润饰也应视为本发明的保护范围。当前第1页1 2 3