一种通过API测试覆盖度考核的方法、设备及介质与流程

一种通过api测试覆盖度考核的方法、设备及介质
技术领域
1.本技术涉及开发测试领域，具体涉及一种通过api测试覆盖度考核的方法、设备及介质。


背景技术：

2.随着企业软件越来越复杂,开发测试的工作量也越来越多,开发完成后的测试工作量以及被测服务的测试覆盖度的评估比较困难,如果在被测服务内添加分析功能的话可能会拖慢产品的速度,并且影响产品的可用性，还会并且提高产品复杂度。
3.因此，急需一种在开发完成后，能够得到测试人员对被测服务的测试覆盖度，并对测试人员进行考核的方法，提高测试人员工作的效率以及规范度。


技术实现要素：

4.为了解决上述问题，本技术提出了一种通过api测试覆盖度考核的方法、设备及介质，方法包括：
5.获取测试时间段内被测服务的流量信息，所述流量信息包括所述测试时间段内所述被测服务的访问次数、访问时间；通过分析所述流量信息，得到所述被测服务中所有应用程序接口api的测试信息，所述测试信息包括所述api的应用类型、测试时间、测试次数；根据所述测试次数，将所述所有api分为待测api与已测api；根据所述已测api的数量与所述所有api的数量确定测试覆盖度，并根据所述测试覆盖度对所述测试人员进行考核。
6.在一个示例中，获取测试时间段内被测服务的流量信息，具体包括：在超出预设百分比数量的测试人员对所述被测服务进行测试时，选取相应的测试时间段，获取所述被测服务的流量信息，并在获取所述流量信息时，不向所述测试人员发出通知。
7.在一个示例中，根据所述测试覆盖度对所述测试人员进行考核，具体包括：
8.根据所述api的所述应用类型、所述api对应的服务的关键层级、所述对应服务的使用次数，确定所述api对应的重要程度；根据所述重要程度，以及所述测试人员在测试所述api时对应的深入程度，确定所述测试人员的工作质量；根据所述测试覆盖度和所述工作质量，对所述测试人员进行考核。
9.在一个示例中，根据所述重要程度，以及所述测试人员在测试所述api时对应的深入程度，确定所述测试人员的工作质量，具体包括：根据所述重要程度，确定所述api的应测次数；将所述测试次数，作为所述测试人员在测试所述api时对应的深入程度；根据所述应测次数、所述测试次数，确定所述测试人员的工作质量。
10.在一个示例中，将所述所有api分为待测api与已测api后，所述方法还包括：对所述待测api进行标记；通知所述测试人员追踪所述标记后的待测api。
11.在一个示例中，所述方法还包括：统计所述测试人员发现的问题数量；
12.将所述问题数量与所述问题对应的api测试次数进行对比，确认所述测试人员的测试敏感度。
13.在一个示例中，将所述问题数量与所述问题对应的api测试次数进行对比，确认所述测试人员的测试敏感度，具体包括：若所述api测试次数高于第一预设阈值且所述问题数量低于第二预设阈值，则对所述被测服务进行人工审计，判断所述api对应的测试人员或开发人员是否存在问题。若所述测试人员的测试角度存在问题，向所述测试人员发送所述被测服务信息及所述人工审计结果；若所述测试人员的测试角度不存在问题，则认为开发人员的开发质量达到预设标准。
14.在一个示例中，所述方法还包括：获取客户端api的测试信息，根据所述测试信息将所述api分为常用api和不常用api；将所述常用api的测试信息传输至服务端，作为所述常用api的重要程度，参与计算所述常用api的重要等级；通过所述客户端获取所述被测服务的反馈问题，根据所述反馈问题判断所述测试人员的工作质量。
15.本技术还公开了一种判断测试覆盖度的设备，其特征在于，包括：
16.至少一个处理器；以及，与所述至少一个处理器通信连接的存储器；其中，
17.所述存储器存储有可被所述至少一个处理器执行的指令，所述指令被所述至少一个处理器执行，以使所述至少一个处理器能够执行：
18.获取测试时间段内被测服务的流量信息，所述流量信息包括所述测试时间段内所述被测服务的访问次数、访问时间；通过分析所述流量信息，得到所述被测服务中所有应用程序接口api的测试信息，所述测试信息包括所述api的应用类型、测试时间、测试次数；根据所述测试次数，将所述所有api分为待测api与已测api；根据所述已测api的数量与所述所有api的数量确定测试覆盖度，并根据所述测试覆盖度对所述测试人员进行考核。
19.本技术还公开了一种非易失性计算机存储介质，存储有计算机可执行指令，其特征在于，所述计算机可执行指令设置为：
20.获取测试时间段内被测服务的流量信息，所述流量信息包括所述测试时间段内所述被测服务的访问次数、访问时间；通过分析所述流量信息，得到所述被测服务中所有应用程序接口api的测试信息，所述测试信息包括所述api的应用类型、测试时间、测试次数；根据所述测试次数，将所述所有api分为待测api与已测api；根据所述已测api的数量与所述所有api的数量确定测试覆盖度，并根据所述测试覆盖度对所述测试人员进行考核。
21.本技术从网络层出发,通过在应用服务器前添加设备,能够记录并且分析进入应用服务器的请求,再根据时间粒度对请求进行区分,获取各类api的调用次数,以及获取客户端的调用次数，自动得出被测服务中测试api的覆盖率以及测试人员的工作质量评分，以使测评工作能够更有效率地进行。
附图说明
22.此处所说明的附图用来提供对本技术的进一步理解，构成本技术的一部分，本技术的示意性实施例及其说明用于解释本技术，并不构成对本技术的不当限定。在附图中：
23.图1为本技术实施例中一种通过api测试覆盖度考核的方法示意图；
24.图2为本技术实施例中一种通过api测试覆盖度考核的设备示意图。
具体实施方式
25.为使本技术的目的、技术方案和优点更加清楚，下面将结合本技术具体实施例及
相应的附图对本技术技术方案进行清楚、完整地描述。显然，所描述的实施例仅是本技术一部分实施例，而不是全部的实施例。基于本技术中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本技术保护的范围。
26.以下结合附图，详细说明本技术各实施例提供的技术方案。
27.如图1所示，本技术实施例提供一种通过api测试覆盖度考核的方法，包括：
28.s101，获取测试时间段内被测服务的流量信息，所述流量信息包括所述测试时间段内所述被测服务的访问次数、访问时间。
29.在应用服务器与客户端的网络中间部署一套设备，用于获取客户端与服务端的流量信息，这里可以使用nginx服务器，也可以使用防火墙或者是其他带日志分析的工具。这里的流量信息至少要包括这一段时间内被测服务的访问次数以及访问时间。
30.s102，通过分析所述流量信息，得到所述被测服务中所有应用程序接口api的测试信息，所述测试信息包括所述api的应用类型、测试时间、测试次数。
31.在获取被测服务的流量信息后，通过分析流量信息，得到其中包含的各个api的测试信息，例如api的应用类型、测试时间，测试次数。
32.s103，根据所述测试次数，将所述所有api分为待测api与已测api；
33.再根据各个api的测试信息中包含的测试次数，将api分为待测api和已测api，例如，划分规则可以是只要测试次数不是0的api都叫已测api；也可以根据api测试信息中包含的测试时间对api的种类进行划分，划分规则可以是特定时间段内测试次数是否超过预设阈值。例如一天内测试了一次，可以被认为是已测api，也可以是三天之内测试了五次，认为该api是已测api。
34.s104，根据所述已测api的数量与所述所有api的数量确定测试覆盖度，并根据所述测试覆盖度对所述测试人员进行考核。
35.划分api种类之后，确定已测api和所有api的数量，再通过已测api的数量和所有api的数量，可以得到测试人员对被测服务的测试覆盖度。
36.在一个实施例中，获取测试时间段内被测服务的流量信息时，如果正在工作的测试人员太少，会造成抓取的流量信息过少，进一步导致在进行测评时，可用信息太少，可能导致测评结果不准确或实用性较低。基于此，可以在特定的测试时间段内获取被测服务的流量信息，要求该测试时间段内，正在工作的测试人员较多。比如，测试时间可以是当百分之九十以上的测试人员正在对被测服务进行测试的时间段。
37.进一步地，由于测评结果会反应测试人员的工作质量问题，如果测试人员为了得到较好的工作质量评价，有可能会在测试时间段内故意多进行测试，从而提高自己的工作评价。为避免这种情况出现，可以不将测试时间告诉相关测试人员，或是随机抽取时间进行测试，避免出现与测试人员正常工作时的流量失真现象，提高测评结果的准确性以及权威性。
38.在一个实施例中，由于企业软件中存在大量的服务功能，比如记账、签到、登陆等功能。但是有些功能并不是太重要，我们希望把精力投放到更重要的服务功能中，从而在减轻工作量的同时，提高工作效率。基于此，我们可以根据api的应用类型、api对应服务的关键层级、对应服务的使用次数，来确定各个api的重要程度。按照通过预设的需求对流量信息进行过滤和筛选，将一些不符合预设需求的流量信息筛去，这里的需求可以是服务功能
的重要度，比如可能记账的重要程度就会比日志的重要程度更高一些；也可以是别的需求，比如挑选客户使用比较多的服务功能，以减轻分析流量信息时的工作量。确定各个api的重要程度后，根据重要程度以及测试人员在测试各个api时对应的深入程度，确定测试人员的工作质量。
39.进一步地，根据重要程度以及测试人员在测试各个api时对应的深入程度，确定测试人员的工作质量具体包括：根据api对应的重要程度，确定各个api的应测次数，再将api的测试次数也就是实测次数作为测试人员在测试api时的深入程度，并根据应测次数以及实测次数，确定测试人员的工作质量。
40.重要程度设定参数可以包括api的使用次数、使用频率等。我们希望越重要的服务功能，测试的程度也要更深，以防止重要的服务功能出现漏洞等现象。可以通过扫描工具分析被测服务中关键api的测试深入程度，不同的重要等级，对应的测试深入程度的最低阈值不同，如果发现api的测试深入程度低于最低阈值，可以通过系统向该api的测试人员发送邮件通知，以使测试人员能够根据服务功能的不同重要程度，对各个服务功能进行不同的深入测试。
41.在一个实施例中，由于某些服务功能内含的数据量较大，可能需要进行实时更新、维护，这种服务功能的测试工作无疑会非常繁重，但又必须进行，此时我们在进行测试工作时，为了保证该服务功能的运行，需要提高测试频率，防止服务功能出现漏洞。基于此，可以根据时间粒度对被测服务进行划分，时间粒度可以是每时、每天、每周、每月等，将被测服务划分为需要每天检测、每周检测的服务类型，由于流量信息中包含了被测服务的测试时间，我们可以在获取流量信息后，根据流量信息对被测服务的检测时间进行判断，是否满足划分的类别。若不满足，比如，需要每天检测的服务功能已经三天没有检测过了，此时可以通过系统对测试人员进行邮件通知，以使需要频繁检测的服务功能的检测工作得到落实。
42.在一个实施例中，由于测试人员在对被测服务进行测试工作时，很难对所有的api都进行及时、深入的测试。但是没有被测试到的api如果放任不管的话，又有可能会存在漏洞。为防止这种情况的发生，可以在将api分为待测api和已测api之后，对待测api进行标记，并在系统中通知测试人员追踪标记后的待测api，从而尽量使得所有的api都能得到检测，增加评测任务的准确性以及全面性。
43.在一个实施例中，由于测试人员可能会受到经验、想法的限制，不能从多个方面对被测服务中的各个api进行检测，为了确认测试人员的测试敏感度，以及确认对应开发人员的开发质量，可以统计测试人员发现的问题数量，并将问题数量与这个问题对应的api测试次数进行对比，以此确认测试人员的测试敏感度。
44.进一步地，如果api的测试次数很高，而且测试人员发现问题的数量却很低的话，可以对该服务功能进行人工审计，判断是该服务功能的开发人员的开发质量好，还是该服务功能存在问题，但是由于测试人员的测试敏感度不够，导致多次测试api，但并不能发现问题所在。此数据可以作为评价开发交付物质量的一个数据来源。
45.进一步地，如果问题出于测试人员的测试敏感度不够，导致不能测试出问题，通过系统对测试人员发送该被测服务的信息以及人工审计结果，使得测试人员能够对自己的工作内容进行总结反思，从而提升测试任务以及评测任务的效率以及准确性。
46.在一个实施例中，由于服务功能的好坏还需要使用者进行评价，因此不能全靠开
发人员以及部门经理的经验进行判断，为了了解使用者的评价以及使用意愿，从而对服务功能进一步改善，还可以通过获取客户端api的测试信息，测试信息包括api的调用频率以及使用次数、使用时间等信息。根据测试信息将客户端的api分为常用api和不常用api，将客户端常用api的测试信息传输至服务端，并作为衡量一个api重要程度的其中一个参数，参与计算该常用api的重要等级。通过客户端获取被测服务的反馈问题，也可以用来判断测试人员的工作质量，还可以反馈给后台一编有侧重的进行产品质量的开发与测试保证，也可以作为评价开发人员与测试人员工作绩效的标准。通过对客户现场api的调用频率与公司内部的调用频率进行交叉对比，也能改善测试工作的重心，着重保证测试经常使用的功能正确性。
47.如图2所示，本技术实施例还提供了一种通过api测试覆盖度考核的设备，包括：
48.至少一个处理器；以及，
49.与所述至少一个处理器通信连接的存储器；其中，
50.所述存储器存储有可被所述至少一个处理器执行的指令，所述指令被所述至少一个处理器执行，以使所述至少一个处理器能够：
51.获取测试时间段内被测服务的流量信息，所述流量信息包括所述测试时间段内所述被测服务的访问次数、访问时间；
52.通过分析所述流量信息，得到所述被测服务中所有应用程序接口api的测试信息，所述测试信息包括所述api的应用类型、测试时间、测试次数；
53.根据所述测试次数，将所述所有api分为待测api与已测api；
54.根据所述已测api的数量与所述所有api的数量确定测试覆盖度，并根据所述测试覆盖度对所述测试人员进行考核。
55.本技术实施例还提供了一种非易失性计算机存储介质，存储有计算机可执行指令，所述计算机可执行指令设置为：
56.获取测试时间段内被测服务的流量信息，所述流量信息包括所述测试时间段内所述被测服务的访问次数、访问时间；
57.通过分析所述流量信息，得到所述被测服务中所有应用程序接口api的测试信息，所述测试信息包括所述api的应用类型、测试时间、测试次数；
58.根据所述测试次数，将所述所有api分为待测api与已测api；
59.根据所述已测api的数量与所述所有api的数量确定测试覆盖度，并根据所述测试覆盖度对所述测试人员进行考核。
60.本技术中的各个实施例均采用递进的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于设备和介质实施例而言，由于其基本相似于方法实施例，所以描述的比较简单，相关之处参见方法实施例的部分说明即可。
61.本技术实施例提供的设备和介质与方法是一一对应的，因此，设备和介质也具有与其对应的方法类似的有益技术效果，由于上面已经对方法的有益技术效果进行了详细说明，因此，这里不再赘述设备和介质的有益技术效果。
62.本领域内的技术人员应明白，本技术的实施例可提供为方法、系统、或计算机程序产品。因此，本技术可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实
施例的形式。而且，本技术可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、cd
‑
rom、光学存储器等)上实施的计算机程序产品的形式。
63.本技术是参照根据本技术实施例的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。
64.这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。
65.这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。
66.在一个典型的配置中，计算设备包括一个或多个处理器(cpu)、输入/输出接口、网络接口和内存。
67.内存可能包括计算机可读介质中的非永久性存储器，随机存取存储器(ram)和/或非易失性内存等形式，如只读存储器(rom)或闪存(flash ram)。内存是计算机可读介质的示例。
68.计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括，但不限于相变内存(pram)、静态随机存取存储器(sram)、动态随机存取存储器(dram)、其他类型的随机存取存储器(ram)、只读存储器(rom)、电可擦除可编程只读存储器(eeprom)、快闪记忆体或其他内存技术、只读光盘只读存储器(cd
‑
rom)、数字多功能光盘(dvd)或其他光学存储、磁盒式磁带，磁带磁磁盘存储或其他磁性存储设备或任何其他非传输介质，可用于存储可以被计算设备访问的信息。按照本文中的界定，计算机可读介质不包括暂存电脑可读媒体(transitory media)，如调制的数据信号和载波。
69.还需要说明的是，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、商品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、商品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个
……”
限定的要素，并不排除在包括所述要素的过程、方法、商品或者设备中还存在另外的相同要素。
70.以上所述仅为本技术的实施例而已，并不用于限制本技术。对于本领域技术人员来说，本技术可以有各种更改和变化。凡在本技术的精神和原理之内所作的任何修改、等同替换、改进等，均应包含在本技术的权利要求范围之内。