- State transition diagrams,
- Decision tables and
- Activity diagrams.
Thursday, July 5, 2012
Describe test design techniques like: State-transition diagrams, Decision tables, Activity diagrams.
Posted by
Sunflower
at
7/05/2012 11:00:00 PM
0
comments
Labels: Actions, Activity Diagrams, Application, Conditions, Decision Tables, Diagrams, Finite, Graphs, Logic, Relation, Semantics, Software System, Software testing, State transition Diagram, States, Techniques, Test Design
|
| Subscribe by Email |
|
Monday, July 25, 2011
Designing Conventional Components- Graphical Design Notation and Tabular Design Notation
A set of constrained logical constructs that emphasize on maintenance of functional domain are used for designing conventional components. These logical constructs are sequence, condition, and repetition. Structured programming is a design technique that constrains logic flow to three constructs: sequence, condition, and repetition. These structured constructs help in reducing the complexity of the program and enhances readability, test ability and maintainability.
GRAPHICAL DESIGN NOTATION
- Activity diagram is a descendant of flowchart in which all elements of structured programming are represented.
- In a flowchart, each step in the process is represented by a different symbol and contains a short description of the process step.
- Structured programming constructs should make it easier to understand the design. If unnecessary complexity is introduced by using them without violation, it is better ti violate them.
- Dogmatic use of structured constructs introduces inefficiency.
TABULAR DESIGN NOTATION
- Decision tables translates actions and conditions into a tabular form.
- A decision table is used when a complex set of conditions and actions are encountered within a component.
- Decision table is divided into four quadrants. Upper left quadrant lists all conditions. Lower left quadrant lists all actions. Right hand quadrants form a matrix indicating condition combinations and corresponding actions
Posted by
Sunflower
at
7/25/2011 07:25:00 PM
0
comments
Labels: Component based development, Components, Conditions, Decision Tables, Flowchart, Graphical Design Notation, Logical, Repetitive, Sequences, Structured constructs, Tabular Design Notation
|
| Subscribe by Email |
|
Tuesday, May 31, 2011
What are different startegies for black box testing?
Writing and executing test cases is an expensive task. Whatever test case is written, it should hint towards a different mode of failure. Testing strategies for black box testing are:
- Customer Requirements tests
Requirements are very important for black box testing. Each and every customer requirement should be tested. To do this, every requirement is traced to its test case and every test case to its customer requirement. The first test case is to write a most used success path ( a path that is error condition free) and proceed by planning more success paths. Some failure paths (a path that has errors in it) are also planned. Execution of tests is done so that risky requirements are tested first. It would give more time to fix the errors before the product delivery.
- Equivalence Partitioning
It is a strategy that reduces the number of test cases that are needed to be developed. The input domain is divided into classes. Test cases should be designed so that the inputs lie within these equivalence classes. For each equivalence class, set of data should be treated same by the module under test and should produce same result.
- Boundary Value Analysis
Mistakes generally occur at boundaries of the equivalence classes. Boundary value analysis guides you to create test cases at the boundaries of equivalence classes. Boundary value is defined as a value that relates to a minimum or maximum input.
- Decision Table Testing
To record business rules, decision tables are used. In decision tables, conditions represents input conditions, actions represent events that should trigger. Each column in table is a unique combination of input condition resulting in initiating an action associated with rule. Each rule or column becomes a test case.
- Failure Test Cases
The program or the application should be robust which means that it should respond properly in case or erroneous user input.
Posted by
Sunflower
at
5/31/2011 01:58:00 PM
0
comments
Labels: Black box testing, Boundary Value Analysis, Customer, Decision Tables, Equivalence Partitioning, Errors, Failure, Quality, Requirements, Software testing, Strategies, Test cases
|
| Subscribe by Email |
|