An automated system and method for AUTOSAR software functional testing

Abstract

This invention provides an automated system and method for AUTOSAR software functional testing, belonging to the field of software testing technology. The system includes: a configuration module for storing user-inputted test configuration information as a standard configuration file; a test script generation engine for automatically generating executable test scripts based on the configuration file and pre-stored test case templates; and a code generation module for automatically generating UpperTester-compliant integration code based on the same configuration file, for integration into the device under test for test execution. The advantages are: it achieves one-click automated testing from configuration to execution, significantly improving testing efficiency and software iteration speed; through standardized templates and automatic generation mechanisms, it enables cross-project reuse of test assets, reducing development costs; and the automated process ensures the standardization of test implementation and the consistency of results, effectively avoiding human error and ensuring the accuracy and objectivity of the tests.

Description

Technical Field

[0001] This invention relates to the field of software testing technology, and in particular to an automated system and method for AUTOSAR software functional testing. Background Technology

[0002] AUTOSAR (Automotive Open System Architecture) Classic Platform (CP), as a widely used automotive embedded software architecture standard, places paramount importance on the functional correctness and performance reliability of its base software (BSW) modules for the safety of the entire automotive electronic system. In the V-model development process, software functional testing is a crucial step in verifying whether the BSW modules meet the requirements specifications. In this step, UpperTester is typically used as a test proxy integrated within the device under test (DUT) to assist external test equipment in testing the AUTOSAR protocol stack.

[0003] In existing technologies, the implementation and testing process of UpperTester are highly dependent on the specific project's engineering configuration. Each client or project has different requirements and integration methods for the AUTOSAR BSW module, necessitating manual adjustments and customized development of UpperTester for each specific project integration environment. This includes not only adjusting UpperTester's own software model and code logic according to the actual integrated BSW module functionality, but also simultaneously writing or modifying the corresponding test scripts (i.e., test cases). Because the test scripts are tightly coupled with the specific UpperTester implementation for a particular project, test scripts developed for project A cannot be directly reused for project B. Even within the same project, configuration changes often cause existing test scripts to become invalid in different version iterations.

[0004] Therefore, the existing technology has the following main drawbacks: Inefficient and long delivery cycles: Each project requires a significant investment of manpower for the re-adaptation of UpperTester and the manual writing of test scripts, resulting in lengthy cycles for each functional test, which severely slows down software version iterations and project delivery progress.

[0005] Poor reusability and high cost: Test assets (including UpperTester components and test scripts) cannot be reused across different projects, resulting in a huge waste of human resources due to repeated development work and driving up the overall R&D cost.

[0006] Consistency is difficult to guarantee, and the accuracy of testing is questionable: The method of relying heavily on manual operation is prone to omissions and misjudgments, and the test scripts written by different engineers may differ, making it difficult to guarantee the completeness of test coverage and the accuracy and consistency of result judgment.

[0007] The root of these problems lies in the fact that the existing testing process lacks an automated mechanism that can automatically adapt to and generate the required UpperTester components and accompanying test scripts based on the project configuration. Summary of the Invention

[0008] To address the problems existing in the prior art, this invention provides an automated system for AUTOSAR software functional testing, comprising: The configuration module is used to receive test configuration information input by the user. The test configuration information includes at least one or more of the following: the selected BSW module under test, the range of performance indicators collected, and the load simulation task. The module stores the test configuration information as a configuration file in a standard format. A test script generation engine, connected to the configuration module, is used to generate an executable test script corresponding to the current project configuration based on the configuration file and pre-stored test case templates associated with BSW function points. The code generation module, connected to the configuration module, is used to generate UpperTester integration code conforming to the AUTOSAR architecture according to the configuration file. The UpperTester integration code is used to integrate into the device under test to perform test operations on the corresponding BSW module according to the instructions of the executable test script.

[0009] Preferably, the configuration module provides a graphical user interface, and the test configuration information also includes bus message association and parsing logic configuration and test data filtering rule configuration.

[0010] Preferably, the configuration file is an ARXML format file.

[0011] Preferably, the test script generation engine includes a template library and a parser. The template library stores the test case templates, and the parser is used to parse the configuration file to determine the list of BSW function points and specific parameters adopted by the current project, and to fill the parameters into the corresponding test case template to generate the executable test script.

[0012] Preferably, the code generation module includes: A communication interface generation unit is used to generate the communication interface code of UpperTester, wherein the communication interface is configured to communicate with the host computer test device in accordance with a predefined message protocol. The test agent generation unit is used to generate code for one or more test agents in UpperTester based on the configuration file, wherein the test agents are configured to parse instructions received through the communication interface; The BSW interaction component generation unit is used to generate interaction component code in UpperTester corresponding to each BSW module based on the BSW module under test specified in the configuration file. The interaction component is configured to respond to the parsing result of the test agent and call the corresponding BSW service interface to perform test operations.

[0013] Preferably, the predefined message protocol includes request messages, response messages, and event messages, wherein the request messages and response messages contain submodule identifiers and operation data.

[0014] Preferably, the code generation module further includes a performance acquisition code generation unit, used to generate instrumentation code for acquiring performance metrics in a specified runnable entity.

[0015] Preferably, the code generation module further includes a load simulation code generation unit for generating code that simulates the execution load in a specified runnable entity.

[0016] This invention also provides an automated method for AUTOSAR software functional testing, characterized in that it is applied to the automated system described above, and the automated method includes: Step S1: The automated system receives test configuration information input by the user and stores the test configuration information as a standard format configuration file. The test configuration information includes at least one or more of the following: the selected BSW module under test, the performance index collection range, and the load simulation task. Step S2: The automation system generates an executable test script corresponding to the current project configuration based on the configuration file and the pre-stored test case templates associated with BSW function points. Step S3: The automation system generates UpperTester integration code conforming to the AUTOSAR architecture based on the configuration file; Step S4: The automated system integrates the UpperTester integration code into the device under test; Step S5: The automated system runs the executable test script and controls the device under test, which integrates the UpperTester integrated code, to perform corresponding test operations.

[0017] Preferably, the test operation in step S5 includes one or more of the following: functional testing of the BSW module, performance indicator collection, or load simulation.

[0018] The above technical solution has the following advantages or beneficial effects: 1. By leveraging the collaborative work of the configuration module, test script generation engine, and code generation module, a one-click automated transformation from project requirement configuration to test execution is achieved. This significantly reduces the workload required for manually adapting UpperTester and writing scripts, resulting in a marked improvement in testing efficiency and greatly accelerating software version iteration and project delivery schedules.

[0019] 2. By building a standardized test case template library and an automated code generation mechanism, this invention breaks the strong coupling between test scripts and specific project engineering. Test logic and code implementation no longer rely on manual hard coding, enabling mature test assets to be quickly migrated and reused across projects and versions, effectively avoiding the waste of human resources caused by redundant development and significantly reducing the overall R&D costs of enterprises.

[0020] 3. By automatically generating integration code and test scripts through parsing standardized configuration files, a high degree of consistency in engineering parameters is ensured between the test implementation layer (UpperTester) and the test logic layer (test cases). This automated process eliminates script deviations caused by differences in the habits of different engineers, effectively avoiding problems such as missed tests and false tests that may be introduced by manual operation, and ensuring the objectivity and accuracy of test results. Attached Figure Description

[0021] Figure 1 This is a schematic diagram of the structure of an automated system for AUTOSAR software functional testing in Embodiment 1 of the present invention; Figure 2 This is a schematic diagram of the diagnostic protocol stack in Embodiment 5 of the present invention; Figure 3 This is a flowchart illustrating an automated method for AUTOSAR software functional testing in Embodiment 9 of the present invention. Detailed Implementation

[0022] The present invention will now be described in detail with reference to the accompanying drawings and specific embodiments. The present invention is not limited to this embodiment; other embodiments that conform to the spirit of the present invention may also fall within the scope of the present invention.

[0023] Example 1: This embodiment provides an automated system for AUTOSAR software functional testing, such as... Figure 1 As shown, it includes: Configuration module 1 is used to receive test configuration information input by the user. The test configuration information includes at least one or more of the following: the selected BSW module under test, the range of performance indicators collected, and the load simulation task. The test configuration information is stored as a configuration file in a standard format. Test script generation engine 2, connected to configuration module 1, is used to generate executable test scripts corresponding to the current project configuration based on the configuration file and pre-stored test case templates associated with BSW function points. The code generation module 3, connected to the configuration module 1, is used to generate UpperTester integration code conforming to the AUTOSAR architecture based on the configuration file. The UpperTester integration code is used to integrate into the device under test to perform test operations on the corresponding BSW modules according to the instructions of the executable test script.

[0024] Specifically, this embodiment provides an automated system for AUTOSAR software functional testing. Its core lies in building an integrated toolchain to solve the inefficiencies caused by manual configuration and development. The system mainly includes three collaborative core modules: configuration module 1, test script generation engine 2, and code generation module 3.

[0025] First, the user inputs the test configuration information for the current project through the configuration module. This information must at least explicitly specify the BSW module to be tested (e.g., diagnostic protocol stack, communication stack, etc.), the range of performance metrics to be collected (e.g., CPU load, stack consumption, etc.), and the planned load simulation tasks. The configuration module stores this information in a structured format as a configuration file, which serves as the input source for the entire automated process.

[0026] Next, Test Script Generation Engine 2 reads the configuration file. Internally, Test Script Generation Engine 2 stores test case templates that map one-to-one with various BSW function points (function points are defined between SRS and SWS in the AUTOSAR standard specification). By parsing the configuration file, Test Script Generation Engine 2 identifies the list of function points actually adopted by the current project and their specific parameters, and automatically fills these parameters into the corresponding test case templates, thereby dynamically generating a set of executable test scripts that perfectly match the current project configuration.

[0027] Meanwhile, code generation module 3 also operates based on the same configuration file. Its task is to automatically generate UpperTester integration code compliant with the AUTOSAR architecture. This code will serve as an integrable module within the device under test (DUT), its function being to receive and execute instructions from external test scripts. Finally, the generated UpperTester integration code is embedded into the DUT, and the executable test scripts generated by the test script generation engine are run, thus driving the DUT to complete automated testing operations.

[0028] This embodiment achieves one-click generation from project configuration to executable tests by standardizing the manual configuration process, templating test logic, and automating UpperTester code generation. This directly reduces the manual adjustment and development work required for each project in the traditional model (which typically requires 4-6 person-days per project; in project workload assessment, "person-day" refers to the amount of work one person can complete in one day. More specifically, it usually refers to the workload of a standard workday, such as 8 hours. In front-end development, person-days are used to estimate the workload required to complete a specific task or the entire project) to less than 1 person-day, improving testing efficiency by over 75%. Furthermore, it fundamentally ensures the consistency between test cases and project configuration, avoiding human oversights and misjudgments.

[0029] Example 2: This embodiment further defines the configuration module based on the aforementioned embodiment 1. The configuration module provides a graphical user interface, and the test configuration information also includes bus message association and parsing logic configuration, and test data filtering rule configuration.

[0030] Specifically, the configuration module provides a graphical user interface (GUI), which greatly enhances the intuitiveness and convenience of user operation. Through this interface, users can not only perform basic configurations such as selecting the BSW module in Example 1, but also perform more refined test settings.

[0031] For example, users can configure the association between bus messages and Protocol Data Units (PDUs), define message disassembly and assembly logic, and set the communication buffer size within the interface. Furthermore, the interface supports configuring test data filtering rules, enabling generated test scripts to focus on key test scenarios. Through this graphical interface, users can perform one-stop configuration, including but not limited to: enabling or disabling functional test logic for various protocol stacks or BSW modules; selecting the range of performance metrics to be collected (e.g., which Runnables specifically); specifying Runnables or interrupt service routines to be simulated under load; configuring the PDU association, disassembly and assembly logic, and communication buffer size for test bus messages; and setting filter conditions and specific test data for test cases. All these configurations are structured and saved. These rich configuration items are collected through the interface and stored in the configuration file, providing a more comprehensive basis for subsequent script and code generation. Graphical configuration lowers the technical barrier for testers, enabling the rapid construction of complex test scenarios even without in-depth understanding of the underlying protocol details.

[0032] Example 3: This embodiment, based on embodiment 1 or 2, specifies the storage format of the configuration file. The configuration file is in ARXML format.

[0033] Specifically, to ensure seamless integration with the AUTOSAR development system, the configuration files are stored in the ARXML (AUTOSAR XML) format defined by the AUTOSAR standard. ARXML is a common data exchange format in the AUTOSAR field for describing software components, system configurations, etc. Carrying test configuration information in ARXML format means that the system of this invention can naturally reuse existing AUTOSAR configuration toolchain frameworks, facilitating data interaction and integration with processes such as BSW module configuration and RTE generation, thereby reducing the complexity of system development and integration costs.

[0034] Example 4: This embodiment, based on embodiment 1, elaborates on the internal working mechanism of the test script generation engine. The test script generation engine 2 mainly consists of two parts: a template library and a parser.

[0035] Specifically, the test script generation engine includes a template library and a parser. The template library stores test case templates, and the parser is used to parse the configuration file to determine the list of BSW feature points adopted by the current project and the specific parameters, and then fills the parameters into the corresponding test case template to generate an executable test script.

[0036] The template library stores pre-designed test case templates. These templates are not specific to any particular project, but rather associated with abstract BSW functionalities. Their code forms the framework of the test cases, containing general test logic and flow control. The parser is responsible for processing the specific project configuration file. It parses the configuration file and accurately extracts a list of all BSW functionalities actually adopted in the current project, as well as the specific parameter values ​​corresponding to each functionality (e.g., the identifier of a diagnostic service, the ID of a communication channel, etc.).

[0037] The parser then populates or binds the extracted parameters into the corresponding test case templates in the template library. Finally, an executable test script containing specific test data and fully adapted to the current project configuration is automatically generated. This method decouples test logic from test data, allowing test logic (templates) to be reused across projects, while test data is dynamically generated based on configuration, solving the problem of test scripts not being reusable in the background technology.

[0038] Example 5: This embodiment, based on Embodiment 1, reveals in detail the internal architecture of the code generation module. Instead of generating a single, monolithic code block, this module generates multiple collaborative code parts in an organized manner, following the component-based approach of AUTOSAR. These primarily include a communication interface generation unit, a test proxy generation unit, and a BSW interaction component generation unit.

[0039] Specifically, code generation module 3 adopts a layered, component-based generation strategy. Based on the test requirements and integration environment defined in the configuration file, it automatically builds a clearly structured UpperTester software module that closely matches the project architecture. This module mainly includes the following collaborative components: Communication Interface Generation Unit 31: Used to generate the underlying code for communication between UpperTester and the host computer testing device. This code implements a communication interface that conforms to a predefined message protocol (such as...). Figure 2 As shown, in the implementation example it can be called UT_SBUS), which serves as the unified communication portal for the entire UpperTester, responsible for receiving the original test commands and sending the results.

[0040] Test Agent Generation Unit 32: Used to generate one or more test agents (e.g., based on the configuration file) Figure 2 As shown, the code is referred to as Agent in the implementation example (e.g., UT_Diag_Agent). The test agent sits between the communication interface and the specific functional components. Its core responsibility is to parse the complex instruction data packets received from the communication interface (e.g., UT_SBUS), decompose them, and dispatch them into atomic operation commands for specific BSW modules. This design effectively avoids direct coupling between the communication interface and a large number of underlying functional components. It is worth noting that the test agent layer is flexible and not mandatory; when the logic of a functional domain under test is simple enough, its agent responsibilities can be directly integrated into subsequent interaction components, thereby simplifying the architecture.

[0041] BSW Interaction Component Generation Unit 33: This is the final execution layer, used to generate software component code that directly interacts with the specific BSW module under test. During implementation, UpperTester is integrated into the corresponding location in the AUTOSAR protocol stack in the form of these components. These components together constitute a logical composite unit. Its generation strategy closely integrates key considerations for actual project integration: Scenario Adaptability: Based on the integration scenario (RTE scenario or non-RTE scenario) indicated by the configuration information, the unit adaptively generates component code of different forms. For RTE scenarios that require integration with the AUTOSAR runtime environment, the generated component code will include complete service port mapping logic, interface definitions, and encapsulation of periodic scheduling functions, enabling it to function as a standard AUTOSAR software component and interact with other applications or service components within the system through RTE. For non-RTE scenarios, more direct call interface code is generated.

[0042] Architecture Compatibility: The generated interactive components strictly map to the actual physical deployment architecture of the BSW module. Especially when the configuration file indicates that a BSW module is deployed in multiple different ECU partitions in an RTE scenario, this unit will automatically generate an independent interactive component instance for each corresponding partition based on this configuration. This ensures that UpperTester's test logic can be correctly split and deployed to the same partition as the target BSW module, thereby achieving accurate test access that conforms to the actual architecture.

[0043] Ultimately, these generated interactive components receive the parsing results from the test agent (or directly from the communication interface) and call the standard service interface of the corresponding BSW module to perform specific test operations such as diagnostic service requests and communication signal reading and writing.

[0044] This component-based generation mechanism endows the system with strong adaptability, enabling it to flexibly handle different project integration scenarios. Specifically, when generating BSW interactive component code, the code generation module automatically adapts the code's interface and calling methods based on the integration environment indicated in the configuration file (e.g., whether it runs under the AUTOSAR runtime environment). In scenarios requiring integration with the AUTOSAR runtime environment, the generated component code includes necessary service port mapping logic and periodic scheduling function encapsulation, allowing it to interact with existing application or service components in a standardized manner, just like standard AUTOSAR software components. Furthermore, when the configuration file indicates that the BSW module under test will be deployed in multiple different ECU partitions, the BSW interactive component generation unit will generate independent interactive component instances for the same BSW module in different partitions according to the configuration, thereby ensuring that UpperTester's logic can correctly match the actual physical deployment architecture of the BSW module.

[0045] The code generation module follows key design principles to ensure the generated UpperTester code has good reusability and adaptability: First, it generates atomic stub code that is decoupled from specific test steps. The execution logic of the test cases themselves is defined by external scripts, rather than being fixed in C code. Second, all communication between UpperTester and the host computer test script is based on standardized bus data flow, mainly using a request-response pattern, and supports independent periodic event reporting. Finally, the format design of communication data packets is decoupled from the underlying physical bus type, and a built-in data packet assembly / disassembly and caching mechanism is included to adapt to the frame length limitations of different buses and ensure reliable data feedback after communication is temporarily interrupted and resumed.

[0046] This layered generation architecture makes UpperTester code structure clear, easy to maintain and extend, and can flexibly adapt to complex integration scenarios where BSW modules are deployed in different partitions.

[0047] Example 6: This embodiment, based on embodiment 5, specifically defines the message protocol followed by the communication interface. This predefined protocol mainly includes three message types: request messages, response messages, and event messages, to support a complete interactive process. Request and response messages contain submodule identifiers and operation data.

[0048] Specifically, request messages (sent from the test equipment to the DUT) and response messages (sent from the DUT to the test equipment) have a specific structure. Both contain a submodule identifier (SUB_ID) field, which identifies the target BSW module (e.g., referencing the ID in the AUTOSAR standard module list), ensuring that instructions can be accurately routed to the corresponding test agent or BSW interaction component generated in Example 5. In addition, the messages also contain an operation data field to carry specific command parameters or return results. This structured protocol design decouples the test logic from the underlying bus type (such as CAN or Ethernet), unifies the communication data packet format, and only requires transmission on one channel of one bus, simplifying system design and enhancing versatility.

[0049] The design table for UpperTester's communication messages is as follows:

[0050] The message ID and length are configured in the UpperTester interface and other BSW modules.

[0051] SUB_ID: Corresponds to the submodule of UT. Existing BSW modules refer to the standard specification. 《AUTOSAR_TR_BSWModuleList.pdf》List of Basic Software Modules, including modules and module IDs; other modules should be added based on this.

[0052] The message protocol defines the complete interaction semantics. In the response message, the return code field is used to explicitly indicate the request processing status. For example, a return code "0" represents success, "1" indicates that the submodule identifier is not supported, "2" indicates a data length error, and "4" indicates that the UpperTester receive buffer is full. The range of return codes "128 to 255" is reserved for individual BSW modules to define their own. In addition, the entire communication link (such as the bus type, channel, and message ID used) is uniformly set in the graphical interface and related BSW module configurations, ensuring end-to-end consistency.

[0053] Example 7: This embodiment, based on embodiment 5, adds a performance acquisition code generation unit 34 to the code generation module 3. This unit is used to automatically generate instrumentation code required for performance testing.

[0054] Once the user specifies the performance metrics to be collected (such as CPU load, stack consumption, and data link transmission time) and their collection scope (i.e., the specific Runnable) in the configuration information, this unit will automatically insert specific collection code into the code of the corresponding runnable entity. For example, timestamp recording code is inserted at the entry and exit points of the Runnable to calculate execution time. These automatically generated instrumentation codes enable UpperTester to automatically collect key performance data at runtime. Specifically, performance metric collection covers, but is not limited to: CPU load, stack consumption of tasks or functions, and data link transmission time (e.g., the shortest and longest time from the application layer initiating data writing to the driver layer actually completing the transmission). The instrumentation code is precisely inserted into the specified runnable entity by the code generation module according to the configuration information, thereby achieving non-intrusive automated collection. It is also reported through the communication interface, thus realizing the automation of performance testing without requiring testers to manually write tedious measurement code.

[0055] Example 8: This embodiment adds a load simulation code generation unit 35 to the code generation module 3, based on embodiment 5. This unit is used to generate code that simulates real controller load scenarios.

[0056] Load simulation includes time consumption simulation and stack consumption simulation. Once the user configures the Runnable or interrupt service routine requiring load simulation, this unit generates the corresponding simulation code and inserts it into the target location. Load simulation aims to simulate the resource consumption scenarios of a real controller. For runtime simulation, the generated code implements deterministic delays by accessing hardware timing registers. The delay length can be controlled by configuration parameters (e.g., within the range of 50 microseconds to 10 milliseconds), and its on / off state and duration are managed by global variables unique to each task or interrupt service routine. For stack consumption simulation, this is achieved by generating code that calls specific recursive functions. This recursive logic is designed to be controllable to simulate non-linear stack growth, and its depth and behavior are also controlled by dedicated global variables. For example, generating code that accesses hardware registers to achieve deterministic and precise delays, or generating code that calls specific recursive functions to consume stack space. These codes are typically controlled by global variables in terms of their on / off state and intensity (e.g., delay length). By automatically generating and injecting load simulation code, the behavior of products under various stress conditions can be efficiently simulated in a laboratory environment, greatly improving the adequacy and reliability of testing.

[0057] Example 9: This invention also provides an automated method for AUTOSAR software functional testing, characterized in that it is applied to the automated system described above, such as... Figure 3 As shown, the automation methods include: Step S1: Receive the test configuration information input by the user and store it as a standard format configuration file. The information should at least specify the BSW module under test, the range of performance metrics of interest, and the load task to be simulated.

[0058] Step S2: Based on the configuration file mentioned above, and combined with the pre-stored test case templates associated with BSW functionalities, an executable test script that perfectly matches the current project configuration is automatically generated. The core of this step is "filling the template according to the configuration," which achieves automatic adaptation of test cases.

[0059] Step S3: Based on the same configuration file, automatically generate UpperTester integration code that conforms to the AUTOSAR componentization specification. This code includes necessary components such as communication, proxy, and execution, and is a software module that can be directly compiled and integrated.

[0060] Step S4: Embed the UpperTester integration code generated in step S3 into the software engineering of the device under test (DUT) to complete the integration.

[0061] Step S5: Run the executable test script generated in step S2. This script controls the UpperTester code integrated into the DUT through a predefined protocol, automatically executing a series of test operations and collecting feedback results.

[0062] This method forms a complete automated testing pipeline through five major steps: configuration, script generation, code generation, integration, and execution, completely changing the traditional manual, sequential, and project-specific test preparation mode.

[0063] The test operations in step S5 include one or more of the following: functional testing of the BSW module, performance metric collection, or load simulation.

[0064] Specifically, this embodiment details the test operation in the final step. Step S5, performed by the device under test integrated with UpperTester, is a comprehensive test process, mainly including one or more of the following types of combinations: Functional testing of the BSW module: This involves verifying whether each basic software module (such as diagnostics, communication, and storage) functions correctly according to the AUTOSAR specification and project requirements. This is the most crucial testing content.

[0065] Performance metrics collection: While performing functional tests or in specific scenarios, automatically collect performance data such as CPU utilization, task stack usage depth, and end-to-end communication latency for performance evaluation.

[0066] Load simulation: Injecting simulated computing or storage loads into the system to test its stability and performance under stress conditions, and to verify the system's robustness.

[0067] By supporting the automated execution of these three categories of test operations, the method of this invention can meet all-round testing needs from basic functional verification to advanced performance and reliability assessment.

[0068] The above are merely preferred embodiments of the present invention and are not intended to limit the implementation methods and protection scope of the present invention. Those skilled in the art should recognize that any equivalent substitutions and obvious changes made using the content of this specification and illustrations should be included within the protection scope of the present invention.

Claims

1. An automated system for AUTOSAR software function testing, characterized in that, include: The configuration module is used to receive test configuration information input by the user. The test configuration information includes at least one or more of the following: the selected BSW module under test, the range of performance indicators collected, and the load simulation task. The module stores the test configuration information as a configuration file in a standard format. A test script generation engine, connected to the configuration module, is used to generate an executable test script corresponding to the current project configuration based on the configuration file and pre-stored test case templates associated with BSW function points. The code generation module, connected to the configuration module, is used to generate UpperTester integration code conforming to the AUTOSAR architecture according to the configuration file. The UpperTester integration code is used to integrate into the device under test to perform test operations on the corresponding BSW module according to the instructions of the executable test script.

2. The automated system of claim 1, wherein, The configuration module provides a graphical user interface, and the test configuration information also includes bus message association and parsing logic configuration and test data filtering rule configuration.

3. The automation system according to claim 1, characterized in that, The configuration file is in ARXML format.

4. The automated system of claim 1, wherein, The test script generation engine includes a template library and a parser. The template library stores the test case templates, and the parser is used to parse the configuration file to determine the list of BSW function points and specific parameters adopted by the current project, and fill the parameters into the corresponding test case template to generate the executable test script.

5. The automated system of claim 1, wherein, The code generation module includes: A communication interface generation unit is used to generate the communication interface code of UpperTester, wherein the communication interface is configured to communicate with the host computer test device in accordance with a predefined message protocol. The test agent generation unit is used to generate code for one or more test agents in UpperTester based on the configuration file, wherein the test agents are configured to parse instructions received through the communication interface; The BSW interaction component generation unit is used to generate interaction component code in UpperTester corresponding to each BSW module based on the BSW module to be tested specified in the configuration file. The interaction component is configured to respond to the parsing result of the test agent and call the corresponding BSW service interface to perform test operations.

6. The automated system of claim 5, wherein, The predefined message protocol includes request messages, response messages, and event messages, wherein the request messages and response messages contain submodule identifiers and operation data.

7. The automated system of claim 5, wherein, The code generation module also includes a performance acquisition code generation unit, which is used to generate instrumentation code for acquiring performance metrics in a specified runnable entity.

8. The automated system of claim 5, wherein, The code generation module also includes a load simulation code generation unit, which generates code that simulates the execution of load in a specified runnable entity.

9. An automated method of AUTOSAR software function testing, characterized in that, Applied to the automation system as described in any one of claims 1-8, the automation method comprises: Step S1: The automated system receives the test configuration information input by the user and stores the test configuration information as a standard format configuration file. The test configuration information includes at least one or more of the following: the selected BSW module under test, the range of performance indicators collected, and the load simulation task. Step S2: The automation system generates an executable test script corresponding to the current project configuration based on the configuration file and the pre-stored test case templates associated with the BSW function points. Step S3: The automated system generates UpperTester integration code that conforms to the AUTOSAR architecture based on the configuration file; Step S4: The automated system integrates the UpperTester integration code into the device under test; Step S5: The automated system runs the executable test script and controls the device under test, which has integrated UpperTester code, to perform the corresponding test operations.

10. The automated method of claim 9, wherein, The test operations in step S5 include one or more of the following: functional testing of the BSW module, performance indicator collection, or load simulation.

Images