一种覆盖测试方法、系统、存储介质及计算设备与流程

1.本发明涉及程序测试技术领域，特别是一种覆盖测试方法、系统、存储介质及计算设备。


背景技术：

2.代码覆盖(code coverage)是软件测试中的一种度量，描述程式中源代码被测试的比例和程度，所得比例称为代码覆盖率。在做单元测试时，代码覆盖率常常被拿来作为衡量测试好坏的指标，甚至用代码覆盖率来考核测试任务完成情况，这类测试通常有5个级别，最完善的就是全覆盖测试，现有的技术方案中比较有名的就是gcc编译器中的代码覆盖工具gcov和lcov，主要是c 提代的覆盖测试和检查工具，有些主流语言也提供了覆盖测试的工具，会按指定的规范来实现。
3.现有技术中，覆盖测试是一种比较小众的测试方法,虽然大部分时间己经沦为一种单元测试的评价方式，有些单元测试工具甚至集成了覆盖测试工具，会显示出单元测试的代码覆盖率，这是覆盖测试的主要应用，即单元测试的一种评价方法，通常覆盖75％-90％左右比较好。因为单元测试针对开发者，所以目前通常是一种开发者使用的测试评价手段，为了让单元测试可以覆盖更多的代码，开发者要额外做很多的工作，在游戏这种大规模、迭代快、多版本的复杂项目中，前端和后端工程师要使用多种语言，单元测试不太可能做到，按规范的覆盖测试会更麻烦。另外，单独使用覆盖测试工具，一般都建立在gcov、lcov的规范上开发，比较复杂，因为其本身也是一个性能测试工具，有一些特殊的定义，在脚本语言(如lua)上的使用和开发上不太友好,效率也不高。由于覆盖测试工具要求要在目标函数上打点(即在开始和结束时插入代码)，或是某个时间阶段内记录全部的代码，生成出来的内容也都是代码，普通测试人员难以使用这类工具，开发者使用这类工具会降低开发效率。


技术实现要素：

4.鉴于上述问题，提出了本发明以便提供一种克服上述问题或者至少部分地解决上述问题的覆盖测试方法、系统、存储介质及计算设备，能够让覆盖测试变为需求和测试主导，而技术辅助的方式，可得到测试某种需求下的全部或大部份代码的执行逻辑。
5.根据本发明实施例的一方面，提供了一种覆盖测试方法，包括：
6.响应于代码版本控制系统接收到至少一个新版本文件的提交请求，比较所述新版本文件与相同文件名的上一版本文件，将比较后的新版本文件的修改代码行信息、文件名和对应需求标识记录至版本覆盖记录文件；
7.对被测程序启动覆盖测试过程，监控覆盖测试过程中执行的新版本文件的代码行的行号信息并记录至新版本文件对应的覆盖测试记录文件中；
8.若测试结果参数包含指定需求，依据所述版本覆盖记录文件内容统计所述指定需求的代码总行数，依据所述覆盖测试记录文件内容统计指定需求的代码执行行数，通过所
述代码执行行数除以所述代码总行数得到指定需求的测试覆盖度。
9.可选地，通过所述代码执行行数除以所述代码总行数得到指定需求的测试覆盖度之前，还包括：从所述版本覆盖记录文件中读取所述指定需求对应的代码行，将读取出的所述指定需求对应的代码行写入超文本文件，一个指定需求对应写入一个超文本文件；若从所述覆盖测试记录文件中查找到与写入超文本文件的指定需求对应代码行相同的行号信息，对写入超文本文件的代码行标记覆盖标识；
10.通过所述代码执行行数除以所述代码总行数得到指定需求的测试覆盖度之后，还包括：基于所述指定需求的测试覆盖度、包含指定需求对应代码行的超文本文件生成所述指定需求对应的脚本文件，其中，一个指定需求对应生成一个脚本文件。
11.可选地，监控覆盖测试过程中执行的新版本文件的代码行的行号信息并记录至新版本文件对应的覆盖测试记录文件中之后，还包括：
12.若所述测试结果参数未包含指定需求，依据所述覆盖测试记录文件内容统计执行的各新版本文件的代码执行行数，通过任一新版本文件的代码执行行数除以所述任一新版本文件的代码总行数得到所述任一新版本文件的测试覆盖度；
13.依据执行的所有新版本文件的代码执行行数除以所述所有新版本文件的代码总行数得到所述被测程序的总测试覆盖度。
14.可选地，依据执行的所有新版本文件的代码执行行数除以所述所有新版本文件的代码总行数得到所述被测程序的总测试覆盖度之前，还包括：将所述新版本文件的文件路径记录至所述覆盖测试记录文件中；依据所述覆盖测试记录文件中的新版本文件路径查找对应的新版本文件，将查找到的新版本文件的代码行写入超文本文件，一个新版本文件对应写入一个超文本文件；若从所述覆盖测试记录文件中查找到与写入超文本文件的新版本文件对应代码行相同的行号信息，对写入超文本文件的代码行标记覆盖标识；
15.依据执行的所有新版本文件的代码执行行数除以所述所有新版本文件的代码总行数得到所述被测程序的总测试覆盖度之后，还包括：基于任一新版本文件的测试覆盖度、包含所述任一新版本文件代码行的超文本文件生成所述任一新版本文件对应的脚本文件，其中，一个新版本文件对应生成一个脚本文件。
16.可选地，所述方法还包括：
17.将不同新版本文件对应的脚本文件以目录结构形式写入第一目录，将不同需求对应的脚本文件写入第二目录；
18.为所述第一目录的脚本文件和第二目录的脚本文件生成同一索引文件。
19.可选地，比较所述新版本文件与相同文件名的上一版本文件之前，还包括：
20.判断所述新版本文件是否包含符合预设规范的需求标识；
21.若不包含符合预设规范的需求标识，拒绝接收至少一个所述新版本文件的提交请求；
22.若包含符合预设规范的需求标识，且接收到相同文件名的新版本文件的多个提交请求，分析所述多个提交请求分别包含的新版本文件是否存在冲突；
23.若存在冲突，拒绝接收至少一个所述新版本文件的多个提交请求；
24.其中，不存在冲突时可进入比较所述新版本文件与相同文件名的上一版本文件的过程。
25.可选地，将比较后的新版本文件的修改代码行信息、文件名和对应需求标识记录至版本覆盖记录文件之后，还包括：
26.若一个新版本文件的文件名对应多个需求，且针对所述多个需求中的任一需求修改了代码行，分析所述修改代码行信息是否影响所述新版本文件对应的其他需求相关的代码行信息；
27.若是，将所述版本覆盖记录文件中已经记录的所述其他需求相关的代码行信息进行相应修改。
28.可选地，若预先配置对新版本文件的文件路径、执行代码行的执行次数的监控，监控覆盖测试过程中执行的新版本文件的代码行的行号信息并记录至新版本文件对应的覆盖测试记录文件中，包括：
29.启动监控覆盖测试过程，通过预置在被测程序中的钩子程序从被测程序中调取文件路径、执行代码行的执行次数及行号信息，并以哈希映射的结构形式保存至内存；
30.将内存中的文件路径、执行代码行的执行次数及行号信息写入所述覆盖测试记录文件。
31.可选地，将内存中的文件路径、执行代码行的执行次数及行号信息写入所述覆盖测试记录文件，包括：
32.按照预设钩子参数将内存中的文件路径、执行代码行的执行次数及行号信息写入所述覆盖测试记录文件；
33.其中，所述预设钩子参数包含向所述覆盖测试记录文件写入文件路径、执行代码行的执行次数及行号信息的时间间隔、需要过滤的文件信息、是否读取覆盖测试记录文件之前记录信息中的至少一项。
34.可选地，若所述钩子参数包含读取覆盖测试记录文件之前记录信息的参数，将内存中的文件路径、执行代码行的执行次数及行号信息写入所述覆盖测试记录文件之后，还包括：
35.响应于对被测程序覆盖测试的重启指令，从所述覆盖测试记录文件中获取最近一次记录的文件路径、执行代码行的执行次数及行号信息；
36.将获取到的重新文件路径、执行代码行的执行次数及行号信息重新写入内存。
37.根据本发明实施例的另一方面，还提供了一种覆盖测试系统，包括：
38.比较单元，适于响应于代码版本控制系统接收到至少一个新版本文件的提交请求，比较所述新版本文件与相同文件名的上一版本文件，将比较后的新版本文件的修改代码行信息、文件名和对应需求标识记录至版本覆盖记录文件；
39.测试单元，适于对被测程序启动覆盖测试过程，监控覆盖测试过程中执行的新版本文件的代码行的行号信息并记录至新版本文件对应的覆盖测试记录文件中；
40.统计单元，适于若测试结果参数包含指定需求，依据所述版本覆盖记录文件内容统计所述指定需求的代码总行数，依据所述覆盖测试记录文件内容统计指定需求的代码执行行数，通过所述代码执行行数除以所述代码总行数得到指定需求的测试覆盖度。
41.根据本发明实施例的另一方面，还提供了一种计算机存储介质，所述计算机存储介质存储有计算机程序代码，当所述计算机程序代码在计算设备上运行时，导致所述计算设备执行上文任意实施例的覆盖测试方法。
42.根据本发明实施例的另一方面，还提供了一种计算设备，包括：处理器；存储有计算机程序代码的存储器；当所述计算机程序代码被所述处理器运行时，导致所述计算设备执行上文任意实施例的覆盖测试方法。
43.本发明实施例通过在向代码控制系统提交新版本文件的过程中比较新旧版本文件的差别，并将比较后的新版本文件的修改代码行信息、文件名和对应需求标识记录至版本覆盖记录文件，从而后续在针对需求的覆盖率测试过程中可对相应代码行的执行过程进行准确地记录和统计，以提高覆盖测试的准确度和覆盖率。而且，本发明实施例通过监控覆盖测试过程并将监控到的代码执行相关信息记录至新版本文件对应的覆盖测试记录文件中，从而可以依据覆盖测试记录文件中的指定需求的相关内容计算得到指定需求的测试覆盖率。本发明实施例的覆盖测试方式无需开发人员在开发过程中做过多的操作，便可以实现以需求和测试为主导，而技术辅助的覆盖测试过程，能够将需求、文件版本、开发、测试及需求测试覆盖度统一结合，可以方便的判断出测试过程是否测试了指定需求下的全部或大部份代码逻辑，本发明实施例能够有效地提高覆盖测试的准确度和覆盖率，进而也有助于提高代码开发效率和代码稳定性。
44.上述说明仅是本发明技术方案的概述，为了能够更清楚了解本发明的技术手段，而可依照说明书的内容予以实施，并且为了让本发明的上述和其它目的、特征和优点能够更明显易懂，以下特举本发明的具体实施方式。
45.根据下文结合附图对本发明具体实施例的详细描述，本领域技术人员将会更加明了本发明的上述以及其他目的、优点和特征。
附图说明
46.此处所说明的附图用来提供对本发明的进一步理解，构成本发明的一部分，本发明的示意性实施例及其说明用于解释本发明，并不构成对本发明的不当限定。在附图中：
47.图1示出了根据本发明一实施例的覆盖测试方法流程示意图；
48.图2示出了根据本发明一实施例的覆盖测试系统结构示意图；
49.图3示出了根据本发明另一实施例的覆盖测试系统结构示意图；
50.图4示出了根据本发明再一实施例的覆盖测试系统结构示意图；
51.图5示出了根据本发明又一实施例的覆盖测试系统结构示意图；
52.图6示出了根据本发明又一实施例的覆盖测试系统结构示意图。
具体实施方式
53.下面将参照附图更详细地描述本发明的示例性实施例。虽然附图中显示了本发明的示例性实施例，然而应当理解，可以以各种形式实现本发明而不应被这里阐述的实施例所限制。相反，提供这些实施例是为了能够更透彻地理解本发明，并且能够将本发明的范围完整的传达给本领域的技术人员。
54.为解决上述技术问题，本发明实施例提供了一种覆盖测试方法，图1示出了根据本发明一实施例的覆盖测试方法流程示意图。参见图1，覆盖测试方法包含步骤s102至步骤s106。
55.步骤s102，响应于代码版本控制系统接收到至少一个新版本文件的提交请求，比
较新版本文件与相同文件名的上一版本文件，将比较后的新版本文件的修改代码行信息、文件名和对应需求标识记录至版本覆盖记录文件。
56.步骤s104，对被测程序启动覆盖测试过程，监控覆盖测试过程中执行的新版本文件的代码行的行号信息并记录至新版本文件对应的覆盖测试记录文件中。
57.该实施例中，在执行覆盖测试之前，还会根据覆盖测试需求编写测试用例，进而利用编写的测试用例对被测程序进行覆盖测试。
58.步骤s106，若测试结果参数包含指定需求，依据版本覆盖记录文件内容统计指定需求的代码总行数，依据覆盖测试记录文件内容统计指定需求的代码执行行数，通过代码执行行数除以代码总行数得到指定需求的测试覆盖度。
59.本发明实施例通过在向代码控制系统提交新版本文件的过程中比较新旧版本文件的差别，并将比较后的新版本文件的修改代码行信息、文件名和对应需求标识记录至版本覆盖记录文件，从而后续在针对需求的覆盖率测试过程中可对相应代码行的执行过程进行准确地记录和统计，以提高覆盖测试的准确度和覆盖率。而且，本发明实施例通过监控覆盖测试过程并将监控到的代码执行相关信息记录至新版本文件对应的覆盖测试记录文件中，从而可以依据覆盖测试记录文件中的指定需求的相关内容计算得到指定需求的测试覆盖率。本发明实施例的覆盖测试方式无需开发人员在开发过程中做过多的操作，便可以实现以需求和测试为主导，而技术辅助的覆盖测试过程，能够将需求、文件版本、开发、测试及需求测试覆盖度统一结合，可以方便的判断出测试过程是否测试了指定需求下的全部或大部份代码逻辑，本发明实施例能够有效地提高覆盖测试的准确度和覆盖率，进而也有助于提高代码开发效率和代码稳定性。
60.本发明实施例可以应用于在游戏代码版本更新后的覆盖测试过程，在游戏这种大规模、迭代快、多版本的复杂项目中，前端工程师和后端工程师会使用到多种语言，采用本发明实施例实现以需求和测试为主导，而技术辅助的覆盖测试过程，无需开发人员在开发过程中做过多的操作，也可以准确地实现对被测程序的覆盖测试过程。
61.在本发明一实施例中，还可以从版本覆盖记录文件中读取指定需求对应的代码行，将读取出的指定需求对应的代码行写入超文本文件(html文件)，一个指定需求对应写入一个超文本文件。若从覆盖测试记录文件中查找到与写入超文本文件的指定需求对应代码行相同的行号信息，对写入超文本文件的代码行标记覆盖标识。进而，可以基于上文计算得到的指定需求的测试覆盖度、包含指定需求对应代码行的超文本文件生成指定需求对应的脚本文件，该实施例的一个指定需求对应生成一个脚本文件。
62.在本发明实施例中，读取指定需求对应的代码行时，可以依据指定需求的需求编号在版本覆盖记录文件中查找对应的文件名称，然后从相应的文件中查找与指定需求相关的代码行。在将一个指定需求写入一个html文件的过程中，先写入html头部和层叠样式表(cascading style sheets，css)信息，然后再使用定义好的css格式将指定需求相关的代码行以行为单位写入html文件，写入过程中，若判断出覆盖测试记录文件中记录有写入代码行的行号，可以将写入代码行加背景颜色以标记覆盖标识，并且，还可以向html文件中写入对应代码行的行号和执行的次数。当然，还可以采用其他方式对代码行标记覆盖标识，本发明实施例对此不作限定。
63.进而，本发明实施例利用生成的指定需求对应的脚本文件可以清楚地对需求的覆
盖测试结果进行可视化展示，以方便测试人员和开发人员了解覆盖测试的结果和出现的问题。
64.上文实施例介绍了测试得到指定需求的测试覆盖度的过程，本发明实施例还可以对文件的测试覆盖度和被测程序的总测试覆盖度进行测试。
65.该实施例中，若测试结果参数未包含指定需求，依据覆盖测试记录文件内容统计执行的各新版本文件的代码执行行数，通过任一新版本文件的代码执行行数除以任一新版本文件的代码总行数得到任一新版本文件的测试覆盖度。进而，依据执行的所有新版本文件的代码执行行数除以所有新版本文件的代码总行数得到被测程序的总测试覆盖度。由此，本发明实施例既可以测试得到每个文件的测试覆盖度，也可以测试得到被测程序的总的测试覆盖度，以从多个方面展示测试结果。
66.在一可选实施例中，还可以将新版本文件的文件路径记录至覆盖测试记录文件中，依据覆盖测试记录文件中的新版本文件路径查找对应的新版本文件，将查找到的新版本文件的代码行写入超文本文件，一个新版本文件对应写入一个超文本文件。若从覆盖测试记录文件中查找到与写入超文本文件的新版本文件对应代码行相同的行号信息，对写入超文本文件的代码行标记覆盖标识。进而，可以基于任一新版本文件的测试覆盖度、包含任一新版本文件代码行的超文本文件生成任一新版本文件对应的脚本文件，该实施例的一个新版本文件对应生成一个脚本文件。
67.本发明实施例中，通过遍历覆盖测试记录文件，可以依据覆盖测试记录文件中记录的新版本文件路径path/filename查找对应的新版本文件，将查找到的新版本文件中的代码行以行为单位写入html文件，并且先写入html头部和css信息，再使用定义好的css格式将新版本文件的代码行以行为单位写入html文件，写入过程中，若判断覆盖测试记录文件中记录有写入代码行的行号，可以将写入代码行加背景颜色以标记覆盖标识。该实施例在将新版本文件中的代码行写入html文件过程中，还可以向html文件写入对应代码行的行号和执行的次数。当然，也可以采用其他方式对代码行标记覆盖标识，本发明实施例对此不作限定。
68.由于本发明实施例通过遍历覆盖测试记录文件中的文件路径来查找相应的新版本文件，并将新版本文件的代码行写入html文件，由此生成的脚本文件中包含覆盖测试记录信息，若查找的是指定需求的对应的新版本文件，那么脚本文件中包含指定需求的需求编号和对应的代码行，若不指定需求，则脚本文件中包含依据文件路径查找到的全部代码行的信息。
69.进而，本发明实施例通过生成的新版本文件对应的脚本文件可以清楚地对新版本文件的覆盖测试结果进行可视化展示，以方便测试人员和开发人员了解覆盖测试的结果和出现的问题。
70.在本发明一实施例中，在生成新版本文件对应的脚本文件和需求对应的脚本文件之后，还可以将不同新版本文件对应的脚本文件以目录结构形式写入第一目录，将不同需求对应的脚本文件写入第二目录。然后为第一目录的脚本文件和第二目录的脚本文件生成同一索引文件(index文件)。通过索引文件可以方便的从对应目录中查找到基于需求的测试结果和文件覆盖测试结果。本发明实施例还可以为每个新版本文件添加指向对应脚本文件的链接标签link，通过链接标签link可以方便的查找到生成的脚本文件。本发明实施例
还可以将脚本文件放入需求任务管理工具，从而可以对覆盖测试的结果进行有效地记录和清楚的显示。
71.本发明实施例中，在需求任务管理工具中可以为索引文件设置一个对应的策略模块，该策略模块可以根据索引文件的索引结果生成不同的需求任务。例如测试人员通过索引文件索引得到指定需求对应的脚本文件后，与索引文件对应的策略模块会依据索引出的指定需求的脚本文件生成指定需求任务，通过需求任务管理工具不仅可以显示指定需求的覆盖测试结果，还可以显示出生成的指定需求任务，方便测试人员或开发人员可以依据测试结果对相应的代码进行修改完善。
72.参见上文步骤s102，本发明实施例的代码版本控制系统可用于多个开发人员共同开发同一个项目(如一个游戏项目)，能够实现不同版本代码文件的共享资源以及对不同版本代码文件的集中式管理。例如，开发人员的计算机中存储游戏开发版本的文件，当开发人员修改代码进行版本更新后，可以将新版本文件上传至代码版本控制系统的版本库中，从而可以从版本库中获取新版本文件和相同文件名的上一版本文件并进行比较，通过比较两个版本文件的差异，可以得到新版本文件修改代码行的位置信息、内容信息等等。
73.在该实施例中，由于每个代码文件通常会对应一个或多个项目需求，每个项目需求都会有一个唯一需求标识(如需求编号)，因此开发人员在向代码版本控制系统提交新版本文件时，通常会在注释comment信息中填入本次提交新版本文件所涉及的需求编号，当然每次提交新版本文件都针对一项需求。
74.本发明实施例在将比较后的新版本文件的修改代码行信息、文件名和对应需求标识记录至版本覆盖记录文件时，可以依据新版本文件提交时触发的脚本文件对修改代码行信息、文件名和需求标识进行版本覆盖记录实现代码版本控制脚本。
75.在本发明一实施例中，在比较新版本文件与相同文件名的上一版本文件之前，还可以判断新版本文件中是否注释有需求且需求是否符合规范，并且，对于接收多方提交请求的情况，还会分析多方提交的新版本文件是否存在冲突。
76.具体的，判断新版本文件是否包含符合预设规范的需求标识，若不包含符合预设规范的需求标识，拒绝接收至少一个新版本文件的提交请求。例如，预设规范可以是代码第一行的开始部份是需求的数字编号加空格，若判断出新版本文件中代码的第一行没有数字编号加空格，则新版本文件无法提交。
77.若判断出新版本文件包含符合预设规范的需求标识，进一步判断是否接收到相同文件名的新版本文件的多个提交请求，若接收到多个提交请求，还会分析多个提交请求分别包含的新版本文件是否存在冲突，如果存在冲突，拒绝接收至少一个新版本文件的多个提交请求，如果不存在冲突，则可以进入比较新版本文件与相同文件名的上一版本文件的过程。
78.对于存在冲突的情况，例如多个开发人员都对相同文件名的文件做了修改，如果提交的相同文件名的多个新版本文件中某一行或几行存在不同修改，此时多个新版本文件就存在冲突，这需要相关人员解决，如保留某一个开发人员的修改版本或对多个文件进行合并等等。当然对于多个提交请求还会出现其他存在冲突的情况，本发明实施例对此不作限定。
79.需要说明的是，如果提交无需求的新版本文件，需要在新版本文件中添加几个特
殊号码以了解提交的新版本文件的内容，特殊号码可以与代码版本控制系统进行预先约定。
80.当然，本发明实施例还可以进行一些代码规范的检查，以检查体检的新版本文件中的代码是否符合设定的代码规范，通过检查代码规范，可以使得提交的代码文件中的代码符合统一的规范，避免不同开发人员提交的代码没有统一标准，影响后续的代码覆盖测试过程。
81.在本发明一可选实施例中，在步骤s102将比较后的新版本文件的修改代码行信息、文件名和对应需求标识记录至版本覆盖记录文件的过程中，可以按照如下的json格式进行版本覆盖记录。
82.例如，id”:[“path/filename”:[“line1”,“line3-line4”],“path/filename:[“line1”,“li ne2”]]。其中，id表示需求编号，需求编号的下一层是文件路径path/filename，一个需求可以对应多个文件，因此一个需求编号的下一层可以包含多个文件路径，每个文件路径的下一层是代码行的行号line，行号有两种记录方式，一种是单独一行的行号，另一种是连续多行采用
“‑”
连接，行号按从小到大的顺序连接，且不重复的记录行号。当然，也可以按照其他方式(如数据库等方式)进行版本覆盖记录，本发明实施例对此不作具体限定。
[0083]
在本发明一实施例中，提交新版本文件时一次只能提交一个需求相关的代码，通过新版本文件和旧版本文件的比较结果，可以将修改代码行的相关信息记录至版本覆盖记录文件，从而可以清楚的了解到提交的需求都修改了哪些代码行，但是关于代码行的记录信息可能会因为其它相关需求或这个需求之后的修改产生变动，比如针对需求b之前提交的文件修改了第16-18行，后来需求c在第15行位置加了一行，此时需求b的代码行就变成了17-19行，因此，若本次针对某个需求提交的新版本文件影响了其它相关需求中的记录，还需要对相关需求的记录进行修改，以避免后续测试结果不准确。
[0084]
具体的，若判断一个新版本文件的文件名对应多个需求，且针对这多个需求中的任一需求修改了代码行，进一步分析修改代码行信息是否影响了新版本文件对应的其他需求相关的代码行信息，如果影响了新版本文件对应的其他需求相关的代码行信息，将版本覆盖记录文件中已经记录的其他需求相关的代码行信息进行相应修改。
[0085]
例如，针对需求123，开发人员张三修改了文件a的第5-10、18行后进行了提交，版本覆盖记录文件记录了“123”:[“a”:[“5-10”,18]]。
[0086]
开发人员李四修改了文件b中第100、102行，添加了第109-200后进行了提交，版本覆盖记录文件的记录内容更新为“123”:[“a”:[“5-10”,18],“b”:[“100”,“102”,“109-200”]]。
[0087]
进而，开发人员赵五在文件a中添加了第2行、19-20行，修改了第6行，此时，版本覆盖记录文件的记录内容更新为“123”:[“a”:[“2”,“6-11”,“19-21”]，“b”:[“100”,“102”,“109-200”]]，文件a由于增加了第2行，因此文件a后面的代码行的行数也进行了调整。
[0088]
张三之后又对需求124开发，修改了文件a的第3、17行，添加了第5行，版本覆盖记录文件的记录内容更新为“123”:[“a”:[“2”,“7-12”,“20-22”],“b”:[“100”,“102”,“109-200”]]，“124”:[“a”:[“3”,“5”,“17”]]，可见，由于需求124对应的文件a中添加了第5行，因此也会影响需求123对应的文件a中代码行信息的记录，此时会对需求123对应的文件a的代
码行信息进行调整。
[0089]
本发明实施例中通过在版本覆盖记录文件中进行版本覆盖记录，可以在后续测试过程中对需求中正确的代码行进行记录和统计。本发明实施例可以依据新版本文件提交时触发的脚本文件对修改代码行信息进行版本覆盖记录，从而后续无需对程序的语法语义做额外分析。
[0090]
参见上文步骤s104，在本发明一实施例中，在对被测程序启动覆盖测试过程中，还可以对新版本文件的文件路径、执行代码行的执行次数进行监控。该实施例在覆盖测试记录文件中记录测试过程中监控到的相关信息过程如下。
[0091]
首先，启动监控覆盖测试过程，通过预置在被测程序中的钩子程序从被测程序中调取文件路径、执行代码行的执行次数及行号信息，并以哈希映射的结构形式保存至内存。然后，将内存中的文件路径、执行代码行的执行次数及行号信息写入覆盖测试记录文件。
[0092]
本发明实施例覆盖测试记录文件的记录信息也是以行为单位进行记录，例如覆盖测试记录文件记录了如下信息：
[0093]
path/filename:[line:times,line:times
……
]，
[0094]
path/filename:[line:times,line:times
……
]，
[0095]
其中，path/filename表示文件路径，覆盖测试记录文件可以包含多个文件路径，每个文件路径的下一层是代码行的信息，line:times表示代码行信息列表，line表示数字型的行号，times表示对应行号代码行的执行次数。
[0096]
本发明实施例优化了对覆盖测试结果的存储方式，在内存中以哈希映射(hashmap)的结构形式维护更新整个覆盖测试过程的记录信息，且采用简洁的文件路径、代码行行号、执行次数三个参数来方便的记录覆盖测试过程。
[0097]
在本发明实施例中，钩子程序(hook程序)预先内置在被测程序中，可以以函数、方法或类的任一形式存在，被测程序中可以设置一个开关，若将开关配置为打开状态则可以启动hook程序，若将开关配置为关闭状态则可以不启动hook程序，启动hook程序可以实现启动覆盖测试的监控过程。
[0098]
该实施例的hook程序可以在被测程序执行的入口处启动，被测程序的持续运行过程实际上是一个大的循环，循环到被测程序主动退出或是满足退出的条件才会执行结束，hook程序放在被测程序的前面，基本上可以hook到被测程序的所有代码行。本发明实施例可以不使用外部工具执行hook，而采用调试工具(debug工具)进行hook，在被测程序中进行hook的目的是在被测程序运行时可以知道运行了哪些代码行，只要执行了一个代码行，就可以把执行的代码行的行号和对应文件路径保存至内存，也可以对代码行的执行次数进行累计。本发明实施例方案采用大部份语言都可以实现，采用脚本或是解释语言更方便，在编译型语言中不做编译优化，在解释型的脚本语言中直接hook之后交给对hook指定的函数记录即可。
[0099]
在本发明一实施例中，将内存中的文件路径、执行代码行的执行次数及行号信息写入覆盖测试记录文件的过程中，可以按照预设钩子参数将内存中的文件路径、执行代码行的执行次数及行号信息写入覆盖测试记录文件。
[0100]
在该实施例中，预设钩子参数可以包含调取文件路径、执行代码行的执行次数及行号信息的时间间隔(如每隔n秒将内存信息写入覆盖测试记录文件)、需要过滤的文件信
息、是否读取覆盖测试记录文件之前记录信息等至少一项参数。例如，hook程序以hook函数形式存在，且命名为hook_fun(record_times,filelist,need_read_file)。其中，record_times为数值型(int)参数，表示每隔n秒将内存信息写入覆盖测试记录文件，例如每隔1秒或2秒或300秒将内存信息写入覆盖测试记录文件。filelist为字符串(string)参数，表示过滤文件的配置信息，配置的过滤文件不会被记录覆盖测试的结果数据。need_read_file为布尔型(boolean)参数，表示是否先读取覆盖测试记录文件之前的记录，如果是，表示被测程序重新执行后需要先把覆盖测试记录文件之前记录的文件信息读到内存中。覆盖测试记录文件中的内容从内存中按照预设时间间隔写入，可以是全覆盖方式写入至覆盖测试记录文件，覆盖测试记录文件可以进行不断的更新。
[0101]
在本发明一可选实施例中，若钩子参数包含读取覆盖测试记录文件之前记录信息的参数，在将内存中的文件路径、执行代码行的执行次数及行号信息写入覆盖测试记录文件之后，若被测程序重启覆盖测试，还可以将覆盖测试记录文件中的内容重新写入内存。具体的，响应于对被测程序覆盖测试的重启指令，从覆盖测试记录文件中获取最近一次记录的文件路径、执行代码行的执行次数及行号信息，进而，将获取到的重新文件路径、执行代码行的执行次数及行号信息重新写入内存。
[0102]
该实施例中，被测程序重新执行(即被测程序重启)后会清空或初始化被测程序对应的内存空间，被测程序重新执行是上一次覆盖测试的延续，由于清空或初始化了被测程序对应的内存，后续写入覆盖测试记录文件的内容是重启动后的内存内容，若指定需求要包括重启之前的内容，可以从覆盖测试记录文件中获取最近一次记录的内容写入内存，从而使得重启之后内容中的记录信息依然是连续的。比如，测试被测程序的指定需求时，服务器/客户端意外退出再打开，采用本发明实施例的方式可以有效地保证测试结果数据不丢失。
[0103]
基于同一发明构思，本发明实施例还提供了一种覆盖测试系统，图2示出了根据本发明一实施例的覆盖测试系统结构示意图。参见图2，覆盖测试系统包含比较单元210、测试单元220和第一计算单元230。
[0104]
比较单元210，适于响应于代码版本控制系统接收到至少一个新版本文件的提交请求，比较新版本文件与相同文件名的上一版本文件，将比较后的新版本文件的修改代码行信息、文件名和对应需求标识记录至版本覆盖记录文件；
[0105]
测试单元220，适于对被测程序启动覆盖测试过程，监控覆盖测试过程中执行的新版本文件的代码行的行号信息并记录至新版本文件对应的覆盖测试记录文件中；
[0106]
第一计算单元230，适于若测试结果参数包含指定需求，依据版本覆盖记录文件内容统计指定需求的代码总行数，依据覆盖测试记录文件内容统计指定需求的代码执行行数，通过代码执行行数除以代码总行数得到指定需求的测试覆盖度。
[0107]
参见图3，在本发明一实施例中，图2所示覆盖测试系统还包括第一写入单元240和第一生成单元250。
[0108]
第一写入单元240适于，在第一计算单元230通过代码执行行数除以代码总行数得到指定需求的测试覆盖度之前，从版本覆盖记录文件中读取指定需求对应的代码行，将读取出的指定需求对应的代码行写入超文本文件，一个指定需求对应写入一个超文本文件；若从覆盖测试记录文件中查找到与写入超文本文件的指定需求对应代码行相同的行号信
息，对写入超文本文件的代码行标记覆盖标识；
[0109]
第一生成单元250适于，在第一计算单元230通过代码执行行数除以代码总行数得到指定需求的测试覆盖度之后，基于指定需求的测试覆盖度、包含指定需求对应代码行的超文本文件生成指定需求对应的脚本文件，其中，一个指定需求对应生成一个脚本文件。
[0110]
参见图4，在本发明一实施例中，图2所示覆盖测试系统还包括第二计算单元260，第二计算单元260适于，在测试单元220监控覆盖测试过程中执行的新版本文件的代码行的行号信息并记录至新版本文件对应的覆盖测试记录文件中之后，若测试结果参数未包含指定需求，依据覆盖测试记录文件内容统计执行的各新版本文件的代码执行行数，通过任一新版本文件的代码执行行数除以任一新版本文件的代码总行数得到任一新版本文件的测试覆盖度；依据执行的所有新版本文件的代码执行行数除以所有新版本文件的代码总行数得到被测程序的总测试覆盖度。
[0111]
参见图5，在本发明一实施例中，图4所示覆盖测试系统还包括第二写入单元270、第二生成单元271和索引单元280。
[0112]
第二写入单元270适于，第二计算单元260依据执行的所有新版本文件的代码执行行数除以所有新版本文件的代码总行数得到被测程序的总测试覆盖度之前，还包括：将新版本文件的文件路径记录至覆盖测试记录文件中；依据覆盖测试记录文件中的新版本文件路径查找对应的新版本文件，将查找到的新版本文件的代码行写入超文本文件，一个新版本文件对应写入一个超文本文件；若从覆盖测试记录文件中查找到与写入超文本文件的新版本文件对应代码行相同的行号信息，对写入超文本文件的代码行标记覆盖标识。
[0113]
第二生成单元271适于，第二计算单元260依据执行的所有新版本文件的代码执行行数除以所有新版本文件的代码总行数得到被测程序的总测试覆盖度之后，还包括：基于任一新版本文件的测试覆盖度、包含任一新版本文件代码行的超文本文件生成任一新版本文件对应的脚本文件，其中，一个新版本文件对应生成一个脚本文件。
[0114]
索引单元280适于，将不同新版本文件对应的脚本文件以目录结构形式写入第一目录，将不同需求对应的脚本文件写入第二目录；为第一目录的脚本文件和第二目录的脚本文件生成同一索引文件。
[0115]
参见图6，在本发明一实施例中，图2所示覆盖测试系统还包括判断单元290和修改单元200。
[0116]
判断单元290适于，判断新版本文件是否包含符合预设规范的需求标识；若不包含符合预设规范的需求标识，拒绝接收至少一个新版本文件的提交请求；若包含符合预设规范的需求标识，且接收到相同文件名的新版本文件的多个提交请求，分析多个提交请求分别包含的新版本文件是否存在冲突；若存在冲突，拒绝接收至少一个新版本文件的多个提交请求；其中，不存在冲突时可进入比较新版本文件与相同文件名的上一版本文件的过程。
[0117]
修改单元200适于，若一个新版本文件的文件名对应多个需求，且针对多个需求中的任一需求修改了代码行，分析修改代码行信息是否影响新版本文件对应的其他需求相关的代码行信息；若是，将版本覆盖记录文件中已经记录的其他需求相关的代码行信息进行相应修改。
[0118]
在本发明一实施例中，测试单元220还适于，若预先配置对新版本文件的文件路径、执行代码行的执行次数的监控，启动监控覆盖测试过程，通过预置在被测程序中的钩子
程序从被测程序中调取文件路径、执行代码行的执行次数及行号信息，并以哈希映射的结构形式保存至内存；将内存中的文件路径、执行代码行的执行次数及行号信息写入覆盖测试记录文件。
[0119]
测试单元220还适于，按照预设钩子参数将内存中的文件路径、执行代码行的执行次数及行号信息写入覆盖测试记录文件；其中，预设钩子参数包含向覆盖测试记录文件写入文件路径、执行代码行的执行次数及行号信息的时间间隔、需要过滤的文件信息、是否读取覆盖测试记录文件之前记录信息中的至少一项。
[0120]
在本发明一实施例中，若钩子参数包含读取覆盖测试记录文件之前记录信息的参数，将内存中的文件路径、执行代码行的执行次数及行号信息写入覆盖测试记录文件之后，响应于对被测程序覆盖测试的重启指令，从覆盖测试记录文件中获取最近一次记录的文件路径、执行代码行的执行次数及行号信息；将获取到的重新文件路径、执行代码行的执行次数及行号信息重新写入内存。
[0121]
基于同一发明构思，本发明实施例还提供了一种计算机存储介质，计算机存储介质存储有计算机程序代码，当计算机程序代码在计算设备上运行时，导致计算设备执行上文任意实施例的覆盖测试方法。
[0122]
基于同一发明构思，本发明实施例还提供了一种计算设备，包括：处理器；存储有计算机程序代码的存储器；当计算机程序代码被处理器运行时，导致计算设备执行上文任意实施例的覆盖测试方法。
[0123]
所属领域的技术人员可以清楚地了解到，上述描述的系统、装置、模块和单元的具体工作过程，可以参考前述方法实施例中的对应过程，为简洁起见，在此不另赘述。
[0124]
另外，在本发明各个实施例中的各功能单元可以物理上相互独立，也可以两个或两个以上功能单元集成在一起，还可以全部功能单元都集成在一个处理单元中。上述集成的功能单元既可以采用硬件的形式实现，也可以采用软件或者固件的形式实现。
[0125]
本领域普通技术人员可以理解：所述集成的功能单元如果以软件的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本发明的技术方案本质上或者该技术方案的全部或部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，其包括若干指令，用以使得一台计算设备(例如个人计算机，服务器，或者网络设备等)在运行所述指令时执行本发明各实施例所述方法的全部或部分步骤。而前述的存储介质包括：u盘、移动硬盘、只读存储器(rom)、随机存取存储器(ram)，磁碟或者光盘等各种可以存储程序代码的介质。
[0126]
或者，实现前述方法实施例的全部或部分步骤可以通过程序指令相关的硬件(诸如个人计算机，服务器，或者网络设备等的计算设备)来完成，所述程序指令可以存储于一计算机可读取存储介质中，当所述程序指令被计算设备的处理器执行时，所述计算设备执行本发明各实施例所述方法的全部或部分步骤。
[0127]
最后应说明的是：以上各实施例仅用以说明本发明的技术方案，而非对其限制；尽管参照前述各实施例对本发明进行了详细的说明，本领域的普通技术人员应当理解：在本发明的精神和原则之内，其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分或者全部技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案脱离本发明的保护范围。