Software testing method and device and electronic equipment

Abstract

The invention discloses a software testing method and device and electronic equipment. Comprising the following steps: determining function key information respectively corresponding to each function unit in a source file of to-be-tested vehicle-mounted underlying software; generating a test code of the source file based on the function key information and the source file by testing the large model; compiling and running the test code to obtain core error information; and correcting the test code based on the core error information through the test large model, running the corrected test code to obtain a corresponding test result, and generating a test report of the source file based on the test result. According to the technical scheme, the test codes corresponding to the vehicle-mounted underlying software can be automatically generated through the test large model, it is ensured that the test codes run in sequence, the test report is finally generated, manual writing is not needed, and the test efficiency and the test quality can be effectively improved.

Description

Technical Field

[0001] This application belongs to the field of artificial intelligence technology, and in particular relates to a software testing method, apparatus and electronic device. Background Technology

[0002] Vehicle-mounted underlying software is directly linked to vehicle control and safety functions. Its unit testing needs to cover four core dimensions: basic functions, boundary conditions, abnormal inputs, and combined scenarios, and the test results must be traceable. This places much higher demands on the completeness of test cases and the reliability of test code than on ordinary software, and further amplifies the drawbacks of traditional manual testing methods.

[0003] Because of the high frequency of requirement changes during the development cycle of in-vehicle software, manually writing test cases requires matching function logic with requirements line by line, resulting in repeated modifications to test cases, affecting the development schedule. In addition, manual writing also has the problems of large coverage blind spots, high maintenance costs, and high quality risks. Summary of the Invention

[0004] The embodiments of this application provide a software testing method, apparatus, and electronic device that can autonomously generate test code corresponding to the underlying vehicle software through a large test model, ensure the sequential execution of the test code, and finally generate a test report without manual writing, which can effectively improve testing efficiency and test quality.

[0005] Other features and advantages of this application will become apparent from the following detailed description, or may be learned in part from practice of this application.

[0006] According to a first aspect of the embodiments of this application, a software testing method is provided, comprising: Determine the key information of each function unit in the source file of the vehicle-mounted underlying software to be tested; By testing a large model, test code for the source files is generated based on key function information and source files. Compile and run the test code to obtain the core error information; By testing a large model, the test code is corrected based on the core error information. The corrected test code is then run to obtain the corresponding test results, and a test report of the source file is generated based on the test results.

[0007] In some embodiments of this application, based on the aforementioned scheme, the key function information corresponding to each function unit in the source file of the vehicle-mounted underlying software to be tested is determined, including: Determine the encoding format and code structure of the source files of the vehicle-mounted underlying software to be tested; Based on the encoding format and code structure, identify the function units in the source file; Extract the key information of each function unit from the source file.

[0008] In some embodiments of this application, based on the foregoing scheme, the large test model includes a first large test model and a second large test model. Using the large test model, test code for the source files is generated based on key function information and source files, including: Using the first test model, based on the key information of the function and the source file, the corresponding structured summary is generated according to the preset structured template; The second test model generates test code for the source files based on the structured summary and source files.

[0009] In some embodiments of this application, based on the foregoing scheme, a corresponding structured summary is generated according to a preset structured template using a first test large model, based on key function information and source files, including: Get the prompt words corresponding to the file type of the source file; Input the prompt words, key function information, and source file into the first test model to obtain the structured summary output by the first test model.

[0010] In some embodiments of this application, based on the foregoing scheme, test code for the source file is generated using a second large-scale test model, based on the structured digest and the source file, including: The second test model generates test cases for the source files based on the structured summary and source files. The second test model converts test cases into corresponding test code.

[0011] In some embodiments of this application, based on the aforementioned scheme, the test code is compiled and run to obtain core error information, including: The test code is compiled to obtain the compiled test code and the corresponding compilation error information; Run the compiled test code and obtain the test execution log; Based on compilation error messages and test run logs, generate core error messages.

[0012] In some embodiments of this application, based on the aforementioned scheme, the test code is corrected based on core error information by testing a large model, including: The second large test model identifies compilation and logical errors in the test code based on core error information, and corrects these errors to obtain the corrected test code.

[0013] In some embodiments of this application, based on the foregoing scheme, the modified test code is run to obtain corresponding test results, and a test report of the source file is generated based on the test results, including: Compile the revised test code; If compilation fails, the test code is corrected again based on the core error information, and the process returns to the step of compiling the corrected test code. If compilation is successful, the compiled test code will be run to obtain the corresponding test results, and a test report of the source file will be generated based on the test results.

[0014] According to a second aspect of the embodiments of this application, a software testing apparatus is provided, comprising: The key information extraction module is used to determine the key information of each function unit in the source file of the vehicle-mounted underlying software to be tested. The test code generation module is used to generate test code for source files based on key function information and source files from a large test model. The error message extraction module is used to compile and run the test code to obtain the core error messages; The test report generation module is used to correct test code based on core error information using a large test model, run the corrected test code to obtain corresponding test results, and generate a test report of the source file based on the test results.

[0015] According to a third aspect of the embodiments of this application, a computer-readable storage medium is provided, which stores computer program instructions that, when loaded and executed by a processor, implement the steps of the method as described in any of the first aspects above.

[0016] According to a fourth aspect of the embodiments of this application, an electronic device is provided, including a memory and a processor. The memory stores a computer program, and when the processor executes the computer program, it implements the steps of the method as described in any of the first aspects above.

[0017] According to a fifth aspect of the embodiments of this application, a vehicle is provided on which on-board underlying software runs, and the on-board underlying software is tested based on the steps of the method as described in any of the first aspects above.

[0018] According to a sixth aspect of the embodiments of this application, a computer program product is provided, including a computer program that, when executed by a processor, implements the steps of the method as described in any of the first aspects above.

[0019] In this application, key function information corresponding to each function unit in the source file of the vehicle-mounted underlying software to be tested is determined. Based on the key function information and the source file, test code for the source file is generated using a large-scale test model. The test code is compiled and run to obtain core error information. Based on the core error information, the test code is corrected using the large-scale test model, and the corrected test code is run to obtain corresponding test results. A test report for the source file is then generated based on the test results. The technical solution provided in this application can autonomously generate test code for the vehicle-mounted underlying software using a large-scale test model, ensuring the sequential execution of the test code and ultimately generating a test report, eliminating the need for manual coding and effectively improving testing efficiency and quality.

[0020] It should be understood that the above general description and the following detailed description are exemplary and explanatory only, and do not limit this application. Attached Figure Description

[0021] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application. It is obvious that the drawings described below are merely some embodiments of this application, and those skilled in the art can obtain other drawings based on these drawings without any inventive effort. In the drawings: Figure 1 This paper illustrates the basic architecture diagram of the application software testing method according to an embodiment of this application; Figure 2 A flowchart of a software testing method in an embodiment of this application is shown; Figure 3 A flowchart illustrating the acquisition of key information of the function in an embodiment of this application is shown; Figure 4 A flowchart illustrating the generation of test code in an embodiment of this application is shown; Figure 5 A flowchart illustrating the acquisition of core error information in an embodiment of this application is shown; Figure 6 Another flowchart of the software testing method in an embodiment of this application is shown; Figure 7 A block diagram of a software testing apparatus according to an embodiment of this application is shown; Figure 8 A schematic diagram of the structure of an electronic device in an embodiment of this application is shown. Detailed Implementation

[0022] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0023] Furthermore, the described features, structures, or characteristics can be combined in any suitable manner in one or more embodiments. Numerous specific details are provided in the following description to give a thorough understanding of embodiments of this application. However, those skilled in the art will recognize that the technical solutions of this application can be practiced without one or more of the specific details, or other methods, components, apparatuses, steps, etc., can be employed. In other instances, well-known methods, apparatuses, implementations, or operations are not shown or described in detail to avoid obscuring various aspects of this application.

[0024] The block diagrams shown in the accompanying drawings are merely functional entities and do not necessarily correspond to physically independent entities. That is, these functional entities can be implemented in software, in one or more hardware modules or integrated circuits, or in different network and / or processor devices and / or microcontroller devices.

[0025] The flowcharts shown in the accompanying drawings are merely illustrative and do not necessarily include all content and operations / steps, nor do they necessarily have to be performed in the described order. For example, some operations / steps can be broken down, while others can be combined or partially combined; therefore, the actual execution order may change depending on the specific circumstances.

[0026] Currently, there are four main problems in software testing scenarios for automotive underlying software: An efficiency bottleneck exists: During the development cycle of automotive software, the frequency of requirement changes is as high as 1-2 times per iteration cycle (2-3 weeks), while manually writing test cases requires matching function logic with requirements line by line. According to project statistics, requirement changes cause 68.3% of existing test cases to be repeatedly modified (for example, after the requirement of adjusting the "braking pressure threshold" of the ESP (Electronic Stability Program) module of a certain model was adjusted, the testing team had to spend 2 days modifying 156 related test cases); at the same time, for every 10% increase in functional points, the number of test cases will increase non-linearly by 28% (due to the need to add scenario test cases of "interaction between new functions and existing functions"), making the testing phase a major bottleneck in the development progress.

[0027] Significant blind spots: Manually designed test cases rely on engineers' experience and easily overlook scenarios such as "critical parameter values, abnormal inputs, and hardware failure simulations." Data shows that 35.2% of production stage defects originate from missed boundary value tests in unit tests; even for senior engineers with more than 5 years of experience, the boundary value test failure rate of manual test cases is still as high as 18.6%, which cannot meet the safety redundancy requirements of automotive software.

[0028] High maintenance costs: After requirement changes, manually maintaining test cases requires simultaneous updates to the "test case description, test code, and expected results," and manual verification of the consistency between test cases and code is also necessary. Project data shows that as many as 78% of test cases require manual modification after requirement changes, while rework accounts for 22% of the entire iteration cycle, severely impacting the development time of core functions.

[0029] High Quality Risks: The "Sharper Cost Effect" of Defect Repair: Junior engineers, due to insufficient knowledge of automotive software (such as AUTOSAR specifications and hardware register logic), often miss 2-3 critical scenarios on average during manual unit testing (such as failing to test the "CAN (Controller Area Network) bus message timeout retransmission" scenario). According to industry data, the cost of fixing defects discovered after deployment is 6-10 times that of the development phase (automotive software requires additional vehicle road testing and compliance certification), significantly increasing project costs and safety risks.

[0030] To address the aforementioned problems and to enable those skilled in the art to better understand this application, firstly, in conjunction with... Figure 1 A brief description of the application scenarios involved in this application is provided.

[0031] See Figure 1 The diagram shows the basic architecture of the application software testing method according to an embodiment of this application.

[0032] The software testing method is implemented through the McoreUniTest agent, which consists of four main modules: environment layer, perception end, control end, and action end.

[0033] The environment layer provides the basic support for the operation of the intelligent agent, including source code import interface and test environment adaptation function; the perception end realizes accurate information collection, which can efficiently obtain source code information through code scanner and code parser, and obtain the compilation information corresponding to the test code through error information extractor; the control end is responsible for decision optimization and memory reduction, which can realize decision making (i.e., the first test model) based on GPT-40 (Generative Pre-trained Transformer), and complete the storage of memory / knowledge to realize information summary / backtracking; the action end is responsible for task execution and result assurance, which can include test case generator, test code generator, test runtime and test code repair tools, and finally generate test report based on test information. Each step of the action end can also be implemented based on GPT-40 (i.e., the second test model).

[0034] It should be noted that current technologies are mostly limited to a single language. However, in this embodiment, when extended to other languages, only the code parser on the perception end needs to be replaced to adapt it to the target language syntax, and the test code template on the action end needs to be replaced to match the target language testing framework. This achieves cross-language adaptation without refactoring the overall architecture. Existing tools require the local installation of compilers, testing frameworks, and other plugins, which is time-consuming to deploy. In contrast, the intelligent agent in this embodiment can be packaged into an executable file, and loading the source code file triggers the automated testing process.

[0035] In one exemplary embodiment, refer to Figure 2 The flowchart of the software testing method in the embodiments of this application is shown below, and is described in detail below: Step 201: Determine the key information of each function unit in the source file of the vehicle-mounted underlying software to be tested.

[0036] The vehicle's underlying software is directly related to vehicle control and safety functions. The source files of the vehicle's underlying software can be C language source code files, including .c files and .h files.

[0037] The source files of the vehicle-mounted underlying software contain several function units. A function unit is the smallest testable unit in the source file, which can be, but is not limited to, a function, method, class, functional module, or subsystem. When the source file is a C language source code file, the function unit specifically refers to a C function unit.

[0038] By identifying each function unit in the source file and extracting the key information corresponding to each function unit, we can deeply analyze the function constraints and dependencies of the underlying vehicle software, rather than just extracting surface information. This key information includes, but is not limited to, function parameters, return values, and dependent modules.

[0039] Optionally, the source files for the vehicle's underlying software can also be source code files written in other programming languages.

[0040] Step 202: By testing the large model, test code for the source files is generated based on key function information and source files.

[0041] The large-scale test model is a large language model trained under software testing scenarios. Key function information and source files are input into the large-scale test model, enabling it to generate test cases corresponding to the source files via a test case generator, and subsequently, test code generator to generate the corresponding test code.

[0042] Specifically, the test case generator in the large test model can combine domain knowledge, input parameters, expected outputs, and test priorities from the memory layer to ensure coverage of basic software testing functions, boundary conditions, abnormal inputs, and combined scenarios. The test code generator in the large test model can automatically convert test cases into executable C language test code and ensure that the test code includes test function definitions, parameter initializations, function calls, and result assertions, conforming to the AUTOSAR (Automotive Open System Architecture) C language coding standard.

[0043] Step 203: Compile and run the test code to obtain the core error information.

[0044] First, compile the test code, then run the compiled test code to obtain the corresponding core error information. This core error information includes compilation errors and runtime errors.

[0045] Step 204: By testing the large model, the test code is corrected based on the core error information. The corrected test code is run to obtain the corresponding test results, and a test report of the source file is generated based on the test results.

[0046] The large-scale test model can also reference core error information and use a test code repair tool to correct the generated test code. For example, it can perform syntax checks on the test code, fix compilation errors, ensure successful compilation, and perform logic checks to see if it covers key scenarios in software testing, resulting in corrected test code.

[0047] Furthermore, by running the modified test code in the vehicle-mounted MCU (Microcontroller Unit) development environment through the test runner, the corresponding test results can be obtained. The test report generator then uses the vehicle-mounted MCU development environment to collect the test results and ultimately generate a visualized test report. This report can include information such as test case coverage, defect location results, and execution time, meeting the project's compliance and traceability requirements.

[0048] In this application, key function information corresponding to each function unit in the source file of the vehicle-mounted underlying software to be tested is determined. Based on the key function information and the source file, test code for the source file is generated using a large-scale test model. The test code is compiled and run to obtain core error information. Based on the core error information, the test code is corrected using the large-scale test model, and the corrected test code is run to obtain corresponding test results. A test report for the source file is then generated based on the test results. The technical solution provided in this application can autonomously generate test code for the vehicle-mounted underlying software using a large-scale test model, ensuring the sequential execution of the test code and ultimately generating a test report, eliminating the need for manual coding and effectively improving testing efficiency and quality.

[0049] Based on the above embodiments, in an exemplary embodiment, see [link to example]. Figure 3 This illustrates the method for obtaining key information about functions in embodiments of this application, specifically including: Step 301: Determine the encoding format and code structure of the source files of the vehicle-mounted underlying software to be tested.

[0050] The encoding format of a source file refers to the character encoding method of the source file, such as UTF-8 (Universal Character Set / Unicode Transformation Format, a variable-length character encoding for Unicode) or GBK (Chinese Internal Code Specification, a Chinese character encoding set). The code structure of a source file refers to the mutual references and circular dependencies in the source file, such as header file dependencies and function call relationships.

[0051] Step 302: Based on the encoding format and code structure, determine each function unit in the source file.

[0052] Based on the source file's encoding format and code structure, the source file is scanned, and each function unit in the source file is automatically located.

[0053] Step 303: Extract the key information of each function unit from the source file.

[0054] Then, the key information of each function unit in the source file is extracted. This key information includes, but is not limited to, function parameters, return values, and dependent modules. Function parameters include function type, function range, and default values, while return values ​​include valid ranges and error code definitions.

[0055] Optionally, a structured function information table can be generated, which associates and stores each function unit with the key function information corresponding to that function unit, so that the agent can update and call it at any time.

[0056] In this application, the encoding format and code structure are obtained at the environment layer, and a code scanner is used at the perception end to determine each function unit and the key information of each function unit. No manual operation is required, which can effectively improve the reliability of information.

[0057] Based on the above embodiments, in an exemplary embodiment, the large test model includes a first large test model and a second large test model, see [link to example]. Figure 4 This illustrates the method for generating test code in embodiments of this application, specifically including: Step 401: Using the first test model, based on the key information of the function and the source file, generate the corresponding structured summary according to the preset structured template.

[0058] The first test model is a large language model on the control side. Key function information and source files are input into the first test model, and a structured summary is output by the first test model. The structured summary is generated based on a preset structured template, such as the format "Function ID (Identity document) - Core Requirements - Special Constraints".

[0059] Optionally, testers can engage in multiple "dialogues" with the first large-scale test model, inputting key function information and source files into it in batches. This allows the first large-scale test model to record the "dialogue" process and, by combining the domain knowledge of the memory layer, input parameters, expected outputs, and test priorities, accurately match the specific scenario requirements of the vehicle's underlying software and generate corresponding structured summaries.

[0060] Optionally, obtain the prompt words corresponding to the file type of the source file; input the prompt words, key function information and source file into the first test model to obtain the structured summary output by the first test model.

[0061] The file type of the source file refers to the specific type of the vehicle-mounted underlying software. There are differences between the prompt words corresponding to different file types. Using matching prompt words can further improve the processing effect of the first test model.

[0062] Optionally, the prompts may include a pre-defined structured template.

[0063] Step 402: Using the second large test model, generate test code for the source files based on the structured summary and source files.

[0064] The second large-scale test model is a large language model for the mobile device. The structured summary and source files are input into the second large-scale test model, resulting in the output test code. This test code includes test function definitions, parameter initializations, function calls, and result assertions, and conforms to the AUTOSAR C language coding standard.

[0065] Optionally, test cases for the source files are generated based on the structured summary and source files using the second large test model; the test cases are then converted into corresponding test code using the second large test model.

[0066] Specifically, the test case generator in the second test model can combine domain knowledge from the memory layer, input parameters, expected outputs, and test priorities to ensure coverage of basic software testing functions, boundary conditions, abnormal inputs, and combined scenarios, and automatically generate test cases based on structured summaries and source files.

[0067] Furthermore, the test code generator in the second test model can automatically convert test cases into executable C language test code, and ensure that the test code includes test function definitions, parameter initialization, function calls and result assertions, conforming to the AUTOSAR C language coding standard.

[0068] In this application, generating structured summaries at the control end can reduce the memory load of the large test model, ensure priority response to the safety-related requirements of the vehicle's underlying software, and generate test cases and test code sequentially at the action end, avoiding the generation of redundant test cases and ultimately improving the quality of the test code.

[0069] Based on the above embodiments, in an exemplary embodiment, see [link to example]. Figure 5 This illustrates the method for obtaining core error information in an embodiment of this application, specifically including: Step 501: Compile the test code to obtain the compiled test code and the corresponding compilation error information.

[0070] Compiling the test code yields the compilation result, which includes the compiled test code and corresponding compilation error messages, such as syntax errors or link warnings.

[0071] Step 502: Run the compiled test code and obtain the test run log.

[0072] Running the compiled test code yields the results and generates corresponding test logs, which record specific runtime exceptions, such as array out-of-bounds access.

[0073] Step 503: Generate core error information based on compilation error information and test run logs.

[0074] An information filtering algorithm is used to process compilation error messages and test run logs to extract core error information. This core error information includes the error location, error type, and error cause. Error locations include filenames and line numbers; error types include syntax errors and logical errors; and error causes include header files not included.

[0075] Optionally, an information filtering algorithm can be implemented based on keyword matching and semantic clustering. This algorithm filters out unimportant error information based on indicators, retaining only important error information, i.e., core error information, and keeping the core error information within a preset number of characters to avoid information overload in subsequent large-scale testing models.

[0076] In this application, compilation error information and test run logs are obtained at the environment layer, and core error information is generated at the perception end using an error information extractor. No manual operation is required. Error information noise reduction is achieved through compression and annotation, which reduces the input burden of the large test model and provides accurate guidance for subsequent code repair, effectively improving information reliability.

[0077] Based on the above embodiments, in an exemplary embodiment, the method for modifying the test code specifically includes: The second large test model identifies compilation and logical errors in the test code based on core error information, and corrects these errors to obtain the corrected test code.

[0078] Specifically, the test code repairer in the second large test model can perform dual-round verification and repair for syntax and logic problems in the test code. That is, for syntax problems, it performs syntax verification on the test code, repairs compilation errors such as missing semicolons and parameter type mismatches, and ensures that the test code compiles successfully. For logic problems, it performs logic verification on the test code, checks whether it covers the key scenarios in software testing, and forms the corrected test code.

[0079] Optionally, logical validation can be performed on test cases to check whether they cover key scenarios in software testing, such as whether they include null pointer input. If any key scenarios are missing, test cases can be automatically added and the corresponding test code updated.

[0080] Optionally, for different types of in-vehicle underlying software, corresponding key scenarios can be preset. Then, during the process of correcting the test code, the key scenarios can be directly called for matching to quickly identify logical problems.

[0081] Optionally, the test runner in the second test model can collect compilation information of the test code to provide abnormal compilation information for the test code fixer.

[0082] Based on the above embodiments, in an exemplary embodiment, the method for generating a test report specifically includes: The corrected test code is compiled; if compilation fails, the test code is corrected again based on the core error information, and the process returns to the step of compiling the corrected test code; if compilation succeeds, the compiled test code is run to obtain the corresponding test results, and a test report of the source file is generated based on the test results.

[0083] Specifically, the test report generator in the second test model can call the vehicle MCU development environment to collect test results, i.e., success or failure, and then generate a visual test report. The test report can include information such as test case coverage, defect location results, and execution time. Test case coverage includes statement coverage and branch coverage. Defect location results include the code lines corresponding to failed test cases, so that the test report meets the project compliance traceability requirements.

[0084] In this application, the process of generating test cases, generating test code, correcting test code, and generating test reports is automatically executed on the mobile device without manual intervention. This solves the problem of poor usability of generated test code, and the test reports can be directly used for project auditing, reducing the time spent on manually compiling reports.

[0085] Based on the above embodiments, in an exemplary embodiment, see [link to example]. Figure 6 Another flowchart of the software testing method in this application embodiment is shown below, which is described in detail below: Step 601: Determine the encoding format and code structure of the source files of the vehicle-mounted underlying software to be tested.

[0086] Step 602: Based on the encoding format and code structure, determine each function unit in the source file.

[0087] Step 603: Extract the key function information corresponding to each function unit from the source file.

[0088] Step 604: Obtain the prompt word corresponding to the file type of the source file.

[0089] Step 605: Input the prompt words, key function information and source file into the first test model to obtain the structured summary output by the first test model.

[0090] Step 606: Using the second large test model, generate test cases for the source files based on the structured summary and source files.

[0091] Step 607: Using the second large test model, convert the test cases into corresponding test code.

[0092] Step 608: Compile the test code to obtain the compiled test code and the corresponding compilation error information.

[0093] Step 609: Run the compiled test code and obtain the test run log.

[0094] Step 610: Generate core error information based on compilation error information and test run logs.

[0095] Step 611: Using the second large test model, determine the compilation errors and logical errors in the test code based on the core error information, and correct the compilation errors and logical errors to obtain the corrected test code.

[0096] Step 612: Compile the revised test code.

[0097] Step 613: Run the compiled test code to obtain the corresponding test results, and generate a test report of the source file based on the test results.

[0098] In this application, test code corresponding to the underlying vehicle software is automatically generated by testing a large model, and the test code is ensured to run in sequence to generate a test report. This eliminates the need for manual coding and can effectively improve testing efficiency and quality.

[0099] The following describes an apparatus embodiment of this application, which can be used to execute the software testing method in the above embodiments of this application. For details not disclosed in the apparatus embodiments of this application, please refer to the embodiments of the software testing method described above.

[0100] See Figure 7 The diagram shows a block diagram of the software testing apparatus 700 in an embodiment of this application, which specifically includes: The key information extraction module 701 is used to determine the key information of each function unit in the source file of the vehicle-mounted underlying software to be tested. The test code generation module 702 is used to generate test code for the source files based on key function information and source files from a large test model. Error message extraction module 703 is used to compile and run the test code to obtain core error messages; The test report generation module 704 is used to correct the test code based on the core error information through the test model, run the corrected test code to obtain the corresponding test results, and generate a test report of the source file based on the test results.

[0101] In an exemplary embodiment, based on the above embodiments, the key information extraction module 701 includes: The format determination unit is used to determine the encoding format and code structure of the source files of the vehicle-mounted underlying software to be tested; Function determination unit, used to determine each function unit in the source file based on the encoding format and code structure; The information extraction unit is used to extract the key information of each function unit from the source file.

[0102] In an exemplary embodiment, based on the above embodiments, the large test model includes a first large test model and a second large test model, and the test code generation module 702 includes: The abstract generation unit is used to generate a corresponding structured abstract based on the key information of the function and the source file, according to a preset structured template, through the first test model. The code generation unit is used to generate test code for the source files based on the structured summary and source files, using the second large test model.

[0103] In an exemplary embodiment, based on the above embodiments, the above-described summary generation unit includes: The prompt word acquisition subunit is used to retrieve the prompt word corresponding to the file type of the source file; The summary generation subunit is used to input prompt words, key function information, and source files into the first test model to obtain a structured summary output by the first test model.

[0104] In one exemplary embodiment, based on the above embodiments, the code generation unit includes: The test case generation subunit is used to generate test cases for the source files based on the structured summary and source files, using the second test model. The code generation subunit is used to convert test cases into corresponding test code through the second large test model.

[0105] In an exemplary embodiment, based on the above embodiments, the error information extraction module 703 includes: The error message extraction unit is used to compile the test code to obtain the compiled test code and the corresponding compilation error messages; The runtime log acquisition unit is used to run the compiled test code and obtain the test runtime log; The error message generation unit is used to generate core error messages based on compilation error messages and test run logs.

[0106] In an exemplary embodiment, based on the above embodiments, the test report generation module 704 includes: The code correction unit is used to identify compilation errors and logical errors in the test code based on the core error information through the second test model, and to correct the compilation errors and logical errors to obtain the corrected test code.

[0107] In an exemplary embodiment, based on the above embodiments, the test report generation module 704 includes: The code compilation unit is used to compile the corrected test code; The report generation unit is used to correct the test code again based on the core error information if compilation fails, and then return to the step of compiling the corrected test code; if compilation is successful, the compiled test code is run to obtain the corresponding test results, and a test report of the source file is generated based on the test results.

[0108] Based on the same inventive concept, embodiments of this application provide a computer-readable storage medium storing computer program instructions. When the computer program instructions are loaded and executed by a processor, they implement the steps of the software testing method described above.

[0109] Based on the same inventive concept, this application provides an electronic device, see [link to relevant documentation]. Figure 8 The diagram shows a schematic of the structure of an electronic device in an embodiment of this application. The electronic device includes one or more memories 804, one or more processors 802, and at least one computer program stored in the memory 804 and executable on the processor 802. When the processor 802 executes the computer program, it implements the steps of the software testing method described above.

[0110] The bus architecture (represented by bus 800) can include any number of interconnected buses and bridges, linking various circuits including one or more processors represented by processor 802 and memory represented by memory 804. Bus 800 can also link various other circuits such as peripherals, voltage regulators, and power management circuits, which are well known in the art and therefore will not be described further herein. Bus interface 805 provides an interface between bus 800 and receiver 801 and transmitter 803. Receiver 801 and transmitter 803 can be the same element, a transceiver, providing a unit for communicating with various other devices over a transmission medium. Processor 802 is responsible for managing bus 800 and general processing, while memory 804 can be used to store data used by processor 802 during operation.

[0111] The functions described herein may be implemented in hardware, software executed by a processor, firmware, or any combination thereof. If implemented in software executed by a processor, the functions may be stored as one or more instructions or codes on or transmitted via a computer-readable medium. Other examples and embodiments are within the scope and spirit of this application and the appended claims. For example, due to the nature of software, the functions described above may be implemented using software executed by a processor, hardware, firmware, hardwired, or any combination thereof. Furthermore, the functional units may be integrated into a single processing unit, or each unit may exist physically separately, or two or more units may be integrated into a single unit.

[0112] Based on the same inventive concept, this application provides a vehicle on which in-vehicle underlying software runs, and the in-vehicle underlying software is tested according to the steps of the software testing method described above.

[0113] Based on the same inventive concept, embodiments of this application provide a computer program product, including a computer program, which, when executed by a processor, implements the steps of the software testing method described above.

[0114] In the several embodiments provided in this application, it should be understood that the disclosed technical content can be implemented in other ways. The device embodiments described above are merely illustrative; for example, the division of units can be a logical functional division, and in actual implementation, there may be other division methods. For instance, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the displayed or discussed mutual coupling, direct coupling, or communication connection may be through some interfaces; the indirect coupling or communication connection between units or modules may be electrical or other forms.

[0115] The units described as separate components may or may not be physically separate. Similarly, the components of the control device may or may not be physical units; they may be located in one place or distributed across multiple units. Some or all of the units can be selected to achieve the purpose of this embodiment, depending on actual needs.

[0116] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing computer program instructions, such as USB flash drives, read-only memory (ROM), random access memory (RAM), portable hard drives, magnetic disks, or optical disks.

[0117] The above description is merely an embodiment of this application and is not intended to limit this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the scope of the claims of this application.

Claims

1. A software testing method, characterized in that, The method includes: Determine the key information of each function unit in the source file of the vehicle-mounted underlying software to be tested; By testing the large model, test code for the source file is generated based on the key information of the function and the source file. The test code was compiled and run to obtain the core error information; Using the aforementioned large-scale test model, the test code is corrected based on the core error information. The corrected test code is then run to obtain the corresponding test results, and a test report for the source file is generated based on the test results.

2. The method according to claim 1, characterized in that, The key function information corresponding to each function unit in the source file of the vehicle-mounted underlying software to be tested includes: Determine the encoding format and code structure of the source files of the vehicle-mounted underlying software to be tested; Based on the encoding format and the code structure, determine each function unit in the source file; From the source file, extract the key information of each function unit.

3. The method according to claim 1, characterized in that, The large-scale test model includes a first large-scale test model and a second large-scale test model. The step of generating test code for the source file based on the key information of the function and the source file using the large-scale test model includes: Using the first test model, based on the key information of the function and the source file, a corresponding structured summary is generated according to a preset structured template; Using the second test model, test code for the source file is generated based on the structured summary and the source file.

4. The method according to claim 3, characterized in that, The step of generating a corresponding structured summary based on the key information of the function and the source file using the first test model, according to a preset structured template, includes: Obtain the prompt word corresponding to the file type of the source file; The prompt words, the key information of the function, and the source file are input into the first large-scale test model to obtain the structured summary output by the first large-scale test model.

5. The method according to claim 3, characterized in that, The step of generating test code for the source file based on the structured summary and the source file using the second test model includes: Using the second test model, test cases for the source file are generated based on the structured summary and the source file; The second test model is used to convert the test cases into corresponding test code.

6. The method according to claim 3, characterized in that, The process of compiling and running the test code yields core error information, including: The test code is compiled to obtain the compiled test code and the corresponding compilation error information; Run the compiled test code to obtain the test execution log; Based on the compilation error information and the test run log, core error information is generated.

7. The method according to claim 6, characterized in that, The step of correcting the test code based on the core error information using the large test model includes: Using the second test model, the compilation errors and logical errors of the test code are determined based on the core error information, and the compilation errors and logical errors are corrected to obtain the corrected test code.

8. The method according to claim 7, characterized in that, The modified test code is run to obtain corresponding test results, and a test report for the source file is generated based on the test results, including: Compile the revised test code; If compilation fails, the test code is corrected again based on the core error information, and the process returns to the step of compiling the corrected test code. If compilation is successful, the compiled test code is run to obtain the corresponding test results, and a test report of the source file is generated based on the test results.

9. A software testing device, characterized in that, The device includes: The key information extraction module is used to determine the key information of each function unit in the source file of the vehicle-mounted underlying software to be tested. The test code generation module is used to generate test code for the source file based on the key information of the function and the source file, using the large test model. The error information extraction module is used to compile and run the test code to obtain core error information; The test report generation module is used to correct the test code based on the core error information using the test model, run the corrected test code to obtain the corresponding test results, and generate a test report for the source file based on the test results.

10. An electronic device comprising a processor and a memory, characterized in that, The memory stores computer program instructions that can be executed by the processor, and when the processor executes the computer program instructions, it implements the instructions of the method as described in any one of claims 1 to 8.

Images