Författare: Anders Sandström

Läste precis föreläsningsmaterial och en artikel av Lloyd Roden där han går igenom tekniken parvis testing. Principen är att de fel som finns vanligen är enkla fel - dvs ett visst värde på en viss parameter ger ett fel oavsett värdena på övriga variabler, eller duala där en kombination av två värden för två olika variabler i kombination gör att felet uppträder. Fel som kräver fler kombinationer är betydligt förre och att testa alla kombinationer av värden för alla variabler är sällan möjligt. 

Som många andra, ex Lee Copeland, ägnar han stor möda åt att förklara fenomenet ortogonala arrayer och hur dessa kan användas för att lösa problemen. O Arrayer är matematiska och manuellt framtagna och har egenskapen att de innehåller alla par av värden för vilka två kolumner som helst dvs i vårt falla för alla variabler och alla värden, jag ska inte förklara detta närmare här. Läs artikeln om du vill veta mer. problemet som jag ser det är att det finns en mängd begränsingar med arrayerna och det finns inga (?) bevisade fördelar med den ena eller andra metoden vad gäller felupptäckning för mjukvara. Däremot finns ett exempel för hårdvara 

The index is important when you want to make sure not only that each combination is tested, but that each combination is tested the same number of times. That's important in manufacturing and product safety tests, because it allows us to account for wear or friction between components. When we test combinations of components using orthogonal arrays, we find not only which combination of components will break, but also which combination will break first.  Michael Bolton

 Det Lloydutelämnar i artikeln är alla de fördelar som finns med ett verktyg som ex PICT nämligen följande:

a) det går att ha variabel täckning för olika variabler dvs du kan ha enkel täckning för vissa, parvis för andra och ännu högre för resten. Med andra ord högre risk - bättre täckning! Ortogonala arrayer för högre kombinationer är mycket stora och svåra att hantera.

b) det går att lägga in begränsingar för vissa kombinationer av variabler vilket är praktiskt då det ofta finns kombinationer som ej är tillåtna

c) det går att markera vissa värden som ogiltiga vilket gör att verktyget endast har med ett ogiltigt värde i varje testfall. detta är rekommendationen att ha då annars ett felaktigt värde kan hindra att nästa felaktiga vrde testas - dvs felhantering gör att vi hoppar ur loopen innan värdet avläses

d) när, inte OM men NÄR, du kommer på att det finns fler värden för en viss variabel. Då är det bara att lägga in de nya värdena och köra om filen. Använder du en array så är risken stor att du måste leta upp en ny vilket är tidsödande.

e) eftersom det inte finns arrayer för alla kombinationer av parameterantal och värden så är risken större att det blir fler testfall med arrayerna. Självklart finns det exempel på fall där motsaten gäller då du lyclas hitta en perfekt array för dina variabler.

Jag har diskuterat arrayer med Mats Grindal på ENEA som skrivit en doktorsavhandling i ämnet och med Peter Zimmerer som hade en tutorial på EuroSTAR förra veckan. Deras svar är entydliga - använd verktyg! 

Någon som har en avvikande mening är välkommen att argumentera för den här.