Operating system testing method, device and equipment, storage medium and program product

Abstract

The embodiment of the invention provides an operating system testing method and device, equipment, a storage medium and a program product. On one hand, the servers corresponding to the various service type tasks are configured on the test equipment, and on the other hand, the multiple clients executing the different service type tasks are deployed on the tested equipment carrying the operating system, so that the networking complexity of the test is reduced. And then under the condition that the server runs, the test equipment controls a plurality of clients to concurrently execute tasks of corresponding service types by sending an instruction which is input by a user and comprises a control instruction for concurrently executing tasks of multiple service types to the tested equipment, so that a complex scene of the tasks of the multiple service types is simulated, and meanwhile, the test efficiency is improved.

Description

Technical Field

[0001] This invention belongs to the field of Internet of Things (IoT) technology, and particularly relates to a method, apparatus, device, storage medium, and program product for operating system testing. Background Technology

[0002] Existing technologies mainly include testing the operating system by adjusting network load using a single indicator, testing the operating system based on testing tools, and testing the operating system based on checksums before and after testing. These existing technologies currently have the following problems: 1) The scheme of testing the operating system by adjusting network load using a single indicator is too limited to the extreme value of that single indicator and has a single task, failing to simulate network load in real multi-tasking scenarios; 2) In the scheme of testing the operating system based on testing tools, the involvement of testing tools leads to complex network topology, too many parameters, and low automation efficiency; 3) The scheme of testing the operating system based on checksums has a single dimension and lacks multi-dimensional consideration of the operating system's operational stability. Summary of the Invention

[0003] This invention provides a method, apparatus, device, storage medium, and program product for operating system testing, which can simulate network load in real multi-tasking scenarios and evaluate the stability of operating system operation from multiple dimensions while reducing network complexity.

[0004] In a first aspect, embodiments of the present invention provide an operating system testing method, applied to a testing device, the testing device being connected to the device under test via a network cable and a serial cable, the testing device including servers corresponding to various business type tasks; the method includes: When servers corresponding to multiple business types of tasks are running, the system receives user input instructions, including control instructions for the concurrent execution of multiple business types of tasks. Send commands to the device under test to control the client machines corresponding to various service types on the device under test to execute the corresponding service type tasks, so as to test the operating system of the device under test.

[0005] Secondly, embodiments of the present invention provide a method for testing an operating system, applied to a device under test (DUT). The DUT is connected to the testing device via a network cable and a serial cable. The DUT includes an operating system and is configured with client machines for various service types. The method includes: Receive instructions sent by the test equipment. These instructions include control instructions for the concurrent execution of various business type tasks. The instructions are user input instructions received by the test equipment when the servers corresponding to the various business type tasks set on the test equipment are running. In response to the instructions, clients of various service types execute their respective service type tasks and send test data to the servers corresponding to the various service type tasks on the test device to perform operating system testing on the device under test.

[0006] Thirdly, embodiments of the present invention provide an operating system testing apparatus, applied to a testing device. The testing device is connected to the device under test via a network cable and a serial cable. The testing device includes servers corresponding to various service types and tasks. The apparatus includes: The receiving unit is used to receive user input instructions when the server corresponding to multiple business type tasks is running. The instructions include control instructions for the concurrent execution of multiple business type tasks. The sending unit is used to send instructions to the device under test (DUT) to control the client machines corresponding to various service types on the DUT to execute their respective service type tasks in order to test the operating system of the DUT.

[0007] Fourthly, embodiments of the present invention provide an operating system testing apparatus applied to a device under test (DUT). The DUT is connected to the testing device via a network cable and a serial cable. The DUT includes an operating system and is configured with client machines for various service types. The apparatus includes: The receiving module is used to receive instructions sent by the test equipment. The instructions include control instructions for the concurrent execution of multiple business type tasks. The instructions are user input instructions received by the device under test when the servers corresponding to the multiple business type tasks set on the test equipment are running. The execution module is used to respond to instructions, with clients of various business types executing their respective business type tasks, and sending test data to the servers corresponding to the various business type tasks on the test device to perform operating system testing on the device under test.

[0008] Fifthly, embodiments of the present invention provide an operating system testing apparatus, the apparatus comprising: a processor, and a memory storing computer program instructions; the processor reads and executes the computer program instructions to implement the operating system testing method as described in the first or second aspect.

[0009] Sixthly, embodiments of the present invention provide a computer storage medium storing computer program instructions, which, when executed by a processor, implement the operating system testing method as described in the first or second aspect. Seventhly, embodiments of the present invention provide a computer program product including a computer program that, when executed by a processor, implements the operating system testing method as described in the first or second aspect.

[0010] This invention discloses a method, apparatus, device, storage medium, and program product for operating system testing. On one hand, it configures servers corresponding to various business type tasks on the testing device; on the other hand, it deploys multiple client machines running different business type tasks on the device under test (DUT) equipped with the operating system, reducing the network complexity of the test. Then, with the servers running, the testing device sends user-input control commands, including concurrent execution instructions for various business type tasks, to the DUT, controlling multiple client machines to concurrently execute tasks of the corresponding business type. This simulates a complex scenario with multiple business type tasks and improves testing efficiency. Attached Figure Description

[0011] To more clearly illustrate the technical solutions of the embodiments of the present invention, the accompanying drawings used in the embodiments of the present invention will be briefly introduced below. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0012] Figure 1 This is a schematic diagram of the architecture of an embedded industrial operating system; Figure 2 This is a flowchart illustrating a method for testing an operating system applied to a testing device, according to an embodiment of the present invention. Figure 3 This is a block diagram illustrating the technical principles of operating system testing methods; Figure 4 This is a flowchart of the TCP task execution process; Figure 5 This is a flowchart of the UDP task execution process; Figure 6 This is a flowchart of the TFTP task execution process; Figure 7 This is a flowchart of the multicast task operation; Figure 8 This is a flowchart of the monitoring task execution process; Figure 9 This is a diagram illustrating the execution steps of tasks across multiple business types; Figure 10 This is a flowchart illustrating a method for testing the operating system of a device under test, provided by an embodiment of the present invention. Figure 11 This is a schematic diagram of the structure of an operating system testing device applied to a testing equipment according to an embodiment of the present invention; Figure 12 This is a schematic diagram of the structure of the device for testing the operating system of the device under test provided in an embodiment of the present invention; Figure 13 This is a schematic diagram of the structure of an operating system testing device provided in an embodiment of the present invention. Detailed Implementation

[0013] The features and exemplary embodiments of various aspects of the present invention will now be described in detail. To make the objectives, technical solutions, and advantages of the present invention clearer, the present invention will be further described in detail below with reference to the accompanying drawings and specific embodiments. It should be understood that the specific embodiments described herein are merely intended to explain the present invention and not to limit the present invention. For those skilled in the art, the present invention can be practiced without some of these specific details. The following description of the embodiments is merely to provide a better understanding of the present invention by illustrating examples of the invention.

[0014] It should be noted that, in this document, relational terms such as "first" and "second" are used merely to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising..." does not exclude the presence of additional identical elements in the process, method, article, or apparatus that includes said element.

[0015] To address the problems of existing technologies, embodiments of the present invention provide a method, apparatus, device, and storage medium for operating system testing. By configuring servers with multiple service types on a test device, and deploying multiple client machines simulating different service types on the device under test (DUT) with a built-in operating system, these client machines interact with the servers. Parallel instructions control the multiple client machines on the DUT to execute tasks and generate network load, thereby enabling the test device to perform testing. This approach is applicable to complex scenarios with multiple service types, and the concurrent execution of these tasks can improve testing efficiency to a certain extent and allow for multi-dimensional assessment of operating system stability. Furthermore, the overall network setup is relatively simple due to the deployment of servers with multiple service types on the test device, effectively reducing testing costs.

[0016] The application scenarios for the device under test can include intelligent transportation, smart grids, or industrial control intelligent controllers, etc. The stability of the operating system is particularly important in industrial sectors, as it is a key factor in ensuring the continuity, reliability, and safety of industrial production. For example... Figure 1 The diagram illustrates the architecture of an embedded industrial operating system. Figure 1As can be seen, the embedded industrial operating system runs on top of the OneOS (One Operation System) base operating system and can also include hardware platforms, industrial components, application modules, and solution units. Hardware platforms can include RISC-V (Reduced Instruction Set Computer V), ARM (Acorn RISC Machine), and others. ARM can include STM32 (STMicroelectronics Microcontroller 32), GD32 (GigaDevice 32), NXP, Rockchip, Chipown, Phytium, and Allwinner. RISC-V can include Supcon Microelectronics and Chipown. Others can include ESP32 (Espressif Systems 32), Loongson, and Infineon. Industrial components can be specifically divided into industrial runtime components, visualization components, and networked components. Industrial runtime components can be divided into Codesys (Controlled Development System) components and domestically produced components. Codesys components include a first motion control component, a first industrial bus, a Corte-M runtime component, a Corte-R5F runtime component, and a Corte-A runtime component. Domestically produced components include a second motion control component, a second industrial component, a Cortex-M runtime component, and a RISC-V runtime component. Visualization components can include QT components, LVGL (Light and Versatile Graphics Library) components, and web visualization components. Networking components can include remote debugging components, network connection components, and OTA (Over-the-Air Technology) components. Solution modules can include standard controller solutions, network controller solutions, functional safety controller solutions, and intelligent instrument display solutions. Application modules can include PLC (Programmable Logic Controller) modules, HMI (Human-Machine Interface) / instrument modules, industrial gateway / DTU (Data Transfer Unit) modules, and DCS (Distributed Control System) modules.The solution provided in this embodiment of the invention can be applied to the networked component module in the industrial components of the embedded industrial operating system to verify the stability of the embedded industrial operating system.

[0017] The method for testing the operating system provided in the embodiments of the present invention will be introduced first below.

[0018] Figure 2 This diagram illustrates a flowchart of a method for testing an operating system on a test device, according to an embodiment of the present invention. The test device can be connected to the device under test (DUT) via a network cable and a serial cable. The network cable establishes communication between the test device and the DUT, while the serial cable connects the serial ports of the two devices, facilitating control and debugging of the DUT by the test device.

[0019] like Figure 2 As shown, the method may include the following steps: Step 210: When the server corresponding to various business type tasks is running, receive instructions input by the user.

[0020] The testing equipment includes servers corresponding to various business types and tasks, and can be used to start servers corresponding to various business types and tasks for stable operation.

[0021] Instructions can include control instructions for the concurrent execution of various business types of tasks. Depending on the hardware resources of the device under test (DUT) and the changing application scenarios, the business types of tasks can vary greatly. Even within the same application scenario, there may be a large number of concurrent tasks of multiple business types, such as data acquisition, image processing, network interaction, and DUT monitoring. Such concurrent application scenarios of multiple business types place extremely high demands on the stability of the entire operating system, from the upper-layer applications to the underlying kernel and drivers. Operating system stability is a multi-dimensional and systematic concept, measuring the operating system's ability to continuously and reliably provide services under various expected and unexpected conditions.

[0022] Step 220: Send instructions to the device under test to control the client machines corresponding to various service types on the device under test to execute the corresponding service type tasks, so as to test the operating system of the device under test.

[0023] After receiving the user's input command, the test device forwards the command to the device under test, thereby controlling the start or stop of the network load test of the operating system of the device under test in scenarios with concurrent tasks of multiple service types.

[0024] The client machine here can refer to a physical computer or the dedicated computing software installed on the client. The operating system is a program built into the device under test that works in conjunction with the computer's various hardware components to interact with the user.

[0025] Each client runs within the operating system environment of its corresponding device under test (DUT), which is recognized by the server. A single DUT can have multiple clients, each responsible for executing various business tasks. After executing tasks, the clients generate data streams. These data streams from multiple clients converge to form the total network load of the operating system, allowing the test device to perform stability tests on the operating system under various network loads. From the upper-layer network load to the network protocol stack, file system, kernel task management, and drivers, comprehensive verification of the stability of the entire operating system and the DUT can be achieved.

[0026] The testing method in this embodiment can simulate complex application scenarios such as real-world industrial control and smart grids. Through long-term, multi-task concurrent network load stress testing, it can comprehensively verify the stable operation capability of the real-time operating system in complex network environments, meeting the stringent reliability requirements of industrial-grade systems and ensuring uninterrupted critical tasks. This lays the foundation for the application of real-time operating systems in industries and other fields, increasing user confidence. By thoroughly examining the adaptability of the operating system in harsh network environments through improved testing methods, potential stability vulnerabilities can be identified and resolved to the greatest extent, fundamentally improving the quality of the operating system product. Once deployed, the reliable operation of the operating system can be guaranteed, reducing the likelihood of downtime and other failures, thereby significantly reducing maintenance and troubleshooting costs.

[0027] In one embodiment, the server may include at least one of the following: a Transmission Control Protocol (TCP) server, a User Datagram Protocol (UDP) server, a Trivial File Transfer Protocol (TFTP) server, and a multicast source server. Accordingly, these servers may correspond to at least one service type of data, including TCP tasks, UDP tasks, TFTP tasks, and multicast tasks.

[0028] These tasks can be prioritized, allowing TCP, UDP, TFTP, and multicast tasks to be run in order of priority, efficiently simulating complex network service scenarios and enabling seamless integration with the test equipment's load environment. It's worth noting that these tasks can run simultaneously on both single-core and multi-core CPUs, and other computing units such as GPUs can be introduced when necessary.

[0029] In one embodiment, the servers corresponding to the various business types of tasks included in the test equipment can be virtualized servers.

[0030] Considering that the network servers and business types involved in the solution of this invention may face many situations, in order to build an efficient test network load environment with limited hardware resources, virtualization technology can be used to simulate multiple fully functional, isolated, and independently running virtualized servers on a single machine.

[0031] In one embodiment, the operating system of the device under test may include an embedded operating system or a distributed IoT operating system. A distributed IoT operating system refers to system software running on IoT terminal devices, which differs from the operating systems on traditional personal computing or personal smart terminal devices; it exists to better serve IoT applications. An embedded operating system, also known as a dedicated operating system, is a specialized operating system embedded within non-computer devices (such as home appliances, automobiles, and industrial machinery) to perform specific tasks. Unlike commonly used general-purpose operating systems (such as Windows), it is characterized by its specialization, high reliability and stability, and high real-time performance. Embedded operating systems are widely present in all aspects of daily life, such as consumer electronics, automotive electronics, industrial control, and medical devices.

[0032] In one embodiment, after the test device sends instructions to the device under test to control the clients corresponding to various service type tasks on the device under test to execute their respective service type tasks, the operating system testing method may further include: The test equipment receives test data sent by clients corresponding to various service types on the device under test. The testing equipment determines the target business type task to which the test data belongs; If the test equipment does not include the server corresponding to the target business type task, the test equipment sends test data to the server corresponding to the target business type task set on the cloud server to test the operating system of the device under test.

[0033] This embodiment uses a cloud server to share part of the network load in the test environment, which can cope with test failures under unexpected circumstances and reduce the operating costs of test equipment.

[0034] In one embodiment, the operating system testing method may further include: The test equipment receives configuration information input by the user. The configuration information includes adding, deleting, or updating servers corresponding to business type tasks, as well as the control parameters of the servers corresponding to business type tasks.

[0035] The test equipment is configured with servers corresponding to various business types of tasks based on the configuration information.

[0036] The testing equipment can receive parameters from the servers corresponding to various business types and tasks, thereby adjusting network traffic characteristics such as data type and packet size, and applying different levels of customized network load pressure to the operating system of the device under test. This flexible configuration and control of network load enables diverse testing, covering as many potential problems as possible that may arise under corresponding environmental parameters during subsequent formal use.

[0037] In one embodiment, the user input received by the test device can be shell commands.

[0038] At this point, the test device can use shell commands to execute network load test start or stop commands to control the device under test to start or stop concurrent test tasks of multiple service types. Afterwards, the stability and reliability of the device under test and its operating system can be observed and analyzed through shell log recording.

[0039] In one embodiment, the multiple service type tasks include monitoring tasks; the instructions also include monitoring instructions; sending instructions to the device under test to control the clients corresponding to the multiple service type tasks on the device under test to execute the corresponding service type tasks may include: Send instructions to the device under test to control the clients corresponding to various first service type tasks on the device under test to execute the corresponding service type tasks, and control the clients corresponding to the monitoring tasks on the device under test to monitor the status of the clients corresponding to various first service type tasks.

[0040] The first service type task is a service type task other than the monitoring task among the various service types included in the instruction. In this embodiment, a monitoring task is provided to monitor the behavior of the operating system of the device under test under different network loads. This can include not only the execution status of the first service type task, but also CPU utilization and memory usage (especially whether there is a memory leak), so as to monitor and evaluate the network adaptability and stability performance of the operating system of the device under test.

[0041] In one embodiment, after sending instructions to the device under test to control the clients corresponding to various service type tasks on the device under test to execute their respective service type tasks in order to test the operating system of the device under test, the operating system testing method may further include: generating a test report, the test report including the status of the clients corresponding to various first service type tasks.

[0042] The system monitors and records the operating system's runtime status logs in real time. These logs include not only the execution status, CPU utilization, and memory usage of the first type of business task mentioned above, but also, if the server corresponding to the first type of business task includes a TCP server and a UDP server, the logs may also include TCP connection status and UDP port usage status. These runtime status logs directly reflect the operating system's performance under network load pressure and are crucial evidence of the operating system's stability. Extracting the key information needed by the user from the runtime status logs allows for the generation of more concise test reports, facilitating quick review by the user.

[0043] Furthermore, during the testing process, network traffic between the operating systems of the test device and the device under test can be captured using network packet capture tools (such as Wireshark), recording the data interaction process between the two ends. Network traffic data can reflect the actual network load, thus corroborating the network load level of this testing solution.

[0044] If any abnormalities, crashes, or other instabilities are found in the system under test during the test, the maintenance personnel will also record the error recovery, repair measures, and related information.

[0045] In addition, by connecting to the device under test, hardware performance data such as CPU operating frequency, temperature and power supply voltage can be monitored and recorded during the test, which can be used to verify the stability of the operating system under network load pressure.

[0046] Data captured by network packet capture tools, data recorded by maintenance personnel, and hardware performance data can be flexibly selected and displayed in the test report as needed.

[0047] To avoid the network load simulation in this application not fully covering all complex scenarios in real-world applications, continuous follow-up research on actual application needs can be conducted after testing to update and optimize test cases in a timely manner. Alternatively, learning technologies can be introduced to automatically collect and analyze existing network data and generate test cases that conform to actual distributions. A test case refers to a set of specific, executable, and measurable test steps and rules. Its purpose is to systematically verify whether the operating system can run continuously and reliably under various network load pressure scenarios, without performance degradation or service interruption. Specifically, it involves having the client machines on the device under test perform certain types of business tasks and generate network load pressure to facilitate testing.

[0048] To avoid inefficiency and prolonged testing cycles caused by long-term continuous testing, parallel testing with multiple test cases can be introduced, or test case discovery and optimization techniques can be employed to improve the efficiency of discovering high-intensity test cases. Compared to ordinary test cases (such as checking whether a function is available), these methods can uncover the causes of deeper and more serious problems, enabling deeper-level operating system testing.

[0049] A specific example is provided here to illustrate the implementation process of the solution in this application.

[0050] like Figure 3 As shown, a technical principle block diagram of the operating system testing method is first provided. The test equipment is connected to the shell via a serial cable to control and debug the device under test (DUT), and the two are directly connected via a network cable for network communication. The test equipment runs a TCP server, a UDP server, a TFTP server, and a multicast source server to send relevant data. The DUT runs an embedded real-time operating system (such as OneOS embedded real-time industrial operating system). In the kernel and system components, TCP tasks, UDP tasks, TFTP tasks, and multicast tasks are created respectively by calling the socket interface through C language programming. Finally, a monitoring task is implemented to monitor the running status of each task, TCP connection status, UDP port usage status, CPU utilization, and memory usage, etc.

[0051] The test equipment is configured with the following servers: 1) A TCP server runs and listens for connections from the device under test (DUT), immediately replying with the same data upon receiving connection data. 2) A UDP server runs and listens for connections from the DUT, immediately replying with the same data upon receiving connection data. 3) A TFTP server runs, storing a large file in a specified local directory. 4) A multicast source server uses VLC (VideoLAN Client) software to loop through a UDP video stream with a specified multicast address and port.

[0052] Configure the task implementation process for the device under test. 1) Set the TCP task priority to 22 and deploy the client machine. For example... Figure 4 The diagram shows the TCP task execution flowchart. First, a socket is created and connected to the TCP server. Data packets of lengths 64 bytes, 512 bytes, and 2048 bytes are sent to the TCP server in a loop without delay, and the server replies with identical data until the connection is closed. 2) Set the UDP task priority to 22 and deploy the client. (The diagram is incomplete and requires further context.) Figure 5The diagram shows the UDP task execution flowchart. First, a socket is created, and data packets of lengths 64 bytes, 512 bytes, and 2048 bytes are sent to the UDP server in a loop without delay, and the server replies with the same data. 3) Set the TFTP task priority to 22 and deploy the client. (The diagram is incomplete and requires further context.) Figure 6 The diagram shows the TFTP task execution flowchart. First, the file is downloaded from the TFTP server, then the file is uploaded back to the TFTP server, and finally the local file on the tested device is deleted. This process is repeated continuously. 4) Set the multicast task priority to 22, create a socket, as shown... Figure 7 As shown, a flowchart of the multicast task operation is provided. First, bind the specified port of the multicast group, join the multicast group, and continuously receive data from the multicast group while actively sending UDP packets to the multicast group address. 5) Set the monitoring task priority to 17, such as... Figure 8 The monitoring task execution flowchart is shown. The following monitoring information is output to the shell every 5 minutes: `show_task`, which displays the running status of the above four tasks, such as running, suspending, sleeping, ready, and blocking; `cpu_usage`, which displays the real-time CPU usage during the entire operating system operation; `show_mem`, which displays the real-time memory usage during the entire operating system operation; `list_tcps`, which displays the TCP server connection status and traffic; and `list_udps`, which displays the UDP server port operation status.

[0053] The above five tasks are encapsulated into a single shell command: `netload_test start / stop`, which starts or stops the network load test. The priority of this shell task can be set to 16. In this example, lower priority values ​​indicate higher priority.

[0054] The test equipment was started and all the above servers were running stably, such as... Figure 9 As shown in the schematic diagram of the multi-service type task execution steps, the test device sends shell execution commands to control each client in the device under test to start or stop the concurrent test tasks of TCP, UDP, TFTP and multicast tasks. The test device also records and saves the monitoring information during the execution of the monitoring tasks in real time through the shell log, so as to observe and analyze the stability and reliability of the device under test and its operating system.

[0055] like Figure 10As shown in the diagram, this invention also provides a flowchart illustrating a method for testing the operating system of a device under test (DUT). The DUT can be connected to the test device via a network cable and a serial cable. The DUT may include an operating system and can be configured with clients for various service types. The method may include: Step 1010: Receive instructions sent by the test device. The instructions include control instructions for the concurrent execution of multiple business type tasks. The instructions are user input instructions received by the test device when the servers corresponding to the multiple business type tasks set on the test device are running. Step 1020: In response to the instruction, the clients of various service type tasks execute their respective service type tasks and send test data to the servers corresponding to the various service type tasks on the test device to perform operating system testing on the device under test.

[0056] In one embodiment, the multiple service type tasks include monitoring tasks; the instructions also include monitoring instructions; in response to the instructions, the client machines of the multiple service type tasks execute their respective service type tasks and send test data to the servers corresponding to the multiple service type tasks on the test device, which may include: In response to the instructions, the client machines corresponding to the various first-type service tasks on the device under test execute their respective service type tasks, and the client machines corresponding to the monitoring tasks monitor the status of the clients corresponding to the various first-type service tasks. The client machines corresponding to the various first-type service tasks send test data and the status of the monitored clients to the server corresponding to the service type task of the test device.

[0057] In one embodiment, the instruction can be a shell instruction.

[0058] In one embodiment, before the clients of various service type tasks execute their respective service type tasks in response to instructions, the operating system testing method further includes: The device under test encapsulates client machines corresponding to various business types and tasks into shell commands.

[0059] The device under test encapsulates client functions for various types of tasks into shell commands. Only when the device under test receives shell commands sent by the test device can it identify and execute tasks of the corresponding business type.

[0060] In one embodiment, the operating system of the device under test includes an embedded operating system or a distributed Internet of Things (IoT) operating system.

[0061] In one embodiment, the tasks of multiple service types include at least one of Transmission Control Protocol (TCP) task, User Datagram Protocol (UDP) task, Simple File Transfer Protocol (TFTP) task, and Multicast Source Service task, as well as a monitoring task.

[0062] like Figure 11 As shown, an embodiment of the present invention provides an apparatus for operating system testing of a testing device. The testing device is connected to the device under test via a network cable and a serial cable. The testing device includes servers corresponding to various service types and tasks. The apparatus may include a receiving unit 911 and a sending unit 920.

[0063] The receiving unit 1111 is used to receive user input instructions when the server corresponding to multiple business type tasks is running. The instructions include control instructions for the concurrent execution of multiple business type tasks.

[0064] The sending unit 1120 is used to send instructions to the device under test to control the client machines corresponding to various service types on the device under test to execute the corresponding service type tasks, so as to test the operating system of the device under test.

[0065] In one embodiment, the apparatus for operating system testing of the test equipment may further include a data receiving unit 1130, a determining unit 1140, and a data sending unit 1150.

[0066] The data receiving unit 1130 is used to receive test data sent by the clients corresponding to the various service types on the device under test after sending instructions to the device under test to control the clients corresponding to the various service types on the device under test to execute the corresponding service types.

[0067] The determination unit 1140 is used to determine the target business type task to which the test data belongs.

[0068] The data sending unit 1150 is used to send test data to the server corresponding to the target business type task set on the cloud server when the test device does not include the server corresponding to the target business type task, so as to test the operating system of the device under test.

[0069] In one embodiment, multiple service type tasks may include monitoring tasks, and instructions may further include monitoring instructions. The sending unit 1120 may also be used for: Send instructions to the device under test to control the clients corresponding to various first service type tasks on the device under test to execute their respective service type tasks, and control the clients corresponding to the monitoring tasks on the device under test to monitor the status of the clients corresponding to various first service type tasks; wherein, the first service type task is the service type task other than the monitoring task among the various service types included in the instructions.

[0070] In one embodiment, the apparatus for operating system testing of the test equipment may further include a generation unit 1160.

[0071] The generation unit 1160 is used to generate a test report after sending instructions to the device under test to control the clients corresponding to various service type tasks on the device under test to execute the corresponding service type tasks in order to test the operating system of the device under test. The test report includes the status of the clients corresponding to various first service type tasks.

[0072] In one embodiment, the apparatus for operating system testing of the test equipment may further include an information receiving unit 1170 and a configuration unit 11110.

[0073] The information receiving unit 1170 is used to receive configuration information input by the user. The configuration information includes adding, deleting or updating the server corresponding to the business type task, as well as the control parameters of the server corresponding to the business type task.

[0074] Configuration unit 11110 is used to configure servers corresponding to various business type tasks based on configuration information.

[0075] like Figure 12 The diagram shows a structural schematic of an apparatus for testing the operating system of a device under test (DUT). The DUT is connected to the test equipment via a network cable and a serial cable. The DUT includes an operating system and has client machines configured with various service types. The apparatus may include a receiving module 1212 and an execution module 1220.

[0076] The receiving module 1212 is used to receive instructions sent by the test device. The instructions include control instructions for the concurrent execution of multiple business type tasks. The instructions are user input instructions received by the device under test when the servers corresponding to the multiple business type tasks set on the test device are running.

[0077] The execution module 1220 is used to respond to instructions, with clients of various business type tasks executing their respective business type tasks and sending test data to the servers of various business type tasks on the test device to perform operating system testing on the device under test.

[0078] In one embodiment, the multiple service type tasks may include monitoring tasks; the instructions may also include monitoring instructions. The execution module 1220 may further be configured to: respond to the instructions, have the clients corresponding to the multiple first service type tasks on the device under test execute their respective service type tasks, and have the client corresponding to the monitoring task monitor the status of the clients corresponding to the multiple first service type tasks, and send test data and the monitored status of the clients corresponding to the multiple first service type tasks to the server corresponding to the service type task on the test device through the clients corresponding to the multiple service type tasks.

[0079] In one embodiment, the apparatus for operating system testing of the device under test may further include a packaging module 1330.

[0080] The encapsulation module 1330 is used to encapsulate the client corresponding to the various business type tasks into shell commands before the client executes the corresponding business type task in response to the command.

[0081] Figure 13 The diagram shows a hardware structure schematic of an operating system testing device provided in an embodiment of the present invention.

[0082] A device for testing an operating system may include a processor 1301 and a memory 1302 storing computer program instructions.

[0083] Specifically, the processor 1301 may include a central processing unit (CPU), an application specific integrated circuit (ASIC), or one or more integrated circuits that can be configured to implement the embodiments of the present invention.

[0084] Memory 1302 may include mass storage for data or instructions. For example, and not limitingly, memory 1302 may include a hard disk drive (HDD), floppy disk drive, flash memory, optical disk, magneto-optical disk, magnetic tape, or Universal Serial Bus (USB) drive, or a combination of two or more of these. In one instance, memory 1302 may include removable or non-removable (or fixed) media, or memory 1302 may be non-volatile solid-state memory. Memory 1302 may be internal or external to the integrated gateway disaster recovery device.

[0085] In one example, memory 1302 may include read-only memory (ROM), random access memory (RAM), disk storage media device, optical storage media device, flash memory device, electrical, optical, or other physical / tangible memory storage device. Thus, typically, memory includes one or more tangible (non-transitory) computer-readable storage media (e.g., memory devices) encoded with software including computer-executable instructions, and when the software is executed (e.g., by one or more processors), it is operable to perform the operations described with reference to the method according to one aspect of this disclosure.

[0086] The processor 1301 reads and executes computer program instructions stored in memory 1302 to achieve... Figure 2 or Figure 9 An operating system testing method is shown in the embodiment.

[0087] Furthermore, in conjunction with the operating system testing method described in the above embodiments, this invention can be implemented using a computer storage medium. This computer storage medium stores computer program instructions; when these computer program instructions are executed by a processor, they implement any of the operating system testing methods described in the above embodiments.

[0088] This application also provides a computer program product, including a computer program that, when executed by a processor, implements any of the operating system testing methods described in the above embodiments.

[0089] It should be clarified that the present invention is not limited to the specific configurations and processes described above and shown in the figures. For the sake of brevity, detailed descriptions of known methods are omitted here. In the above embodiments, several specific steps are described and shown as examples. However, the method process of the present invention is not limited to the specific steps described and shown. Those skilled in the art can make various changes, modifications, and additions, or change the order of steps, after understanding the spirit of the present invention.

[0090] The functional blocks shown in the above-described structural diagram can be implemented as hardware, software, firmware, or a combination thereof. When implemented in hardware, they can be, for example, electronic circuits, application-specific integrated circuits (ASICs), appropriate firmware, plug-ins, function cards, etc. When implemented in software, the elements of this invention are programs or code segments used to perform the required tasks. Programs or code segments can be stored on a machine-readable medium or transmitted over a transmission medium or communication link via data signals carried in a carrier wave. "Machine-readable medium" can include any medium capable of storing or transmitting information. Examples of machine-readable media include electronic circuits, semiconductor memory devices, read-only memory (ROM), flash memory, erasable read-only memory (EROM), floppy disks, compact disc read-only memory (CD-ROM), optical disks, hard disks, fiber optic media, radio frequency (RF) links, etc. Code segments can be downloaded via computer networks such as the Internet, intranets, etc.

[0091] It should also be noted that the exemplary embodiments mentioned in this invention describe methods or systems based on a series of steps or apparatus. However, this invention is not limited to the order of the steps described above; that is, the steps can be performed in the order mentioned in the embodiments, or in a different order, or several steps can be performed simultaneously.

[0092] The aspects of this disclosure have been described above with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this disclosure. It should be understood that each block in the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing apparatus to produce a machine such that these instructions, executable via the processor of the computer or other programmable data processing apparatus, enable the implementation of the functions / actions specified in one or more blocks of the flowchart illustrations and / or block diagrams. Such a processor can be, but is not limited to, a general-purpose processor, a special-purpose processor, a special application processor, or a field-programmable logic circuit. It is also understood that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, can also be implemented by special-purpose hardware performing the specified functions or actions, or can be implemented by a combination of special-purpose hardware and computer instructions.

[0093] The above description is merely a specific embodiment of the present invention. Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working processes of the systems, modules, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here. It should be understood that the protection scope of the present invention is not limited thereto. Any person skilled in the art can easily conceive of various equivalent modifications or substitutions within the technical scope disclosed in the present invention, and these modifications or substitutions should all be covered within the protection scope of the present invention.

Claims

1. A method of operating a system test, characterized by, The application is applied to a test device connected with a device under test through a network cable and a serial cable, and the test device comprises servers corresponding to a plurality of business type tasks; the method comprises: In the case that the servers corresponding to the plurality of business type tasks are running, receiving an instruction input by a user, wherein the instruction comprises a control instruction for concurrent execution of the plurality of business type tasks; sending the instruction to the device under test to control the clients corresponding to the plurality of business type tasks on the device under test to respectively execute the corresponding business type tasks, so as to test an operating system of the device under test.

2. The method of claim 1, wherein, The servers corresponding to the plurality of business type tasks comprised by the test device are virtualization servers.

3. The method of claim 1, wherein, After the instruction is sent to the device under test to control the clients corresponding to the plurality of business type tasks on the device under test to respectively execute the corresponding business type tasks, the method further comprises: receiving test data respectively sent by the clients corresponding to the plurality of business type tasks on the device under test; determining a target business type task to which the test data belongs; in the case that the test device does not comprise a server corresponding to the target business type task, sending the test data to a server corresponding to the target business type task set on a cloud server, so as to test the operating system of the device under test.

4. The method of claim 1, wherein, The plurality of business type tasks comprise a monitoring task; the instruction further comprises a monitoring instruction; and the sending of the instruction to the device under test to control the clients corresponding to the plurality of business type tasks on the device under test to respectively execute the corresponding business type tasks comprises: sending the instruction to the device under test to control the clients corresponding to a plurality of first business type tasks on the device under test to respectively execute the corresponding business type tasks, and to control a client corresponding to a monitoring task on the device under test to monitor states of the clients corresponding to the plurality of first business type tasks; wherein the first business type tasks are business type tasks other than the monitoring task in the plurality of business type tasks included in the instruction.

5. The method of claim 4, wherein, After the instruction is sent to the device under test to control the clients corresponding to the plurality of business type tasks on the device under test to respectively execute the corresponding business type tasks, so as to test the operating system of the device under test, the method further comprises: generating a test report, wherein the test report comprises states of the clients corresponding to the plurality of first business type tasks.

6. The method of claim 1, wherein, The instruction is a shell instruction.

7. The method according to any one of claims 1 to 6, characterized in that, The servers comprise at least one of a transmission control protocol (TCP) server, a user datagram protocol (UDP) server, a trivial file transfer protocol (TFTP) server, and a multicast source server.

8. The method according to any one of claims 1 to 6, characterized in that, The method further comprises: receiving configuration information input by a user, wherein the configuration information comprises adding, deleting, or updating a server corresponding to a business type task, and a control parameter of the server corresponding to the business type task; configuring the servers corresponding to the plurality of business type tasks based on the configuration information.

9. The method of claim 1, wherein, The operating system comprises an embedded operating system or a distributed Internet of Things operating system.

10. A method of operating a system test, characterized by, The application is applied to a device under test, which is connected with a test device through a network cable and a serial cable, and comprises an operating system and a client of a plurality of service type tasks; the method comprises: receiving an instruction sent by the test device, wherein the instruction comprises a control instruction of concurrent execution of the plurality of service type tasks, and the instruction is an instruction input by a user and received by the test device in a case where servers corresponding to the plurality of service type tasks on the test device are running; in response to the instruction, the client of the plurality of service type tasks respectively executes corresponding service type tasks, and sends test data to the servers corresponding to the plurality of service type tasks on the test device to perform operating system testing of the device under test.

11. The method of claim 10, wherein, The plurality of service type tasks comprise a monitoring task; the instruction further comprises a monitoring instruction; and in response to the instruction, the client of the plurality of service type tasks respectively executes corresponding service type tasks, and sends test data to the servers corresponding to the plurality of service type tasks on the test device, comprising: in response to the instruction, the client of a plurality of first service type tasks on the device under test respectively executes corresponding service type tasks, the client corresponding to the monitoring task executes monitoring of states of the clients of the plurality of first service type tasks, and sends test data and the monitored states of the clients of the plurality of first service type tasks to the servers corresponding to the service type tasks on the test device through the clients corresponding to the plurality of service type tasks.

12. The method of claim 10, wherein, The instruction is a shell instruction.

13. The method of claim 12, wherein, Before the response to the instruction, the method further comprises: encapsulating the clients corresponding to the plurality of service type tasks into a shell instruction.

14. The method according to any one of claims 10 to 13, characterized in that, The operating system comprises an embedded operating system or a distributed Internet of Things operating system.

15. The method according to any one of claims 10 to 13, characterized in that, The plurality of service type tasks comprise at least one of a transmission control protocol (TCP) task, a user datagram protocol (UDP) task, a simple file transfer protocol (TFTP) task and a multicast source service task, and a monitoring task.

16. An apparatus for operating system testing, the apparatus comprising: The application is applied to a test device, which is connected with a device under test through a network cable and a serial cable, and comprises servers corresponding to a plurality of service type tasks; the device comprises: a receiving unit, configured to receive an instruction input by a user in a case where the servers corresponding to the plurality of service type tasks are running, wherein the instruction comprises a control instruction of concurrent execution of the plurality of service type tasks; a sending unit, configured to send the instruction to the device under test to control clients corresponding to the plurality of service type tasks on the device under test to respectively execute corresponding service type tasks to perform operating system testing of the device under test.

17. An apparatus for operating system testing, the apparatus comprising: The application is applied to a device under test, which is connected with a test device through a network cable and a serial cable, and comprises an operating system and a client of a plurality of service type tasks; the device comprises: The receiving module is configured to receive an instruction sent by a test device, the instruction comprising a control instruction for concurrent execution of multiple service type tasks, and the instruction is an instruction input by a user and received by the DUT in a case where servers corresponding to the multiple service type tasks are running on the test device; The execution module is configured to, in response to the instruction, execute the corresponding service type tasks by the clients of the multiple service type tasks respectively, and send test data to the servers corresponding to the multiple service type tasks on the test device, so as to perform the operating system test of the DUT.

18. An operating system testing device, characterized in that, The device comprises a processor and a memory storing computer program instructions; the processor reads and executes the computer program instructions to implement the operating system test method according to any one of claims 1 to 9, or the processor reads and executes the computer program instructions to implement the operating system test method according to any one of claims 10 to 15.

19. A computer-readable storage medium, characterized in that, The computer storage medium stores computer program instructions, and the computer program instructions are executed by the processor to implement the operating system test method according to any one of claims 1 to 9, or the computer program instructions are executed by the processor to implement the operating system test method according to any one of claims 10 to 15.

20. A computer program product, characterised in that, The computer program is executed by the processor to implement the operating system test method according to any one of claims 1 to 9, or the computer program is executed by the processor to implement the operating system test method according to any one of claims 10 to 15.

Images