4. Testowanie na podstawie ryzyka
• Testowanie na podstawie ryzyka:
• Identyfikacja
• Ocena
• Łagodzenie ryzyka projektowego/produktowego
Adam Ścierski | a.scierski@gmail.com 4
5. Testowanie na podstawie ryzyka [Identyfikowanie ryzyka] (1/5)
Przykładowe ryzyka:
• Ryzyko wydajnościowe (czasy odpowiedzi)
• Ryzyko związane z bezpieczeństwem (wyciek danych
wrażliwych)
• Ryzyko związane z niezawodnością (niemożliwość
spełnienia wymagania dostępności opisanego w SLA*)
*Service Level Agreement
Adam Ścierski | a.scierski@gmail.com 5
6. Testowanie na podstawie ryzyka [Analiza Ryzyka] (2/5)
Określenie poziomu/wagi ryzyka oznacza zwykle ocenę
ryzyka oraz jego ewentualnych skutków
http://rbcs-us.com/site/assets/files/1159/a-case-study-in-risk-based-testing.pdf
Adam Ścierski | a.scierski@gmail.com 6
7. Testowanie na podstawie ryzyka [Analiza Ryzyka] (3/5)
http://rbcs-us.com/site/assets/files/1159/a-case-study-in-risk-based-testing.pdf
*RPN – Risk Priority Number
Adam Ścierski | a.scierski@gmail.com 7
8. Testowanie na podstawie ryzyka [Łagodzenie Ryzyka] (4/5)
http://rbcs-us.com/site/assets/files/1159/a-case-study-in-risk-based-testing.pdf
Adam Ścierski | a.scierski@gmail.com 8
9. Testowanie na podstawie ryzyka [Łagodzenie Ryzyka] (5/5)
Co dalej?
• Nakład pracy związany z testami powinien być adekwatny
do odkrytego ryzyka
• Ryzyka powiny być połączone z specyfikacją
• Ryzyka powinny być połączone z przypadkami testowymi
• Priorytetyzacja przypadków testowych w oparciu o
poziom ryzyka poszczególnych zdefiniowanych ryzyk
http://rbcs-us.com/site/assets/files/1159/a-case-study-in-risk-based-testing.pdf
Adam Ścierski | a.scierski@gmail.com 9
11. Techniki projektowania oparte na
strukturze
Techniki projektowania oparte na strukturze:
• Testowanie Instrukcji (Statement Testing) [CTFL]
• Testowanie Decyzji (Decision Testing) [CTFL]
• Testowanie Warunków (Condition Testing)
• Testowanie Warunków Decyzji (Decision Condition Testing)
• Pokrycie warunków znaczących/Zmodyfikowane pokrycie
warunków decyzji (MC/DC Testing)
• Testowanie wielokrotnych warunków (Multiple Condition Testing)
• Testowanie ścieżek
• Testowanie API
Adam Ścierski | a.scierski@gmail.com 11
12. Techniki projektowania oparte na strukturze
[Statement Testing] (1/10)
if (a>0 && b==2)
{
Printf(”b equals 2”)
}
Test
Case
a b
1 1 2
end
T F
Adam Ścierski | a.scierski@gmail.com 12
13. Techniki projektowania oparte na strukturze
[Decision Testing] (2/10)
if (a>0 && b==2)
Test Case a b Decision
1 1 2 True
2 0 2 False
Decison Testing
T F
100% Decision coverage = 100%
Statement coverage
Adam Ścierski | a.scierski@gmail.com 13
14. Techniki projektowania oparte na strukturze
[Condition Testing] (3/10)
if (a>0 && b==2)
Atomowe warunki w decyzji
Test Case A B Decision
1 False True False
2 True False False
100% Conditions coverage ≠ 100%
Decisions coverage
A B
Adam Ścierski | a.scierski@gmail.com 14
15. Techniki projektowania oparte na strukturze
[Decision Condition Testing] (4/10)
if (a>0 && b==2)
Test Case A B Decision
1 False False False
2 True True True
condition coverage
+ decision coverage
100% Condition + 100% Decision
A B
Adam Ścierski | a.scierski@gmail.com 15
16. Techniki projektowania oparte na strukturze
[Modified Condition/Decision Coverage (MC/DC) Testing] (5/10)
• Wystarczy n+1 przypadków testowych do pokrycia
MC/DC
• MC/DC jest szeroko stosowania w lotnictwie i innych
krytycznych dla życia produktach/projektach
• Standardy mogą wymagać użycia MC/DC
FAA DO-178B (Europejski odpowiednik, ED-12B)
Level
A Katastroficzny Uniemożliwia kontynuowanie bezpiecznego lotu i lądowanie MC/DC, Decision, Statement
B Niebezpieczny/
bardzo wysoki
Duże zmniejszenie marginesów bezpieczeństwa lub możliwości funkcjonalnych. Nie można
polegać na załodze, że wykona swoje zadania dokładnie lub skutecznie. Poważne lub
śmiertelne obrażenia małej liczby oasażerów
Decision coverage (MC/DC optional),
Statement
C Wysoki Znaczące zmniejszenie marginesów bezpieczeństwa. Znaczące zwiększenie obciążenia
załogi. Dyskomfort pasażerów oraz możliwe obrażenia
Statement coverage
D Niski Niewielkie zmneijszenie marginesów bezpieczeństwa lub możliwości funkcjonalnych.
Niewielkie zwiększenie obciążenia załogi. Niewielkie utrudnienia dla pasażerów.
Brak
E Żaden Brak wpływu na możliwości statku powietrznego. Brak wpływu na obciążenie załogi. Brak
http://www.faa.gov/aircraft/air_cert/design_approvals/air_software/cast/cast_papers/media/cast-10.pdf
http://www.tc.faa.gov/its/worldpac/techrpt/ar01-18.pdf
Adam Ścierski | a.scierski@gmail.com 16
17. Techniki projektowania oparte na strukturze
[Modified Condition/Decision Coverage (MC/DC) Testing] (6/10)
MC/DC osiąga pokrycie Warunków Decyzji (Decision
condition) oraz wymaga:
• Przynajmniej jeden test gdzie decyzja zmieni się gdy warunek
atomowy X będzie True
• Przynajmniej jeden test gdzie decyzja zmieni się gdy warunek
atomowy X będzie False
• Każdy unikalny warunek atomowy ma test który jest zgodny z
powyższymi stwierdzeniami
http://ntrs.nasa.gov/archive/nasa/casi.ntrs.nasa.gov/20010057789.pdf
http://www.nasa.gov/centers/ivv/doc/212828main_Needs5.3.doc
http://www.cs.bris.ac.uk/Publications/Papers/2001693.pdf
Adam Ścierski | a.scierski@gmail.com 17
18. Techniki projektowania oparte na strukturze
[Modified Condition/Decision Coverage (MC/DC) Testing] (7/10)
if (a>0 && b==2)A && B
A&&B True False
A T _ F _
B _ T _ F
OR->F, AND->T
A&&B True False
A T T F T
B T T T F
n+1=3
3 Test Cases = TT, FT, TF
Adam Ścierski | a.scierski@gmail.com 18
20. Techniki projektowania oparte na strukturze
[Modified Condition/Decision Coverage (MC/DC) Testing]
A || B && C
(A || B) && C True False
A T _ _ F _ _
B _ T _ _ F _
C _ _ T _ _ F
n+1=4
4 Test Cases = TFT, FTT, FFT, TFF
(A || B) && C True False
A T F T F F T
B F T T F F T
C T F T T F F
Adam Ścierski | a.scierski@gmail.com 20
22. Techniki projektowania oparte na strukturze
[Modified Condition/Decision Coverage (MC/DC) Testing]
Requirement
The self-check module will check the status of 4 engines of
a airplane, then return if the airplane can take off.
The airplane shall be able to take off with at least one of the
engine1 and engine2 on, and at least one of the engine 3
and engine 4 on.
E1
E2
E3
E4
Adam Ścierski | a.scierski@gmail.com 22
23. Techniki projektowania oparte na strukturze
[Modified Condition/Decision Coverage (MC/DC) Testing]
if((E1||E2) && (E3||E4)){
return true;
} else {
return false;
} E1
E2
E3
E4
(E1||E2) && (E3||E4) True False
E1 T _ _ _ F _ _ _
E2 _ T _ _ _ F _ _
E3 _ _ T _ _ _ F _
E4 _ _ _ T _ _ _ F
4+1=5
(E1||E2) && (E3||E4) True False
E1 T F T F F F T F
E2 F T T F F F T F
E3 T F T F T F F F
E4 T F F T T F F F
TC = TFTF, FTTF, TFFT, FFTF, TFFF
Adam Ścierski | a.scierski@gmail.com 23
24.
25. Techniki projektowania oparte na strukturze [Multiple Condition Testing]
(8/10)
W nielicznych przypadkach, jest wymagane pełne pokrycie
wszystkich kombinacji warunków w decyzji.
Liczba wymaganych przypadków testowych jest zależna od
ilości atomowych warunków w decyzji: 2n
A && B
A B
Test 1 T T
Test 2 T F
Test 3 F T
Test 4 F F
22= 4
Adam Ścierski | a.scierski@gmail.com 25
27. Techniki projektowania oparte na strukturze [Multiple Condition Testing]
A || B && C
23=8
A B C
Test 1 T T T
Test 2 T F T
Test 3 T T F
Test 4 T F F
Test 5 F F F
Test 6 F F T
Test 7 F T F
Test 8 F T T
Adam Ścierski | a.scierski@gmail.com 27
28.
29. Techniki projektowania oparte na strukturze [Multiple Condition Testing +
short-circuiting] (9/10)
A || B && C
23=8-3=5
A B C
Test 1 T - T
Test 2 T - T
Test 3 T - F
Test 4 T - F
Test 5 F F -
Test 6 F F -
Test 7 F T F
Test 8 F T T
Adam Ścierski | a.scierski@gmail.com 29
30. Techniki projektowania oparte na strukturze [Podsumowanie] (10/9)
• 100% pokrycie Multiple Condition
(warunków wielokrotnych) oznacza
100% pokrycie MC/DC (warunków
znaczących/Zmodyfikowanych
warunków decyzji)
• 100% pokrycia MC/DC
(zmodyfikowanych warunków decyzji)
daje 100% pokrycia Decision
Condition (warunków decyzji).
• 100% pokrycia Decision Condition
(warunków decyzji) implikuje 100%
pokrycia Condition (warunków) oraz
100% pokrycia Decision (decyzji)
• 100% pokrycia Decision (decyzji) jest
równoważny 100% pokrycia Branch
(gałęzi) oraz implikuje 100% pokrycia
Statement (instrukcji).
Multiple
Condition
MC/DC
Decision
Condition
Condition Decision
Branch Statement
Adam Ścierski | a.scierski@gmail.com 30
32. Techniki analityczne
• Techniki analityczne:
• Analiza statyczna kodu
• Analiza przepływu sterowania (Control Flow Analysis) [Miara złożoności
cyklomatycznej]
• Analiza przepływu danych (Data Flow Analysis) [notacja define-use]
Adam Ścierski | a.scierski@gmail.com 32
33. TechnikiAnalityczne [Analiza Statyczna Kodu] (1/4)
• Może być wykonana przez narzędzie lub przez człowieka
• Kompilator
• Przeglądy
• Nie wymaga uruchomienia kodu
Cel:
Wykrycie aktualnych lub potencjalnych usterek w kodzie i
architekturze, poprawa ich pielęgnowalności.
[pielęgnowalność: Łatwość, z którą oprogramowanie może być modyfikowane w celu
naprawy defektów, dostosowania do nowych wymagań, modyfikowane w celu ułatwienia
przyszłego utrzymania lub dostosowania do zmian zachodzących w jego środowisku.
[ISO 9126] ]
Adam Ścierski | a.scierski@gmail.com 33
34. Analiza Statyczna Kodu [Control FlowAnalysis] (2/4)
Analiza Przepływu Sterowania [Control Flow Analysis]
dostarcza informacji na temat złożoności struktury –
najczęściej złożoności cyklomatycznej.
• Złożoność cyklomatyczna mówi nam o liczbie unikalnych
ścieżek prowadzących przez testowany moduł a zatem o
maksymalnej ilości dobrze zaprojektowanych testów
które gwarantowały by 100% pokrycia decyzji.
Adam Ścierski | a.scierski@gmail.com 34
35. Analiza Statyczna Kodu [Control FlowAnalysis] (3/4)
Po co?
Skomplikowany kod:
• jest wylęgarnią błędów [kumulowanie błędów [CTFL]]
• utrudnia pielęgnowalność kodu
Maksymalna zalecana przez NIST* wartość złożoności
wynosi 10.
*National Institute of Standards and Technology
http://www.mccabe.com/pdf/mccabe-nist235r.pdf
Adam Ścierski | a.scierski@gmail.com 35
36. Analiza Statyczna Kodu [Control FlowAnalysis] (4/4)
http://www.mccabe.com/pdf/mccabe-nist235r.pdf
Adam Ścierski | a.scierski@gmail.com 36
41. Przeglądy(1/4)
Przeglądy są najczęściej spotykaną formą testowania
statycznego (bez uruchamiania oprogramowania).
Można przejrzeć każdy produkt pracy programistycznej:
• Kod
• Specyfikacje
• Wymagań
• Projektu
• Testów
• Plany testów, przypadki testowe, skrypty testowe
• Instrukcję użytkownika
Adam Ścierski | a.scierski@gmail.com 41
42. Przeglądy[Checklisty] (2/4)
Przykładowa checklista dla przeglądu kodu:
• Structure
• Does the code completely and correctly implement the design?
• Does the code conform to any pertinent coding standards?
• Is the code well-structured, consistent in style, and consistently formatted?
• Are there any uncalled or unneeded procedures or any unreachable code?
• Are there any leftover stubs or test routines in the code?
• Can any code be replaced by calls to external reusable components or library functions?
• Are there any blocks of repeated code that could be condensed into a single procedure?
• Is storage use efficient?
• Are symbolics used rather than “magic number” constants or string constants?
• Are any modules excessively complex and should be restructured or split into multiple modules?
• Documentation
• Is the code clearly and adequately documented with an easy-to-maintain commenting style?
• Are all comments consistent with the code?
• Does the documentation conform to applicable standards?
• Variables
• Are all variables properly defined with meaningful, consistent, and clear names?
• Are there any redundant or unused variables?
Adam Ścierski | a.scierski@gmail.com 42
43. Przeglądy[Checklisty] (3/4)
• Arithmetic Operations
• Does the code avoid comparing floating-point numbers for equality?
• Does the code systematically prevent rounding errors?
• Does the code avoid additions and subtractions on numbers with greatly different magnitudes?
• Are divisors tested for zero or noise?
• Loops and Branches
• Are all loops, branches, and logic constructs complete, correct, and properly nested?
• Are the most common cases tested first in IF-ELSEIF chains?
• Are all cases covered in an IF-ELSEIF or CASE block, including ELSE or DEFAULT clauses?
• Does every case statement have a default?
• Are loop termination conditions obvious and invariably achievable?
• Are indices or subscripts properly initialized, just prior to the loop?
• Can any statements that are enclosed within loops be placed outside the loops?
• Does the code in the loop avoid manipulating the index variable or using it upon exit from the loop?
Adam Ścierski | a.scierski@gmail.com 43
44. Przeglądy[Checklisty] (4/4)
• Defensive Programming
• Are indices, pointers, and subscripts tested against array, record, or file bounds?
• Are imported data and input arguments tested for validity and completeness?
• Are all output variables assigned?
• Is the correct data element operated on in each statement?
• Is every memory allocation released?
• Are timeouts or error traps used for external device access?
• Are files checked for existence before attempting to access them?
• Are all files and devices left in the correct state upon program termination?
Adam Ścierski | a.scierski@gmail.com 44
