An automated testing method, device and storage medium based on Kubernetes

Abstract

The present application discloses an automated testing method, device and storage medium based on Kubernetes, the method comprising: using a server to send a container creation request to a master node, so that the master node creates a container group based on a configuration file, wherein the container group includes a virtual device container and an automated test container; using a virtual device container to download firmware related to the virtual device to start the virtual device; using an automated test container to enable the virtual device to execute a test case and generate a test report. In the above manner, the present application can generate a test report, which is convenient for testers to view.

Description

Technical Field

[0001] The present application relates to the field of testing technology, and in particular to an automated testing method, device, and storage medium based on Kubernetes. Background Art

[0002] Currently, the new version of the Internet of Things (IoT) firmware needs to be burned into the development board, and then the tester will test the IoT firmware according to the test case. The test case coverage is small, the cost is high, and it is impossible to test devices in other regions (such as the United States or Europe). The new Software Defined Packet Transport Network (SPTN) network architecture is to abstract the hardware of the network device so that it can be deployed on a virtual machine without relying on the hardware. Its purpose is to process data on the network. In fact, it is still a network device and cannot simulate the behavior of a real IoT device. Summary of the invention

[0003] The present application provides an automated testing method, device, and storage medium based on Kubernetes, which can generate test reports for easy viewing by testers.

[0004] To solve the above technical problems, the technical solution adopted in this application is: to provide an automated testing method based on Kubernetes, the method comprising: using a server to send a container creation request to a master node, so that the master node creates a container group based on a configuration file, wherein the container group includes a virtual device container and an automated testing container; using the virtual device container to download firmware related to the virtual device to start the virtual device; using the automated testing container to enable the virtual device to execute test cases and generate test reports.

[0005] To solve the above technical problems, another technical solution adopted in the present application is: to provide an automated testing device, which includes a memory and a processor connected to each other, wherein the memory is used to store a computer program, and when the computer program is executed by the processor, it is used to implement the Kubernetes-based automated testing method in the above technical solution.

[0006] To solve the above technical problems, another technical solution adopted in the present application is: providing a computer-readable storage medium, which is used to store a computer program. When the computer program is executed by a processor, it is used to implement the Kubernetes-based automated testing method in the above technical solution.

[0007] Through the above scheme, the beneficial effect of the present application is: the server can send the obtained container creation request to the main node. After receiving the container creation request, the main node creates a container group based on the obtained configuration file, and the container group includes a virtual device container and an automated test container; the virtual device container can download firmware related to the virtual device to start the virtual device; after the virtual device is successfully started, the automated test container can enable the virtual device to execute test cases, obtain test results and generate test reports. Since the test report is generated, it is convenient for testers to view it. BRIEF DESCRIPTION OF THE DRAWINGS

[0008] In order to more clearly illustrate the technical solutions in the embodiments of the present application, the following briefly introduces the drawings required for use in the description of the embodiments. Obviously, the drawings described below are only some embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without creative work. Among them:

[0009] Figure 1 This is a flow chart of an embodiment of an automated testing method based on Kubernetes provided by the present application;

[0010] Figure 2 This is an interactive schematic diagram of another embodiment of the automated testing method based on Kubernetes provided by the present application;

[0011] Figure 3 It is a structural diagram of the automated testing system provided by this application;

[0012] Figure 4 It is a structural schematic diagram of an embodiment of an automated testing device provided by the present application;

[0013] Figure 5 It is a structural schematic diagram of an embodiment of a computer-readable storage medium provided by the present application. DETAILED DESCRIPTION

[0014] The following will be combined with the drawings in the embodiments of the present application to clearly and completely describe the technical solutions in the embodiments of the present application. Obviously, the described embodiments are only part of the embodiments of the present application, not all of the embodiments. Based on the embodiments in the present application, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of this application.

[0015] See also Figure 1 , Figure 1 : is a flow chart of an embodiment of an automated testing method based on Kubernetes provided by the present application, the method comprising:

[0016] Step 11: Use the server to send a container creation request to the master node, so that the master node creates a container group based on the configuration file.

[0017] Kubernetes is an open source system for automatically deploying, scaling, and managing containerized applications. This implementation implements firmware testing based on Kubernetes. The server can send a request to create a container (i.e., a container creation request) to the master node. After receiving the container creation request, the master node can create a container group based on the obtained configuration file. The container group includes a virtual device container and an automated test container.

[0018] Furthermore, the server can use the obtained configuration parameters to generate a configuration file. The master node can be recorded as Kubernetes Master. Kubernetes Master starts the container group (referred to as Pod) through the configuration file sent by the server. The pod contains 2 containers, one container is used to deploy virtual devices, that is, it is a virtual device container, and the other container is used to deploy automated testing services, that is, it is an automated testing container.

[0019] Step 12: Use the virtual device container to download the firmware related to the virtual device to start the virtual device.

[0020] After the virtual device container is created, the virtual device container can download firmware from the server. The firmware is a program related to the virtual device to be tested and is used to start the virtual device. The firmware can import specifications of different categories and products according to the configuration file to realize the capabilities of various IoT devices.

[0021] A virtual device can be understood as an IoT operating system. Abstracting its hardware is only part of its function. More importantly, it can import specifications of different categories and products according to the configuration file to realize the capabilities of various IoT devices. Furthermore, different categories of virtual devices can be dynamically loaded according to the configuration file. If the configuration file of a smart light is loaded, the virtual device is a smart light. If the configuration file of a smart sweeper is loaded, the virtual device is a smart sweeper.

[0022] Step 13: Use the automated test container to enable the virtual device to execute test cases and generate test reports.

[0023] The server can send the test case to the automated test container in the specified container group. The automated test container can enable the virtual device to execute the test case. After executing the test case, the virtual device can generate corresponding test results and form a test report. The test report may include information about the test case and the test results corresponding to the test case.

[0024] The test method adopted in this embodiment can be applied to the field of automated IoT device testing. The existing solutions cannot truly simulate the behavior of an IoT device, such as: the network access behavior of the device, the issuance or reporting of device commands, etc. This embodiment can dynamically load virtual devices of different categories according to the configuration file; Due to the limitations of real devices, only small-scale tests can be performed on IoT devices at present, and a small number of individual performances on specific issues often cannot represent the characteristics of the group. This embodiment can deploy thousands of IoT devices to computer rooms in various regions around the world through Kubernetes to achieve large-scale testing; and currently due to environmental limitations, the logs of the device itself cannot be easily viewed. For testers, they can only analyze whether the use case is executed correctly based on the response of the device itself, and cannot really know whether the use case is executed normally; and using this solution, the virtual device can report the test report generated by the test to the server in real time, and the tester can intuitively view the execution status of each test case and obtain detailed information about the test.

[0025] See also Figure 2 , Figure 2 : is an interactive schematic diagram of another embodiment of the automated testing method based on Kubernetes provided by the present application, the method comprising:

[0026] Step 201: Utilize the front end to send a request to start a virtual device to the server, so that the server generates a configuration file based on the configuration parameters.

[0027] The front end can send a request to start the virtual device (i.e., a request to start the virtual device) to the server. After receiving the request to start the virtual device, the server can generate a configuration file based on the obtained configuration parameters. The configuration parameters include a universally unique identifier (UUID), an authentication key (Authkey), product data (PID) or binding information (token). The PID indicates the product information to be activated by the virtual device, such as a 5-way lamp or a 3-way socket, etc. The token indicates which user account the virtual device should be bound to so that the user can control the virtual device.

[0028] Furthermore, the front end provides a python library that can directly operate the application programming interface (API) of the software development kit (SDK) to obtain data or status inside the SDK; the front end can build firmware running on the Ubuntu system and upload it to the server.

[0029] Step 202: Utilize the server to send the configuration file to the master nodes in multiple communication areas.

[0030] Each communication area is set with a master node and at least one node connected to the master node. After generating the configuration file, the server can send the configuration file to the master node in each communication area; specifically, the server puts the UUID, Authkey, PID or token information required for virtual device activation into the configuration parameters of the startup container group, and sends it to the Kubernetes Master of several communication areas (for example: China, the United States, Europe or India).

[0031] Step 203: Use the master node to select a node from at least one node as the current node.

[0032] The request to start a virtual device includes region information, and each master node can be used to determine whether the region information is the same as the region to which the master node belongs; if the region information is the same as the region to which the master node belongs, it indicates that test deployment is required in the region, and the master node is recorded as the current master node. The current master node is used to select an idle node from at least one node connected to the current master node as the current node; if the region information is different from the region to which the master node belongs, it indicates that test deployment is not required in the region to which the master node belongs.

[0033] Step 204: Create a container group based on the container creation request using the current node.

[0034] After receiving the container creation request, the current node creates a container group, which includes a virtual device container and an automated test container.

[0035] Step 205: Use the virtual device container to download firmware related to the virtual device to start the virtual device.

[0036] Step 205 is the same as step 12 in the above embodiment and will not be described again.

[0037] Step 206: After the virtual device is started, the front end is used to send an interface test request to the server.

[0038] After the front end obtains the message that the virtual device is successfully started, it can send an interface test request to the server.

[0039] Step 207: Use the server to send the test case to the automated test container through the kubectl API.

[0040] After receiving the interface test request, the server can send the test case to the automated test container in the specified container group through the kubectl API.

[0041] Step 208: Use the server to send the automatic test container command to the master node, and use the master node to forward the automatic test container command to the current node, so that the current node forwards the automatic test container command to the automated test container.

[0042] After receiving the interface test request, the server generates an automatic test container command and sends it to the master node. The automatic test container command includes a use case or a use case script. After receiving the automatic test container command, the master node forwards the automatic test container command to the automated test container through the current node.

[0043] Step 209: parse the test case using the use case parsing engine, and send the parsed test case to the virtual device through the remote procedure call protocol interface, so that the virtual device executes the parsed test case to generate a test report.

[0044] The automated test container includes a use case parsing engine, which parses the test case and allows the virtual device to execute the test case through the Remote Procedure Call Protocol (RPC) interface. After the virtual device executes the test case, it can generate test results and form a test report. Furthermore, the use case parsing engine is responsible for parsing the test case and then allows the virtual device to perform the corresponding operation through the RPC interface. For example, a use case for adjusting the brightness of a light bulb includes multiple steps: first turn on the light bulb, then switch the mode of the light bulb, and then adjust the brightness. That is, the purpose of the use case parsing engine is to parse the test case into specific execution steps and then hand it over to the virtual device for execution.

[0045] Step 210: Use the automated test container to upload the test report to the server through the Fluent interface.

[0046] After generating the test report, the automated test container can upload the test report back to the server through the Fluent interface.

[0047] Step 211: After the server sends a request to restart the virtual device to the server, the server is used to delete the created container group and assemble a new configuration file based on the configuration parameters.

[0048] If you want to restart the virtual device, the front end can send a restart virtual device request to the server. After receiving the restart virtual device request, the server deletes the corresponding container group according to the group name of the created container group, and assembles a new configuration file based on the last UUID, Authkey, PID or Uniform Resource Locator (URL) to create a new container group. The subsequent operations are the same as the last time the virtual device was started, so they are not repeated here.

[0049] In a specific embodiment, Figure 3 As shown, the solution adopted in this embodiment includes multiple modules: a continuous integration (CI) platform 31, a test container 32, a test simulator 33, a cloud 34 and a management platform 35.

[0050] The CI platform 31 is responsible for the management of firmware, test cases and virtual devices. It can serve as a front end. The CI platform 31 can implement SDK automatic integration testing, build firmware, automate application container engine (Docker) deployment and automatically initiate testing services.

[0051] The test container 32 is a carrier for running firmware, which can be used as a virtual device; the test container 32 includes a universal test application, SDK, and hardware abstraction layer (HAL) connected in sequence, and the test container 32 can interact with the cloud 34 through message queuing telemetry transport (mqtt) / hypertext transfer protocol (HTTP). Specifically, the test container 32 is a Docker container used to run embedded Ubuntu products, and has the following capabilities:

[0052] 1) The configuration file can be read to determine the product, network, or region to be tested.

[0053] 2) Product information binding: Read PID, firmware key (KEY), UUID or Authkey from the configuration file, and the product form can be determined based on different information.

[0054] 3) Network information: bound interface or Internet Protocol (IP) address, etc.

[0055] 4) Regional information: token.

[0056] 5) With RPC capability, you can add an RPC encapsulation component, which encapsulates the interface provided by the SDK one by one. As a service provider, you can receive messages from the client, decode and call the interface.

[0057] 6) Provides additional interfaces for obtaining internal status.

[0058] The test simulator 33 is used to parse test cases and communicate with virtual devices through RPC protocol or LAN protocol. Specifically, the test simulator 33 includes a cloud operation library, an application (Application, App) library, a shadow device and a test framework (Test Framework). The test framework interacts with the cloud 34 operation library, APP library and shadow device. The shadow device includes an API and a virtual driver (Driver). The API interacts with the test container 32 through the RPC interface, and the driver interacts with the test container 32 through the docking protocol interface; the test simulator 33 can interact with the CI platform 31 and the cloud 34 through the http interface. At the same time, the test framework has its own environment configuration capabilities, such as: network interface or routing, etc., which are used to simulate the network environment. Behavior such as successful networking or disconnection.

[0059] Furthermore, the RPC interface is divided into two parts. The core is the CI RPC component. In the SDK, a description file is generated for the interface provided by each component to the outside world. The RPC interface is written and generated based on the description file. The RPC interface includes a C interface and a Python interface. The C interface is used for baseline processing of RPC requests, and the Python interface is used to provide it to the test framework for calling.

[0060] The virtual driver is the default driver provided after the HAL layer is cut. It is mainly used in the Ubuntu environment to provide some low-level operations to ensure the normal operation of the device. It can simulate communications, such as serial port docking, to simulate production testing, burning or authorization operations, and can also be expanded. When the virtual firmware is moved to the real environment, it can also run normally.

[0061] The management platform 35 may be used to manage the generated test reports, tasks, and use cases. The management platform 35 may interact with the test simulator 33 and the CI platform 31 to receive test tasks or send use cases to the test simulator 33 .

[0062] The orchestration technology used in this embodiment is to operate, control and verify the capabilities of the IoT product simulated by the virtual device, so as to determine whether the functions of the IoT operating system are normal; for the cloud or App, there is no difference between the virtual device and the real device, so this solution can be used to verify whether the functions of the cloud interface and the App are normal. This solution sends test cases through the server, and automatically executes the test cases through the use case parsing engine, which can conduct a full coverage test of the device firmware, cloud services or App functions. In addition, this solution actually runs the firmware of the IoT device on the Ubuntu system, and the code actually running on the device is still its own firmware code. Therefore, the capability test of the virtual device is actually also a test of the device firmware, which is simple to implement.

[0063] See also Figure 4 , Figure 4 It is a structural diagram of an embodiment of an automated testing device provided in the present application. The automated testing device 40 includes a memory 41 and a processor 42 connected to each other. The memory 41 is used to store a computer program. When the computer program is executed by the processor 42, it is used to implement the Kubernetes-based automated testing method in the above embodiment.

[0064] In this embodiment, the Ubuntu product of the firmware can be deployed as a virtual device through a Docker container, and the virtual device can be published to multiple communication areas through Kubernetes, so the test coverage is relatively wide.

[0065] See also Figure 5 , Figure 5 It is a structural diagram of an embodiment of a computer-readable storage medium provided in the present application. The computer-readable storage medium 50 is used to store a computer program 51. When the computer program 51 is executed by a processor, it is used to implement the Kubernetes-based automated testing method in the above embodiment.

[0066] The computer-readable storage medium 50 may be a server, a USB flash drive, a mobile hard disk, a read-only memory (ROM), a random access memory (RAM), a magnetic disk or an optical disk, or other media that can store program codes.

[0067] In the several embodiments provided in this application, it should be understood that the disclosed methods and devices can be implemented in other ways. For example, the device implementation described above is only illustrative, for example, the division of modules or units is only a logical function division, and there may be other division methods in actual implementation, such as multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed.

[0068] The units described as separate components may or may not be physically separated, and the components shown as units may or may not be physical units, that is, they may be located in one place or distributed on multiple network units. Some or all of the units may be selected according to actual needs to achieve the purpose of the present embodiment.

[0069] In addition, each functional unit in each embodiment of the present application may be integrated into one processing unit, or each unit may exist physically separately, or two or more units may be integrated into one unit. The above-mentioned integrated unit may be implemented in the form of hardware or in the form of software functional units.

[0070] The above descriptions are merely embodiments of the present application and are not intended to limit the patent scope of the present application. Any equivalent structure or equivalent process transformation made using the contents of the present application specification and drawings, or directly or indirectly applied in other related technical fields, are also included in the patent protection scope of the present application.

Claims

1. An automated testing method based on Kubernetes, characterized in that: include: Using the server to send a container creation request to the master node, so that the master node creates a container group based on the configuration file, wherein the container group includes a virtual device container and an automated test container; Downloading firmware related to the virtual device using the virtual device container to start the virtual device; Using the automated test container to enable the virtual device to execute test cases and generate a test report; The method further comprises: Using the server to send the configuration file to master nodes in multiple communication areas, wherein each communication area is provided with a master node and at least one node connected to the master node; Selecting a node from the at least one node as a current node using the master node; Creating the container group based on the container creation request using the current node; The virtual device startup request includes the region information, and the step of using the master node to select a node from the at least one node as the current node includes: Using each of the master nodes to determine whether the region information is the same as the region to which the master node belongs; If so, the master node is recorded as the current master node, and the current master node is used to select an idle node from at least one node connected to the current master node as the current node.

2. The automated testing method based on Kubernetes according to claim 1, characterized in that: The configuration file may be generated according to configuration parameters, where the configuration parameters include a universal unique identifier, an authentication key, product data, or mounting information.

3. The automated testing method based on Kubernetes according to claim 2, characterized in that: The method further comprises: After the virtual device is started, the front end is used to send an interface test request to the server; Using the server to send the automatic test container command to the master node; The master node is used to forward the automatic test container command to the current node, so that the current node forwards the automatic test container command to the automatic test container.

4. The automated testing method based on Kubernetes according to claim 1, characterized in that: The automated test container includes a use case parsing engine, and the method further includes: Using the server to send the test case to the automated test container through the kubectl application program interface; The test case is parsed using the use case parsing engine, and the parsed test case is sent to the virtual device through a remote procedure call protocol interface, so that the virtual device executes the parsed test case.

5. The automated testing method based on Kubernetes according to claim 1, characterized in that: Before the step of using the server to send a container creation request to the master node, the following steps are included: The front end is used to send a request to start the virtual device to the server, so that the server generates the configuration file based on the configuration parameters.

6. The automated testing method based on Kubernetes according to claim 1, characterized in that: The method further comprises: The test report is uploaded to the server through a Fluent interface using the automated test container.

7. The automated testing method based on Kubernetes according to claim 1, characterized in that: The method further comprises: After the front end sends a request to restart the virtual device to the server, the server is used to delete the created container group and assemble a new configuration file based on the configuration parameters.

8. An automated testing device, characterized in that: It comprises a memory and a processor connected to each other, wherein the memory is used to store a computer program, and when the computer program is executed by the processor, it is used to implement the Kubernetes-based automated testing method described in any one of claims 1 to 7.

9. A computer-readable storage medium for storing a computer program, characterized in that: When the computer program is executed by a processor, it is used to implement the automated testing method based on Kubernetes described in any one of claims 1 to 7.

Images