How can you approach Modified Condition/Decision Coverage(MC/DC) in your project?…not to be confused with AC/DC!
Let’s look at the what, the why and the when…
Modified Condition/Decision Coverage (MC/DC) is a code coverage criterion commonly used in software testing.
For example, DO-178C software development guidance in the aerospace industry requires MC/DC for the most critical software level (DAL A).
Code coverage is a way of measuring the effectiveness of your test cases.
The higher the percentage of code that has been covered by testing, the less likely it is to contain bugs when compared to code that has a lower coverage score.
There are three other types of code coverage that are worth considering in relation to MC/DC: Statement coverage, Decision coverage and Multiple condition coverage.
In addition to the criteria required by statement and decision coverage, MC/DC requires that 'Each condition in a decision has been shown to independently affect that decision's outcome'.
===
Why MC/DC?
Aerospace and automotive guidance prioritizes safety above all else in the software development lifecycle.
With that in mind, truly ‘exhaustive testing’, as encapsulated by MCC, would be the safest and most rigorous approach in a perfect world.
MC/DC represents a compromise that finds a balance between rigor and effort; positioning itself in between DC and MCC.
MC/DC requires a much smaller number of test cases in comparison to multiple condition coverage (MCC), while retaining a high error-detection probability.
===
When is MC/DC required?
DAL A aerospace projects
Any software that is critical to provide (or prevent failure of) continued safe flight and landing of an aircraft is defined as being Design Assurance Level A software.
Any aerospace software that is being created at this level of assurance must measure and report MC/DC.
ASIL D automotive projects
ISO 26262 prescribes MC/DC for ASIL D (the highest criticality level) software.
MC/DC Neden Lazım
Eğer
Full condition coverage veya bir diğer ismiyle
Truth Table yöntemini deneseydik çok fazla test yazmak gerekirdi. N tane koşul için 2^N tane test yazmak gerekir. Örneğin A ve B'nin yanına yeni bir C koşulu daha gelseydi, test sayısı iki ile çarpılacaktı. Bu durum da maliyetler çok artacaktı.
MC/DC test sayısını azaltmayı hedefler. Açıklaması
şöyle. Çünkü MC/DC 'de tüm koşullar önce True ile başlar sonra bir seferde tek bir koşul False yapılır. Truth Table yönteminde ise bir seferde birden fazla False olabiliyor. Bu yüzden test sayısı çok fazla oluyor.
In general, with N conditions MC/DC requires N+1 test cases as opposed to 2^N. As such, it strikes a good balance between rigor (each condition tested) and efficiency (testing all of 2^4 may not be necessary).
Truth TableMC/DC için truth table çıkartmak gerekiyor. Bunu çıkartmanın kolay bir yolu şöyle.
Kaç tane değişken varsa (n diyelim) s^n tane (K diyelim) satır olması gerekiyor.
İlk sütuna dönüşümlü olarak K/2 tane T ve F yazılır.
İkinci sütuna dönüşümlü olarak K/4 tane T ve F yazılır.
Üçüncü sütuna dönüşümlü olarak K/8 tane T ve F yazılır.
Truth Table'dan MC/DC Testine Geçiş
İlk sütundaki değer değişikliği (diğer sütunlar sabit kalmalı) sonucu da değiştiriyorsa bu sütun teste dahil edilir.
İkinci sütundaki değer değişikliği (diğer sütunlar sabit kalmalı) sonucu da değiştiriyorsa bu sütun teste dahil edilir.
Üçüncü sütundaki değer değişikliği (diğer sütunlar sabit kalmalı) sonucu da değiştiriyorsa bu sütun teste dahil edilir.
Dolayısıyla kodun nasıl yazıldığı testleri de etkiler. Şu iki kod arasında test maliyeti açısından fark mevcut. Bu örnekte çok fazla test yazmak
gerekiyor.
(A||B) && (A||!C)
Aynı işi gören bu kodda ise daha az test yazmak
gerekiyor.
A||(B&&!C)
Örnek
Elimizde şöyle bir kod olsun
if (conditionA && conditionB && conditionC && conditionD) {
return true;
}
MC/DC testi için şöyle yaparız
A B C D
testTypicalCall() -> T T T T
testAisFalseFails() -> F T T T
testBisFalseFails( -> T F T T
testCisFalseFails() -> T T F T
testDisFalseFails() -> T T T F
Örnek
Modified Condition/Decision Coverage (MC/DC) is a code coverage criterion commonly used in software testing as a way of measuring the effectiveness of your test cases.
MC/DC requires that 'Each condition in a decision has been shown to independently affect that decision's outcome'.
Imagine making a cup of coffee.
To make a warm and tasty cup of coffee, we'd need ALL of the following: a kettle, a cup and coffee.
If any of the components were missing, we wouldn't be able to make our coffee.
Or, to express this another way:
if( kettle && cup && coffee ) {
return cup_of_coffee;
}
else {
return none;
}
(see the illustration attached to this post)
Tests 4 & 8 demonstrate that ‘kettle’ can independently affect the outcome.
Tests 6 & 8 demonstrate that ‘mug’ can independently affect the outcome.
Tests 7 & 8 demonstrate that ‘coffee’ can independently affect the outcome.
The tests required for MC/DC analysis in this case are tests 4, 6, 7 & 8.
Tests 1, 2, 3 and 5 are not required as we can satisfy the MC/DC criterion without them.
These redundant tests need not be included in the coverage report.
Şeklen
şöyle. Burada bence en kolayı önce tüm koşulların 1 olduğu durumu yani 8. satırı bulmak daha sonra bir koşulun 0 yapılarak sonucu değiştiği satırı bulmak gerekiyor. Bu satırlar 4,6 ve 7
Örnek
Elimizde şöyle bir kod
olsun
if ( ((x == 0) && (y == 0)) || y == 0) {
...
}
MC/DC için Şöyle
yaparız.
╔════════╦════════╦══════════════════════════════════╗
║ x == 0 ║ y == 0 ║ ((x == 0) && (y == 0)) || y == 0 ║
╠════════╬════════╬══════════════════════════════════╣
║ 0 ║ 0 ║ 0 ║
║ 0 ║ 1 ║ 1 ║
║ 1 ║ 0 ║ 0 ║
║ 1 ║ 1 ║ 1 ║
╚════════╩════════╩══════════════════════════════════╝
