具体实施方式
为了使本技术领域的人员更好地理解本申请中的技术方案,下面将结合本申请实施例中的附图,对本申请实施例中的技术方案进行清楚、完整地描述,显然,所描述的实施例仅仅是本申请一部分实施例,而不是全部的实施例。基于本申请中的实施例,本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例,都应当属于本申请保护的范围。
下面结合附图对本申请所述的构建测试用例请求对象的方法进行详细的说明。图1是本申请提供的构建测试用例请求对象方法的一种实施例的方法流程示意图。虽然本申请提供了如下述实施例或附图所示的方法操作步骤,但基于常规或者无需创造性的劳动在所述方法中可以包括更多或者更少的操作步骤。在逻辑性上不存在必要因果关系的步骤中,这些步骤的执行顺序不限于本申请实施例提供的执行顺序。所述方法在实际中的测试用例请求对象构建过程中或者装置执行时,可以按照实施例或者附图所示的方法顺序执行或者并行执行(例如并行处理器或者多线程处理的环境)。
具体的本申请提供的构建测试用例请求对象方法的一种实施例如图1所示,所述方法可以包括:
S1:获取待测系统的目标数据源,所述目标数据源与所述待测系统具有业务关联关系。
本实施例中的待测系统可以包括已经开发完成的计算机软件系统,一般地,可以将所述待测系统与计算机硬件、其它支持软件、数据和人员等系统元素结合在一起,对所述待测系统进行测试。测试的目的在于通过将测试的预期结果数据与实际结果数据作比较,发现待测系统与初始系统定义之间不匹配或者相矛盾的地方,以验证待测系统的功能和性能等指标是否满足预设要求。例如,所述待测系统可以为日常所用的各种支付应用、购物应用、外卖应用等,所述待测系统还可以为应用中的功能模块,例如,XX应用中的外卖功能模块等。
本实施例中的目标数据源可以与所述待测系统具有关联关系,例如,所述目标数据源可以包括所述待测系统的业务日志、与所述待测系统相似业务系统的业务日志、其他离线数据源等。本实施例中的目标数据源可以包含真实场景中的业务信息,如用户搜索行为日志、商品交易日志等。例如,当所述待测系统为外卖系统,且测试目标在于测试所述外卖系统的搜索性能是否满足预设要求时,提供的目标数据源可以为外卖系统或者其他相似外卖系统的用户搜索日志。
本实施例中获取的目标数据源与待测系统具有关联关系,所述目标数据源可以为构建测试用例请求对象提供真实的业务场景,为构建测试用例请求对象提高可靠的数据基础。
S2:根据所述待测系统的预设请求参数从所述目标数据源中采集得到用例参数数据。
本实施例中的预设请求参数作为向所述待测系统发出测试请求的参数,对构建测试用例请求对象具有重要意义,所述预设请求参数的设置与构建测试用例的测试目标、测试规模、测试策略等因素紧密联系。例如,当所述待测系统为外卖系统,且测试目标在于测试所述外卖系统的搜索性能是否满足预设要求时,可以设置所述预设请求参数为搜索词。若所述测试目标在于测试所述外卖系统在某个城市的搜索性能是否满足预设性能时,可以设置所述预设请求参数为搜索词和城市两个参数。
本实施例中的实施例主体可以为软件测试平台,所述软件测试平台被设置为可以访问所述待测系统、向所述待测系统发出测试请求以及获取测试结果数据。所述软件测试平台还可以读取所述目标数据源中的数据,并从所述目标数据源中采集得到用例参数数据。
当所述目标数据源为用户搜索日志时,所述用户搜索日志中包含至少一条用户搜索数据,且用户搜索数据中包含的信息相对比较全面、完整,例如,获取的用户搜索数据的格式为:用户名/城市/经纬度/搜索词/类目/…/…/搜索耗时/响应结果。如上所述,所述预设请求参数的设置与构建测试用例的测试目标、测试规模、测试策略等紧密联系,所述预设请求参数一般不与用户搜索数据中包含的参数完全匹配,所述用户搜索数据中与所述预设请求参数相对应的参数数据才是构建测试用例请求对象的必要数据。本实施例中,可以根据所述待测系统的预设请求参数从所述目标数据源中采集得到用例参数数据。例如,若所述预设请求参数为搜索词和城市,则可以从所述用户搜索日志中提取与“搜索词”和“城市”相对应的用例参数数据。当然,在其他实施例中,还可以根据所述预设请求参数以外的参数采集所述用例参数数据,本申请在此不做限制。
在本申请的一个实施例中,所述用例参数数据可以包括下述采集方式:
在预设采集时间内按照业务参考指标从所述目标数据源中采集得到所述用例参数数据。
其中,预设采集时间的设置可以参考数据源的时间特征,例如,周末时间的用户搜索日志数据量相对较多,数据更加具有参考价值,此时,可以设置数据预设采集时间为周末。所述业务参考指标可以作为采集顺序的参考指标,当用户搜索日志中包含的数据量较多时,数据的参考价值参差不齐,此时可以将业务参考指标作为采集顺序的标准。在本申请的一个实施例中,所述业务参考指标至少包括下述中的一种:业务数据访问量、业务数据评价次数、业务数据评分指数、业务数据交易完成量。本实施例中,可以从业务数据访问量、业务数据评价次数、业务数据评分指数、业务数据交易完成量中的一个指标或者多个指标,确定数据采集的顺序。例如,当测试目标在于测试待测系统在美食分类的搜索性能时,可以基于用户搜索的美食访问量从高到低的顺序从用户美食搜索日志中采集用例参数数据。另外,还可以设置采集数据量上限,所述采集数据量上限为采集数据最多的个数,设置采集数据量上限可以限制测试用例的数量,不仅可以控制系统的存储空间,还可以保证较高的测试效率。
本实施例中,在构建测试用例请求对象的过程中,可以从与待测系统有业务关联关系的目标数据源中采集用例参数数据,采集得到的用例参数数据不仅可以为构建测试用例提供业务场景,还可以作为构建测试用例请求对象的基础。相对于现有技术中构建测试用例时人工搭建业务场景,本实施例中从目标数据源中提取真实的业务场景,不仅可以提高构建业务场景的效率,还可以提高测试用例与真实业务场景的关联性,进而提高测试用例的质量。
S3:从所述用例参数数据中读取所述预设请求参数对应的参数值。
本实施例中,可以从所述用例参数数据中读取所述预设请求参数对应的参数值。由S2可知,从所述目标数据源中采集所述用例参数数据时所使用的参数包括所述预设请求参数。由于所述用例参数数据为结果性的业务场景数据,因此,所述用例参数数据中至少包括所述预设请求参数所对应的参数值。表1是一个应用场景中根据预设请求参数“搜索词”、“城市代码”从美食分类中获取的10000条用例参数数据,如表1所示,在展示的所述10000条用例参数数据中,有部分数据是重复的,例如,编号1和编号7对应的“肯德基”、“341500”。本申请的一个实施例中,可以对采集得到的用例参数数据进行预处理,例如对数据去重处理等,实现对用例参数数据进行清洗的目的。本场景中,在对上述采集得到的10000条用例参数数据进行去重处理之后,最终还剩余8500条用例参数数据。那么,根据所述8500条用例参数数据中搜索词与城市代码的对应关系,可以构建8500个测试用例。
表1用例参数数据
S4:构建所述待测系统的测试用例的请求对象,所述请求对象包括所述预设请求参数以及对应的参数值。
本实施例中,可以构建所述待测系统的测试用例的请求对象,所述请求对象包括所述预设请求参数以及对应的参数值。根据所述请求对象,可以向所述待测系统发出测试请求。例如,在S3所述的场景中,可以设置所述请求对象的格式为{搜索词=肯德基,分类=美食,城市代码=010111}。需要说明的是,所述请求对象中除了包括所述预设请求参数之外,还可以包括所述待测系统的系统参数,例如算法策略、查询类型等参数,此时,所述请求对象的格式可以被设置为{算法策略=a,查询类型=b,搜索词=肯德基,分类=美食,城市代码=010103}。所述系统参数可以从所述待测系统的配置信息中读取得到。
本实施例中,可以基于采集得到的用例参数数据生成所述测试用例的请求对象,所述请求对象包含系统参数和预设请求参数,如此,可以将系统维度和业务维度的配置结合到测试用例中。在本申请的另一个实施例中,在所述构建所述待测系统的测试用例的请求对象之后,所述方法还可以包括:
S5:基于所述请求对象以及所述待测系统的预设测试字段,构建所述测试用例的预期结果数据。
一般地,测试用例包括输入部分和预期结果数据,本实施例中,可以基于所述请求对象以及所述待测系统的预设测试字段,构建所述测试用例的预期结果数据。本实施例中,所述测试用例的输入部分可以包括所述请求对象和预设测试字段,所述预设测试字段可以根据所述待测系统的测试目标进行预先设定,且可以从所述待测系统的配置信息中读取。本申请的一个实施例提供了一种生成测试用例预期结果数据的方法,图2是本申请提供的构建测试用例预期结果数据方法的一种实施例的方法流程图,如图2所示,所述基于所述请求对象以及所述待测系统的预设测试字段,构建所述测试用例的预期结果数据可以包括:
S21:向所述待测系统发出测试请求,所述测试请求中包括所述请求对象。
如上所述,所述请求对象可以包括预设请求参数、预设请求参数的参数值、系统参数、系统参数的参数值。本实施例中,可以向所述待测系统发出测试请求,所述测试请求中至少包括所述请求对象。例如,可以通过预设接口向所述外卖系统发出测试请求,所述测试请求中至少包括请求对象A{算法策略=a,查询类型=b,搜索词=肯德基,分类=美食,城市代码=010111}。所述外卖系统在接收所述测试请求后,响应于所述测试请求,可以基于所述请求对象A中的算法策略a和查询类型b,从杭州(杭州的城市代码为010111)的美食分类中搜索肯德基的结果数据。
S22:接收所述待测系统返回的第一测试结果数据。
本实施例中,所述待测系统响应于所述测试请求,输入所述请求对象进行测试,生成第一测试结果数据。所述第一测试结果数据作为生成所述测试用例的预期结果数据的基础,因此,所述待测系统在测试过程中设置的环境具有重要的影响。
在本申请的一个实施例中,所述第一测试结果数据可以包括所述待测系统在基准环境中响应于所述测试请求获取的测试结果数据。
本实施例中,所述测试请求中可以包括环境信息,设置本实施例中的环境信息为基准环境。所述基准环境为所述待测系统的预发布环境,所述基准环境更加稳定,更加接近于用户使用所述待测系统时的真实环境,因此,将所述待测系统在所述基准环境中测试得到的数据结果数据作为第一测试结果数据,更加符合预期结果数据的生成条件。
S23:从所述第一测试结果数据中提取出所述预设测试字段对应的第一字段值,将所述第一字段值作为所述测试用例的预期结果数据。
本实施例中,所述待测系统返回的第一测试结果数据中可以包含至少一个测试参数,测试参数的设置和测试参数的个数可以根据所述请求对象中的系统参数或者对所述待测系统的预先设置确定得到。在本申请的一个实施例中,所述第一测试结果数据可以以网表的形式展示出来。在一个示例中,所述第一测试结果数据的展示格式可以为:用户/城市/搜索词/类目/优惠/…/…/搜索耗时/评价指数。本实施例中的预设测试字段为所述待测系统的校对参数,所述预设测试字段同样可以从所述待测系统的配置参数中读取。所述预设测试字段包含于所述第一测试结果数据的测试参数,例如,基于上述第一测试结果数据的测试参数,所述预设测试字段可以为{城市,搜索词,优惠}。从所述第一测试结果数据中提取出所述预设测试字段对应的第一字段值,将所述第一字段值作为所述测试用例的预期结果数据,例如,所述第一字段值可以为{城市=杭州,搜索词=肯德基,优惠=9折},{城市=上海,搜索词=麦当劳,优惠=9.5折},……,{城市=苏州,搜索词=海底捞,优惠=满500减50}。
本实施例中,可以基于所述请求对象向所述待测系统发出测试请求,所述测试系统响应于所述测试请求,返回第一测试结果数据。根据待测系统的预设测试字段,从所述第一测试结果数据中裁剪出与所述预设测试字段相对应的第一字段值,并将所述第一字段值作为所述测试用例的预期结果数据。另外,所述预设测试字段的设置与测试目标紧密联系,且所述预设测试字段可以根据需要进行变化,增强所述测试用例的多样性,提高测试用例的质量。
在本申请的另一个实施例中,还提供了一种筛选测试用例的方法,图3是本申请提供的筛选测试用例方法的一种实施例的方法流程图,如图3所示,所述在接收所述待测系统返回的第一测试结果数据之后,所述方法还可以包括:
S31:根据所述第一测试结果数据,计算所述测试用例的代码覆盖率。
本实施例中,根据所述第一测试结果数据,可以获取所述测试用例的代码覆盖率,所述代码覆盖率为所述待测系统在执行测试动作时所使用的源代码的比例。本实施例中,可以使用代码覆盖率工具计算得到所述测试用例的代码覆盖率。
S32:计算所述待测系统中包含的测试用例的代码覆盖率。
本实施例中,在根据目标数据源生成测试用例的过程中,所述用例参数数据越多,相应地,生成测试用例请求对象的数量也越多。因此,本实施例中,所述待测系统中可以包含多个测试用例,且所述多个测试用例源于同一批用例参数数据或者具有相同测试目标。如上述举例中,根据请求参数“搜索词”、“城市代码”,从美食分类中获取10000条用例参数数据,对所述用例参数数据进行去重之后,最终还剩余8500条用例参数数据,根据所述8500条用例参数数据中搜索词、城市代码的对应关系,可以构建8500个测试用例。本实施例中,按照S21-S22计算得到所述8500个测试用例中每个测试用例的测试结果数据,并从所述测试结果数据中计算每个测试用例的代码覆盖率。
S33:删除所述待测系统包含的测试用例中代码覆盖率差值小于预设阈值的重复测试用例。
本实施例中,获取所述待测系统包含的测试用例的代码覆盖率后,可以将所述待测系统包含的测试用例的代码覆盖率进行排序。在本申请的一个实施例中,可以按照代码覆盖率从小到大的顺序对测试用例进行重新排序。当有多个测试用例的代码覆盖率差值小于预设阈值时,可以确定所述多个测试用例具有重复性,此时,可以对所述测试用例进行去重处理。例如,在对上述举例中的8500个测试用例的代码覆盖率进行排序后,发现有300个测试用例的代码覆盖率在(85±0.8)%范围之内,此时可以对所述300个测试用例进行去重处理,并保留其中的一个测试用例。
本实施例中,可以基于测试用例的代码覆盖率对所述测试用例进行筛选处理,去除冗余重复的测试用例,进一步提高测试用例的质量,提高测试效率。
在本申请的另一个实施例中,还提供一种获取测试用例挖掘结果数据的方法。图4是本申请提供的获取测试用例挖掘结果数据方法的一种实施例的方法流程图,如图4所示,在所述构建所述待测系统的测试用例的请求对象之后,所述方法还可以包括:
S41:获取所述待测系统的关联系统,向所述关联系统发出测试请求,所述测试请求包括所述请求对象。
本实施例中,还可以进一步获取所述测试用例的挖掘结果数据,具体地,可以从所述待测系统的关联系统中获取所述挖掘结果数据。所述关联系统与所述待测系统业务上相关联,例如,所述外卖系统的关联系统可以为具有类似业务的推荐类系统。所述关联系统信息可以从所述待测系统的配置参数中获取。
S42:接收所述关联系统返回的第二测试结果数据。
S43:从所述第二测试结果数据中提取出所述预设测试字段对应的第二字段值,将所述第二字段值作为所述测试用例的挖掘结果数据。
S42、S43的具体实施方式可以参考S22、S23,在此不再赘述。
本实施例中,可以基于所述待测系统的关联系统,获取所述测试用例的挖掘结果数据,将所述测试用例的挖掘结果数据与实际结果数据进行对比,通过待测系统与关联系统的测试结果数据的误差,一方面可以了解待测系统的准确性,另一方面可以为产品业务提供参考数据。
需要说明的是,后续的,本实施例中,还可以向所述待测系统发出测试请求,并设置所述测试请求中的环境为测试环境,所述测试环境相对于基准环境而言,参数配置相对宽松,可以根据测试需要进行设置。根据所述预设测试字段,将所述待测系统在所述测试环境中获取的测试结果数据进行裁剪后得到的结果数据作为实际结果数据。具体的数据处理过程可以参考S21-S23,在此不再赘述。在构建完整的测试用例之后,可以根据测试用例的测试结果数据,生成所述测试用例的测试报告。具体地,可以将测试用例中的预期结果数据与实际结果数据进行对比,生成所述测试用例的功能测试报告;将测试用例中的挖掘结果数据与实际结果数据进行对比,生成所述测试用例的参考测试报告。还可以基于上述代码覆盖情况,生成测试用例的系统覆盖率报告。最后,可以将所述功能测试报告、参考测试报告和代码覆盖率报告发送给用户,供用户参考。
表2第一测试结果数据表
下面通过一个具体的应用场景说明本发明实施例方法,本场景中的待测系统为XX应用中的外卖系统,例如支付宝客户端中的口碑(外卖)系统,本次测试的目的在于测试所述外卖系统的搜索功能。图5是本申请提供的构建的测试用例1的示意图,如图5所示,测试用例1的构建基于的目标数据源包括用户搜索日志和离线数据Data1。基于预设请求参数“搜索词”、“分类=美食”从目标数据源中获取如表1所示的10000条用例参数数据,对所述用例参数数据进行去重处理后,最终剩余8500条用例参数数据。读取所述外卖系统的系统配置参数,获取所述系统参数为{算法策略=a,查询类型=b}。从表1中读取第一条采集数据的搜索词“肯德基”,构建测试用例1,输入预设请求参数的值,其中,搜索词=肯德基,分类=美食。同理,在构建测试用例2时,搜索词=9味龙虾,分类=美食;构建测试用例3时,搜索词=麦当劳,分类=美食,…,一共可以构建8500个测试用例。至此,可以生成测试用例1的请求对象1{算法策略=a,查询类型=b,搜索词=肯德基,分类=美食}。向所述外卖系统发出测试请求,所述测试请求中包括请求对象1和运行环境,所述运行环境可以设置为基准环境。所述外卖系统接收到所述测试请求后,在所述基准环境中输入“搜索词=肯德基,分类=美食”,生成如表2所示的第一测试结果数据,所述第一测试结果数据中包含M条数据,如表2所示,所述第一测试结果数据的展示格式为:搜索词/类目/用户名/城市/经度/纬度/优惠/搜索耗时/评价指数。如图5所示,测试用例1的预设测试字段为“城市,搜索词,优惠”,根据所述预设测试字段,从所述第一数据结果数据表中裁剪得到如图5所示的预期结果数据。从外卖系统的系统配置参数中读取关联系统为XX推荐类系统,基于请求对象2{算法策略=a,查询类型=b,搜索词=肯德基,分类=美食},向XX推荐类系统发出测试请求,所述测试请求中包括请求对象2。所述XX推荐类系统响应于所述测试请求,并返回第二测试结果数据,根据所述测试字段“城市,搜索词,优惠”,从所述第二数据结果数据表中裁剪得到如图5所示的挖掘结果数据。最后,向所述外卖系统发送第二次测试请求,所述测试请求中包括请求对象1和运行环境,所述运行环境被设置为测试环境。从所述外卖系统返回的结果数据中裁剪得到如图5所述的实际结果数据。
本申请提供的构建测试用例请求对象的方法、装置及系统,可以从与待测系统有业务关联关系的目标数据源中采集用例参数数据,采集得到的用例参数数据不仅可以为构建测试用例提供业务场景,还可以作为构建测试用例请求对象的基础。相对于现有技术中构建测试用例时人工搭建业务场景,本实施例在测试用例请求对象的构建过程中,从目标数据源中提取真实的业务场景,不仅可以提高构建业务场景的效率,还可以提高测试用例与真实业务场景的关联性,进而提高测试用例的质量。
另外,将请求对象和测试字段作为所述测试用例的输入数据,并基于所述输入数据生成所述测试的预期结果数据,通过调节请求对象可以获取不同的采集数据,调节测试字段得到不同的预期结果,因此,可以建立多种可能性的测试用例,增强测试用例的适应性能。
基于本申请实施例所述的构建测试用例请求对象的方法,本申请还提供一种构建测试用例请求对象的装置。图6是本申请提供的构建测试用例请求对象装置的一种实施例的模块结构示意图,如图6所示,所述装置60可以包括:
数据源获取单元61,用于获取待测系统的目标数据源,所述目标数据源与所述待测系统具有关联关系;
数据采集单元62,用于根据所述待测系统的预设请求参数从所述目标数据源中采集得到用例参数数据;
参数值读取单元63,用于从所述用例参数数据中读取所述预设请求参数对应的参数值;
请求对象构建单元64,用于构建所述待测系统的测试用例的请求对象,所述请求对象包括所述预设请求参数以及对应的参数值。
本申请提供的构建测试用例请求对象的方法、装置及系统,可以从与待测系统有业务关联关系的目标数据源中采集用例参数数据,采集得到的用例参数数据不仅可以为构建测试用例提供业务场景,还可以作为构建测试用例请求对象的基础。相对于现有技术中构建测试用例时人工搭建业务场景,本实施例在测试用例请求对象的构建过程中,从目标数据源中提取真实的业务场景,不仅可以提高构建业务场景的效率,还可以提高测试用例与真实业务场景的关联性,进而提高测试用例的质量。
如图6所示,在本申请的一个实施例中,所述装置还包括:
预期结果构建单元65,用于基于所述请求对象以及所述待测系统的预设测试字段,构建所述测试用例的预期结果数据。
将请求对象和测试字段作为所述测试用例的输入数据,并基于所述输入数据生成所述测试的预期结果数据,通过调节请求对象可以获取不同的采集数据,调节测试字段得到不同的预期结果,因此,可以建立多种可能性的测试用例,增强测试用例的适应性能。
本申请中还提供所述预期结果生成单元的一种实施方式,图7是本申请提供的预期结果构建单元的一种实施例的模块结构示意图,如图7所示,所述预期结果构建单元65可以包括:
第一测试请求发送单元71,用于向所述待测系统发出测试请求,所述测试请求中包括所述请求对象;
第一结果获取单元72,用于接收所述待测系统返回的第一测试结果数据;
第一字段值获取单元73,用于从所述第一测试结果数据中提取出所述待测系统的预设测试字段对应的第一字段值,将所述第一字段值作为所述测试用例的预期结果数据。
本实施例中,可以基于所述请求对象向待测系统发出测试请求,所述测试系统响应于所述测试请求,返回第一测试结果数据,根据待测系统的预设测试字段,从所述第一测试结果数据中裁剪出与所述预设测试字段相对应的第一字段值,并将所述第一字段值作为所述测试用例的预期结果数据。所述预设测试字段的设置与测试目标紧密联系,且所述预设测试字段可以根据需要进行变化,增强所述测试用例的多样性,提高测试用例的质量。
在本申请的一个实施例中,所述第一测试结果数据可以包括所述待测系统在基准环境中响应于所述测试请求获取的测试结果数据。将所述待测系统在所述基准环境中测试得到的数据结果数据作为第一测试结果数据,更加符合预期结果数据的生成条件。
图8是本申请提供的构建测试用例请求对象装置的另一种实施例的模块结构示意图,如图8所示,所述装置80还可以包括:
用例覆盖率获取单元81,用于根据所述第一测试结果数据,计算所述测试用例的代码覆盖率;
系统覆盖率获取单元82,用于计算所述待测系统中包含的测试用例的代码覆盖率;
用例去重单元83,用于删除所述待测系统包含的测试用例中代码覆盖率差值小于预设阈值的重复测试用例。
本实施例中,可以基于测试用例的代码覆盖率对所述测试用例进行筛选处理,去除冗余重复的测试用例,进一步提高测试用例的质量,提高测试效率。
在本申请的一个实施例中,所述用例参数数据包括下述采集方式:
在预设采集时间内按照业务参考指标从所述目标数据源中采集得到所述用例参数数据。
在本申请的一个实施例中,所述业务参考指标可以包括下述中的至少一种:业务数据访问量、业务数据评价次数、业务数据评分指数、业务数据交易完成量。
本实施例中,按照预设参数从目标数据源中采集数据,可以提高数据的采集质量。
图9是本申请提供的构建测试用例请求对象装置的另一种实施例的模块结构示意图,如图9所示,所述装置90还可以包括:
第二测试请求发送单元91,用于获取所述待测系统的关联系统,向所述关联系统发出测试请求,所述测试请求包括所述请求对象;
第二结果获取单元92,用于接收所述关联系统返回的第二测试结果数据;
第二字段值获取单元93,用于从所述第二测试结果数据中提取出所述预设测试字段对应的第二字段值,将所述第二字段值作为所述测试用例的挖掘结果数据。
本实施例中,可以基于所述待测系统的关联系统,获取所述测试用例的挖掘结果数据,将所述测试用例的挖掘结果数据与实际结果数据进行对比,通过待测系统与关联系统的测试结果数据的误差,一方面可以了解待测系统的准确性,另一方面可以为产品业务提供参考数据。
基于本申请实施例所述的构建测试用例的方法及装置,本申请还提供一种构建测试用例的系统,所述系统包括:
待测系统,用于存储目标数据源,所述目标数据源与所述待测系统具有业务关联关系;
测试平台,用于根据所述待测系统的预设请求参数从所述目标数据源中采集得到用例参数数据;还用于从所述用例参数数据中读取所述预设请求参数对应的参数值;还用于构建所述待测系统的测试用例的请求对象,所述请求对象包括所述预设请求参数以及对应的参数值。
在本申请的一个实施例中,所述测试平台还用于向所述待测系统发出测试请求,所述测试请求包括所述请求对象;还用于接收所述待测系统返回的第一测试结果数据;还用于从所述第一测试结果数据中提取出所述待测系统的预设测试字段对应的第一字段值,将所述第一字段值作为所述测试用例的预期结果数据。
在本申请的另一个实施例中,所述系统还包括:
关联系统,所述关联系统与所述待测系统具有业务关联关系;
相应地,所述测试平台还用于向所述关联系统发出测试请求,所述测试请求包括所述请求对象;还用于接收所述关联系统返回的第二测试结果数据;还用于从所述第二测试结果数据中提取出所述预设测试字段对应的第二字段值,将所述第二字段值作为所述测试用例的挖掘结果数据。
本申请提供的构建测试用例请求对象的系统,可以从与待测系统有业务关联关系的目标数据源中采集数据,采集得到的数据不仅可以为构建测试用例提供业务场景,还可以作为构建测试用例请求对象的基础。相对于现有技术中构建测试用例时人工搭建业务场景,本实施例中从目标数据源中提取真实的业务场景,不仅可以提高构建业务场景的效率,还可以提高测试用例与真实业务场景的关联性,进而提高测试用例的质量。另外,将请求对象和预设测试字段作为所述测试用例的输入数据,并基于所述输入数据生成所述测试的预期结果数据,通过调节请求对象可以获取不同的采集数据,调节所述预设测试字段得到不同的预期结果,因此,可以建立多种可能性的测试用例,增强测试用例的适应性能。
尽管本申请内容中提到实施例中的数据采集、数据提取、参考指标设置等之类的数据设置、处理描述,但是,本申请并不局限于必须是完全符合行业编程语言设计标准或实施例所描述的数据设置、处理的情况。某些页面设计语言或实施例描述的基础上略加修改后的实施方案也可以实行上述实施例相同、等同或相近、或变形后可预料的实施效果。当然,即使不采用上数据处理、判断的方式,只要符合本申请上述各实施例的数据处理、信息交互方式,仍然可以实现相同的申请,在此不再赘述。
虽然本申请提供了如实施例或流程图所述的方法操作步骤,但基于常规或者无创造性的手段可以包括更多或者更少的操作步骤。实施例中列举的步骤顺序仅仅为众多步骤执行顺序中的一种方式,不代表唯一的执行顺序。在实际中的装置或客户端产品执行时,可以按照实施例或者附图所示的方法顺序执行或者并行执行(例如并行处理器或者多线程处理的环境)。
上述实施例阐明的单元、装置、系统,具体可以由计算机芯片或实体实现,或者由具有某种功能的产品来实现。为了描述的方便,描述以上装置时以功能分为各种模块分别描述。当然,在实施本申请时可以把各模块的功能在同一个或多个软件和/或硬件中实现。当然,本申请中所述的某一单元模块也可以将实现同一功能的模块由多个子模块或子模块的组合实现。
本申请可以在由计算机执行的计算机可执行指令的一般上下文中描述,例如程序模块。一般地,程序模块包括执行特定任务或实现特定抽象数据类型的例程、程序、对象、组件、数据结构、类等等。也可以在分布式计算环境中实践本申请,在这些分布式计算环境中,由通过通信网络而被连接的远程处理设备来执行任务。在分布式计算环境中,程序模块可以位于包括存储设备在内的本地和远程计算机存储介质中。
通过以上的实施方式的描述可知,本领域的技术人员可以清楚地了解到本申请可借助软件加必需的通用硬件平台的方式来实现。基于这样的理解,本申请的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来,该计算机软件产品可以存储在存储介质中,如ROM/RAM、磁碟、光盘等,包括若干指令用以使得一台计算机设备(可以是个人计算机,移动终端,服务器,或者网络设备等)执行本申请各个实施例或者实施例的某些部分所述的方法。
本说明书中的各个实施例采用递进的方式描述,各个实施例之间相同或相似的部分互相参见即可,每个实施例重点说明的都是与其他实施例的不同之处。本申请可用于众多通用或专用的计算机系统环境或配置中。例如:个人计算机、服务器计算机、手持设备或便携式设备、平板型设备、多处理器系统、基于微处理器的系统、置顶盒、可编程的电子设备、网络PC、小型计算机、大型计算机、包括以上任何系统或设备的分布式计算环境等等。
虽然通过实施例描绘了本申请,本领域普通技术人员知道,本申请有许多变形和变化而不脱离本申请的精神,希望所附的权利要求包括这些变形和变化而不脱离本申请的精神。