System and method for managing test case of test for testing vehicle system

Abstract

To provide a system, a method, and devices for managing one or more test cases of a test for testing a software of a vehicle system.SOLUTION: A method is implemented by at least one processor and includes: presenting, to a user, a first graphical user interface (GUI) including information of one or more test cases available to the user; receiving, from the user, a user input defining a user selection of a test case from among the one or more available test cases; and performing at least one operation for managing the user-selected test case.SELECTED DRAWING: Figure 7

Description

[Technical field]

[0001] Systems and methods consistent with example embodiments of the present disclosure relate to test case management, and more particularly, to managing one or more test cases for testing software associated with a vehicle system. [Background technology]

[0002] Software testing is necessary to ensure that the software functions as intended, meets specified requirements, and performs reliably in a variety of scenarios. Software testing is an important part of the Software Development Life Cycle (SDLC) and is performed to identify defects, errors, or bugs in the software before it is deployed into live systems.

[0003] To develop advanced or complex features in a system, testing of the functionality and performance of multiple software and / or hardware components across multiple systems or domains may be required. In the context of vehicle systems, cross-domain testing may be required during the development of advanced features in vehicle systems, such as lane change assist, mobile smart keys, and the like, and cross-domain testing may include testing interactions between various electronic control units (ECUs) and associated software and hardware components across various systems. For example, various test systems may be utilized to provide testing of various fidelity levels (e.g., virtual ECUs, emulated ECUs, simulated ECUs, etc.), to provide testing in various vehicle variants or platforms, and / or to provide testing of software developed by various developers.

[0004] To properly perform a test to test the software of a vehicle system, various test conditions defined by multiple test cases may be required. In this regard, a test case may refer to a specific set of conditions or test steps utilized during a test to verify the functionality or behavior of the software. A test case may include, among other things, a detailed description of the test steps performed during a test. Thus, when testing software having complex functionality, managing the test cases (e.g., organizing, creating, documenting, and / or tracking the status of the test cases) throughout the SDLC may be complex and difficult, especially when the tests involve cross-system or cross-domain requirements.

[0005] First, in the related art, the test cases available to a user may be limited or restricted by those built into the available test system. That is, whenever a user uses a particular test system to test software, the user may only be able to use the test cases provided by the particular test system. The user may not be able to easily configure, adjust, specify, or the like, the test cases provided by the test system according to the intended test requirements. When a test involves multiple test systems, while a test case constructed for one part of the test system is not compatible or executable in another part of the test system, the situation becomes even more complicated and difficult. Therefore, in the related art, users tend to use only the available or provided test cases and avoid modifications in the test cases as much as possible.

[0006] Furthermore, whenever the use of specific test cases is not avoidable, the user may need to expend significant effort, time, and cost to build the intended test cases. Furthermore, because different test systems may have different test case requirements and may not be compatible with each other, whenever the user wants to use specific test cases at different fidelity levels and / or for different vehicle variants, the user may need to repeat the process, which in turn may significantly increase the effort, time, and cost to build specific test cases. In particular, for users who have no experience and / or no technical background in building test cases, the process of building specific test cases may be even more burdensome and costly.

[0007] Additionally, in the related art, there is no way for one user to efficiently and easily share test cases with another user, so even if a user wants to utilize a particular test case that may have been previously constructed by another user, there is no way for the user to do so.

[0008] Furthermore, in the related art, the processes of searching for available test cases, creating new test cases, and deploying the newly constructed test cases to existing test systems are performed separately in various independent systems, making test case management inefficient and ineffective.

[0009] In view of the above, limitations and restrictions in managing test cases in related art systems may result in wasted resources (e.g., manpower, time, cost, etc.), resulting in delayed testing. Thus, software testing in the related art may be time-consuming and inefficient, slowing down software development. Summary of the Invention

[0010] According to an embodiment, a method for managing one or more test cases of tests for testing software associated with a vehicle system may be provided. The method may be implemented by at least one processor of the system and may include presenting to a user a first graphical user interface (GUI) comprising information of one or more test cases available to the user, receiving user input from the user defining a user selection of a test case from among the one or more available test cases, and performing at least one operation of managing the user-selected test case.

[0011] According to an embodiment, presenting the first GUI may include retrieving information associated with a user from at least one storage medium, determining one or more available test cases based on the retrieved user information, generating the first GUI to include information associated with the one or more available test cases, and transmitting the first GUI to a user device associated with the user. The retrieved user information may include at least one of a role of the user, a project associated with the user, a workgroup associated with the user, and a location associated with the user.

[0012] According to an embodiment, the first GUI may include one or more interactive elements, each of which is associated with an available test case from among the one or more available test cases. Further, receiving the user input may include receiving a user interaction with at least one interactive element from among the one or more interactive elements, and determining an available test case associated with the at least one interactive element with which the user interacted as the user-selected test case.

[0013] According to an embodiment, performing the at least one operation may include presenting a second GUI to a user comprising information associated with the user-selected test case, receiving user input from the user that modifies at least a portion of the information associated with the user-selected test case, and generating a new test case based on the user input, the new test case comprising at least a portion of the information that differs from the user-selected test case.

[0014] According to an embodiment, the information associated with the user-selected test case may include at least one test step associated with the user-selected test case. The second GUI may include at least one input field associated with the at least one test step. Receiving the user input may include receiving a user selection for at least one parameter defining the at least one test step. Generating the new test case may include generating the new test case based on the at least one user-defined test step.

[0015] According to an embodiment, receiving a user selection for the at least one parameter may include receiving one or more user inputs from a user in at least one input field, the one or more user inputs may include one or more keywords associated with the at least one parameter. The at least one parameter may include at least one of a software-based ECU-defined parameter, a hardware-based ECU-defined parameter, and a test environment fidelity-defined parameter.

[0016] According to an embodiment, the at least one input field may include a pre-filled parameter, and receiving a user selection for the at least one parameter may include receiving from the user an approval for the pre-filled parameter or a modification to the pre-filled parameter. Additionally or alternatively, the at least one input field may include a plurality of selectable parameters, and receiving a user selection for the at least one parameter may include receiving from the user at least one user selection for the at least one parameter from among the plurality of selectable parameters.

[0017] According to an embodiment, a system for managing one or more test cases of tests for testing software associated with a vehicle system may be provided. The system may include at least one memory storage that stores instructions and at least one processor that is configured to execute the instructions to perform at least one operation of presenting to a user a first graphical user interface (GUI) comprising information of one or more test cases available to the user, receiving user input from the user defining a user selection of a test case from among the one or more available test cases, and managing the user-selected test case.

[0018] According to an embodiment, at least one processor may be configured to execute instructions to present the first GUI by retrieving information associated with a user from at least one storage medium, determining one or more available test cases based on the retrieved user information, generating the first GUI to include information associated with the one or more available test cases, and transmitting the first GUI to a user equipment associated with the user. The retrieved user information may include at least one of a role of the user, a project associated with the user, a workgroup associated with the user, and a location associated with the user.

[0019] According to an embodiment, the first GUI may include one or more interactive elements, each of which is associated with an available test case from among the one or more available test cases, and the at least one processor may be configured to execute instructions to receive user input by receiving user interaction with at least one interactive element from the one or more interactive elements and determining an available test case associated with the at least one interactive element with which the user interacted as a user-selected test case.

[0020] According to an embodiment, the at least one processor may be configured to execute instructions to perform at least one operation by: presenting a second GUI to a user comprising information associated with the user-selected test case, receiving user input from the user modifying at least a portion of the information associated with the user-selected test case, and generating a new test case based on the user input, where the new test case may include at least a portion of the information different from the user-selected test case. The at least one parameter may include at least one of a parameter defining a software-based ECU, a parameter defining a hardware-based ECU, and a parameter defining a test environment fidelity.

[0021] According to an embodiment, the information associated with the user-selected test case may include at least one test step associated with the user-selected test case. The second GUI may include at least one input field associated with the at least one test step. The at least one processor may be configured to receive user input by executing instructions to receive a user selection for at least one parameter defining the at least one test step. The at least one processor may be configured to generate a new test case by executing instructions to generate a new test case based on the at least one user-defined test step.

[0022] According to an embodiment, at least one processor may be configured to execute instructions to receive a user selection for the at least one parameter by receiving one or more user inputs from a user in at least one input field, The one or more user inputs may include one or more keywords associated with the at least one parameter.

[0023] According to embodiments, the at least one input field may include a pre-filled parameter and the at least one processor may be configured to receive a user selection for the at least one parameter by executing instructions to receive from the user an approval for or a modification to the pre-filled parameter. Alternatively or in addition, the at least one input field may include a plurality of selectable parameters and the at least one processor may be configured to receive a user selection for the at least one parameter by executing instructions to receive from the user at least one user selection for the at least one parameter from among the plurality of selectable parameters.

[0024] Additional aspects will be set forth in part in the description that follows, and in part will be apparent from the description, or may be realized by practice of the presented embodiments of the present disclosure. [Brief description of the drawings]

[0025] The features, advantages and importance of preferred embodiments of the present disclosure will now be described with reference to the accompanying drawings, in which like reference numerals refer to like elements, and in which: [Figure 1] FIG. 1 illustrates a block diagram of an example system architecture for managing one or more test cases for testing one or more software associated with a vehicle system, according to one or more embodiments. [Diagram 2] FIG. 2 illustrates a block diagram of example components of a test case management system according to one or more embodiments. [Diagram 3] FIG. 3 illustrates an exemplary graphical user interface (GUI) presented by a test case management system according to one or more embodiments. [Figure 4] FIG. 4 illustrates another exemplary GUI presented by a test case management system according to one or more embodiments. [Diagram 5] FIG. 5 illustrates yet another exemplary GUI presented by a test case management system according to one or more embodiments. [Figure 6] FIG. 6 illustrates yet another exemplary GUI presented by a test case management system according to one or more embodiments. [Figure 7] FIG. 7 illustrates a flow diagram of an example method for managing one or more test cases for testing software associated with a vehicle system according to one or more embodiments. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0026] The following detailed description of the preferred embodiments refers to the accompanying drawings. The above disclosure provides illustration and description, but is not intended to be exhaustive or to limit the implementation to the precise form disclosed. Modifications and variations are possible in light of the above disclosure or may be acquired from practice of the implementation. Furthermore, one or more features or components of one embodiment may be incorporated in or combined with another embodiment (or one or more features of another embodiment). Furthermore, in the flowcharts and descriptions of operations provided below, it is understood that one or more operations may be omitted, one or more operations may be added, one or more operations may be performed (at least partially) simultaneously, and the order of one or more operations may be switched.

[0027] Although a particular combination of features is recited in a claim and / or disclosed herein, that combination is not intended to limit the disclosure of possible implementations. Indeed, many of the features may be combined in ways not specifically recited in the claims and / or disclosed herein. Although each dependent claim listed below may depend directly on only one claim, the disclosure of possible implementations includes each dependent claim in combination with all other claims in the claim set.

[0028] No element, act, or instruction used herein should be construed as critical or required unless expressly stated otherwise. Additionally, the articles "a" and "an" as used herein are intended to include one or more items and may be used interchangeably with "one or more." When only one item is intended, the term "a" or similar terms are used. Additionally, the terms "has," "have," "having," "include," "including," or the like as used herein are intended to be open-ended terms. Additionally, the phrase "based on" is intended to mean "based at least in part on," unless expressly stated otherwise. Additionally, phrases such as "at least one of [A] and [B]" or "at least one of [A] or [B]" should be understood as including only A, only B, or both A and B.

[0029] References throughout this specification to "one embodiment," "an embodiment," "a non-limiting preferred embodiment," or similar terms mean that a particular feature, structure, or characteristic described in connection with the illustrated embodiment is included in at least one embodiment of the solution. Thus, the phrases "in one embodiment," "in an embodiment," "a non-limiting preferred embodiment," and similar terms throughout this specification may all refer to the same embodiment, but do not necessarily do so.

[0030] Furthermore, the described features, advantages, and characteristics of the present disclosure may be combined in any suitable manner in one or more embodiments. Those skilled in the art will recognize, in light of the description herein, that the present disclosure may be practiced without one or more of the specific features or advantages of a particular embodiment. In other instances, additional features and advantages may be recognized in certain embodiments that may not be present in all embodiments of the present disclosure.

[0031] Additionally, as used herein, the term "vehicle" or the like may refer to any motorized and / or mechanical machine capable of carrying or transporting people and / or cargo, such as cars, trucks, motorcycles, buses, bicycles, mobility scooters, and the like.

[0032] As used herein, the terms "test artifact," "artifact of a test," and the like may refer to one or more components that make up a test. For example, a test artifact may include one or more software-based components (e.g., virtual ECUs, emulated ECUs, vehicle models, etc.), one or more hardware-based components (e.g., physical ECUs, vehicle hardware components, etc.), one or more test configurations (e.g., test environment configurations, test cycles, test runs, etc.), one or more test scenarios, one or more test cases, one or more test packages, and / or the like.

[0033] Exemplary embodiments consistent with the present disclosure provide methods, systems, and apparatus for managing one or more test cases of a test that tests one or more software of a vehicle system, such as one or more on-board ECUs. According to embodiments, the disclosed methods, systems, apparatus, or the like may enable one or more users to effectively and efficiently manage one or more test cases of a test that tests the software of the vehicle system.

[0034] In some implementations, methods, systems, apparatus, or the like of the present disclosure may generate and present at least one graphical user interface (GUI) to one or more users, such that the one or more users may utilize the at least one GUI to browse and search available test cases, manage test cases associated with them, share one or more test cases, and create one or more new test cases. According to embodiments, a user may utilize the at least one GUI to select an available test case and use the selected test case as a template in creating one or more new test cases.

[0035] The at least one GUI may be generated based on user information (e.g., user role, etc.) such that the at least one GUI may include information and components suitable for the user. In this manner, exemplary embodiments of the present disclosure allow users with different backgrounds to efficiently and effectively manage one or more test cases as they intend.

[0036] Finally, exemplary embodiments of the present disclosure enable one or more test cases to be synchronized in a timely and consistent manner, such that software testing may be more efficiently performed and managed, the burden on users may be significantly reduced, and the time and cost required to develop software may be significantly reduced.

[0037] It is envisioned that the features, advantages, and significance of the exemplary embodiments described herein above are merely part of the present disclosure and are not intended to be exhaustive or to limit the scope of the present disclosure. Further descriptions of the features, components, configurations, operations, and implementation aspects of the exemplary embodiments of the present disclosure, as well as associated technical advantages and significance, are provided below.

[0038] 1 illustrates a block diagram of an example system architecture 100 for managing one or more test cases for testing one or more software associated with a vehicle system, according to one or more embodiments. According to an embodiment, the software may include one or more software-based (e.g., virtualized, emulated, etc.) on-board electronic control units (ECUs). As shown in FIG. 1, system architecture 100 may include a test case management system 110, a number of user equipments (UEs) 120-1 through 120-N, a number of nodes 130-1 through 130-N, and a network 140.

[0039] Generally, test case management system 110 may be communicatively coupled to multiple UEs 120-1-120-N and multiple nodes 130-1-130-N via network 140 and may be configured to interoperate with multiple UEs 120-1-120-N and multiple nodes 130-1-130-N to manage one or more test cases for one or more associated users. A description of example components that may be included in test case management system 110 is provided below with reference to FIG. 2, and a description of associated operations and use cases is provided below with reference to FIG. 3-7.

[0040] Each of the plurality of UEs 120-1-120-N may include one or more machines, devices, or the like that can receive, generate, store, process, and / or provide information when utilized by an associated user. For example, one or more of the plurality of UEs 120-1-120-N may include a computing device (e.g., a desktop computer, a laptop computer, a tablet computer, a handheld computer, a smart speaker, a server, etc.), a mobile device (e.g., a smartphone, etc.), a wearable device (e.g., a pair of smart glasses or a smart watch), a SIM-based device, or any other suitable device that may be associated with one or more users involved in testing the software.

[0041] The multiple UEs 120-1-120-N may be utilized by one or more associated users to access and utilize the test case management system 110. For example, a user may access the test case management system 110 via an associated UE to manage one or more test cases. For example, a user may utilize the test case management system 110 via an associated UE to search for one or more available test cases, to construct one or more test cases, to view one or more associated test cases, to modify one or more test cases, to share one or more test cases, and the like. Additionally, a user may also utilize the test case management system 110 to obtain (e.g., view, download, etc.) information associated with one or more test cases (e.g., content of the test case, creator of the test case, test artifacts associated with the test case, etc.).

[0042] According to an embodiment, at least some of the plurality of UEs 120-1 to 120-N may be located in various geographic locations. For example, a first portion of the plurality of UEs 120-1 to 120-N may be utilized by a first user (e.g., a developer of a first ECU, etc.), and the first user may be located in a first location, while a second portion of the plurality of UEs 120-1 to 120-N may be utilized by a second user (e.g., a developer of a second ECU, etc.), and the second user may be located in a second location different from the first location.

[0043] On the other hand, each of the plurality of nodes 130-1 to 130-N may include one or more devices, instruments, systems, or any other suitable components that may receive, host, store, deploy, process, provide, or the like, information and data associated with a test. According to an embodiment, at least some of the plurality of nodes 130-1 to 130-N may be configured to host, deploy, store, provide, or the like, one or more test artifacts or components associated with one or more test cases.

[0044] For example, some of the nodes 130-1-130-N may include devices or equipment that may be utilized to build, store, execute, simulate, execute, or the like, one or more computer-executable software applications, such as one or more virtualized ECUs, one or more emulated ECUs, and / or any other suitable software-based components of a vehicle system (e.g., vehicle models, data communication module (DCM) models, heating, ventilation, and air conditioning (HVAC) models, etc.). As another example, some of the nodes 130-1-130-N may include or be communicatively connected to one or more hardware-based components, such as one or more fully developed physical ECUs, one or more partially developed physical ECUs, one or more vehicle hardware components (e.g., powertrain, engine, etc.), or the like. One or more of the aforementioned software-based components and hardware-based components may be associated with one or more test cases managed by the test case management system 110. For example, the one or more test cases may include information (eg, steps, conditions, etc.) that utilizes or tests one or more of the software-based and hardware-based components described above.

[0045] According to an embodiment, one or more of the plurality of nodes 130-1 through 130-N may include one or more interfaces, each of which may be configured to communicatively connect the associated node to the test case management system 110. For example, one or more of the plurality of nodes may include a hardware interface, a software interface (e.g., a programmatic interface, an application program interface (API), etc.), and / or the like.

[0046] According to an embodiment, at least a portion of the plurality of nodes 130-1 to 130-N may be located in a geographic location that is different from test case management system 110, different from one or more of the plurality of UEs 120-1 to 120-N, and / or different from another portion of the plurality of nodes 130-1 to 130-N.

[0047] According to an embodiment, at least a portion of the plurality of nodes 130-1-130-N may be associated with one or more test environments. For example, the portion of the nodes may have at least one software-based test environment (e.g., a software-in-the-loop (SIL) test environment, a virtual ECU (V-ECU) test environment, a model-in-the-loop (MIL) test environment, a processor-in-the-loop (PIL) test environment, etc.) and / or at least one hardware-based test environment (e.g., a hardware-in-the-loop (HIL) test environment) communicatively connected (e.g., wired, wireless, etc.) thereto or deployed thereon. In this regard, the portion of the plurality of nodes 130-1-130-N may receive one or more test cases (e.g., test cases constructed by a user, test cases associated with a user, etc.) from the test case management system 110 and may be configured to utilize the received test cases to automatically perform tests on desired software and / or hardware components based thereon.

[0048] Further, at least some of the plurality of nodes 130-1 to 130-N may include one or more storage media, such as a server or server cluster, that may be configured to store, publish, or the like, one or more data or information provided by test case management system 110, one or more of the plurality of UEs 120-1 to 120-N, and / or other portions of the plurality of nodes 130-1 to 130-N.

[0049] The network 140 may include one or more wired and / or wireless networks that may be configured to connect the test case management system 110, the plurality of UEs 120-1-120-N, and the plurality of nodes 130-1-130-N to one another. For example, the network 140 may include a cellular network (e.g., a fifth generation (5G) network, a long term evolution (LTE) network, a third generation (3G) network, a code division multiple access (CDMA) network, etc.), a public land mobile network (PLMN), a local area network (LAN), a wide area network (WAN), a metropolitan area network (MAN), a telephone network (e.g., a public switched telephone network (PSTN)), a private network, an ad-hoc network, an intranet, the Internet, an optical fiber-based network, or the like, and / or a combination of these or other types of networks.

[0050] According to an embodiment, network 140 may include a virtual network that may include one or more physical network components (e.g., Ethernet, WiFi modules, telecommunications network hardware, etc.) implemented with one or more virtualized network functions (e.g., a Control Area Network (CAN) bus, etc.).

[0051] Reference is now made to Figure 2, which illustrates a block diagram of example components of a test case management system 200 according to one or more embodiments. Test case management system 200 may be similar to test case management system 110 of Figure 1.

[0052] As shown in FIG. 2, test case management system 200 may include at least one communication interface 210, at least one storage 220, and at least one processor 230, although it may be understood that test case management system 200 may include more or fewer components than those shown and / or the components included therein may be arranged in any manner different than that shown without departing from the scope of the present disclosure.

[0053] The communication interface 210 may include transceiver-like components (e.g., a transceiver, separate receivers and transmitters, etc.) that enable the test case management system 200 (or one or more components included therein) to communicate with one or more components external to the test case management system 200, such as via a wired connection, a wireless connection, or a combination of wired and wireless connections. For example, the communication interface 210 may connect the test case management system 200 (or one or more components included therein) to multiple UEs (e.g., UEs 120-1 to 120-N, etc., of FIG. 1) and multiple nodes (e.g., nodes 130-1 to 130-N, etc., of FIG. 1), thereby enabling them to communicate with each other and operate interoperably. As another example, the communication interface 210 may enable components of the test case management system 200 to communicate with each other. For example, the communication interface 210 may connect the storage 220 to the processor 230, thereby enabling them to communicate with each other and operate interoperably.

[0054] According to an embodiment, the communication interface 210 may include a hardware-based interface, such as a bus interface, an Ethernet interface, an optical interface, a coaxial interface, an infrared interface, a radio frequency (RF) interface, a universal serial bus (USB) interface, a Wi-Fi interface, a cellular network interface, a software interface, or the like. According to an embodiment, the communication interface 210 may include at least one controller area network (CAN) bus, which is configurable to communicatively couple components of the test case management system 200 (e.g., storage 220, processor 230, etc.) to a plurality of UEs (e.g., UEs 120-1 to 120-N) and a plurality of nodes (e.g., nodes 130-1 to 130-N). Additionally or alternatively, the communication interface 210 may include a software-based interface, such as an application programming interface (API), a virtualized network interface (e.g., a virtualized CAN bus, etc.), or the like.

[0055] According to an embodiment, communications interface 210 may be configured to receive information from one or more components external to test case management system 200 and provide that information to processor 230 for further processing and / or to storage 220 for storage. For example, communications interface 210 may receive one or more user inputs from multiple UEs to manage one or more test cases (e.g., define and build test cases, view test cases, sequence test cases, modify test cases, share test cases, etc.) and provide the user inputs to processor 230 and / or storage 220.

[0056] Similarly, communications interface 210 may be configured to enable processor 230 of test case management system 200 to provide one or more information to one or more components external to test case management system 200. For example, communications interface 210 may enable processor 230 to provide or transmit one or more GUIs to multiple UEs or the like.

[0057] At least one storage 220 may include one or more storage media suitable for storing data, information, and / or computer-readable / computer-executable instructions therein. According to an embodiment, storage 220 may include random access memory (RAM), read-only memory (ROM), and / or another type of dynamic or static storage device (e.g., flash memory, magnetic memory, and / or optical memory) that stores information and / or instructions for use by processor 230.

[0058] Additionally or alternatively, storage 220 may include a hard disk (e.g., a magnetic disk, optical disk, magneto-optical disk, and / or solid state disk), a compact disk (CD), a digital versatile disk (DVD), a floppy disk, a cartridge, a magnetic tape, and / or another type of non-transitory computer-readable medium along with a corresponding drive.

[0059] According to an embodiment, storage 220 may be configured to store information utilized by processor 230 to perform one or more operations to manage one or more test cases for one or more users. For example, storage 220 may be configured to store one or more test cases constructed or created by one or more users, store information associated with one or more users, store information for one or more test artifacts, store information for one or more test environments, and the like.

[0060] At least one processor 230 may be configured to receive (e.g., via communications interface 210, etc.) one or more signals that define one or more instructions to perform one or more operations. Furthermore, processor 230 may be implemented in hardware, firmware, or a combination of hardware and software. Processor 230 may include a central processing unit (CPU), a graphics processing unit (GPU), an accelerated processing unit (APU), a microprocessor, a microcontroller, a digital signal processor (DSP), a field programmable gate array (FPGA), an application specific integrated circuit (ASIC), and / or another type of processing or computational component.

[0061] According to an embodiment, at least one processor 230 may include one or more processors that are programmable to perform functions or operations for managing one or more test cases. For example, processor 230 may be configured to execute computer-readable instructions stored in a memory storage (such as, for example, storage 220) to thereby perform one or more acts or operations described herein.

[0062] As an example, the at least one processor 230, upon identifying user access, may generate and present one or more graphical user interfaces (GUIs) to the user that enable the user to interact with the test case management system 200 to manage one or more test cases (e.g., view test cases, search test cases, create test cases, modify test cases, share test cases, etc.). A description of exemplary GUIs that may be generated by the processor 230 for interaction with one or more users is provided below with reference to FIGS. 3-6.

[0063] Referring first to Figure 3, Figure 3 illustrates an exemplary GUI 300 in accordance with one or more embodiments. GUI 300 may be generated by at least one processor (e.g., processor 230) of a test case management system and presented to a user by the at least one processor to enable the user to search and view information about available test cases and to create or define new test cases.

[0064] According to an embodiment, the at least one processor may generate and present GUI 300 when a user initially accesses and / or logs into the test case management system. For example, upon identifying a user's access (e.g., upon receiving an access request from a UE associated with the user, upon receiving authorization and / or authentication from a security system, upon verifying the user's identity, etc.), the at least one processor may obtain information associated with the user (which may be referred to herein as "user information") (from one or more storage media, such as storage 220 and / or an external server) and may generate GUI 300 based thereon.

[0065] The user information may include a role or function of the user (e.g., test engineer, business manager, software developer, vendor user, etc.), the user's workgroup (e.g., a team to which the user belongs, a team of users collaborating, etc.), one or more projects associated with the user (e.g., projects in which the user is involved, previously constructed test cases, etc.), locations associated with the user (e.g., the user's current location, the last known location for the user, the user's planned location, etc.), and / or the like. The user information may be included in one or more user profiles associated with the user, such that upon identifying user access, the at least one processor may retrieve the one or more user profiles (based on the user's authentication information, e.g., user ID, etc.) from the one or more storage media.

[0066] Thus, the at least one processor may generate GUI 300 based on the obtained user information. For example, the at least one processor may determine which test cases are associated with the user (based on the obtained user information), collect information of the associated test cases from among multiple nodes (e.g., nodes 130-1 through 130-N of FIG. 1 ), and include the information in GUI 300 (described further below with reference to first portion 310 of GUI 300).

[0067] As another example, the at least one processor may determine (based on the obtained user information) whether there are any pending projects (e.g., whether there are any pending test cases to be built, etc.), identify the progress of the pending projects (if any), and include that information in GUI 300 so that the user may resume work on the pending projects. Otherwise, based on a determination that there are no pending projects available to the user, the at least one processor may generate GUI 300 so that the user may quickly begin a project to build or create one or more desired test cases (described further below with reference to second portion 320 of GUI 300).

[0068] As yet another example, at least one processor may determine which test cases are available to a user (based on the obtained user information), collect information about the available test cases from among multiple nodes (e.g., nodes 130-1 to 130-N in FIG. 1), and include the information in GUI 300 (described further below with reference to third portion 330 of GUI 300).

[0069] In some implementations, at least one processor may continuously (or periodically) obtain the latest user information and update GUI 300 (if any) so that GUI 300 may always include updated information for the test cases.

[0070] With reference to FIG. 3 , the GUI 300 may include a first portion 310, a second portion 320, and a third portion 330. The first portion 310 may include a list of test cases associated with a user, and the test cases may be classified into one or more categories. For example, in the example of FIG. 3 , the first portion 310 includes a list 311 including test cases associated with a user, and the test cases are classified into various categories according to the project the test case is involved in (denoted as “Project X” in FIG. 3 ), according to the team or workgroup with which the test case is associated (denoted as “Team Y” in FIG. 3 ), and according to the function or feature with which the test case is associated (denoted as “ECU Z” in FIG. 3 ). It may be understood that the test cases associated with a user may be classified in any other suitable manner without departing from the scope of the present disclosure.

[0071] Each of the test cases presented in first portion 310 may have an interactive element associated with it that can be interacted with by a user. For example, a description of each of the test cases may be presented in the form of selectable or interactable text that, upon interaction (e.g., clicking) by the user, allows the user to select the associated test case.

[0072] 3, first portion 310 may include buttons 312 that, upon interaction by a user, enable the user to edit list 311, such as by renaming each of the categories of test cases in list 311, reorganizing test cases from one category to another, adding or removing one or more categories, and / or the like.

[0073] The second portion 320 may include an input window 321 and a number of interactive elements 322 that, upon user interaction, allow a user to define and create one or more new test cases. According to an embodiment where there are pending test cases to be built (e.g., a user has partially created a test case and saved the project for further use), the second portion 320 may include information of the pending test case, and the user may continue to work on the pending test case. Additionally, as described further below with reference to FIG. 4, in some implementations, the second portion 320 may include information of one or more test cases selected by the user (e.g., test cases selected from the first portion 310 and / or the third portion 330).

[0074] The input window 321 may be configured to receive one or more user inputs from a user to specify, define, and create one or more test cases. According to an embodiment, a user may simply enter a description of intended test steps into the input window 321 to define an intended test case. According to an embodiment, the at least one processor may receive one or more inputs from a user defining an intended test case in a first format (e.g., a generic format, etc.) and automatically convert the one or more user inputs into a second format (e.g., a specific programming language, a specific format, etc.).

[0075] According to an embodiment, as the user enters a description into the input window 321, the at least one processor may simultaneously search for test artifacts associated with the description and present one or more recommendations to the user in the input window 321. As an example, based on a determination that the user has entered the terms “ECU A” and “service” into the input window 321, the at least one processor may update the input window 321 to present information (e.g., in a drop-down list) of one or more services associated with “ECU A,” such that the first user may simply select an intended “service” associated with “ECU A” from the presented recommendations.

[0076] Alternatively or additionally, a user may create or build a new test case by utilizing one or more templates. For example, a user may select (e.g., drag and drop, double-click, etc.) one or more available test cases presented in the first portion 310 and / or the third portion 330 and / or double-click in the input window 321, and the at least one processor may generate additional interactive elements (e.g., pop-out windows, text input fields, etc.) to enable the user to upload the template to and from a directory where the desired templates are located. Thus, a user may utilize the templates to build or create an intended new test case. An exemplary GUI that enables a user to utilize test case templates is described below with reference to FIG. 6.

[0077] It may be appreciated that the input window 321 may be configured to accept one or more first user inputs that define a first portion of an intended test case via a description and to accept one or more second user inputs that define a second portion of the intended test case via the use of a template. For example, a user may define a first portion of test steps or test conditions by manually entering a description in the input window 321 and may define a second portion of the test steps or test conditions by modifying a test case template.

[0078] Further, each of the plurality of interactive elements 322 may trigger the execution of one or more associated actions or operations upon interaction by a user. For example, in the example of FIG. 3, the “Cancel” button may trigger at least one processor upon interaction by a user to terminate an ongoing operation (e.g., close the GUI 300, redirect the user to a previous page of the GUI 300, sign the user out of the test case management system, etc.). Further, the “Save” button may trigger at least one processor upon interaction by a user to create a project file (or any other suitable file or document) including the current progress, configuration, or the like, that the user provided in the input window 321, the first portion 310, and / or the third portion 330. Further, the “Create” button may trigger at least one processor upon interaction by a user to create a test case file including a description or configuration provided by the user in the input window 321 specifying one or more new test cases. According to an embodiment, upon creating the test case file, the at least one processor may store the created test case file on one or more storage media, thereby making the created test case available to selected users (functionality associated with sharing test cases is further described below with reference to FIG. 4).

[0079] The third portion 330 may include components and information associated with test cases available to the user. As shown in FIG. 3, in some implementations, the third portion 330 may include a first sub-portion 331 and a second sub-portion 332. The first sub-portion 331 may include a search field (or any other suitable interactive element) that allows a user to enter one or more criteria (e.g., keywords, etc.) that define one or more test cases of interest. In the example of FIG. 3, the user has entered keywords "ECU A" and "verification" into the first sub-portion 331, indicating that the user is interested in viewing available test cases associated with verification tests that include ECU A. Thus, the at least one processor may obtain information of test cases associated with ECU A and / or verification tests from a plurality of nodes (e.g., nodes 130-1 to 130-N, etc., of FIG. 1) communicatively coupled to the test case management system, and may update the second sub-portion 332 to present the obtained information.

[0080] In some implementations, in addition to one or more user-inputted criteria, the at least one processor may also take user information into account when searching for available test cases. For example, in the example of FIG. 3, upon obtaining information of test cases associated with ECU A and / or validation tests, the at least one processor may determine which test cases are associated with the user's role or function, which test cases are authorized for presentation to the user, which test cases are related to projects associated with the user, and the like, and may then present only the determined test cases to the user.

[0081] The second subpart 332 may include components and information associated with available test cases of interest to the user. For example, as shown in FIG. 3, the second subpart 332 includes a plurality of selectable texts associated with the criteria (e.g., “ECU A” and “Verification”) provided by the user in the first subpart 331. Each of the selectable texts in the second subpart may be associated with, for example, a respective category of test cases and may include one or more subparts upon interaction (e.g., selection, clicking, tapping, etc.) by the user. In some implementations, one or more of the plurality of subparts may further include one or more subparts. For example, in the example of FIG. 3, a plurality of test cases associated with a verification test including ECU A have been found by the at least one processor, while the selectable text associated with “Verification Test 1” has been initially selected by the user. Thus, the at least one processor may update the second subpart 332 to display selectable text associated with the available test cases associated with “Verification Test 1”.

[0082] According to an embodiment, one or more of the test cases presented in the second sub-part 332 may be available for user interaction when specifying or creating one or more new test cases. For example, when creating one or more new test cases, a user may drag and drop one or more portions of a test case presented in the second sub-part 332, such as the entire test case content, a test case step, or the like, into the input window 321 of the second part 320. In addition, a user may build or create a new test case in the second part 320 while referencing one or more available test cases presented in the third part 330. For example, upon determining one or more user interactions with selectable text in the second sub-part 332, the at least one processor may present (in an additional GUI, an additional part of the GUI 300, etc.) the content of the test case associated with the interacted selectable text, so that a user may view the content of the selected test case therefrom. It may be appreciated that one or more of the test cases presented in the first portion 310 may be capable of being interacted with by a user in a similar manner to specify or create one or more new test cases.

[0083] Additionally, the user may add one or more of the test cases presented in second sub-portion 332 to list 311 in first portion 310, so that the user may easily access the test cases in the future. For example, the user may drag and drop selectable text associated with an intended test case into first portion 310, and at least one processor may update first portion 310 to include the test case associated with the selectable text.

[0084] In view of the above, exemplary embodiments of the present disclosure provide a test case management system that generates and presents one or more GUIs that enable one or more users to easily and efficiently view, search, and create one or more test cases.

[0085]

[0036] Referring now to Figure 4, Figure 4 illustrates an exemplary GUI 400 in accordance with one or more embodiments. GUI 400 may be generated by at least one processor (e.g., processor 230) of a test case management system and presented to a user by the at least one processor to allow the user to view and configure test cases associated with the user. For example, in the example of Figure 4, GUI 400 may be generated and presented to a user after the user creates a new test case by utilizing GUI 300 of Figure 3.

[0086] The GUI 400 may include a first portion 410, a second portion 420, and a third portion 430. The first portion 410 may include a list of test cases associated with a user and one or more interactive elements associated with operations for managing the list, in a manner similar to that described above with reference to the first portion 310 of the GUI 300. Accordingly, redundant descriptions associated therewith may be omitted below for brevity.

[0087] The second portion 420 may include a browsing window 421 configured to present information of a test case selected by the user in the first portion 410, and may include a number of interactive elements 422 to enable the user to manage the selected test case. For example, in the example of FIG. 4, the user interacts with selectable text associated with “Test Case 1” in the first portion 410, and thus the at least one processor may obtain information associated with the selected test case and update the browsing window 421 to present the contents of the selected test case. According to an embodiment in which the user has selected a portion of the test case (e.g., one or more test steps), the at least one processor may update the browsing window 421 to present only the selected portion of the test case.

[0088] Further, each of the plurality of interactive elements 422 may, upon interaction by a user, trigger the performance of one or more associated actions or operations. For example, in the example of FIG. 4, the “Cancel” button, upon interaction by a user, may trigger at least one processor to terminate an ongoing operation (e.g., close GUI 400, redirect the user to a previous page of GUI 400, erase the content presented in browsing window 421, etc.). Further, the “Edit” button, upon interaction by a user, may trigger at least one processor to update third portion 430 to include information and elements that enable the user to edit the selected test case. Additionally, the “Template” button, upon interaction with a user, may trigger at least one processor to update GUI 400 to include information and elements that enable a user to define or create one or more new test cases using the selected test case as a template, or may generate an additional GUI that may include information and elements that enable a user to define or create one or more new test cases using the selected test case as a template (an exemplary GUI including the above information and elements is described below with reference to FIG. 6).

[0089] The third portion 430 may include a number of interactive elements that enable a user to modify or edit a test case selected by the user in the first portion 410 or the second portion 420. In the example of FIG. 4, the third portion 430 includes a number of interactive elements 432 associated with an operation of modifying a configuration for sharing a selected test case ("Test Case 1"). Specifically, the number of interactive elements 432 includes a number of checkboxes, each of which is associated with a user group with which the user may share the selected test case. The user may select one or more of the user groups presented in the third portion 430 by clicking or checking an associated text box, and the at least one processor may determine which of the text boxes the user interacted with, determine the user group associated therewith, and update the shared configuration of the selected test case such that the selected test case is visible and accessible by the user-selected user group.

[0090] Further, the interactive elements 432 also include buttons, each of which may trigger the execution of one or more associated actions or operations upon interaction with a user. For example, in the example of FIG. 4, the “Save” button may trigger at least one processor upon interaction with a user to collect information of a user-selected checkbox, determine a user group associated with the user-selected checkbox, and update the shared configuration of the selected test case based thereon. Further, the “Edit” button may trigger at least one processor upon interaction with a user to generate and present one or more additional GUIs, the additional GUIs including information and elements that enable a user to edit the text boxes (e.g., add a new text box and associated new user group, delete an existing text box and associated user group, rearrange the order of the existing text boxes and associated user groups, etc.) and / or edit the available user groups (e.g., rename a user group, set one or more user groups as default, etc.). Additionally, a "default" button may, upon interaction by a user, trigger at least one processor to restore the shared configuration of the selected test case to a default configuration.

[0091] In view of the above, exemplary embodiments of the present disclosure provide a test case management system that generates and presents one or more GUIs that enable one or more users to easily and efficiently view, utilize, and configure one or more associated test cases.

[0092] Although GUI 300 and GUI 400 are described and shown herein as separate GUIs, it can be understood that a user may configure the GUIs to include information and / or elements of interest in any suitable manner. For example, a user may configure GUI 300 to include a test case browser (e.g., second portion 420 of GUI 400), may configure GUI 400 to include a test case library (e.g., third portion 330 of GUI 300), or the like.

[0093] For example, referring to FIG. 5, FIG. 5 illustrates an exemplary GUI 500 according to one or more embodiments. The GUI 500 may be generated by at least one processor (e.g., processor 230) of the test case management system based on a user-defined configuration. For example, in the example of FIG. 5, the GUI 500 includes a first portion 510 that is similar to the third portion 330 of the GUI 300 and a second portion 520 that is similar to the second portion 420 of the GUI 400. Accordingly, redundant descriptions associated therewith may be omitted below for brevity.

[0094] In view of the above, exemplary embodiments of the present disclosure provide a test case management system that enables one or more users to freely customize how one or more GUIs should be presented, such that the one or more users can utilize the test case management system in a manner intended by the users, thereby easily and efficiently managing one or more test cases.

[0095] Reference is now made to FIG. 6, which illustrates an exemplary GUI 600 according to one or more embodiments. The GUI 600 may be generated by at least one processor (e.g., processor 230) of the test case management system and presented to a user by the at least one processor to enable the user to utilize available test cases (e.g., test cases previously constructed by the user or by another user, etc.) as templates in creating and defining new test cases. For example, in the example of FIG. 6, the GUI 600 may be generated and presented to the user by the at least one processor based on a determination of a user interaction with a “Templates” button in the second portion 420 of the GUI 400 or the second portion 520 of the GUI 500, and the like.

[0096] 6, GUI 600 may include an input window 610 and a number of interactive elements 620. The roles and functions of the number of interactive elements 620 may be similar to the number of interactive elements 322 in GUI 300 (described above with reference to FIG. 3), so redundant descriptions associated therewith may be omitted below for brevity.

[0097] The input window 610 may contain the contents of the selected test case as a template, while the contents may be presented in one or more editable formats so that the user may easily modify one or more intended contents according to an intended manner. For example, in the example of FIG. 6, the title of the selected test case and each of the test steps included in the selected test case are presented in multiple editable formats.

[0098] Specifically, the editable text 611 may be associated with a title of a new test case to be constructed based on the selected test case template, and the editable text 611 may trigger the at least one processor to receive one or more user inputs that define or rename the title of the new test case to be constructed upon user interaction. According to an embodiment, the at least one processor may generate the editable text 611 based on a default configuration (e.g., a configuration by a user). For example, in the example of FIG. 6, the at least one processor may generate the GUI 600 such that the first portion 610 includes a default title according to a default naming configuration that places the term "(copy)" after the original title of the selected test case.

[0099] Further, an editable text 612 may be associated with a first test step of a selected test case, and the editable text 612 may include a number of input fields (denoted as “{}” in FIG. 6 ), each of which, upon user interaction, may trigger at least one processor to receive one or more user inputs defining one or more parameters of the first test step. The one or more parameters may include parameters defining software-based components (e.g., virtual ECU names, signal frame names, etc.), parameters defining hardware-based components (e.g., physical bus names, etc.), parameters defining time periods (e.g., seconds, minutes values, etc.), parameters defining test environment fidelity (e.g., hardware resources, simulated resources, emulated resources, etc.), and / or any other suitable parameters that, when combined with the test step description, form one or more test conditions of the test case.

[0100] According to an embodiment, at least a portion of the input fields of the editable text may be pre-filled or pre-populated by the at least one processor. Specifically, the input fields of the editable text 613 may be pre-filled or pre-populated by the at least one processor based on, for example, user information of one or more users. For example, the at least one processor may determine which parameters are most common in defining the same (or similar) test steps based on the usage history of the multiple users, and then automatically fill in the input fields at the time of generating the GUI 600 accordingly. As another example, the at least one processor may determine which parameters are most used in defining and creating new test cases based on the usage history of the users, and then automatically fill in the input fields at the time of generating the GUI 600 accordingly.

[0101] According to an embodiment, the at least one processor may present one or more selectable options of a parameter in at least a portion of the plurality of editable text input fields. Specifically, the at least one processor may determine a type of parameter associated with each input field, collect information of possible parameters from among the plurality of nodes (e.g., nodes 130-1 through 130-N), and present the possible parameters for user selection in the associated input fields. For example, during generation of the GUI 600, the at least one processor may determine that a first input field of the editable text 614 is associated with a parameter defining a time period, collect information of available resources and / or available test environments of possible configurations from the plurality of nodes, determine the possible parameters that define the time period, and then include the possible parameters in the first input field in the form of a drop-down list.

[0102] It may be understood that the input fields associated with each of the test steps of a selected test case are variously described and illustrated herein for illustrative purposes only, and in fact, all of the input fields of all of the test steps may be the same (e.g., all input fields are automatically pre-filled, etc.) or similar without departing from the scope of the present disclosure.

[0103] In view of the above, exemplary embodiments of the present disclosure provide a test case management system that enables one or more users to utilize one or more available test cases, such as one or more test cases constructed and shared by other users, one or more test cases constructed by one or more users, and / or the like, such that the one or more users may use the one or more available test cases as templates to create one or more new test cases.

[0104] It may be understood that the GUIs described herein above with reference to Figures 3-6 are merely examples of possible embodiments, and the scope of the present disclosure should not be limited thereto. In particular, one or more of the above GUIs may include more or less information or components than those shown, and / or may be arranged in a different manner than those shown. For example, without departing from the scope of the present disclosure, GUI 300 may include a fourth portion for enabling a user to configure a shared configuration of one or more test cases in a manner similar to that described above with reference to third portion 430 of GUI 400, GUI 500 may include an additional portion showing a list of test cases associated with a user in a manner similar to that described above with reference to first portion 310 of GUI 300, and the like.

[0105] In view of the above, at least one processor of the test case management system may be configured to generate and present an appropriate GUI to a user, such that the user may easily and efficiently manage one or more test cases by interacting with the presented GUI.

[0106] Operations that may be performed by at least one processor (e.g., processor 230) of the test case management system will now be described with reference to FIG. 7. With reference to FIG. 7, FIG. 7 illustrates a flow diagram of an example method 700 for managing one or more test cases for testing software associated with a vehicle system, according to one or more embodiments. Upon executing computer-executable instructions stored in at least one memory storage (e.g., storage 220), one or more operations of method 700 may be performed by the at least one processor. The software to be tested may include an on-board electronic control unit (ECU), and / or any other software associated with the vehicle system.

[0107] 7, at operation S710, the at least one processor may be configured to present information associated with one or more test cases available to a user (which may be referred to herein as "one or more available test cases"). Specifically, the at least one processor may present to the user a first GUI comprising information of the one or more available test cases.

[0108] The first GUI may include one or more information or components related to one or more of GUIs 300-600 (described above with reference to FIGS. 3-6, respectively). For example, the first GUI may include first portion 310 and / or third portion 330 of GUI 300, may include first portion 410 of GUI 400, may include first portion 510 of GUI 500, and / or the like.

[0109] According to an embodiment, the at least one processor may retrieve information associated with the user (which may be referred to herein as “user information”) from one or more storage media (e.g., storage 220, a server external to the test case management system, etc.), determine one or more available test cases based on the retrieved user information, generate a first GUI to include information associated with the one or more available test cases, and transmit the first GUI to at least one user equipment (e.g., UEs 120-1 to 120-N, etc.) associated with the user, thereby presenting the first GUI to the user. The user information may include, for example, a role of the user (e.g., test engineer, software developer, etc.), a project associated with the user (e.g., a project assigned to the user, a project managed by the user, etc.), a workgroup associated with the user (e.g., the user's team with which the user is collaborating, etc.), and a location associated with the user (e.g., current location, last known location, planned location, etc.).

[0110] Thereafter, at operation S720, the at least one processor may be configured to receive user input from a user defining a user selection of a test case from among one or more available test cases (which may be referred to herein as a “user-selected test case”). For example, the first GUI may comprise one or more interactive elements (e.g., selectable text, etc.), each of which is associated with an available test case from among the one or more available test cases (see, for example, descriptions associated with the selectable text in the first portion 310 and the third portion 330 of the GUI 300). In this regard, the at least one processor may be configured to receive the user input by receiving a user interaction with at least one interactive element from among the one or more interactive elements, and determining an available test case associated with the at least one interactive element with which the user interacted as the user-selected test case.

[0111] Further, at operation S730, the at least one processor may be configured to perform one or more operations of managing the user-selected test cases. For example, the at least one processor may present a second GUI to the user comprising information associated with the user-selected test cases. The second GUI may include one or more information or components related to one or more of GUIs 300-600 (described above with reference to FIGS. 3-6, respectively). For example, the second GUI may include the third portion 330 of GUI 300, the second portion 420 of GUI 400, the second portion 520 of GUI 500, the input window 610 of GUI 600, and / or the like. Through the second GUI, the user may utilize the selected test case as a template to create a new test case.

[0112] For example, the at least one processor may receive one or more user inputs from a user that modify at least a portion of the information associated with the user-selected test case, and the at least one processor may then generate a new test case based on the user inputs, the new test case comprising at least a portion of the information that differs from the user-selected test case.

[0113] As an example, the information associated with the user-selected test case may include a title, labeling, or description associated with the user-selected test case, and the at least one processor may receive one or more user inputs via the second GUI that modify the title, labeling, and / or description of the user-selected test case (e.g., see the description associated with the editable text 611 provided above with reference to FIG. 6 ). Thus, the at least one processor may generate a new test case having the modified title, labeling, and / or description.

[0114] As another example, the information associated with the user-selected test case may include one or more test steps associated with the user-selected test case, and the second GUI comprises at least one input field associated with the one or more test steps (e.g., see the description associated with the editable text 612-614 input fields provided above with reference to FIG. 6).

[0115] In this regard, the at least one processor may be configured to receive user input via the second GUI by receiving a user selection regarding at least one parameter defining a test step, and may be configured to generate a new test case by generating a new test case based on the user-defined test step. As described above with reference to FIG. 6, the at least one parameter may include at least one of a parameter defining a software-based component (e.g., a software-based ECU, etc.), a parameter defining a hardware-based component (e.g., a hardware-based ECU, etc.), a parameter defining a time period (e.g., a value of seconds, minutes, etc.), a parameter defining a test environment fidelity (e.g., hardware resources, simulated resources, emulated resources, etc.), and / or any other suitable parameter.

[0116] In particular, the at least one processor may receive one or more user inputs in the at least one input field from a user (e.g., one or more keywords associated with the at least one parameter). Additionally or alternatively, the at least one input field may include parameters pre-filled by the at least one processor, in which case the at least one processor may receive approval for the pre-filled parameters (e.g., user interaction with an associated interactive element, etc.) or modifications to the pre-filled parameters (e.g., revisions to the pre-filled parameters, etc.) from the user. Additionally or alternatively, the at least one input field may include a plurality of selectable parameters (e.g., in the form of a drop-down list, etc.), in which case the at least one processor may receive at least one user selection for the at least one parameter from among the plurality of selectable parameters from the user.

[0117] To this end, exemplary embodiments of the present disclosure provide a test case management system (and method of utilizing same) that enables one or more users to effectively and efficiently manage one or more test cases, and thus addresses the problems in the related art as discussed above.

[0118] It is understood that the specific order or hierarchy of blocks in the processes / flowcharts disclosed herein is an example of an example approach. Based on design preferences, it is understood that the specific order or hierarchy of blocks in the processes / flowcharts may be rearranged. Further, some blocks may be combined or omitted. The accompanying method claims present elements of the various blocks in a sample order, and are not meant to be limited to the specific order or hierarchy presented.

[0119] Some embodiments may relate to systems, methods, and / or computer-readable media at any possible level of technical detail of integration. Additionally, as described herein above, one or more of the above-mentioned components described above may be implemented as instructions stored in a computer-readable medium and executable by at least one processor (and / or may include at least one processor). The computer-readable medium may include a computer-readable non-transitory storage medium (or media) having computer-readable program instructions for causing a processor to perform operations.

[0120] A computer-readable storage medium may be a tangible device that can hold and store instructions used by an instruction execution device. A computer-readable storage medium may be, for example, but not limited to, an electronic storage device, a magnetic storage device, an optical storage device, an electromagnetic storage device, a semiconductor storage device, or any suitable combination of the above. A non-exhaustive list of more specific examples of computer-readable storage media includes the following: portable computer diskettes, hard disks, random access memories (RAM), read-only memories (ROM), erasable programmable read-only memories (EPROM or flash memory), static random access memories (SRAM), portable compact disk read-only memories (CD-ROM), digital versatile disks (DVD), memory sticks, floppy disks, mechanically encoded devices such as punch cards or ridge structures in grooves with instructions recorded on them, and any suitable combination of the above. As used herein, computer-readable storage media should not be construed as being transitory signals per se, such as radio waves or other freely propagating electromagnetic waves, electromagnetic waves propagating through a waveguide or other transmission medium (e.g., light pulses passing through a fiber optic cable), or electrical signals transmitted over wires.

[0121] The computer-readable program instructions described herein may be downloaded from a computer-readable storage medium into each computing / processing device, or may be downloaded to an external computer or external storage device via a network, such as the Internet, a local area network, a wide area network, and / or a wireless network. The network may comprise copper transmission cables, optical transmission fiber, wireless transmission, routers, firewalls, switches, gateway computers, and / or edge servers. A network adapter card or network interface in each computing / processing device receives the computer-readable program instructions from the network and forwards the computer-readable program instructions for storage in a computer-readable storage medium in the respective computing / processing device.

[0122] The computer readable program code / instructions for performing the operations may be either assembler instructions, instruction set architecture (ISA) instructions, machine instructions, machine dependent instructions, microcode, firmware instructions, state setting data, configuration data for an integrated circuit, or source or object code written in any combination of one or more programming languages, including object oriented programming languages ​​such as Smalltalk, C++, or the like, and procedural programming languages ​​such as the "C" programming language or similar programming languages. The computer readable program instructions may 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 the latter scenario, the remote computer may be connected to the user's computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or a connection to an external computer may be made (e.g., through the Internet using an Internet Service Provider). In some embodiments, electronic circuitry including, for example, a programmable logic circuit, a field programmable gate array (FPGA), or a programmable logic array (PLA), may execute computer readable program instructions by utilizing state information of the computer readable program instructions to personalize the electronic circuitry to perform an aspect or operation.

[0123] The computer-readable program instructions may be provided to a processor of a general purpose computer, special purpose computer, or other programmable data processing apparatus to produce a machine, such that the instructions executed by the processor of the computer or other programmable data processing apparatus produce means for implementing the function / act specified in the block or blocks of the flowcharts and / or block diagrams. The computer-readable program instructions may also be stored in a computer-readable storage medium that may direct a computer, programmable data processing apparatus, and / or other device to function in a particular manner, such that the computer-readable storage medium having instructions stored therein comprises an article of manufacture including instructions that implement an aspect of the function / act specified in the block or blocks of the flowcharts and / or block diagrams.

[0124] The computer-readable program instructions may also be loaded onto a computer, other programmable data processing apparatus, or another device to cause the computer, other programmable apparatus, or other device to perform a series of operational steps to generate a computer-implemented process, such that the instructions executing on the computer, other programmable apparatus, or other device implement the function / act specified in the block or blocks of the flowcharts and / or block diagrams.

[0125] The flowcharts and block diagrams in the figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer-readable media according to various embodiments. In this regard, each block in the flowcharts or block diagrams may represent a module, segment, or portion of instructions comprising one or more executable instructions for implementing a specified logical function. The methods, computer systems, and computer-readable media may include additional, fewer, different, or differently arranged blocks compared to those depicted in the figures. In some alternative implementations, the functions noted in the blocks may occur out of the order noted in the figures. For example, two blocks shown in succession may in fact be executed simultaneously or substantially simultaneously, or the blocks may be executed in the reverse order depending on the functionality involved. It should also be noted that each block of the block diagrams and / or flowchart diagrams, as well as combinations of blocks in the block diagrams and / or flowchart diagrams, may be implemented by a dedicated hardware-based system that performs the specified functions or acts or executes a combination of dedicated hardware and computer instructions.

[0126] It will be apparent that the systems and / or methods described herein may be implemented in various forms of hardware, firmware, or a combination of hardware and software. The actual dedicated control hardware or software code used to implement the systems and / or methods is not a limitation of the implementation. Thus, the operation and behavior of the systems and / or methods are described herein without reference to specific software code, and it will be understood that software and hardware can be designed to implement the systems and / or methods based on the description herein.

Claims

1. 1. A method for managing one or more test cases for testing software associated with a vehicle system, the method being implemented by at least one processor, the method comprising: presenting to a user a first graphical user interface (GUI) comprising information of one or more test cases available to the user; receiving user input from the user defining a user selection of a test case from among the one or more available test cases; performing at least one operation of managing the user-selected test cases; A method comprising:

2. The presenting of the first graphical user interface includes: obtaining information associated with the user from at least one storage medium; determining the one or more available test cases based on the obtained user information; and generating the first graphical user interface to include information associated with the one or more available test cases; transmitting the first graphical user interface to a user equipment associated with the user; The method of claim 1 , comprising:

3. the first graphical user interface comprises one or more interactive elements, each of the one or more interactive elements being associated with an available test case from the one or more available test cases, and the receiving of the user input comprises: receiving a user interaction regarding at least one interactive element among the one or more interactive elements; determining the available test case associated with at least one interactive element with which the user has interacted as the user-selected test case; The method of claim 1 or 2, comprising:

4. The performing of the at least one operation includes: presenting to the user a second graphical user interface comprising information associated with the user-selected test cases; receiving user input from the user modifying at least a portion of the information associated with the user-selected test case; generating new test cases based on the user input; The method of claim 1 or 2, wherein the new test case comprises at least a portion of information that differs from the user-selected test case.

5. The method of claim 2 , wherein the obtained user information comprises at least one of a role of the user, a project associated with the user, a workgroup associated with the user, and a location associated with the user.

6. the information associated with the user-selected test case comprises at least one test step associated with the user-selected test case; the second graphical user interface comprises at least one input field associated with the at least one test step; said receiving said user input includes receiving a user selection for at least one parameter defining said at least one test step; The method of claim 4 , wherein the generating the new test case comprises generating the new test case based on at least one test step defined by the user.

7. The receiving of the user selection for the at least one parameter comprises: The method of claim 6 , comprising receiving one or more user inputs from the user in the at least one input field, the one or more user inputs comprising one or more keywords associated with the at least one parameter.

8. the at least one input field comprises pre-filled parameters; The receiving of the user selection for the at least one parameter comprises: The method of claim 6 , further comprising receiving approval for or modifications to the pre-filled parameters from the user.

9. The at least one input field comprises a plurality of selectable parameters, and the receiving of the user selection for the at least one parameter includes: The method of claim 6 , further comprising receiving at least one user selection from the user for at least one parameter from the plurality of selectable parameters.

10. 7. The method of claim 6, wherein the at least one parameter comprises at least one of a parameter defining a software-based ECU, a parameter defining a hardware-based ECU, and a parameter defining a test environment fidelity.

11. 1. A system for managing one or more test cases for testing software associated with a vehicle system, the system comprising: A memory storage for storing instructions; At least one processor; wherein the at least one processor executes the instructions to presenting a first graphical user interface (GUI) to a user comprising information of one or more test cases available to the user; receiving user input from a user defining a user selection of a test case from among the one or more available test cases; The system is configured to perform at least one operation of managing the user-selected test cases.

12. The at least one processor executes the instructions to: obtaining information associated with the user from at least one storage medium; determining the one or more available test cases based on the obtained user information; and generating the first graphical user interface to include information associated with the one or more available test cases; transmitting the first graphical user interface to a user equipment associated with the user; The system of claim 11 , configured to present the first graphical user interface by:

13. the first graphical user interface comprises one or more interactive elements, each of the one or more interactive elements being associated with an available test case from the one or more available test cases; The at least one processor executes the instructions to: receiving a user interaction regarding at least one interactive element among the one or more interactive elements; determining the available test case associated with at least one interactive element with which the user has interacted as the user-selected test case; 13. The system of claim 11 or 12, configured to receive the user input by:

14. The at least one processor executes the instructions to: presenting to the user a second graphical user interface comprising information associated with the user-selected test cases; receiving user input from the user modifying at least a portion of the information associated with the user-selected test case; generating new test cases based on the user input; 12. The system of claim 11, configured to perform the at least one action by:

15. 13. The system of claim 12, wherein the obtained user information comprises at least one of a role of the user, a project associated with the user, a workgroup associated with the user, and a location associated with the user.

16. the information associated with the user-selected test case comprises at least one test step associated with the user-selected test case; the second graphical user interface comprises at least one input field associated with the at least one test step; the at least one processor is configured to execute the instructions to receive the user input by receiving a user selection for at least one parameter defining the at least one test step; 15. The system of claim 14, wherein the at least one processor is configured to execute the instructions to generate the new test case by generating the new test case based on at least one test step defined by the user.

17. The at least one processor executes the instructions to:

17. The system of claim 16, configured to receive the user selection for the at least one parameter by receiving one or more user inputs from the user in the at least one input field, the one or more user inputs comprising one or more keywords associated with the at least one parameter.

18. The at least one input field comprises pre-filled parameters, and the at least one processor executes the instructions to:

17. The system of claim 16, further configured to receive the user selection for the at least one parameter by receiving from the user an approval for or a modification to the pre-filled parameters.

19. The at least one input field comprises a plurality of selectable parameters, and the at least one processor executes the instructions to:

17. The system of claim 16, further configured to receive at least one user selection for at least one parameter from the plurality of selectable parameters by receiving from the user the user selection for the at least one parameter.

20. 17. The system of claim 16, wherein the at least one parameter comprises at least one of a parameter defining a software-based ECU, a parameter defining a hardware-based ECU, and a parameter defining a test environment fidelity.

Images