Test processing method and device, electronic equipment and storage medium

Abstract

The invention discloses a test processing method and device, electronic equipment and a storage medium. According to the specific scheme, the method comprises the steps of determining a target equipment system type based on a received test processing request; determining a target test case according to the target device system type and the test case set configuration information; determining target test case driving information according to the target test case and the test case driving information; determining to-be-tested target equipment based on the target test case driving information and the equipment management information; when the running state of the target equipment is a normal state, locking the target equipment to obtain the locked target equipment, and updating the system type of the locked target equipment based on the system type of the target equipment to obtain the updated target equipment; and performing test processing on the updated target equipment based on the target test case to obtain a target test result. According to the invention, the test rate and the test accuracy are improved, and the applicability of test processing is improved.

Description

Technical Field

[0001] The present invention relates to the technical field of equipment testing, and in particular to a testing processing method, device, electronic equipment and storage medium. Background Art

[0002] With the development of computers, the requirements for equipment stability, reliability and safety are getting higher and higher. Therefore, it is necessary to test the equipment to ensure its quality.

[0003] At present, the main way to test and process the equipment is to record the device information of the equipment under test through an Excel file, and to test and process the equipment under test based on the device information of the equipment under test. However, the above method has some problems in the scenario of multi-person collaborative operation. For example, if the test management equipment in area A and area B processes the same equipment under test based on the same test case at the same time, it will lead to repeated testing of the equipment under test, resulting in test redundancy. If the same equipment under test is processed based on different test cases, it will not only affect the test speed, but also fail to obtain accurate test results. In addition, since different equipment under test corresponds to different system types, that is, different equipment under test has different system version numbers, it is necessary to configure corresponding test cases for each equipment under test in the above method, and the test cases that need to be configured are numerous and complex, and the applicability of the test cases is not high. Summary of the invention

[0004] The present invention provides a test processing method, device, electronic equipment and storage medium, which improve the test rate and test accuracy and improve the applicability of the test processing.

[0005] According to one aspect of the present invention, a test processing method is provided, the method comprising:

[0006] Determining a target device system type to be tested based on the received test processing request;

[0007] Determine the target test case to be used according to the target device system type and the test case set configuration information pre-configured for multiple device system types;

[0008] Determine target test case driving information corresponding to the target test case based on the target test case and the test case driving information pre-configured for the plurality of test cases;

[0009] Determine a target device to be tested based on target test case drive information and device management information pre-configured for multiple test devices;

[0010] When the running state of the target device is normal, the target device is locked to obtain a locked target device, and a system type update process is performed on the locked target device based on the system type of the target device to obtain an updated target device;

[0011] The updated target device is tested based on the target test case to obtain the target test result.

[0012] According to another aspect of the present invention, there is provided a test processing device, the device comprising:

[0013] A system type determination module, used to determine the system type of the target device to be tested based on the received test processing request;

[0014] A test case determination module, used to determine the target test case to be used according to the target device system type and the test case set configuration information pre-configured for multiple device system types;

[0015] A use case driving information determination module, used to determine the target test case driving information corresponding to the target test case based on the target test case and the test case driving information pre-configured for multiple test cases;

[0016] A target device determination module, used to determine a target device to be tested based on target test case drive information and device management information pre-configured for multiple test devices;

[0017] The device update module is used to lock the target device when the target device is in a normal operating state to obtain the locked target device, and update the system type of the locked target device based on the system type of the target device to obtain the updated target device;

[0018] The device testing module is used to test the updated target device based on the target test case to obtain the target test result.

[0019] According to another aspect of the present invention, there is provided an electronic device, the electronic device comprising:

[0020] at least one processor; and

[0021] a memory communicatively connected to at least one processor; wherein,

[0022] The memory stores a computer program that can be executed by at least one processor. The computer program is executed by the at least one processor so that the at least one processor can execute the test processing method of any embodiment of the present invention.

[0023] According to another aspect of the present invention, a computer-readable storage medium is provided. The computer-readable storage medium stores computer instructions. The computer instructions are used to enable a processor to implement the test processing method of any embodiment of the present invention when executed.

[0024] According to another aspect of the present invention, a computer program product is provided, comprising a computer program, wherein the computer program implements the test processing method according to any embodiment of the present invention when executed by a processor.

[0025] The technical solution of the embodiment of the present invention determines the system type of the target device to be tested according to the received test processing request, determines the test environment for subsequent test processing, and realizes the decoupling of the system environment and the test environment of the test device. According to the target device system type and the test case set configuration information pre-configured for multiple device system types, the target test case to be used is determined to implement the test processing of the test device based on the target test case. According to the target test case and the test case drive information, the target test case drive information corresponding to the target test case is determined to determine the target device to be tested based on the target test case drive information and the device management information. When the running state of the target device is normal operation, the target device is locked to obtain the locked target device, ensuring that the subsequent test process can be carried out smoothly without interference. Based on the target device system type, the system type of the locked target device is updated to obtain the updated target device. According to the target test case, the updated target device is tested to obtain the target test result. The present invention solves the problems of test redundancy, low test efficiency and inaccurate test results caused by simultaneous operation of the same test device in the prior art by locking the target device. By determining the target device system type, the target test case corresponding to the target device system type, and updating the system type of the target device, the test processing of the target device under the target device system type is achieved, which solves the problem of configuring test cases for each device to be tested in the prior art, resulting in numerous and complex test cases and low applicability of the test cases, improves the speed and accuracy of the target device test, and improves the applicability of the test processing.

[0026] It should be understood that the contents described in this section are not intended to identify the key or important features of the embodiments of the present invention, nor are they intended to limit the scope of the present invention. Other features of the present invention will become easily understood through the following description. BRIEF DESCRIPTION OF THE DRAWINGS

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

[0028] Figure 1 is a flow chart of a test processing method provided by an embodiment of the present invention;

[0029] Figure 2 is a flow chart of a test processing method provided by an embodiment of the present invention;

[0030] Figure 3 is a flowchart of a test processing method provided by an embodiment of the present invention;

[0031] Figure 4 is a structural schematic diagram of a test processing device provided by an embodiment of the present invention;

[0032] Figure 5 It is a structural schematic diagram of an electronic device for implementing the test processing method of an embodiment of the present invention. DETAILED DESCRIPTION

[0033] In order to enable those skilled in the art to better understand the scheme of the present invention, the technical scheme in the embodiments of the present invention will be clearly and completely described below in conjunction with the drawings in the embodiments of the present invention. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without creative work should fall within the scope of protection of the present invention.

[0034] It should be noted that the terms "first", "second", etc. in the specification and claims of the present invention and the above-mentioned drawings are used to distinguish similar objects, and are not necessarily used to describe a specific order or sequence. It should be understood that the data used in this way can be interchanged where appropriate, so that the embodiments of the present invention described herein can be implemented in an order other than those illustrated or described herein. In addition, the terms "including" and "having" and any variations thereof are intended to cover non-exclusive inclusions, for example, a process, method, system, product or device that includes a series of steps or units is not necessarily limited to those steps or units that are clearly listed, but may include other steps or units that are not clearly listed or inherent to these processes, methods, products or devices.

[0035] Embodiment 1

[0036] Figure 1This is a flow chart of a test processing method provided by the first embodiment of the present invention. This embodiment can be applied to the case where a target device is tested based on a target test case corresponding to the target device system type in an embedded test scenario. The method can be executed by a test processing device, which can be implemented in the form of hardware and / or software. The test processing device can be configured in an electronic device such as a mobile phone, a computer or a server. Figure 1 As shown, the method includes:

[0037] S110: Determine the system type of the target device to be tested based on the received test processing request.

[0038] Among them, in the process of device development, in order to ensure the stability of the device, the device is usually tested. That is, the request for testing the device is a test processing request. Optionally, the device architecture type that currently needs to be tested can be included in the test processing request. For example, the device architecture type that currently needs to be tested and the target device system type corresponding to the device architecture type can be determined according to the base information carried by the test processing request. The target device system type can be the device system type corresponding to the device architecture type in the test processing request. For example, the target device system type can be the system type of SylixOS 4.0 version.

[0039] Specifically, when a test processing request is received, the test processing request is parsed to determine the device architecture type that currently needs to be tested and processed. According to the device architecture type corresponding to the test processing request, the target device system type that currently needs to be tested is determined.

[0040] In an embodiment of the present invention, a method for determining the target device system type may be: parsing the test processing request to determine the target device architecture type to be tested; and determining the target device system type that is compatible with the target device architecture type based on the target device architecture type and the correspondence between the preset device architecture type and the device system type.

[0041] The target device architecture type may be the device system architecture type that is currently to be tested. Since different device architecture types correspond to different device system types, the correspondence between the device architecture type and the device system type may be pre-set. Optionally, the pre-set correspondence between the device architecture type and the device system type may be stored in a JSON format file with the device architecture type as the key and the device system type as the value.

[0042] Specifically, the test processing request is parsed to determine the target device architecture type that needs to be tested currently. According to the correspondence between the preset device architecture type and the device system type, the target device system type corresponding to the target device architecture type is determined, so that the devices tested subsequently are all tested under the test environment corresponding to the target device system type.

[0043] Exemplarily, the target device system type is the SylixOS system type. When a test processing request is received, the base.json file is parsed to determine the SylixOS system type and device architecture type that need to be tested. And determine that the current SylixOS system type is in a usable state. Among them, the base.json file uses the "base" keyword as the key and the SylixOS multiple system types as the value. And use "Yes" or "No" to mark the usable system type and the unusable system type.

[0044] S120 , determining a target test case to be used according to the target device system type and test case set configuration information pre-configured for multiple device system types.

[0045] The test case set configuration information includes configuration information of multiple test cases corresponding to multiple device system types. The test case set configuration information can be used to determine whether the test case is in an available state and the storage path information of the test case. Optionally, the storage path information may include the storage location of the test case, source path information, and target path information. The target test case may be a test case corresponding to the target device system type.

[0046] Specifically, according to the target device system type, whether the target test case matching the target device system type is in an available state and the storage path information of the target test case are determined from the test case set configuration information pre-configured for multiple device system types. When the target test case is in an available state, the target test case is retrieved according to the storage path information, so as to perform test processing on the device to be tested subsequently based on the target test case.

[0047] In an embodiment of the present invention, a method for determining a target test case may be: based on a target device system type, parsing and processing test case set configuration information pre-configured for a variety of device system types, determining target test case status information and target test case storage path information corresponding to the target device system type; when the target test case status information is in an available state, based on the target test case storage path information, retrieving the target test case corresponding to the target device system type, and obtaining the target test case to be used.

[0048] Among them, the test case set configuration information includes configuration information of test cases for multiple device system types. The test case configuration information corresponding to different device system types is different. The test case configuration information may include case status information and case storage path information. The case status information is used to characterize whether the test case is in an available state. The case storage path information is used to characterize the storage path corresponding to the test case. The corresponding test case can be retrieved through the case storage path information. Optionally, the test case set configuration information pre-configured for multiple device system types is stored in a JSON format file.

[0049] The target test case is a test case that is compatible with the target device system type. The target test case can be a test case to be used, or a set of multiple test cases to be used. The target case status information can be used to characterize the state of the target test case corresponding to the target device system type. Optionally, the target case status information can be an available state or an unavailable state. The target case storage path information can be understood as the storage path of the target test case. The target test case can be retrieved through the target case storage path information.

[0050] Specifically, according to the target device system type, the test case set configuration information pre-configured for multiple device system types is parsed and processed to determine the target case state information and target case storage path information corresponding to the target device system type. According to the target case state information, it is determined whether the state of the target test case is an available state. If the state of the target test case is an available state, the target test case corresponding to the target device system type is retrieved through the target case storage path information to obtain the target test case to be used.

[0051] Exemplarily, the app.json file can be used to configure the test case set configuration information corresponding to various device system types. In the app.json file, you can configure the test case status information, storage location, source path name, and destination path name. Optionally, in the app.json file, the test case set configuration information corresponding to different device system types is different, and can be represented by the name of the test case or the device system type to facilitate subsequent search. If the target device system type is SylixOS version 4.0, the app.json file is parsed to obtain the target use case status information and target use case storage path information corresponding to SylixOS version 4.0. When the status information corresponding to SylixOS version 4.0 is in an available state, the target test case corresponding to SylixOS version 4.0 is retrieved according to the storage location and source path name.

[0052] S130 . Determine target test case driving information corresponding to the target test case according to the target test case and test case driving information pre-configured for a plurality of test cases.

[0053] Among them, the test case driving information pre-configured for multiple test cases may include the execution mode of the test case and the execution parameter information corresponding to the execution of the test case. For example, the execution mode of the test case may be a single-end test mode or a peer collaborative test mode. The number of test devices required can be determined by the execution mode of the test case. The execution parameter information may be various parameters required to execute the test case. The device architecture type of the test device required to execute the test case can be determined by the execution parameter information. Optionally, the test case driving information pre-configured for multiple test cases is stored in a file in JSON format. The target test case driving information may be the test case driving information required to execute the target test case.

[0054] Specifically, according to the target test case, the test case driving information pre-configured for multiple test cases is parsed to determine the target test case driving information corresponding to the target test case, so as to determine the number of devices and device architecture type for executing the target test case according to the target test case driving information.

[0055] Exemplarily, the test.json file is a JSON configuration file for a specific test case, which can be used to configure the test case driver information corresponding to multiple test cases. The test.json file may include information such as the execution mode, execution parameters, and execution system type of the test case. The test.json file is parsed according to the target test case to determine the execution mode and execution parameters for executing the target test case. The execution system type is the target device system type corresponding to the target test case. According to the execution mode, it is determined whether the target test case is a test case for a single-end test or a test case for a peer test to determine the number of devices executing the target test case. The device architecture type corresponding to the device executing the target test case is determined through the execution parameters. Based on this, the corresponding device can be called according to the number of devices and the device architecture type.

[0056] S140: Determine a target device to be tested based on the target test case driving information and the device management information pre-configured for multiple test devices.

[0057] The device management information may be device information used to manage multiple test devices. The device management information is configured with information such as the device architecture type, device quantity, operating status, network address, user name and password, protocol port number, and floating point type used by the device. Optionally, the device management information pre-configured for multiple test devices is stored in a JSON format file.

[0058] Specifically, the number of devices and the device architecture type for executing the target test case are determined according to the execution mode and execution parameter information in the target test case driving information. According to the number of devices and the device architecture type, a target device consistent with the number of devices and the device architecture type is determined from the device management information pre-configured for multiple test devices, so as to perform subsequent test processing based on the target device.

[0059] Exemplarily, in combination with the above example, the device architecture type required to execute the target test case is determined according to the execution parameter information in the target test case driver information. If the target test case corresponding to the SylixOS 4.0 version is executed, devices of various device system types can be obtained according to the execution parameter information. It should be noted that the devices of different device system types will be updated in a unified version later, that is, the device system types of the devices to be tested will be updated to the SylixOS 4.0 version.

[0060] Determine the number of target devices required to execute the target test case based on the execution mode in the target test case driver information. If the execution mode in the target test case driver information is single-end testing, it means that only one device is required to execute the target test case. However, in order to ensure the smooth progress of the test, at least one device can be obtained so that after the target device fails, the test process can be performed through the backup device. It should be noted that the device architecture type of the acquired backup device is consistent with the target device. If the execution mode in the target test case driver information is peer collaborative testing, it means that at least two target devices are required to execute the target test case.

[0061] Device.json is a JSON configuration file for the test device, which can be used to store the device management information of each test device. That is, the device.json file may include the device number, device system type, device architecture type, network address, username and password, protocol port number, and operating status of the test device. According to the device architecture type and the number of target devices determined above, the target device consistent with the device architecture type and the number of target devices determined above is determined from the device.json file, so as to perform subsequent test processing based on the target device.

[0062] It should be noted that in order to facilitate the determination of the target device and spare device, the device.json file can include three parts of device management information, namely, the "Hosts" device management information, the "MainMachine" device management information, and the "SpareMachine" device management information. The "Hosts" device management information contains the device management information of all remote devices and local devices that can be used for SylixOS testing. The "MainMachine" device management information uses the device architecture type as a category, and contains the device management information of the main devices of various device architecture types. The "SpareMachine" device management information is similar to the "MainMachine" device management information, and contains the device management information of spare devices of various device architecture types.

[0063] Optionally, in order to improve test efficiency, modular management of device management information can be implemented through the case.json file, that is, each module corresponds to the management information of one or more test devices. By modifying the case.json file, test processing of one or more test devices under a module can be implemented.

[0064] S150. When the target device is in a normal operating state, the target device is locked to obtain a locked target device, and a system type update process is performed on the locked target device based on the system type of the target device to obtain an updated target device.

[0065] Among them, in order to ensure that the target device can be tested normally, the operating state of the target device can be determined first. The operating state of the target device can include a normal state and an abnormal state. The normal state, that is, the available state, is the state in which the current target device can be tested. The abnormal state, that is, the unavailable state, can be the state in which the current target device is occupied or the current target device has an abnormal fault. The target device is locked to ensure the safety of the target device and prevent interference in the test process of the target device. The locking process can be achieved by a pre-set digital password, pattern password or file password. Since the device architecture type of the acquired target device may be different from the target device architecture type, correspondingly, the device system type of the target device is also different from the target device system type. In order to ensure the smooth progress of the test, the target device can be updated with a system type, which can be understood as updating the device system type of the target device to the target device system type. That is, the updated target device is a target device of the target device system type.

[0066] Specifically, the running state of the target device is detected, and when it is determined that the running state of the target device is normal, the target device is locked to obtain a locked target device. Based on this, the test process of the target device can be prevented from being disturbed. The locked target device is updated according to the system type of the target device to obtain an updated target device, and the updated target device is tested based on the target test case.

[0067] Exemplarily, the target device system type is SylixOS 4.0 version. Since the locked target device may be a SylixOS 2.0 version device or a SylixOS 3.0 version device. Therefore, in order to ensure that the subsequent target device can be tested smoothly, the pre-configured platform.json file can be used to determine the device system type update method of the target device and the floating point type corresponding to the target device system type. According to the device system update method, the device system type of the locked target device is updated to SylixOS 4.0 version, and the floating point type used by the target device is replaced with the floating point type corresponding to the target device system type. It should be noted that when the system type of the locked target device is updated, in order to increase the processing rate, the device system type corresponding to the locked target device can be determined, and the locked target device can be updated directly according to the target device system type. Among them, the platform.json file is a pre-configured JSON format file used to store information such as the method of updating the device system type and the floating point type adapted to the target device system type.

[0068] S160: Perform test processing on the updated target device based on the target test case to obtain a target test result.

[0069] The target test result may be a test result corresponding to a target test case, for example, a functional test result, a performance test result, or a security test result.

[0070] Specifically, the updated target device is tested according to the target test case to obtain a target test result corresponding to the target test case.

[0071] Optionally, the method also includes: if it is detected that the operating state of the target device is abnormal, determining the backup device corresponding to the target device; locking the backup device to obtain a locked backup device, and updating the system type of the locked backup device based on the system type of the target device to obtain an updated backup device; testing the updated backup device based on the target test case to obtain a test result corresponding to the backup device.

[0072] The standby device may be a device determined from the device management information, which is consistent with the device architecture type of the target device and whose operating status is normal.

[0073] Specifically, the operating status of the target device is detected. If it is detected that the operating status of the target device is abnormal, that is, the target device is occupied or fails, a backup device that is consistent with the device architecture type of the target device is determined from the device management information. The backup device is locked to obtain a locked backup device. Based on this, the test process of the backup device can be prevented from being disturbed, and the accuracy of the test can be ensured. The locked backup device is updated with a system type according to the system type of the target device to obtain an updated backup device. It should be noted that there is no need to determine the device system type of the backup device here, and the system type of the backup device is directly updated according to the system type of the target device. The backup device after the device system type is updated is tested according to the target test case to obtain the test result corresponding to the backup device.

[0074] The technical solution of this embodiment determines the system type of the target device to be tested according to the received test processing request, determines the test environment for subsequent test processing, and realizes the decoupling of the system environment and the test environment of the test device. According to the target device system type and the test case set configuration information pre-configured for multiple device system types, the target test case to be used is determined to implement the test processing of the test device based on the target test case. According to the target test case and the test case drive information, the target test case drive information corresponding to the target test case is determined to determine the target device to be tested based on the target test case drive information and the device management information. When the running state of the target device is normal operation, the target device is locked to obtain the locked target device, ensuring that the subsequent test process can be carried out smoothly without interference. Based on the target device system type, the locked target device is updated to obtain the updated target device. According to the target test case, the updated target device is tested to obtain the target test result. The present invention solves the problems of test redundancy, low test efficiency and inaccurate test results caused by simultaneous operation of the same test device in the prior art by locking the target device. By determining the target device system type, the target test case corresponding to the target device system type, and updating the system type of the target device, the test processing of the target device under the target device system type is achieved, which solves the problem of configuring test cases for each device to be tested in the prior art, resulting in numerous and complex test cases and low applicability of the test cases, improves the speed and accuracy of the target device test, and improves the applicability of the test processing.

[0075] Embodiment 2

[0076] Figure 2 This is a flow chart of a test processing method provided by the second embodiment of the present invention. This embodiment is based on the above embodiment and refines the step of "determining the target device to be tested based on the target test case driving information and the device management information pre-configured for multiple test devices". The specific implementation method can refer to the technical solution of this embodiment. Among them, the technical terms that are the same or corresponding to the above embodiment are not repeated here. Figure 2 As shown, the method includes:

[0077] S210: Determine the system type of the target device to be tested based on the received test processing request.

[0078] S220: Determine the target test case to be used according to the target device system type and the test case set configuration information pre-configured for multiple device system types.

[0079] S230 , determining target test case driving information corresponding to the target test case according to the target test case and the test case driving information pre-configured for a plurality of test cases.

[0080] S240: Determine the number of test devices that execute the target test case based on the execution mode in the target test case driving information.

[0081] The target test drive information includes the execution mode and execution parameter information of the target test case. The number of test devices can be understood as the number of devices used to execute the target test case.

[0082] Specifically, according to the execution mode in the target test case driving information, the number of test devices required when executing the target test case is determined, so as to obtain the target devices of the number of test devices for subsequent test processing.

[0083] Optionally, if the execution mode in the target test case driver information is peer collaborative testing, the number of test devices is determined to be at least two.

[0084] The peer collaborative test can be understood as: one test device is required to execute the test program of the server, and another or more test devices are required to execute the test program of the client.

[0085] Specifically, when the execution mode in the target test case driving information is peer collaborative testing, the number of test devices can be determined to be at least two. Optional. When the execution mode in the target test case driving information is single-ended testing, the number of test devices can be determined to be at least one.

[0086] S250: Determine a device architecture type corresponding to the execution parameter information based on the execution parameter information in the target test case driver information.

[0087] The execution parameter information may be various parameters required to execute the target test case.

[0088] Specifically, according to the execution parameter information in the target test case driving information, the device architecture type corresponding to the execution parameter information is determined, so as to call the corresponding target device according to the device architecture type.

[0089] S260: Based on the number of test devices and the device architecture type, determine the target device to be tested from the device management information pre-configured for the multiple test devices.

[0090] The device management information pre-configured for the multiple test devices includes the number of test devices and the device architecture type corresponding to each test device.

[0091] Specifically, according to the number of test devices and the device architecture type corresponding to the target test case driving information, the target device consistent with the number of test devices and the device architecture type is determined from the device management information pre-configured for multiple test devices to facilitate subsequent testing and processing of the target device.

[0092] Optionally, if the number of test devices is at least two, the main device to be tested and at least one collaborative test device consistent with the device architecture type of the main device are determined from the device management information based on the device architecture type, and the main device and at least one collaborative test device are used as the target devices to be tested.

[0093] Among them, when the execution mode of the target test case is peer collaborative testing, the number of test devices corresponding to the target device is at least two. The target device may include a main device and at least one collaborative test device. The main device may be used to execute the test program of the server. The collaborative test device may be a device that completes the test together with the main device and is used to execute the test program of the client.

[0094] Specifically, if the number of test devices is at least two, a main device to be tested and at least one cooperative test device of the same device architecture type as the main device are determined from the device manager according to the device architecture type. The main device and the at least one cooperative test device are used as the target devices to be tested. Based on this, it is convenient to perform cooperative testing on the main device and the at least one cooperative test device according to the target test case in the future.

[0095] Exemplarily, when peer collaborative testing is required, the user name, password, network address, protocol port number and other information of the master device are determined from the device.json file, so as to control the master device to execute the test program of the server based on these device management information. Correspondingly, the user name, password, network address, protocol port number and other information of at least one collaborative test device are determined from the device.json file, so as to control the collaborative test device to execute the test program of the client based on the device management information of the collaborative test device.

[0096] S270. When the target device is in a normal operating state, the target device is locked to obtain a locked target device, and a system type update process is performed on the locked target device based on the system type of the target device to obtain an updated target device.

[0097] S280: Perform test processing on the updated target device based on the target test case to obtain a target test result.

[0098] The technical solution of this embodiment determines the system type of the target device to be tested according to the received test processing request, determines the test environment for subsequent test processing, and realizes the decoupling of the system environment and the test environment of the test device. According to the target device system type and the test case set configuration information pre-configured for multiple device system types, the target test case to be used is determined to implement the test processing of the test device based on the target test case. According to the target test case and the test case drive information, the target test case drive information corresponding to the target test case is determined. According to the execution mode in the target test case drive information, the number of test devices for executing the target test case is determined. According to the execution parameter information in the target test case drive information, the device architecture type corresponding to the execution parameter is determined, so as to determine the appropriate target device from the device management information according to the number of test devices and the device architecture type. Based on this, the accurate determination of the target device is realized. When the operating state of the target device is normal operation, the target device is locked to obtain the locked target device, which ensures that the subsequent test process can be carried out smoothly without interference. The system type of the locked target device is updated based on the target device system type to obtain the updated target device. The updated target device is tested and processed according to the target test case to obtain the target test result. The present invention solves the problems of test redundancy, low test efficiency and inaccurate test results caused by simultaneous operation of the same test device in the prior art by locking the target device. By determining the target device system type, the target test case corresponding to the target device system type and updating the system type of the target device, the target device under the target device system type is tested and processed, which solves the problem of configuring test cases for each device to be tested in the prior art, resulting in numerous and complex test cases and low applicability of test cases, improves the speed and accuracy of testing the target device, and improves the applicability of the test process.

[0099] Embodiment 3

[0100] Figure 3 This is a flow chart of a test processing method provided in Embodiment 3 of the present invention. This embodiment is an optional embodiment of the above embodiment. For its specific implementation, please refer to the technical solution of this embodiment. Among them, the technical terms that are the same or corresponding to the above embodiment are not repeated here. Next, in combination with Figure 3 To illustrate the technical solution provided by the embodiment of the present invention.

[0101] First, when a test processing request is received, the base type configuration table is parsed through a compilation trigger to determine the target device architecture type and the target device system type.

[0102] Among them, the base type configuration table, that is, the base.json file, includes the corresponding relationship between the base information as the keyword and the device system type as the value.

[0103] Specifically, when a test processing request is received, the base type configuration table base.json is parsed through a compilation trigger to determine the target device architecture type and the target device system type that need to be compiled. Optionally, the target device system type whose enable state is available can be determined based on the enable state of the device system type configured in the base.json file. The enable state corresponds to the running state mentioned in the above embodiment.

[0104] Secondly, according to the target device system type, the test case configuration table is parsed through the test trigger to determine the test cases that need to be tested.

[0105] Among them, the test case configuration table, i.e., the app.json file, corresponds to the test case set configuration information mentioned in the above embodiment. The test case configuration table is used to configure the state information, storage location information, source path name, destination path name and other information of the test case. The information of each test case can be classified according to the name of the test case in the test case configuration table. The test case that needs to be tested corresponds to the target test case to be used in the above embodiment.

[0106] Specifically, according to the target device system type, the test case configuration table app.json is parsed through the test trigger to obtain the test case to be tested.

[0107] Afterwards, according to the test cases to be tested, the test case driver configuration table is parsed to determine the test case driver information for executing the test cases to be tested.

[0108] Among them, the test case driver configuration table, i.e., the test.json file, corresponds to the test case driver information mentioned in the above embodiment. The test case driver configuration table includes the execution mode of the test case, execution parameter information, and execution device system type, etc. The test case driver information of the test case to be tested corresponds to the target test case driver information mentioned in the above embodiment.

[0109] Specifically, according to the test cases to be tested, the test case driver configuration table test.json is parsed to determine the execution mode, execution parameter information, execution device system type and other use case driver information of the test cases to be tested.

[0110] Then, according to the use case driving information, the device management configuration table is parsed to obtain the device management information corresponding to the use case driving information, and the target device corresponding to the use case driving information is determined.

[0111] Among them, the device management configuration table, namely device.json, corresponds to the device management information mentioned in the above embodiment. The device management configuration table mainly includes the "Hosts" device set, the "MainMachine" device set and the "SpareMachine" spare device set. The "Hosts" device set manages all remote devices and local devices that can be used for device system type testing. The device management information contained in this set includes: test device number, device system type, device architecture type, network address, user name and password, protocol port and enable status and other information. The "MainMachine" device set is classified by device architecture type and manages test devices of the same device architecture type, and the device configuration information contained in this set includes: floating point type and enable status of the test device. The "SpareMachine" spare device set is similar to the "MainMachine" device set and manages spare devices.

[0112] Specifically, according to the use case driving information such as execution mode, execution parameter information, and execution device system type, the device management configuration table device.json is parsed to determine the device management information such as the number of test devices, architecture type, network address, and username and password corresponding to the use case driving information, and according to the above device management information, the target device corresponding to the use case driving information is determined from multiple test devices.

[0113] Optionally, in a test cluster, the device management information of all test devices can be managed through the "target device and backup device mode". This mode is suitable for embedded testing. When the target device is occupied or an exception occurs, the backup device is enabled to continue testing. However, when the target device is operating normally, the enable status and test execution of the backup device are independent of the target device. The above method is also for situations where embedded testing requires peer collaborative testing, that is, when the target device executes the test program on the server side and another one or more collaborative test devices execute the test program on the client side, the target device and the collaborative test device can be centrally obtained in the "MainMachine" device to complete the test processing. It should be noted that the test equipment can also be managed modularly through case.json, so that the test processing of the test equipment under a certain module can be implemented by modifying the content in the case.json file.

[0114] Next, the target device is locked, and the system type update mode is obtained by parsing the update system mode configuration table. The locked target device is updated according to the system type update mode to obtain an updated target device.

[0115] Among them, the update system method configuration table, that is, the platform.json file, contains two parts. One part is the board support package information corresponding to the target device, including the name of the board support package, the image name used, and the update method of the device system type. The other part is the floating point type corresponding to the device system type. Among them, the floating point type includes soft floating point or hard floating point.

[0116] Specifically, the target device is locked to obtain the locked target device. The system type update mode configuration table is parsed to determine the system type update mode. The locked target device is updated according to the system type update mode to obtain the updated target device.

[0117] Finally, the updated target device is tested according to the test cases that need to be tested to obtain the test results.

[0118] It should be noted that in order to ensure that the json file mentioned above can be parsed smoothly, the configuration information corresponding to the json file can be defined and constrained according to preset keywords.

[0119]

[0120]

[0121] The technical solution of this embodiment, when receiving a test processing request, parses the device architecture type configuration table through a compile trigger to determine the device architecture type and the target device system type that need to be compiled, and determines the system environment required for the test for subsequent test processing. According to the target device system type, parse the test case configuration table through a test trigger to determine the test case that needs to be tested. According to the test case that needs to be tested, parse the test case driver configuration table to determine the use case driver information for executing the test case that needs to be tested. According to the use case driver information, parse the device management configuration table to obtain the device management information corresponding to the use case driver information, and determine the target device corresponding to the use case driver information. Lock the target device, and parse and update the system mode configuration table to obtain the system type update mode. It is ensured that the subsequent test process can be carried out smoothly without interference. According to the system type update mode, the locked target device is updated with the system type to obtain the updated target device. According to the test case that needs to be tested, the updated target device is tested and processed to obtain the test result. The present invention solves the problems of test redundancy, low test efficiency and inaccurate test results caused by simultaneous operation of the same test device in the prior art by locking the target device. By determining the system type of the target device, the test case to be tested and updating the system type of the target device, the target device under the target device system type is tested, which solves the problem of numerous and complex test cases and low applicability of test cases caused by configuring test cases for each device to be tested in the prior art, improves the speed and accuracy of the test on the target device, and improves the applicability of the test process.

[0122] Embodiment 4

[0123] Figure 4 Schematic diagram of the structure of a test processing device provided by the fourth embodiment of the present invention. Figure 4 As shown, the apparatus includes: a system type determination module 310 , a test case determination module 320 , a test case driving information determination module 330 , a target device determination module 340 , a device update module 350 and a device test module 360 ​​.

[0124] The system type determination module 310 is used to determine the system type of the target device to be tested based on the received test processing request; the test case determination module 320 is used to determine the target test case to be used based on the target device system type and the test case set configuration information pre-configured for multiple device system types; the use case drive information determination module 330 is used to determine the target test case drive information corresponding to the target test case based on the target test case and the test case drive information pre-configured for multiple test cases; the target device determination module 340 is used to determine the target device to be tested based on the target test case drive information and the device management information pre-configured for multiple test devices; the device update module 350 is used to lock the target device when the operating state of the target device is normal to obtain the locked target device, and update the system type of the locked target device based on the target device system type to obtain the updated target device; the device test module 360 ​​is used to test the updated target device based on the target test case to obtain the target test result.

[0125] The technical solution of this embodiment determines the system type of the target device to be tested according to the received test processing request, determines the test environment for subsequent test processing, and realizes the decoupling of the system environment and the test environment of the test device. According to the target device system type and the test case set configuration information pre-configured for multiple device system types, the target test case to be used is determined to implement the test processing of the test device based on the target test case. According to the target test case and the test case drive information, the target test case drive information corresponding to the target test case is determined to determine the target device to be tested based on the target test case drive information and the device management information. When the running state of the target device is normal operation, the target device is locked to obtain the locked target device, ensuring that the subsequent test process can be carried out smoothly without interference. Based on the target device system type, the locked target device is updated to obtain the updated target device. According to the target test case, the updated target device is tested to obtain the target test result. The present invention solves the problems of test redundancy, low test efficiency and inaccurate test results caused by simultaneous operation of the same test device in the prior art by locking the target device. By determining the target device system type, the target test case corresponding to the target device system type, and updating the system type of the target device, the test processing of the target device under the target device system type is achieved, which solves the problem of configuring test cases for each device to be tested in the prior art, resulting in numerous and complex test cases and low applicability of the test cases, improves the speed and accuracy of the target device test, and improves the applicability of the test processing.

[0126] Based on the above embodiment, optionally, the system type determination module includes: a device architecture type determination unit, which is used to parse the test processing request to determine the target device architecture type to be tested; and a device system type determination unit, which is used to determine the target device system type that is compatible with the target device architecture type based on the target device architecture type and the correspondence between the preset device architecture type and the device system type.

[0127] Optionally, the test case determination module includes: a storage path information determination unit, which is used to parse and process the test case set configuration information pre-configured for multiple device system types according to the target device system type, and determine the target test case status information and target test case storage path information corresponding to the target device system type; a target test case determination unit, which is used to retrieve the target test case corresponding to the target device system type based on the target test case storage path information when the target test case status information is in an available state, so as to obtain the target test case to be used.

[0128] Optionally, the target device determination module includes: a device quantity determination unit, used to determine the number of test devices executing the target test case based on the execution mode in the target test case driver information; an architecture type determination unit, used to determine the device architecture type corresponding to the execution parameter information based on the execution parameter information in the target test case driver information; a target device determination unit, used to determine the target device to be tested from the device management information pre-configured for multiple test devices based on the number of test devices and the device architecture type.

[0129] Optionally, the device quantity determination unit is used to determine the number of test devices to be at least two if the execution mode in the target test case driving information is peer collaborative testing.

[0130] Optionally, a target device determination unit is used to determine, based on the device architecture type, a main device to be tested and at least one collaborative test device consistent with the device architecture type of the main device from the device management information if the number of test devices is at least two, and use the main device and at least one collaborative test device as target devices to be tested.

[0131] Optionally, the device also includes: a backup device testing module, which includes: a backup device determination unit, which is used to determine the backup device corresponding to the target device if it is detected that the operating state of the target device is abnormal; a backup device update unit, which is used to lock the backup device to obtain a locked backup device, and update the system type of the locked backup device based on the system type of the target device to obtain an updated backup device; a backup device testing unit, which is used to test the updated backup device based on the target test case to obtain a test result corresponding to the backup device.

[0132] The test processing device provided in the embodiment of the present invention can execute the test processing method provided in any embodiment of the present invention, and has the functional modules and beneficial effects corresponding to the execution method.

[0133] Embodiment 5

[0134] Figure 5 1 is a schematic diagram of the structure of an electronic device provided in Embodiment 5 of the present invention. The electronic device 10 is intended to represent various forms of digital computers, such as laptop computers, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframe computers, and other suitable computers. The electronic device may also represent various forms of mobile devices, such as personal digital processing, cellular phones, smart phones, wearable devices (such as helmets, glasses, watches, etc.) and other similar computing devices. The components shown herein, their connections and relationships, and their functions are merely examples and are not intended to limit the implementation of the present invention described and / or required herein.

[0135] like Figure 5 As shown, the electronic device 10 includes at least one processor 11, and a memory connected to the at least one processor 11, such as a read-only memory (ROM) 12, a random access memory (RAM) 13, etc., wherein the memory stores a computer program that can be executed by at least one processor, and the processor 11 can perform various appropriate actions and processes according to the computer program stored in the read-only memory (ROM) 12 or the computer program loaded from the storage unit 18 to the random access memory (RAM) 13. In the RAM 13, various programs and data required for the operation of the electronic device 10 can also be stored. The processor 11, the ROM 12, and the RAM 13 are connected to each other through a bus 14. An input / output (I / O) interface 15 is also connected to the bus 14.

[0136] A number of components in the electronic device 10 are connected to the I / O interface 15, including: an input unit 16, such as a keyboard, a mouse, etc.; an output unit 17, such as various types of displays, speakers, etc.; a storage unit 18, such as a disk, an optical disk, etc.; and a communication unit 19, such as a network card, a modem, a wireless communication transceiver, etc. The communication unit 19 allows the electronic device 10 to exchange information / data with other devices through a computer network such as the Internet and / or various telecommunication networks.

[0137] The processor 11 may be a variety of general and / or special processing components with processing and computing capabilities. Some examples of the processor 11 include, but are not limited to, a central processing unit (CPU), a graphics processing unit (GPU), various special artificial intelligence (AI) computing chips, various processors running machine learning model algorithms, a digital signal processor (DSP), and any appropriate processor, controller, microcontroller, etc. The processor 11 performs the various methods and processes described above, such as the test processing method.

[0138] In some embodiments, the test processing method may be implemented as a computer program, which is tangibly contained in a computer-readable storage medium, such as a storage unit 18. In some embodiments, part or all of the computer program may be loaded and / or installed on the electronic device 10 via the ROM 12 and / or the communication unit 19. When the computer program is loaded into the RAM 13 and executed by the processor 11, one or more steps of the test processing method described above may be performed. Alternatively, in other embodiments, the processor 11 may be configured to execute the test processing method in any other appropriate manner (e.g., by means of firmware).

[0139] Various implementations of the systems and techniques described above herein can be implemented in digital electronic circuit systems, integrated circuit systems, field programmable gate arrays (FPGAs), application specific integrated circuits (ASICs), application specific standard products (ASSPs), systems on chips (SOCs), load programmable logic devices (CPLDs), computer hardware, firmware, software, and / or combinations thereof. These various implementations can include: being implemented in one or more computer programs that can be executed and / or interpreted on a programmable system including at least one programmable processor, which can be a special purpose or general purpose programmable processor that can receive data and instructions from a storage system, at least one input device, and at least one output device, and transmit data and instructions to the storage system, the at least one input device, and the at least one output device.

[0140] The computer programs for implementing the test processing method of the present invention may be written in any combination of one or more programming languages. These computer programs may be provided to a processor of a general-purpose computer, a special-purpose computer or other programmable data processing device, so that when the computer program is executed by the processor, the functions / operations specified in the flow chart and / or block diagram are implemented. The computer program may be executed entirely on the machine, partially on the machine, partially on the machine and partially on a remote machine as a stand-alone software package, or entirely on a remote machine or server.

[0141] Embodiment 6

[0142] Embodiment 6 of the present invention further provides a computer-readable storage medium, wherein the computer-readable storage medium stores computer instructions, and the computer instructions are used to cause a processor to execute a test processing method, the method comprising:

[0143] Based on the received test processing request, determine the system type of the target device to be tested; determine the target test case to be used based on the target device system type and the test case set configuration information pre-configured for multiple device system types; determine the target test case driver information corresponding to the target test case based on the target test case and the test case driver information pre-configured for multiple test cases; determine the target device to be tested based on the target test case driver information and the device management information pre-configured for multiple test devices; when the operating state of the target device is normal, lock the target device to obtain a locked target device, and update the system type of the locked target device based on the target device system type to obtain an updated target device; test the updated target device based on the target test case to obtain a target test result.

[0144] In the context of the present invention, a computer-readable storage medium may be a tangible medium that may contain or store a computer program for use by or in combination with an instruction execution system, device or equipment. A computer-readable storage medium may include, but is not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, devices or equipment, or any suitable combination of the foregoing. Alternatively, a computer-readable storage medium may be a machine-readable signal medium. A more specific example of a machine-readable storage medium may include an electrical connection based on one or more lines, a portable computer disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disk read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing.

[0145] To provide interaction with a user, the systems and techniques described herein may be implemented on an electronic device having: a display device (e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor) for displaying information to the user; and a keyboard and a pointing device (e.g., a mouse or trackball) through which the user can provide input to the electronic device. Other types of devices may also be used to provide interaction with the user; for example, the feedback provided to the user may be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback); and input from the user may be received in any form (including acoustic input, voice input, or tactile input).

[0146] The systems and techniques described herein may be implemented in a computing system that includes backend components (e.g., as a data server), or a computing system that includes middleware components (e.g., an application server), or a computing system that includes frontend components (e.g., a user computer with a graphical user interface or a web browser through which a user can interact with implementations of the systems and techniques described herein), or a computing system that includes any combination of such backend components, middleware components, or frontend components. The components of the system may be interconnected by any form or medium of digital data communication (e.g., a communication network). Examples of communication networks include: a local area network (LAN), a wide area network (WAN), a blockchain network, and the Internet.

[0147] A computing system may include a client and a server. The client and the server are generally remote from each other and usually interact through a communication network. The client and server relationship is generated by computer programs running on the corresponding computers and having a client-server relationship with each other. The server may be a cloud server, also known as a cloud computing server or cloud host, which is a host product in the cloud computing service system to solve the defects of difficult management and weak business scalability in traditional physical hosts and VPS services.

[0148] It should be understood that the various forms of processes shown above can be used to reorder, add or delete steps. For example, the steps described in the present invention can be executed in parallel, sequentially or in different orders, as long as the desired results of the technical solution of the present invention can be achieved, and this document does not limit this.

[0149] The above specific implementations do not constitute a limitation on the protection scope of the present invention. It should be understood by those skilled in the art that various modifications, combinations, sub-combinations and substitutions can be made according to design requirements and other factors. Any modification, equivalent substitution and improvement made within the spirit and principle of the present invention should be included in the protection scope of the present invention.

Claims

1. A test processing method, characterized in that: include: Determining a target device system type to be tested based on the received test processing request; Determining a target test case to be used according to the target device system type and test case set configuration information pre-configured for multiple device system types; Determining target test case driving information corresponding to the target test case based on the target test case and test case driving information pre-configured for a plurality of test cases; Determining a target device to be tested based on the target test case driving information and device management information pre-configured for a plurality of test devices; When the running state of the target device is normal, locking the target device to obtain a locked target device, and updating the system type of the locked target device based on the system type of the target device to obtain an updated target device; The updated target device is tested based on the target test case to obtain a target test result.

2. The method according to claim 1, characterized in that The step of determining the target device system type to be tested based on the received test processing request includes: Parsing the test processing request to determine the architecture type of the target device to be tested; According to the target device architecture type and a preset correspondence between the device architecture type and the device system type, a target device system type that is compatible with the target device architecture type is determined.

3. The method according to claim 1, characterized in that The determining of the target test case to be used according to the target device system type and the test case set configuration information pre-configured for multiple device system types includes: According to the target device system type, the test case set configuration information pre-configured for multiple device system types is parsed and processed to determine the target case state information and the target case storage path information corresponding to the target device system type; When the target test case state information is in an available state, a target test case corresponding to the target device system type is retrieved based on the target test case storage path information to obtain a target test case to be used.

4. The method according to claim 1, characterized in that: The determining of the target device to be tested based on the target test case driving information and the device management information pre-configured for the plurality of test devices comprises: Determine the number of test devices that execute the target test case based on the execution mode in the target test case driving information; Based on the execution parameter information in the target test case driver information, determining a device architecture type corresponding to the execution parameter information; Based on the number of test devices and the device architecture type, a target device to be tested is determined from device management information pre-configured for a plurality of test devices.

5. The method according to claim 4, characterized in that The determining the number of test devices for executing the target test case based on the execution mode in the target test case driving information includes: If the execution mode in the target test case driving information is peer collaborative testing, the number of test devices is determined to be at least two.

6. The method according to claim 4, characterized in that The determining, based on the number of test devices and the device architecture type, a target device to be tested from device management information pre-configured for a plurality of test devices comprises: If the number of the test devices is at least two, then based on the device architecture type, determine the main device to be tested and at least one collaborative test device consistent with the device architecture type of the main device from the device management information, and use the main device and at least one of the collaborative test devices as the target devices to be tested.

7. The method according to any one of claims 1 to 6, characterized in that: Also includes: If it is detected that the operating state of the target device is an abnormal state, determining a backup device corresponding to the target device; Locking the standby device to obtain a locked standby device, and updating the system type of the locked standby device based on the target device system type to obtain an updated standby device; The updated standby device is tested based on the target test case to obtain a test result corresponding to the standby device.

8. A test processing device, characterized in that: include: A system type determination module, used to determine the system type of the target device to be tested based on the received test processing request; A test case determination module, used to determine the target test case to be used according to the target device system type and the test case set configuration information pre-configured for multiple device system types; A use case driving information determination module, used to determine the target test case driving information corresponding to the target test case based on the target test case and the test case driving information pre-configured for multiple test cases; A target device determination module, used to determine a target device to be tested based on the target test case drive information and device management information pre-configured for a plurality of test devices; A device update module, used for, when the running state of the target device is normal, locking the target device to obtain the locked target device, and updating the system type of the locked target device based on the system type of the target device to obtain the updated target device; The device testing module is used to perform testing on the updated target device based on the target test case to obtain a target test result.

9. An electronic device, characterized in that: The electronic device comprises: at least one processor; and a memory communicatively connected to the at least one processor; wherein, The memory stores a computer program executable by the at least one processor, and the computer program is executed by the at least one processor so that the at least one processor can perform the test processing method according to any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores computer instructions, and the computer instructions are used to enable a processor to implement the test processing method according to any one of claims 1 to 7 when executed.

Images