Chapter 4 Flashcards
Test Techniques
Dynamic Testing
Analysis → what to test
Design → how to test
- Used in test analysis, test design and test implementation activities
- Depends on context, test maturity and development maturity
- Help in identifying
- Test conditions
- Test Cases
- Test Procedures
Black Box or Behavioral-based
- Don’t care about the code
- Based on an Analysis of the appropriate ttest basis
- SRS → software requirements document
- BRD → business requirements document
- FRD → functional requirements document
- Non-functional requirement document
Common characteristics of black-box test techniques include the following:
• Test conditions, test cases, and test data are derived from a test basis that may include software
requirements, specifications, use cases, and user stories
• Test cases may be used to detect gaps between the requirements and the implementation of the
requirements, as well as deviations from the requirements
• Coverage is measured based on the items tested in the test basis and the technique applied to
the test basis
White Box or Structural or Architectural
- Understand the programming language
- Internal structure
- Code
- Software architectural
- We care about the processing
Experience-based
- Understand
- Knowledge and experience
- No documentation
What is the definition of “test technique”?
→ A procedure used to define test conditions, design test cases, and specify test data
“Use cases’ are examples of test basis for
→ Black-box test technique
“Knowledge of testers and developers” is one of the test basis for
→ Experience-based test technique
Which one of the following options is categorized as a black-box test technique?
→ Techniques based on formal requirements
Black Box Techniques
- Test condition, test cases and test data are derived from a test basis
- -Software requirements
- Specifications
- Use cases
- User Stories
- Equivalence Partitioning
- All testing levels
- Divide (partition)
- Also known as equivalence classes
- Execute representatives from ALL equivalence partitions
- If one condition in a partition works we assume they all work
- Invalid equivalence partitions should be tested individually
- Partitions are called equivalence classes
- Partition that contains values is called a valid equivalence partition
- Partition that contains invalid values is called an invalid equivalence partition
- Each value must belong to one and only one equivalence partition
- Any partition may be divided into sub-partitions if required
To achieve 100% coverage with this technique, test cases must cover all identified partitions (including
invalid partitions)
- Boundary-value Analysis
- We need two test cases per boundary
- A place between two partition
- Is an extension of equivalence partitioning, but can only be used when the partition is ordered. The minimum and maximum values of partition are its boundary values.
- Some variations of this technique identify three boundary values per boundary: the values before, at, and just over the boundary
- Analysis can be applied at all test levels
- Generally used to test requirements that call for a range of numbers
- Is measured as the number of boundary values tested, divided by the total number of identified boundary test values.
2-value
Boundary
- Focused on testing at the minimum and maximum values of each partition
- Take:
- The min and max (boundary) values of each valid partition
- The first or last value respectively in each of the invalid partitions bordering the valid partition
3-value
Boundary
- Full boundary value
- Focused on testing at the boundaries between partitions PLUS both one value on either side of each boundary (as close as you can get)
- Decision Table Testing
- Each column corresponds to a decision rule that defines a unique combination of conditions which results in the execution of the actions associated with that rule
- The value of the conditions and actions are usually shown as Boolean values (true or false) or discrete values (red, green and blue)
- The common minimum coverage standard for decision table testing is to have at least one test case per decision rule in the table.
- Coverage is measured as the number of decision rules tested by at least one test case, divided by the total number of decision rules
- State Transition Testing
- Used when an aspect of the system is in a ‘finite state machine’
- Limited number of states
- State is determined by the rules of the machine
- State transition diagram shows the possible software states, as well as how the software enters, exists, and transitions between states
- A transitions is initiated by an event. The event results in a transition
- The state change may result in the software taking an action
- A state transition table shows all valid transitions and potentially invalid transitions between states
- State transition diagrams normally show only the valid transitions and exclude the invalid transitions
- Tests can be designed to cover a typical sequence of states, to exercise all states, to exercise every transition, to exercise specific sequences of transitions
- Coverage is commonly 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.
States are the squares
Transitions are the lines
- Use Case Testing
- Are associated with actors (human users, external hardware) and subjects (the component or system)
- Each use case specifies some behavior that a subject can perform in collaboration with one or more actors
- A use case can be described by interactions and activities, as well as preconditions, postconditions and natural language
- A use case can include possible variations of its basic behavior
- Tests are designed to exercise the defined behaviors
- Coverage can be measured by the percentage of use case behaviors tested divided by the total number of use case behaviors, normally expressed as a percentage
Tests are designed to exercise the defined behaviors (basic, exceptional or alternative, and error handling)
Which of the following best describes the behaviors defined in a use case that should be covered by tests?
→ Basic, exception and error
Question #4.2.01
An employee’s bonus is to be calculated. It cannot be negative, but it can be calculated down to zero. The bonus is based on the length of employment:
- less than or equal to 2 years
- more than 2 years but less than 5 years
- 5 to 10 years inclusively
- longer than 10 years
What is the minimum number of test cases required to cover all valid equivalence partitions for calculating the bonus?
The 4 equivalence partitions correspond to the description in the question, i.e. at least one test case must be created for each equivalence partition 1. Equivalence partition: 0 ≤ employment time ≤ 2. 2. Equivalence partition: 2 < employment time < 5. 3. Equivalence partition: 5 ≤ employment time ≤ 10. 4. Equivalence partition: 10 < employment time.
Question #4.2.02
A speed control and reporting system has the following characteristics:
- If you drive 50 km/h or less, nothing will happen.
- If you drive faster than 50 km/h, but no more than 55 km/h, you will be warned.
- If you drive faster than 55 km/h but not more than 60 km/h, you will be fined.
- If you drive faster than 60 km/h, your driving license will be suspended.
- The speed in km/h is available to the system as an integer value.
Which would be the most likely set of values (km/h) identified by applying the boundary value analysis, where only the values on the boundaries of the equivalence classes are selected?
The following partitions can be identified: 1. <= 50, boundary value 50 2. 51 – 55 boundary values 51, 55 3. 56 – 60 boundary values 56, 60 4. >=61 boundary value 61 Boundary value according to glossary V.3.2: A minimum or maximum value of an ordered equivalence partition
Which of the following statements BEST describes how test cases are derived from a use case?
Test cases are created to exercise defined basic, exceptional and error behaviors performed by the system under test in collaboration with actors.
This explains that each use case specifies some behavior that a subject can perform in collaboration with one or more actors. It also (later) explains that tests are designed to exercise the defined behaviors (basic, exceptional and errors)