Automatic testing method, device and tool for cloud native service

By generating and executing suspend scripts to automatically acquire and suspend the process of the target application service, the problem of low efficiency in non-functional testing of cloud-native services is solved, and a highly efficient testing process is achieved.

CN121579355APending Publication Date: 2026-02-27CHINA CONSTRUCTION BANK +1
View PDF 0 Cites 0 Cited by

Patent Information

Application Number
CN202511751019.4
Authority / Receiving Office
CN · China
Patent Type
Applications(China)
Current Assignee / Owner
Filing Date
2025-11-26
Publication Date
2026-02-27

AI Technical Summary

Technical Problem

Existing non-functional testing methods for cloud-native services are inefficient and costly in terms of manpower and time.

Method used

By obtaining the identifier of the target application service and the IP address of the target business node, a suspension script is generated and executed to automatically obtain and suspend each target process associated with the target application service, and to obtain monitoring status data to determine the test results.

Benefits of technology

It enables automated testing of cloud-native services, improves testing efficiency, and saves testers time costs associated with suspending service processes.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN121579355A_ABST
    Figure CN121579355A_ABST
Patent Text Reader

Abstract

The invention provides an automatic testing method and device for cloud native services and a testing tool. The method comprises the steps that an identifier of a target application service and an ip address of a target service node where the target application service is located are obtained; generating a hanging script according to the identifier of the target service node and a pre-stored script template; according to the ip address of a target service node where the target application service is located, creating a copy of a hanging script on the target service node; controlling the target service node to execute the execution of hanging up the copy of the script so as to control the target service node to automatically obtain and hang up each target process associated with the target application service; and obtaining monitoring state data of each target process associated with the target application service so as to determine a test result of the cloud native service. According to the scheme, the target process of the target application service can be automatically suspended, the service process can be quickly suspended by one key, the test efficiency can be improved, and the time cost of suspending the service process when a tester performs a non-function test is greatly saved.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] This application relates to the field of cloud computing technology, and in particular to an automated testing method, apparatus and testing tool for cloud-native services. Background Technology

[0002] Cloud computing infrastructure (such as Kubernetes) typically includes a management cluster and a business cluster. Application services are mostly deployed and run in the business cluster as Pods. Non-functional testing is a type of testing that targets non-core business functions of application services (such as performance, reliability, and stability tests). Its core value lies in ensuring the overall availability and user experience of the service in real-world operating scenarios, and it is an indispensable critical step before service deployment. When performing non-functional testing on a service, it is often necessary to suspend the service.

[0003] In existing technical solutions, when suspending a service, testers often need to first log in to the management cluster to query the business cluster and specific node to which the target service belongs; then log in to the corresponding node, manually locate the process ID (PID) of the service; and finally complete the service suspension operation by executing a command.

[0004] The existing technical solution has obvious limitations, resulting in low testing efficiency and significantly increasing the manpower and time costs of the testing process. Summary of the Invention

[0005] This specification provides an automated testing method, apparatus, and testing tool for cloud-native services to address the problems of low testing efficiency and high manpower and time costs associated with existing non-functional testing methods.

[0006] To address the aforementioned technical issues, this specification provides, in its first aspect, an automated testing method for cloud-native services. The method includes: obtaining the identifier of a target application service and the IP address of the target business node where the target application service resides; generating a suspension script based on the identifier of the target business node and a pre-stored script template; creating a copy of the suspension script on the target business node based on the IP address of the target business node where the target application service resides; controlling the target business node to execute the copy of the suspension script, thereby controlling the target business node to automatically acquire and suspend each target process associated with the target application service; and acquiring monitoring status data of each target process associated with the target application service to determine the test results of the cloud-native service.

[0007] In some embodiments, the method further includes: generating a monitoring script based on the identifier of the target application service and a pre-stored script template, wherein when the monitoring script is executed, it automatically obtains the identifiers and statuses of each target process associated with the target application.

[0008] In some embodiments, the method further includes: obtaining the IP address of the target management node; creating a copy of the monitoring script on the target management node based on the IP address of the target management node, and controlling the target management node to execute the copy of the monitoring script, so as to control the target management node to automatically obtain the identifier and status of the target process associated with the target application service; and obtaining the monitoring status data of the target process from the target management node.

[0009] In some embodiments, the monitoring script includes: a first query code segment, used to call the API server component provided by the management cluster to send a query request to the target management node, the query request carrying the identifier of the target application service; the query request is used to query the identifiers and statuses of each target process associated with the target application service; and the query code segment is used to receive the identifiers and statuses of the target processes fed back by the target management node.

[0010] In some embodiments, the suspension script template includes: a second query code segment for controlling the target business node to query each target process associated with the target application service; a detection code segment for detecting the running status of each target process; and a suspension code segment for controlling the target business node to suspend the target process when the running status of the target process is stopped.

[0011] In some embodiments, before controlling the target management node to access the target business node, the method further includes: the target management node setting a public key and a private key; distributing the public key to each business node and retaining its own private key; sending a public key fingerprint to the target business node; the public key fingerprint triggers the template business node to check whether the public key fingerprint exists in its own key file, and if the public key fingerprint exists, generating a random string, encrypting the random string with the received public key, and sending the ciphertext to the target management node; decrypting the received ciphertext with its own retained private key; returning the ciphertext decryption result to the target business node; the ciphertext decryption result triggers the target business node to match the received ciphertext decryption result with the random string it generated; if they match, the target business node allows the target management node to access; if they do not match, the target business node does not allow the target management node to access; if access is allowed, accessing the target business node to create a copy of the suspending script on the target business node, and controlling the target business node to execute the copy of the suspending script.

[0012] The second aspect of this specification provides an automated testing method for cloud-native services. The method includes: receiving a copy of a suspension script; the suspension script is generated based on the identifier of a target business node and a pre-stored script template; the suspension script is used to control the target business node to automatically acquire and suspend each target process associated with the target application service; and executing the copy of the suspension script in response to a suspension script execution instruction.

[0013] In some embodiments, the suspension script template includes: a second query code segment for controlling the target business node to query each target process associated with the target application service; a detection code segment for detecting the running status of each target process; and a suspension code segment for controlling the target business node to suspend the target process when the running status of the target process is stopped.

[0014] In some embodiments, the method further includes: after receiving a copy of the suspension script, detecting whether there is script code in the copy that controls the suspension process; if so, detecting whether the operation of controlling the suspension process is executed when the process is in a stopped running state; if so, allowing the copy to execute; otherwise, prohibiting the copy from executing.

[0015] This specification provides a third aspect of an automated testing tool for cloud-native services, comprising: an input component for receiving a user-inputted identifier of a target application service and the IP address of a target business node where the target application service resides; a first generation component for generating a suspension script based on the identifier of the target business node and a pre-stored script template; a control component for creating a copy of the suspension script on the target business node based on the IP address of the target business node where the target application service resides; controlling the target business node to execute the copy of the suspension script to automatically acquire and suspend each target process associated with the target application service; and a presentation component for acquiring and presenting monitoring status data of each target process associated with the target application service to determine the test results of the cloud-native service.

[0016] In some embodiments, the automated testing tool for cloud-native services further includes: a second generation component, configured to generate a monitoring script based on the identifier of the target business node and a pre-stored script template; correspondingly, the input component is further configured to input the IP address of the target management node; and the control component is further configured to create a copy of the monitoring script on the target management node based on the IP address of the target management node, and control the target management node to execute the copy of the monitoring script, so as to control the target management node to automatically obtain the identifier and status of the target process associated with the target application service; and the presentation component obtains the monitoring status data of the target process from the target management node.

[0017] In some embodiments, the monitoring script includes: a first query code segment, used to call the API server component provided by the management cluster to send a query request to the target management node, the query request carrying the identifier of the target application service; the query request is used to query the identifiers and statuses of each target process associated with the target application service; and the query code segment is used to receive the identifiers and statuses of the target processes fed back by the target management node.

[0018] In some embodiments, the suspension script template includes: a second query code segment for controlling the target business node to query each target process associated with the target application service; a detection code segment for detecting the running status of each target process; and a suspension code segment for controlling the target business node to suspend the target process when the running status of the target process is stopped.

[0019] This specification provides an automated testing device for cloud-native services in a fourth aspect. The device includes: a first acquisition unit for acquiring the identifier of a target application service and the IP address of a target business node where the target application service resides; a first generation unit for generating a suspension script based on the identifier of the target business node and a pre-stored script template; a first creation unit for creating a copy of the suspension script on the target business node based on the IP address of the target business node where the target application service resides; a first control unit for controlling the target business node to execute the copy of the suspension script, thereby controlling the target business node to automatically acquire and suspend each target process associated with the target application service; and a first acquisition unit for acquiring monitoring status data of each target process associated with the target application service, for determining the test results of the cloud-native service.

[0020] In some embodiments, the apparatus further includes: a second generation unit, configured to generate a monitoring script based on the identifier of the target application service and a pre-stored script template, wherein when the monitoring script is executed, it automatically obtains the identifiers and statuses of each target process associated with the target application.

[0021] In some embodiments, the apparatus further includes: a second acquisition unit, configured to acquire the IP address of the target management node; a second creation unit, configured to create a copy of the monitoring script on the target management node according to the IP address of the target management node, and control the target management node to execute the copy of the monitoring script, so as to control the target management node to automatically acquire the identifier and status of the target process associated with the target application service; and a third acquisition unit, configured to acquire monitoring status data of the target process from the target management node.

[0022] In some embodiments, the monitoring script includes: a first query code segment, used to call the API server component provided by the management cluster to send a query request to the target management node, the query request carrying the identifier of the target application service; the query request is used to query the identifiers and statuses of each target process associated with the target application service; and the query code segment is used to receive the identifiers and statuses of the target processes fed back by the target management node.

[0023] In some embodiments, the suspension script template includes: a second query code segment for controlling the target business node to query each target process associated with the target application service; a detection code segment for detecting the running status of each target process; and a suspension code segment for controlling the target business node to suspend the target process when the running status of the target process is stopped.

[0024] In some embodiments, the apparatus further includes: a first sending unit, configured to send a public key fingerprint to a target service node; the public key fingerprint triggers a template service node to check whether the public key fingerprint exists in its own key file, and if the public key fingerprint exists, generates a random string, encrypts the random string with the received public key, and sends the ciphertext to the target management node; a decryption unit, configured to decrypt the received ciphertext using its own private key; a second sending unit, configured to return the ciphertext decryption result to the target service node; the ciphertext decryption result triggers the target service node to match the received ciphertext decryption result with the random string it generated; if they match, the target service node allows the target management node to access; if they do not match, the target service node does not allow the target management node to access; and an access unit, configured to, if access is allowed, access the target service node to create a copy of the suspending script on the target service node, and control the target service node to execute the copy of the suspending script.

[0025] This specification provides a fifth aspect of an automated testing device for cloud-native services. The device includes: a receiving unit for receiving a copy of a suspension script; the suspension script is generated based on the identifier of a target business node and a pre-stored script template; the suspension script is used to control the target business node to automatically acquire and suspend each target process associated with the target application service; and an execution unit for executing the copy of the suspension script in response to a suspension script execution instruction.

[0026] In some embodiments, the suspension script template includes: a second query code segment for controlling the target business node to query each target process associated with the target application service; a detection code segment for detecting the running status of each target process; and a suspension code segment for controlling the target business node to suspend the target process when the running status of the target process is stopped.

[0027] In some embodiments, the apparatus further includes: a first detection unit, configured to detect, upon receiving a copy of the suspending script, whether script code controlling the suspended process exists in the copy; a second detection unit, configured to, if present, detect whether the operation controlling the suspended process is executed when the process is in a stopped running state; and an execution permission control unit, configured to, if present, allow the copy to execute; otherwise, prohibit the copy from executing.

[0028] The sixth aspect of this specification provides an electronic device, comprising: a memory and a processor, wherein the processor and the memory are communicatively connected to each other, the memory stores computer instructions, and the processor executes the computer instructions to implement the automatic testing method for cloud-native services as described in any one of the first aspects or the second aspect, or the automatic testing tool for cloud-native services as described in any one of the third aspects.

[0029] The seventh aspect of this specification provides a computer storage medium storing computer program instructions, which, when executed, implement the automatic testing method for cloud-native services described in any of the first or second aspects, or the automatic testing tool for cloud-native services described in any of the third aspects.

[0030] This specification provides a computer program product in an eighth aspect, comprising a computer program that, when executed by a processor, implements an automatic testing method for cloud-native services as described in any of the first or second aspects, or an automatic testing tool for cloud-native services as described in any of the third aspects.

[0031] The automated testing methods, devices, and tools for cloud-native services provided in this manual generate suspension scripts based on the identifier of the target business node and pre-stored script templates. A copy of the suspension script is copied and executed on the target business node based on the IP address of the target application service, enabling the target business node to automatically acquire and suspend all target processes associated with the target service. This solution only requires knowledge of the target application service identifier and the IP address of the target business node to automatically suspend the target application service's processes, achieving one-click and rapid service process suspension. This improves testing efficiency and significantly reduces the time and cost for testers to suspend service processes during non-functional testing. Attached Figure Description

[0032] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments recorded in this application. For those skilled in the art, other drawings can be obtained from these drawings without creative effort.

[0033] Figure 1 A schematic diagram illustrating the execution entity involved in the automated testing methods for cloud-native services provided in this specification; Figure 2 Another schematic diagram of the execution entity involved in the automated testing methods for cloud-native services provided in this specification; Figure 3 A flowchart illustrating an automated testing method for cloud-native services provided in this specification. Figure 4 This is another flowchart illustrating the automated testing method for cloud-native services provided in this specification. Figure 5 A schematic diagram illustrating one implementation of the automated testing method for cloud-native services provided in this specification; Figure 6 A schematic diagram of the structure of the automated testing tool for cloud-native services provided in this specification; Figure 7 This is another structural diagram of the automated testing tools for cloud-native services provided in this specification; Figure 8 This specification provides a schematic diagram of an automated testing device for cloud-native services. Figure 9 This is another principle block diagram of an automated testing device for cloud-native services provided in this specification; Figure 10 This is a schematic diagram of the electronic device provided in this specification. Detailed Implementation

[0034] To enable those skilled in the art to better understand the technical solutions in this application, the technical solutions in the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of this application, and not all of the embodiments. Based on the embodiments in this application, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of this application.

[0035] It should be noted that the information and data related to users involved in the embodiments of this specification are all information and data authorized by the user or fully authorized by the relevant parties. Furthermore, the collection, storage, use, processing, transmission, provision, disclosure, and application of the relevant data all comply with relevant laws, regulations, and standards, and necessary confidentiality measures have been taken. They do not violate public order and good morals, and corresponding operation entry points are provided for users or relevant parties to choose to authorize or refuse.

[0036] It should also be noted that in the embodiments of this specification, certain software, components, models and other existing solutions in the industry may be mentioned. These should be regarded as exemplary and are only intended to illustrate the feasibility of implementing the technical solution of this application. However, it does not mean that the applicant has used or necessarily used the solution.

[0037] Kubernetes is an open-source distributed container orchestration platform used to automate containerized deployment, scheduling, scaling, fault healing, service discovery, and resource management. It is a core infrastructure of cloud-native architectures. Cloud computing infrastructures similar to Kubernetes typically include management clusters and business clusters.

[0038] The management cluster consists of a set of core components with global control capabilities. It serves as the cluster's decision-making and command center, focusing on storing the cluster's global state, making scheduling decisions, and issuing commands. It does not directly handle business workloads. The core components of the management cluster include kube-apiserver, etcd, kube-scheduler, and kube-controller-manager. kube-apiserver is the API server, serving as the unified API entry point for the cluster. It receives and verifies all user / system operation requests (such as deploying Pods and querying node status), acting as the hub for inter-component communication. etcd is a distributed key-value database, acting as the cluster configuration center, storing all core cluster configurations (such as Pod deployment information, node lists, and permission policies) and runtime status data. kube-scheduler is the Pod scheduling decision component, allocating the optimal target node for Pods to be deployed based on rules such as remaining node resources, affinity / anti-affinity policies, and taint tolerance. kube-controller-manager is used to run various cluster controllers (such as NodeController, ReplicaSetController, and DeploymentController) to continuously monitor the difference between the actual and expected cluster states, automatically performing fault recovery (such as rescheduling Pods after a node crash), scaling up and down, and other operations to ensure cluster state convergence.

[0039] The business cluster consists of several computing nodes and is the core carrier of business workloads. It focuses on running Pods corresponding to application services and directly provides business capabilities (such as interface services, data processing, application access, etc.) to the outside world. The core components of the business cluster include nodes, kubelet, kube-proxy, and underlying components. Nodes can be physical servers or virtual machines, providing hardware resources such as CPU, memory, storage, and network, and are the direct carriers for running Pods. Kubelet is a proxy component running on each node, communicating with the kube-apiserver of the management cluster, receiving and executing instructions such as Pod creation, startup, and shutdown, while monitoring the container's running status and reporting it to the management cluster. Kube-proxy is the node network proxy component, implementing load balancing of services and maintaining network rules to ensure that external requests are correctly forwarded to the associated Pods. The underlying components are responsible for the lifecycle management of containers, including creation, startup, and destruction.

[0040] The management cluster acts as the decision-maker, specifically responsible for storing the full cluster configuration and business deployment expectations (e.g., "a service needs to run 3 Pods"). It ensures the business cluster's operational status meets these expectations through scheduling algorithms and controllers. The business cluster acts as the executor, specifically responsible for receiving instructions from the management cluster, deploying and running Pods on nodes, carrying actual business traffic, and reporting its operational status (e.g., Pod liveness status, node resource utilization) to the management cluster in real time. The management cluster receives user operations (e.g., deploying services via kubectl) through the kube-apiserver, schedules and makes decisions, and then issues instructions to the business clusters. The business clusters execute these instructions and provide feedback on their status. The management cluster adjusts its decisions based on this feedback (e.g., triggering a restart instruction when a Pod fails), thus achieving a closed-loop data interaction. Nodes in the management cluster are called management nodes, and nodes in the business cluster are called business nodes.

[0041] A Pod is the smallest unit of scheduling and deployment in the aforementioned cloud computing infrastructure. It is a collection of resources containing one or more closely related containers, sharing the same network namespace, storage volume, and PID namespace (optional). It represents the smallest unit of scheduling in the aforementioned computer infrastructure (indivisible scheduling). Essentially, a Pod is a "logical encapsulation unit" of a container, carrying the actual running instance of an application service (such as a single running copy of a backend service).

[0042] A service is an abstract network resource within the aforementioned cloud computing infrastructure framework. It's used for service discovery and load balancing, associating a group of Pods with identical functionality through a label selector. It provides a fixed access endpoint, shielding the access differences caused by dynamic changes in Pods (such as restarts, scaling, and IP changes). Essentially, a service is a "stable access point" for Pods, resolving the unreliability issues caused by the dynamic nature of Pods.

[0043] Services include application services and non-application services. Application services are services that specifically carry out business logic and directly provide business information to the outside world. Non-application services include infrastructure services and middleware services. Infrastructure services include DNS services, storage services, and network services, while middleware services include database services, caching services, and message queue services.

[0044] A node, in the aforementioned cloud computing infrastructure framework, is a computing node that can be a physical server or a virtual machine. It is the direct runtime environment for Pods, providing hardware resources such as CPU, memory, storage, and network, and running Kubernetes node-level core components to support Pod lifecycle management. Essentially, a node is the "hardware resource carrier" of the cluster, serving as the physical / virtual foundation for Pod execution.

[0045] Containers are a lightweight, portable, and self-contained virtualization technology. Through operating system-level virtualization (rather than hardware virtualization), they package applications and all their dependencies (such as code, runtime, libraries, environment variables, and configuration files) into standardized units, ensuring that applications run consistently in any compatible runtime environment. In the aforementioned cloud computing infrastructure, containers are the smallest atomic unit for application execution, used to solve the problem of inconsistent application performance across different environments. Containers are not independent operating systems; they are process-level isolated environments. Resource isolation is achieved through namespaces (which isolate networks, PIDs, mount points, etc.), and resource limits such as CPU and memory are implemented through cgroups.

[0046] In other words, containers are components of Pods. Pods run on nodes of the business cluster. The management cluster indirectly controls containers by managing Pods. The business cluster supports container operation through nodes and container runtime (i.e., container lifecycle management tools).

[0047] To improve the high availability of cloud-native services, developers typically configure health check mechanisms. These mechanisms periodically monitor service status according to predefined rules, and automatically trigger recovery actions (such as restarting a Pod) if a service fails to meet health standards (e.g., a process is suspended). Therefore, achieving high availability for cloud-native services inevitably requires suspending service processes.

[0048] Existing technologies suffer from low testing efficiency and high manpower and time costs when testing cloud-native services. To address this, this application aims to improve the testing efficiency of cloud-native services by providing an automated testing method.

[0049] This method can be used on the target control node, other control nodes, and nodes other than the control node itself. For example... Figure 1 As shown, this method can involve target control nodes and target business nodes; such as Figure 2 As shown, this method can also involve target control nodes, target business nodes, and other nodes. These other nodes can be other control nodes in the control cluster or any electronic device outside the control cluster.

[0050] like Figure 3 As shown, the automated testing methods for cloud-native services executed on the target management node include the following S11 to S15.

[0051] S11: Obtain the identifier of the target application service and the IP address of the target business node where the target application service is located.

[0052] The target application service can be an application service that the user needs to test, or an application service associated with an application service that needs to be tested.

[0053] The identifiers of the target application service and the target process are the core basis for locating the service to be operated / monitored and the underlying running process corresponding to that service. The identifier of the target application service is an abstract label or resource name that uniquely identifies a certain type of business service within the aforementioned cloud computing infrastructure cluster. The identifier of the target process is an identifier used to uniquely identify the running process corresponding to the application service within the Pod container or on the business node host.

[0054] The identifier of the target application service and the IP address of the target business node where the target application service is located can be entered by the tester through the automated testing methods of the cloud-native service mentioned above, or they can be passed by other programs or other code segments.

[0055] S12: Generate a suspension script based on the identifier of the target business node and the pre-stored script template.

[0056] Pre-stored script templates can include suspension script templates, as well as script templates for performing other functions.

[0057] The suspension script template has pre-set standardized execution logic, and only reserved dedicated configuration placeholders for the target business node identifier and the target process identifier. When generating the suspension script, you only need to fill in the target business node identifier and the target process identifier on the basis of the suspension script.

[0058] S13: Create a copy of the suspension script on the target business node based on the IP address of the target application service.

[0059] S13 can be understood as copying the suspended script to the target business node. By using S13, it can be ensured that the script can perform relevant operations locally on the target business node.

[0060] By using the IP address of the target business node, it can be determined which node the suspended script copy should be copied to.

[0061] S14: Control the target business node to execute a copy of the suspension script, so as to control the target business node to automatically obtain and suspend each target process associated with the target application service.

[0062] S15: Obtain the monitoring status data of each target process associated with the target application service, in order to determine the test results of the cloud-native service.

[0063] When the automated testing method for cloud-native services runs on the target management node, it can respond to internal or external query commands to obtain the status monitoring results of each target process associated with the target application service.

[0064] When the automated testing method for cloud-native services runs on either the target management node or a non-target management node (i.e., not on the target management node), the automated testing method can generate a monitoring script based on the identifier of the target application service and a pre-stored script template. When the monitoring script is executed, it automatically obtains the identifiers and statuses of each target process associated with the target application. In this case, the identifiers and statuses of each target process can be obtained by running the monitoring script.

[0065] When the automated testing method for cloud-native services is running on a non-target management node (i.e., not on the target management node), the monitoring script may include a first query code segment, which is used to call the API server component provided by the management cluster to send a query request to the target management node. The query request carries the identifier of the target application service. The query request is used to query the identifier and status of each target process associated with the target application service. The query code segment is also used to receive the identifier and status of the target process fed back by the target management node.

[0066] As a parallel implementation of the above method, when the automated testing method for cloud-native services runs on a non-target management node (i.e., not on the target management node), the automated testing method for cloud-native services may further include: obtaining the IP address of the target management node; creating a copy of the monitoring script on the target management node based on the IP address of the target management node, and controlling the target management node to execute the copy of the monitoring script, so as to control the target management node to automatically obtain the identifier and status of the target process associated with the target application service; and obtaining the monitoring status data of the target process from the target management node.

[0067] With this setting, testers only need to enter the identifier of the target application service, the IP address of the target management node, and the IP address of the target business node to perform cloud-native service testing anytime, anywhere using any electronic device.

[0068] The control and management nodes and business nodes follow a "control-execution" separation architecture. The control and management nodes do not directly access the operating system processes of the business nodes; instead, they rely on native components of the business nodes (such as kubelet) as state collection proxies. The native components of the business nodes (such as kubelet) report the collected process states to the API server of the control and management nodes via HTTPS. After verification, the data is synchronously stored in the unified data storage of the cluster. When process states are needed (e.g., by executing a query command via Kubectl), the API service of the control and management nodes retrieves the corresponding state data from the unified data storage of the cluster and sends it back to the requester.

[0069] S11 to S15 above can be executed by the same executing entity or by different executing entities.

[0070] The aforementioned automated testing method for cloud-native services generates a suspension script based on the target business node's identifier and a pre-stored script template. It then copies and controls the execution of a copy of the suspension script on the target business node based on the IP address of the target application service. This allows the target business node to automatically acquire and suspend all target processes associated with the target service. This solution only requires knowledge of the target application service's identifier and the IP address of the target business node to automatically suspend the target application service's processes, achieving one-click and rapid service process suspension. This improves testing efficiency and significantly reduces the time and cost for testers to suspend service processes during non-functional testing.

[0071] In this specification, "pre-stored script templates" refers to pre-stored script templates, not specially created script templates. In some embodiments, pre-stored script templates may include suspension script templates and monitoring script templates.

[0072] In some embodiments, the suspend script template includes a second query code segment, a detection code segment, and a suspend code segment.

[0073] The second query code segment is used to control the target business node to query each target process associated with the target application service.

[0074] The detection code segment is used to detect the running status of each target process.

[0075] The suspension code segment is used to control the target business node to suspend the target process when the target process is in a stopped running state.

[0076] By checking the running status of the target process before suspending it, and only suspending the target process when its running status is stopped, non-functional tests can be avoided from affecting the normal operation of application services.

[0077] In some embodiments, to further prevent non-functional testing from affecting the normal operation of application services, each business node can be configured to check whether there is script code controlling the suspended process in the copy after receiving the copy of the suspended script. If so, it checks whether the operation of the suspended process is executed when the process running state is stopped. If so, the copy is allowed to execute; otherwise, the copy is prohibited from executing.

[0078] In some embodiments, the control node requires the access password of the business node to access the business node. This requires testers to enter the password to execute the automated testing methods of the cloud-native services, which increases the difficulty of testing.

[0079] To improve the convenience for testers to perform non-functional testing, automated testing methods for cloud-native services can execute the following SA1 to SA5 before the control target management node accesses the target business node.

[0080] SA1: Send the public key fingerprint to the target business node; the public key fingerprint triggers the template business node to check whether the public key fingerprint exists in its own key file, and if the public key fingerprint exists, it generates a random string, encrypts the random string with the received public key, and sends the ciphertext to the target control node.

[0081] SA2: Decrypt the received ciphertext using the private key that is kept by the user.

[0082] SA3: Return the ciphertext decryption result to the target service node; the ciphertext decryption result triggers the target service node to match the received ciphertext decryption result with the random string it generated; if they match, the target service node allows the target management node to access; if they do not match, the target service node does not allow the target management node to access.

[0083] SA4: If access is permitted, access the target service node to create a copy of the suspending script on the target service node, and control the target service node to execute the copy of the suspending script.

[0084] Before executing SA1 to SA4, a public key and a matching private key can be set for the target management node, and the public key can be distributed to each business node, while the private key is kept on the target management node.

[0085] Through SA1 to SA4, passwordless access to target business nodes can be achieved by the target management node, allowing testers to execute the automated testing methods of the cloud-native services without entering a password, thereby reducing the difficulty of non-functional testing and improving the convenience of testing.

[0086] This manual also provides an automated testing method for cloud-native services from the perspective of target business nodes, such as... Figure 4 As shown, the method includes the following steps S21 and S22.

[0087] S21: Receive a copy of the suspension script; the suspension script is generated based on the identifier of the target business node and a pre-stored script template; the suspension script is used to control the target business node to automatically acquire and suspend each target process associated with the target application service.

[0088] The copy of the suspension script can be sent by the target control node or by a node other than the target control node.

[0089] S22: In response to the suspend script execution instruction, execute a copy of the suspend script.

[0090] This suspended script execution command is used to control the execution of the suspended script copy on the target business node. This suspended script execution command can be sent by the target management node or by other nodes.

[0091] In some embodiments, the suspension script template includes a second query code segment, a detection code segment, and a suspension code segment.

[0092] The second query code segment controls the target business node to query each target process associated with the target application service. The detection code segment is used to detect the running status of each target process. The suspension code segment controls the target business node to suspend the target process when its running status is stopped.

[0093] In some embodiments, after receiving a copy of the suspension script, the target service node checks whether there is script code in the copy that controls the suspension process; if so, it checks whether the operation of controlling the suspension process is executed when the process is in a stopped running state; if so, it allows the copy to execute; otherwise, it prohibits the copy from executing.

[0094] The above S21 and S22 can be executed by the same executing entity or by different executing entities.

[0095] The above S21 and S22 can be understood by referring to the descriptions of S11 to S15.

[0096] like Figure 5 As shown, in some embodiments, S11 to S15 are executed by the target management node, and S21 and S22 are executed by the target service node.

[0097] This specification also provides an automated testing tool for cloud-native services, which can run on any electronic device used by the tester. For example... Figure 6 As shown, the automated testing tool for this cloud-native service includes input component A, first generation component B, control component C, and presentation component D.

[0098] Input component A is used to receive the identifier of the target application service and the IP address of the target business node where the target application service is located, input by the user. Input component A can be a keyboard, touch screen, etc.

[0099] The first generation component B is used to generate a suspension script based on the identifier of the target business node and a pre-stored script template.

[0100] Control component C is used to create a copy of the suspension script on the target business node based on the IP address of the target business node where the target application service is located; and to control the target business node to execute the copy of the suspension script so as to control the target business node to automatically obtain and suspend each target process associated with the target application service.

[0101] The presentation component D is used to acquire and present monitoring status data of each target process associated with the target application service, in order to determine the test results of the cloud-native service. This presentation component D may be a display.

[0102] In some embodiments, such as Figure 7 As shown, the automated testing tool for cloud-native services also includes a second generation component E, used to generate monitoring scripts based on the identifier of the target business node and a pre-stored script template.

[0103] Accordingly, the input component A is also used to input the IP address of the target management node; and the control component is also used to create a copy of the monitoring script on the target management node according to the IP address of the target management node, and control the target management node to execute the copy of the monitoring script, so as to control the target management node to automatically obtain the identifier and status of the target process associated with the target application service; and the presentation component D obtains the monitoring status data of the target process from the target management node.

[0104] In some embodiments, the monitoring script includes: a first query code segment, used to call the API server component provided by the management cluster to send a query request to the target management node, the query request carrying the identifier of the target application service; the query request is used to query the identifiers and statuses of each target process associated with the target application service; and the query code segment is used to receive the identifiers and statuses of the target processes fed back by the target management node.

[0105] In some embodiments, the suspension script template includes a second query code segment, a detection code segment, and a suspension code segment.

[0106] The second query code segment controls the target business node to query each target process associated with the target application service. The detection code segment is used to detect the running status of each target process. The suspension code segment controls the target business node to suspend the target process when its running status is stopped.

[0107] The automated testing tools for the aforementioned cloud-native services can run on the target management node, or on an electronic device outside the management cluster and business cluster, such as a computer carried by the tester; or on a management node in the management cluster other than the target management node.

[0108] The description of the automated testing tools for cloud-native services can be understood by referring to the description of the automated testing methods for cloud-native services.

[0109] This specification provides an automated testing device for cloud-native services, which can be used to implement S11 to S15 described above. For example... Figure 8 As shown, the device includes a first acquisition unit 11, a first generation unit 12, a first creation unit 13, a first control unit 14, and a first acquisition unit 15.

[0110] The first acquisition unit 11 is used to acquire the identifier of the target application service and the IP address of the target business node where the target application service is located.

[0111] The first generation unit 12 is used to generate a suspension script based on the identifier of the target business node and the pre-stored script template.

[0112] The first creation unit 13 is used to create a copy of the suspension script on the target business node according to the IP address of the target business node where the target application service is located.

[0113] The first control unit 14 is used to control the target business node to execute a copy of the suspension script, so as to control the target business node to automatically obtain and suspend each target process associated with the target application service.

[0114] The first acquisition unit 15 is used to acquire monitoring status data of each target process associated with the target application service, so as to determine the test results of the cloud-native service.

[0115] In some embodiments, the apparatus further includes: a second generation unit, configured to generate a monitoring script based on the identifier of the target application service and a pre-stored script template, wherein when the monitoring script is executed, it automatically obtains the identifiers and statuses of each target process associated with the target application.

[0116] In some embodiments, the apparatus further includes a second acquisition unit, a second creation unit, and a third acquisition unit.

[0117] The second acquisition unit is used to acquire the IP address of the target control node.

[0118] The second creation unit is used to create a copy of the monitoring script on the target management node according to the IP address of the target management node, and control the target management node to execute the copy of the monitoring script so as to control the target management node to automatically obtain the identifier and status of the target process associated with the target application service.

[0119] The third acquisition unit is used to acquire monitoring status data of the target process from the target management node.

[0120] In some embodiments, the monitoring script includes: a first query code segment, used to call the API server component provided by the management cluster to send a query request to the target management node, the query request carrying the identifier of the target application service; the query request is used to query the identifiers and statuses of each target process associated with the target application service; and the query code segment is used to receive the identifiers and statuses of the target processes fed back by the target management node.

[0121] In some embodiments, the suspension script template includes a second query code segment, a detection code segment, and a suspension code segment. The second query code segment controls the target business node to query each target process associated with the target application service. The detection code segment detects the running status of each target process. The suspension code segment controls the target business node to suspend the target process when its running status is stopped.

[0122] In some embodiments, the apparatus further includes a first sending unit, a decryption unit, a second sending unit, and an access unit.

[0123] The first sending unit is used to send a public key fingerprint to the target service node; the public key fingerprint trigger template service node checks whether the public key fingerprint exists in its own key file, and if the public key fingerprint exists, generates a random string, encrypts the random string with the received public key, and sends the ciphertext to the target control node.

[0124] The decryption unit is used to decrypt the received ciphertext using its own private key.

[0125] The second sending unit is used to return the ciphertext decryption result to the target service node; the ciphertext decryption result triggers the target service node to match the received ciphertext decryption result with the random string it generates; if they match, the target service node allows the target management node to access; if they do not match, the target service node does not allow the target management node to access.

[0126] The access unit is used to access the target service node when access is permitted, to create a copy of the suspension script on the target service node, and to control the target service node to execute the copy of the suspension script.

[0127] This specification provides an automated testing device for cloud-native services, which can be used to implement S21 and S22 described above. For example... Figure 9 As shown, the device includes a receiving unit 21 and an execution unit 22.

[0128] The receiving unit 21 is used to receive a copy of the suspension script; the suspension script is generated based on the identifier of the target business node and a pre-stored script template; the suspension script is used to control the target business node to automatically acquire and suspend each target process associated with the target application service.

[0129] The execution unit 22 is used to execute a copy of the suspended script in response to the suspended script execution instruction.

[0130] In some embodiments, the suspension script template includes a second query code segment, a detection code segment, and a suspension code segment.

[0131] The second query code segment controls the target business node to query each target process associated with the target application service. The detection code segment detects the running status of each target process. The suspension code segment controls the target business node to suspend the target process when its running status is stopped.

[0132] In some embodiments, the apparatus further includes a first detection unit, a second detection unit, and an execution authority control unit.

[0133] The first detection unit, upon receiving a copy of the suspension script, checks whether the copy contains script code controlling the suspended process. The second detection unit, if present, checks whether the operation controlling the suspended process is executed while the process is in a stopped state. The execution permission control unit, if so, allows the copy to execute; otherwise, it prohibits the copy from executing.

[0134] The descriptions and functions of the above devices can be found in the section on automated testing methods for the corresponding cloud-native services, and will not be repeated here.

[0135] This invention also provides an electronic device, such as... Figure 10 As shown, the electronic device may include a processor 1001 and a memory 1002, wherein the processor 1001 and the memory 1002 may be connected via a bus or other means. Figure 10 Taking the example of a connection between China and Israel via a bus.

[0136] Processor 1001 may be a central processing unit (CPU). Processor 1001 may also be other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, or combinations thereof.

[0137] Memory 1002, as a non-transitory computer-readable storage medium, can be used to store non-transitory software programs, non-transitory computer-executable programs, and modules, such as the program instructions / modules corresponding to the automatic testing method for cloud-native services in this embodiment of the invention (e.g., Figure 8 The first acquisition unit 11, first generation unit 12, first creation unit 13, first control unit 14, and first acquisition unit 15 shown, or Figure 9 The receiving unit 21 and the execution unit 22 shown, or Figure 6 or Figure 7(The various components shown). The processor 1001 executes various functional applications and data processing by running non-transitory software programs, instructions, and modules stored in the memory 1002, thereby implementing the automatic testing method or automatic testing tool for cloud-native services in the above method embodiments.

[0138] The memory 1002 may include a program storage area and a data storage area. The program storage area may store the operating system and applications required for at least one function; the data storage area may store data created by the processor 1001, etc. Furthermore, the memory 1002 may include high-speed random access memory and may also include non-transitory memory, such as at least one disk storage device, flash memory device, or other non-transitory solid-state storage device. In some embodiments, the memory 1002 may optionally include memory remotely located relative to the processor 1001, and these remote memories may be connected to the processor 1001 via a network. Examples of such networks include, but are not limited to, the Internet, corporate intranets, local area networks, mobile communication networks, and combinations thereof.

[0139] The one or more modules are stored in the memory 1002, and when executed by the processor 1001, they execute the above-mentioned automatic testing method or automatic testing tool for cloud-native services.

[0140] The specific details of the above-mentioned electronic device can be understood by referring to the relevant descriptions and effects in the method embodiments, and will not be repeated here.

[0141] This specification also provides a computer storage medium storing computer program instructions, which, when executed, implement the above-described automatic testing method or automatic testing tool for cloud-native services.

[0142] This specification also provides a computer program product comprising a computer program that, when executed by a processor, implements the above-described automatic testing method or automatic testing tool for cloud-native services.

[0143] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The program can be stored in a computer-readable storage medium, and when executed, it can include the processes of the embodiments of the above methods. The storage medium can be a magnetic disk, optical disk, read-only memory (ROM), random access memory (RAM), flash memory, hard disk drive (HDD), or solid-state drive (SSD), etc.; the storage medium can also include combinations of the above types of memory.

[0144] The various embodiments in this specification are described in a progressive manner. For the same or similar parts between the various embodiments, please refer to each other. The focus of each embodiment is to describe the differences from other embodiments.

[0145] The systems, devices, modules, or units described in the above embodiments can be implemented by computer chips or entities, or by products with certain functions.

[0146] For ease of description, the above devices are described separately by function as various units. Of course, in implementing this application, the functions of each unit can be implemented in one or more software and / or hardware.

[0147] As can be seen from the above description of the embodiments, those skilled in the art can clearly understand that this application can be implemented by means of software plus necessary general-purpose hardware platforms. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product can be stored in a storage medium, such as ROM / RAM, magnetic disk, optical disk, etc., and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute certain parts of the methods of various embodiments of this application.

[0148] This application can be used in a wide variety of general-purpose or special-purpose computer system environments or configurations. For example: personal computers, server computers, handheld or portable devices, tablet devices, multiprocessor systems, microprocessor-based systems, set-top boxes, programmable consumer electronics devices, network PCs, minicomputers, mainframe computers, distributed computing environments including any of the above systems or devices, etc.

[0149] This application can be described in the general context of computer-executable instructions, such as program modules, that are executed by a computer. Generally, program modules include routines, programs, objects, components, data structures, etc., that perform a specific task or implement a specific abstract data type. This application can also be practiced in distributed computing environments where tasks are performed by remote processing devices connected via a communication network. In distributed computing environments, program modules can reside in local and remote computer storage media, including storage devices.

[0150] Although this application has been described through embodiments, those skilled in the art will know that this application has many modifications and variations without departing from the spirit of this application, and it is intended that the appended claims cover such modifications and variations without departing from the spirit of this application.

Claims

1. An automated testing method for cloud-native services, characterized in that, The method includes: Obtain the identifier of the target application service and the IP address of the target business node where the target application service is located; A suspension script is generated based on the identifier of the target business node and the pre-stored script template; Create a copy of the suspension script on the target business node based on the IP address of the target application service; Control the target business node to execute a copy of the suspension script, so as to control the target business node to automatically acquire and suspend each target process associated with the target application service; Obtain monitoring status data of each target process associated with the target application service to determine the test results of the cloud-native service.

2. The method according to claim 1, characterized in that, The method further includes: A monitoring script is generated based on the identifier of the target application service and a pre-stored script template. When the monitoring script is executed, it automatically obtains the identifiers and statuses of each target process associated with the target application.

3. The method according to claim 2, characterized in that, The method further includes: Obtain the IP address of the target control node; Based on the IP address of the target management node, a copy of the monitoring script is created on the target management node, and the target management node is controlled to execute the copy of the monitoring script, so as to control the target management node to automatically obtain the identifier and status of the target process associated with the target application service; The monitoring status data of the target process is obtained from the target management node.

4. The method according to claim 2, characterized in that, The monitoring script includes: The first query code segment is used to call the API server component provided by the management cluster to send a query request to the target management node. The query request carries the identifier of the target application service. The query request is used to query the identifier and status of each target process associated with the target application service. The query code segment is also used to receive the identifier and status of the target process fed back by the target management node.

5. The method according to claim 1, characterized in that, The suspension script template includes: The second query code segment is used to control the target business node to query each target process associated with the target application service; The detection code segment is used to detect the running status of each target process; The suspension code segment is used to control the target business node to suspend the target process when the target process is in a stopped running state.

6. The method according to claim 1, characterized in that, Before controlling the target management node to access the target business node, the method further includes: The target control node sets up a public key and a private key; and distributes the public key to each business node, while retaining its own private key. Send a public key fingerprint to the target business node; the public key fingerprint triggers the template business node to check whether the public key fingerprint exists in its own key file, and if the public key fingerprint exists, it generates a random string, encrypts the random string with the received public key, and sends the ciphertext to the target control node; Decrypt the received ciphertext using your own private key; The encrypted decryption result is returned to the target service node; the encrypted decryption result triggers the target service node to match the received encrypted decryption result with the random string it generated; if they match, the target service node allows the target management node to access; if they do not match, the target service node does not allow the target management node to access. If access is granted, access the target service node to create a copy of the suspending script on the target service node, and control the target service node to execute the copy of the suspending script.

7. An automated testing method for cloud-native services, characterized in that, The method includes: Receive a copy of the suspension script; the suspension script is generated based on the identifier of the target business node and a pre-stored script template; the suspension script is used to control the target business node to automatically acquire and suspend each target process associated with the target application service; In response to a suspend script execution instruction, a copy of the suspend script is executed.

8. An automated testing tool for cloud-native services, characterized in that, include: The input component is used to receive the identifier of the target application service and the IP address of the target business node where the target application service is located, which are input by the user. The first generation component is used to generate a suspension script based on the identifier of the target business node and a pre-stored script template. A control component is used to create a copy of the suspension script on the target business node based on the IP address of the target application service. Control the target business node to execute a copy of the suspension script, so as to control the target business node to automatically acquire and suspend each target process associated with the target application service; The presentation component is used to acquire and present the monitoring status data of each target process associated with the target application service, in order to determine the test results of the cloud-native service.

9. An automated testing device for cloud-native services, characterized in that, The device includes: The first acquisition unit is used to acquire the identifier of the target application service and the IP address of the target business node where the target application service is located; The first generation unit is used to generate a suspension script based on the identifier of the target business node and a pre-stored script template. The first creation unit is used to create a copy of the suspension script on the target business node according to the IP address of the target application service; The first control unit is used to control the target business node to execute a copy of the suspension script, so as to control the target business node to automatically obtain and suspend each target process associated with the target application service; The first acquisition unit is used to acquire monitoring status data of each target process associated with the target application service, so as to determine the test results of the cloud-native service.

10. An automated testing device for cloud-native services, characterized in that, The device includes: A receiving unit is used to receive a copy of the suspension script; the suspension script is generated based on the identifier of the target business node and a pre-stored script template; the suspension script is used to control the target business node to automatically acquire and suspend each target process associated with the target application service; An execution unit is configured to execute a copy of the suspended script in response to a suspended script execution instruction.

11. An electronic device, characterized in that, include: The system includes a memory and a processor, which are communicatively connected to each other. The memory stores computer instructions, and the processor executes the computer instructions to implement the automatic testing method for cloud-native services as described in any one of claims 1 to 7, or the automatic testing tool for cloud-native services as described in claim 8.

12. A computer storage medium, characterized in that, The computer storage medium stores computer program instructions, which, when executed, implement the automatic testing method for cloud-native services as described in any one of claims 1 to 7, or the automatic testing tool for cloud-native services as described in claim 8.

13. A computer program product, characterized in that, It includes a computer program that, when executed by a processor, implements the automatic testing method for cloud-native services as described in any one of claims 1 to 7, or the automatic testing tool for cloud-native services as described in claim 8.