Which of the following are not a black box testing techniques?
a. Boundary value testing
b. MC/DC testing
c. Cause-effect (Decision Table) testing
d. Combinatorial testing
e. Basic Condition testing
Black box testing techniques are used to test the functionality of a software system without examining its internal code or structure. They focus on testing the software based on its specifications, requirements, and inputs/outputs. Let's analyze the options to determine which of them are not black box testing techniques:
a. Boundary value testing - This is a black box testing technique that focuses on testing values at the boundaries of input domains.
b. MC/DC testing - This stands for Modified Condition/Decision Coverage testing and is primarily used for white box testing. It involves examining the code's internal logic to ensure that all conditions and decision points are tested.
c. Cause-effect (Decision Table) testing - This is a black box testing technique that uses decision tables to derive test cases based on various input combinations and their corresponding outcomes.
d. Combinatorial testing - This is a black box testing technique that involves testing various combinations of input values to identify potential issues related to the interactions between inputs.
e. Basic Condition testing - This is a black box testing technique that focuses on testing the basic conditions and logic of a software system without examining its internal code.
Based on the explanations above, the only option that is not a black box testing technique is:
b. MC/DC testing
Which one of the following is an implicit assumption made in equivalence class testing?
a. A program behaves
b. Different
in similar ways to every input value belonging equivalence classes of a program
contain similar bugs
c. Different equivalence classes of a program contain dissimilar bugs
d. Equivalence classes define the behaviorally similar components of a program
e. Equivalence classes define the behaviorally similar code segments of a program
to an equivalence class.
In equivalence class testing, the implicit assumption made is:
d. Equivalence classes define the behaviorally similar components of a program
This assumption implies that input values falling into the same equivalence class should result in similar behavior or outcomes from the program. Equivalence class testing is based on the idea that if one input within an equivalence class triggers a certain behavior or reveals a certain bug, other inputs within the same class are likely to exhibit similar behavior or expose similar issues.
In a certain bank, customers are offered different rates interest on deposits depending on the amount of deposit and the duration of deposit. The rate of interest for deposits of any amount between Rs. 1000 and Rs. 1 Lakh is as follows:
6% for deposit upto 1 year
7% for deposit over 1 year but less than 3 years
8% for deposit over 3 years and less than 10 years
The rate of interest for deposits of any amounts between Rs. 1 Lakh to less than 1 crore, is as follows:
• 7% for deposit upto 1 year
• 8% for deposit over 1 year but less than 3 years
• 9% for deposit over 3 years and less than 10 years
A function named compute-interest-rate (amount, months) was developed by the bank to compute the interest rate applicable for a deposit made by a customer. At least how many test cases are needed for weak equivalence class testing of the function compute-interest-rate?
a. 2
b. 3
C. 56
d. 6
e. 7
To perform weak equivalence class testing for the compute-interest-rate function, we need to identify the equivalence classes based on the given criteria. Equivalence classes are groups of inputs that should produce the same output or behavior from the function.
In this case, there are two main factors to consider: the amount of deposit and the duration of deposit. We'll break down the equivalence classes based on these factors.
For the amount of deposit:
Deposits between Rs. 1000 and Rs. 1 Lakh
Deposits between Rs. 1 Lakh and less than Rs. 1 crore
For the duration of deposit:
Deposits up to 1 year
Deposits over 1 year but less than 3 years
Deposits over 3 years and less than 10 years
Now, let's calculate the total number of combinations for these equivalence classes:
Number of classes for amount: 2
Number of classes for duration: 3
Total combinations: 2 (amount) * 3 (duration) = 6 combinations
So, you would need at least 6 test cases for weak equivalence class testing of the compute-interest-rate function. The correct answer is:
d. 6
For the function compute-interest-rate of Q. 3, at least how many test cases are needed for strong equivalence testing?
a. 3
b. 6
C. 8
d. 9
e. 12
To perform strong equivalence class testing, you need to consider all possible combinations of input values within each equivalence class. Let's break down the equivalence classes based on the given criteria:
For the amount of deposit:
Deposits between Rs. 1000 and Rs. 1 Lakh
Deposits between Rs. 1 Lakh and less than Rs. 1 crore
For the duration of deposit:
Deposits up to 1 year
Deposits over 1 year but less than 3 years
Deposits over 3 years and less than 10 years
Now, calculate the total number of combinations for these equivalence classes:
Number of classes for amount: 2
Number of classes for duration: 3
Total combinations: 2 (amount) * 3 (duration) = 6 combinations
For strong equivalence class testing, you would need to test all possible combinations within each equivalence class. Therefore, for each of the 6 combinations, you would need to test them for both amounts (Rs. 1000 to Rs. 1 Lakh and Rs. 1 Lakh to less than Rs. 1 crore). So, you need:
6 combinations * 2 amounts = 12 test cases
So, you would need at least 12 test cases for strong equivalence class testing of the compute-interest-rate function. The correct answer is:
e. 12
For the function compute-interest-rate of Q. 3, at least how many test cases are needed for strong robust equivalence testing?
a. 6
b. 12
C. 15
d. 16
e. 20
Strong robust equivalence testing involves testing all combinations of valid and invalid inputs within each equivalence class. In this case, we have two main factors to consider: the amount of deposit and the duration of deposit, and we also need to account for invalid inputs.
Let's break down the equivalence classes based on the given criteria:
For the amount of deposit:
Deposits between Rs. 1000 and Rs. 1 Lakh
Deposits between Rs. 1 Lakh and less than Rs. 1 crore
For the duration of deposit:
Deposits up to 1 year
Deposits over 1 year but less than 3 years
Deposits over 3 years and less than 10 years
Now, calculate the total number of combinations for these equivalence classes:
Number of classes for amount: 2
Number of classes for duration: 3
Total combinations: 2 (amount) * 3 (duration) = 6 combinations
For strong robust equivalence class testing, you would need to test all combinations of valid inputs and also consider invalid inputs. Assuming that invalid inputs include values outside the specified ranges, we need to consider three invalid cases for each factor (amount and duration).
So, for each of the 6 combinations, you need:
(3 invalid amount values + 1 valid amount value) * (3 invalid duration values + 1 valid duration value) = 4 * 4 = 16 test cases
Total test cases needed:
6 combinations * 16 test cases per combination = 96 test cases
So, you would need at least 96 test cases for strong robust equivalence class testing of the compute-interest-rate function. The correct answer is not among the provided options.
Consider the function find-intersection(m1,c1,m2, c2) that computes the point of intersection of two straight lines of the form y=mx+c. For equivalence class testing, at the first level of the equivalent class hierarchy the valid and invalid equivalence classes can be formed. The valid set of input values can be further divided into how many equivalence classes?
a. 1
b. 2
C. 3
d. 4
e. 5
In equivalence class testing, you typically start by identifying valid and invalid equivalence classes for the inputs of a function. For the find-intersection function, you have four input parameters: m1, c1, m2, and c2, which represent the slopes and intercepts of two straight lines.
Let's consider the input parameters one by one:
m1 (slope of the first line) - Valid equivalence classes might include any real number because a slope can be any real number. So, you can create one valid equivalence class for m1.
c1 (intercept of the first line) - Valid equivalence classes might also include any real number because an intercept can be any real number. So, you can create one valid equivalence class for c1.
m2 (slope of the second line) - Again, valid equivalence classes might include any real number. You can create one valid equivalence class for m2.
c2 (intercept of the second line) - Valid equivalence classes might also include any real number. You can create one valid equivalence class for c2.
So, for each of the four input parameters, you have one valid equivalence class. Therefore, the valid set of input values can be divided into:
1 (valid equivalence class for m1) * 1 (valid equivalence class for c1) * 1 (valid equivalence class for m2) * 1 (valid equivalence class for c2) = 1
You have one valid equivalence class for the input values. The correct answer is:
a. 1
In a certain software development organization it was found based on an analysis of collected data over several completed projects that black box unit tests detect 24% of the total defects detected, White box tests detect 30% of the defects, Integration tests detect 16%, and system tests detect 10% of the defects, and 20% defects were reported by the customers after the release of the software. What proportion of the total test effort should be allocated to integration testing?
a. 10%
b. 12%
C. 15%
d. 20%
e. 25%
To determine the proportion of the total test effort that should be allocated to integration testing, you can use the information given about the percentage of defects detected by each type of testing.
Integration tests are responsible for detecting 16% of the total defects. Therefore, to allocate an appropriate proportion of the total test effort to integration testing, you should aim to allocate a similar proportion of the total test effort to it.
So, the proportion of the total test effort allocated to integration testing is:
16%
Therefore, the correct answer is:
b. 16%
During unit testing, why is it important to test the boundary values? a. It reduces test costs as boundary values are easily computed by hand.
b. Debugging is easier when testing boundary values. c. The correct execution of a function on all boundary values proves that the function is
correct.
d. Programming the boundary conditions is usually error-prone in practice
e. Each boundary value test case checks working of two equivalence classes
The correct answer is:
e. Each boundary value test case checks the working of two equivalence classes.
Testing boundary values is essential because they often represent points where the behavior of a software component may change. Boundary values are where one equivalence class transitions to another. By testing boundary values, you effectively test both sides of this transition, ensuring that the software behaves correctly as it crosses from one equivalence class to another. This is why boundary value testing is valuable in uncovering potential issues and defects in software during unit testing.
To test a unit, the programmer has to write a piece of code which would call the function and passes it test data. What would this piece of code called?
a. Stub
b. Driver
c. Proxy
d. Glue
e. Library routine
f. System call
The piece of code that is used to call a function and pass it test data during unit testing is typically called a:
b. Driver
A driver is used to invoke the unit of code being tested, providing inputs and then observing the outputs or behavior of the unit to ensure it functions correctly. This is often done when testing individual functions or methods in isolation.
If a user interface has two check boxes, at least how many test cases are required to achieve pair-wise coverage?
a. 3
b. 4
C. 5
56 d. 6
To achieve pair-wise coverage for a user interface with two checkboxes, you need to test all possible pairs of values for these checkboxes. Since each checkbox can have two states (checked or unchecked), there are 2^2 = 4 possible combinations of states for the two checkboxes. To achieve pair-wise coverage, you need to test each possible pair of these combinations.
The number of test cases required for pair-wise coverage is:
4 combinations * 2 (to test pairs) = 8 test cases
However, you only need to test each pair once, so you would exclude duplicate pairs. Therefore, the minimum number of test cases required for pair-wise coverage is:
8 / 2 = 4 test cases
So, the correct answer is:
b. 4