具体实施方式
以下结合其中的较佳实施例对本发明方案进行详细阐述,在下述各实施例的说明中,出于简便说明的目的,是以被测代码为被测源代码为例进行说明,本领域技术人员可以知晓的是,根据实际需要,下述各实施例中的被测源代码可以根据需测试的代码的名称(例如被测代码)进行替换,因此,下述说明仅仅是对本发明方案的举例说明,并不用以对本发明方案构成限定。
在下述各实施例的说明中,先对本发明的代码测试信息收集方法的各实施例进行举例说明,再对本发明的代码测试信息收集系统的各实施例进行距离说明。
以下先对本发明的代码测试信息收集方法的各实施例进行详细说明。
实施例一
图1中示出了本发明的代码测试收集方法实施例一的流程示意图。如图1所示,本实施例中的代码测试信息收集方法包括步骤:
步骤S101:通过自动化发布系统将被测代码部署到测试环境,所谓测试环境(test environment),是指测试运行其上的软件和硬件环境的描述,以及任何其它与被测软件交互的软件,包括驱动和桩等等,也是指为了完成软件测试工作所必需的计算机硬件、软件、网络设备、历史数据的总称,因此,在本发明的下述说明中,不对测试环境展开赘述;
步骤S102:在上述测试环境中对所述被测代码进行测试,获得代码测试信息,其中,这里的代码测试信息可以是代码覆盖率信息,也可以是代码差异化信息,也可以是代码覆盖率信息与代码差异化信息的组合。
根据本实施例中的方案,其是通过自动化发布系统将被测源代码部署到测试环境后,再在测试环境中对被测代码进行测试得到代码测试信息,从而实现对代码测试信息的收集,由于自动化发布系统可以实现文件的自动化发布,文件的传输无需人工干预,测试人员只需点几个按钮就可以将文件从开发环境发布到外网正式环境,从而在通过自动化发布系统将被测源代码部署到测试环境后进行测试从而收集代码测试信息,实现了代码测试信息的收集与自动化发布工具的结合,无需用户的大量干预,实现了在用户无感知的情况下对代码测试信息的收集,减少了测试人员的工作量,提高了效率。
以下结合代码测试信息为代码覆盖率信息、代码差异化信息为例,分别对本发明的代码测试信息收集方法进行详细说明。
实施例二
图2中示出了本发明的代码测试信息收集方法实施例二的流程示意图,在本实施例二的方案中,与上述实施例一的不同之处主要在于,本实施例中是以仅仅收集代码覆盖率信息为例进行说明。
如图2所示,在该实施例二中,本发明的代码测试信息收集方法包括步骤:
步骤S201:通过自动化发布系统将被测源代码部署到测试环境;
步骤S202:对上述部署到测试环境的被测源代码进行插桩;
步骤S203:执行功能测试用例,在执行功能测试用例时收集代码覆盖率信息;
步骤S204:对上述被测源代码移桩后将上述被测源代码进行发布。
根据如上所述的本实施例中的代码测试信息收集方法,其是通过自动化发布系统将被测源代码部署到测试环境后,再对被测源代码进行插桩,然后执行测试功能用例,并在执行功能测试用例时收集代码覆盖率信息,并在测试完毕后,将移桩后的被测源代码进行发布,由于自动化发布系统可以实现文件的自动化发布,文件的传输无需人工干预,测试人员只需点几个按钮就可以将文件从开发环境发布到外网正式环境,从而在通过自动化发布系统将被测源代码部署到测试环境后进行测试从而收集代码覆盖率信息,由此可见,本实施例中的方案是实现了代码覆盖率信息的收集与自动化发布工具的结合,无需用户的大量干预,实现了在用户无感知的情况下对代码覆盖率信息的收集,减少了测试人员的工作量,提高代码覆盖率信息收集的效率。
上述步骤S202中对被测源代码进行插桩时,可以采用已有的以及在以后出现的各种可能的方式进行,用于插桩的代码,可以根据实际需要进行设定,在此不予赘述。所谓插桩,是指在不破坏被测程序原有逻辑完整性的情况下,在被测程序的相应位置插入用于插桩的代码(也称之为探针),这些探针本质上是进行信息采集的代码段,通过探针的执行并输出程序的运行特征数据,从而基于这些特征数据的分析,揭示程序的内部行为和特性。在测试完毕后,需要将这些插入的探针去除,以保留被测程序的完整性,即步骤S204中的移桩操作。
在执行功能测试用例时对代码覆盖率信息的收集,可以是在执行功能测试用例的后台进行,无需人工干预,对用户完全透明,因此可以在用户毫无感知的情况下收集到代码覆盖率信息。所谓无感知,是指对用户完全透明,用户只需正常完成测试工作即可,在测试过程中感知不到代码覆盖率信息收集工具的存在。具体的代码覆盖率信息的收集方式,可以采用已有的以及在以后出现的各种可能的方式进行,在此不予赘述。
其中,在收集到代码覆盖率信息之后,还可以对该代码覆盖率信息进行分析、生成可视化报告。该对代码覆盖率信息进行分析、生成可视化报告的过程,可以是任何时候进行,在其中一种实现方式中,可以是在测试完毕后、对被测源代码移桩之前进行,因此,如图2所示,在本实施例的方法中,在上述步骤S203与步骤S204之间还包括步骤:
步骤S2034:测试完毕后,接收将上述被测源代码进行发布的指令,对上述代码覆盖率信息进行分析,生成可视化报告。
出于对生成可视化报告时的便利性考虑,在其中一种实现方式中,在收集到代码覆盖率信息之后,还可以将该代码覆盖率信息转换成第一预设格式类型信息后予以存储,以方便后续过程中对代码覆盖率信息分析后生成可视化报告。生成的可视化报告可提供给测试人员,供测试人员对测试过程及结果进行评估,例如基于代码覆盖率信息对测试用例是否够全面进行评估等等。此外,该第一预设格式类型,可以依据实际需要设定为任何一种方式,只要能够便于后续过程生成可视化报告即可,例如json格式类型或者xml格式类型等等。
在另外一种方式中,在收集到代码覆盖率信息之后,可以将该代码覆盖率信息以其当前格式直接予以存储,在需要进行分析、生成可视化报告时,读取出该代码覆盖率信息后,再将该代码覆盖率信息转换为第一预设格式类型,以便于生成可视化报告,该第一预设格式类型,可以依据实际需要设定为任何一种方式,例如json格式类型或者xml格式类型等等。
图3中示出了图2所示的代码测试信息收集方法在对代码覆盖率信息进行分析生成可视化报告时实施例的流程示意图,如图3所示,该实施例二中生成可视化报告的步骤包括:
获取被测源代码的代码统计信息,这里的该代码统计信息标明了被测源代码中哪些行是可执行行,哪些行是注释行;
加载上述获得的代码覆盖率信息,该代码覆盖率信息,实际上标明了哪些行是覆盖行,方便后续过程中对各行是否为覆盖行的判断;
读取被测源代码的一行源代码,根据上述代码覆盖率信息判断当前行是否为覆盖行,其中,在对源代码行进行读取时,可以是按照程序编码顺序依次对各行源代码进行读取,也可以是采用其他的设定方式进行读取,例如随机读取等等;
若是覆盖行,判断该当前行是否为可执行行,若是可执行行,将该当前行的样式设置为覆盖样式,若不是可执行行,将该当前行的样式设置为普通样式;
若不是覆盖行,判断该当前行是否为可执行行,若是可执行行,将该当前行的样式设置为未覆盖样式,若不是可执行行,将该当前行的样式设置为普通样式;请对以上三种样式做出阐述。
若该被测源代码的各行源代码均已读取完毕,则完成可视化报告的生成过程,若未读取完毕,则读取下一行源代码后,针对所读取的下一行源代码执行上述判断其是否为覆盖行、可执行行的判断过程,直至被测源代码中的各行源代码均完成该判断过程。
其中,上述代码统计信息,可以是在收集代码覆盖率信息的同时予以分析收集,对被测源代码进行分析统计、获得代码统计信息的方式可以采用已有的或者以后出现的各种可能的方式进行,具体的收集代码统计信息的方式在此不予赘述。
其中,上述覆盖样式、普通样式、未覆盖样式,是为了从生成的可视化报告的结果直观地对各行的测试结果进行分析,将当前行的样式设置为覆盖样式,则说明该当前行为可执行行且在测试过程中被覆盖,将当前行的样式设置为未覆盖样式,则说明该当前行为可执行行且在测试过程中未被覆盖,将当前行的样式设置为普通样式,则说明当前行不是可执行行,基于各行的样式的设置,测试人员可以一目了然地对测试结果进行分析。
在对代码覆盖率信息进行分析时,也可以不按上述步骤先对覆盖行、再对可执行行的步骤进行判断,对覆盖行、可执行行的判定顺序不限,只要是能够将不是可执行行的源代码行的样式设置为普通样式、将是可执行行且是覆盖行的源代码行的样式设置为覆盖样式、将是可执行行且不是覆盖行的源代码行的样式设置为未覆盖样式即可。
实施例三
图4中示出了本发明的代码测试信息收集方法实施例三的流程示意图,在本实施例中,与上述实施例一的不同之处主要在于,本实施例中是以仅收集代码差异化信息为例进行说明。
如图4所示,本实施例中的代码测试信息收集方法包括步骤:
步骤S401:通过自动化发布系统将被测源代码部署到测试环境;
步骤S402:检测与上述被测源代码对应的旧版源代码;
步骤S403:根据上述被测源代码、上述旧版源代码生成代码差异化信息。
根据如上所述的本实施例中的代码测试信息收集方法,其不仅实现了代码差异化信息的收集,而且其是通过自动化发布工具将被测源代码部署到测试环境后,再收集代码差异化信息,然后对被测源代码进行发布,由于自动化发布系统可以实现文件的自动化发布,文件的传输无需人工干预,测试人员只需点几个按钮就可以将文件从开发环境发布到外网正式环境,从而在通过自动化发布系统将被测源代码部署到测试环境后进行测试从而收集代码差异化信息,由此可见,本实施例中的方案是实现了代码差异化信息的收集与自动化发布工具的结合,无需用户的大量干预,实现了在用户无感知的情况下对代码差异化信息的收集,减少了测试人员的工作量,提高代码差异化信息收集的效率。
上述与被测源代码对应的旧版源代码,通常情况下可以设置为与当前的被测源代码最近的旧版源代码,即最新的旧版源代码。当然,如果需要对早前的某个版本的旧版源代码与被测源代码进行评估,也可以将其设置为所需要版本的旧版源代码,可以依据实际需要进行设定,在此不予赘述。
对代码差异化信息的收集,可以是在执行功能测试用例的过程中进行,无需人工干预,对用户完全透明,因此可以在用户毫无感知的情况下收集到代码差异化信息。所谓无感知,是指对用户完全透明,用户只需正常完成测试工作即可,在测试过程中感知不到代码差异化信息收集工具的存在。具体的代码差异化信息的收集方式,可以采用已有的或者以后出现的各种可能的方式进行,具体的代码差异化信息的收集方式在此不予赘述。
其中,在收集到代码差异化信息之后,还可以对该代码差异化信息进行分析,生成可视化报告。该对代码差异化信息进行分析、生成可视化报告的过程,可以是在得到代码差异化信息之后的任何时候进行,在其中一种实现方式中,可以是在测试完毕后进行,因此,如图4所示,在本实施例的方法中,在上述步骤S403之后还包括步骤:
步骤S404:执行功能测试用例,在测试完毕后、接收到将被测源代码进行发布的指令时,对上述代码差异化信息进行分析生成可视化报告。
出于对生成可视化报告时的便利性考虑,在其中一种实现方式中,在收集到代码差异化信息之后,还可以将该代码差异化信息转换成第二预设格式类型信息后予以存储,以方便后续过程中对代码差异化信息进行分析生成可视化报告。该第二预设格式类型,可以依据实际需要设定为任何一种方式,只要能够便于后续过程生成可视化报告即可,例如json格式类型或者xml格式类型等等。
在另外一种方式中,在收集到代码差异化信息之后,可以将该代码差异化信息以其当前格式直接予以存储,在需要进行分析生成可视化报告时,读取出该代码差异化信息后,再将该代码差异化信息转换为第二预设格式类型,以便于生成可视化报告,该第二预设格式类型,可以依据实际需要设定为任何一种哦方式,例如json格式类型或者xml格式类型等等。
图5中示出了本实施例中对代码差异化信息进行分析生成可视化报告的流程示意图,如图5所示,对代码差异化信息进行分析生成可视化报告的步骤包括:
加载上述代码差异化信息,该代码差异化信息,实际上标明了哪些行是变更行,方便后续过程中对是否为变更行的判断;
读取被测源代码行中的一行源代码;
根据上述代码差异化信息判断当前行是否为变更行:若是变更行,将当前行的样式设置为变更样式,若不是变更行,将当前行的样式设置为非变更样式;
若该被测源代码的各行源代码均已读取完毕,则完成可视化报告的生成过程,若未读取完毕,则读取下一行源代码后,针对所读取的下一行源代码执行上述判断其是否为变更行的判断过程,直至被测源代码中的各行源代码均完成该判断过程。
其中,这里的变更样式、未变更样式,是为了从生成的可视化报告的结果直观地对各行的测试结果进行分析,将当前行的样式设置为变更样式,则说明该当前行发生了变更,将当前行的样式设置为未变更样式,则说明该当前行未发生变更,基于各行的样式的设置,测试人员可以一目了然地对测试结果进行分析。
实施例四
图6中示出了本发明的代码测试信息收集方法实施例四的流程示意图,在本实施例中,与上述实施例二的不同之处主要在于,本实施例中的方案还实现了代码差异化信息的收集,即同时收集了代码覆盖率信息与代码差异化信息。
如图6所示,本实施例四中的代码测试信息收集方法包括步骤:
步骤S601:通过自动化发布系统将被测源代码部署到测试环境;
步骤S602:对上述部署到测试环境的被测源代码进行插桩;
步骤S603:检测与上述被测源代码对应的旧版源代码,根据该被测源代码、该旧版源代码生成代码差异化信息;
步骤S604:执行功能测试用例,在执行功能测试用例时收集代码覆盖率信息;
步骤S605:对上述被测源代码移桩后将被测源代码进行发布。
根据本实施例中的方法,不仅实现了代码覆盖率信息的收集,还实现了代码差异化信息的收集,而代码差异化信息与代码覆盖率信息的结合表明了新旧版本代码差异部分被覆盖的情况,有助于测试人员对变更代码测试程度的评估,可以评估增量测试的完整性,具有重要的意义。
上述与被测源代码对应的旧版源代码,通常情况下可以设置为与当前的被测源代码最近的旧版源代码,即最新的旧版源代码。当然,如果需要对早前的某个版本的旧版源代码与被测源代码进行评估,也可以将其设置为所需要版本的旧版源代码,可以依据实际需要进行设定,在此不予赘述。
其中,在收集到代码差异化信息、代码覆盖率信息之后,还可以对该代码差异化信息、代码覆盖率信息进行分析、生成可视化报告。该对代码差异化信息和代码覆盖率信息进行分析、生成可视化报告的过程,可以是任何时候进行,在其中一种实现方式中,可以是在测试完毕后、对被测源代码移桩前进行,因此,如图6所示,在本实施例的方法中,在上述步骤S604与步骤S605之间还包括步骤:
步骤S6045:测试完毕后,接收将上述被测源代码进行发布的指令,对上述代码差异化信息、代码覆盖率信息进行分析,生成可视化报告。
出于对生成可视化报告时的便利性考虑,在其中一种实现方式中,在收集到代码差异化信息之后,还可以将该代码差异化信息转换成第二预设格式类型信息后予以存储,以方便后续过程中对代码差异化信息分析后生成可视化报告。该第二预设格式类型,可以依据实际需要设定为任何一种方式,只要能够便于后续过程生成可视化报告即可,例如json格式类型或者xml格式类型等等。
在另外一种方式中,在收集到代码差异化信息之后,可以将该代码差异化信息以其当前格式直接进行存储,在需要进行分析、生成可视化报告时,读取出该代码差异化信息后,再将该代码差异化信息转换为第二预设格式类型,以便于生成可视化报告,该第二预设格式类型,可以依据实际需要设定为任何一种哦方式,例如json格式类型或者xml格式类型等等。
上述代码覆盖率信息转换成的第一预设格式类型信息与该代码差异化信息转换成的第二预设格式类型可以相同也可以不同,通常情况下可设置为相同,以便于操作。
图7中示出了本实施例中对代码差异化信息、代码覆盖率信息进行分析生成可视化报告的流程示意图,如图7所示,将代码差异化信息、代码覆盖率信息的分析结果生成可视化报告的步骤包括:
获取被测源代码的代码统计信息,这里的代码统计信息标明了被测源代码中哪些行是可执行行,哪些行是注释行;
加载上述收集的代码差异化信息、代码覆盖率信息,该代码差异化信息,实际上标明了哪些行是变更行,方便后续过程中对是否为变更行的判断,该代码覆盖率信息,实际上标明了哪些行是覆盖行,方便后续过程中对是否为覆盖行的判断;
读取被测源代码中的一行源代码;
根据上述代码差异化信息判断当前行是否为变更行:若是变更行,将当前行的样式设置为变更样式,若不是变更行,将当前行的样式设置为非变更样式;
根据上述代码覆盖率信息判断当前行是否为覆盖行:
若是覆盖行,判断该当前行是否为可执行行,若是可执行行,将该当前行的样式设置为覆盖样式,若不是可执行行,将该当前行的样式设置为普通样式;
若不是覆盖行,判断该当前行是否为可执行行,若是可执行行,将该当前行的样式设置为未覆盖样式,若不是可执行行,将该当前行的样式设置为普通样式;
若该被测源代码的各行源代码均已读取完毕,则完成可视化报告的生成过程,若未读取完毕,则读取下一行源代码后,针对所读取的下一行源代码执行上述判断其是否为变更行、覆盖行、可执行行的判断过程,直至被测源代码中的各行源代码均完成该判断过程。
其中,这里的变更样式、未变更样式,是为了从生成的可视化报告的结果直观地对各行的测试结果进行分析,将当前行的样式设置为变更样式,则说明该当前行发生了变更,将当前行的样式设置为未变更样式,则说明该当前行未发生变更,基于各行的样式的设置,测试人员可以一目了然地对测试结果进行分析。
在对代码差异化信息、代码覆盖率信息进行分析时,也可以不按上述步骤先对变更行、再对覆盖行与可执行行的步骤进行判断,对变更行、覆盖行、可执行行的判定顺序不限,只要是能够将是变更行的源代码行的样式设置为变更样式、将不是变更行的源代码行的样式设置为未变更样式、将不是可执行行的源代码行的样式设置为普通样式、将是可执行行且是覆盖行的源代码行的样式设置为覆盖样式、将是可执行行且不是覆盖行的源代码行的样式设置为未覆盖样式即可。
其中上述代码统计信息,可以是在收集代码差异化信息或者代码覆盖率信息的同时予以分析收集,对被测源代码进行分析统计、获得代码统计信息的方式可以采用现有技术中已有的方式,在此不予赘述。
本实施例四中的代码测试信息收集方法的其他技术特征与上述实施例二中的相同,在此不予赘述。
根据上述本发明的代码测试信息收集方法,本发明还提供一种代码测试信息收集系统,以下针对本发明的代码测试信息收集系统的其中几个具体示例进行详细说明。
实施例一
图8中示出了本发明的代码测试信息收集系统实施例一的结构示意图。如图8所示,本实施例一中的代码测试信息收集系统包括:
导入单元801,用于通过自动化发布系统将被测代码部署到测试环境;
测试单元802,用于在上述测试环境中对所述被测代码进行测试,获得代码测试信息,其中,这里的代码测试信息可以是代码覆盖率信息,也可以是代码差异化信息,也可以是代码覆盖率信息与代码差异化信息的组合。
根据本实施例中的方案,其是通过自动化发布系统将被测源代码部署到测试环境后,再在测试环境中对被测代码进行测试得到代码测试信息,从而实现对代码测试信息的收集,由于自动化发布系统可以实现文件的自动化发布,文件的传输无需人工干预,测试人员只需点几个按钮就可以将文件从开发环境发布到外网正式环境,从而在通过自动化发布系统将被测源代码部署到测试环境后进行测试从而收集代码测试信息,实现了代码测试信息的收集与自动化发布工具的结合,无需用户的大量干预,实现了在用户无感知的情况下对代码测试信息的收集,减少了测试人员的工作量,提高了效率。
以下结合代码测试信息为代码覆盖率信息、代码差异化信息为例,分别对本发明的代码测试信息收集系统进行详细说明。
实施例二
图9中示出了本发明的代码测试信息收集系统实施例二的结构示意图,在本实施例二的方案中,与上述实施例一中的不同之处主要在于,本实施例中是以仅仅收集代码覆盖率信息为例进行说明。
如图9所示,本实施例中的代码测试信息收集系统包括:
导入单元901,用于通过自动化发布系统将被测源代码部署到测试环境;
测试单元902,用于在上述测试环境中对所述被测代码进行测试,获得代码测试信息,这里的代码测试信息可以包括代码覆盖率信息。
其中,该测试单元902具体可以包括:
插桩单元9021,用于对上述部署到测试环境的被测源代码进行插桩;
代码覆盖率信息收集单元9022,用于在执行功能测试用例时收集上述部署到测试环境的被测源代码的代码覆盖率信息;
移桩单元9023,用于对上述被测源代码进行移桩,上述被测源代码经移桩后进行发布。
根据本实施例中的代码测试信息收集系统,其是通过自动化发布工具将被测源代码部署到测试环境后,再对被测源代码进行插桩,然后执行测试功能用例,并在执行功能测试用例时收集代码覆盖率信息,并在测试完毕后,将被测源代码移桩后进行发布,由于自动化发布系统可以实现文件的自动化发布,文件的传输无需人工干预,测试人员只需点几个按钮就可以将文件从开发环境发布到外网正式环境,从而在通过自动化发布系统将被测源代码部署到测试环境后进行测试从而收集代码覆盖率信息,由此可见,本实施例中的方案是实现了代码覆盖率信息的收集与自动化发布工具的结合,无需用户的大量干预,实现了在用户无感知的情况下对代码覆盖率信息的收集,减少了测试人员的工作量,提高代码覆盖率信息收集的效率。
插桩单元9021对被测源代码进行插桩时,可以采用已有的以及在以后出现的各种可能的方式进行,用于插桩的代码,可以根据实际需要进行设定,在此不予赘述。所谓插桩,是指在不破坏被测程序原有逻辑完整性的情况下,在被测程序的相应位置插入用于插桩的代码(也称之为探针),这些探针本质上是进行信息采集的代码段,通过探针的执行并输出程序的运行特征数据,从而基于这些特征数据的分析,揭示程序的内部行为和特性。在测试完毕后,需要将这些插入的探针去除,以保留被测程序的完整性,即移桩单元9023中的移桩操作。
代码覆盖率信息收集单元9022对代码覆盖率信息的收集,可以是在执行功能测试用例的后台进行,无需人工干预,对用户完全透明,因此可以在用户毫无感知的情况下收集到代码覆盖率信息。所谓无感知,是指对用户完全透明,用户只需正常完成测试工作即可,在测试过程中感知不到代码覆盖率信息收集的存在。具体的代码覆盖率信息的收集方式,可以采用已有的以及在以后出现的各种可能的方式进行,在此不予赘述。
其中,在收集到代码覆盖率信息之后,还可以对该代码覆盖率信息进行分析、生成可视化报告。该对代码覆盖率信息进行分析、生成可视化报告的过程,可以是任何时候进行,在其中一种实现方式中,可以是在测试完毕后、对被测源代码移桩之前进行,因此,如图9所示,在本实施例的系统中,在上述代码覆盖率信息收集单元9022与插桩单元9021之间还包括:
分析单元90212,用于在接收到将被测源代码进行发布的指令时,对上述代码覆盖率信息进行分析生成可视化报告。
出于对生成可视化报告时的便利性考虑,在其中一种实现方式中,代码覆盖率信息收集单元9022在收集到代码覆盖率信息之后,还可以将该代码覆盖率信息转换成第一预设格式类型信息后予以存储,以方便后续过程中对代码覆盖率信息分析后生成可视化报告。生成的可视化报告可提供给测试人员,供测试人员对测试过程及结果进行评估,例如基于代码覆盖率信息对测试用例是否够全面进行评估等等。该第一预设格式类型,可以依据实际需要设定为任何一种方式,只要能够便于后续过程生成可视化报告即可,例如json格式类型或者xml格式类型等等。
在另外一种方式中,代码覆盖率信息收集单元9022在收集到代码覆盖率信息之后,可以将该代码覆盖率信息以其当前格式直接予以存储,分析单元90212在需要对代码覆盖率信息进行分析、生成可视化报告时,读取出该代码覆盖率信息后,再将该代码覆盖率信息转换为第一预设格式类型,以便于生成可视化报告,该第一预设格式类型,可以依据实际需要设定为任何一种哦方式,例如json格式类型或者xml格式类型等等。
图10中示出了图9中所示的分析单元90212在一个具体示例中的结构示意图,如图10所示,在本实施例二中,上述分析单元90212具体可以包括:
统计信息获取单元902121,用于获取被测源代码的代码统计信息;
加载单元902122,用于加载上述代码覆盖率信息;
行读取单元902123,用于读取被测源代码中的各行;
覆盖行判定单元902124,用于根据上述代码覆盖率信息判断当前行是否为覆盖行;
可执行行判定单元902125,用于根据上述代码统计信息判定当前行是否为可执行行;
样式设置单元902126,用于在覆盖行判定单元902124判定当前行是覆盖行、可执行行判定单元902125判定当前行是可执行行时,将当前行的样式设置为覆盖样式,在覆盖行判定单元902124判定当前行不是覆盖行、可执行行判定单元902125判定当前行是可执行行时,将该当前行的样式设置为未覆盖样式,否则将该当前行的样式设置为普通样式。
在对代码覆盖率信息进行分析时,对覆盖行、可执行行的判定顺序不限,只要是能够将不是可执行行的源代码行的样式设置为普通样式、将是可执行行且是覆盖行的源代码行的样式设置为覆盖样式、将是可执行行且不是覆盖行的源代码行的样式设置为未覆盖样式即可。
上述代码统计信息,可以直接利用已经分析统计好的代码统计信息,也可以由图9中所示的代码信息统计单元9024进行分析统计,即本实施例中的代码测试信息收集系统,还可以包括代码信息统计单元9024,用于对上述被测源代码进行分析统计,获得上述代码统计信息。
该代码统计信息,可以是在收集代码覆盖率信息的同时予以分析收集,对被测源代码进行分析统计、获得代码统计信息的方式可以采用各种可能的方式进行,在此不予赘述。
本实施例二中的代码测试信息收集系统,具体的代码测试信息的收集方法与上述本发明代码测试信息收集方法实施例二中的相同,在此不予赘述。
本实施例二的代码测试信息收集具体的代码测试信息的收集方式与上述本发明代码测试信息收集方法实施例二中的相同,在此不予赘述。
实施例三
图11中示出了本发明的代码测试信息收集系统实施例三的结构示意图,在本实施例三的方案中,与上述实施例一中的方案的不同之处主要在于,本实施例中是以仅仅收集代码差异化信息为例进行说明。
如图11所示,本实施例中的代码测试信息收集系统包括:
导入单元1101,用于通过自动化发布系统将被测源代码部署到测试环境;
测试单元1102,用于在上述测试环境中对所述被测代码进行测试,获得代码测试信息,这里的代码测试信息可以包括代码差异化信息,
其中,该测试单元1102具体包括:
代码差异化信息收集单元1121,用于检测与上述被测源代码对应的旧版源代码,并根据上述被测源代码、旧版源代码生成代码差异化信息。
根据如上所述的本实施例中的代码测试信息收集系统,其不仅实现了代码差异化信息的收集,而且是通过自动化发布工具将被测源代码部署到测试环境后,再收集代码差异化信息,然后将被测源代码进行发布,由于自动化发布系统可以实现文件的自动化发布,文件的传输无需人工干预,测试人员只需点几个按钮就可以将文件从开发环境发布到外网正式环境,从而在通过自动化发布系统将被测源代码部署到测试环境后进行测试从而收集代码差异化信息,由此可见,本发明方案是实现了代码差异化信息的收集与自动化发布工具的结合,无需用户的大量干预,实现了在用户无感知的情况下对代码差异化信息的收集,减少了测试人员的工作量,提高代码差异化信息收集的效率。
上述与被测源代码对应的旧版源代码,通常情况下可以设置为与当前的被测源代码最近的旧版源代码,即最新的旧版源代码。当然,如果需要对早前的某个版本的旧版源代码与被测源代码进行评估,也可以将其设置为所需要版本的旧版源代码,可以依据实际需要进行设定,在此不予赘述。
代码差异化信息收集单元1121对代码差异化信息的收集,可以是在执行功能测试用例的过程中进行,无需人工干预,对用户完全透明,因此可以在用户毫无感知的情况下收集到代码差异化信息。所谓无感知,是指对用户完全透明,用户只需正常完成测试工作即可,在测试过程中感知不到代码差异化信息收集工具的存在。具体的代码差异化信息的收集方式,可以采用已有的或者以后出现的各种可能的方式进行,具体的代码差异化信息的收集方式在此不予赘述。
其中,在收集到代码差异化信息之后,还可以对该代码差异化信息进行分析,生成可视化报告。该对代码差异化信息进行分析、生成可视化报告的过程,可以是在得到代码差异化信息之后的任何时候进行,在其中一种实现方式中,可以是在测试完毕后进行,因此,如图11所示,在本实施例中,上述测试单元1102还可以包括:
分析单元1122,用于在接收到将上述被测源代码进行发布的指令时,对上述代码差异化信息进行分析生成可视化报告。
出于对生成可视化报告时的便利性考虑,在其中一种实现方式中,代码差异化信息生成单元1121在收集到代码差异化信息之后,还可以将该代码差异化信息转换成第二预设格式类型信息后予以存储,以方便后续过程中对代码差异化信息分析后生成可视化报告。该第二预设格式类型,可以依据实际需要设定为任何一种方式,只要能够便于后续过程生成可视化报告即可,例如json格式类型或者xml格式类型等等。
在另外一种方式中,代码差异化信息生成单元1121在收集到代码差异化信息之后,可以将该代码差异化信息以其当前格式直接予以存储,分析单元1122在需要生成可视化报告时,读取出该代码差异化信息后,再将该代码差异化信息转换为第二预设格式类型,以便于生成可视化报告,该第二预设格式类型,可以依据实际需要设定为任何一种哦方式,例如json格式类型或者xml格式类型等等。
图12中示出了图11中所示的分析单元1122在一个具体示例中的结构示意图,如图12所示,在本实施例中,上述分析单元1122具体可以包括:
加载单元11221,用于加载上述代码差异化信息;
行读取单元11222,用于读取被测源代码行中的各行;
变更行判定单元11223,根据上述代码差异化信息判断当前行是否为变更行;
样式设置单元11224,用于在变更行判定单元11223判定当前行为变更行时,将当前行的样式设置为变更样式,在变更行判定单元11223判定当前行不是变更行时,将当前行的样式设置为非变更样式。
本实施例三中的代码测试信息收集具体的代码测试信息的收集方式与上述本发明代码测试信息收集方法实施例三中的相同,在此不予赘述。
实施例四
图13中示出了本发明的代码测试信息收集系统实施例四的结构示意图,在本实施例中,与上述实施例二的不同之处主要在于,本实施例中的方案还实现了代码差异化信息的收集,即同时收集了代码覆盖率信息与代码差异化信息。
如图13所示,本实施例四中的代码测试信息收集系统包括:
导入单元1301,用于通过自动化发布系统将被测源代码部署到测试环境;
测试单元1302,用于在上述测试环境中对所述被测代码进行测试,获得代码测试信息,这里的代码测试信息可以包括代码覆盖率信息以及代码差异化信息。
其中,该测试单元1302具体包括:
插桩单元13211,用于对部署到测试环境的上述被测源代码进行插桩;
代码差异化信息生成单元13212,用于检测与上述被测源代码对应的旧版源代码,并根据上述被测源代码、上述旧版源代码生成代码差异化信息;
代码覆盖率信息收集单元13213,用于在执行功能测试用例时收集代码覆盖率信息;
移桩单元13214,用于对上述被测源代码进行移桩,上述被测源代码经移桩后进行发布。
根据本实施例中的系统,不仅实现了代码覆盖率信息的收集,还实现了代码差异化信息的收集,而代码差异化信息与代码覆盖率信息的结合表明了新旧版本代码差异部分被覆盖的情况,有助于测试人员对变更代码测试程度的评估,可以评估增量测试的完整性,具有重要的意义。
上述与被测源代码对应的旧版源代码,通常情况下可以设置为与当前的被测源代码最近的旧版源代码,即最新的旧版源代码。当然,如果需要对早前的某个版本的旧版源代码与被测源代码进行评估,也可以将其设置为所需要版本的旧版源代码,可以依据实际需要进行设定,在此不予赘述。
其中,在收集到代码差异化信息、代码覆盖率信息之后,还可以对该代码差异化信息、代码覆盖率信息进行分析、生成可视化报告。该对代码差异化信息和代码覆盖率信息进行分析、生成可视化报告的过程,可以是任何时候进行,在其中一种实现方式中,可以是在测试完毕后、对被测源代码移桩前进行,因此,如图13所示,在本实施例的系统中,在上述代码覆盖率信息收集单元13213与移桩单元13214之间还包括:
分析单元132134,用于在接收到将被测源代码进行发布的指令时,对上述代码差异化信息、代码覆盖率信息进行分析生成可视化报告。
出于对生成可视化报告时的便利性考虑,在其中一种实现方式中,代码差异化信息生成单元13212在收集到代码差异化信息之后,还可以将该代码差异化信息转换成第二预设格式类型信息后予以存储,以方便后续过程中对代码差异化信息分析后生成可视化报告。该第二预设格式类型,可以依据实际需要设定为任何一种方式,只要能够便于后续过程生成可视化报告即可,例如json格式类型或者xml格式类型等等。
在另外一种方式中,代码差异化信息生成单元13212在收集到代码差异化信息之后,可以将该代码差异化信息以其当前格式直接予以存储,分析单元132134在需要生成可视化报告时,读取出该代码差异化信息后,再将该代码差异化信息转换为第二预设格式类型,以便于生成可视化报告,该第二预设格式类型,可以依据实际需要设定为任何一种方式,例如json格式类型或者xml格式类型等等。
上述代码覆盖率信息转换成的第一预设格式类型信息与该代码差异化信息转换成的第二预设格式类型可以相同也可以不同,通常情况下可设置为相同,以便于操作。
图14中示出了图13中所示的分析单元132134在一个具体示例中的结构示意图,如图14所示,在本实施例二中,上述分析单元132134具体可以包括:
统计信息获取单元132101,用于获取被测源代码的代码统计信息;
加载单元132102,用于加载上述代码差异化信息、代码覆盖率信息;
行读取单元132103,用于读取被测源代码中的各行;
变更行判定单元132104,根据上述代码差异化信息判断当前行是否为变更行;
覆盖行判定单元132105,用于根据上述代码覆盖率信息判断当前行是否为覆盖行;
可执行行判定单元132106,用于根据上述代码统计信息判定当前行是否为可执行行;
样式设置单元132107,用于在变更行判定单元132104判定当前行为变更行时,将当前行的样式设置为变更样式,在变更行判定单元132104判定当前行不是变更行时,将当前行的样式设置为非变更样式,在覆盖行判定单元132105判定当前行是覆盖行、可执行行判定单元132106判定当前行是可执行行时,将当前行的样式设置为覆盖样式,在覆盖行判定单元132105判定当前行不是覆盖行、可执行行判定单元132106判定当前行是可执行行时,将该当前行的样式设置为未覆盖样式,在可执行行判定单元132106判定当前行不是可执行行时,将该当前行的样式设置为普通样式。
在对代码差异化信息、代码覆盖率信息进行分析时,对变更行、覆盖行、可执行行的判定顺序不限,只要是能够将是变更行的源代码行的样式设置为变更样式、将不是变更行的源代码行的样式设置为未变更样式、将不是可执行行的源代码行的样式设置为普通样式、将是可执行行且是覆盖行的源代码行的样式设置为覆盖样式、将是可执行行且不是覆盖行的源代码行的样式设置为未覆盖样式即可。
上述代码统计信息,可以直接利用已经分析统计好的代码统计信息,也可以由图13中所示的代码信息统计单元13215进行分析统计,即本实施例中的代码测试信息收集系统,还可以包括代码信息统计单元13215,用于对上述被测源代码进行分析统计,获得上述代码统计信息。
该代码统计信息,可以是在收集代码差异化信息或者代码覆盖率信息的同时予以分析收集,对被测源代码进行分析统计、获得代码统计信息的方式可以采用现有技术中已有的方式,在此不予赘述。
本实施例四中的代码测试信息收集系统的其他技术特征,与上述实施例二中的代码测试信息收集系统中的相同,具体的代码测试信息的收集方法与上述本发明代码测试信息收集方法实施例四中的相同,在此不予赘述。
以上所述实施例仅表达了本发明的几种实施方式,其描述较为具体和详细,但并不能因此而理解为对本发明专利范围的限制。应当指出的是,对于本领域的普通技术人员来说,在不脱离本发明构思的前提下,还可以做出若干变形和改进,这些都属于本发明的保护范围。因此,本发明专利的保护范围应以所附权利要求为准。