System and method for managing test cases for testing vehicle systems

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 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 Lifecycle (SDLC) and is performed to identify defects, errors, or bugs in software before it is deployed into live systems.

[0003] Developing advanced or complex features in a system may require testing the functionality and performance of multiple software and / or hardware components across multiple systems or domains. 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 key, and the like, and cross-domain testing may include testing the 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 on various vehicle variants or platforms, and / or to provide testing of software developed by various developers.

[0004] Proper execution of a test for testing vehicle system software may require various test conditions defined by multiple test cases. In this regard, a test case may refer to a specific set of conditions or test steps utilized during testing to verify software functionality or behavior. A test case may, among other things, include a detailed description of the test steps performed during testing. Thus, when testing software with complex functionality, managing test cases (e.g., organizing, creating, documenting, and / or tracking the status of test cases) throughout the SDLC can be complex and challenging, 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 built 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 available or provided test cases and avoid modifications to test cases whenever possible.

[0006] Furthermore, whenever the use of specific test cases is unavoidable, the user may need to expend significant effort, time, and cost to build the intended test cases. Furthermore, because various test systems may have different test case requirements that may be incompatible 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, the related art does not provide a method for one user to efficiently and easily share test cases with another user, so even if a user wants to use 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.), which may result in testing delays. Therefore, software testing in related art may be time-consuming and inefficient, which may delay software development. Summary of the Invention

[0010] According to an embodiment, a method for managing one or more test cases 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 the user interaction as the user-selected test case.

[0013] According to an embodiment, performing 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 user input may include receiving a user selection for at least one parameter defining the at least one test step. Generating a new test case may include generating a 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, where 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 parameter defining a software-based ECU, a parameter defining a hardware-based ECU, and a parameter defining a test environment fidelity.

[0016] According to embodiments, 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 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 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 a 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.

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

[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 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, wherein the new test case may include at least a portion of the information that differs 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 at least one parameter by receiving one or more user inputs from a user in at least one input field, wherein 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 of 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 presented embodiments of the present disclosure. [Brief explanation of the drawings]

[0025] The features, advantages, and importance of preferred embodiments of the present disclosure will be described below with reference to the accompanying drawings, in which like reference numerals refer to like elements. [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. [Figure 2] FIG. 2 illustrates a block diagram of example components of a test case management system according to one or more embodiments. [Figure 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. [Figure 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 exemplary 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 INVENTION

[0026] The following detailed description of preferred embodiments refers to the accompanying drawings. The foregoing disclosure provides illustration and description, but is not intended to be exhaustive or to limit implementations to the precise form disclosed. Modifications and variations are possible in light of the above disclosure or may be acquired from practice of implementations. Furthermore, one or more features or components of one embodiment may be incorporated into 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) concurrently, or the order of one or more operations may be switched.

[0027] Although particular combinations of features are recited in the claims and / or disclosed herein, such combinations are 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. Also, as used herein, the articles "a" and "an" are intended to include one or more items and may be used interchangeably with "one or more." Where only one item is intended, the term "one" or similar terms are used. Also, as used herein, the terms "has," "have," "having," "include," "including," and the like are intended to be open-ended terms. Furthermore, the phrase "based on" is intended to mean "based at least in part on," unless expressly stated otherwise. Furthermore, phrases such as "at least one of [A] and [B]" or "at least one of [A] or [B]" should be understood to include A only, B only, 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, but do not necessarily, all refer to the same embodiment.

[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 enable users with different backgrounds to efficiently and effectively manage one or more test cases as intended.

[0036] Ultimately, exemplary embodiments of the present disclosure enable one or more test cases to be synchronized in a timely and consistent manner. Thus, software testing can be more efficiently performed and managed, the burden on users can be significantly reduced, and the time and cost required to develop software can 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. A further description of the features, components, configuration, operation, and implementation aspects of the exemplary embodiments of the present disclosure, as well as associated technical advantages and significance, is provided below.

[0038] 1 illustrates a block diagram of an exemplary 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 plurality of user equipments (UEs) 120-1 through 120-N, a plurality 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 descriptions of associated operations and use cases are provided below with reference to FIGS. 3-7.

[0040] Each of the plurality of UEs 120-1 through 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 through 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 can be associated with one or more users involved in software testing.

[0041] Multiple UEs 120-1 through 120-N may be utilized by one or more associated users to access and utilize test case management system 110. For example, a user may access test case management system 110 via an associated UE to manage one or more test cases. For example, a user may utilize 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 test case management system 110 to obtain (e.g., view, download, etc.) information associated with one or more test cases (e.g., test case content, test case creator, test artifacts associated with a 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 used by a first user (e.g., a developer of a first ECU, etc.), and the first user may be located at a first location, while a second portion of the plurality of UEs 120-1 to 120-N may be used by a second user (e.g., a developer of a second ECU, etc.), and the second user may be located at a second location different from the first location.

[0043] Alternatively, each of the plurality of nodes 130-1 through 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 through 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 plurality of nodes 130-1 through 130-N may include devices or equipment that may be utilized to build, store, execute, simulate, run, 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., a vehicle model, a data communication module (DCM) model, a heating, ventilation, and air conditioning (HVAC) model, etc.). As another example, some of the plurality of nodes 130-1 through 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., a powertrain, an 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 utilize or test one or more of the aforementioned software-based components and hardware-based components.

[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 some 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 through 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 coupled (e.g., wired, wireless, etc.) thereto or deployed thereon. In this regard, some of the plurality of nodes 130-1 through 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] Additionally, 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 another portion of the plurality of nodes 130-1 to 130-N.

[0049] Network 140 may include one or more wired and / or wireless networks configured to connect test case management system 110, multiple UEs 120-1 through 120-N, and multiple nodes 130-1 through 130-N to one another. For example, 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, which may include one or more physical network components (e.g., Ethernet, WiFi modules, telecommunications network hardware, etc.) on which one or more virtualized network functions (e.g., a Control Area Network (CAN) bus, etc.) are implemented.

[0051] 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 FIG.

[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 from that shown without departing from the scope of the present disclosure.

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

[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 multiple UEs (e.g., UEs 120-1 through 120-N) and multiple nodes (e.g., nodes 130-1 through 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, communication interface 210 may be configured to enable processor 230 of test case management system 200 to provide one or more pieces of information to one or more components external to test case management system 200. For example, communication 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, an optical disk, a magneto-optical disk, and / or a 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 one or more signals (e.g., via communications interface 210, etc.) 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 memory storage (e.g., storage 220, etc.) to thereby perform one or more acts or operations described herein.

[0062] As an example, upon identifying user access, at least one processor 230 may generate and present one or more graphical user interfaces (GUIs) to the user that enable the user to interact with 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 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 according to 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 for and view information about available test cases and to create or define new test cases.

[0064] According to an embodiment, 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 the 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.), 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 the user's role or function (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 with whom the user collaborates, 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 the user's 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 about the associated test cases from among multiple nodes (e.g., nodes 130-1 through 130-N in 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 any pending projects exist (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 no pending projects are available to the user, the at least one processor may generate GUI 300 so that the user may quickly start 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 the 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] 3 , GUI 300 may include a first portion 310, a second portion 320, and a third portion 330. First portion 310 may include a list of test cases associated with a user, and the test cases may be categorized into one or more categories. For example, in the example of FIG. 3 , first portion 310 includes list 311 containing test cases associated with a user, and the test cases are categorized into various categories according to the project to which the test case is involved (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 categorized 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, the 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] First portion 310 may also include one or more interactive elements to enable a user to manage list 311. For example, in the example of FIG. 3, first portion 310 may include buttons 312 that, upon user interaction, enable the user to edit list 311, such as 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] Second portion 320 may include an input window 321 and multiple interactive elements 322 that, upon user interaction, enable a user to define and create one or more new test cases. In embodiments where there are pending test cases to be constructed (e.g., a user has partially created a test case and saved the project for further use), second portion 320 may include information about the pending test case, and the user may continue working on the pending test case. Additionally, as described further below with reference to FIG. 4, in some implementations, second portion 320 may include information about one or more test cases selected by the user (e.g., test cases selected from first portion 310 and / or third portion 330).

[0074] 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 input window 321 to define the intended test case. According to an embodiment, at least one processor may receive one or more inputs from a user defining the 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 a user enters a description into input window 321, at least one processor may simultaneously search for test artifacts associated with the description and present one or more recommendations to the user in input window 321. As an example, based on determining that a user has entered the terms “ECU A” and “service” into input window 321, at least one processor may update input window 321 to present information (e.g., in a drop-down list) of one or more services associated with “ECU A,” so 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 construct 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 first portion 310 and / or third portion 330 and / or double-click in input window 321, and at least one processor may generate additional interactive elements (e.g., pop-out windows, text entry 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 a template to construct 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 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 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 input window 321 and may define a second portion of test steps or test conditions by modifying a test case template.

[0078] Furthermore, each of the plurality of interactive elements 322 may, upon user interaction, trigger the execution of one or more associated actions or operations. For example, in the example of FIG. 3 , the “Cancel” button, upon user interaction, may trigger at least one processor to terminate an ongoing operation (e.g., close GUI 300, redirect the user to a previous page of GUI 300, sign the user out of the test case management system, etc.). Furthermore, the “Save” button, upon user interaction, may trigger at least one processor to create a project file (or any other suitable file or document) containing the current progress, configuration, or the like, that the user provided in input window 321, first portion 310, and / or third portion 330. Furthermore, the “Create” button, upon user interaction, may trigger at least one processor to create a test case file containing the description or configuration provided by the user in 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 section 330 may include components and information associated with test cases available to the user. As shown in FIG. 3 , in some implementations, the third section 330 may include a first subsection 331 and a second subsection 332. The first subsection 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) defining one or more test cases of interest. In the example of FIG. 3 , the user has entered the keywords “ECU A” and “verification” into the first subsection 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 retrieve information about test cases associated with ECU A and / or verification tests from multiple nodes (e.g., nodes 130-1 through 130-N in FIG. 1 ) communicatively coupled to the test case management system and update the second subsection 332 to present the retrieved information.

[0080] In some implementations, in addition to one or more user-input 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 about 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 subsection 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 subsection 332 includes multiple selectable texts associated with criteria (e.g., “ECU A” and “Verification”) provided by the user in the first subsection 331. Each selectable text in the second subsection may be associated with a respective category of test cases, for example, and may include one or more subsections upon user interaction (e.g., selection, clicking, tapping, etc.). In some implementations, one or more of the multiple subsections may further include one or more subsections. For example, in the example of FIG. 3 , multiple test cases associated with verification tests including ECU A have been found by the at least one processor, while the selectable text associated with “Verification Test 1” was initially selected by the user. Thus, the at least one processor may update the second subsection 332 to display selectable text associated with available test cases associated with “Verification Test 1.”

[0082] According to an embodiment, one or more of the test cases presented in second subsection 332 may be interactable with by a user 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 second subsection 332, such as the entire test case content, test case steps, or the like, into input window 321 of second section 320. Additionally, a user may construct or create a new test case in second section 320 while referencing one or more available test cases presented in third section 330. For example, upon determining one or more user interactions with selectable text in second subsection 332, at least one processor may present (e.g., in an additional GUI, an additional section of GUI 300) the content of the test case associated with the interacted selectable text, so that a user can view the content of the selected test case therefrom. It may be appreciated that one or more of the test cases presented in 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] Referring now to FIG. 4, FIG. 4 illustrates an exemplary GUI 400 according to 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 enable the user to view and configure test cases associated with the user. For example, in the example of FIG. 4, GUI 400 may be generated and presented to a user after the user creates a new test case by utilizing GUI 300 of FIG. 3.

[0086] GUI 400 may include a first portion 410, a second portion 420, and a third portion 430. 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 first portion 310 of GUI 300. Accordingly, redundant description associated therewith may be omitted below for the sake of brevity.

[0087] Second portion 420 may include a browsing window 421 configured to present information about a test case selected by a user in first portion 410 and may include a plurality of interactive elements 422 to enable a 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 first portion 410; therefore, at least one processor may obtain information associated with the selected test case and update 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 a test case (e.g., one or more test steps), at least one processor may update 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 user interaction, trigger the performance of one or more associated actions or operations. For example, in the example of Figure 4, the "Cancel" button, upon user interaction, may trigger at least one processor to terminate an ongoing operation (e.g., close GUI 400, redirect the user to a previous page in GUI 400, erase the content presented in browsing window 421, etc.). Further, the "Edit" button, upon user interaction, 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 user interaction, may trigger at least one processor to update GUI 400 to include information and elements that enable the 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 the 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] Third portion 430 may include multiple interactive elements that enable a user to modify or edit a test case selected by the user in first portion 410 or second portion 420. In the example of FIG. 4 , third portion 430 includes multiple interactive elements 432 associated with modifying the sharing configuration of the selected test case (“Test Case 1”). Specifically, multiple interactive elements 432 include multiple checkboxes, each 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 third portion 430 by clicking or checking an associated text box, and at least one processor may determine which of the multiple text boxes the user interacted with, determine the associated user group, and update the sharing configuration of the selected test case so that the selected test case is visible to and accessible by the user-selected user group.

[0090] Furthermore, the plurality of interactive elements 432 may also include a plurality of buttons, each of which, upon user interaction, may trigger the execution of one or more associated actions or operations. For example, in the example of FIG. 4 , the “Save” button, upon user interaction, may trigger at least one processor to collect information about the user-selected checkboxes, determine the user groups associated with the user-selected checkboxes, and update the shared configuration of the selected test case based thereon. Furthermore, the “Edit” button, upon user interaction, may trigger at least one processor to generate and present one or more additional GUIs, which include information and elements that enable the user to edit the plurality of text boxes (e.g., add new text boxes and associated user groups, delete existing text boxes and associated user groups, rearrange the order of existing text boxes and associated user groups, etc.) and / or edit the available user groups (e.g., rename user groups, set one or more user groups as default, etc.). Additionally, a "default" button may, upon user interaction, trigger at least one processor to restore the shared configuration of the selected test case to the 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 will be appreciated 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. 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, GUI 500 includes a first portion 510 that is similar to third portion 330 of GUI 300 and a second portion 520 that is similar to second portion 420 of GUI 400. Accordingly, redundant descriptions associated therewith may be omitted below for the sake of brevity.

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

[0095] 6, which illustrates an exemplary GUI 600 according to one or more embodiments. GUI 600 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 utilize available test cases (e.g., test cases previously constructed by the user or by another user, etc.) as templates when creating and defining new test cases. For example, in the example of FIG. 6, GUI 600 may be generated and presented to a user by the at least one processor based on a determination of a user interaction with a “Templates” button in second portion 420 of GUI 400 or second portion 520 of GUI 500, and the like.

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

[0097] The input window 610 may contain the content of the test case selected as a template, and the content may be presented in one or more editable formats so that the user can easily modify one or more intended content 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, 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 upon user interaction, the editable text 611 may trigger at least one processor to receive one or more user inputs defining or renaming the title of the new test case to be constructed. According to an embodiment, the at least one processor may generate the editable text 611 based on a default configuration (e.g., a user configuration). For example, in the example of FIG. 6, the at least one processor may generate GUI 600 such that 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] Additionally, editable text 612 may be associated with a first test step of a selected test case, and the editable text 612 may include multiple input fields (denoted in FIG. 6 as “{}”), 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 a parameter defining a software-based component (e.g., a virtual ECU name, a signal frame name, etc.), a parameter defining a hardware-based component (e.g., a physical bus name, etc.), a parameter defining a time period (e.g., a value in 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 that, when combined with the test step description, forms 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 at least one processor. Specifically, the input fields of the editable text 613 may be pre-filled or pre-populated by at least one processor, for example, based on user information of one or more users. For example, the at least one processor may determine, based on usage history of multiple users, which parameters are most common when defining the same (or similar) test steps, and then automatically fill in the input fields accordingly when generating the GUI 600. As another example, the at least one processor may determine, based on usage history of users, which parameters are most used when defining and creating new test cases, and then automatically fill in the input fields accordingly when generating the GUI 600.

[0101] According to an embodiment, at least one processor may present one or more selectable options for a parameter in at least some 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 on the 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 GUI 600, the at least one processor may determine that a first input field of editable text 614 is associated with a parameter defining a time period, collect information on available resources and / or available test environments of possible configurations from the plurality of nodes, determine the possible parameters defining the time period, and then include the possible parameters in the first input field in the form of a drop-down list.

[0102] It will 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 for 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, so 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 can 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 GUIs described above may include more or fewer 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, so that the user can 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 a test case management system will now be described with reference to FIG. 7. Referring 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. Executing computer-executable instructions stored in at least one memory storage (e.g., storage 220) may perform one or more operations of method 700 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 the 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 a 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 through 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 the one or more available test cases (which may be referred to herein as a “user-selected test case”). For example, the first GUI may include 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, e.g., 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 user interaction with at least one interactive element from among the one or more interactive elements, and determining the 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 for managing the user-selected test case. For example, the at least one processor may present a second GUI to the user comprising information associated with the user-selected test case. 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 third portion 330 of GUI 300, second portion 420 of GUI 400, second portion 520 of GUI 500, 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 editable text 611 provided above with reference to FIG. 6 ). Accordingly, 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 the new test case by generating the 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] Specifically, the at least one processor may receive one or more user inputs (e.g., one or more keywords associated with the at least one parameter) from a user in the at least one input field. Additionally or alternatively, the at least one input field may include parameters pre-filled by the at least one processor. In that case, the at least one processor may receive from the user an approval of the pre-filled parameters (e.g., user interaction with an associated interactive element) or a modification to the pre-filled parameters (e.g., revision of the pre-filled parameters). Additionally or alternatively, the at least one input field may include multiple selectable parameters (e.g., in the form of a drop-down list). In that case, the at least one processor may receive from the user at least one user selection of at least one parameter from among the multiple selectable parameters.

[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 that addresses the problems of 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. Furthermore, 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, one or more of the above components described above may be implemented as instructions stored on 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 for use by an instruction execution device. A computer-readable storage medium may be, for example, but is 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 thereof. A non-exhaustive list of more specific examples of computer-readable storage media includes the following: portable computer diskettes, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), static random access memory (SRAM), portable compact disk read-only memory (CD-ROM), digital versatile disk (DVD), memory sticks, floppy disks, mechanically encoded devices such as punch cards or ridge-in-groove structures with instructions recorded thereon, and any suitable combination thereof. 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 to each computing / processing device from a computer-readable storage medium, 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 include copper transmission cables, optical fiber transmissions, wireless transmissions, 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 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 integrated circuits, 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 the connection to the 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 aspects or operations.

[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 create a machine, such that the instructions, executed by the processor of the computer or other programmable data processing apparatus, create means for implementing the function(s) / act(s) specified in the block(s) of the flowcharts and / or block diagrams. The computer-readable program instructions may also be stored on a computer-readable storage medium that can 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 aspects of the function(s) / act(s) specified in the block(s) 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 create a computer-implemented process, such that the instructions executing on the computer, other programmable apparatus, or other device implement the function(s) / act(s) specified in the flowchart and / or block diagram block or blocks.

[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 a flowchart or block diagram may represent a module, segment, or portion of instructions comprising one or more executable instructions that implement a specified logical function. The methods, computer systems, and computer-readable media may include additional, fewer, different, or differently arranged blocks than 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 concurrently or substantially concurrently, or the blocks may even 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, and combinations of blocks in the block diagrams and / or flowchart diagrams, may be implemented by dedicated hardware-based systems that perform the specified functions or acts or execute 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 combinations 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 and 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 to manage the user-selected test cases, the performing of the at least one operation including generating a first new test case based on the user input; presenting one or more selectable options to a user in at least a portion of a plurality of input fields in the first new test case based on the test environment information; A method comprising:

2. The presentation of the first graphical user interface includes: retrieving 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; 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 device 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 from 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; 3. The method of claim 1 or 2, comprising:

4. said performing said at least one operation presenting to the user a second graphical user interface 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; generating a second new test case based on the user input; and 3. The method of claim 1, wherein the second new test case comprises at least some of the information that is different 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 second new test case includes generating the second 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:

7. 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 of 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 , 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 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, the performing of the at least one operation including generating a first new test case based on the user input; In the first new test case, the system is configured to present a user with one or more selectable options for at least a portion of a plurality of input fields based on environmental information of the test.

12. The at least one processor executes the instructions to: retrieving 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; 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 device 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 from 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 case; receiving user input from the user modifying at least a portion of the information associated with the user-selected test case; generating a second new test case based on the user input; and 13. The system of claim 11 or 12, wherein the second new test case comprises at least some of the information that is different from the user-selected test case.

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 second new test case by generating the second 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 approval for or modification to the pre-filled parameter from the user.

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, configured to receive at least one user selection for at least one parameter from the plurality of selectable parameters by receiving 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