Method and device for checking updated software

Abstract

The invention discloses a method and a device for checking updated software. A method and apparatus for verifying updated software may be associated with an infotainment platform of a vehicle. The software inspection method includes: receiving data for software inspection from an external server or an external device; generating a flow graph based on the received data; updating the flow graph based on the updated change specification of the software; reconfiguring the updated flow graph based on an estimated frequency of use of a display identifier ID added in an updated change specification of the software; and verifying the changed specification of the software by performing a test on the reconfigured flow graph, where the display ID is a unique identifier assigned to each displayable screen during the software execution process.

Description

Technical Field

[0001] The present disclosure relates to a method and apparatus for verifying updated software (e.g., infotainment platform software for a vehicle), which can be updated based on big data and changing software specifications. Background Art

[0002] The increasing frequency and expansion of wireless and wired updates of in-vehicle infotainment systems have highlighted the importance of verifying software updates. Whether developing a new platform or project, there is an urgent need for more efficient and centralized software integration verification within a relatively short time frame during software verification and deployment. Traditional software verification methods mainly focus on evaluators based on constantly changing specifications, and user big data mainly serves general statistical purposes. However, the demand for more user-centric and intensive software verification methods has increased due to unexpected problems caused by customer usage scenarios after software deployment.

[0003] In traditional software verification techniques, user data is not fully utilized and only serves simple statistical purposes or does not actively contribute to the verification process. For infotainment systems deployed periodically and continuously, it is crucial to focus on verifying software based on actual user scenarios. Traditional user scenarios mainly rely on estimating user scenarios based on design specifications or evaluator experience.

[0004] Recently, with the increasing popularity of vehicle networking services and the accumulation of user information, user big data has become increasingly reliable, enabling the extraction of details about screens frequently used or displayed during actual user operations, and facilitating the creation of a user-based flow map by estimating user manipulation information through timestamp data during screen transitions. However, such information may not include details about newly added or changed screens when updating and redeploying software.

[0005] Therefore, in this technical field, there is a need for a technique that can estimate user manipulations of newly deployed software and verify software based on scenarios. Summary of the Invention

[0006] An object of the present disclosure is to provide a software verification method and apparatus that can derive the process of new screens based on internal logs and status information during a random test process for system stability evaluation of changed software specifications.

[0007] Another object of the present disclosure is to provide a software verification method and apparatus that can assign transition probabilities to the flow map of existing software based on existing information and updated information during new software deployment and apply probability tags based on the evaluation priorities of evaluators.

[0008] Another object of the present disclosure is to provide a software inspection method and apparatus that can estimate user manipulations of newly deployed software and inspect the software based on scenarios.

[0009] To achieve the above object, a software inspection method according to an embodiment of the present disclosure includes: receiving data for software inspection from an external server or an external device; generating a flow graph based on the received data; updating the flow graph based on an updated change specification of the software; reconfiguring the updated flow graph based on an estimated usage frequency of a display identifier (ID) added to the updated change specification of the software; and inspecting the changed specification of the software by performing a random test on the reconfigured flow graph, wherein the display ID is a unique identifier assigned to each screen that can be displayed during software execution.

[0010] Here, the flow graph can be generated based on at least one of exposure probability information of each display ID, the display ID, and time information.

[0011] Here, based on the flow graph before software update, the usage frequency of the added display ID is estimated based on the display frequency of the display ID immediately before the added display ID and the frequency of screen transitions to the display ID immediately after the added display ID.

[0012] Here, generating the flow graph may include: generating user exposure frequency data for each display ID; generating a screen operation flow based on a timestamp; and generating the flow graph based on the user exposure frequency data and the screen operation flow.

[0013] Here, updating the flow graph may include: filtering added or removed displays based on a user experience (UX) change specification of the software, filtering added or removed database (DB) data based on a communication database (DB) change specification of the software, generating a list of added or modified display IDs according to the updated change specification of the software, classifying the display IDs in the generated list into added display IDs and modified display IDs, detecting the added display IDs by performing a random test on the software, and updating the flow graph based on the connectivity between the added display IDs and existing display IDs.

[0014] Here, reconfiguring the flow graph may include: estimating the usage frequency of the added display ID; receiving weights for display IDs affected by the change specification of the updated software from a user, and reconfiguring the updated flow graph based on the usage frequency of the added display ID and the weights for display IDs affected by the changed specification.

[0015] Here, the data for software inspection may include information on a user screen of the software and user manipulation information.

[0016] Here, the test can be a random test.

[0017] Here, the software may be infotainment platform software for a vehicle.

[0018] Here, the software may be associated with the infotainment platform of the vehicle.

[0019] Meanwhile, a software inspection device according to an embodiment of the present disclosure includes: a transceiver configured to receive data for software inspection from an external server or an external device; and a processor configured to generate a flow graph based on the received data, update the flow graph based on an updated change specification of the software, reconfigure the updated flow graph based on an estimated usage frequency of a display identifier (ID) added in the updated change specification of the software, and inspect the change specification of the software by performing a random test on the reconfigured flow graph, wherein the display ID is a unique identifier assigned to each screen that can be displayed during software execution.

[0020] Here, the flow graph may be generated based on at least one of exposure probability information of each display ID, the display ID, and time information.

[0021] Here, based on the flow graph before software update, the usage frequency of the added display ID is estimated based on the display frequency of the display ID immediately before the added display ID and the frequency of transition to the screen of the display ID immediately after the added display ID.

[0022] Here, the processor may generate user exposure frequency data for each display ID, generate a screen operation flow based on a timestamp, and generate a flow graph based on the user exposure frequency data and the screen operation flow.

[0023] Here, the processor may filter added or removed displays based on a user experience (UX) change specification of the software, filter added or removed database (DB) data based on a communication database (DB) change specification of the software, generate a list of added or modified display IDs according to the updated change specification of the software, classify the display IDs in the generated list into added display IDs and modified display IDs, detect the added display IDs by performing a random test on the software, and update the flow graph based on the connectivity between the added display IDs and existing display IDs.

[0024] Here, the processor may estimate the usage frequency of the added display ID, receive weights of display IDs affected by the change specification of the updated software from a user, and reconfigure the updated flow graph based on the usage frequency of the added display ID and the weights of the display IDs affected by the change specification.

[0025] Here, the data for software inspection may include information on the user screen of the software and user manipulation information.

[0026] Here, the software can be associated with the vehicle's infotainment platform.

[0027] The vehicle may include a software inspection device.

[0028] As described in various embodiments, the present disclosure can improve the evaluation efficiency by using probability criteria to model action scenarios based on existing user data and by allocating weights to centrally examine action scenarios to verify user scenarios that are reasonable in the field.

[0029] In addition, for features newly introduced through software updates, the present disclosure reflects and verifies the display identifiers (IDs) newly applied through a flow chart based on the existing page transition probabilities, thereby allowing the probability of a user entering a newly added screen to be estimated based on the probability of the display ID before the new screen addition.

[0030] In addition, when the inspection result drops below the expected frequency or probability due to the influence of the usage rate and complexity of the previous page of the screen, the system designer can verify the design estimate by rearranging the screen to a path with a higher exposure probability in the flow chart according to the degree of exposure requirement of the screen.

[0031] The advantages of the present disclosure are not limited to the above advantages, and those skilled in the art can clearly understand other advantages not described herein from the following description. BRIEF DESCRIPTION OF THE DRAWINGS

[0032] Figure 1 is a diagram showing a software inspection device according to an embodiment of the present disclosure.

[0033] Figure 2 is an exemplary diagram showing the user exposure frequency of each display ID;

[0034] Figure 3 is a diagram showing an exemplary user scenario based on time information and display ID.

[0035] Figure 4 is a diagram showing that by Figure 3 including the exposure probability of each display ID in the corresponding user scenario and defining the main stream based on probability, an exemplary flow chart is generated.

[0036] Figure 5 is a diagram showing Figure 4 an exemplary flow chart after a software specification update with changes.

[0037] Figure 6 is a diagram showing Figure 4 a part of the flow chart of

[0038] Figure 7It is a flowchart showing a software verification method according to an embodiment of the present disclosure.

[0039] Figure 8 It shows the generation Figure 7 The flowchart of the details of the flowchart in;

[0040] Figure 9 It shows the update Figure 7 The flowchart of the details of the flowchart in;

[0041] Figure 10 It shows the reconfiguration Figure 7 The flowchart of the details of the flowchart in; and

[0042] Figure 11 It shows the verification Figure 7 The flowchart of the details of the changed software specification in. Detailed Description of the Invention

[0043] It should be understood that as used herein, the term "vehicle" or "vehicular" or other similar terms include motor vehicles in a broad sense, such as passenger vehicles, including sport utility vehicles (SUVs), buses, trucks, various commercial vehicles, boats (including various vessels and boats), airplanes, etc., and include hybrid vehicles, electric vehicles, plug-in hybrid electric vehicles, hydrogen-powered vehicles, and other alternative fuel vehicles (e.g., fuels derived from resources other than petroleum). As mentioned herein, a hybrid vehicle is a vehicle having two or more power sources, for example, a gasoline-powered and an electric vehicle.

[0044] The terms used herein are for the purpose of describing particular embodiments only and are not intended to limit the present disclosure. As used herein, unless the context clearly indicates otherwise, the singular forms "a", "an", and "the" are intended to include the plural forms as well. It should also be understood that when the terms "comprises" and / or "comprising" are used in this specification, they specify the presence of the stated features, integers, steps, operations, elements, and / or components, but do not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and / or combinations thereof. As used herein, the term "and / or" includes any and all combinations of one or more of the associated listed items. Throughout the specification, unless explicitly described to the contrary, the word "comprises" and variations such as "comprising" or "containing" will be understood to imply the inclusion of the stated element but not the exclusion of any other element. In addition, the terms "unit", "-er", "-or", and "module" described in the specification mean a unit for processing at least one function and operation, and can be implemented by hardware components or software components and combinations thereof.

[0045] In addition, the control logic of the present disclosure can be embodied as a non-volatile computer-readable medium on a computer-readable medium, which includes executable program instructions executed by a processor, a controller, etc. Examples of computer-readable media include, but are not limited to, ROM, RAM, compact disc (CD)-ROM, magnetic tape, floppy disk, flash drive, smart card, and optical data storage device. The computer-readable medium can also be distributed in a network-coupled computer system, such that the computer-readable medium is stored and executed in a distributed manner, for example, via a telematics server or a controller area network (CAN).

[0046] Hereinafter, embodiments disclosed in this specification will be described with reference to the accompanying drawings, in which the same reference numerals refer to the same or similar components, and redundant descriptions thereof are omitted. In addition, detailed descriptions of well-known technologies related to the embodiments disclosed in this specification may be omitted to avoid obscuring the subject matter of the embodiments disclosed in this specification. In addition, the drawings are only used to easily understand the embodiments disclosed in this specification and do not limit the technical spirit disclosed herein, and it should be understood that the embodiments include all changes, equivalents, and alternatives within the spirit and scope of the present disclosure.

[0047] As used herein, terms including ordinal numbers such as "first" and "second" may be used to describe various components without limiting the components. These terms are only used to distinguish one component from another.

[0048] It will be understood that when a component is referred to as being "connected to" or "coupled to" another component, it can be directly connected to or coupled to the other component, or there may be an intermediate component. In contrast, when a component is referred to as being "directly connected to" or "directly coupled to" another component, there is no intermediate component.

[0049] As used herein, unless the context clearly indicates otherwise, the singular form is also intended to include the plural form.

[0050] Figure 1 is a diagram showing a software inspection device according to an embodiment of the present disclosure.

[0051] Referring to Figure 1 , a software inspection device 100 according to an embodiment of the present disclosure includes a transceiver 110, a processor 130, and a storage unit 150.

[0052] The transceiver 110 can receive data for software inspection.

[0053] Here, the transceiver 110 can receive big data related to infotainment platform software from an external server or an external device.

[0054] The processor 130 performs software verification based on the data obtained from the transceiver 110.

[0055] The processor 130 includes a flow graph generation unit 131, a flow graph update unit 133, a flow graph reconfiguration unit 135, and a change specification verification unit 137.

[0056] The flow graph generation unit 131 generates a flow graph based on the display ID, time information, and the exposure probability information for each display ID.

[0057] Here, the display ID refers to the unique identifier assigned to each screen that can be displayed during the execution of the software.

[0058] With the consent of the customer, information about the use of the software is collected through big data, which enables the estimation of user manipulation information not only based on the information about the most frequently used screens and time information, but also the estimation of user scenarios based on the display screen criteria.

[0059] Here, the flow graph generation unit 131 can classify the exposure frequency of each display ID for users to facilitate the creation of the flow graph.

[0060] For example, referring to Figure 2 , the display ID can be assigned from "A" to "L", and the exposure frequency of each display ID can be expressed as a percentage indicating the probability of being displayed on the screen.

[0061] In addition, the flow graph generation unit 131 generates a user scenario by reclassifying the previous screen information and user manipulation information for display ID exposure based on the time information (i.e., timestamp) and the display ID.

[0062] Figure 3 is a diagram showing an exemplary user scenario based on time information and display ID.

[0063] See Figure 3 , it can be observed that the user scenario may include causal relationship information about the order in which the display ID is displayed on the user screen.

[0064] The flow graph generation unit 131 generates a flow graph by including the exposure probability of each display ID in the user scenario and defining the main stream based on the probability.

[0065] Figure 4 is a diagram showing an exemplary flow graph generated by including the exposure probability of each display ID in the corresponding user scenario in Figure 3 and defining the main stream based on the probability.

[0066] See Figure 4, it can be observed that the flow graph includes not only causal relationship information about the order in which display IDs are shown on the user screen in a user scenario, but also information about the probability of transitioning from one display ID to another.

[0067] In this case, a database (DB) format is used to construct user manipulation information during each screen transition process, and the system control for these actions can include the necessary information that can be implemented through an infotainment system verification protocol or a separate analog input device.

[0068] Here, the necessary information can include database information and coordinate information.

[0069] In addition, the user manipulation information can include touch input information, hard key input information, user input information, and signal input information.

[0070] Reference Figure 1 , the flow graph update unit 133 checks the changed software specifications and updates the flow graph generated by the flow graph generation unit 131 based on the information related to these specifications.

[0071] Here, the changed software specifications can include user experience (UX) change specifications and communication database (DB) change specifications.

[0072] Here, the flow graph update unit 133 filters out the display IDs added or removed for the UX change specifications, and filters out the DB data added or removed for the communication database (DB) change specifications.

[0073] In addition, the flow graph update unit 133 generates a list of relevant display IDs by differentiating the display IDs changed according to the specification changes and the added display IDs based on the filtering information, and classifies the display IDs into added display IDs and changed display IDs.

[0074] In addition, the flow graph update unit 133 performs random tests for system stability verification based on the modified software, uses the internal data or internal state information data of the target system to check the newly added display IDs whenever the screen changes, records and extracts the display IDs in the generated display ID list in order to identify the flows that can be input using the newly added display IDs.

[0075] Here, when a newly added display ID is detected, the flow graph update unit 133 identifies the user manipulation information for inputting these IDs and reconfigures the connectivity with the existing display IDs.

[0076] Here, the flow graph update unit 133 adds the newly added display IDs from the changed software specifications to the flow graph generated by the flow graph generation unit 131, and assigns labels to the display IDs affected by the specification changes.

[0077] Figure 5 is a diagram of an exemplary flowchart after a software specification update with changes Figure 4 of the

[0078] As Figure 5 shown, new IDs (which are newly added display IDs in the changed software specification) are added to the Figure 4 flowchart, and labels are assigned to display ID F, display ID H, and the new ID affected by the specification change.

[0079] Referring again to Figure 1 , the flowchart reconfiguration unit 135 estimates the usage frequency of the newly added display IDs, reconstructs the flowchart based on the estimate, and performs random testing using the reconstructed flowchart.

[0080] For the newly added display IDs, it is difficult to estimate their usage frequency because most of these IDs are associated with newly introduced features for which existing user data is not available.

[0081] Here, the flowchart reconfiguration unit 135 can reconfigure the flowchart by incorporating the estimated screen transition probabilities into the updated flowchart from the flowchart update unit 133.

[0082] In this case, the reconfigured flowchart can be used as a prediction model based on transition probabilities regardless of the actual functions associated with the new IDs.

[0083] Here, separate labels are assigned to the display IDs affected by the specification change, and the flowchart is configured to allow the evaluator to arbitrarily assign weights.

[0084] Meanwhile, when performing random testing based on the reconfigured flowchart, the random testing can be performed based on the weights assigned by the evaluator.

[0085] In this case, the flowchart reconfiguration unit 135 calculates the display frequency of the display ID immediately preceding the newly added display ID and the screen frequency of transitioning to the display ID immediately following the newly added display ID based on the existing flowchart, and estimates the usage frequency of the newly added display ID based on the calculation results.

[0086] For example, referring to Figure 4 and Figure 6 , when "New ID" is added between the "D" screen and the "H" screen, based on the existing flowchart, it is possible to transition from the "D" screen to the "H" screen, from the "D" screen to the "I" screen, and from the "D" screen to the "J" screen, with probabilities assumed to be a%, b%, and c% respectively. In this case, the probability of transitioning from the "D" screen to the new ID can be estimated as (a + b + c) / 3%.

[0087] Here, the display ID “H” affected by the specification change is marked separately, and the evaluator can arbitrarily assign a weight of X + a% adjusted from the existing X% weight, selectively reflecting the evaluation focus. The main user action scenario can be reconstructed based on the prediction model reflected in this way.

[0088] The change specification test unit 137 performs a random test based on the flowchart reconfigured by the flowchart reconfiguration unit 135 to test the changed specification.

[0089] Here, the change specification test unit 137 can generate concentrated test result comparison data based on the changed specification and existing user data.

[0090] In addition, the change specification test unit 137 can estimate the user utilization rate of the new or modified flow based on the user prediction model.

[0091] Here, the change specification test unit 137 applies a probability algorithm at each decision point to assign weights to specific coordinate ranges or specific hard key operations for transitioning to the next display screen, combined with an evaluation algorithm to ensure concentrated testing based on high probability during the extended test. This enables concentrated testing of whether the normal transition works with the traffic coverage of the screens affected by the changed specification and whether errors related to system stability (such as crashes and Anr) occur by monitoring the logs during the process.

[0092] Through this concentrated testing, the system stability for the new or changed specification can be effectively tested, reducing the probability of errors occurring in real - world scenarios by relying on the actual changed specification and user data. This is a concentrated scenario - based testing method compared to traditional consistent and equivalent functional testing methods.

[0093] The storage unit 150 stores the information received by the transceiver 110 and the information generated by the processor 130.

[0094] Here, the storage unit 150 can be implemented using a database (DB) or a memory.

[0095] Figure 7 is a flowchart showing a software testing method according to an embodiment of the present disclosure.

[0096] The software testing method according to this embodiment can be executed by each component of the Figure 1 software testing device 100.

[0097] See Figure 7 , the software testing device 100 receives data for software testing in step S710.

[0098] Here, the transceiver 110 can receive big data related to the infotainment platform software from an external server or an external device.

[0099] In step S730, the software inspection device 100 generates a flow graph based on the data received in step S710.

[0100] In step S750, the software inspection device 100 updates the flow graph generated in step S730 based on the changed specifications of the updated software.

[0101] In step S770, the software inspection device 100 estimates the usage frequency of the newly added display IDs in the software and reconfigures the flow graph based on the estimate.

[0102] In step S790, the software inspection device 100 performs a random test on the flow graph reconfigured in step S770 to verify the changed specifications of the updated software.

[0103] Figure 8 It is a flowchart showing the details of generating the flow graph in step S730 in Figure 7 the flowchart shows the details of generating the flow graph in step S730.

[0104] According to Figure 8 the embodiment of, the step S730 of generating the flow graph can be executed by Figure 1 the flow graph generation unit 131 in

[0105] Referring to Figure 8 , in step S810, the flow graph generation unit 131 generates user exposure frequency data for each display ID.

[0106] In step S830, the flow graph generation unit 131 generates a screen operation flow based on the timestamps.

[0107] In step S850, the flow graph generation unit 131 generates a flow graph based on the user exposure frequency data generated in step S810 and the screen operation flow generated in step S830.

[0108] Figure 9 It is a flow graph showing the details of updating the flow graph in step S750 in Figure 7 the flow graph shows the details of updating the flow graph in step S750.

[0109] According to Figure 9 the embodiment of, the step S750 of updating the flow graph can be executed by the flow graph update unit 133.

[0110] Referring to Figure 9 , in step S910, the flow graph update unit 133 filters the displays added or removed based on the user experience (UX) change specifications.

[0111] In step S920, the flow graph update unit 133 filters the database (DB) data added or removed based on the communication database (DB) change specification.

[0112] In step S930, the flow graph update unit 133 generates a list of added or modified display IDs based on the specification change of the updated software.

[0113] In step S940, the flow graph update unit 133 classifies the display IDs in the generated list into added display IDs and modified display IDs.

[0114] In step S950, the flow graph update unit 133 performs random testing to detect the added display IDs.

[0115] In step S960, the flow graph update unit 133 updates the flow graph based on the connectivity between the added display IDs and the existing display IDs.

[0116] Figure 10 It is a flowchart showing the details of reconfiguring the flow graph in Figure 7 step S770.

[0117] According to Figure 10 an embodiment of Figure 1 the flow graph reconfiguration unit 135 in

[0118] Refer to Figure 10 where the flow graph reconfiguration unit 135 estimates the usage frequency of the added display IDs.

[0119] In this case, the flow graph reconfiguration unit 135 calculates the display frequency of the display ID immediately before the newly added display ID and the frequency of the screen transition to the display ID immediately after the newly added display ID based on the existing flow graph, and estimates the usage frequency of the newly added display ID based on the calculation results.

[0120] In step S1030, the flow graph reconfiguration unit 135 assigns labels to the display IDs affected by the specification change, and in step S1050 receives the weights of the display IDs with assigned labels from the user.

[0121] In step S1070, the flow graph reconfiguration unit 135 reconfigures the flow graph based on the usage frequency of the newly added display ID and the weights assigned to the display IDs affected by the specification change.

[0122] Figure 11 It is a flow graph showing the details of checking the changed software specification in Figure 7 step S790.

[0123] According to Figure 11In an embodiment, the step S790 of verifying the changed software specification may be executed by Figure 1 the changed specification verification unit 137 in

[0124] Referring to Figure 11 , in step S1110, the changed specification verification unit 137 may perform a random test on the reconfigured flow graph.

[0125] In step S1130, the changed specification verification unit 137 monitors the normal operation and operation processing log of the screen converted according to the changed specification of the software.

[0126] Meanwhile, the present disclosure can be applied to verifying updates in software associated with a vehicle infotainment system, including newly added features and changes in external signal inputs and user operation buttons, as follows.

[0127] First, according to the version of the software before the update, the data of the platform is checked on the big data server, the data is extracted according to the display frequency of each display ID, the screen transition flow between each ID is constructed based on the comparison of the data including time and operation information, and the screen transition flow is stored in a separate flow graph database. The flow graph database includes information on the screen display frequency of each ID, the operation method for transitioning between screens, and the display ID information of the next screen after the operation. In addition, a structure file with a separate label is stored in the flow graph display, allowing the evaluator to change the weight based on the probability of each display ID.

[0128] Here, separate labels are assigned to the flow graph database by checking the display ID of the newly added feature based on the changed specification and the IDs that can be changed due to communication DB and user operations.

[0129] Here, a random test is performed to verify the transition flow of the newly added feature. Through the random test, the system stability can be verified while monitoring the internal log to extract the screen transition information and operation information at the corresponding points. In this case, data update is performed by extracting the transition information linkable to the existing flow graph from the collected data. The updated flow graph database includes a flow containing the operation (input) information that can be input from the newly added display ID and the existing display ID.

[0130] In this case, since there is no existing user data for the newly added display ID, the average of the multiple branch probabilities of the IDs that can be transitioned to the new ID in the initial flow graph is calculated and assigned to the new ID. The weight label assigned to the newly added ID in this way can be manually input or automatically assigned based on the decision of the evaluator.

[0131] Based on the screen transition probabilities in the finally updated flow graph, extract the flows that the user is most likely to execute frequently, and centrally test the changed specifications by centrally reproducing the derived flows. During this process, flows that run in unexpected paths due to the impact of software changes, or parts that run with flows or probabilities significantly different from the existing flows, can be identified, enabling the confirmation and testing of errors. During this process, when the probability of a flow is lower than the probability estimated by the flow prediction model based on the existing user data, user operation scenarios can be recommended to increase the user's usage frequency.

[0132] As described in various embodiments, the present disclosure can check reasonable user scenarios on-site by using probability criteria to model action scenarios based on existing user data and centrally checking action scenarios by assigning weights, thereby improving the evaluation efficiency.

[0133] In addition, for functions newly introduced through software updates, the present disclosure reflects and tests the display identifiers (IDs) newly applied through the flow graph based on the existing page transition probabilities, thereby allowing the probability of the user entering the newly added screen to be estimated based on the probability of the display ID before adding the new screen.

[0134] In addition, when the test result is lower than the expected frequency or probability due to the impact of the usage rate and complexity of the previous page leading to the screen, the system designer can test the design estimate by rearranging the screen to a path with a higher exposure probability in the flow chart according to the degree of exposure requirement of the screen.

[0135] Meanwhile, the present disclosure described above can be implemented as computer-readable code on a medium recording a program. Computer-readable media include all types of recording devices in which data readable by a computer system is stored. Examples of computer-readable media include hard disk drives (HDDs), solid-state drives (SSDs), silicon disk drives (SDDs), ROMs, RAMs, CD-ROMs, magnetic tapes, floppy disks, optical data storage devices, etc. Therefore, the above detailed description should not be construed as restrictive in all respects, but rather exemplary. The scope of the present disclosure should be determined by a reasonable interpretation of the appended claims and include all modifications within the equivalent scope of the present disclosure.

Claims

1. A software inspection method, comprising: receiving, by the transceiver, data for software verification from an external server or an external device; generating, by the processor, a flow graph based on the received data; updating, by the processor, the flow graph based on a change specification of a software update; reconfiguring, by the processor, the updated flow graph based on an estimated frequency of use of a display identifier (ID) added to the updated change specification of the software; as well as verifying, by the processor, the change specification of the software by executing tests on the reconfigured flow graph, The display identifier is a unique identifier assigned to each screen that can be displayed during the execution of the software.

2. The software checking method according to claim 1, wherein: The flow graph is generated based on at least one of the display identifiers, time information, or exposure probability information for each display identifier.

3. The software checking method according to claim 1, wherein: The usage frequency of the added display identifier is estimated based on the display frequency of the display identifier immediately before the added display identifier and the frequency of screen transition to the display identifier immediately after the added display identifier according to the flow chart before the software is updated.

4. The software checking method according to claim 1, wherein: Generating the flow graph includes: generating user exposure frequency data for each display identifier; Generate screen operation stream based on timestamp; and The flow graph is generated based on the user exposure frequency data and the screen operation flow.

5. The software checking method according to claim 1, wherein: Updating the flow graph includes: Filtering displays that are added or removed based on user experience (UX) change specifications for the software; filtering database (DB) data added or removed based on a communication database (DB) change specification of the software; generating a list of added or modified display identifiers according to a change specification for an update of the software; Classifying the display identifiers in the generated list into added display identifiers and modified display identifiers; detecting the added display identifier by performing random testing on the software; and The flow graph is updated based on connectivity between the added display identifiers and existing display identifiers.

6. The software checking method according to claim 1, wherein: Reconfiguring the flow graph includes: estimating the usage frequency of the added display identifiers; receiving from a user weights for display identifiers affected by the change specification of the updated software; and The updated flow graph is reconfigured based on the usage frequency of the added display identifiers and the weights for the display identifiers affected by the change specification.

7. The software checking method according to claim 1, wherein: The data used for software verification includes information on the user screen of the software and user manipulation information.

8. The software checking method according to claim 1, wherein: The test is a random test.

9. The software checking method according to claim 1, wherein: The software is the infotainment platform software for the vehicle.

10. The software checking method according to claim 1, wherein: The software is associated with the vehicle's infotainment platform.

11. A software inspection device, comprising: A transceiver configured to receive data for software verification from an external server or an external device; as well as a processor configured to generate a flow graph based on the received data, update the flow graph based on an updated change specification of the software, reconfigure the updated flow graph based on an estimated usage frequency of a display identifier (ID) added to the updated change specification of the software, and verify the change specification of the software by performing a test on the reconfigured flow graph, The display identifier is a unique identifier assigned to each screen that can be displayed during the execution of the software.

12. The software checking device according to claim 11, wherein: The flow graph is generated based on at least one of the display identifiers, time information, or exposure probability information for each display identifier.

13. The software checking device according to claim 11, wherein: The usage frequency of the added display identifier is estimated based on the display frequency of the display identifier immediately before the added display identifier and the frequency of screen transition to the display identifier immediately after the added display identifier according to the flow chart before the software is updated.

14. The software checking device according to claim 11, wherein: The processor generates user exposure frequency data for each display identifier, generates a screen operation flow based on a timestamp, and generates the flow graph based on the user exposure frequency data and the screen operation flow.

15. The software checking device according to claim 11, wherein: The processor filters displays added or removed based on a user experience (UX) change specification of the software, filters database (DB) data added or removed based on a communication database (DB) change specification of the software, generates a list of added or modified display identifiers according to an updated change specification of the software, classifies the display identifiers in the generated list into added display identifiers and modified display identifiers, detects the added display identifiers by performing random testing on the software, and updates the flow graph based on connectivity between the added display identifiers and existing display identifiers.

16. The software checking device according to claim 11, wherein: The processor estimates usage frequencies of the added display identifiers, receives weights for display identifiers affected by a change specification of the updated software from a user, and reconfigures the updated flow graph based on the usage frequencies of the added display identifiers and the weights for the display identifiers affected by the change specification.

17. The software checking device according to claim 11, wherein: The data used for software verification includes information on the user screen of the software and user manipulation information.

18. The software checking device according to claim 11, wherein: The test is a random test.

19. The software checking device according to claim 11, wherein: The software is associated with the vehicle's infotainment platform.

20. A vehicle, comprising the software checking device according to claim 11.

Images