Human-computer interface (HCI) test driver
A method and a system for driving a computer interface for a user is provided. The system includes an interface client having a computer platform, a test driver having software on the computer platform; a window displayed to the interface client, the window providing an interface between the computer platform and the user; and a command file that provides an instruction to the computer interface for executing by the driver software, such that the instruction mimics a user input. The method includes providing instructions through a command file having an instruction for execution on the computer interface, providing driver software to the computer interface, and executing the instruction on the computer interface using the driver software, such that the instruction mimics a user input.
Latest The United States of America as represented by the Secretary of the Navy Patents:
Pursuant to 35 U.S.C. §119, the benefit of priority from Provisional Application No. 60/835,966, with a filing date of Jul. 24, 2006, is claimed for this non-provisional application.
STATEMENT OF GOVERNMENT INTERESTThe invention described was made in the performance of official duties by one or more employees of the Department of the Navy, and thus, the invention herein may be manufactured, used or licensed by or for the Government of the United States of America for governmental purposes without the payment of any royalties thereon or therefor.
BACKGROUNDThe invention relates generally to software integration verification. In particular, the invention relates to using a command file and optionally user interaction to represent the inputs from an operator and/or external subsystems. The effects of the inputs on the HCI software are validated against expected responses.
Modern operational control, such as for a ship-board combat platform, typically requires an integrated computer system to receive data, select appropriate options and transmit instructions to and from components for instrumentation and execution. Construction of such a system can require integration of many separate processes, each receiving and transmitting data in coöperation with other related processes.
In addition to creation and assembly of hardware electronic components for receiving information and transmitting commands, software code must be prepared and compiled to interpret and execute instructions that perform the system operations. Prior to complete integration, verification of separate components is performed by a testing operator in combination with simulation software processes. The development alone of the simulation software itself is immense and may become necessary at an early stage in the development cycle. The time and effort required of the testing operator to completely verify the software component is extensive to cover the plethora of different input combinations. This represents a time-consuming and error-prone process.
Such component operation testing typically involves executing the component's instruction software and simulating its external subsystems from which to receive anticipated input and submit appropriate output. Such code must be sufficiently robust to not only properly execute the intended functions on command, but also recover gracefully from inappropriate inputs and other faulty conditions without undue and potentially catastrophic interruption. The simulation procedure involves preparing a test driver to be executed under sets of conditions and selections.
The production software, as well as the simulation software, requires a graphical user interface (GUI). The program renders its GUI to respond to user interaction (e.g., weapon selection) while concurrently operating another device (e.g., tracking a target). Execution of a software application involves kernel scheduling, such as by an operating system process or by a thread of execution. A process is used to instantiate (i.e., run an instance of) a program.
Processors typically operate independently and carry extensive state information regarding operation status (e.g., running, blocked, ready). By contrast, threads share the state information of a single process, memory, address space and other resources with each other. A process switches between threads, whereas multiple threads switch by time slicing. Multi-threading between threads is generally faster than context switching between processes, providing a speed advantage on a cluster of machines. Implementing threads may require careful scheduling to rendezvous properly for processing data in the correct order.
Conventional methods of testing software components require a separate test driver for each component. Each test driver is unique to the software component under test and is neither reusable nor applicable to other components to be tested. Each software developer has a different method or style of testing software and thus the test drivers are usually not transferable to other developers or even other software components. Regression testing or comparing actual results with expected results must be conducted manually by observing the actual results, or the test driver has to be modified to perform the comparison.
For a test of software, an operator may interact with a GUI-equipped client platform referred to as a Human Computer Interface (HCI) as one component in a control system. One or more data servers may communicate with the HCI to simulate an associated device in the control system. The data servers may interact with one or more server threads in the HCI. The operator may interact through an interface thread that displays a GUI window for each instantiated executable program. The server and interface threads may exchange information between each other, with each window responding to condition changes caused by the exchanges.
SUMMARYConventional software testing yields disadvantages addressed by various exemplary embodiments of the present invention. In particular, capabilities are needed to comprehensively test all option selections. Other various embodiments alternatively or additionally provide for obviating the necessity for providing simulators prior to software development and testing.
Various exemplary embodiments provide a method and a system for driving a computer interface for a user. The system includes a computer platform, a test driver having software on the computer platform, a window providing an interface between the computer platform and the user, and a command file that provides instructions to the computer interface for execution by the driver software, as well as verification of the production software. The instructions mimic user and external subsystem input. The method includes providing instructions and verification via a command file, providing driver software to the computer interface, and executing the instruction on the computer interface using the driver software. The instructions mimic user and external subsystem input.
In various exemplary embodiments, the system includes a remote server in which the method provides for exchanging information with the client and executing a server command from the server in response to the information. In alternate embodiments, a window is provided to display the instruction, and thereby enable the instruction to be edited and re-executed.
In other exemplary embodiments, the instruction in the command file verifies attributes of the information by one of confirming conformity and identifying discrepancy. Additional embodiments enable the user input to be selected from a list of menu options. The instructions may be incorporated using human-readable symbology, such as alpha-numeric characters. In addition, the driver software may incorporate a software library. The computer interface represents a Human Computer Interface (HCI). Preferably, an HCI Test Driver associated with the client platform represents a simulator for testing and verifying combat operations capabilities.
These and various other features and aspects of various exemplary embodiments will be readily understood with reference to the following detailed description taken in conjunction with the accompanying drawings, in which like or similar numbers are used throughout, and in which:
In the following detailed description of exemplary embodiments of the invention, reference is made to the accompanying drawings that form a part hereof, and in which is shown by way of illustration specific exemplary embodiments in which the invention may be practiced. These embodiments are described in sufficient detail to enable those skilled in the art to practice the invention. Other embodiments may be utilized, and logical, mechanical, and other changes may be made without departing from the spirit or scope of the present invention. The following detailed description is, therefore, not to be taken in a limiting sense, and the scope of the present invention is defined only by the appended claims.
The Advanced Tomahawk Weapons Control System (ATWCS) represents an example combat weapons platform. ATWCS GUI software was based on the Motif widget set using the Ada programming language. ATWCS software was designed using an Object Oriented paradigm. A window within the software was considered an object. Unit testing each routine within the window package lacks the same effectiveness as testing the window package as a whole object. The HCI Test Driver concept was conceived based on the need to thoroughly test the window as an object.
The next software version for Tactical Tomahawk Weapons Control System (TTWCS) used C++ as the language for GUI development. HCI Test Driver, as provided in exemplary embodiments, enabled conversion from Ada to C++ with that capability subsequently extended to run on multiple platforms (HP-UX, Linux).
Original methods of testing these GUI windows required separate test drivers for each window. Each test driver was unique to the window under test and was neither reusable nor applicable to other windows to be tested. Each software developer had a different method or style of testing software and thus the test drivers were usually not transferable to other developers or even other software components. Regression testing, or comparing actual results with expected results, had to be done manually by observing the actual results, or the test driver had to be modified to perform the comparison. Continuing to write individual test drivers for each window in subsequent projects would have been costly, time consuming and tedious.
An example commercial tool for software testing and development is X-window GUI testing product, XRunner from Mercury™ Interactive Corporation. See http://www.mercury.com/us/products/application-delivery/xrunner/. This tool enables user interaction, such as button clicks and data entry to be recorded. However, the software development industry requires more extensive capabilities, as provided by various exemplary embodiments described herein.
The design of the HCI Test Driver (coupled with the HCI design for ATWCS/TTWCS) has been widely used within the Tomahawk cruise missile program. This has enhanced the productivity of Navy GUI developers and significantly improved the quality of the GUI software. The flexibility and extensibility of the design enables conversion to a different Widget set of wxWidgets. This will facilitate development on more platforms than conventionally available (HP-UX, Linux, Microsoft) with the same productivity and high quality.
General Architecture: By contrast with the conventional arrangement,
The operator 110 reviews the GUI information content in an HCI window 260 associated with the internal thread 250. Instructions in the command file 210 may be written in American Standard Code for Information Interchange (ASCII). The HCI windows 260 may be composed of widgets, such as push buttons, toggle buttons, pull-down menus, labels and images.
A data server 270 can either be the actual production data server or else a simulator independent of the command file 210. The server 270 communicates via the server thread 240 to provide condition data to which the internal thread 250 reacts. Communication between the operator 110 and the server 270 with the HCI client 220 is shown by interaction connectors 280.
The operator 110 can communicate with the HCI Window 260 by a first link 340 to issue a command receive an updated view of that window by the GUI imagery. The HCI Test Driver 230 can communicate by a second link 350 with the HCI Window 260 and by a third link 360 with the HCI Application 330 to send instruction messages and receive return messages.
The HCI Window 260 can communicate by a fourth link 370 with the HCI Application 330 to provide the GUI-update. For example, the HCI Window 260 may submit a user request to the HCI Application 330. This procedure can then update the window by changing the characteristic by an update view command.
For example, the command file 210 may direct the HCI Test Driver 230 to send a GUI-update message to the HCI Application 330 to update the characteristic of a button described later. The HCI Test Driver 230 issues a request for window attributes and/or attributes of user inputs. Upon receipt of the attributes, the HCI Test Driver 230 compares these against expected parameters for confirmation that the attributes changed appropriately.
Every HCI window 260 can be tested extensively with the HCI Test Driver 230 before being integrated with the tactical interfaces and software systems. In this manner, every aspect of the window 260 can be exercised to discover (and subsequently repair) all the software bugs and to make sure the software behaves correctly. The HCI Test Driver 230 can simulate multiple application servers and their interfaces to the HCI client 220. The HCI Test Driver 230 may send and receive the same messages that application servers send and receive. The HCI Test Driver 230 can also simulate keypunch input from the operator 110 such as pressing buttons and moving a mouse or other cursor manipulator. The HCI Test Driver 230 may also check the HCI Window 260 to determine if attributes have changed as expected.
Example Windows: An exemplary window and associated commands is described and explained in the following paragraphs. This simple window is named Test Window (see 600 in
The particular X/Motif code and header files written to generate the Test Window 600 are respectively in TestMW.cc and TestMW.hh and written in C++. In this example, the header file in a Header Window 400 is located in TestWindowCb.hh, shown in FIG. 4. The application code is located in Code Window 500 is located in TestWindowCb.cc, with upper and lower portions 510, 520 shown respectively in
The Header Window 400 contains procedures in lines of instructions 410 to chose 420, create 430, open 440 and close 450 the Test Window 600. In addition, the header file 400 handles the clicking of the “Hello!!” Push Button by a call-back procedure 460. The HCI client 220 represents the GUI software that the operator 110 for the computer platform 310 views on the monitor screen and through which applications can be interacted with or sequenced by the HCI Test Driver 230.
The code file 500 handles the display and processing of the Test Window 600. The code file 500 includes procedures to create 530 (FIG. 5A), open 540 (FIG. 5B), and close 550 (
Exemplary embodiments of the Test Window 600, as described in further detail, are shown in
Testing the Window without the HCI Test Driver: In a first operational embodiment, the operator 110 exercises the Test Window 600 without the HCI Test Driver 230. A makefile may be written to compile and bind the Test Window's files to produce an executable file, in this case named testMain. A short script named run_driver in a command line 710 may be created to run the testMain executable 700 labeled 1xdev03, as shown in FIG. 7. The executable 700 incorporates a command line to receive and process an instruction from the operator 110. The software for an HCI Application 330 represents the code behind the HCI window 260 that handles the operator's actions. The operator 110 may make a selection by pressing (or clicking) the Push Button 610.
Typing run_driver in the command line 710 causes the Test Window 600 to open in FIG. 6A. Then in response to the operator 110 clicking on the Push Button 610 labeled “Hello!!” 620 in
Notice that there is an extra exclamation point shown in the dashed oval 650. This is due to a bug (i.e., coding flaw) in the helloCallback code 540. Examination of the code in the TestWindowCb.cc file 500 may reveal the bug. On the other hand, the operator 110 that visually verifies the correct working of the Test Window 600 may easily overlook this subtle defect. In contrast, the operator 110 testing this Test Window 600 with the HCI Test Driver 230 receives explicit notice of this bug that causes the display flaw in
If the operator 110 clicks the Push Button 610 again, the label will change back to “Goodbye” 630 in
Testing the Window with the HCI Test Driver: To use the HCI Test Driver 230 for testing the Test Window 600, a makefile 800 in
The test tool libraries 810 are added to the makefile 800. The HCI Test Driver 230 provides a custom file named SpecialAction.cc 900, shown in
The command file 210, named test.cmd as a Test Command Window 1000, is written as shown in
The makefile 800 is used to compile and bind the files, thereby producing an executable named testMain. The same script 1100 for run_driver in
Upon opening the Command File Window 1200 in
The operator 110 may click the “Open Command File” button 1210 to choose the command file 210 desired and the HCI Test Driver 230 to use. This opens a Select Command File Window 1300, shown in
The operator 110 may then click the “Start Command File” button 1230 so the HCI Test Driver 230 can begin reading in and executing test.cmd 1000. The HCI Test Driver Window 1400 opens as FIG. 14. The HCI Test Driver Window 1400 includes a list of upper display buttons including “Command Lines” 1410, “To HCI Messages” 1420, “From HCI Messages” 1430 and “Check Log” 1440. In this example, the “Command Lines” button 1410 is highlighted. The “Check Log” tab 1440 displays test results and other summary information.
The contents from these display buttons may be displayed in a text box 1450, while a status box 1455 may provide instructional options. In this example, the HCI Test Driver Window 1400 enables the operator 110 to observe each line of test.cmd appear in the text box 1450 as that line is executed. The file name test.cmd for the command file 210 that was previously selected is identified in a Command File Name dialog box 1460. The HCI Test Driver 230 can be arranged to automatically start the command file 210 in response to a particular command file being specified on the command line 1460.
In this example, a “down” arrow icon 1465 (that may be colored red for emphasis) is shown below the dialog box 1460 and adjacent to a progress bar. The “down” arrow 1465 means that at least one of the tests failed, i.e., that there is a bug in the Test Window code. A prompt section below the arrow 1465 and the progress bar includes buttons for “Yes” 1470, “No” 1475, “Continue” 1480, “Options” 1485 and “Close” 1490.
The operator 110 may click on the “Check Log” button 1440 at the top of the HCI Test Driver Window 1400 to see which test(s) failed. The HCI Test Driver Window 1500 changes to highlight the “Check Log” button 1440 and adjusts the information displayed in the text box 1450, as shown in FIG. 15. In particular, the text box 1450 shows, by respective arrows 1510 and 1520, that the second and fourth test cases failed due to non-matching strings.
In this manner, the HCI Test Driver 230 informs the operator 110 which tests failed and why they failed. The Test Driver Window 1500 tells the operator 110 that the label for the Push Button 610 should display “Hello!!” 620 (with two exclamation points) while the label actually displayed “Hello!!!” 640 (with three exclamation points). This discrepancy corresponds to the code portion within the dashed oval 580 in the TestWindowCb.cc code file 500.
Now, the operator 110 can return to TestWindowCb.cc 1600 in FIG. 16 and find the bug. The portion of TestWindowCb.cc 1600 displayed in
The operator 110 can readily test the Test Window 600 again with the HCI Test Driver 230 by running a script 1700 shown in
In response, the HCI Test Driver Window 1800 opens as FIG. 18 and starts running the test.cmd command file. This time the HCI Test Driver 230 returns an “up” arrow 1820 (that may be colored green for emphasis) because all the tests passed. The operator 110 can also examine the text box 1450 to verify that all the tests passed. Selecting the “Check Log” 1440 button replaces the information displayed in the text box 1450 as shown in
Supplemental Features: When executing a command file 210, “Prompt” and “Pause” commands may be used to control the testing process with appropriately selectable buttons. When a “Prompt” command is encountered e.g., FIG. 22), the “Yes” and “No” buttons 1470, 1475 are sensitive, and the operator 110 responds either “Yes” or “No” to the prompt. For example, the operator 110 may be prompted to verify that actual results matched expected results. When a “Pause” command is encountered, the “Continue” button 1480 is sensitive. Selection of the “Options” button 1485 displays an HCI Test Driver Options Window 2000, as shown in
The HCI Test Driver Options Window 2000 includes several toggle buttons 2010, 2020, 2030, 2040 for setting test options. The “Demo Mode” toggle button 2010 is used to simulate mouse movement when widget activation commands are used in the command file 210. When such an instruction is used, the mouse moves to the referenced widget before activating that widget. To accelerate the test process, the “Pause” toggle button 2020 may turn off pauses in the command file 210. The “Prompt” toggle button 2030 may turn off prompt commands. When these buttons are toggled off, the commands are ignored. The “Test Window Visible” option 2040 is used to hide the Test Window 600.
A slider bar 2050 is used to slow down or speed up mouse movements when the “Demo Mode” button 2010 is selected. “Log” option toggle buttons 2060 are used to save the contents of the tabs 1410, 1420, 1430, 1440 on the HCI Test Driver Window 1400. The operator 110 may enter a file name in an appropriate dialog box line 2070 to enable toggling the associated one of the toggle buttons 2060.
An “Enter Commands” function (not shown) in the HCI Test Driver 230 displays an Enter Commands Window 2100 shown in FIG. 21. The Enter Commands Window 2100 enables commands to be entered manually in a text editing box 2110. The Enter Commands window 2100 also has an associated pop-up menu 2120, also shown in FIG. 21. The menu 2120 includes editing command selections, such as “Copy” 2130, “Paste” 2140 and “Clear” 2150 (erase text in box). Beneath the text editing box 2110 are window operation buttons, such as “Execute” 2160 (commands), “Clear” 2170 and “Close” 2180 (window).
A “View Command File” function (not shown) in the HCI Test Driver 230 displays a View Command File Window 2200 shown in
A Generate Commands Window 2300 in
The Generate Commands Window 2300 has three panes shown in
The command filenames can be provided in the Command File pane 2350. The Generates Commands Window 2300 extracts information from these files and inserts in the instructions produced therefrom in the Generated Commands pane 2360. Messages processed by the window 2200 may be extracted from the source code of the command file 210 in the Generated Messages pane 2370. This window 2300 also includes a “Close” button 2380 for the window's termination.
The File Selection group 2342 includes: “Select UIL File” 2342a, “Select AppDefaults File” 2342b, “Select Source File” 1242c and “Select By Widget” 2342d. The Category Selection group 2344 includes: “Select By Command” 2344a, “Select By Template” 2344b and “Select By Message” 2344c. Additional selections 2349 include generation and display options for the Generated Commands pane 2360 and the Generated Messages pane 2370. The Generation group 2346 includes options, inter alia, “Generate Commands” 2346a, “Refresh Comments” 2346b, “Execute Selected Commands” 2346c and “Generate Messages” 2346d. The Display group 2348 includes options for providing or erasing commands and/or messages.
Widget names and classes are extracted from the UIL file and context sensitive help information is extracted from the App-Defaults file. Once the files are specified, instructions can be generated and inserted into a command file 210. The File, Edit, and Search pull-down menus 2310, 2320, 2330, 2340 apply to the pane that currently has focus (i.e., not “grayed-out” and hence inactive). For example, if “Save As” 2316 in
For example, when a UIL file has been specified via “Select by UIL” 2342a in
The “Select By” options 2342, 2344 display the selected commands in the Generated Commands pane 2360. Selection of the “Select By Widget” option 2344a displays a Widget List Window 2400, as shown in FIG. 24. The window 2400 includes an Item List in Items pane 2410, a selection box 2420 (to identify the highlighted item) and a selection of buttons, including an “OK” button 2430. When a widget from the Items pane 2410 and the “OK” button 2430 are selected, those commands specifically associated with the selected widget are then displayed.
Likewise, selection of the “Select By Command” option 2344b displays a first Command Class List Window 2500, as shown in FIG. 25. The window 2500 includes a Command Class List in Items pane 2510, a selection box 2520 (to identify the highlighted class) and a selection of buttons, including an “OK” button 2530. When a command class from the Class pane 2510 and the “OK” button 2530 are selected, those commands specifically associated with the command class are displayed. Similarly, the “Select By Template” option 2344c displays a second Command Class List Window 2600, as shown in
A Build Command Window 2700 as shown in
Items listed under Parameter Name field column 2750 in the Parameter pane 1720 can be edited under Parameter Value field column 2760 accompanied by a Select column 2770. The Select column 2770 contains two types of arrows, a down arrow 2772 and a left arrow 2774.
The down arrow 2772 indicates that the parameter is a list of values displayed in a Parameter Selection Window 2800, as shown in
Exemplary Lists: There are several different types of commands supported by the HCI Test Driver 230. Check commands shown in
This may be useful when using Xrt Tables and verification of the sort order becomes necessary. The Check_Xrt_Sort_Order under item “kk.)” verifies a column in an Xrt Table to verify the values in each row. When generating this command, the current contents of the Xrt Table may be used in this command. In particular, a Check_Xrt_Sort_Order command may be generated for each column. If another sort button is selected, then the “Refresh Commands” button 2346b can be selected again, and new commands can be generated with the new sort order and added to a command file 210.
Command Formats for the HCI Test Driver Window 1400 include formats for files, controls, messages, sets and widgets. Check commands shown in
The HCI Test Driver 230 reads command lines from a user-specified text file and executes those commands. The HCI Test Driver 230 strips all leading blanks from a command line, as well as empty command lines and any command line beginning with a sharp symbol “#” that is thereby interpreted as a comment. If the command line contains a “#” that is not enclosed in quotes, the “#” and remainder of the line is considered to be a comment. A command line may extend over several text lines. A “carriage return” indicates that the command line is continued on the next line. The command line consists of a directive and one or more parameters. Parameters are delimited by blanks. A string surrounded by double quotes is considered to be a single parameter. Parameters containing the “#” character must be enclosed in quotes.
Conclusion: This is an example of how to test a very simple window with the HCI Test Driver 230. The techniques provided herein can reduce workload and save enormous man-hour resources for larger and more intricate codes. As the developer fixes software bugs and adds functionality, the entire HCI Window 260 can be quickly tested (versus only testing the changes), and total branch coverage can be achieved. The HCI Test Driver 230 provides an environment for testing HCI Windows 260 independently without using server sockets for the receipt and transmission of messages. The HCI Test Driver 230 enhances GUI development and productivity significantly, thereby providing an invaluable tool for software integration and validation.
Advantages of using the HCI Test Driver 230 include: (a) providing a “quick start” for HCI development by reducing lead time of simulation components; (b) providing scalability, portability, and ease of use; (c) ensuring commonality of core classes, templates, tools, and libraries for development of any HCI Window 260; (d) containing a set of common classes used by most HCI Applications 330 to shorten development time; (e) containing a set of classes that can be customized for each application; (f) containing a set of classes to interface with the HCI Test Driver 230 for standalone testing of the application; (g) providing the structure for adding multiple client-server interfaces (such as pipes and sockets) from the HCI client 220 to application servers; and (h) providing abstract classes for applications to use to derive other classes in order to implement application-specific requirements.
In addition, the HCI Test Driver 230 (a) enables the HCI Window 260 to be tested without using sockets for the receipt and transmission of messages; (b) simulates sending messages to the HCI client 220 from multiple interfaces; (c) can fully test the HCI Window 260 before integration with other software systems; (d) runs using ASCII command files 210 that are easily modifiable for new test cases; and (e) can be run in automation mode to simulate the operator 110 pushing buttons and using the HCI Window 260.
While certain features of the embodiments of the invention have been illustrated as described herein, many modifications, substitutions, changes and equivalents will now occur to those skilled in the art. It is, therefore, to be understood that the appended claims are intended to cover all such modifications and changes as fall within the true spirit of the embodiments.
Claims
1. A method for driving a computer interface on a computer platform that executes test software, the method comprising:
- connecting the computer interface with an input provider via a thread;
- communicating a command file having an instruction for execution on the computer interface;
- providing driver software to the computer interface;
- executing the instruction on the computer interface using the driver software to produce a result, wherein the instruction mimics a command from the input provider; and
- transmitting the result from the computer interface to the input provider.
2. The method according to claim 1, further comprising:
- exchanging server information with a remote server,
- executing a server command from the remote server in response to the server information.
3. The method according to claim 1, further comprising:
- displaying a window of the instruction on the computer interface; and
- providing an editor viewable by the window for modifying the instruction.
4. The method according to claim 1, wherein the instruction in the command file verifies attributes of the information by one of confirming conformity and identifying discrepancy.
5. The method according to claim 1, wherein the input provider is a series of selections from a list of menu options for a window displayable to an operator.
6. The method according to claim 1, wherein the command file includes a verification step that compares a reply to the instruction with an expectation to determine a discrepancy and displays an indicator in response to the discrepancy.
7. The method according to claim 1, wherein the command file incorporates the instruction in ASCII text using Motif code.
8. The method according to claim 1, wherein the driver software incorporates a software library.
9. The method according to claim 1, wherein the computer interface is a Human-Computer Interface (HCI), and the computer system is a platform simulator for combat operations.
10. A system for driving a computer interface for an input provider, the system comprising:
- an interface client connecting by a thread to the input provider and having a computer platform that includes the computer interface;
- a command file that issues an instruction to the computer interface;
- a test driver having software on the computer platform and that executes the instruction for providing a result to the computer interface; and
- a window that displays on the interface client, the window
- communicating the result from the computer interface to the input provider, wherein the instruction mimics a command from the input provider.
11. The system according to claim 10, further comprising:
- a remote server to exchange server information with the interface client,
- wherein the interface client executes a server command from the remote server in response to the server information.
12. The system according to claim 10, wherein the input provider is a series of selections from a list of menu options for the window displayable to an operator.
13. The system according to claim 10, wherein the command file includes a verification step that compares a reply to the instruction with an expectation to determine a discrepancy and displays an indicator in response to the discrepancy.
14. The system according to claim 10, wherein the command file incorporates the instruction in ASCII text using Motif code.
15. The system according to claim 10, wherein the driver software incorporates a software library.
16. The system according to claim 10, wherein the instruction in the command file verifies attributes of the information by one of confirming conformity and identifying discrepancy.
17. The method according to claim 1, wherein the input provider is a server simulator.
18. The system according to claim 10, wherein the input provider is a server simulator.
5781720 | July 14, 1998 | Parker et al. |
6028593 | February 22, 2000 | Rosenberg et al. |
6057828 | May 2, 2000 | Rosenberg et al. |
6859819 | February 22, 2005 | Rosenberg et al. |
6968370 | November 22, 2005 | Wu |
20020091968 | July 11, 2002 | Moreaux et al. |
20040148586 | July 29, 2004 | Gilboa |
20040225919 | November 11, 2004 | Reissman et al. |
- P Virgili, A Versatile PC-Based Human Computer Interface for Robotic Applications, National Research Council, 1997.
Type: Grant
Filed: May 16, 2007
Date of Patent: Sep 6, 2011
Assignee: The United States of America as represented by the Secretary of the Navy (Washington, DC)
Inventors: Maureen J. Gladden (Beaverdam, VA), Jennifer E. O'Leary (Stafford, VA), Colleen A. Johnson (Fredericksburg, VA), Donald J. Lemoine (Fredericksburg, VA), Frank J. Petranka (Fredericksburg, VA)
Primary Examiner: Daniel Pihulic
Attorney: Gerhard W. Thielman
Application Number: 11/805,266
International Classification: G06F 15/173 (20060101);