TestWorks & Testing Technology Glossary

Listed below in alphabetic order is a complete glossary of common software testing terms that apply to the software testing and quality problems in general and to use of TestWorks in particular. These definitions are based on applicable IEEE and other international standards whenever possible.

Many of these terms also apply to the eValid Web Testing and Analysis Suite, which has a slighly different slant. See the: eValid Glossary, where the context is

References to the particular product within the collection of tools that make up the TestWorks product line are made when appropriate.

A...(BACK TO TOP)

• Acceptance test. Formal tests conducted to determine whether or not a system satisfies its acceptance criteria and to enable the customer to determine whether or not to accept a system. This particular kind of testing is performed with the STW/Regression suite of tools.
• Action statement. A non-decision statement in a program that results in executable code.
• Activation clause. A clause in the SMARTS' ATS file which is comprised of the activation keyword and a sequence of system commands to be performed during test execution.
• Ada. The DoD standard programming language.
• Ancestor node. A node in a STW/Coverage directed graph that lies on some path (i.e., sequence of logical branches) that leads to the specified node.
• apg. All Paths Generator. A TCAT-PATH facility that generates equivalence classes that include all program paths from a directed graph.
• Arc. In a directed graph, the oriented connection between two nodes. This is also referred to as an edge.
• Archive file. A file generated from STW/Coverage's cover, scover or ctcover utility containing test trace information in reduced form.
• ASCII synchronization. The process by which a playback (e.g. from CAPBAK/X) holds back execution until a character string is located.
• ATS. A SMARTS user-designed description file which references a test suite. Test cases are referenced in a hierarchically organized structure and can be supplemented with activation commands comparison arguments, pass/fail evaluation criteria, and system commands. When SMARTS is run on either a X Window or UNIX system, the ATS is written in SMARTS' Description Language (which is similar to C language syntax). The ATS file is written in SMARTS C-Interpreter Language when SMARTS is run on a MS Windows system.
• AUT. Application-under-test.
• Automated Test Script. See ATS.
• Automatic flow control. When CAPBAK/UNIX is being run in terminal emulation record mode, a record of the manual flow control is stored in the keysave file and response file.When CAPBAK/UNIX is transmitting keys in playback mode the flow control is maintained by using the information saved in these files.
• Automated Test Script. See ATS.
• Automatic flow control. When CAPBAK/UNIX is being run in terminal emulation record mode, a record of the manual flow control is stored in the keysave file and response file.When CAPBAK/UNIX is transmitting keys in playback mode the flow control is maintained by using the information saved in these files.

B...(BACK TO TOP)

• Back-to-back testing. For software subject to parallel implementation, back-to-back testing is the execution of a test on the similar implementations and comparing the results.
• Basis paths. The set of non-iterative paths.
• Black-Box testing. A test method where the tester views the program as a black box, that is the test is completely unconcerned about the internal behavior and structure of the program. Rather the tester is only interested in finding circumstances in which the program does not behave according to its specifications. Test data are derived solely from the specifications without taking advantage of knowledge of the internal structure of the program. Black-box testing is performed with the STW/Regression suite of tools.
• Bottom-up testing. Testing starts with lower level units. Driver units must be created for units not yet completed, each time a new higher level unit is added to those already tested. Again a set of units may be added to the software system at the time, and for enhancements the software system may be complete before the bottom up tests starts. The test plan must reflect the approach, though. The STW/Coverage suite of tools supports this type of testing.
• Built-in testing. Any hardware or software device which is part of an equipment, subsystem of system and which is used for the purpose of testing that equipment, subsystem or system.
• Byte mask. A differencing mask used by EXDIFF that specifies to disregard differences based on byte counts.

C...(BACK TO TOP)

• C. The programming language C. ANSI standard and K&R C are normally grouped as one language. Certain extensions supported by popular C compilers are also included as normal C.
• C++. The C++ object oriented programming language. The current standard is ANSI C++ and/or AT&T C++. Both are supported by TCAT/C++.
• C0 coverage. The percentage of the total number of statements in a module that are exercised, divided by the total number of statements present in the module.
• C1 coverage. The percentage of logical branches exercised in a test as compared with the total number of logical branches known in a program.
• Call graph. The function call tree capability of S-TCAT. This utility show caller-callee relationship of a program. It helps the user to determine which function calls need to be tested further.
• Call pair. A connection between two functions in which one function "calls" (references) the other function.
• Coding rule. A rule that specifies a particular way in which a program is to be expressed.
• Coding style. A general measure of the programming nature of a system; abstractly, the way the programming language is used in a real system.
• Combinational flow. Combinational flow is represented by a sequence of logical branches with the property that no logical branch is repeated within the flow.
• Command mode. This mode of execution of keysave files allows the user to program the keysave file in order to do conditional execution based on system calls. The other mode of execution is Data Mode. Command mode is supported by CAPBAK/X, and CAPBAK/UNIX.
• Complexity. A relative measurement of the ``degree of internal complexity'' of a software system, expressed possibly in terms of some algorithmic complexity measure.
• Complexity report. This METRIC report lists all a source code program's encountered procedures and lists Software Science metrics (which are concerned with the "size" of software) and Cyclomatic Complexity measures (which are concerned with the flow of control within the program's code). This report is also referred to as a Full report.
• Component. A part of a software system smaller than the entire system but larger than an element.
• Conditional playback. Certain STW components incorporate a language that provides for logical operations to control behavior during test execution. E.g. a SMARTS test can involve use of the if or while constructs, as can a CAPBAK script. See also Playback programming.
• Configuration file. A file used to declare start-up time parameter values. Usually suffixed as *.rc.
• Connected directed graph. A directed graph is connected if there is at least one path from every entry node to every exit node.
• Control statement. A statement that involves some predicate operation. For example: an if statement or a while statement.
• correctness proof. A mathematical process which demonstrates the consistency between a set of assertions about a program and the properties of the program, when executed in a known environment.
• Coverage testing. Coverage testing is concerned with the degree to which test cases exercise or cover the logic (source code) of the software module or unit. It is also a measure of coverage of code lines, code branches and code branch combinations.
• Cross-reference. An indication, for a selected symbol, of where instances of that symbol lie in a software system.
• Ct coverage. The percentage of independently executable sub-trees of the hierarchical decomposition tree of a program that has been exercised, in terms of all of the possible sub-trees that can be executed for that program.
• Cumulative coverage. The test coverage attained by a set of several test runs.
• Cumulative report. This TCAT or S-TCAT report charts branch and/or call-pair coverage for the current test cumulatively, and for each module in the total system.
• Cycle. A sequence of logical branches that forms a closed loop, so that at least one node is repeated.
• Cyclomatic number. A number which assesses program complexity according to a program's flow of control. A program's flow of control is based on the number and arrangement of decision statements within the code. The cyclomatic number of a flow graph can be calculated as follows

D...(BACK TO TOP)

• Data Mode. In this mode of execution of keysave files, text is interpreted as saved keystrokes to be played back along with timing information which is inclosed in brackets. The Data mode is supported by CAPBAK/X and CAPBAK/UNIX.
• DD-path. See Logical branch.
• De-instrumentation. When certain parts of your code have already been tested, you can use TCAT's and S-TCAT's de-instrumentations utilities to exclude those parts from instrumentation. For large programs, this can save time.
• Debug. After testing has identified a defect, one "debugs" the software by making certain changes that repair the defect.
• Decision node. A node in the program directed graph which corresponds to a decision statement within the program.
• Decision statement. A decision statement in a module is one in which an evaluation of some predicate is made, which (potentially) affects the subsequent execution behavior of the module.
• Decision-to-decision path. See Logical branch.
• Decisional depth. The number of decisions that must take on a particular value prior to arriving at a specified logical branch. "The decisional depth for this logical branch is..."
• Defect. Any difference between program specifications and actual program behavior of any kind, whether critical or not. What is reported as causing any kind of software problem.
• Deficiency. See Defect.
• Delay multiplier. The multiplier used to expand or contract playback rates.
• Directed graph. A directed graph consists of a set of nodes which are interconnected with oriented arcs. An arbitrary directed graph may have many entry nodes and many exit nodes. A program directed graph has only one entry and one exit node.
• Dynamic analysis. A process of systematically demonstrating properties of programs by a series of constructed executions. The STW/Coverage suite of tools performs dynamic analysis.
• Dynamic call-tree display. An organic diagram showing modules and their call-pair structure, where the call-pairs are "animated" based on behavior of the instrumented program being tested.
• Dynamic directed graph display. An organic diagram showing the connection between logical branches in a program, where the logical branches are "animated" based on behavior of the instrumented program being tested.

E...(BACK TO TOP)

• Edge. In a directed graph, the oriented connection between two nodes.
• End-to-end testing. Test activity aimed at proving the correct implementation of a required function at a level where the entire hardware/software chain involved in the execution of the function is available.
• Entry logical branch. An entry logical branch is one which has no predecessors, a situation which can occur only at the entrance (i.e., invocation point) of a module.
• Entry node. In a program directed graph, a node which has more than one out-way and zero in-ways. An entry node has an in-degree of zero and a non-zero out-degree.
• Environment Clause. A clause in the SMARTS ATS file that defines local environment variables that can be used as variables in the activation and evaluation clauses.
• Error. A difference between program behavior and specification that renders the program results unacceptable. See Defect.
• Essential edges. The set of paths that first include each edge which is on only one of the original set of paths.
• Essential logical branch. A logical branch of a program that exists on only one path. Hence, execution of an essential logical branch is required to obtain complete segment (branch) coverage.
• Essential paths. The set of paths that include one essential edge, that is an edge that lies on no other path.
• Evaluation clause. A clause in the SMARTS' ATS file that specifies how to assess the correctness of a test.
• Event synchronization. The process by which a playback (e.g. from CAPBAK/X or CAPBAK/MSW) is forced to wait until an menu opening is completed.
• Exception report. A METRIC report which identifies source code procedures that exceed a user-defined metric threshold.
• EXDIFF. The extended differencing system, a component of STW/Regression. EXDIFF compares two files and reports the difference between them, and it ignores difference that lie within a user-defined masked area.
• Executable statement. A statement in a module which is executable in the sense that it produces object code instructions. A non-executable statement is not the opposite: it may be a declaration. Only comments can be left out without affective program behaviour.
• Execution verifier. A system to analyze the execution-time behavior of a test object in terms of the level of testing coverage attained.
• Exit logical branch. An exit logical branch is one for which there are no successor logical branches. This occurs only when the consequence of the logical branch is an exit from the module.
• Exit node. In a directed graph, a node which has more than one in-way, but has zero out-ways. An exit node has an out-degree of zero and a non-zero in-degree.
• Exit structure. The exit structure of a program directed graph is the set of logical branches which, if executed, lead unalterably to termination of program flow without involving subsequent repetition of any logical branches.
• Explicit predicate. A program predicate whose formula is displayed explicitly in the program text. For example: a single conditional always involves an explicit program predicate. A predicate is implicit when it is not visible in the source code of the program. An example is a program exception, which can occur at any time.

F...(BACK TO TOP)

• Filter. A stage in a software process that attempts to identify defects so they can be removed.
• Filter Efficiency. The percentage of state-detectable defects vs. the actual average number of defects detected. Typical filter efficiencies range from 10% (not often of much practical use) to 90% (nothing is perfect)>
• Flow control. When a terminal emulation program establishes communications with a mainframe application, it establishes flow control to prevent characters being lost. In some cases the mainframe application (or cluster controller) locks out the keyboard. This prevents the user from typing ahead; however, when CAPBAK is being used to record terminal sessions, the user is expected to wait for a response from the mainframe. The user, thus, imposes manual flow control to prevent data from being lost in cases where the keyboard is not locked. When CAPBAK is being run in terminal emulation mode, a record of the manual flow control is stored in the keysave and response files. When CAPBAK is transmitting keys in playback, flow control is maintained by using the information saved in these files. See also Automatic flow control.
• Flow graph. The oriented diagram, composed with nodes and edges with arrows, the shows the flow of control in a program. Also called a flow chart or a directed graph.
• Formal parameter. For an invocable element of program text, the set of variable names which are assigned value or meaning outside of the program text.
• Full report. A METRIC report which indicates a set of metrics for each of the modules in a given source file. See also Complexity report.
• Function call. A reference by one program to another through the use of an independent procedure-call or functional-call method. Each function call is the ``tail'' of a caller-callee call-pair.
• Function Keys. During a recording session with CAPBAK/X or CAPBAK/MSW, you can issue commands via function keys (i.e. your F1 to F10 keyboard function keys). During a recording session, you can use the function keys to bring up the Hotkey window (see Hotkeywindow), add comments to the keysave file, select an image or window for or the entire screen, pause, resume or terminate the session. CAPBAK/X also has additional function keys that allow you to synchronize on a character string or extract characters froman image or the entire screen. During playback, function keys can be used to slow or to quicken the speed of playback, to insert or to append new keysave records into a keysave file, to pause, to resume or to terminate a playback session.
• Functional specifications. A set of behavioral and performance requirements which, in aggregate, determine the functional properties of a software system.
• Functional test cases. A set of test case data sets for software which are derived from structural test cases.

G...(BACK TO TOP)

• GUI (Graphical User Interface). A interface system, e.g. X11 or Windows '95 that communicates between a user and an application.

H...(BACK TO TOP)

• Halstead metric. A measure of the complexity of computer software that is computed as
• History report. A SMARTS summary report which indicates all test outcomes maintained in the log file, providing an overview of test regression throughout the testing process.
• Hit report. This report is used by TCAT and S-TCAT to identifies all of the logical branches, call-pairs or paths which were exercised in the present and past tests. It analyzes both the trace file and archive file.
• Hotkey window. When recording a test session with CAPBAK/X or CAPBAK/MSW, this window pops up when the hotkey function key is pressed (defaulted to F1). It allows you to issue commands, including inserting comments into the keysave file, to save an image or window for synchronization, to capture an image, a window, or the entire screen, to resume, and to end a recording session.

I...(BACK TO TOP)

• Image synchronization. The process by which a playback (e.g. from CAPBAK/X and CAPBAK/MSW) holds back execution until the image or window is redrawn or found.
• In-degree. In a directed graph, the number of in-ways for a node.
• Incompatible logical branch. Two segments in one program are said to be incompatible if there is no logically feasible execution of the program which will permit both of them to be executed in the same test. See also Essential logical branch.
• Independent logical branch pair. A pair of logical branches is (sequentially) independent when there are no assignment actions along the first branch. This changes any of the variables used in the predicate of the second statement.
• Infeasible path. A logical branch sequence is logically impossible if there is no collection of setting of the input space relative to the first branch in the sequence, which permits the sequence to execute.
• Inspection/review. A process of systematically studying and inspecting programs in order to identify certain types of errors, usually accomplished by human rather than mechanical means.
• Instrumentation. The first step in analyzing test coverage, is to instrument the source code. Instrumentation modifies the source code so that special markers are positioned at every logical branch or call-pair or path. Later, during program execution of the instrumented source code, these markers will be tracked and counted to provide data for coverage reports.
• Integration Testing. Exposes faults during the process of integration of software components or software units and it is specifically aimed at exposing faults in their interactions. The integration approach could be either bottom-up (using drivers), top-down (using stubs) or a mixture of the two. The bottom up is the recommended approach.
• Interface. The informational boundary between two software systems, software system components, elements, or modules.
• Invocation point. The invocation point of a module is normally the first statement in the module.
• Invocation structure. The tree-like hierarchy that contains a link for invocation of one module by another within a software system.
• Iteration level. The level of iteration relative to the invocation of a module. A zero-level iteration characterizes flows with no iteration. A one-level iteration characterizes program flow which involves repetition of a zero-level flow.

J...(BACK TO TOP)

• Java. A programming language, not unlike C++, that is used to program applets that are interpretively executed by Java applet viewers associated with several InterNet browsers. Some say that Java := ((C++)--)++.
• Junction node. A junction node within a program directed graph is a node, which has an in-degree of two or greater, and an out-degree of exactly one.

K...(BACK TO TOP)

• Keysave file. A test script file automatically generated during the CAPBAK's recording session. A keysave file contains a sequence of event statements (including keystrokes, mouse movements and screen captures), which represent user input directed to the AU. When a test is played back, the event statements in the keysave file are regenerated and the AUT executes the previously recorded statements exactly as before.
• Kiviat chart. A graphical depiction of the metric results from the METRIC Summary report, where each metric is represented by an axis and results are plotted with reference to user-definable upper and lower bounds. The Kiviat chart quickly identifies the metrics to focus on for a particular program.

L...(BACK TO TOP)

• Length. Maurice Halstead defined the length of a program to be
• Line mask. An EXDIFF statement that permits masking a line or group of lines.
• Linear histogram. A dynamically updated linear-style histogram showing accumulating C1 or S1 coverage for a selected module.
• Log file. An established or default SMARTS file where all test information is automatically accumulated.
• Logical branch. The set of statements in a module which are executed as the result of the evaluation of some predicate (conditional) within the module. The logical branch should be thought of as including the outcome of a conditional operation and the subsequent statement execution up to and including the computation of the value of the next predicate, but not including its evaluation in determining program flow.
• Logical units. A logical unit is a concept used for synchronization when differencing two files with the EXDIFF system. A logical unit may be a line of text, a page of text, a CAPBAK screen dump, or the keys (or responses) between marker records in a keysave file.
• Loop. A sequence of logical branches in a program that repeats at least one node. See Cycle.
• (M,N)-cycle. An M-entry, N-exit cycle in a flow graph. A program is perfectly structured ("pure-structured") if it is composed of loops that involve only (1,1)-cycles. Most real-world programs contain many multi-exit cycles, however. Some studies show that over 99% of programs are non-pure-structured.

M...(BACK TO TOP)

• Make file. Most often, TCAT and S-TCAT will be used to develop test suites for systems that are created with make files. make files cut the time of constructing systems, by automating the various steps necessary to build systems, including preprocessing, instrumenting, compiling and linking. All these steps can be written in a make file.
• makeats. A SMARTS utility which, based on minimal information, generates the initial hierarchical test structure for an ATS file, as well as basic source, activation, and evaluation clauses.
• Manual analysis. The process of analyzing a program for conformance to in-house rules of style, format, and content as well as for correctly producing the anticipated output and results. This process is sometimes called code inspection, structured review, o formal inspection.
• METRIC. The software metrics processor/generator component of STW/Advisor. METRIC computes several software measures to help you determine the complexity properties of your software.
• Module. A module is a separately invocable element of a software system. Similar terms are procedure, function, or program.
• Multi-unit test. A multi-unit test consists of a unit test of a single module in the presence of other modules. It includes: (1) a collection of settings for the input space of the module and all the other modules invoked by it and (2) precisely one invocation of the module under test.

N...(BACK TO TOP)

• Node. (1) A position in a program assigned to represent a particular state in the execution space of that program. (2) Group or test case in a test tree.
• Node number. A unique node number assigned at various critical places within each module. The node number is used to describe potential and/or actual program flow.
• Non-executable statement. A declaration or directive within a module which does not produce (during compilation) object code instructions directly.
• Not hit report. A TCAT or S-TCAT report giving the names of logical branches or call-pairs "not hit" yet by any test.

O...(BACK TO TOP)

• OCR. Optical Character Recognition by Xerox Imaging Systems (XIS) provides general character recognition capabilities for CAPBAK/X.
• Out-degree. In a directed graph, the number of out-ways of a node.
• Output synchronization. The process by which a playback (e.g. from CAPBAK/X or CAPBAK/MSW) is forced to wait until an expected window opening is completed.
• Outway. In a directed graph, an arc (edge) leaving a node.
• Out-degree. In a directed graph, the number of out-ways of a node.

P...(BACK TO TOP)

• Path, path class. An ordered sequence of logical branches representing one or more categories of program flow.
• Path predicate. The predicate that describes the legal condition under which a particular sequence of logical branches will be executed.
• Past test report. This report lists information from the stored archive file for TCAT and S-TCAT. It summarizes the percentage of logical branches/call-pairs hit in each module listed, giving the C1/S1 value for each module and the program as a whole.
• Playback counter. The time interval between two keystrokes recorded or played back by CAPBAK.
• Playback delay. Minimum interval between keystrokes at playback time with CAPBAK.
• Playback mode. The CAPBAK/X or CAPBAK/MSW playback mode that validates execution and generates or updates a test's expected results.
• Playback programming. A technique in which playback behavior is controlled by the use of various system calls placed in the keysave file. Playback programming provides an easy way for a user to playback a keysave file as a script that modifies the behavior conditionally on the basis of system and environmental factors.
• Predecessor logical branches. One of many logical branches that precede a specified logical branch in normal (structurally implied) program flow.
• Predicate. A logical formula involving variables/constants known to a module.
• Predicted length. Maurice Halstead theorizes that a well-written program with n1 unique operators and n2 unique operands should have a length of
• Preview. A CAPBAK/X utility which simulates keysave file activity for you. The simulation shows the recording session's mouse movements, button and keyboard activities, and captured images.
• Process. The sequence of steps that are performed in developing a software product, system, upgrade, etc. Software processes involve multiple stages, multiple types of activities, many of which may be concurrent.
• Program. See Module.
• Program directed graph. See Directed graph.
• Program predicate. See Predicate.
• Pseudo code. A form of software design in which programming actions are described in a program-like structure; not necessarily executable but generally held to be humanly readable.
• Purity ratio. Maurice Halstead suggested that programs which are not the same length as predicted by N^ (see Predicted length) are victims of impurities. The purity ratio is the ratio of N^ to N (predicted length/length). This measurement is used by METRIC o determine error-prone parts of code.

Q...(BACK TO TOP)

• Qualification. The process that assures that a given software component at the end of its development is compliant with the requirements. The qualification shall be performed at appropriate and defined software components and sub software systems, before integrating the software to the next higher level. The techniques for qualification is testing, inspection and reviewing.
• Quick Check mode. The CAPBAK/X and CAPBAK/MSW playback mode that replays a test in order to generate a new set of AUT responses. The new responses, the actual results, are compared with earlier results, that is the expected results of the test. This mode verifies an application's behavior by automatically comparing any currently captured actual images, windows or ASCII characters with the image, window or characters that were captured and stored as the expected results.
• record. This CAPBAK/UNIX command is a program that records keystrokes being entered at a terminal and saves them in a keysave file format. It records and displays the responses from the remote machine, and saves them in a baseline file which can be used to synchronize playback.

R...(BACK TO TOP)

• Reference listing report. A report produced by TCAT and S-TCAT which shows the coverage level achieved for all modules that are named in the specified reference listing.
• Regression report. A SMARTS report which lists only the most recently executed test cases whose outcomes have changed from the previous executions. The Regression report helps to identify bugs which have been fixed or introduced since the last time the test were executed.
• Regression Testing. Testing which is performed after making a functional improvement or repair of the software. Its purpose is to determine if the change has regressed other aspects of the software. As a general principle, software unit tests are fully repeated if a module is modified, and additional tests which expose the fault removed, are added to the test set. The software unit will then be re-integrated and integration testing repeated.
• Resource file. For X Windows applications only, a file that contains a set of pre-determined values for parameters.
• Response file. A text or image file that can be compared against the baseline file.
• Return variable. A return variable is an actual or formal parameter for a module, which is modified within the module.

S...(BACK TO TOP)

• S0 coverage. The percentage of modules that are invoked at least once during a test or during a set of tests.
• S1 coverage. The percentage of call-pairs exercised in a test as compared with the total number of call-pairs known in a program. This metric is calculated by S-TCAT. By definition the S1 value for a module which has no call pairs is 100% if the module has een called at least once, and 0% otherwise.
• S-TCAT. The System Test Coverage Analysis Tool of the STW/Coverage tool group. S-TCAT measures the structural completeness of a test suite by reporting on the percentage of function call-pairs exercised.
• scover. An S-TCAT utility used to assess the value of S1 coverage.
• Segment. A [logical branch] segment or decision-to-decision path is the set of statements in a module which are executed as the result of the evaluation of some predicate (conditional) within the module. The segment should be thought of as including the outcome of a conditional operation and the subsequent statement execution up to and including the computation of the value of the next predicate, but not including its evaluation in determining program flow.
• Segment instrumentation. The process of producing an altered version of a module which is logically equivalent to the unmodified module but which contains calls to a special data collection subroutine which accepts information as to the specific logical branch sequence incurred in an invocation of the module.
• Software sub-system. A part of a software system, but one which includes many modules. Intermediate between module and system.
• Software system. A collection of modules, possibly organized into components and subsystems, which solves some problem or performs some task.
• Source clause. A clause in the ATS file that contains comments which may give some explanation to the origin of the test(s) invoked in each particular case. Most commonly the source clause is used to specify the purpose of a test. The comments in a source cause are displayed by SMARTS when a test case activation is evaluated as a test failure: This allows you to note which files need to be inspected.
• Spaghetti code. A program whose control structure is so entangled by a surfeit of GOTO's that is flow graph resembles a bowl of spaghetti.
• Statement complexity. A complexity value assigned to each statement which is based on (1) the statement type, and (2) the total length of postfix representations of expressions within the statement (if any). The statement complexity values are intended to represent an approximation to potential execution time.
• Static analysis. The process of analyzing a program without executing it. This may involve wide range of analyses. The STW/Advisor suite of tools performs static analyses.
• Static frequency. Forced constant CAPBAK playback rate.
• Status report. This SMARTS' report presents the most recent information about executed tests. It contains: test case name, outcome (pass/fail), activation date, execution time (seconds), and error number.
• Sub-test. A part of a test that occurs between passing control to the test object and the return of control to the test environment.
• Successor logical branch. One or more logical branches that (structurally) follow a given logical branch.
• Summary report. A METRIC report indicates the accumulated complexity measures for the entire AUT.
• Synchronization. During playback of a test script, e.g. with CAPBAK/X, there are several ways that the playback process can behave to avoid loss of synchronization, among them "output synchronization" and "image synchronization".
• System Testing. Verifies that the total software system satisfies all of its functional, quality attribute and operational requirements in simulated or real hardware environment. It primarily demonstrates that the software system does fulfill requirements specified in the requirements specification during exposure to the anticipated environmental conditions. All testing objectives relevant to specific requirements should be included during the software system testing. Software system testing is mainly based on black-box methods. The STW/Coverage suite of tools supports this type of testing.

T...(BACK TO TOP)

• TCAT. The Test Coverage Analysis Tool of the STW/Coverage tool group. TCAT measures the thoroughness of your test case coverage by reporting on the percentage of logical branches exercised.
• TDGEN. The Test Data Generator System which is a component of the TestWorks product line. TDGEN produces test data files in a user-designed format by replacing variable fields in a template file with random or sequential data values from a values file.
• Template file. A user-designed TDGEN file which indicates where selected values are to placed within an existing test file. A template file provides a format for the generation of additional test.
• Termination clause. A SMARTS clause that is executed when a special termination command fails to complete normally.
• Test. A [unit] test of a single module consists of (1) a collection of settings for the inputs of the module, and (2) exactly one invocation of the module. A unit test may or may not include the effect of other modules which are invoked by the undergoing teting.
• Test Bed. See Test Harness.
• Test coverage measure. A measure of the testing coverage achieved as the result of one unit test usually expressed as a percentage of the number logical branches within a module traversed in the test.
• Test data set. A specific set of values for variables in the communication space of a module which are used in a test.
• Test harness. A tool that supports automated testing of a module or small group of modules.
• Test object, object under test. The central object on which testing attention is focused.
• Test path. A test path is a specific (sequence) set of logical branches which is traversed as the result of a unit test operation on a set of test case data. A module can have many test paths.
• Test purpose. The free-text description indicating the objective of a test, which is usually specified in the source clause of a SMARTS ATS file.
• Test stub. A testing stub is a module which simulates the operations of a module which is invoked within a test. The testing stub can replace the real module for testing purposes.
• Test target. The current module (system testing) or the current logical branch (unit testing) upon which testing effort is focused.
• Test target selector. A function which identifies a recommended next testing target.
• Testability. A design characteristic which allows the status (operable, inoperable, or degrade) of a system of any of its sub-system to be confidently determined in a timely fashion. Testability attempts to qualify those attributes of system designs which facilitate detection and isolation of faults that affect system performance. Testability can be defined as the characteristic of a design which allows the status of a system of any of its subsystems to be confidently determined in a timely fashion.
• Testing. Testing is the execution of a system in a real or simulated environment with the intent of finding faults.
• Testing Techniques. Can be used in order to obtain a structured and efficient testing which covers the testing objectives during the different phases in the software life cycle.
• Top-Down Testing. The testing starts with the main program. The main program becomes the test harness and the subordinated units are added as they are completed and testing continues. Stubs must be created for units not yet completed. This type of testing results in retesting of higher level units when more lower level units are added. The adding of new units one by one should not be taken too literary. Sometimes a collection of units will be included simultaneously, and the whole set of units will serve as test harness for each unit test. Each unit is tested according to a unit test plan, with a top-down strategy.
• Trace file. A file containing the most recent test run of trace coverage information for STW/Coverage's TCAT tool.
• True time recording. The capability of CAPBAK to record complete timing information about the CAPBAK session in such a way that it can be played back at identically the same rate it was recorded. feasible path" A sequence of logical branches is logically possible if there is a setting for the input space relative to the first logical branch in the sequence, which permits the sequence to execute.

U...(BACK TO TOP)

• Unconstrained paths. The set of edges that will imply execution of other edges in the program.
• Unit test. See Test.
• Unit Testing. Unit testing is meant to expose faults on each software unit as soon as this is available regardless of its interaction with other units. The unit is exercised against its detailed design and by ensuring that a defined logic coverage is performed. Informal tests on module level which will be done by the software development team and are informal tests which are necessary to check that the coded software modules reflect the requirements and design for that module. White-box oriented testing in combination with at least one black box method are used.
• Unreachability. A statement (or logical branch) is unreachable if there is no logically obtainable set of input-space settings which can cause the statement (or logical branch) to be traversed.

V...(BACK TO TOP)

• Validation. The process of evaluation software at the end of the software development process to ensure compliance with software requirements. The techniques for validation is testing, inspection and reviewing.
• Values file. A user-designed TDGEN file which indicates the actual test values, test value ranges or test value generation rules for the creation of additional test files.
• Verification. The process of determining whether of not the products of a given phase of the software development cycle meet the implementation steps and can be traced to the incoming objectives established during the previous phase. The techniques for verification are testing, inspection and reviewing.
• Vertex. See Node.

W...(BACK TO TOP)

• White-box testing. A test method where the tester views the internal behavior and structure of the program. The testing strategy permits one to examine the internal structure of the program. In using this strategy, the tester derives test data from an examination of the program's logic without neglecting the requirements in the specification. The goal of this test method is to achieve a high test coverage, that is examination of as much of the statements, branches, paths as possible.

X...(BACK TO TOP)

• X11 Virtual Display. Simulates multiple-user sessions from the same machine for the purposes of lad generation, performance assessment, and multiple-test execution.

Y...(BACK TO TOP)

Z...(BACK TO TOP)