# Decision testing and converage

###### tags: `White Box Testing Tech` `ISTQB` `Software Testing` `SQA`
:::danger

:question:
:::
## Decision testing and coverage
**ensure that the decisions in a program are adequately exercised.**

To test a decision we need to exercise it when the associated condition is **true** and when the condition is **false**; **this guarantees that both exits from the decision are exercised.**

For example, a test case that sets the variable Count to 5 and then ==inputs the values 1, 5, −2, −3, 6 will exercise all the decisions fully and provide us with 100 per cent decision coverage.== :question:
Note that this is considered to be a single test case, even though there is more than one value for the variable New, because the values are all input in a single execution of the program. This example does not provide the smallest set of inputs that would achieve 100 per cent decision coverage, but it does provide a valid example.

**One hundred percent ==decision coverage== guarantees 100 percent statement coverage**, **but 100 percent statement coverage may be less than 100 percent decision coverage.**


:::success
Answer 1 i.e. list = (2,3,4,-1)
:::

Using Program Counting Numbers from Exercise 4.9, what level of decision coverage would be achieved by the single input A = –1?

:::success
50% because it will trigger false condition.
but it will not trigger the True condition.
:::

### Simplified control flow graphs
They incorporate less detail since **their purpose is to identify control structures but not the detail of code.**

只特別描述控制的部分，一般的執行的部分將其忽略

==4.16 右圖decision at the end of a loop
上面沒有箭頭指下來感覺有點怪?== :question:
==選項d如果是答案，那B是否改成 B<=3 or B>3才合理?==


**Exercise 4.11**
In the simplified CFG shown in Figure 4.18, which of the following sets of test cases would achieve 100 per cent statement coverage?

::: success
No answer can cover 100%
==but answer is a!== :question:
題目要的是statement 所以C是答案沒錯
:::

::: success
c.
:::

## Other structure-based techniques
**More sophisticated techniques are available to provide increasingly complete code coverage.**
In some applications these are essential:
for example, in a safety-critical system it is vital to know that nothing unacceptable happens at any point when the code is executed.

**Coverage is also applicable to other types and levels of structure.**
For example,
- at the **integration level** it is useful to know ++what percentage of modules or interfaces has been exercised by a test suite++
- while at the **functional level** it is ++helpful to step through all the possible paths of a menu structure++

## EXPERIENCE-BASED TECHNIQUES
Experience-based techniques are those that you fall back on when there is **no adequate pecification from which to derive specification-based test cases** or **no time to run the full structured set of tests.**

Even when specifications are available ==it is worth supplementing the structured tests with some that you know by experience have found defects in other similar systems.==
即使有spec，也有必要用經驗中的方式補充一些，從其他類似系統的經驗中發現的defect當作補充的測試。
而Experience部分包含 users’ and the testers’ experience

- Ad hoc testing or Error guessing
::: danger
兩者差異:question:
- Adhoc testing can be achieved with the Software testing technique called Error Guessing.
- Error guessing can be done by the people having enough experience on the system to "guess" the most likely source of errors.
:::
- Exploratory testing

### Error guessing
**Error guessing is a very simple technique that takes advantage of a tester’s skill, intuition and experience with similar applications to identify special tests** that may not be easy to capture by the more formal techniques.

The main drawback of error guessing is its varying effectiveness, depending as it does on the experience of the tester deploying it.

However, if several testers and/or users contribute to constructing a list of possible errors and tests are designed to attack each error listed, this weakness can be effectively overcome.

The defect and failure list can be used as the basis of a set of tests that are applied after the systematic techniques have been used. ==This systematic approach is known as fault attack.==

### Exploratory testing
Exploratory testing is a technique that **combines the experience of testers with a structured approach to testing** where specifications are either missing or inadequate and where there is severe time pressure.

It exploits concurrent test design, test execution, test logging and learning within time-boxes and is structured around a test charter containing test objectives.

**In this way exploratory testing maximises the amount of testing that can be achieved within a limited time frame**, ==using test objectives to maintain focus on the most important areas.==

:::info
note: funtional testing 就是跟spec最相關的部分
:::

### SYSTEMATIC AND EXPERIENCE-BASED TECHNIQUES
1. ==Always make **functional testing** (spec) the first priority.== It may be necessary to test early code products using structural techniques, but we only really learn about the quality of software when we can see what it does.
2. ==When basic functional testing is complete that is a good time to think about **test coverage**.== Have you exercised all the functions, all the requirements, all the code? Coverage measures defined at the beginning as exit criteria can now come into play. Where coverage is inadequate extra tests will be needed.
3. ==Use **structural methods** to supplement functional methods where possible.==
Even if functional coverage is adequate, it will usually be worth checking statement and decision coverage to ensure that enough of the code has been exercised during testing.
4. ==Once systematic testing is complete there is an opportunity to use **experience-based techniques** to ensure that all the most important and most error-prone areas of the software have been exercised.==
In some circumstances, such as poor pecifications or time pressure, experience-based testing may be the only viable option.

::: success
- structural
- structured
:::