自动化测试方法、装置、电子设备及存储介质与流程

1.本发明涉及软件测试技术领域，尤其涉及自动化测试方法、装置、电子设备及存储介质。


背景技术：

2.由于自动化测试框架因支持关键因素不同而有所区别，因而在测试过程中，可能因使用的语言，和/或基础框架不一致，会导致后期维护的困难增加。
3.现有技术中利用线性脚本编写代码，缺点明显，例如：测试的输入和断言都是捆绑在脚本中，易读性差；无共享或重用脚本，可复用性低；线性脚本修改代价大，维护成本高，不便于后期优化；容易受软件变化的影响或容易受意外事件的影响，引起整个测试失败等。


技术实现要素：

4.为了解决上述提出的至少一个技术问题，本发明提供一种自动化测试方法、装置、处理器、电子设备及存储介质。
5.第一方面，提供了一种自动化测试方法，所述方法包括：从测试用例中心中获取测试用例；通过批量或单点运行所述测试用例，对待测系统中相应的待测产品进行测试并返回结果；其中，所述用例中心的测试用例与所述待测系统中的产品、模块和接口一一映射；对所述结果进行断言处理，以确定对所述测试用例的测试结果。
6.在该方面中，通过将所述用例中心的测试用例与所述待测系统中的产品、模块和接口一一映射，提高了对测试用例的调用效率，同时，由于定义了测试用例中心，并对待测系统进行抽象化，能够从测试用例中心获取测试用例，统一发送请求给待测系统进行相应的产品测试，并由待测系统返回结果，进行断言处理，形成高内聚低耦合的设计模式。
7.在一种可能实现的方式中，在从测试用例中心中获取测试用例之前，还包括：根据测试用例中心定义的测试代码的组织结构，以及待测系统的产品、模块和接口的设计结构，通过引用公共函数和工具集的方式，生成相应的测试用例；对所述测试用例进行调试。
8.在该种可能实现的方式中，通过测试用例中心定义的测试代码的组织结构，统一的测试用例的规范，通过引用公共函数和工具集的方式来生成相应的测试用例，能够积累工具，并将通用的函数提取封装，高复用相似代码，避免重复造轮子，化解了冗余。
9.在又一种可能实现的方式中，所述对所述测试用例进行调试，包括：对所述测试用例进行单点调试。
10.在该种可能实现的方式中，实现了单点调试，针对每个case进行debug。
11.在又一种可能实现的方式中，在所述对所述测试用例进行调试之前，还包括：分离所述测试用例对应的测试数据和测试脚本，并在生成相应的测试用例之后，获取调试所述测试用例所需的测试场景及相应的测试数据。
12.在该种可能实现的方式中，通过分离所述测试用例对应的测试数据和测试脚本，降低维护成本，提高可移植性，实现了测试只需要关注业务逻辑的脚本编写，高效使用已封
装的公共方法提供的便捷服务。
13.在又一种可能实现的方式中，所述公共函数，为将生成测试用例所需的函数、方法以及通用操作进行封装所得。
14.在该种可能实现的方式中，通过公共函数封装，将通用的函数提取封装，高复用相似代码，避免重复造轮子。
15.在又一种可能实现的方式中，在所述通过批量或单点运行所述测试用例，对待测系统中相应的待测产品进行测试并返回结果之前，还包括：基于预设的配置信息，设置运行环境并部署待测系统；其中，所述配置信息包括不同环境的配置信息，以及不同产品之间的配置信息。
16.在该种可能实现的方式中，通过统一配置，提高了不同环境的配置信息，以及不同产品之间的配置信息的配置效率，同时保证了测试过程的维护和协同的准确性。
17.在又一种可能实现的方式中，在对所述结果进行断言处理，以确定对所述测试用例的测试结果之后，还包括：根据所述测试结果，生成相应的日志信息并上报至日志中心。
18.在该种可能实现的方式中，统一日志中心，用于记录和管理日志，针对不同情况，能够通过设置不同的日志级别，方便定位问题。
19.第二方面，提供了一种自动化测试装置，所述装置包括：获取单元，用于从测试用例中心中获取测试用例；第一处理单元，用于通过批量或单点运行所述测试用例，对待测系统中相应的待测产品进行测试并返回结果；其中，所述用例中心的测试用例与所述待测系统中的产品、模块和接口一一映射；第二处理单元，用于对所述结果进行断言处理，以确定对所述测试用例的测试结果。
20.在一种可能实现的方式中，所述装置，还包括：生成单元，用于根据测试用例中心定义的测试代码的组织结构，以及待测系统的产品、模块和接口的设计结构，通过引用公共函数和工具集的方式，生成相应的测试用例；调试单元，用于对所述测试用例进行调试。
21.在又一种可能实现的方式中，所述装置还包括：第三处理单元，用于分离所述测试用例对应的测试数据和测试脚本，并在生成相应的测试用例之后，获取调试所述测试用例所需的测试场景及相应的测试数据。
22.在又一种可能实现的方式中，所述装置还包括：配置单元，用于基于预设的配置信息，设置运行环境并部署待测系统；其中，所述配置信息包括不同环境的配置信息，以及不同产品之间的配置信息。
23.在又一种可能实现的方式中，所述装置还包括：日志单元，用于根据所述测试结果，生成相应的日志信息并上报至日志中心，其中，所述测试结果以测试报告的形式呈现。
24.第三方面，提供了一种处理器，所述处理器用于执行如上述第一方面及其任意一种可能实现的方式的方法。
25.第四方面，提供了一种电子设备，包括：处理器、发送装置、输入装置、输出装置和存储器，所述存储器用于存储计算机程序代码，所述计算机程序代码包括计算机指令，当所述处理器执行所述计算机指令时，所述电子设备执行如上述第一方面及其任意一种可能实现的方式的方法。
26.第五方面，提供了一种计算机可读存储介质，所述计算机可读存储介质中存储有计算机程序，所述计算机程序包括程序指令，所述程序指令当被电子设备的处理器执行时，
使所述处理器执行如上述第一方面及其任意一种可能实现的方式的方法。
27.应当理解的是，以上的一般描述和后文的细节描述仅是示例性和解释性的，而非限制本公开。
附图说明
28.为了更清楚地说明本技术实施例或背景技术中的技术方案，下面将对本技术实施例或背景技术中所需要使用的附图进行说明。
29.此处的附图被并入说明书中并构成本说明书的一部分，这些附图示出了符合本公开的实施例，并与说明书一起用于说明本公开的技术方案。
30.图1为本技术实施例提供的一种自动化测试方法的流程示意图；
31.图2为本技术实施例提供的另一种自动化测试方法的流程示意图；
32.图3为本技术实施例提供的另一种自动化测试方法的流程示意图；
33.图4为本技术实施例提供的一种自动化测试装置的结构示意图；
34.图5为本技术实施例提供的另一种自动化测试装置的结构示意图；
35.图6为本技术实施例提供的一种自动化测试装置的硬件结构示意图。
具体实施方式
36.为了使本技术领域的人员更好地理解本技术方案，下面将结合本技术实施例中的附图，对本技术实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本技术一部分实施例，而不是全部的实施例。基于本技术中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本技术保护的范围。
37.本技术的说明书和权利要求书及上述附图中的术语“第一”、“第二”等是用于区别不同对象，而不是用于描述特定顺序。此外，术语“包括”和“具有”以及它们任何变形，意图在于覆盖不排他的包含。例如包含了一系列步骤或单元的过程、方法、系统、产品或设备没有限定于已列出的步骤或单元，而是可选地还包括没有列出的步骤或单元，或可选地还包括对于这些过程、方法、产品或设备固有的其他步骤或单元。
38.本文中术语“和/或”，仅仅是一种描述关联对象的关联关系，表示可以存在三种关系，例如，a和/或b，可以表示：单独存在a，同时存在a和b，单独存在b这三种情况。另外，本文中术语“至少一种”表示多种中的任意一种或多种中的至少两种的任意组合，例如，包括a、b、c中的至少一种，可以表示包括从a、b和c构成的集合中选择的任意一个或多个元素。
39.在本文中提及“实施例”意味着，结合实施例描述的特定特征、结构或特性可以包含在本技术的至少一个实施例中。在说明书中的各个位置出现该短语并不一定均是指相同的实施例，也不是与其它实施例互斥的独立的或备选的实施例。本领域技术人员显式地和隐式地理解的是，本文所描述的实施例可以与其它实施例相结合。
40.另外，为了更好地说明本发明，在下文的具体实施方式中给出了众多的具体细节。本领域技术人员应当理解，没有某些具体细节，本发明同样能够实施。在一些实例中，对于本领域技术人员熟知的方法、手段、元件和电路未作详细描述，以便于凸显本发明的主旨。
41.目前的自动化测试框架可能因支持不同的关键因素(如可重用性，易维护性等)而有所不同，而且每个成员写的自动化测试代码，都是自己去实现的方法，这就产生了混乱。
以及使用的语言，基础框架不一致的问题，维护起来困难，难以为继。
42.当前很多人在使用线性脚本编写代码，线性脚本的缺点明显，测试的输入和断言都是捆绑在脚本中，易读性差。无共享或重用脚本，可复用性低。线性脚本修改代价大，维护成本高，不便于后期优化。容易受软件变化的影响，容易受意外事件的影响，引起整个测试失败。
43.现有技术中也存在部分使用数据驱动的框架，这个框架也存在着相应的弊端，该框架仅仅是将测试数据从测试脚本中分离出来，解决了混沌的第一步，但任何被测试程序的变更都可能导致维护的工作量变大，使得维护成本增加。
44.而应用本技术实施例提供的技术方案，统一了标准的测试框架，能够实现高内聚低耦合的自动化测试，并提高了自动化测试的效率。
45.请参阅图1，图1为本技术实施例(一)提供的一种自动化测试方法的流程示意图。
46.s101、从测试用例中心中获取测试用例。
47.测试用例是指对一项特定的软件产品进行测试任务的描述，体现测试方案、方法、技术和策略。其内容包括测试目标、测试环境、输入数据、测试步骤、预期结果、测试脚本等，最终形成文档。简单地认为，测试用例是为某个特殊目标而编制的一组测试输入、执行条件以及预期结果，用于核实是否满足某个特定软件需求。
48.在本实施例中，测试用例，是在测试过程中很重要的一类文档，它是测试工作的核心、是一组在测试时输入输出的标准、是软件需求的具体对照。测试用例，用于检验软件是否满足客户需求、体现一个测试人员的工作量、展现测试用例的设计思路。测试用例所包含的内容包括用例编号、用例名称、测试背景、前置条件、优先级、重要级、测试数据、测试步骤、预期结果、实际结果、备注。测试用例的编写过程包括需求分析、提取测试点、测试用例编写、测试用例评审。
49.其中，需求分析是指客户需要的东西以及对东西的要求，需求的种类包括业务需求(关注系统是否满足业务要求)、用户需求(关注系统是否满足用户习惯)和功能需求(关注系统是否满足功能要求)。
50.测试用例中心被设计为能够对测试用例进行有效的管理，并提供使用一套标准的测试框架，如：pytest，以解决测试用例脚本编写过程中不规范难以阅读，脚本混乱不可维护，易用性差等问题。可以理解的是，测试用例中心的测试用例为根据具体接口设计好的测试用例，在自动化测试过程中可直接调用。
51.在本实施例中，由于测试用例数目巨大、测试用例会根据需求的改变而改变，以及测试用例需要补充完善，因此需要对测试用例管理进行有效的管理。对于如何管理测试用例，可以采用原始的excel进行管理，也可以进行专业的项目管理系统(eg：alm、禅道、testlink、bugzilla、jira)一般都为web格式等。
52.s102、通过批量或单点运行所述测试用例，对待测系统中相应的待测产品进行测试并返回结果。其中，所述用例中心的测试用例与所述待测系统中的产品、模块和接口一一映射。
53.在本实施例中，在执行测试用例的主程序或者批量执行测试用例的主程序时，统一向待测系统发送测试请求，对待测系统中相应的待测产品进行测试并返回结果。
54.可以理解的是，如果多个测试用例在不同的类中，又需要一次性执行完所有的测
试用例，则可以使用一些批量执行的测试方法。
55.批量运行测试用例的方法，如run.py、run.bat、run.sh、shell脚本。其中，run.py运行方式：新建一个run.py通过在命令行运行python run.py执行。其中，run.bat运行方式：在win系统下建一个run.bat批处理文件，通过双击该文件执行。或者，在linux系统构建run.sh。或者在jenkins环境下构建shell脚本运行指令。
56.在本实施例中，通过将所述用例中心的测试用例与所述待测系统中的产品、模块和接口一一映射，能够更加高效地分析测试目标与执行测试，也提高了对测试用例的调用效率。同时，由于定义了测试用例中心，并对待测系统进行抽象化，能够从测试用例中心获取测试用例，统一发送请求给待测系统进行相应的产品测试，并由待测系统返回结果，进行断言处理，形成高内聚低耦合的设计模式。
57.s103、对所述结果进行断言处理，以确定对所述测试用例的测试结果。
58.程序一般分为debug版本和release版本，debug版本用于内部调试，release版本发行给用户使用。断言assert是仅在debug版本起作用的宏，它用于检查“不应该”发生的情况。因此，在程序设计中，断言是一种放在程序中的一阶逻辑，目的是为了标示与验证程序开发者预期的结果。当程序运行到断言的位置时，对应的断言应该为真。若断言不为真时，程序会中止运行，并给出错误消息。
59.可以理解的是，在防御式编程中经常会用断言对参数和环境做出判断，避免程序因不当的输入或错误的环境而产生逻辑异常，断言在很多语言中都存在，c、c++、python都有不同的断言表示形式。
60.请参阅图2，图2是本技术实施例(二)提供的另一种自动化测试方法的流程示意图。
61.s104、根据所述测试结果，生成相应的日志信息并上报至日志中心。
62.对运维人员来说，无论管理什么系统，对日志信息或者日志文件的监控、调用、管理都是其中重要的一部分。例如，服务器问题的解决都是从查看系统(错误)日志开始的。系统日志是记录系统硬件检查、内核动作、软件启动、用户动作等各项信息的文件。通过系统日志可以判断系统健康状态、检测系统问题、查找攻击证据等。
63.测试结果以“report”测试报告的形式呈现。统一日志中心，用于记录和管理日志，并针对不同情况，能够通过设置不同的日志级别，方便定位问题。
64.其中，对于设置日志级别，如可设置：“debug”表示一般的调试信息；“info”表示基本通知信息；“notice”表示普通的注意信息；“warning”表示一般警告信息，目前对系统运行没有影响但以后可能出现问题；“err”表示错误信息，可能影响一部分系统功能；“crit critical”表示致命错误，较错误信息更加严重；“alert”警告状态信息，如果不处理可能造成系统损坏；“emerg”表示系统无法使用；另外，“.none”表示不记录日志，一般在排除情况下使用。
65.为了统一日志中心，确定一套适用于微服务架构的日志管理流程，例如：
66.日志选取，确定选择哪些日志记录分析。
67.日志采集，filebeat轻巧做收集。filebeat和应用是挂钩的，需要知道针对每个落点去收集日志信息。filebeat会有一个或者多个的叫做prospector的探测器，可以实时监听指定的文件或者制定的文件目录的变更状况，将变更状况及时的传递到下一层——
spooler处理。通过filebeat动态的将新增的日志进行及时存储取样。
68.日志缓冲，kafka缓存本地做缓冲。在日志存储之前，引入组件kafka，作为日志缓冲层的优点，包括：吞吐量大，一个topic可以拆分为多个partition；分布式系统易拓展；kafka的性能主要取决于它对磁盘的连续读写，它的性能很大程度上是取决于磁盘处理的能力，即只要磁盘性能允许，它可以无限制的接收来自filebeat的日志信息，从而实现一个缓冲的作用。
69.日志筛选，logstash筛选过滤。日志信息经过filebeat、kafka等工具的收集传递，给日志事件加了很多附加信息。利用logstash实现二次处理，可在filter里进行过滤或处理。在filebeat收集信息的时候通过将同一个server上的日志信息发送到同一个kafka的topic中来实现日志的汇总，这个topic名称就是server的关键信息。在更细粒度的层面上将每一个app的信息都当作一个topic来进行汇总。kafka中通过filebeat接受到的日志信息中包含了一个标识——日志是从哪里来的。logstash的作用就是在日志汇入es之前，通过标识将对应的日志信息进行二次筛选汇总处理，输送给es，为之后的搜索提供依据，方便确定定位来源。
70.日志存储，elasticsearch建索引入库。选用elasticsearch的原因主要为：可分布式的部署，方便拓展；处理海量数据可以应对多种需求；强大的搜索功能，基于lucene可以实现快速搜索；活跃的开发社区，资料多、上手简单。
71.日志检索，利用elasticsearch本身的检索功能。elasticsearch本身就是一个强大的搜索引擎，支持通过系统、应用、应用实例分组、应用实例ip、关键字、日志级别、时间区间来检索所需要的日志信息。
72.日志展现，参考kibana风格实现日志数据可视化。通过精简提炼日志信息，对日志信息进行整合分析，以图表的形式将日志信息进行展示。在展示的过程中借鉴和吸收kibana在日志可视化方面的努力，实现日志的可视化处理，只需通过简单的配置就可以看到对某一个服务或者某一个应用的清晰的可视化的日志分析结果。
73.请参阅图3，图3是本技术实施例(三)提供的另一种自动化测试方法的流程示意图。
74.在一种可能实现的方式中，在步骤s101、从测试用例中心中获取测试用例之前所述自动化测试方法之前，所述自动化测试方法还包括：根据测试用例中心定义的测试代码的组织结构，以及待测系统的产品、模块和接口的设计结构，通过引用公共函数和工具集的方式，生成相应的测试用例；对所述测试用例进行调试。
75.在本实施例中，通过测试用例中心定义的测试代码的组织结构，统一的测试用例的规范，通过引用公共函数和工具集的方式来生成相应的测试用例，能够积累工具，并将通用的函数提取封装，高复用相似代码，避免重复造轮子，化解了冗余。
76.具体的，在自动化测试方法实施过程中，可以将如下标准进行统一化：
77.1.统一case(测试用例)规范。根据按照实际产品做模块划分，按照业务规范命名，统一了测试代码的组织结构。测试方法命名，项目(英文)_模块(英文)_子模块(英文)为包名路径，采用modulename_expectedbehavior_understatetest，驼峰命名方式。说明modulename:模块名称；expectedbehavior：期望的行为，结果；stateundertest：描述前提条件状态。
78.2.统一测试报告模式。采用allure插件，统一测试报告模式。
79.3.统一目录结构。base_api.py：对requests库进行二次封装，完成对api的驱动；api：继承base_api，将http请求接口封装成python方法；utils：commonutil，公共函数，将一些通用函数、方法以及通用操作进行封装，如：日志模块、yaml操作模块、时间模块；config：配置中心，或配置文件模块，配置信息存放，如：url、port、headers、token、数据库信息等；data：数据中心，或测试数据模块，用于测试数据的管理，数据与脚本分离，降低维护成本，提高可移植性，如：yml文件数据；cases中心：测试用例模块，用于测试用例的管理，这里会用到测试框架，如：pytest；run.py：运行，批量执行测试用例的主程序，根据不同需求不同场景进行组装，遵循框架的灵活性和扩展性；logs：日志中心，或日志模块，用于记录和管理日志，针对不同情况，设置不同的日志级别，方便定位问题；reports：测试报告模块，用于测试报告的生成和管理。
80.4.统一封装公共方法。将一些通用函数、方法以及通用操作进行封装。如：上传文件，数据库链接与关闭，获取redis数据等。
81.在一种可能实现的方式中，在所述自动化测试方法中，所述对所述测试用例进行调试，可以是对所述测试用例进行单点调试。
82.通过公共函数封装，将通用的函数提取封装，高复用相似代码，避免重复造轮子，节约了人力，化解了冗余。通过积累工具模块，如token生成，时间模块，读取配置文件方法，文件上传等工具，高可用的减少重复代码。继而能够实现单点调试，针对每个case进行debug。
83.在一种可能实现的方式中，所述自动化测试方法还包括：分离所述测试用例对应的测试数据和测试脚本；并在生成相应的测试用例之后，获取调试所述测试用例所需的测试场景及相应的测试数据。
84.现有技术中，通常会使用线性脚本编写代码，但是线性脚本的缺点明显，测试的输入和断言都是捆绑在脚本中，易读性差。无共享或重用脚本，可复用性低。线性脚本修改代价大，维护成本高，不便于后期优化。容易受软件变化的影响，容易受意外事件的影响，引起整个测试失败。
85.可以理解的是，在测试一个函数时需要编写测试用例并断言，通过框架及相关方法来进行测试，这样做会产生一个问题，对于一个庞大的软件、游戏而言，可能会有上万条测试用例，如果数据与代码存在绑定关系，很明显会有很多弊端，例如查询、更改测试数据等，这意味着代码和测试数据将会一起进行维护，维护成本会随着时间以及数量不断的增加，且有互相依赖性。故此，需要把数据与代码区分开来，那么分开的这个过程和结果，称之为数据分离，进行单独性的管理。而测试用例的数据分离，就是将用例数据与代码区分开的意思。如果测试数据需要进行修改或添加，那么我们只需要维护测试数据即可，而测试用例是不需要进行改动的。测试数据和代码实现分离，这样当进行测试数据维护或代码维护时就会更加便捷。
86.因此，在本实施例中，通过分离所述测试用例对应的测试数据和测试脚本，降低维护成本，提高可移植性，实现了测试只需要关注业务逻辑的脚本编写，高效使用已封装的公共方法提供的便捷服务。
87.在一种可能实现的方式中，所述公共函数，为将生成测试用例所需的函数、方法以
及通用操作进行封装所得。
88.在做接口自动化过程中会把获取token的方法定义公共函数去调用。在本实施例中，以python公共方法及公共函数为例。
89.对于公共方法：
90.1.“+”：加法运算适用于所有的基础数据类型(int float bool)；加法运算所有两侧要是同种数据类型；加法运算再容器类型中是拼接的意思，不是相加计算值。
91.2.“*”：基础数据类型(int float bool)都可以进行乘法运算；容器类型只能和int类型数据进行乘法运算；容器类型进行乘法运算，就是将容器复制指定次数，并进行拼接。
92.3.“in”和“not in”：判断元素是否在数据序列当中；字符串，列表，元组，集合，字典都可以使用。
93.4.切片：通过切片按照规则获取数据序列中的一部分元素；tuple list str可以使用切片；dict set不可以使用切片。
94.对于公共函数：
95.1.“len”：获取容器内元素个数。
96.2.“del”：删除容器内元素。
97.3.“max”：获取容器内数据的最大值。
98.4.“min”：获取容器内元素的最小值。
99.5.“enumerate”：获取容器内元素时可以携带序号。
100.6.“range”：根据一定规则获取整数序列。
101.在本实施例中，通过公共函数封装，将通用的函数提取封装，高复用相似代码，避免重复造轮子。
102.在一种可能实现的方式中，所述自动化测试方法，在所述通过批量或单点运行所述测试用例，对待测系统中相应的待测产品进行测试并返回结果之前，还包括：
103.基于配置中心预设的配置信息，设置运行环境(抽象环境)并通过环境中心部署待测系统；其中，所述配置信息包括不同环境的配置信息，以及不同产品之间的配置信息。
104.如果微服务架构中没有使用统一配置中心时，所存在的问题：配置文件分散在各个项目里，不方便维护；配置内容安全与权限；更新配置后，项目需要重启。
105.在该实施例中，以nacos作为配置中心：系统配置的集中管理(编辑、存储、分发)、动态更新不重启、回滚配置(变更管理、历史版本管理、变更审计)等所有与配置相关的活动。
106.具体的，以nacos作为配置中心，如何实现不同环境(开发、测试、灰度、正式)的配置管理：
107.1、用命名空间(namespace)来区分不同的环境，一个命名空间对应一个环境；
108.2、用配置组(group)来区分不同的环境，命名空间用默认的public即可，一个组对应一种环境；
109.3、用配置集id(data id)名称来区分不同的环境，命名空间和组用默认的即可，通过文件命名来区分。
110.可以理解的是，上述不同环境包括生产环境、测试环境、开发环境，以及其他环境。
开发环境是指，开发环境时专门用于开发的服务器，配置要求较低，为了开发调试方便，一般打开全部错误报告和测试工具，是最基础的环境。测试环境是指，一般是克隆一份生产环境的配置，一个程序在测试环境工作不正常，则不能把它发布到生产服务器上，是开发环境到生产环境的过度环境。生产环境是指，生产环境是指正式提供对外服务的，一般会关掉错误报告，打开错误日志，是最重要的环境。上述不同环境也可以理解为系统开发的三个阶段：开发-》测试-》上线，其中，生产环境也就是通产说的真实的环境，最后交给用户的环境。简单来说，开发环境就是开发人员在开发联调时比如前后端交互的本地环境，一般在本地开发完成后会将代码部署到测试环境，也就是提交测试。
111.在该实施例中，通过统一配置，提高了不同环境的配置信息，以及不同产品之间的配置信息的配置效率，同时保证了测试过程的维护和协同的准确性。
112.在上述实施例中，基于一套标准的测试框架，能够解决用例脚本编写过程中不规范难以阅读，脚本混乱不可维护，易用性差，维护和运行成本高，以及待测系统变更导致修改代价大的问题。
113.本领域技术人员可以理解，在具体实施方式的上述方法中，各步骤的撰写顺序并不意味着严格的执行顺序而对实施过程构成任何限定，各步骤的具体执行顺序应当以其功能和可能的内在逻辑确定。
114.上述详细阐述了本技术实施例的方法，下面提供了本技术实施例的装置。
115.请参阅图4，图4为本技术实施例提供的一种自动化测试装置的结构示意图。一种自动化测试装置，包括：获取单元100、第一处理单元200和第二处理单元300。
116.获取单元100，用于从测试用例中心中获取测试用例；
117.第一处理单元200，用于通过批量或单点运行所述测试用例，对待测系统中相应的待测产品进行测试并返回结果；其中，所述用例中心的测试用例与所述待测系统中的产品、模块和接口一一映射；
118.第二处理单元300，用于对所述结果进行断言处理，以确定对所述测试用例的测试结果。
119.请参阅图5，图5为本技术实施例提供的另一种自动化测试装置的结构示意图。
120.在一种可能实现的方式中，所述自动化测试装置，还包括：
121.生成单元400，用于根据测试用例中心定义的测试代码的组织结构，以及待测系统的产品、模块和接口的设计结构，通过引用公共函数和工具集的方式，生成相应的测试用例；
122.调试单元500，用于对所述测试用例进行调试。
123.在又一种可能实现的方式中，所述自动化测试装置，还包括：
124.第三处理单元600，用于分离所述测试用例对应的测试数据和测试脚本，并在生成相应的测试用例之后，获取调试所述测试用例所需的测试场景及相应的测试数据。
125.在又一种可能实现的方式中，所述自动化测试装置，还包括：
126.配置单元700，用于基于预设的配置信息，设置运行环境并部署待测系统；其中，所述配置信息包括不同环境的配置信息，以及不同产品之间的配置信息。
127.在又一种可能实现的方式中，所述自动化测试装置，还包括：
128.日志单元800，用于根据所述测试结果，生成相应的日志信息并上报至日志中心，
其中，所述测试结果以测试报告的形式呈现。
129.本实施例通过将所述用例中心的测试用例与所述待测系统中的产品、模块和接口一一映射，提高了对测试用例的调用效率，同时，由于定义了测试用例中心，并对待测系统进行抽象化，能够从测试用例中心获取测试用例，统一发送请求给待测系统进行相应的产品测试，并由待测系统返回结果，进行断言处理，形成高内聚低耦合的设计模式。通过测试用例中心定义的测试代码的组织结构，统一的测试用例的规范，通过引用公共函数和工具集的方式来生成相应的测试用例，能够积累工具，并将通用的函数提取封装，高复用相似代码，避免重复造轮子，化解了冗余。通过分离所述测试用例对应的测试数据和测试脚本，降低维护成本，提高可移植性，实现了测试只需要关注业务逻辑的脚本编写，高效使用已封装的公共方法提供的便捷服务。
130.在一些实施例中，本公开实施例提供的装置具有的功能或包含的模块可以用于执行上文方法实施例描述的方法，其具体实现可以参照上文方法实施例的描述，为了简洁，这里不再赘述。
131.本技术还提供了一种处理器，所述处理器用于执行如上述任意一种可能实现的方式的方法。
132.本技术还提供了一种电子设备，包括：处理器、发送装置、输入装置、输出装置和存储器，所述存储器用于存储计算机程序代码，所述计算机程序代码包括计算机指令，当所述处理器执行所述计算机指令时，所述电子设备执行如上述任意一种可能实现的方式的方法。
133.本技术还提供了一种计算机可读存储介质，所述计算机可读存储介质中存储有计算机程序，所述计算机程序包括程序指令，所述程序指令当被电子设备的处理器执行时，使所述处理器执行如上述任意一种可能实现的方式的方法。
134.请参阅图6，图6为本技术实施例提供的一种自动化测试装置的硬件结构示意图。
135.该自动化测试装置2包括处理器21，存储器22，输入装置23，输出装置24。该处理器21、存储器22、输入装置23和输出装置24通过连接器相耦合，该连接器包括各类接口、传输线或总线等等，本技术实施例对此不作限定。应当理解，本技术的各个实施例中，耦合是指通过特定方式的相互联系，包括直接相连或者通过其他设备间接相连，例如可以通过各类接口、传输线、总线等相连。
136.处理器21可以是一个或多个图形处理器(graphics processing unit，gpu)，在处理器21是一个gpu的情况下，该gpu可以是单核gpu，也可以是多核gpu。可选的，处理器21可以是多个gpu构成的处理器组，多个处理器之间通过一个或多个总线彼此耦合。可选的，该处理器还可以为其他类型的处理器等等，本技术实施例不作限定。
137.存储器22可用于存储计算机程序指令，以及用于执行本技术方案的程序代码在内的各类计算机程序代码。可选地，存储器包括但不限于是随机存储记忆体(random access memory，ram)、只读存储器(read-only memory，rom)、可擦除可编程只读存储器(erasable programmable read only memory，eprom)、或便携式只读存储器(compact disc read-only memory，cd-rom)，该存储器用于相关指令及数据。
138.输入装置23用于输入数据和/或信号，以及输出装置24用于输出数据和/或信号。输出装置23和输入装置24可以是独立的器件，也可以是一个整体的器件。
disc，dvd))、或者半导体介质(例如固态硬盘(solid state disk，ssd))等。
147.本领域普通技术人员可以理解实现上述实施例方法中的全部或部分流程，该流程可以由计算机程序来指令相关的硬件完成，该程序可存储于计算机可读取存储介质中，该程序在执行时，可包括如上述各方法实施例的流程。而前述的存储介质包括：只读存储器(read-only memory，rom)或随机存储存储器(random access memory，ram)、磁碟或者光盘等各种可存储程序代码的介质。

技术特征：
1.一种自动化测试方法，其特征在于，所述方法包括：从测试用例中心中获取测试用例；通过批量或单点运行所述测试用例，对待测系统中相应的待测产品进行测试并返回结果；其中，所述用例中心的测试用例与所述待测系统中的产品、模块和接口一一映射；对所述结果进行断言处理，以确定对所述测试用例的测试结果。2.根据权利要求1所述的方法，其特征在于，在从测试用例中心中获取测试用例之前，还包括：根据测试用例中心定义的测试代码的组织结构，以及待测系统的产品、模块和接口的设计结构，通过引用公共函数和工具集的方式，生成相应的测试用例；对所述测试用例进行调试。3.根据权利要求2所述的方法，其特征在于，所述对所述测试用例进行调试，包括：对所述测试用例进行单点调试。4.根据权利要求2或3所述的方法，其特征在于，所述方法还包括：分离所述测试用例对应的测试数据和测试脚本；并在生成相应的测试用例之后，获取调试所述测试用例所需的测试场景及相应的测试数据。5.根据权利要求2所述的方法，其特征在于，所述公共函数，为将生成测试用例所需的函数、方法以及通用操作进行封装所得。6.根据权利要求1所述的方法，其特征在于，在所述通过批量或单点运行所述测试用例，对待测系统中相应的待测产品进行测试并返回结果之前，还包括：基于预设的配置信息，设置运行环境并部署待测系统；其中，所述配置信息包括不同环境的配置信息，以及不同产品之间的配置信息。7.根据权利要求1所述的方法，其特征在于，在对所述结果进行断言处理，以确定对所述测试用例的测试结果之后，还包括：根据所述测试结果，生成相应的日志信息并上报至日志中心。8.一种自动化测试装置，其特征在于，所述装置包括：获取单元，用于从测试用例中心中获取测试用例；第一处理单元，用于通过批量或单点运行所述测试用例，对待测系统中相应的待测产品进行测试并返回结果；其中，所述用例中心的测试用例与所述待测系统中的产品、模块和接口一一映射；第二处理单元，用于对所述结果进行断言处理，以确定对所述测试用例的测试结果。9.一种电子设备，其特征在于，包括：处理器、发送装置、输入装置、输出装置和存储器，所述存储器用于存储计算机程序代码，所述计算机程序代码包括计算机指令，当所述处理器执行所述计算机指令时，所述电子设备执行如权利要求1至7中任一项所述的方法。10.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质中存储有计算机程序，所述计算机程序包括程序指令，所述程序指令当被电子设备的处理器执行时，使所述处理器执行权利要求1至7中任意一项所述的方法。

技术总结
本发明公开了自动化测试方法、装置、电子设备及存储介质。其中，所述方法包括：从测试用例中心中获取测试用例；通过批量或单点运行所述测试用例，对待测系统中相应的待测产品进行测试并返回结果；其中，所述用例中心的测试用例与所述待测系统中的产品、模块和接口一一映射；对所述结果进行断言处理，以确定对所述测试用例的测试结果。本发明统一了标准的测试框架，能够实现高内聚低耦合的自动化测试，并提高了自动化测试的效率。高了自动化测试的效率。高了自动化测试的效率。


技术研发人员：罗伟东 廖翼
受保护的技术使用者：深圳市和讯华谷信息技术有限公司
技术研发日：2023.03.02
技术公布日：2023/7/19