Testing against specification of system or component. Study it by examining its inputs and related outputs. Key is to devise inputs that have a higher likelihood of causing outputs that reveal the presence of defects. Use experience and knowledge of domain to identify such test cases. Failing this a systematic approach may be necessary. Equivalence partitioning is where the input to a program falls into a number of classes. E.g. positive numbers vs. negative numbers. Programs normally behave the same way for each member of a class. Partitions exist for both input and output. Partitions may be discrete or overlap. Invalid data (i.e. outside the normal partitions) is one or more partitions that should be tested. Test cases are chosen to exercise each portion. Also test boundary cases (atypical, extreme, zero) since these frequently show up defects. For completeness, test all combinations of partitions. Black box testing is rarely exhaustive (because one doesn't test every value in an equivalence partition) and sometimes fails to reveal corruption defects caused by "weird" combination of inputs. Black box testing should not be used to try and reveal corruption defects caused, for example, by assigning a pointer to point to an object of the wrong type. Static inspection (or using a better programming language!) is preferable for this.

White-box (structural) Testing:

Testing based on knowledge of structure of component (e.g. by looking at source code). Advantage is that structure of code can be used to find out how many test case need 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). Use 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. Tools support. 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. Problems with flow graph derived testing:

> Data complexity not taken into account.

> Does not test all paths in combination.

> Really only possible at unit and module testing stages because beyond that complexity is too high.

Interface testing:

Usually done at integration stage when modules or sub-systems are combined. Objective is to detect errors or invalid assumptions about interfaces between modules. Reason these are not shown up in unit testing is that test case may perpetuate same incorrect assumption made by module designer. Particularly important when OO development has been used. Four types of interface:

1. Parameter: data (or occasionally function references) passed from one unit to another.

2. Shared memory: block of memory shared between units (e.g. global variable) .One places data there and the other retrieves it.

3. Procedural: object-oriented or abstract data type form of interface, encapsulating several procedures.

4. Message passing: one sub-system requests a service by passing a message. Client-server interface also used by some OO architectures.

Three common kinds of interface error:

> Interface misuse: caller gives wrong number/types/order of parameters or sends invalid message.

> Interface misunderstanding: caller misunderstanding specification of called component and provides or receives data in legal but unexpected form.

> Timing errors: producer/consumer of data operate at different speeds and data is accessed before being ready. "Race conditions".

Common manifestations are when each unit assumes the other one is checking for invalid data (failure to check return status) and the consequences of when such a fault is propagated to other units.

This site is designed to help BCA MCA student to develop final project and synopsis Download Free BCA Project, MCA Project, IT Projects, Final report and Project synopsis with Full documentation and code

Free download MCA projects in ASP.NET with documentation, Free download MCA projects in VB.NET with documentation, Free download MCA BSc CS projects in C#.NET with documentation,

Free download MCA projects in JAVA with documentation, Free download MCA projects in PHP with documentation, Free Download MCA BTech BE MSc BSc IT CS projects in PHP with MY SQL

Free Download BCA Final Year Project Synopsis, Free Download BCA Final Year Project Report, Free Download MCA Final Year Project Synopsis, Free Download MCA Final Year Project Report