Error detection/correction and fault detection/recovery – Data processing system error or fault handling – Reliability and availability
Reexamination Certificate
1999-07-15
2004-04-20
Beausoleil, Robert (Department: 2184)
Error detection/correction and fault detection/recovery
Data processing system error or fault handling
Reliability and availability
C717S124000
Reexamination Certificate
active
06725399
ABSTRACT:
BACKGROUND OF THE INVENTION
1. Field of the Invention
This invention relates to a method of testing computer software and in particular to a non invasive method for evaluating the effectiveness of computer software to perform the functions desired by the business user. The testing method of this invention is particularly suited for determining the level of effectiveness achieved by a computer program or software when tailored to a business requirement.
2. Description of the Prior Art
Within the advent of computer software for many different domestic, commercial and industrial uses a need has grown to test that software to determine whether it will achieve its intended or desired purpose. Certain software programs are sufficiently complex that separate computer software is needed to test and evaluate whether a special purpose program will perform satisfactorily under the conditions present in a specific user situation.
For example, in U.S. Pat. No. 5,651,111 there is described a procedure where the program source code is invaded to generate a complementary source code which includes external dependencies. The testing method, then, translates the source code and complementary code to produce a machine-executable program for testing the source code.
In U.S. Pat. No. 5,758,061 an automatic testing technique generates an incremental coverage report for portions of the program that have been unreached by previous testing procedures. In that patent there is described a procedure whereby a computer program is “parsed” and instrument code is inserted in appropriate parts of the program. When the program is executed, the instrument code causes coverage results to be generated and stored. The output then is used to specify the value of a current test.
These types of procedures require access to the source code. However, when computer software is purchased the seller often does not provide access to source code because such code is proprietary. Therefore the purchaser must rely on testing procedures performed by the seller.
In unit testing, test data and various inputs to simulate various conditions under which the unit of software may operate are used. Test data are developed and a corrective action may be taken in response to test results. In integration testing software units are incrementally combined until the complete software system and the resulting integrated machine-executable programs are tested. Integration testing may involve integration of data, executable code and test result. As described in U.S. Pat. No. 5,651,111, in integration testing as in unit testing a machine-executable program is executed and the run time output or results are examined as a way to verify the correct functioning of the program being tested. Therefore, the external dependency problem of unit testing also exists for integration testing. In other words, in such testing, it is necessary to duplicate business external conditions under which the software may be expected to be called upon to function.
In U.S. Pat. No. 5,600,789 a method for automated testing of computer application programs using a Graphic User Interface is described. Simulated user events such as keyboard or mouse actions are automatically inputted into the interface which is then monitored to observe changes in response to the input.
In that method, inputs to the interface that simulate user events, such as keyboard or mouse action, are provided and the changes to the interface in response to the input are observed. The simulated user input is described as appearing exactly as if the input came from the user. A test script is written in a high level programming language and contains the events to be simulated. The script is then executed and a driver is used to take specific references and perform the actual interface to Graphical User Interface objects: Logical Screen Elements are identified and are the objects used to interface with the user. The simulated user input is sent to the graphical user interface directed at a particular Logical Screen Element. Validation, then, concerns whether the Logical Screen Element has accepted the user and entered the expected state.
The test script is described as being written in a language called “T”, although any appropriate programming language could be used.
There remains a need however for a procedure for testing both new and revised computer application programs which is independent of any specific testing tool, operating system or technical platform to direct testing activity to determine the feasibility or practicality of the use of a specific program at the user level. There is a need for determining whether a program which has been cleared by the vendor through unit and integration or other testing will adequately meet the end users needs when subjected to realistic, rather than technical, conditions.
SUMMARY OF THE INVENTION
It has been discoverd that the end user requirements for a software program can be efficiently and reliably evaluated against a software program using actual production measurements and related information. The procedure of this invention, then, not only can determine how well a product has been tested by the vendor and/or creator, but rather if the product will reliably meet the user requirements in performing specific functions, and the quality of the performance. The process of this invention provides evaluation in a succession of six key process areas leading from creation of an initial test plan through a management report on the readiness of the software under test for production service.
In the first key process area a test plan is created which defines the scope of the software test, the approach to complete the test, resources required and the acceptance criteria for the test.
The second key process area is test case development where in the test cases that support the plan are created to validate software functions.
Third key process area is test environment preparation which is used to establish a controlled technical environment for the application of the test cases. The controlled environment simulates a business environment in which the application programs will operate so that results are not skewed by technical environment variables.
The fourth key process area is test execution wherein the test cases defined in the second key process area are executed in the technical environments defined in the third key process area.
The fifth key process area is results analysis wherein a review identifies the areas of the software that need to be repaired and ultimately re-tested and the collection and analysis of metrics used to measure the software system's readiness as defined in the test plan are collected.
Finally, the sixth key process area is a management reporting function, wherein the readiness of the software system as measured by the test results collected in the fifth key process area is communicated to management.
The proper combination of the above key process areas will provide the information necessary for an organization to identify and potentially eliminate defects from software before it is implemented in a production environment.
Accordingly, it is an object of this invention to produce a non-invasive procedure for software testing to determine efficiently whether the software will meet the end user's requirements.
It is another object of this invention to provide a method for testing software wherein previously designed software is evaluated against a user's specific requirements and a determination made based upon testing specific activities on a percentage pass/fail basis to determine if a software program is suitable for a specific set of requirements.
It is yet another object of this invention to provide a software testing methodology wherein specific functions to be performed can be evaluated without altering source code or rewriting the same whereby a requirement based evaluation process is used.
REFERENCES:
patent: 5600789 (1997-02-01), Parker et al.
patent: 5651111 (1997-07-01), McKeeman et al.
patent: 5742754 (1998-
Beausoleil Robert
Compuware Corporation
Fenwick & West LLP
Wilson Yolanda L.
LandOfFree
Requirements based software testing method does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Requirements based software testing method, we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Requirements based software testing method will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-3272037