Download Project Report OCR PDF

TitleProject Report OCR
File Size479.0 KB
Total Pages50
Table of Contents
                            COST- BENEFIT ANALYSIS
OCR system needs textual scanned Image as the input.

White box Testing: was used as an important primary testing approach. Code is tested using code   scripts, drivers, stubs, etc. which are employed to directly interface with it and drive the code. The tester can analyze the code and use the knowledge about the structure of a component to derive test data. This testing is based on the knowledge of structure of component (e.g. by looking at source code). The advantage is that structure of code can be used to find out how many test cases needed to be performed. Knowledge of the algorithm (examination of the code) can be used to identify the equivalence partitions. Path testing is where the tester aims to exercise every independent execution path through the component. All conditional statements tested for both true and false cases. If a unit has n control statements, there will be up to 2n possible paths through it. This demonstrates that it is much easier to test small program units than large ones. Flow graphs are a pictorial representation of the paths of control through a program (ignoring assignments, procedure calls and I/O statements). We use a flow graph to design test cases that execute each path. Static tools may be used to make this easier in programs that have a complex branching structure. Dynamic program analyzers instrument a program with additional code. Typically this will count how many times each statement is executed. At end, print out report showing which statements have and have not been executed.
Possible methods:
Usual method is to ensure that every line of code is executed at least once.
Test capabilities rather than components (e.g. concentrate on tests for data loss over ones for screen layout).
Test old in preference to new (users less affected by failure of new capabilities).
Testing needs to be planned to be cost and time effective. Planning is setting out standards for tests. Test plans set the context in which individual engineers can place their own work. Typical test plan contains:
Typical levels of testing in our system:
Unit -procedure, function, method
Module -package, abstract data type
Sub-system - collection of related modules, method-message paths
Acceptance Testing - whole system with real data(involve customer, user , etc)
Incremental program development:
As program becomes more complex, changes have a tendency to introduce unexpected effects. Incremental programming tries to isolate the effects of changes. We add new features in preference to adding new functions, and add new function rather than writing new programs. The program implementation model becomes:
define types/compile/fix;
add load and dump functions/compile/test;
add first processing function/compile/test/fix;
add features/compile/test/fix;
add second processing function/compile/test/fix;
keep adding features/and compiling/and testing/ and fixing.

Similer Documents