Black-box testing method, device and equipment for in-vehicle infotainment software and storage medium

Abstract

The invention belongs to the technical field of software testing, and discloses a black box testing method, device and equipment for in-vehicle software and a storage medium. The method comprises the following steps: acquiring a to-be-tested vehicle-mounted machine application; comparing the to-be-tested vehicle machine application with a historical vehicle machine application to generate a change method set; a preset method library is inquired according to method items in the change method set, test cases corresponding to the method items are screened out, and the test cases cover the method items during operation; and completing a regression test according to the test case. By means of the mode, under the condition that an executor does not need to carry out white box code analysis, the corresponding regression case is matched for the code change content, and the purposes of accurately classifying the test range and improving the version test efficiency are achieved.

Description

Technical Field

[0001] This invention relates to the field of software testing technology, and in particular to a black-box testing method, apparatus, equipment, and storage medium for vehicle infotainment software. Background Technology

[0002] As car cockpits become increasingly intelligent, users will use various vehicle control, video, and entertainment software to enhance their driving experience. In order to ensure user experience and enhance competitiveness, OEMs also need to continuously optimize and iterate the functions of in-vehicle software and introduce new features.

[0003] Frequent version iterations pose challenges to the quality assurance and testing efficiency of testing teams. Under existing solutions, black-box testers typically define the regression scope based on developer assessments, code change logs, and test case priorities. Manually assessing the impact scope is prone to omissions, and in black-box scenarios, to ensure test quality, many irrelevant test cases are often filtered out, or even full-scale testing is performed, which also affects the efficiency of version testing. Analyzing the code step-by-step through white-box testing is both labor-intensive and impractical. Therefore, how to efficiently and effectively complete a round of iterative testing has become a problem that needs to be solved.

[0004] The above content is only used to help understand the technical solution of the present invention and does not represent an admission that the above content is prior art. Summary of the Invention

[0005] The main objective of this invention is to provide a black-box testing method, apparatus, device, and storage medium for vehicle infotainment software, aiming to solve the technical problem of low efficiency in existing code testing.

[0006] To achieve the above objectives, the present invention provides a black-box testing method for in-vehicle infotainment software, the method comprising the following steps: Obtain the in-vehicle infotainment application to be tested; The vehicle infotainment application to be tested is compared with historical vehicle infotainment applications to generate a set of change methods; Based on the method items in the set of change methods, a preset method library is queried to filter out the test cases corresponding to the method items. The test cases override the method items when they are run. Complete the regression test based on the test cases described.

[0007] Optionally, the preset method library stores a test case mapping between vehicle system test cases and method items covered by vehicle system test cases.

[0008] Optionally, after comparing the vehicle infotainment application to be tested with historical vehicle infotainment applications to generate a set of change methods, the method further includes: Based on the method items in the modified method set, query the preset method library and filter out the newly added method items in the modified method set; Determine the target test cases based on the newly added method items; Update the test case mapping based on the target test cases and the newly added method items.

[0009] Optionally, determining the target test case based on the newly added method item includes: The calling relationship of the newly added method items is determined based on the newly added method items; If the call relationship indicates that there is no existing method call, obtain the code information of the newly added method. Target test cases are generated based on the code information of the newly added method item.

[0010] Optionally, determining the target test case based on the newly added method item includes: The calling relationship of the newly added method items is determined based on the newly added method items; If the call relationship indicates that an existing method item is being called, then the test case corresponding to the existing method item is determined to be the target test case.

[0011] Optionally, after querying the preset method library based on the method items in the change method set and filtering out the test cases corresponding to the method items, the method further includes: Based on the test cases, conduct application testing to determine the corresponding test code coverage information; Establish a test case mapping relationship based on the test cases and test code coverage information; Update the test case mapping based on the test case mapping relationship.

[0012] Optionally, the method further includes: The covered code information is determined based on the code coverage information; Generate a readable code report based on the covered code information; When the code-readable report is displayed, the system responds to user operation commands and generates user-targeted test cases. Complete regression testing based on the user target test cases.

[0013] Optionally, determining the target test case based on the newly added method item includes: The calling relationship of the newly added method items is determined based on the newly added method items; If the call relationship indicates that there is no existing method call, obtain the code information of the newly added method. Target test cases are generated based on the code information of the newly added method item.

[0014] Optionally, determining the target test case based on the newly added method item includes: The calling relationship of the newly added method items is determined based on the newly added method items; If the call relationship indicates that an existing method item is being called, then the test case corresponding to the existing method item is determined to be the target test case.

[0015] Furthermore, to achieve the above objectives, the present invention also proposes a black-box testing device for vehicle infotainment software, the black-box testing device for vehicle infotainment software comprising: The acquisition module is used to acquire the in-vehicle infotainment application to be tested; The processing module is used to compare the vehicle infotainment application to be tested with historical vehicle infotainment applications and generate a set of change methods; The processing module is used to query a preset method library based on the method items in the change method set, filter out the test cases corresponding to the method items, and the test cases cover the method items when they are run. The processing module is used to complete regression testing based on the test cases.

[0016] Furthermore, to achieve the above objectives, the present invention also proposes a black-box testing device for vehicle infotainment software. The black-box testing device for vehicle infotainment software includes: a memory, a processor, and a black-box testing program for vehicle infotainment software stored in the memory and executable on the processor. The black-box testing program for vehicle infotainment software is configured to implement the steps of the black-box testing method for vehicle infotainment software as described above.

[0017] Furthermore, to achieve the above objectives, the present invention also proposes a storage medium storing a black-box test program for vehicle infotainment software, wherein when the black-box test program for vehicle infotainment software is executed by a processor, the steps of the black-box test method for vehicle infotainment software as described above are implemented.

[0018] This invention acquires the in-vehicle infotainment application to be tested; compares the application with historical applications to generate a set of modification methods; queries a preset method library based on the method items in the modified method set to select test cases corresponding to the method items, and the test cases cover the method items during runtime; and completes regression testing based on the test cases. Through this method, it achieves the goal of accurately defining the test scope and improving version testing efficiency by matching corresponding regression test cases to code changes without requiring white-box code analysis by the implementers. Attached Figure Description

[0019] 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.

[0020] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, for those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0021] Figure 1 This is a flowchart illustrating the first embodiment of the black-box testing method for vehicle infotainment software of the present invention; Figure 2 This is a schematic diagram of test case mapping for an embodiment of the black-box testing method for vehicle infotainment software of the present invention; Figure 3 This is a schematic diagram of test case mapping for an embodiment of the black-box testing method for vehicle infotainment software of the present invention; Figure 4 This is a flowchart illustrating the second embodiment of the black-box testing method for vehicle infotainment software of the present invention; Figure 5 This is a flowchart illustrating an embodiment of the black-box testing method for vehicle infotainment software of the present invention. Figure 6 This is a structural block diagram of the first embodiment of the black-box testing device for vehicle infotainment software of the present invention; Figure 7 This is a schematic diagram of the structure of a black-box testing device for the vehicle infotainment software in the hardware operating environment involved in the embodiments of the present invention.

[0022] The realization of the objective, functional features and advantages of the present invention will be further explained in conjunction with the embodiments and with reference to the accompanying drawings. Detailed Implementation

[0023] It should be understood that the specific embodiments described herein are merely illustrative of the technical solutions of this application and are not intended to limit this application.

[0024] To better understand the technical solution of this application, a detailed description will be provided below in conjunction with the accompanying drawings and specific implementation methods.

[0025] The main solution of this application embodiment is as follows: obtain the vehicle infotainment application to be tested through a server; compare the vehicle infotainment application to be tested with historical vehicle infotainment applications to generate a set of change methods; query a preset method library according to the method items in the set of change methods, filter out the test cases corresponding to the method items, and the test cases cover the method items when they are run; and complete regression testing according to the test cases.

[0026] In this embodiment, for ease of description, the following description will take the identification server as the execution subject.

[0027] Frequent version iterations of existing technologies pose challenges to the quality assurance and testing efficiency of testing teams. Under current solutions, black-box testers typically define the regression scope through developer assessments, code change logs, and test case prioritization. Manually assessing the impact scope is prone to omissions, and in black-box scenarios, to ensure test quality, many irrelevant test cases are often filtered out, or even full-scale testing is performed, which also affects the efficiency of version testing. Analyzing the code step-by-step through white-box testing is both labor-intensive and impractical. Therefore, how to efficiently and effectively complete a round of iterative testing has become a problem that needs to be solved.

[0028] This application provides a solution for precise testing of in-vehicle infotainment software black-box testing. It enables the matching of corresponding regression test cases to code changes without requiring white-box code analysis by the test personnel, thereby achieving the goal of accurately defining the test scope and improving version testing efficiency.

[0029] It should be noted that the executing entity in this embodiment can be a computing service device with data processing, network communication, and program execution functions, such as a tablet computer, personal computer, or mobile phone, or an electronic device or server capable of performing the above functions. The following description uses a server as an example to illustrate this embodiment and the subsequent embodiments.

[0030] Based on this, embodiments of this application provide a black-box testing method for in-vehicle infotainment software, referring to... Figure 1 , Figure 1 This is a flowchart illustrating the first embodiment of the black-box testing method for vehicle infotainment software in this application.

[0031] In this embodiment, the black-box testing method for the vehicle infotainment software includes the following steps: Step S10: Obtain the vehicle infotainment application to be tested.

[0032] It's important to note that black-box regression testing for vehicle applications requires a large number of regression test cases. In in-vehicle infotainment software black-box regression testing, regression testing refers to the process of rigorously verifying that the original functions, performance, and stability of the in-vehicle infotainment system (such as navigation, multimedia, and vehicle settings) have not been compromised or degraded after software updates or modifications by re-executing existing test cases. This test focuses on the software's external interface behavior (input / output) and does not involve internal code logic. Its purpose is to ensure that the new version performs well in various in-vehicle environments, user operations, and interaction scenarios. This is a crucial quality control step to ensure vehicle functional safety and user experience continuity.

[0033] It should be noted that, based on the requirements of regression testing, test cases need to be further and reasonably selected. The specific selection process should be based on the in-vehicle infotainment application to be tested. The in-vehicle infotainment application to be tested can be navigation software, human-machine interaction software, or audio-visual entertainment software, etc. In in-vehicle infotainment regression testing, the application to be tested can be determined by parsing the system's pre-installed list (such as vehicle settings, navigation core module), OTA update packages, and certified third-party in-vehicle applications.

[0034] Step S20: Compare the vehicle infotainment application to be tested with the historical vehicle infotainment applications to generate a set of change methods.

[0035] It is understandable that the historical in-vehicle infotainment application is the historical version of the in-vehicle infotainment application to be tested. In order to detect changes in the in-vehicle infotainment application to be tested, the in-vehicle infotainment application to be tested is compared with the historical in-vehicle infotainment application, and the methods or functions that cause changes are the set of change methods.

[0036] In a specific implementation, this embodiment proposes a preferred scheme for obtaining the set of change methods. For example, in the regression testing of vehicle-mounted applications, generating the set of change methods requires using an automated comparison toolchain (such as Git Diff or a binary difference analyzer) to perform a fine-grained difference scan on the software packages of historical and new versions. When a new version of the APP is released, the set of change methods in the new version of the APP is filtered out through GitDiff records and denoted as the set of change methods D = {d1, d2, ..., dn}.

[0037] Step S30: Query the preset method library according to the method items in the change method set, filter out the test cases corresponding to the method items, and the test cases cover the method items when they are run.

[0038] It should be noted that the default method library is a database that stores mapping relationships. These mapping relationships preserve the connections between prepared test cases and the methods or functions covered by those test cases. Therefore, the test cases corresponding to a method item can be determined through that method item.

[0039] Understandably, by searching each dx (method item) within the predefined method library, mapping data containing the relevant methods can be found. For example... Figure 2As shown, if the new version modifies method items d1 and d2, resulting in multiple test cases case1, case2, ..., casen, if the corresponding test case case1 in the mapping data c1 contains method items d1 and d2, and the corresponding test case case n in the mapping data cn contains d1, then case1 and casen are the test cases that need regression, while case2 does not need regression. This process can be repeated to filter out the range of test cases that need regression.

[0040] Step S40: Complete the regression test according to the test cases.

[0041] Understandably, after determining all test cases, regression testing can be performed on each version based on the selected test cases to conduct black-box regression testing, thereby improving the quality and efficiency of testing.

[0042] In some embodiments, step S50: query a preset method library based on the method items in the modified method set, and filter out the newly added method items in the modified method set; step S60: determine the target test case based on the newly added method item; step S70: update the test case mapping based on the target test case and the newly added method item.

[0043] It's understandable that automatically identifying new methods is necessary, especially during development when features are constantly changing and function call chains evolve. A single test case might involve 3 to 5 methods after iteration, and the old mapping database might not contain these new methods. If the old mapping database is continuously used, subsequent modifications to newly added methods will fail to filter out any test cases, resulting in omissions. For example, suppose version A modifies the feature corresponding to case 1, adding method c to class A. Since the new method cannot be used indiscriminately, method a must be modified to call c. At this point, the actual mapping relationship between the test case and the code has changed, but the mapping database remains old. While we can still filter out case 1 for regression testing based on method d1 when testing version A, we cannot filter out any test cases when only method c is modified in version B, leading to test omissions. Therefore, for the test cases filtered by this solution, coverage needs to be re-collected and the mapping database updated during testing for each version.

[0044] In some embodiments, step S601: determine the calling relationship of the newly added method item based on the newly added method item; step S602: if the calling relationship is that there is an existing method item calling, determine that the test case corresponding to the existing method item is the target test case.

[0045] It should be noted that if the call relationship indicates an existing method call, it means there is a binding relationship between the new method and the existing method. In this case, it is only necessary to add the mapping relationship of the new method to the test case mapping corresponding to the existing method, such as... Figure 3 Suppose that in version A, we built an initial mapping database using code coverage data collection, where test case 1 was mapped to methods a and b, and case 2 to method c. In version B, the team optimized the code corresponding to the functionality of case 1, specifically by adding method d and adding calling logic to method b (method d cannot be called independently). Git diff identified the changes to methods b and d, and based on the mapping database, case 1 was identified as needing regression testing, with no omissions in the test scope. However, in version C, this functionality was further optimized, specifically modifying the internal implementation of method d. At this point, Git diff only identified the change to method d, but since none of the test cases in the mapping database were associated with method d, no regression test cases could be selected, resulting in omissions in the test scope. Analysis shows that after the release of version B, the actual mapping scope of case 1 should be updated to a, b, and d. Therefore, during regression testing in version B, we should re-collect coverage data for case 1, determine case 1 as the target test case, and update the mapping relationship. If this step can be completed, case 1 can be accurately selected for regression testing in version C using method d, thus avoiding testing blind spots during the iteration process. In summary, to ensure the long-term accuracy of regression testing, timely updating the mapping data of test cases after each regression is a crucial practice.

[0046] In some embodiments, step S601': determine the calling relationship of the newly added method item based on the newly added method item; step S602': if the calling relationship is that there is no existing method item calling, obtain the code information of the newly added method item; step S603': generate target test cases based on the code information of the newly added method item.

[0047] It is understandable that if the call relationship indicates that no existing method item is being called, it means that the newly added method needs to be called separately. Therefore, a corresponding test case needs to be added as the target test case, for example: Figure 3As shown, in version A, the navigation system only supports daytime mode. Correspondingly, test case 1 is used to verify the UI performance in daytime mode. This test case covers initialization method a and interface drawing method b, so its mapping data includes methods a and b. In version B, the system added a nighttime mode function, specifying that the nighttime interface should be displayed between 18:00 and 7:00 the next day. At the code level, a new method c for drawing the nighttime mode was added, and time judgment logic was added to the initialization method a to dynamically call method b (daytime) or method c (nighttime). However, although code difference analysis can identify changes in methods a and c, and test case 1 is selected for regression testing, this test case only covers the execution path a→b and cannot verify the newly added a→c call chain. Therefore, test case 2 must be added to simulate a nighttime scenario to trigger the test of method c, and its mapping relationship should be collected and updated to the database after execution to ensure that subsequent changes to method c can be correctly associated with the regression scope. In practice, Case 2 can usually be designed based on the product specification and data collection can be completed during the B version testing phase. If the specification omits this function, it can be intercepted through a fallback mechanism: after the version testing and database update are completed, the system automatically retrieves all the change methods in the current version. If it finds that a certain method is not covered by any test cases (such as method c having no corresponding test cases before the update), it automatically outputs its code snippet, prompting manual intervention to review and supplement the corresponding test cases, so as to ensure the synchronous improvement of code changes and test coverage.

[0048] In some embodiments, application testing is performed based on the test cases to determine the corresponding test code coverage information; a test case mapping relationship is established based on the test cases and the test code coverage information; and the test case mapping is updated based on the test case mapping relationship.

[0049] It should be noted that, firstly, the mapping process, in addition to selecting test cases, also needs to be updated simultaneously to prevent errors in the mapping relationship after multiple version iterations. The mapping database maintenance in this solution involves two aspects: 1. Within each test cycle, test cases selected by method dx must have their data re-collected during execution and updated in the mapping database. 2. For entirely new features, new test cases are written, executed, and their data collected and added to the mapping database, thus ensuring the mapping data remains up-to-date. Each version establishes a mapping for the data collected from newly added code. When subsequent methods change, matching can be performed in the database to select corresponding test cases for testing.

[0050] In some embodiments, the code coverage information is determined based on the code coverage information; a code readability report is generated based on the code coverage information; when the code readability report is displayed, user target test cases are generated in response to user operation instructions; and regression testing is completed based on the user target test cases.

[0051] It's important to note that during project development, functionalities are constantly changing, and function call chains will also change accordingly. The same test case might involve 3 to 5 methods after an iteration, and the old mapping database wouldn't contain these new methods. If the old mapping database continues to be used, no test cases will be found when adding new methods later, resulting in omissions. Therefore, during the filtering process, if new method items are identified, a readable code report is generated based on code coverage information for user reference. Corresponding user target test cases are generated based on user instructions. In other words, if new functionalities are added during the filtering process, after writing and executing test cases, the mapping data user target test case Cm' is also collected, and the new Cm' is updated in the mapping database to prepare for the next iteration.

[0052] This solution is a black-box precision testing solution. During the development and iteration cycle of Android app software, testers can use this solution to accurately select regression test cases when performing black-box regression testing on each version, thereby improving the quality and efficiency of testing. The entire solution includes a set of test case mapping data collection, maintenance, and application processes to support the operation of the solution, as well as three self-developed automated tools for auxiliary process execution. This proposal mainly describes the former.

[0053] This embodiment acquires the in-vehicle infotainment application to be tested; compares the application with historical applications to generate a set of modification methods; queries a preset method library based on the method items in the set to select test cases corresponding to the method items, and the test cases cover the method items during runtime; regression testing is completed based on the test cases. Through this method, it achieves the goal of accurately defining the test scope and improving version testing efficiency by matching corresponding regression test cases to code changes without requiring white-box code analysis by the executors.

[0054] Based on the first embodiment of this application, in the second embodiment of this application, the content that is the same as or similar to that in the first embodiment described above can be referred to the above description, and will not be repeated hereafter. Based on this, please refer to... Figure 2 The black-box testing method for the vehicle infotainment software also includes: Step S101: Obtain vehicle infotainment system test cases.

[0055] It should be noted that this embodiment is applied to the generation process of the preset method library. At this time, the vehicle system test cases obtained should be the full set of test cases edited by the testers.

[0056] Step S102: Perform application testing on the vehicle infotainment test cases to determine the corresponding code coverage information.

[0057] Understandably, testing an application with a full set of test cases yields code coverage information. For example, a project's full set of test cases can be denoted as CASE = {case1, case2, ..., case n}, and this could be a specific test case for a navigation app. Our modified app allows us to collect code coverage data (the relevant code executed during app runtime) during test execution. For instance, the test case on the right is used to test the "navigation view switching" function. When testing this function, all code executed by the navigation app will be captured, and this data represents the code coverage of this test case. The generated readable report, as shown in the right image, includes details of which specific line of code and which if branch was executed.

[0058] Step S103: Establish a test case mapping based on the vehicle infotainment test cases and the code coverage information corresponding to the vehicle infotainment test cases.

[0059] Understandably, once the code coverage information of the test cases is obtained, it is possible to determine which code a particular test case covers, and then establish a test case mapping. For example, a test case mapping can establish a mapping between test cases and code line information, logical branches, methods, classes, and other levels.

[0060] In some embodiments, the covered method items and / or covered functions are determined based on the code coverage information corresponding to the vehicle infotainment test cases; a mapping relationship between vehicle infotainment test cases and method items is established based on the covered method items and / or covered functions; and a test case mapping is generated based on the mapping relationship.

[0061] It should be noted that the "method item" mentioned in this embodiment refers to code structures such as methods and functions. It should be noted that, in order to meet the optimal layer requirements for in-vehicle infotainment applications, this embodiment proposes establishing a mapping at the method or function level. This is because this level can maximize the preservation of test case accuracy while ensuring a certain level of efficiency. For example, in practical applications, coverage data is processed and retained at the method / function level. After processing, the set of methods executed by each test case can be obtained, denoted as C = {c1, c2, ..., cn}. Thus, we can establish a one-to-one mapping relationship between test cases (case x) and the methods (cx) executed during test case execution. Therefore, we also call cx the mapping data, and the dataset C is called the mapping database.

[0062] In some embodiments, an Extensible Markup Language (XML) document is generated based on the code coverage information corresponding to the vehicle infotainment test cases; Document Object Model (DOM) node information is extracted based on the XML document; and the covered method items and / or covered functions are determined based on the DOM node information.

[0063] In practical implementation, Extensible Markup Language (XML) documents are equivalent to XML documents, and Document Object Model (DOM) node information is equivalent to DOM node information, such as... Figure 3 As shown, this embodiment proposes a preferred method for determining coverage items. For example, JaCoCo is used to generate an XML report and extract coverage information from DOM nodes. First, when running the test suite, JaCoCo automatically records the code information (including methods, branches, line numbers, etc.) covered by each test case in the background. After the test is completed, JaCoCo temporarily saves this coverage data in binary format (usually a file with the .exec extension). The JaCoCo command-line tool is then used to perform the conversion to determine the generation of the XML report. The XML report is then parsed to extract information from the DOM nodes, extracting class and method information. Based on the extracted method information, the covered functions or methods are confirmed.

[0064] Step S104: Generate a preset method library based on the use case mapping.

[0065] It should be noted that the mapping relationship between test cases and methods or functions can be determined based on the test case mapping, and then added to the database to form a preset method library.

[0066] In specific implementations, such as Figure 3As shown, this embodiment proposes a preferred real-time solution, for example: 1. First, execute a full test of case 1 - case n, and establish a mapping database C = {c1, c2, ..., cn}; 2. After the navigation releases a new version, filter the set of methods changed between versions D = {d1, d2, ..., dn} in the Git navigation source code repository; 3. Search for each dx in the database. If a cm contains dx, it means that case m needs regression; 4. Test all cases m in the new navigation version and collect new mapping data Cm; 5. If there are new features, write test cases and execute them, and also collect mapping data Cm'; 6. Update the new Cm and Cm' into the mapping database to prepare for the next iteration.

[0067] This embodiment acquires vehicle infotainment system test cases; performs application testing on the vehicle infotainment system test cases to determine the corresponding code coverage information; establishes a test case mapping based on the vehicle infotainment system test cases and the corresponding code coverage information; and generates a preset method library based on the test case mapping. Through the above scheme, the preset method library is established, and the test case mapping is established through code coverage information, reasonably mapping the relationship between test cases and methods, thus improving the efficiency of test case selection.

[0068] Furthermore, this embodiment of the invention also proposes a storage medium storing a black-box testing program for vehicle infotainment software. When the black-box testing program for vehicle infotainment software is executed by a processor, it implements the steps of the black-box testing method for vehicle infotainment software as described above.

[0069] Reference Figure 4 , Figure 4 This is a structural block diagram of the first embodiment of the black-box testing device for vehicle infotainment software of the present invention.

[0070] like Figure 4 As shown, the black-box testing device for vehicle infotainment software proposed in this embodiment of the invention includes: Module 10 is used to acquire the vehicle infotainment application to be tested; Processing module 20 is used to compare the vehicle infotainment application to be tested with historical vehicle infotainment applications and generate a set of change methods; The processing module 20 is used to query a preset method library based on the method items in the change method set, filter out the test cases corresponding to the method items, and the test cases cover the method items when they are run. The processing module 20 is used to complete regression testing based on the test cases.

[0071] The black-box testing device for vehicle infotainment software provided in this application employs the black-box testing method for vehicle infotainment software in the above embodiments, and can solve the technical problem of black-box testing of vehicle infotainment software. Compared with the prior art, the beneficial effects of the black-box testing device for vehicle infotainment software provided in this application are the same as the beneficial effects of the black-box testing method for vehicle infotainment software provided in the above embodiments, and other technical features in the black-box testing device for vehicle infotainment software are the same as the features disclosed in the methods of the above embodiments, and will not be repeated here.

[0072] It should be understood that the above are merely illustrative examples and do not constitute any limitation on the technical solutions of the present invention. In specific applications, those skilled in the art can make settings as needed, and the present invention does not impose any restrictions on this.

[0073] In this embodiment, the acquisition module 10 acquires the vehicle infotainment application to be tested; the processing module 20 compares the vehicle infotainment application to be tested with historical vehicle infotainment applications to generate a set of change methods; the processing module 20 queries a preset method library based on the method items in the set of change methods to filter out the test cases corresponding to the method items, and the test cases cover the method items when they are run; the processing module 20 completes regression testing based on the test cases. Through the above method, it is possible to match the code changes with corresponding regression test cases without requiring white-box code analysis by the executors, thereby achieving the goal of accurately defining the test scope and improving version testing efficiency.

[0074] This application provides a black-box testing device for vehicle infotainment software. The black-box testing device for vehicle infotainment software includes: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, and the instructions are executed by the at least one processor to enable the at least one processor to execute the black-box testing method for vehicle infotainment software in the above embodiment 1.

[0075] The following is for reference. Figure 5 This document illustrates a schematic diagram of a black-box testing device suitable for implementing the vehicle infotainment software of the embodiments of this application. The black-box testing device for the vehicle infotainment software in the embodiments of this application may include, but is not limited to, mobile terminals such as mobile phones, laptops, digital radio receivers, PDAs (Personal Digital Assistants), PADs (Portable Application Description), PMPs (Portable Media Players), in-vehicle terminals (e.g., in-vehicle navigation terminals), and fixed terminals such as digital TVs and desktop computers. Figure 5 The black-box testing equipment for the vehicle infotainment software shown is merely an example and should not impose any limitations on the functionality and scope of use of the embodiments of this application.

[0076] like Figure 5 As shown, the black-box testing device for the vehicle infotainment system software may include a processing unit 1001 (e.g., a central processing unit, a graphics processing unit, etc.), which can perform various appropriate actions and processes according to the program stored in ROM (Read-Only Memory) 1002 or the program loaded from storage device 1003 into RAM (Random Access Memory) 1004. RAM 1004 also stores various programs and data required for the operation of the black-box testing device for the vehicle infotainment system software. The processing unit 1001, ROM 1002, and RAM 1004 are interconnected via bus 1005. Input / output (I / O) interface 1006 is also connected to the bus. Typically, the following systems can be connected to I / O interface 1006: input devices 1007 including, for example, touchscreens, touchpads, keyboards, mice, image sensors, microphones, accelerometers, gyroscopes, etc.; output devices 1008 including, for example, liquid crystal displays (LCDs), speakers, vibrators, etc.; storage devices 1003 including, for example, magnetic tapes, hard disks, etc.; and communication devices 1009. Communication device 1009 allows the black-box testing equipment for vehicle infotainment software to communicate wirelessly or wiredly with other devices to exchange data. Although a black-box testing equipment for vehicle infotainment software with various systems is shown in the figure, it should be understood that it is not required to implement or possess all the systems shown. More or fewer systems may be implemented alternatively.

[0077] Specifically, according to the embodiments disclosed in this application, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments disclosed in this application include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via a communication device, or installed from storage device 1003, or installed from ROM 1002. When the computer program is executed by processing device 1001, it performs the functions defined in the methods of the embodiments disclosed in this application.

[0078] The black-box testing equipment for vehicle infotainment software provided in this application, employing the black-box testing method for vehicle infotainment software in the above embodiments, can solve the technical problem of black-box testing of vehicle infotainment software. Compared with the prior art, the beneficial effects of the black-box testing equipment for vehicle infotainment software provided in this application are the same as the beneficial effects of the black-box testing method for vehicle infotainment software provided in the above embodiments, and other technical features in this black-box testing equipment for vehicle infotainment software are the same as those disclosed in the method of the previous embodiment, and will not be repeated here.

[0079] It should be understood that the various parts disclosed in this application can be implemented using hardware, software, firmware, or a combination thereof. In the description of the above embodiments, specific features, structures, materials, or characteristics can be combined in any suitable manner in one or more embodiments or examples.

[0080] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

[0081] This application provides a computer-readable storage medium having computer-readable program instructions (i.e., a computer program) stored thereon, which are used to execute the black-box testing method of the vehicle infotainment software in the above embodiments.

[0082] The computer-readable storage medium provided in this application may be, for example, a USB flash drive, but is not limited to, electrical, magnetic, optical, electromagnetic, infrared, or semiconductor systems, devices, or any combination thereof. More specific examples of computer-readable storage media may include, but are not limited to: electrical connections having one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof. In this embodiment, the computer-readable storage medium may be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, system, or device. The program code contained on the computer-readable storage medium may be transmitted using any suitable medium, including but not limited to: wires, optical cables, RF (Radio Frequency), etc., or any suitable combination thereof.

[0083] The aforementioned computer-readable storage medium may be included in the black-box testing equipment for the vehicle infotainment software; or it may exist independently and not be installed in the black-box testing equipment for the vehicle infotainment software.

[0084] The aforementioned computer-readable storage medium carries one or more programs. When the aforementioned one or more programs are executed by a black-box testing device for vehicle infotainment software, the black-box testing device for vehicle infotainment software performs the following actions: acquires the vehicle infotainment application to be tested; compares the vehicle infotainment application to be tested with historical vehicle infotainment applications to generate a set of change methods; queries a preset method library based on the method items in the set of change methods to select test cases corresponding to the method items, and the test cases cover the method items when they are run; and completes regression testing based on the test cases.

[0085] Computer program code for performing the operations of this application can be written in one or more programming languages ​​or a combination thereof, including object-oriented programming languages ​​such as Java, Smalltalk, and C++, and conventional procedural programming languages ​​such as the "C" language or similar programming languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network—including a Local Area Network (LAN) or a Wide Area Network (WAN)—or can be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0086] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, can be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0087] The modules described in the embodiments of this application can be implemented in software or hardware. The names of the modules do not necessarily limit the functionality of the unit itself.

[0088] The readable storage medium provided in this application is a computer-readable storage medium that stores computer-readable program instructions (i.e., a computer program) for executing the black-box testing method for the above-described vehicle infotainment software, thereby solving the technical problem of black-box testing of vehicle infotainment software. Compared with the prior art, the beneficial effects of the computer-readable storage medium provided in this application are the same as the beneficial effects of the black-box testing method for vehicle infotainment software provided in the above embodiments, and will not be repeated here.

[0089] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the steps of the black-box testing method for vehicle infotainment software as described above.

[0090] The computer program product provided in this application can solve the technical problem of black-box testing of vehicle infotainment software. Compared with the prior art, the beneficial effects of the computer program product provided in this application are the same as the beneficial effects of the black-box testing method for vehicle infotainment software provided in the above embodiments, and will not be repeated here.

[0091] The above description is only a part of the embodiments of this application and does not limit the patent scope of this application. All equivalent structural transformations made under the technical concept of this application and using the contents of the specification and drawings of this application, or direct / indirect applications in other related technical fields, are included in the patent protection scope of this application.

Claims

1. A black-box testing method for vehicle infotainment software, characterized in that, The black-box testing method for the vehicle infotainment software includes: Obtain the in-vehicle infotainment application to be tested; The vehicle infotainment application to be tested is compared with historical vehicle infotainment applications to generate a set of change methods; Based on the method items in the set of change methods, a preset method library is queried to filter out the test cases corresponding to the method items. The test cases override the method items when they are run. Complete the regression test based on the test cases described.

2. The method as described in claim 1, characterized in that, The preset method library stores a mapping between vehicle infotainment test cases and method items covered by vehicle infotainment test cases.

3. The method as described in claim 1, characterized in that, After comparing the vehicle infotainment application under test with historical vehicle infotainment applications to generate a set of change methods, the method further includes: Based on the method items in the modified method set, query the preset method library and filter out the newly added method items in the modified method set; Determine the target test cases based on the newly added method items; Update the test case mapping based on the target test cases and the newly added method items.

4. The method as described in claim 3, characterized in that, The step of determining the target test case based on the newly added method item includes: The calling relationship of the newly added method items is determined based on the newly added method items; If the call relationship indicates that an existing method item is being called, then the test case corresponding to the existing method item is determined to be the target test case.

5. The method as described in claim 3, characterized in that, The step of determining the target test case based on the newly added method item includes: The calling relationship of the newly added method items is determined based on the newly added method items; If the call relationship indicates that there is no existing method call, obtain the code information of the newly added method. Target test cases are generated based on the code information of the newly added method item.

6. The method as described in claim 1, characterized in that, After querying the preset method library based on the method items in the modified method set and filtering out the test cases corresponding to the method items, the method further includes: Based on the test cases, conduct application testing to determine the corresponding test code coverage information; Establish a test case mapping relationship based on the test cases and test code coverage information; Update the test case mapping based on the test case mapping relationship.

7. The method as described in claim 1, characterized in that, The method further includes: The covered code information is determined based on the code coverage information; Generate a readable code report based on the covered code information; When the code-readable report is displayed, the system responds to user operation commands and generates user-targeted test cases. Complete regression testing based on the user target test cases.

8. A black-box testing device for vehicle infotainment software, characterized in that, The black-box testing device for the vehicle infotainment software includes: The acquisition module is used to acquire the in-vehicle infotainment application to be tested; The processing module is used to compare the vehicle infotainment application to be tested with historical vehicle infotainment applications and generate a set of change methods; The processing module is used to query a preset method library based on the method items in the change method set, filter out the test cases corresponding to the method items, and the test cases cover the method items when they are run. The processing module is used to complete regression testing based on the test cases.

9. A black-box testing device for vehicle infotainment software, characterized in that, The device includes: a memory, a processor, and a black-box testing program for vehicle infotainment software stored in the memory and executable on the processor, the black-box testing program for vehicle infotainment software being configured to implement the steps of the black-box testing method for vehicle infotainment software as described in any one of claims 1 to 7.

10. A storage medium, characterized in that, The storage medium stores a black-box test program for the vehicle infotainment system software. When the black-box test program for the vehicle infotainment system software is executed by the processor, it implements the steps of the black-box test method for the vehicle infotainment system software as described in any one of claims 1 to 7.

Images