一种针对银行系统的单元测试方法和相关装置与流程

1.本发明涉及数据处理技术领域，尤其是涉及一种针对银行系统的单元测试方法和相关装置。


背景技术：

2.单元测试覆盖率是对单元测试的测试完全程度的一种评价，用于描述源码中被测试的代码所占比例。单元测试是指对软件中的最小可测试单元进行检查和验证。例如，对于java程序来讲，可能由一个测试类中的某个测试函数来对某个代码块进行单元测试。
3.相关技术中，当前进行代码质量检查时，单元测试覆盖率作为代码质量的重要指标之一，通过单元测试的方式来判断每个模块当天的单元测试覆盖率是否达标，从而确定该模块的单元测试成功率。
4.但是，上述方式适用于银行系统中时，经常会出现代码质量问题发现延后、持续集成效率降低的问题。


技术实现要素：

5.针对上述问题，本技术提供一种针对银行系统的单元测试方法和相关装置，用于避免出现代码质量问题发现延后、持续集成效率降低的问题。
6.基于此，本技术实施例公开了如下技术方案：
7.一方面，本技术实施例提供一种针对银行系统的单元测试方法，银行系统包括m个模块，每个模块用于实现不同的功能，m为大于1的整数；所述方法包括：
8.获取执行单元测试的n个模块分别对应的单元覆盖率和单元测试覆盖率基线值，n为小于或等于m的正整数；
9.针对所述n个模块中的目标模块，若所述目标模块的单元覆盖率大于或等于所述目标模块的单元测试覆盖率基线值，所述目标模块的单元测试结果为成功；若所述目标模块的单元覆盖率小于所述目标模块的单元测试覆盖率基线值，所述目标模块的单元测试结果为失败；
10.获取所述n个模块的n个单元测试结果；
11.根据所述n个单元测试结果确定所述银行系统的整体测试结果。
12.可选的，所述根据所述n个单元测试结果确定所述银行系统的整体测试结果，包括：
13.若所述n个单元测试结果全部为成功，则所述银行系统的整体测试结果为成功；
14.若所述n个单元测试结果中有至少一个单元测试结果为失败，则所述银行系统的整体测试结果为失败。
15.可选的，所述单元测试覆盖率基线值为静态值或动态值。
16.可选的，若所述单元测试覆盖率基线值为动态值，获取所述单元测试覆盖率基线值，包括：
17.获取所述目标模块在第i-1次单元测试得到的历史单元测试覆盖率；
18.根据所述历史单元测试覆盖率和调节参数，确定所述目标模块在第i次单元测试所需的单元测试覆盖率基线值。
19.可选的，所述方法还包括：
20.获取一段时间内所述银行系统对应的多个整体测试结果；
21.根据所述多个整体测试结果确定所述银行系统的综合测试结果。
22.可选的，所述方法还包括：
23.获取第i-1天的整体测试结果；
24.获取第i天的整天测试结果；
25.根据所述第i-1天的整体测试结果和所述第i天的整天测试结果，确定所述银行系统在所述第i天的综合测试结果。
26.可选的，所述获取执行单元测试的n个模块分别对应的单元覆盖率，包括：
27.通过开源代码扫描平台sonarqube获取执行单元测试的n个模块分别对应的单元覆盖率。
28.另一方面，本技术提供了一种针对银行系统的单元测试装置，银行系统包括m个模块，每个模块用于实现不同的功能，m为大于1的整数；所述装置包括：第一获取单元、单元测试结果确定单元、第二获取单元和整体测试结果确定单元；
29.所述第一获取单元，用于获取执行单元测试的n个模块分别对应的单元覆盖率和单元测试覆盖率基线值，n为小于或等于m的正整数；
30.所述单元测试结果确定单元，用于针对所述n个模块中的目标模块，若所述目标模块的单元覆盖率大于或等于所述目标模块的单元测试覆盖率基线值，所述目标模块的单元测试结果为成功；若所述目标模块的单元覆盖率小于所述目标模块的单元测试覆盖率基线值，所述目标模块的单元测试结果为失败；
31.所述第二获取单元，用于获取所述n个模块的n个单元测试结果；
32.所述整体测试结果确定单元，用于根据所述n个单元测试结果确定所述银行系统的整体测试结果。
33.可选的，所述整体测试结果确定单元，具体用于：
34.若所述n个单元测试结果全部为成功，则所述银行系统的整体测试结果为成功；
35.若所述n个单元测试结果中有至少一个单元测试结果为失败，则所述银行系统的整体测试结果为失败。
36.可选的，所述单元测试覆盖率基线值为静态值或动态值。
37.可选的，若所述单元测试覆盖率基线值为动态值，所述第一获取单元，具体用于：
38.获取所述目标模块在第i-1次单元测试得到的历史单元测试覆盖率；
39.根据所述历史单元测试覆盖率和调节参数，确定所述目标模块在第i次单元测试所需的单元测试覆盖率基线值。
40.可选的，所述装置还包括综合测试结果确定单元，用于：
41.获取一段时间内所述银行系统对应的多个整体测试结果；
42.根据所述多个整体测试结果确定所述银行系统的综合测试结果。
43.可选的，所述装置还包括综合测试结果确定单元，用于：
44.获取第i-1天的整体测试结果；
45.获取第i天的整天测试结果；
46.根据所述第i-1天的整体测试结果和所述第i天的整天测试结果，确定所述银行系统在所述第i天的综合测试结果。
47.可选的，所述第一获取单元，具体用于：
48.通过开源代码扫描平台sonarqube获取执行单元测试的n个模块分别对应的单元覆盖率。
49.另一方面，本技术提供了一种计算机设备，所述设备包括处理器以及存储器：
50.所述存储器用于存储程序代码，并将所述程序代码传输给所述处理器；
51.所述处理器用于根据所述程序代码中的指令执行上述方面所述的方法。
52.另一方面，本技术提供了一种计算机可读存储介质，所述计算机可读存储介质用于存储计算机程序，所述计算机程序用于执行上述方面所述的方法。
53.另一方面，本技术实施例提供了一种计算机程序产品或计算机程序，该计算机程序产品或计算机程序包括计算机指令，该计算机指令存储在计算机可读存储介质中。计算机设备的处理器从计算机可读存储介质读取该计算机指令，处理器执行该计算机指令，使得该计算机设备执行上述方面所述的方法。
54.相对于现有技术，本技术上述技术方案的优点在于：
55.针对包括m个模块的银行系统，每个模块用于实现不同的功能，若对m个模块中的n个模块执行单元测试，获取n个模块分别对应的单元覆盖率和单元测试覆盖率基线值，以n个模块中的目标模块为例，若目标模块的单元覆盖率大于或等于所目标模块的单元测试覆盖率基线值，则目标模块的单元测试结果为成功；若目标模块的单元覆盖率小于目标模块的单元测试覆盖率基线值，则目标模块的单元测试结果为失败。由此获取n个模块分别的n个单元测试结果，根据n个单元测试结果确定银行系统的整体测试结果。由此，通过汇集银行系统中多个模块执行单元测试后的单元覆盖率，结合每个模块对应的单元测试覆盖率基线值，确定每个模块的单元测试结果，从而根据多个单元测试结果确定银行系统的整体测试结果。从银行系统的整体维度保证代码质量，提高持续集成效率。
附图说明
56.为了更清楚地说明本技术实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本技术中记载的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其它的附图。
57.图1为本技术提供的一种针对银行系统的单元测试方法的流程图；
58.图2为本技术提供的一种针对银行系统的单元测试方法的示意图；
59.图3为本技术实施例提供的一种计算机设备的结构图。
具体实施方式
60.为了使本技术领域的人员更好地理解本技术方案，下面将结合本技术实施例中的附图，对本技术实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅是本
申请一部分实施例，而不是全部的实施例。基于本技术中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本技术保护的范围。
61.随着devops的理念被广泛运用，持续集成也被越来越多的开发者所使用。开发人员通常在提交代码后，运行(或自动触发)流水线来进行构建、自动化测试、代码质量检查等。其中，单元测试覆盖率即是代码质量的重要指标之一。
62.相关技术中，当前进行代码质量检查时，单元测试覆盖率作为代码质量的重要指标之一，通过单元测试的方式来判断每个模块当天的单元测试覆盖率是否达标，从而确定该模块的单元测试成功率。
63.但是，相关技术所采用的方式只能确定单一模块(或者包括单一模块的系统)的单元测试覆盖率，而对于包含多模块的银行系统，缺少单元测试结果汇集手段，使得无法从整体确定银行系统的健康程度，从而出现代码质量问题发现延后、持续集成效率降低的问题。
64.基于此，本技术实施例提供一种针对银行系统的单元测试方法，该银行系统包括m个用于实现m个不同的功能的模块，若对m个模块中的n个模块执行单元测试，获取n个模块分别对应的单元覆盖率和单元测试覆盖率基线值，以n个模块中的目标模块为例，若目标模块的单元覆盖率大于或等于所目标模块的单元测试覆盖率基线值，则目标模块的单元测试结果为成功；若目标模块的单元覆盖率小于目标模块的单元测试覆盖率基线值，则目标模块的单元测试结果为失败。由此获取n个模块分别的n个单元测试结果，根据n个单元测试结果确定银行系统的整体测试结果。由此，通过汇集银行系统中多个模块执行单元测试后的单元覆盖率，结合每个模块对应的单元测试覆盖率基线值，确定每个模块的单元测试结果，从而结果多个单元测试结果确定银行系统的整体测试结果。从银行系统的整体维度保证代码质量，提高持续集成效率。
65.首先，对本发明实施例中涉及到的术语进行解释。
66.单元测试：unit testing，指对软件中的最小可测试单元进行检查和验证。例如，对于java程序来讲，可能由一个测试类中的某个测试函数来对某个代码块进行单元测试。
67.单元测试覆盖率：是对单元测试的测试完全程度的一种评价，用于描述源码中被测试的代码所占比例。
68.单元测试成功/失败：在对代码进行单元测试时，一般需要设定一个覆盖率基线值。达到或超过该基线值，即视为单元测试成功，否则则视为失败。除此之外，如果单元测试运行报错，同样视为单元测试失败。
69.devops：是一组过程、方法与系统的统称；是一种重视“软件开发人员(dev)”和“it运维技术人员(ops)”之间沟通合作的文化、运动或惯例。通过自动化“软件交付”和“架构变更”的流程使得构建、测试、发布软件能够更加地快捷、频繁和可靠。
70.持续集成：是一种软件开发实践，即团队开发成员经常集成他们的工作，通常每个成员每天至少集成一次，也就意味着每天可能会发生多次集成。每次集成都通过自动化的构建(包括编译，代码检查，自动化测试等)来验证，从而尽早地发现错误。
71.sonarqube：开源代码扫描平台。通过扫描源代码，生成代码质量信息，并发现源码中的缺陷。
72.下面结合图1，对本技术实施例提供的一种针对银行系统的单元测试方法进行介绍。本技术实施例所针对的银行系统包括多个(m个)模块，每个模块均能够实现不同的功
能，如用于执行登录功能的模块，用于执行存钱功能的模块等，本技术对此不做具体限定。
73.参见图1，该图为本技术提供的一种针对银行系统的单元测试方法的流程图，该方法可以包括以下步骤101-104。
74.s101：获取执行单元测试的n个模块分别对应的单元覆盖率和单元测试覆盖率基线值。
75.需要说明的是，虽然银行系统包括m个模块，但是并不是每天都对所有的模块进行单元测试，即仅针对m个模块中的n个模块进行单元测试，其中n为小于或等于m的正整数。在对某个模块执行单元测试后，会获得多个指标，如单元测试覆盖率、单元测试覆盖行数、待覆盖行数等。
76.作为一种可能的实现方式，可以通过开源代码扫描平台sonarqube获取执行单元测试的n个模块分别对应的单元覆盖率。例如，用户执行(或自动触发)构建任务(包括代码质量检查、单元测试等)后，调用sonarqube的api接口，获取单元测试得到的相关参数，存入数据库，供后续使用。
77.需要说明的是，单元测试覆盖率基线值是预先针对不同模块设置的参数，不同模块可以使用一个单元测试覆盖率基线值，也可以不同模块使用不同的单元测试覆盖率基线值，本技术对此不做具体限定，本领域技术人员可以根据实际需要进行设置。
78.s102：针对n个模块中的目标模块，若目标模块的单元覆盖率大于或等于目标模块的单元测试覆盖率基线值，目标模块的单元测试结果为成功；若目标模块的单元覆盖率小于目标模块的单元测试覆盖率基线值，目标模块的单元测试结果为失败。
79.单元测试覆盖率基线值用于衡量一个模块在本次单元测试是否通过，单元测试覆盖率达到或超出单元测试覆盖率基线值视为单元测试成功，否则视为失败。除此之外，单元测试报错也视为失败。下面以n个模块中的任意一个模块，即目标模块为例进行说明。
80.若目标模块的单元覆盖率大于或等于目标模块的单元测试覆盖率基线值，目标模块的单元测试结果为成功；若目标模块的单元覆盖率小于目标模块的单元测试覆盖率基线值，目标模块的单元测试结果为失败。
81.作为一种可能的实现方式，单元测试覆盖率基线值为静态值，即单元测试覆盖率基线值不会随着源码的实际单元测试覆盖率变动，只能通过手工修改。例如，设置单元测试覆盖率基线值为60％，即单元测试覆盖率达到或超过60％，为单元测试成功。
82.作为一种可能的实现方式，单元测试覆盖率基线值为动态值，即单元测试覆盖率基线值会随着源码的实际单元测试覆盖率变动。例如，会基于上一次单元测试覆盖率确定本次单元测试覆盖率基线值。下面继续以目标模块为例进行说明，具体如a1-a2：
83.a1：获取目标模块在第i-1次单元测试得到的历史单元测试覆盖率。
84.其中，历史单元测试覆盖率为目标模块在第i-1次单元测试得到的单元测试覆盖率。
85.a2：根据历史单元测试覆盖率和调节参数，确定目标模块在第i次单元测试所需的单元测试覆盖率基线值。
86.调节参数用于调整历史单元覆盖率，如x个百分点，则根据历史单元测试覆盖率和调节参数，确定目标模块在第i次单元测试所需的单元测试覆盖率基线值可以为不低于历史单元测试覆盖率最大值的x个百分点。
87.例如，当设置单元测试覆盖率基线值为不低于历史单元测试覆盖率最大值的1个百分点时，目标模块在执行第一次单元测试得到的单元测试覆盖率为60％，则目标模块在执行第二次单元测试的单元测试覆盖率应达到或超过59％，即视为成功。如果第二次检测，单元测试覆盖率为62％，则目标模块在执行第三次单元测试的单元测试覆盖率应达到或超过61％。
88.由于实际操作中，开发人员编写目标模块的代码和针对该代码编写测试用例后执行单元测试存在时间差，导致虽然开发人员已经完成编写目标代码的任务后，但是单元测试覆盖率没有增加，即开发人员还没有针对新增的代码编写对应的测试用例，由此，通过根据上一次单元测试得到的历史单元测试覆盖率和调节参数动态调整本次单元测试覆盖率基线值，更符合实际需要。
89.s103：获取n个模块的n个单元测试结果。
90.将n个模块中的每一个模块均作为目标模块，获取其对应的单元测试结果，可以获得n个单元测试结果。
91.s104：根据n个单元测试结果确定银行系统的整体测试结果。
92.本技术实施例不具体限定确定银行系统的整体测试结果的具体方式，只要根据执行单元测试的多个模块对应的单元测试结果确定即可。例如，若n个单元测试结果全部为成功，则银行系统的整体测试结果为成功；若n个单元测试结果中有至少一个单元测试结果为失败，则银行系统的整体测试结果为失败。
93.例如，银行系统包含三个模块，分别是a模块、b模块和c模块。某天a模块和b模块执行了单元测试，且结果都为成功，即视为该天银行系统的整体测试结果为成功；若a模块的单元测试结果为成功，b模块的单元测试结果为失败，则视为该天银行系统的整体测试结果为失败。
94.需要说明的是，如果a模块、b模块和c模块某天都没有进行单元测试，则该日不纳入统计。
95.由上述技术方案可知，针对包括m个模块的银行系统，每个模块用于实现不同的功能，若对m个模块中的n个模块执行单元测试，获取n个模块分别对应的单元覆盖率和单元测试覆盖率基线值，以n个模块中的目标模块为例，若目标模块的单元覆盖率大于或等于所目标模块的单元测试覆盖率基线值，则目标模块的单元测试结果为成功；若目标模块的单元覆盖率小于目标模块的单元测试覆盖率基线值，则目标模块的单元测试结果为失败。由此获取n个模块分别的n个单元测试结果，根据n个单元测试结果确定银行系统的整体测试结果。由此，通过汇集银行系统中多个模块执行单元测试后的单元覆盖率，结合每个模块对应的单元测试覆盖率基线值，确定每个模块的单元测试结果，从而根据多个单元测试结果确定银行系统的整体测试结果。从银行系统的整体维度保证代码质量，提高持续集成效率。
96.需要说明的是，目前单元测试覆盖率仅仅能反映当天的代码质量，无法反映长时间跨度的代码质量，使得无法从长时间跨度上衡量代码质量，开发人员缺少代码质量走势的认知。基于此，本技术实施例通过结合一段时间内，每天得到的针对银行系统的整体测试结果，确定银行测试系统的整体测试结果，下面以两种方式为例进行说明。
97.方式一：获取一段时间内银行系统对应的多个整体测试结果；根据多个整体测试结果确定银行系统的综合测试结果。
98.只获取执行单元测试的日期的整体测试结果，如果某天银行测试系统中每一个模块均没有进行单元测试，则该天不纳入统计。其中，综合测试结果用于反映银行系统在一段时间内通过单元测试得到的整体测试结果。
99.例如，统计本年度的综合测试结果，可以从每年的1月1日至当前日期，如当前日期为7月1日，则根据1月1日至7月1日得到的银行系统各天(即执行单元测试的一天)的整体测试结果，确定银行系统的整体测试结果。计算方式为：本年度当前整体测试结果为成功的总天数(简称suc)/本年度执行单元测试的总天数(简称total)。
100.方式二：获取第i-1天的整体测试结果；获取第i天的整天测试结果；根据第i-1天的整体测试结果和第i天的整天测试结果，确定银行系统在第i天的综合测试结果。
101.在计算综合测试结果时，只需要在上一天的基础上，再加上今当天的数据进行计算即可。继续以前述为例，上一天suc/total为80/100，当天单元测试结果为成功，即今天年度单元测试成功率为((81/101)*100)。
102.相比于方式一，方式二计算更加方便快捷。
103.由此，通过综合测试结果可以在一定程度反映持续集成稳定性、构建健康程度以及代码质量。使得开发人员能直观查看代码在长时间跨度下的单元测试质量走势，有助于代码质量及构建健康度的持续提升。
104.本技术实施例除了提供的针对银行系统的单元测试方法外，还提供了针对银行系统的单元测试装置，银行系统包括m个模块，每个模块用于实现不同的功能，m为大于1的整数。
105.参见图2，该图为本技术实施例提供的一种针对银行系统的单元测试装置的示意图。所述装置包括：第一获取单元201、单元测试结果确定单元202、第二获取单元203和整体测试结果确定单元204；
106.所述第一获取单元201，用于获取执行单元测试的n个模块分别对应的单元覆盖率和单元测试覆盖率基线值，n为小于或等于m的正整数；
107.所述单元测试结果确定单元202，用于针对所述n个模块中的目标模块，若所述目标模块的单元覆盖率大于或等于所述目标模块的单元测试覆盖率基线值，所述目标模块的单元测试结果为成功；若所述目标模块的单元覆盖率小于所述目标模块的单元测试覆盖率基线值，所述目标模块的单元测试结果为失败；
108.所述第二获取单元203，用于获取所述n个模块的n个单元测试结果；
109.所述整体测试结果确定单元204，用于根据所述n个单元测试结果确定所述银行系统的整体测试结果。
110.作为一种可能的实现方式，所述整体测试结果确定单元204，具体用于：
111.若所述n个单元测试结果全部为成功，则所述银行系统的整体测试结果为成功；
112.若所述n个单元测试结果中有至少一个单元测试结果为失败，则所述银行系统的整体测试结果为失败。
113.作为一种可能的实现方式，所述单元测试覆盖率基线值为静态值或动态值。
114.作为一种可能的实现方式，若所述单元测试覆盖率基线值为动态值，所述第一获取单元201，具体用于：
115.获取所述目标模块在第i-1次单元测试得到的历史单元测试覆盖率；
116.根据所述历史单元测试覆盖率和调节参数，确定所述目标模块在第i次单元测试所需的单元测试覆盖率基线值。
117.作为一种可能的实现方式，所述装置还包括综合测试结果确定单元，用于：
118.获取一段时间内所述银行系统对应的多个整体测试结果；
119.根据所述多个整体测试结果确定所述银行系统的综合测试结果。
120.作为一种可能的实现方式，所述装置还包括综合测试结果确定单元，用于：
121.获取第i-1天的整体测试结果；
122.获取第i天的整天测试结果；
123.根据所述第i-1天的整体测试结果和所述第i天的整天测试结果，确定所述银行系统在所述第i天的综合测试结果。
124.作为一种可能的实现方式，所述第一获取单元201，具体用于：
125.通过开源代码扫描平台sonarqube获取执行单元测试的n个模块分别对应的单元覆盖率。
126.由上述技术方案可知，针对包括m个模块的银行系统，每个模块用于实现不同的功能，若对m个模块中的n个模块执行单元测试，获取n个模块分别对应的单元覆盖率和单元测试覆盖率基线值，以n个模块中的目标模块为例，若目标模块的单元覆盖率大于或等于所目标模块的单元测试覆盖率基线值，则目标模块的单元测试结果为成功；若目标模块的单元覆盖率小于目标模块的单元测试覆盖率基线值，则目标模块的单元测试结果为失败。由此获取n个模块分别的n个单元测试结果，根据n个单元测试结果确定银行系统的整体测试结果。由此，通过汇集银行系统中多个模块执行单元测试后的单元覆盖率，结合每个模块对应的单元测试覆盖率基线值，确定每个模块的单元测试结果，从而根据多个单元测试结果确定银行系统的整体测试结果。从银行系统的整体维度保证代码质量，提高持续集成效率。
127.本技术实施例还提供了一种计算机设备，参见图3，该图示出了本技术实施例提供的一种计算机设备的结构图，如图3所示，所述设备包括处理器310以及存储器320：
128.所述存储器310用于存储程序代码，并将所述程序代码传输给所述处理器；
129.所述处理器320用于根据所述程序代码中的指令执行上述实施例提供的任一种针对银行系统的单元测试方法。
130.本技术实施例提供了一种计算机可读存储介质，所述计算机可读存储介质用于存储计算机程序，所述计算机程序于执行上述实施例提供的任一种针对银行系统的单元测试方法。
131.本技术实施例还提供了一种计算机程序产品或计算机程序，该计算机程序产品或计算机程序包括计算机指令，该计算机指令存储在计算机可读存储介质中。计算机设备的处理器从计算机可读存储介质读取该计算机指令，处理器执行该计算机指令，使得该计算机设备执行上述方面的各种可选实现方式中提供的针对银行系统的单元测试方法。
132.需要说明的是，本发明提供的一种针对银行系统的单元测试方法和相关装置可用于大数据领域或金融领域。上述仅为示例，并不对本发明提供的一种针对银行系统的单元测试方法和相关装置的应用领域进行限定。
133.本说明书中的各个实施例均采用递进的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。本技术在上述各
方面提供的实现方式的基础上，还可以进行进一步组合以提供更多实现方式。尤其，对于装置实施例而言，由于其基本相似于方法实施例，所以描述得比较简单，相关之处参见方法实施例的部分说明即可。以上所描述的装置实施例仅仅是示意性的，其中所述作为分离部件说明的单元及模块可以是或者也可以不是物理上分开的。另外，还可以根据实际的需要选择其中的部分或者全部单元和模块来实现本实施例方案的目的。本领域普通技术人员在不付出创造性劳动的情况下，即可以理解并实施。
134.以上所述仅是本技术的具体实施方式，应当指出，对于本技术领域的普通技术人员来说，在不脱离本技术原理的前提下，还可以做出若干改进和润饰，这些改进和润饰也应视为本技术的保护范围。