Please enable JavaScript.
Coggle requires JavaScript to display documents.
test technique - Coggle Diagram
test technique
-
Black-box Test
Techniques
Decision Table
Testing
A full decision table has enough columns (test cases) to cover every combination of conditions. By deleting columns that do not affect the outcome, the number of test cases can decrease considerably.
The common minimum coverage standard for decision table testing is to have at least one test case per decision rule in the table. This typically involves covering all combinations of conditions. Coverage is measured as the number of decision rules tested by at least one test case, divided by the total number of decision rules, normally expressed as a percentage
When creating decision tables, the tester identifies conditions (often inputs) and the resulting actions (often outputs) of the system
The strength of decision table testing: is that it
helps to identify all the important combinations of conditions, some of which might otherwise be overlooked.
helps in finding any gaps in requirements.
-
applied to all situations in which the behavior of the software depends on a combination of conditions, at any test level
State Transition
Testing
A state transition table shows all valid transitions and potentially invalid transitions between states, the events, and resulting actions for valid transitions. State transition diagrams show only the valid transitions and exclude the invalid transitions
Tests is designed to cover a typical sequence of states, to exercise all states, to exercise every transition, to exercise specific sequences of transitions, or to test invalid transitions
A transition is initiated by an event (e.g., user input of a value into a field). The event results in a transition. The same event can result in two or more different transitions from the same state
State transition testing is used for menu-based applications and is widely used within the embedded software industry
A state transition diagram shows the possible software states,
how the software enters, exits & transitions between states
The concept of a state is abstract – it may represent a few lines of code or an entire business process
Coverage is measured as the number of identified states or transitions tested, divided by the total number of identified states or transitions in the test object, normally expressed as a percentage
Boundary Value
Analysis
Behavior at the boundaries of equivalence partitions is more likely to be incorrect than behavior within the partitions
both specified and implemented boundaries may be displaced (dich chuyen) to positions above or below their intended positions, may be omitted altogether (bo qua), or may be supplemented (bo sung) with unwanted additional boundaries.
an extension of equivalence partitioning, but can only be used when the partition is ordered, consisting of numeric or sequential data. The minimum and maximum values (or first and last values) of a partition are its boundary values
Boundary value analysis and testing will reveal (tiet lo) almost all such defects by forcing the software to show behaviors from a partition other than the one to which the boundary value should belong.
-
-
Boundary coverage for a partition is measured as the number of boundary values tested, divided by the total number of identified boundary test values, normally expressed as a percentage.
use case
testing
A use case is described by interactions, activities,
preconditions, postconditions and natural language where appropriate
Each use case specifies some behavior that a subject can perform in collaboration with one or more actors
Interactions between the actors and the subject results in changes to the state of the subject. Interactions are represented graphically by work flows, activity diagrams, or business process models.
Use cases are associated with actors (human users, external hardware, or other components or systems) and subjects (the component or system to which the use case is applied)
A use case include possible variations of its basic behavior, exceptional behavior & error handling (system response and recovery from programming, application and communication errors, e.g., resulting in an error message)
Tests can be derived from use cases, which are a specific way of designing interactions with software items. They incorporate requirements for the software functions
Tests are designed to exercise the defined behaviors (basic, exceptional or alternative, and error handling)
Coverage can be measured by the number of use case behaviors
tested divided by the total number of use case behaviors, normally expressed as a percentage
-
white-box test
technique
-
-
used at all test levels, but are most commonly
used at the component test level
-
-