Software testing method and device, equipment and storage medium

Abstract

The invention provides a software testing method and device, equipment and a storage medium, and relates to the field of software testing. The method comprises the steps of receiving a software test instruction; wherein the software test instruction is used for executing a test task, and the test task comprises test data. According to preset chip adaptation rule information, determining a unified test interface of the chips of different models and types; wherein the unified test interface is used for shielding hardware differences of chips of different models and types and executing test operation on the chips of different models and types, and the unified test interface comprises a chip interaction interface and a driving interface. Based on the unified test interface, test tasks are executed on the chips of all the models and types, and test reports are generated. Therefore, the software testing efficiency is greatly improved.

Description

TECHNICAL FIELD

[0001] The present application relates to the field of software testing, in particular, to a software testing method and device, equipment and storage medium. BACKGROUND

[0002] At present, with the diversification of vehicle operating systems of vehicles, only vehicle operating systems that have passed testing can be put into the market. Therefore, the testing of underlying software (including process management, memory management, device drivers, and real-time scheduling) of current vehicle operating systems (such as QNX, Android Automotive OS, RT-Thread Auto) is crucial.

[0003] In the prior art, the testing of vehicle operating systems mainly relies on traditional automated testing tools. Specifically, general tools such as Selenium, Junit, and Robot Framework are used in combination with manually written test scripts (such as Shell and Python scripts) to verify underlying functions (such as testing the success rate of process creation / destruction through scripts).

[0004] However, in the prior art, traditional tools need to repeatedly develop test scripts and driver interfaces for different architecture chips (ARM / x86 / RISC-V). For example, when adapting to RISC-V chips, more than 90% of the hardware interaction logic needs to be restructured, and the cycle is as long as 3-5 days per chip. The cross-chip adaptability is poor, which further leads to poor software testing efficiency. SUMMARY

[0005] The purpose of the embodiments of the present application is to provide a software testing method, device, equipment and storage medium, which can greatly improve the software testing efficiency.

[0006] In a first aspect, a software testing method is provided. The method can include: receiving a software testing instruction; wherein the software testing instruction is used to execute a testing task, and the testing task includes testing data; determining a unified testing interface of different model types of chips according to preset chip adaptation rule information; wherein the unified testing interface is used to shield the hardware differences of different model types of chips and execute testing operations on different model types of chips, and the unified testing interface includes a chip interaction interface and a driver interface; executing the testing task on each model type of chip based on the unified testing interface, and generating a testing report.

[0007] In a second aspect, a software testing device is provided. The device can include: The receiving module is configured to receive a software test instruction, wherein the software test instruction is used to execute a test task, and the test task comprises test data. The determining module is configured to determine a unified test interface of chips of different model types according to preset chip adaptation rule information, wherein the unified test interface is used to shield hardware differences of the chips of different model types and execute a test operation on the chips of different model types, and the unified test interface comprises a chip interaction interface and a driving interface. The test module is configured to execute the test task on the chips of different model types respectively based on the unified test interface, and generate a test report.

[0008] In a third aspect, an electronic device is provided, which comprises a processor, a communication interface, a memory and a communication bus, wherein the processor, the communication interface and the memory complete mutual communication through the communication bus. The memory is configured to store a computer program. The processor is configured to execute the program stored on the memory, and implement the method steps of any of the first aspect.

[0009] In a fourth aspect, a computer readable storage medium is provided, which stores a computer program, and the computer program is executed by a processor to implement the method steps of any of the first aspect.

[0010] The software test method, device, equipment and storage medium provided by the embodiments of the present application receive a software test instruction, wherein the software test instruction is used to execute a test task, and the test task comprises test data. According to preset chip adaptation rule information, a unified test interface of chips of different model types is determined, wherein the unified test interface is used to shield hardware differences of the chips of different model types and execute a test operation on the chips of different model types, and the unified test interface comprises a chip interaction interface and a driving interface. The test task is executed on the chips of different model types respectively based on the unified test interface, and a test report is generated. In the present solution, the unified test interface of the chips of different model types is adapted, and the test is performed according to the unified test interface. The hardware differences are shielded during the test, the test script can be reused across architectures, repeated development is avoided, the adaptation time is greatly shortened, the cross-chip adaptation efficiency is greatly improved, and an automatic test system of a vehicle operating system bottom software on multiple chips is realized, which greatly improves the software test efficiency. BRIEF DESCRIPTION OF DRAWINGS

[0011] In order to more clearly illustrate the technical solutions of the embodiments of the present application, the following will briefly introduce the drawings needed to be used in the embodiments of the present application. It should be understood that the following drawings only show some of the embodiments of the present application, and therefore should not be regarded as a limitation to the scope, and for those skilled in the art, other related drawings can also be obtained without creative labor on the basis of these drawings.

[0012] Figure 1 A flowchart of a software testing method provided by the embodiments of the present application; Figure 2 A flowchart of a software testing method provided by the embodiments of the present application; Figure 3 An architecture diagram of a software testing method provided by the embodiments of the present application; Figure 4 A structure diagram of a software testing device provided by the embodiments of the present application; Figure 5 A structure diagram of an electronic device provided by the embodiments of the present application. DETAILED DESCRIPTION

[0013] The technical solutions of the embodiments of the present application will be described clearly and completely below with reference to the drawings in the embodiments of the present application. Obviously, the described embodiments are only some of the embodiments of the present application, and not all the embodiments. Based on the embodiments of the present application, all other embodiments obtained by those skilled in the art without creative labor fall within the scope of the present application. Unless otherwise defined, the technical terms or scientific terms used in the present application should be understood as the general meaning understood by those skilled in the art. The words "first", "second", and similar words used in the present application do not represent any order, number, or importance, but are only used to distinguish different components. The words "include" or "contain" and similar words mean that the elements or objects before the words cover the elements or objects listed after the words and their equivalents, and do not exclude other elements or objects. The words "connect", "couple", or "connect" and similar words are not limited to physical or mechanical connections, but can include electrical connections, whether direct or indirect. "Up", "down", "left", "right", and the like are only used to represent relative positional relationships, and when the absolute positions of the described objects change, the relative positional relationships may also change accordingly.

[0014] Currently, with the diversification of vehicle operating systems for vehicles, only vehicle operating systems that have passed testing can be put on the market. Therefore, the testing of the underlying software (including process management, memory management, device drivers, and real-time scheduling) of current vehicle operating systems (such as QNX, Android Automotive OS, RT-Thread Auto) is crucial.

[0015] In one example, the testing of vehicle operating systems mainly relies on traditional automated testing tools, specifically, general tools such as Selenium, Junit, and Robot Framework are used in combination with manually written test scripts (such as Shell and Python scripts) to verify underlying functions (such as detecting the success rate of process creation / destruction through scripts). However, in existing technologies, traditional tools need to repeatedly develop test scripts and driver interfaces for different architecture chips (ARM / x86 / RISC-V), such as reconstructing more than 90% of hardware interaction logic when adapting to RISC-V chips, which takes 3-5 days per chip, has poor cross-chip adaptability, and thus leads to poor testing efficiency.

[0016] In one example, the testing method of vehicle operating systems also includes the following: 1) Hardware-in-the-loop (HIL) testing system: such as Vector VT System and dSPACE SCALEXIO, which simulates chip (such as ARM architecture chip A) running scenarios by building a physical hardware simulation environment to test OS driver compatibility.

[0017] 2) Manual + semi-automated combination scheme: engineers manually configure the test environment (such as deploying test firmware for x86 architecture chips), call special test tools (such as Valgrind to detect memory leaks), execute and record results for each use case, and only script automation for core processes.

[0018] 3) Single-chip dedicated testing system: customized testing solutions for specific chips (such as RISC-V architecture), with strong binding of testing logic and hardware, making it difficult to migrate to other platforms.

[0019] However, existing technologies have many problems, for example, the testing path of the hardware-in-the-loop (HIL) testing system is not intelligent, i.e., it can only rely on preset use cases for execution, and cannot optimize testing priorities based on historical testing data (such as "memory leaks often occur during process destruction"), with more than 40% of redundant testing, leading to low testing efficiency.

[0020] The combination of manual and semi-automatic solutions and single-chip dedicated test systems leads to inefficient resource scheduling. Specifically, when testing multiple chips in parallel, there is a lack of distributed task allocation mechanism, and the utilization rate of hardware resources (such as test terminal CPU) is less than 50%, and the single batch test time is more than 24 hours. Moreover, the test coverage is not complete: it is difficult for manual case writing to cover edge scenarios (such as device driver abnormalities under extreme temperature), the function omission rate is about 12% (the value here is only an example), and the security test (such as permission boundary protection) coverage rate is less than 60%. Moreover, the test data needs to be manually summarized and analyzed, and it takes 4-6 hours to generate a report, which cannot locate the problem in real time (such as "process startup failure due to incompatible driver version"), the result analysis is lagging behind, and the debugging cycle is delayed.

[0021] The software testing method provided by the embodiments of the present application can be applied to an electronic device or a server. The server can be a physical server, a server cluster composed of multiple physical servers or a distributed system, or a cloud server providing basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, content distribution networks (CDN), and big data and artificial intelligence platforms. The electronic device can be a mobile phone, a smart phone, a notebook computer, a digital broadcast receiver, a personal digital assistant (PDA), a tablet computer (PAD), etc. User Equipment (UE), a handheld device, a vehicle-mounted device, a wearable device, a computing device, or other processing devices connected to a wireless modem, a Mobile Station (MS), a Mobile Terminal, etc. The terminal and the server can be directly or indirectly connected through wired or wireless communication, which is not limited in the present application.

[0022] In order to ensure the accuracy of detection, the server is an application server or a cloud server with strong computing power.

[0023] The preferred embodiments of the present application are described below in conjunction with the accompanying drawings. It should be understood that the preferred embodiments described herein are only used to illustrate and explain the present application, and are not used to limit the present application, and the embodiments in the present application and the features in the embodiments can be combined with each other without conflict.

[0024] Figure 1 A flowchart of a software testing method provided by an embodiment of the present application is shown in FIG. 1. As shown in FIG. 1, the method can include the following steps. Figure 1 Step S101, receiving a software testing instruction; wherein the software testing instruction is used to execute a test task, and the test task includes test data.​

[0025] Exemplarily, the software test instruction is received based on an operation of triggering the test by the user. The software test instruction is used to execute a test task, and the test task includes test data. The test data can be data of an operating system for a vehicle, or data of a mobile phone or a tablet, without limitation.

[0026] In step S102, a unified test interface of chips of different model types is determined according to preset chip adaptation rule information. The unified test interface is used to shield hardware differences of chips of different model types and execute test operations on chips of different model types. The unified test interface includes a chip interaction interface and a driving interface.

[0027] Exemplarily, the preset chip adaptation rule information refers to adaptation rule information preset for chips of each model type. The unified test interface refers to an interface that can shield hardware differences of chips of different model types and execute the same or different test operations on chips of different model types in parallel. The unified test interface includes a chip interaction interface and a driving interface. In this step, interface matching is performed on chips of different model types according to the preset chip adaptation rule information, and the unified test interface of chips of different model types is determined.

[0028] In step S103, test tasks are executed on chips of each model type in parallel based on the unified test interface, and a test report is generated.

[0029] Exemplarily, the test tasks are executed on chips of each model type in parallel based on the unified test interface, and a test report is generated. The test tasks include any one or more of the following: a test summary, fault details, and performance indicators. The test summary includes, for example, a number of covered use cases, a pass rate, and the like. The fault details include, for example, a failed use case ID, a reproduction step, a root cause, and the like. The performance indicators include, for example, average process startup time consumption data and the like.

[0030] In the embodiment of the present application, a software test instruction is received; wherein the software test instruction is used to execute a test task, and the test task includes test data. According to preset chip adaptation rule information, a unified test interface of chips of different model types is determined; wherein the unified test interface is used to shield the hardware differences of chips of different model types and execute test operations on chips of different model types, and the unified test interface includes a chip interaction interface and a driving interface. Based on the unified test interface, the test task is executed on chips of each model type respectively, and a test report is generated. In the scheme, the unified test interface of chips of different model types is adapted, and the test is performed according to the unified test interface. The hardware differences are shielded during the test, the test script can be reused across architectures, repeated development is avoided, the adaptation time is greatly shortened, the cross-chip adaptation efficiency is greatly improved, and an automatic test system of the underlying software of the vehicle operating system on multiple chips is realized.

[0031] Figure 2 A flowchart of a software test method provided by the embodiment of the present application is shown in FIG. 1. Figure 2 As shown in the figure, the method can include: Step S201, receiving a software test instruction; wherein the software test instruction is used to execute a test task, and the test task includes test data.

[0032] Exemplarily, the software test instruction is received, and the software test instruction is used to execute the test task. According to the software test instruction, the test data (such as process startup time consumption, memory occupancy, and driving response delay) of the test task is collected in real time, the data accuracy is ensured through a data cleaning algorithm (abnormal values such as instantaneous high delay caused by hardware fluctuation are removed), the preprocessing time consumption is less than or equal to a preset threshold, for example, the preprocessing time consumption is less than or equal to 100ms per item, and the value here is only an example.

[0033] Step S202, determining a chip interaction interface in the unified test interface according to preset chip adaptation rule information and a chip type of the chip.

[0034] Exemplarily, Figure 3 An architecture diagram of a software test method provided by the embodiment of the present application is shown in FIG. 2. Figure 3 As shown in the figure, four core components of an intelligent agent module, a test management module, a chip adaptation module, and a test case library module are included; the intelligent agent module includes machine learning, intelligent adaptation, and automatic execution; the test management module includes scheduling management, real-time analysis, and result output. The core function of the intelligent agent module is to independently execute a test task (such as simulating user operations, running a test script, and collecting data), and dynamically optimize a test strategy.

[0035] The key technology of the agent module is machine learning optimization. Specifically, a Q-learning reinforcement learning algorithm is used, with the goal of "shortest test time and highest coverage", based on historical test data (such as "process management module failure probability 30% -> priority test"), adjusting the execution order of the use case, updating the strategy model after each batch of testing, and optimizing the iteration period ≤ 1 hour. Interface and underlying automation: integrate PyAutoGUI (vehicle UI interaction simulation) and self-developed kernel interaction tools (such as reading process state through kernel debugging interface), support headless and visual testing, script execution success rate ≥ preset success threshold, for example, the success threshold is 99%, the value here is only an example. It should be noted that the Q-learning reinforcement learning algorithm is only an example, other algorithms that can achieve the functions of the present application are also possible, which are not limited.

[0036] The core function of the chip adaptation module is to shield the hardware differences of different chips and provide a unified test interface. Specifically, a standardized hardware abstraction layer (HAL) is used to define a unified chip interaction interface (such as "initiation interface init(), driver loading interface load_driver(), performance monitoring interface get_perf_data()"), and a special HAL implementation layer is developed for each type of chip, greatly improving the success rate of interface calls and the hardware difference shielding rate (test scripts do not need to be aware of the chip architecture).

[0037] Driver interface adaptation library: pre-integrated driver interfaces of mainstream vehicle chips (such as CAN driver, GPIO driver), supports dynamic loading, and the time to add a new chip driver adaptation is ≤ a preset time period, for example, the preset time period is 4 hours or 5 hours. Hardware state monitoring: collect hardware environment data (such as chip temperature, power supply voltage) through built-in sensors (such as temperature sensors, voltage monitoring modules), automatically pause testing and alarm when hardware is abnormal (such as temperature > 85°C, the value here is only an example), alarm response time ≤ preset time threshold, for example, alarm response time ≤ 500ms.

[0038] In this step, according to the preset chip adaptation rule information and the chip type of the chip to be tested, the chip interaction interface in the unified test interface is determined, which is the chip interaction interface in the HAL.

[0039] Step S203, according to the preset driver interface adaptation library, interface adaptation processing is performed on chips of each chip type to generate driver interfaces in the unified test interface; wherein the preset driver interface adaptation library integrates driver interfaces of multiple chips.

[0040] Exemplarily, as Figure 3As shown, since the driving interface adaptation library is pre-integrated with the driving interface of mainstream vehicle chips, the driving interface in the unified test interface is generated by performing interface adaptation processing on chips of various chip types according to the pre-set driving interface adaptation library.

[0041] In step S204, the test task is executed on chips of various model types respectively based on the unified test interface, and a test report is generated.

[0042] In one example, step S204 includes: according to the pre-set reinforcement learning algorithm and the unified test interface, the test task is split into multiple sub-tasks on chips of various model types respectively; the multiple sub-tasks are allocated to test terminals in an idle state respectively, and the allocated multiple sub-tasks are tested and analyzed to generate a test report.

[0043] In one example, the operation of “allocating the multiple sub-tasks to test terminals in an idle state respectively, and testing and analyzing the allocated multiple sub-tasks to generate a test report” includes: allocating the multiple sub-tasks to test terminals in an idle state respectively; based on the pre-set visual component, analysis algorithm, and pre-set test case library, the multiple sub-tasks are tested and analyzed respectively to generate a test report; the analysis algorithm is associated with a mapping relationship between test failure and possible failure causes; the test report includes the failure cause of the test failure.

[0044] In one example, step S204 includes: based on the unified test interface, the test task is executed on chips of various model types respectively to generate a test progress dashboard; based on the test progress dashboard, a test report is generated; the test progress dashboard includes any one or more of the following: pass rate, fault distribution, resource utilization rate.

[0045] In one example, after the test task is executed on chips of various model types respectively based on the unified test interface to generate a test report, the method includes: if the test report includes a fault probability corresponding to each fault type, the fault probability corresponding to each fault type is sorted; the sorting is from high fault probability to low fault probability; based on the sorted fault probability, a test strategy is determined; the test strategy is the test order of the fault type; based on the test strategy, the next test task is tested in turn.

[0046] In one example, the test report includes any one or more of the following: test summary, fault details, and performance indicators.

[0047] Exemplarily, as shown in FIG. 1, the method includes the following steps. Figure 3As shown, the core functions of the test management module include task scheduling, resource allocation, result analysis and report generation. Specifically, distributed task scheduling: based on the Kubernetes containerization architecture, the test task is divided into "chip initialization -> case execution -> data upload" subtasks, which are dynamically allocated to idle test terminals (supporting virtual machine / physical machine mixed deployment), the task scheduling response time is ≤1 second, reducing the load balancing error. Real-time data analysis engine: integrate Tableau visualization components and self-developed root cause analysis algorithm (based on decision tree, related to "test failure type -> possible reason", such as "driver loading failure -> driver version incompatibility / hardware interface exception"), real-time generation of test progress dashboard (including pass rate, fault distribution, resource utilization), greatly improving the analysis accuracy. Report automatic generation: support PDF / Excel / HTML format report, including test summary (such as the number of covered cases, pass rate), fault details (such as failed case ID, reproduction steps, root cause), performance indicators (such as average process startup time), report generation time ≤5 minutes (the value here is only an example).

[0048] The core functions of the test case library module include storage, management, and automatic generation of test cases. Specifically, store cases by test type to achieve full-scenario case coverage, including: functional testing: process creation / termination, memory allocation / release, driver loading / unloading; performance testing: process startup time (≤50ms, the value here is only an example), memory leakage (≤1KB / hour, the value here is only an example), driver response delay (≤10ms, the value here is only an example); security testing: permission boundary protection (such as non-root users cannot modify kernel parameters), data encryption (such as driver communication data encryption); edge scenario testing: functional stability under extreme temperature (-40℃~125℃, the value here is only an example), voltage fluctuation (9V~16V, the value here is only an example). Automatic case generation: based on UML activity diagram model (such as "process management flow model"), automatically generate test cases through model-driven testing (MDT) tools, greatly improve the generation efficiency, support case version control (based on Git, can trace the modification history). Dynamic case update: when the OS version is upgraded or new functions are added (such as real-time task scheduling optimization), automatically identify the change point and update the associated cases, update and greatly improve the coverage without manual intervention.

[0049] In this step, the analysis algorithm is associated with the mapping relationship between test failure and possible failure causes. According to the preset reinforcement learning algorithm, the unified test interface, the test task is divided into multiple sub-tasks, and the multiple sub-tasks are respectively allocated to the idle test terminal on each type of chip. Then, based on the preset visual component, the analysis algorithm, and the preset test case library in the test case library module, the multiple sub-tasks are respectively tested and analyzed, and a test report is generated. The test report includes the failure cause of the test failure.

[0050] Therefore, the automatic generation, dynamic update and edge scenario coverage of the test case library, combined with the data preprocessing algorithm, ensure comprehensive test coverage and accurate data, reduce the function omission rate and error rate. Based on Kubernetes distributed task scheduling, and through real-time data analysis engine to automatically associate fault root cause, without manual summary and analysis, the problem positioning time is compressed from hours to minutes, graphical reports are generated, and the test efficiency and problem positioning speed are improved to realize problem positioning acceleration.

[0051] Optionally, based on the unified test interface, the test task is executed on each type of chip to generate a test progress dashboard, and a test report is generated according to the test progress dashboard. The test progress dashboard includes any one or more of the following: pass rate, fault distribution, resource utilization. After completing the current test task, if the current test task has a fault, or if the next new test task needs to be tested, the fault probability corresponding to each fault type included in the current test report is sorted according to the fault probability corresponding to each fault type. The sorting is from high fault probability to low fault probability, or from low fault probability to high fault probability, which is not limited. According to the sorted fault probability, a test strategy is dynamically determined, and the test strategy is a test order of fault types; for example, the fault type corresponding to the high fault probability has the highest priority, and so on. The fault type corresponding to the low fault probability has the lowest priority, and the test strategy is from the highest priority fault type to the lowest priority fault type. Finally, according to the test strategy, the next test task is tested in sequence.

[0052] Optionally, the test report includes any one or more of the following: test summary, fault details, performance indicators. The test summary includes, for example, the number of covered test cases, pass rate, etc., the fault details include, for example, failed test case ID, reproduction steps, root cause, etc., and the performance indicators include, for example, average process startup time, etc.

[0053] Therefore, the Q-learning algorithm of the agent module preferentially executes high-value use cases (such as use cases with high failure probability and use cases covering core functions), the test path optimization of the agent combining the Q-learning algorithm dynamically adjusts the priority of use case execution, reduces redundant testing, and supports interfaceless and visual testing by integrating interface automation and kernel interaction tools; the distributed scheduling of the test management module fully utilizes hardware resources and improves parallel testing efficiency.

[0054] In the embodiment of the application, a software test instruction is received; the software test instruction is used to execute a test task, and the test task includes test data. A chip interaction interface in a unified test interface is determined according to preset chip adaptation rule information and a chip type of a chip. A driving interface in the unified test interface is generated by performing interface adaptation processing on chips of each chip type according to a preset driving interface adaptation library; the preset driving interface adaptation library integrates driving interfaces of multiple chips. The test task is executed on chips of each model type based on the unified test interface, and a test report is generated. In the scheme, the unified adaptation mechanism of the multi-architecture chip based on the standardized HAL layer is used to adapt the unified test interface of chips of different model types, and the test is performed according to the unified test interface, the hardware difference is shielded during the test, the test script can be reused across architectures, repeated development is avoided, the adaptation time is greatly shortened, the cross-chip adaptation efficiency is greatly improved, and the automatic test system of the underlying software of the vehicle operating system on multiple chips is implemented.

[0055] In one example, the underlying software of a certain vehicle operating system OS needs to cover two types of architecture chips, chip A and chip B, and the test content includes process management, memory management, and CAN driver functions. (1) Deploy the test management module: Deploy the Kubernetes scheduling system on the Linux server, and configure 8 test terminals; start the real-time data analysis engine, and configure test index thresholds (such as process startup time ≤ 50 ms, memory leakage ≤ 1 KB / hour).

[0056] (2) Configure the chip adaptation module: Load the HAL implementation layer of chip A and chip B, and verify the interface calls (init(), load_driver()); Integrate the CAN driver adaptation interfaces of the two chips, and test the driver loading time (chip A: 8 ms, chip B: 10 ms).

[0057] (3) Load the test case library: From the use case library to call process management (15, such as "continuous creation of 100 processes and destroy, verify no residual"), memory management (12, such as "repeated allocation of 1GB memory and release, verify no memory leakage"), CAN driver (8, such as "send 1000 frame CAN data, verify the success rate of receiving ≥99.9%") use case, a total of 35; Through the MDT tool to automatically generate 2 edge scene use cases ("CAN driver initialization at -40℃ low temperature" "16V high voltage memory allocation"), supplemented to the use case library.

[0058] (4) agent to perform the test: The test management module is decomposed into 8 test terminals (4-5 use cases per terminal) by 37 use cases; The agent module is based on historical data (chip A process management failure probability 25%, chip B CAN driver failure probability 18%) to preferentially execute chip A process management use cases and chip B CAN driver use cases; During execution, real-time data (such as chip A process creation average time 42ms, chip B CAN data receiving success rate 99.95%) is collected, and abnormal data (such as 2KB leakage in a memory allocation use case) is automatically marked and triggers secondary testing.

[0059] (5) generate test report: The test management module automatically summarizes the data and generates a report: the total pass rate is 97.3% (36 / 37 use cases pass, 1 memory leakage use case fails), and the root cause analysis is "chip B some memory management driver does not release pointer"; Output visual dashboard to display the pass rate of each module of the two chips (chip A: 100%, chip B: 94.7%) and performance indicators (average process startup time: chip A 42ms, chip B 48ms).

[0060] Corresponding to the above method, the embodiment of the application also provides a software testing device, as shown in Figure 4 The device comprises: A receiving module 31 is configured to receive a software testing instruction; wherein the software testing instruction is used to execute a test task, and the test task comprises test data; A determining module 32 is configured to determine a unified test interface of different model types of chips according to preset chip adaptation rule information; wherein the unified test interface is used to shield the hardware differences of different model types of chips and execute a test operation on different model types of chips, and the unified test interface comprises a chip interaction interface and a driver interface; Test module 33 is used to execute the test tasks on chips of various models and types based on the unified test interface and generate test reports.

[0061] The functions of each functional unit of the software testing apparatus provided in the above embodiments of this application can be implemented through the above method steps. Therefore, the specific working process and beneficial effects of each unit in the software testing apparatus provided in the embodiments of this application will not be repeated here.

[0062] This application also provides an electronic device, such as... Figure 5 As shown, it includes a processor 510, a communication interface 520, a memory 530, and a communication bus 540, wherein the processor 510, the communication interface 520, and the memory 530 communicate with each other through the communication bus 540.

[0063] Memory 530 is used to store computer programs; When the processor 510 executes the program stored in the memory 530, it implements the steps of the above embodiments.

[0064] The communication bus mentioned above can be a Peripheral Component Interconnect (PCI) bus or an Extended Industry Standard Architecture (EISA) bus, etc. This communication bus can be divided into address bus, data bus, control bus, etc. For ease of illustration, only one thick line is used to represent it in the diagram, but this does not mean that there is only one bus or one type of bus.

[0065] The communication interface is used for communication between the aforementioned electronic devices and other devices.

[0066] The memory may include random access memory (RAM) or non-volatile memory (NVM), such as at least one disk storage device. Optionally, the memory may also be at least one storage device located remotely from the aforementioned processor.

[0067] The processor described above can be a general processor, including a central processing unit (CPU), a network processor (NP), etc.; can also be a digital signal processor (DSP), an application specific integrated circuit (ASIC), a field-programmable gate array (FPGA) or other programmable logic device, a discrete gate or transistor logic device, a discrete hardware component.

[0068] The implementation manners and beneficial effects of the electronic device in the above embodiments can be achieved by referring to the steps in the above embodiments, and thus, the specific working process and beneficial effects of the electronic device provided by the embodiments of the present application are not repeated here. Figure 1 The implementation manners and beneficial effects of the electronic device in the above embodiments can be achieved by referring to the steps in the above embodiments, and thus, the specific working process and beneficial effects of the electronic device provided by the embodiments of the present application are not repeated here.

[0069] In another embodiment provided by the present application, a computer readable storage medium is provided, and the computer readable storage medium stores instructions, when the instructions are run on a computer, the computer is caused to execute the software testing method in any of the above embodiments.

[0070] In another embodiment provided by the present application, a computer program product containing instructions is provided, when the instructions are run on a computer, the computer is caused to execute the software testing method in any of the above embodiments.

[0071] Those skilled in the art should understand that the embodiments in the embodiments of the present application can be provided as a method, a system or a computer program product. Therefore, the embodiments in the present application can be in the form of a complete hardware embodiment, a complete software embodiment or an embodiment combining software and hardware aspects. Moreover, the embodiments in the present application can be in the form of a computer program product implemented on one or more computer usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer usable program code.

[0072] The computer program instructions can also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer-implemented process such that the instructions which execute on the computer or other programmable apparatus provide steps for implementing the functions specified in the flowchart block or blocks. Figure 1 one or more flowcharts and / or blocks Figure 1 means for functionally implementing the steps listed in the flowchart block or blocks.

[0073] These computer program instructions can also be stored in a computer-readable memory that can direct a computer or other programmable data processing apparatus to function in a particular manner, such that the instructions stored in the computer-readable memory produce an article of manufacture including instructions which implement the function specified in the flowchart block or blocks. Figure 1 one or more flowcharts and / or blocks Figure 1 means for functionally implementing the steps listed in the flowchart block or blocks.

[0074] The computer program instructions can also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer-implemented process such that the instructions which execute on the computer or other programmable apparatus provide steps for implementing the functions specified in the flowchart block or blocks. Figure 1 one or more flowcharts and / or blocks ​ means for functionally implementing the steps listed in the flowchart block or blocks.

[0075] While preferred embodiments of the application have been described, modifications and variations can be apparent to those skilled in the art once aware of the general underlying concepts. Therefore, it is intended that the scope of the appended claims should include all such modifications and variations.

[0076] Obviously, numerous modifications and variations of the present embodiments are possible in light of the above teachings. It is therefore to be understood that within the scope of the appended claims and their equivalents, the application can be practiced otherwise than as specifically described.

Claims

1. A software testing method characterized by, The method comprises: receiving software test instructions; wherein the software test instructions are used to execute test tasks, and the test tasks include test data; determining a unified test interface of chips of different model types according to preset chip adaptation rule information; wherein the unified test interface is used to shield hardware differences of chips of different model types and execute test operations on chips of different model types, and the unified test interface includes a chip interaction interface and a driving interface; executing the test tasks on chips of each model type based on the unified test interface to generate a test report.

2. The method of claim 1, wherein, Determining a unified test interface of chips of different model types according to preset chip adaptation rule information comprises: determining a chip interaction interface in the unified test interface according to preset chip adaptation rule information and a chip type of the chip; performing interface adaptation processing on chips of each chip type to generate a driving interface in the unified test interface according to a preset driving interface adaptation library; wherein the preset driving interface adaptation library integrates driving interfaces of multiple chips.

3. The method of claim 1, wherein, Executing test tasks on chips of each model type based on the unified test interface to generate a test report comprises: splitting the test tasks into multiple subtasks on chips of each model type according to a preset reinforcement learning algorithm and the unified test interface; allocating the multiple subtasks to test terminals in an idle state respectively and performing test analysis processing on the allocated multiple subtasks to generate a test report.

4. The method of claim 3, wherein, Allocating the multiple subtasks to test terminals in an idle state respectively and performing test analysis processing on the allocated multiple subtasks to generate a test report comprises: allocating the multiple subtasks to test terminals in an idle state respectively; performing test analysis processing on the multiple subtasks respectively based on a preset visual component, an analysis algorithm, and a preset test case library to generate a test report; wherein the analysis algorithm is associated with a mapping relationship between test failure and possible failure causes; and the test report includes failure causes of test failure.

5. The method of claim 1, wherein, Executing test tasks on chips of each model type based on the unified test interface to generate a test report comprises: executing test tasks on chips of each model type based on the unified test interface to generate a test progress dashboard; generating a test report according to the test progress dashboard; wherein the test progress dashboard includes any one or more of the following: pass rate, fault distribution, and resource utilization.

6. The method of claim 1, wherein, After executing test tasks on chips of each model type based on the unified test interface to generate a test report, the method further comprises: if the test report includes fault probabilities corresponding to each fault type, sorting the fault probabilities corresponding to each fault type; wherein the sorting is from high fault probability to low fault probability; determining a test strategy according to the sorted fault probabilities; wherein the test strategy is a test order of fault types; sequentially testing a next test task according to the test strategy.

7. The method according to any one of claims 1 to 6, characterized in that, The test report includes any one or more of the following: Test summary, fault details, performance indicators.

8. A software testing apparatus, characterized by comprising: The device comprises: A receiving module for receiving software testing instructions; wherein the software testing instructions are used to execute a testing task, and the testing task comprises testing data; A determining module for determining a unified testing interface of chips of different model types according to preset chip adaptation rule information; wherein the unified testing interface is used to shield hardware differences of chips of different model types and execute testing operations on chips of different model types, and the unified testing interface comprises a chip interaction interface and a driving interface; A testing module for executing the testing task on chips of each model type based on the unified testing interface respectively, and generating a testing report.

9. An electronic device, comprising: The electronic device comprises a processor, a communication interface, a memory and a communication bus, wherein the processor, the communication interface and the memory complete mutual communication through the communication bus; The memory is used to store a computer program; The processor is used to execute the program stored on the memory, and realize the method in any one of claims 1-7.

10. A computer-readable storage medium, characterized in that, The computer readable storage medium stores a computer program, and the computer program is executed by the processor to realize the method in any one of claims 1-7.

Images