Method and apparatus for making and using wireless test verbs6862682Abstract A computerized method and system for testing a function of an information-processing system. This includes providing an architecture having a set of test commands, the test commands including a set of one or more stimulation commands and a set of one or more result-testing commands, and defining a set of test verbs out of combinations of the test commands. This allows the test programmer to define an overall test program that uses the test verbs in writing a test program that specifies an overall function that will extensively test a system-under-test. The methods further includes executing a program that includes a plurality of test verb instructions and outputting a result of the program. In some embodiments, the present invention provides a computer-readable media that includes instructions coded thereon that when executed on a suitably programmed computer executes one or more of the above methods. Claims What is claimed is: Description FIELD OF THE INVENTION
SELECT text_french
FROM tvt_infrastructure
WHERE screen = "MAIN" AND
objectname = "ICO_ADAPTOR" AND
text_english = "Adapters";
Such a SQL statement will return a value of "Connections" 642 as the French translation of the English text string "Adapters" 632. This embodiment uses database table 600 that also includes other types of information in a row 604 for other purposes. However, as shown in FIG. 7, another embodiment for translating 346 a primary language text string 342 into a target language equivalent 348 uses a table 700 that is for language translation 346 purposes only. In other embodiments, translation process 346 operates using a relational database management system to store the primary language 342 and target language equivalents 348. As shown in FIG. 7, database table 700, named tvt_translation 708, has columns 702 named English 710, French 720, Spanish 730, and German 740 and rows 704 holding text strings of equivalent meaning in the language of their respective columns. In one such embodiment, an example of a structured query language (SQL) statement used to select 346 a target language equivalent 348 of a primary language text string 342 in a typical relational database management system is:
SELECT german
FROM tvt_infrastructure
WHERE spanish = "Archivo";
Such a SQL statement will return a value of "Akte" 742 as the German translation 346 of the Spanish text string "Archivo" 732. In one such embodiment, the system-under-test is a washing machine, developed with English as the primary language. However, the washing machine must also be able to display text on its LCD display in French and Spanish. In such embodiments, when a process is encountered that requires testing of graphical user interface text displayed on the LCD, any text strings that are displayed in English when the washing machine is operating in its primary language are sent to process 346 for translation into the target language 344 of French or Spanish. In some embodiments, underlying a system for automated testing of an information-processing system is a flexible, layered architecture 500, as shown in FIG. 5, that allows such a system to operate on many different devices and operating-system platforms and in many different languages. In some embodiments, the flexible, layered architecture 500 includes a test verb layer 510, a task layer 520, a platform abstraction layer 530, a graphical user interface object layer 540, and a test tool primitive layer 550. In some embodiments, test verb layer 510 includes the semantic content of the test verbs that define a test vocabulary. In some embodiments, task layer 520 includes test verbs instantiated in memory that are available to an automated test program during execution. In some embodiments, the platform abstraction layer 530 handles test verb command handling differences when test verbs are executed or performed on different platforms that have different execution, processing, stimulation, or language requirements. In some embodiments, graphical user interface object layer 540 handles graphical user interface object differences between systems-under-test such as color display, monochrome display, display size, display resolution, or language. In some embodiments, the test tool primitive layer 550 includes the application programming interface (API) of the test tool used along with a test verb implementation such as the HLF application programming interface available within TestQuest Pro. In some embodiments, the flexible, layered architecture 500 allows communication between the infrastructure layers and with additional ancillary components of the computerized system embodied in FIG. 1. In some embodiments, test verb layer 510 includes semantic content that accesses test data 514 that becomes instantiated in memory in task layer 520. In some embodiments, task layer 520 communicates with test verb layer 510, platform abstraction layer 530, graphical user interface object layer 540, and test tool primitives layer 550; accesses test data 514; and handles activity logging 570 and error handling and recovery 580. In some embodiments, platform abstraction layer 530 communicates with task layer 520 and graphical user interface object layer 540 and handles activity logging 570 and error handling and recovery 580. In another embodiment, graphical user interface object layer 540 communicates with task layer 520, platform abstraction layer 530, and test tool primitives layer 550 and handles activity logging 570 and error handling and recovery 580. In some embodiments, test verbs are defined by abstracting the function to be tested to a system level, rather than a hardware level, to ensure the reusability of test verbs across platforms. In one such embodiment for a computerized coffee pot, as shown in FIG. 8, the test vocabulary for a computerized coffee pot 830 is valid regardless of whether the coffee pot on/off switch is a touch panel interface or an electro-mechanical switch. In this embodiment, all of the test verb definitions 825 for testing a computerized coffee pot are created at a level that allows for a test program using these test verbs 825 to be reused from one type of coffee pot to the next. In such an embodiment, the hardware specifics for test verbs are handled in the platform abstraction and graphical user interface object layers. Both example test vocabularies shown in FIG. 8 are oriented to the operations performed not the hardware specifics of the platform. In these embodiments, the flexible, layered architecture shown in FIG. 5, and described above, allows this platform independence. Wireless Test Verb Architecture 1 Overview The following exemplary architecture provides a list of some test verbs embodiments for a generic phone implementation of test verb technology (TVT) along with providing possible parameter information and usage explanations for the test verbs. 2 Abbreviations Acronyms & Definitions
ATS Automated Test Solution
ATC Automated Test Case (the script that automates the test
case)
GUI Graphical User Interface
TQPro TestQuest Pro system
TED Test Execution Driver
Test Case The basic test unit that reports a pass/fail status
Test Verb ATC statements that implement common testing activities.
TV Test Verb
Test Session The running of a sequence of ATC's
SUT System Under Test
3 Test Verbs High-Level Specification The table below shows the test verb embodiments that are described herein. This is intended to be an illustrative list of some embodiments of wireless test verb technology. This is not intended to be an exhaustive list of embodiments. Many other embodiments will be apparent to those of skill in the art upon reviewing the information disclosed herein. The various TV are categorized as to usage. Parameterization, implementation details and general design guidelines for each TV are treated in later sections
TV List Parameters
GENERIC TEST VERBS
FOR_EACH prt, arr
FOR_EACH_IF ptr, arr, expr
REMARK sz
SKIP_TESTCASE sz
KNOWN_TO_FAIL sz
KNOWN_TO_FAIL_BUG sz
DELAY time
NOT (another TV)
NAVIGATION TEST VERBS
NAVIGATE_HOME NULL
NAVIGATE_TO_SCREEN sz
VERIFICATION TEST VERBS
VERIFY_CHOICE_ITEMS list
VERIFY_CHOICE_ITEMS_SELECTED list
VERIFY_INCOMING_CALL timeout
VERIFY_TEXT sz
VERIFY_TEXT_SELECTED sz
READ_TEXT buf
VERIFY_OBJECT sz
WAIT FOR TEST VERBS
WAIT_FOR_TEXT sz, timeout
WAIT_FOR_OBJECT sz, timeout
CURSOR TEST VERBS
CHECK_CURSOR_BLINK x, y
CURSOR_MUST_NOT_EXIST x, y
MENU ITEM SELECTION TEST VERBS
SELECT_MENU_ITEM sz
PHONE RELATED TEST VERBS
SET_POWER ival
POWER_CYCLE_PHONE NULL
RESET_AUDIO NULL
DISCONNECT_BATTERY NULL
CONNECT_BATTERY NULL
UNLOCK_PHONE NULL
LOCK_PHONE NULL
LOG_PHONE_CONFIGURATION NULL
SET_OBJECT Sz
KEY PRESS TEST VERBS
DIAL_NUMBER sz
SEND_STRING sz
PRESS_KEYS sz
HOLD_KEY sz
RELEASE_KEY sz
4 Test Verbs Detail The table below shows some embodiments of the test verbs that are described herein. The various test verbs are categorized. 4.1 Generic Test Verbs This category of TV's is generally associated with whatever implementation is undertaken. These TV's are more specific to testing than they are to a particular platform and are used to control, monitor, log and establish control of testing. 4.1.1 FOR_EACH(ptr, arr) This test verb is a simplified loop iterator that works in conjunction with special data table format. The two parameters that are passed to this test verb have to following characteristics: ptr--This variable is a pointer to the first record in the named static structure that is the second variable of this test verb. arr--This variable is the name of the static structure. In some embodiments, the general usage of this test verb within the script would be as shown below:
FOR_EACH(Record,DataTable)
{
DoThis(Record->Object1);
DoThat(Record->Object2);
DoThis(OtherParameter);
}
This script usage would in general be supported by a static structure that was declared global to the ATC as follows:
static struct
{
char * Object1;
int Object2;
} *Record,DataTable[] = {
{ "One", 1 },
{ "Two", 2 },
{ "Three" 3 }
};
4.1.2 FOR_EACH_IF(ptr, arr,expr) This test verb is a slightly more complex loop iterator that works in conjunction with a special data table format, allowing for conditional execution of data table entries. The three parameters that are passed to this test verb have to following characteristics: ptr--This variable is a pointer to the first record in the named static structure that is the second variable of this test verb. arr--This variable is the name of the static structure. expr--a condition that can be used for early termination of the for loop In some embodiments, the general usage of this test verb within the script would be as shown below:
FOR_EACH_IF(Record,DataTable,(Record->Filter = = variable))
{
DoThis(Record->Object1);
DoThat(Record->Object2);
Filter = DoThis(OtherParameter);
}
This script usage would in general be supported by a static structure that was declared global to the ATC as follows:
static struct
{
char * Object1;
int Object2;
int Filter;
} *Record,DataTable[] = {
{ "One", 1, 4},
{ "Two", 2, 4},
{ "Two" 2, 8}
};
4.1.3 REMARK(sz) This TV simply posts a comment to the log. In some embodiments, the general usage of this test verb within the script would be as shown below: REMARK("Specialized Test Case for SMS messaging") 4.1.4 SKIP_TESTCASE(sz) This TV simply posts comments to the log. In some embodiments, the general usage of this test verb within the script would be as shown below:
TEST_CASE_START("TC DataTable 14")
{
SKIP_TESTCASE("The TC requires a BSE, will perform
manually for now");
}
TEST_CASE_CLEANUP(iStatus)
4.1.5 KNOWN_TO_FAIL(sz) This TV simply posts comments to the log and then skips the remainder of the code to go to the test case cleanup. In some embodiments, the general usage of this test verb within the script would be as shown below: In general, if an ATC is authored, but the script does not yet run for some external reason (that is not a bug), this line can be placed in an appropriate place in the script to ensure the script does not continue to a failure and to continue to note in the log files an area that must be addressed prior to completion. In general, the test engineer would author a complete script, execute the script one time and determine that there was a Bug in the software. At that point, the BUG TV would be inserted typically as the first line of code, to record the fact of the bug to the logfile and skip the remainder of the test. This line of code would be removed upon the bug being corrected so that the test script again executed. It is simply a short-term placeholder of sorts.
TEST_CASE_START("TC DataTable 14")
{
KNOWN_TO_FAIL("BSE TV for invalid frequency not
implemented yet.");
"BUG - 1734 - End Call Softkey not visible during emergency
call");
MORE_TESTVERBS( );
MORE_TESTVERBS( );
}
TEST_CASE_CLEANUP(iStatus);
4.1.6 KNOWN_TO_FAIL_BUG(sz) This TV simply posts comments to the log and then skips the remainder of the code to go to the test case cleanup. In some embodiments, the general usage of this test verb within the script would be as shown below: In general, the test engineer would author a complete script, execute the script one time and determine that there was a Bug in the software. At that point, the BUG TV would be inserted typically as the first line of code, to record the fact of the bug to the logfile and skip the remainder of the test. This line of code would be removed upon the bug being corrected so that the test script again executed. It is simply a short term placeholder of sorts.
TEST_CASE_START("TC DataTable 14")
{
KNOWN_TO_FAIL_BUG(""BUG - 1734 - End Call Softkey
not visible during emergency call");
MORE_TESTVERBS( );
MORE_TESTVERBS( );
}
TEST_CASE_CLEANUP(iStatus);
4.1.7 DELAY(time) This TV simply waits the specified amount of time before releasing control to the next line of code. The parameter that is passed to this TV has the following characteristics: time--an integer string denoting the number of milliseconds to pause. In some embodiments, the general usage of this test verb within the script would be as shown below: PRESS_KEY("<Exit>"); DELAY(1000); VERIFY_TEXT ("Menu", STANDARD); 4.1.8 NOT(another TV) This TV performs the converse of another TV and takes care of correct logging and error handling. For example, if VERIFY_OBJECT("aHat") was used to verify that a bitmap depicting a hat was displayed on the screen, the command shown below would be used to verify that the bitmap was NOT present on the screen. NOT(VERIFY_OBJECT("aHat")); 4.2 Navigation Test Verbs This category of TV's is platform independent to the extent that it is typically used with a menued UI implementation. It is very platform dependent in it's implementation, as the characteristics of each platform are accessed by the TV's. 4.2.1 NAVIGATE_HOME(NULL) This TV takes the steps necessary to return the device to its "home" or default screen. This is the screen from which all other navigation takes place. For the navigation in general, there will be a datatable maintained as one sheet of an Excel spreadsheet which will have a unique name for every screen that can be navigated to (including "home"), along with a title, tag or other unique identifier that can be used to verify navigation to that screen and the key sequence (from the home screen) that is required to navigate to that screen. This particular TV will lookup the screen name (likely "home") on the Excel spreadsheet and execute the associated key sequence and then verify that the navigation to the home screen was successful. For this particular TV, it is likely that the navigation is simply a sequence of END or CLEAR keys. This TV is typically implemented because it is quite frequently used. It could be replaced by the following TV (NAVIGATE_TO_SCREEN("Home")). In some embodiments, the general usage of this test verb within the script would be as shown below: DO_SOMETHING(sz); VERIFY_SOMETHING(sz); NAVIGATE_HOME( ); DO_SOMETHING_ELSE(sz); NAVIGATE_TO_SCREEN("Names Add Number"); DO_SOMETHING(sz); CHECK_SOMETHING(sz); This TV is supported by an Excel spreadsheet table that would have the following general format:
Screen English Spanish Navigation
Home Names nombre <End><End> <Clear>
Names Add sumar
Right><Down><Down><Down><Down>
Add Number numero <Left>
Number
4.2.2 NAVIGATE_TO_SCREEN(sz) This TV takes the steps necessary to navigate to the specified screen. A single parameter, which is the screen to which to navigate is passed to this routine. The first action taken within this TV will be to navigate to the Home screen, after which the navigation to the desired screen will take place. The associated Excel spreadsheet contains entries which specify all navigation from the "home" screen. The parameter that is passed to this TV has the following characteristics: sz--a string matching an entry in the navigation table (Excel spreadsheet) discussed in the previous section. In some embodiments, the general usage of this test verb within the script is shown in the previous paragraph, along with the supporting spreadsheet example. 4.3 Verification Test Verbs This category of TV's is used to perform verification activities on the device. 4.3.1 VERIFY_CHOICE_ITEMS(list) This TV verifies that a list of choice items supplied by the call exists on the display. It will pass if the items are visible whether they are selected (reverse highlighted or color coded) or not selected. The TV will scroll as necessary to view the complete list. The choice items must be valid screen names from the datatable (Excel spreadsheet mentioned in the previous section).
char *aList[10] = {"Unmute",NULL};
VERIFY_CHOICE_ITEMS(aList);
In some embodiments, the general usage of this test verb within the script would be as shown below: NAVIGATE_TO_SCREEN("Names Add Number"); VERIFY_CHOICE_ITEMS(aList); This script usage would in general be supported by a character array declared within the script, an example of which would be:
char *aList[10] = {"General", "Mobile", "Home", "Work",
"Fax", NULL};
4.3.2 VERIFY_CHOICE_ITEMS_SELECTED(list) This TV verifies that a list of choice items supplied by the call exists on the display, and that the items are in the required order and selected (reverse highlighted or color coded) as the cursor passes over each item. The choice items must be valid screen names from the datatable (Excel spreadsheet mentioned in the previous section).
char *aList[10] = {"Unmute",NULL};
VERIFY_CHOICE_ITEMS(aList);
In some embodiments, the general usage of this test verb within the script would be as shown below: NAVIGATE_TO_SCREEN("Names Add Number"); VERIFY_CHOICE_ITEMS(aList); This script usage would in general be supported by a character array declared within the script, an example of which would be:
char *aList[10] = {"General", "Mobile", "Home", "Work",
"Fax", NULL};
4.3.3 VERIFY_INCOMING_CALL(timeout) This TV will continue to attempt to verify that an incoming call is detected until the specified timeout period is exceeded. Internal to this test verb, it may look for objects, look for text, check LED's or use whatever method a particular phone requires for verification of an incoming call. timeout--An integer specifying the number of seconds to retry prior to erroring out. In some embodiments, the general usage of this test verb within the script would be as shown below: VERIFY_INCOMING_CALL(25); 4.3.4 VERIFY_TEXT(sz) This TV verifies that the specified text in the fonts declared in the font tables appears on the display. The parameters passed to this TV has the following format: sz--A string specifying the text string that should appear on the display In some embodiments, the general usage of this test verb within the script would be as shown below: VERIFY_TEXT("John Smith"); VERIFY_TEXT("123 Main Street"); The fonts that are searched for this test verb can be any of those specifically listed in the platform font table. The search region is the default search region set in the platform layer. If a specific font or a specific search region must be verified, the _EXT TV must be developed as discussed in section 5. 4.3.5 VERIFY_TEXT_SELECTED(sz) This TV verifies that the specified text. The parameter passed to this TV has the following format: sz--A string specifying the text string that should appear on the display This TV can be thought to be the opposite of the VERIFY_TEXT TV, as for monochrome screens, typically a single routine is used for this with the foreground and background just reversed. In other instances, the same TV code is used, with a simple if statement that switches the search flow based on foreground/background requirements. The script usage and supporting data are the same as the previous TV. 4.3.6 READ_TEXT(buf) This TV is typically only used in an _EXT format (as described below). It reads the screen for the data and returns that information found. buf--a character buffer to which the return data should be written. In some embodiments, the general usage of this test verb within the script would be as shown below: NAVIGATE_TO_SCREEN("ESN"); READ_TEXT(szText); //Attempt to modify ESN SEND_KEYS("<Delete><Clear>"); PRESS_KEYS("1234"); VERIFY_TEXT(szText); The above usage shows a general read text, which could be used to cycle through the entire screen and a pattern of different fonts, which in many cases is not practical, thus the typical usage of this as a _EXT verb. 4.3.7 VERIFY_OBJECT(sz) This TV verifies the characteristics associated with anything that can be deemed an object. Object types include Icons, Softkeys, Images, Tones, LED's, etc. The string that is passed to this routine contains a key that is used internal to the routine to determine the object type. This in turn leads to the area of the Excel spreadsheet that is used to gather the object characteristics relative to each object type verification. sz--a string denoting object type and object name In some embodiments, the general usage of this test verb within the script would be as shown below: NAVIGATE_TO_SCREEN("ESN"); VERIFY_OBJECT("IC_ConnectedIcon"); VERIFY_OBJECT("SK_Menu"); This test verb would be supported for the above usage by two different sheets in the Excel file. One which contains the Icons and their associated properties and one the contains the SoftKeys and their associated properties. In the first case above, the lookup would be performed against the Icon sheet because of the "IC_" prefix in the second case, the lookup is against the SoftKey sheet ("SK_" prefix). The associated tables in Excel for each case would take a form such as follows;
Icon Properties Data Sheet
ICON Bitmap Region
ConnectedIcon ConnectedIcon.bmp 0, 0, 100, 20
SoftKey Properties Data Sheet
Key Name Font Foreground Background Reqion
Menu Courier.fnt Black White 0, 0, 20, 20
4.4 WaitFor Test Verbs This category of is used to provide the capability to wait a specified amount of time for an event to occur and declare an error if the event does not occur in the specified timeframe. 4.4.1 WAIT_FOR_TEXT(sz timeout) This TV has the identical form to VERIFY_TEXT, where the first parameter specifies the text. The difference is that instead of the immediate check performed by VERIFY_TEXT, this TV will continue to retry the verification activity until a specified timeout period is elapsed. sz--A string specifying the text string that should appear on the display Timeout--The time in seconds to continue to retry the verification activity before declaring an error. In some embodiments, the general usage of this test verb within the script would be as shown below: SET_POWER(ON); WAIT_FOR_TEXT("Searching for Service", 10); 4.4.2 WAIT_FOR_OBJECT(sz, timeout) This TV has the identical form to VERIFY_OBJECT, where the first parameter specifies the object. The difference is that instead of the immediate check performed by VERIFY_OBJECT, this TV will continue to retry the verification activity until a specified timeout period is elapsed. sz--a string denoting object type and object name Timeout--The time in seconds to continue to retry the verification activity before declaring an error. In some embodiments, the general usage of this test verb within the script would be as shown below: PRESS_KEY("<Talk>"); WAIT_FOR_OJBECT("IC_Phone", 3); 4.5 Cursor Test Verbs This category of TV's is used to perform various operations with the cursor. 4.5.1 CHECK_CURSOR_BLINK(x,y) This test verb verifies that the cursor is blinking at the specified location. The location must be expressed in X and Y coordinates, and is typically found in the Excel Spreadsheet. The parameters for the TV are as follows: x--The x location to search for the cursor y--The y location to search for the cursor In some embodiments, the general usage of this test verb within the script would be as shown below: CHECK_CURSOR_BLINK(FirstLineStart); PRESS_KEY("<Down>"); CHECK_CUROR_BLINK(SecondLineStart); CURSOR_MUST_NOT_EXIST(FirstLineStart); Where FirstLineStart is an x, y pair that is retrieved from the Excel Spreadsheet. 4.5.2 CURSOR_MUST_NOT_EXIST(x,y) This test verb verifies that the cursor does not exist at the specified location. The location must be expressed in X and Y coordinates, and is typically found in the Excel Spreadsheet. The parameters for the TV are as follows: x--The x location to search for the cursor y--The y location to search for the cursor In some embodiments, the general usage of this test verb within the script would be as shown in the above paragraph: 4.6 Menu Item Selection Test Verbs This TV is used to perform menu selection. 4.6.1 SELECT_MENU_ITEM(sz) This test verb selects a particular menu item. The parameters for the TV are as follows: sz--The string to select In some embodiments, the general usage of this test verb within the script would be as shown below: NAVIGATE_TO_SCREEN("Calls"); SELECT_MENU_ITEM("Dialed"); PRESS_KEY("<Select>"); 4.7 Phone Related Test Verbs This category of TV's is related to specific phone actions. 4.7.1 SET_POWER(ival) This TV sets the power of the phone to a specified state. The parameter for the TV is as follows: ival--Either ON or OFF In some embodiments, the general usage of this test verb within the script would be as shown below: SET_POWER(ON); WAIT_FOR_TEXT("Connected", STANDARD); 4.7.2 POWER_CYCLE_PHONE(NULL) This TV powers off the phone and then powers on the phone. In some embodiments, the general usage of this test verb within the script would be as shown below: POWER_CYCLE_PHONE( ); WAIT_FOR_TEXT("Connected", STANDARD); 4.7.3 RESET_AUDIO(NULL) This TV resets the audio detection circuitry of the test station (if so equipped). This TV is typically used in conjunction with a VERIFY_OBJECT call. In some embodiments, the general usage of this test verb within the script would be as shown below: RESET_AUDIO( ); DO_SOMETHING( ); VERIFY_OBJECT("AUDIO_RingToneOn"); 4.7.4 DISCONNECT_BATTERY(NULL) This TV disconnects the battery from the phone. In some embodiments, the general usage of this test verb within the script would be as shown below: SELECT_MENU_ITEM("Spanish",5); DISCONNECT_BATTERY( ); CONNECT_BATTERY( ); SET_LANGUAGE("Spanish"); WAIT_FOR_TEXT("Connected", STANDARD); In this case, Spanish is the language selected from a menu item selection. The battery is then disconnected and reconnected and it is then verified that the language selection remains Spanish. The SET_LANGUAGE TV is the key to the various routines that the lookup table in the Excel spreadsheet is to be used to find the translation of the "Connected" phrase in the Spanish language and that is the verification item. 4.7.5 CONNECT_BATTERY(NULL) This TV reconnects the battery to the phone. In some embodiments, the general usage of this test verb within the script would be as shown above: 4.7.6 UNLOCK_PHONE(NULL) This TV unlocks the phone. In some embodiments, the general usage of this test verb within the script would be as shown below: LOCK_PHONE( ); SELECT MENU_ITEM("Dial); WAIT_FOR_TEXT("Enter Lock Code", STANDARD); UNLOCK_PHONE( ); 4.7.7 LOCK_PHONE(NULL) This TV unlocks the phone. In some embodiments, the general usage of this test verb within the script would be as shown above: 4.7.8 LOG_PHONE_CONFIGURATION(NULL) This TV logs various information about the phone, the TV is somewhat dependent on the particular phone that is used and what information is desired to be logged when this TV is selected. Typically the TV will navigate to various menus and read information from the screen such as the software version, browser version, ESN, etc. In some embodiments, the general usage of this test verb within the script would be as shown below: LOG_PHONE_CONFIGURATION( ); 4.7.9 SET_OBJECT(sz) This TV is used to act upon input objects with characteristics defined in the spreadsheet. Objects can include strings of text, numeric strings, discretes, audio, etc. The string passed to the TV indexes into a table in the spreadsheet which can contain a column or columns that are used internal to the implementation to determine the actions associated with the particular object. In some embodiments, the general usage of this test verb within the script would be as shown below SET_OBJECT("AnswerCall"); In the case above, the actions necessary to answer a call on a particular phone (keypress, keypresses, touchpad, etc.) would be performed when this command is utilized. Allowable Input Parameters for this TV are: AnswerCall--Must perform actions necessary to answer a call to the mobile. EndCall--Must perform the actions necessary to terminate a call to the mobile. 4.8 Key Press Test Verbs This category of TV's is used to stimulate the keypad of the phone and input either text or numerics dependent on selection. 4.8.1 DIAL_NUMBER(sz) This TV sends the specified numeric sequence to the phone, and hits the key necessary to "send" the numeric string to the network. The parameter for the TV is as follows: sz--String specifying the number to be sent to the phone In some embodiments, the general usage of this test verb within the script would be as shown below: DIAL_NUMBER("5551212"); 4.8.2 SEND_STRING(sz) This TV set the specified sequence of keys to the phone. The parameter for the TV is as follows: sz--String specifying the keys to be sent In some embodiments, the general usage of this test verb within the script would be as shown below: SEND_STRING("Alpha123"); Within the TV, the determination is made of what keys to strike and how many times to strike the key to obtain the desired sequence, which can be alpha, or alpha and numeric. If the current screen is not a text entry screen, the multiple key strikes to obtain the specified alpha character could be represented as multiple instances of the same number. The TV contains the intelligence to wait the required time between keystrokes to ensure the proper string is obtained when on an alpha entry screen. 4.8.3 PRESS_KEYS(sz) This TV will use the Excel Spreadsheet to perform a lookup of the specified key and press it. It is typically used to specify a named softkey for pressing via looking up what key activates that particular softkey, or to simply press a sequence of keys a single time. The parameter for the TV is as follows: sz--String specifying the key(s) to be pressed In some embodiments, the general usage of this test verb within the script would be as shown below: PRESS_KEYS("<Select>"); PRESS_KEYS("12345"); This TV in the first case above is supported by a sheet in the data file that specifies the associated key to press. 4.8.4 HOLD_KEY(sz) This TV is used to press a specified key without releasing it. The parameters for the TV are as follows: sz--key to be pressed In some embodiments, the general usage of this test verb within the script would be as shown below: HOLD_KEY("1"); DELAY("5000"); RELEASE_KEY("1"); 4.8.5 RELEASE_KEY(sz) This TV is used to release a specified key=t. The parameters for the TV are as follows: sz--key to be pressed In some embodiments, the general usage of this test verb within the script would be as shown above. EXT Test Verbs A certain category of test verbs is quite often required, that being an extended test verb and is denoted by a suffix of _EXT to one of the TV's defined in the previous section. The typical list of TV's that would have the EXT suffix would be as follows: VERIFY_TEXT VERIFY_TEXT_SELECTED VERIFY_TEXT_DOES_NOT_EXIST READ_TEXT WAIT_FOR_TEXT These TV's typically will get the _EXT suffix to specifically denote font and search region characteristics. One example (VERIFY_TEXT) will be shown below. The others follow the same format. VERIFY_TEXT_EXT(sz, font, region) This TV verifies that the specified text in the specified font in the specified region appears on the screen. The parameters passed to this TV has the following format: sz--A string specifying the text string that should appear on the display font--a font, either defined or specified a particular search region, often contained in the data table In some embodiments, the general usage of this test verb within the script would be as shown below: VERIFY_TEXT_EXT("John Smith", LARGE_FONT, NAME_REGION); CONCLUSION As shown in FIG. 2, one aspect of the present invention provides a computerized method 200 for testing, from a host computer, a function of a wireless information-processing device. Method 200 provides an architecture having a set of test commands 212, the test commands 212 including a set of one or more stimulation commands 232 and a set of one or more result-testing commands 234 and defining a set of wireless test verbs from combinations of the test commands 212. This allows the test programmer to define an overall test program 216 that uses the wireless test verbs 214 in writing a test program 216 that specifies an overall function that will extensively test a wireless information processing device-under-test 99. The method further includes executing 220 a program that includes a plurality of wireless test verb instructions 214 and outputting 250 a result of the program 216. The method 200, further includes executing one or more test programs 216 on the host test computer. In some embodiments, the wireless information processing device tested by an executing method 200 is a wireless telephone. In some other embodiments, the wireless information processing device tested by an executing method 200 is a personal data assistant (PDA). In various embodiments, the stimulating 232 of method 200 includes a dialing test for performance on a wireless telephone when the method 200 is executed. In some embodiments, the receiving of a method 200 embodiment includes receiving a ringing signal. In some embodiments of method 200, the test verbs 214 include test verbs 214 for stimulating 232 a wireless personal data assistant (PDA). In some other embodiments of method 200, the test verbs 214 include test verbs 214 for stimulating 232 a wireless phone. In some embodiments, the method 200 further includes connecting the wireless information-processing device to one or more networks. In various method 200 embodiments, the one or more networks the wireless information-processing device can be connected to include a local area network, a wide area network, the internet, a telephone network, and a peer-to-peer network. In various embodiments of method 200, the test verbs 214 include test verbs 214 defined to perform tasks that include looping, looping until certain criteria is met, posting remarks to an execution log, skipping steps in a test sequence in various ways, pausing test program or session execution for a specified period of time, and testing for an inverse result another test verb is intended to test for (see "NOT" test verb described above). Other aspects of some embodiments of the method 200 include test verbs 214 for navigating through a graphical user interface of a wireless information-processing device, verifying the existence of specified items in a displayed list, verifying the existence and order of specified items in a displayed list, waiting for and verifying an incoming telephone call, and verifying that specified text is displayed and in the proper font. Some other embodiments of the method 200 include test verbs 214 for verifying that specified text is selected, reading displayed text, verifying the characteristics associated with a displayed object, waiting for certain events to occur, waiting for a specified event to occur, checking if a cursor is blinking, and checking if a cursor exists. Further, some embodiments of a method 200 include test verbs 214 for determining the existence of static, blinking, and moving pixel patterns. Some method 200 embodiments include test verbs 214 for selecting menu items, setting power options, cycling power settings, manipulating audio options, connecting and disconnecting a power source, locking and unlocking a device, logging configuration settings, and acting upon input objects. In some further embodiments, method 200 includes test verbs 214 for dialing phone numbers, entering text strings, simulating pressing of keys and buttons, simulating the holding of keys and buttons for a specified duration, simulating the release of keys and buttons In some embodiments, the method 200 also includes wireless test verbs 214 for causing numeric, alphanumeric, and iconic data to be entered into the wireless information-processing device includes simulating key-presses, spoken words, and handwriting strokes. Another aspect of the present invention, shown in FIG. 1, provides a computer readable media 160 having a instructions coded thereon for causing a suitably configured information handling system 110 to perform tests on a wireless information-processing device 99. Yet another aspect of the present invention, again shown in FIG. 1, provides a computerized system 110 for testing a function of an information-processing system 99. The system includes a memory 120, an automated test tool 126, a set of test commands 122 stored in the memory 120, wherein each one of the test commands 122 includes a set of one or more stimulation commands 127 and a set of one or more result-testing commands 128. The system also includes individual wireless test verb definitions 125 stored in the memory 120 that defines a set of wireless test verbs 124 out of combinations of the test commands 122. A programmer then generates a wireless test program 121 stored in the memory 120 that includes a plurality of wireless test verb instructions 125. The system also includes a comparator 123 that generates test results based on a comparison of test result signals to desired result values. The system also includes an output port 130 that drives stimulation signals 132 based on the execution of the test program 121, an input port 140 that receives result signals 142 based on behavior of a system-under-test 99, and an output device 199 that presents a result of the test program 121. The system also includes an output device 199 for presenting the test results of a test program 121. In some embodiments, the computerized system 110 is configured for testing wireless information processing devices including wireless telephones and personal digital assistants (PDA). It is understood that the above description is intended to be illustrative, and not restrictive. Many other embodiments will be apparent to those of skill in the art upon reviewing the above description. The scope of the invention should, therefore, be determined with reference to the appended claims, along with the full scope of equivalents to which such claims are entitled.
|
Same subclass Same class Consider this |
||||||||||