Method for merging white box and black box testing

• US 20030046029A1
• Filed: 09/05/2001
• Published: 03/06/2003
• Est. Priority Date: 09/05/2001
• Status: Abandoned Application

• Current Assignee: CorTechs, Inc.
• Original Assignee: CorTechs, Inc.
• Inventors: Wiener, Jay Stuart, Calco, Robert Becka
• Application Number:
  US09/946,282
• Publication Number:
  US 20030046029A1
• Time in Patent Office: Days
• US Class Current: 702/186
• CPC Class Codes: G06F 11/3672 Test management

Abstract

A method and process for developing and testing software applies runtime executable patching technology to enhance the quality assurance effort across all phases of the Software Development Life-Cycle in a “grey box” methodology. The system facilitates the creation of re-usable, Plug‘n’Play Test Components, called Probe Libraries, that can be used again and again by testers as well as developers in unit and functional tests to add an extra safety net against the migration of low-level defects across Phases of the overall Software Development and Testing Life-Cycle. The new elements introduced in the Software Development Life-Cycle focus on bringing developers and testers together in the general quality assurance workflow and provide numerous tools, techniques and methods for making the technology both relatively easy to use and powerful for various test purposes.

Claims

1. A method for merging white box and black box testing of software applications during and after the development phase, comprising the steps of:

a. analyzing the performance of an application to determine functionality prior to release;

b. performing a black box test on the application;

c. simulating white box test conditions during black box testing.

2. The method of claim 1, wherein the simulating step comprises patching a command line in the source code of the application to bypass an error.

3. The method of claim 1, wherein the performing step occurs during development of the application and simultaneously with white box testing.

4. The method of claim 3, further comprising an iterative step of updating the white box test in response to black box test analysis and updating the black box test in response to white black test analysis.

5. The method of claim 1, further comprising the step of generating probe libraries in response to test analysis.

6. The method of claim 5, wherein said probe libraries contain white test probes.

7. The method of claim 5, wherein said probe libraries contain black test probes.

8. The method of claim 5, wherein said probe libraries contain reusable test probes.

9. The method of claim 1, wherein steps a, b and c are performed in combination with white box testing.

10. The method of claim 1, wherein steps a, b and c are performed independently of white box testing.

11. A method for iterative testing of software during the development cycle by communicating between development and testing phases for defining a grey box test regimen, comprising the steps of:

a. providing a requirements document to a development phase and a testing phase;

b. generating a test case based on the requirements document;

c. utilizing plug‘

n’

play probes to test the software;

d. communicating errors and deficiencies to the development cycle based on performance under the test case using the probes.

12. The method of claim 11, wherein the probes are saved in a library for reuse.

13. The method of claim 12, wherein the probes are generic and may be utilized with a plurality of software systems.

14. The method of claim 12, including the step of customizing the probes for use in connection with the testing of a particular software system.

15. A method for iterative testing of software applications during development, comprising the steps of:

a. creating a test project by selecting a program to be tested;

b. selecting a repository for the program;

c. defining a target for each primary executable of the program;

d. stripping debug information into a local format;

e. identifying probe entry points in the program;

f. creating a probe library for use against the target;

g. adding driver scripts;

h. defining and generating a test case;

i. creating a test case;

j. combining the test case into a test set;

k. running the test in accordance with the test case and test set;

l. analyzing the results;

m. repeating the test.

16. The method of claim 15, further including the step of generating a report.

17. The method of claim 15, further including the step of adding additional users after step b.

18. The method of claim 15, further including the step of linking to an external test repository after step b.

19. The method of claim 15, step d further including the step of stripping debugging information into a local format.

20. The method of claim 15, step e further including the steps of:

a. indicating DLLs;

b. verifying debug information;

c. noting modular dependencies.

21. The method of claim 15, step f further including the step of using an available probe library.

22. The method of claim 15, step f further including the step of creating an custom probe library.

23. The method of claim 21, wherein the selected probe library is a utility probe library.

24. The method of claim 23, including the additional steps of:

a. identifying typdef probes to be deployed with the utility probe library;

b. defining the typdef probe-level variables that affect instrument at rules of each function instrumented.

25. The method of claim 16, including the additional steps of:

a. defining all probe library-level variable inputs;

b. defining inpout parameters appropriate to the probe library.