Browse Prior Art Database

System and method for quick error locating based on run time graph in testing automation

IP.com Disclosure Number: IPCOM000202010D
Publication Date: 2010-Dec-01
Document File: 7 page(s) / 201K

Publishing Venue

The IP.com Prior Art Database

Abstract

This paper proposed a solution to precisely locate the error location based on the run time graph of the overall test cases with the execution result of each verify point in the test cases. This method helps testers to grasp more information of the testing process during the automated black-box testing, and helps testers to automatically obtain error location (code level info) at the time of reporting the defects.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 30% of the total text.

Page 01 of 7

System and method for quick error locating based on run time graph in testing automation

The traditional automation testing process is a black-box testing. Testers have no means to analyze the source code to learn more about the internal logics of the program under testing. As a tester, he is not able to and also should not debug and analyze the problem with the whole development environment installed just as a developer does. Reading source code or debugging is not his responsibility at all. But how can he obtain detailed information without reading source code or debugging and show information related to defect in more detail(inside the program aka code level) to developers, which can greatly reduce the cost of communication and code debugging for developers? This is a dilemma.

Normally in a round of the test buckets running,

                                tester will submit all the potential error-prone test cases and obtain the results to analyze. Due to the lack of internal principle information of the program under test and when encountering defects testers are only able to understand and analyze the problem from outside (in the test case level with the outcome phenomena of the problem), it is very hard for tester to do precise locate for the problem from inside. In another word, it can be seen that, by no means can the tester locate the error in source code level while this should be the most key and helpful information for developer to quickly fix it. Current solution is that, when a problem is found during the execution of test cases, the following steps should be performed to open a defect:
1). Describe the recreate steps of the defect.
2). Identify and extract the part of log about the error from the whole log history.
3). Save the snapshot.
4). Organize all the information and send it to developer in Clear Quest (or other defect management system).

The current solution has below shortcomings:
1)Opening a defect requires too much literal words and collecting, analyzing work by the tester.

test log,

screen snapshot to describe the problem together with the tester's analysis. It is not only big workload, but also it is very hard for tester to do precise analyze and locate error in the black box testing. It wastes much time both for tester and developer to write and read the whole bunch of description. And the information provided by tester may not be the most relevant or helpful one and may lead to confusion.

Normally tester needs to collect other materials such as test case script,

No code level information about the reported problem can be obtained for the defects while

2)this kind of information is most critical for developer's quick error locating.
3)Without code level information which is related to the problem, it is hard to dispatch the defect to the correct developer when creating it.

till it goes

1

Normally it needs several re-route

to the responsible developer finally.

It can be seen that a method is highly required for testers to grasp more infor...