Shipping buggy code: The most critical skill for a programme

[hummel]

För i alla fall inbyggda system inom rimlig storlek går det att skriva program på ett sådant sätt att man garanterat testar varje rad (100%) kod i programmet.

Jo, om koden inskränker sig till något hundratal rader typ.

Några tiotusentals rader fungerar det på!

[lillahuset]

Garanterat?
Testar för vad då?
Korrekt?
Korrekt enligt spec?
Och interrupten då?

[TomasL]

Det hela handlar om två helt skilda saker.
Visst man kan skriva ett par hundra rader korrekt kod, dock är det inte 100% säkert att den korrekta koden i alla lägen gör vad man tänkt sig.

Jag tror som Lillahuset, att det i princip är fullständigt omöjligt att skriva kod som är 100% buggfri, oavsett kodstorlek.

[arvidb]

För i alla fall inbyggda system inom rimlig storlek går det att skriva program på ett sådant sätt att man garanterat testar varje rad (100%) kod i programmet.

Visst, 100 % code coverage vid testning är väl ett rimligt mål, men det betyder bara att all kod har blivit exekverad minst en gång. Det ger ingen som helst garanti för att koden är felfri (att den inte kraschar med andra indata, eller ens att den exekverade koden gör det den ska med de indata som användes).

[Gimbal]

Det är knappast så enkelt att du kan räkna ett visst antal rader per bugg och säga att över ett visst antal rader så skiter det sig. Det är en VÄLDIG skillnad på vad för sorts program det handlar om, eller snarare vilken sorts indata den utsätts för.

Vissa program har bara några få väldefinierade indata att ta hänsyn till, då är det enkelt att kontrollera att indatan håller sig inom spec. och att efterföljande behandling klarar att hantera det.

Andra program ska ta emot tonvis av data och styrkommandon behandlade av andra okända datorer och/eller människor där vissa till och med aktivt försöket ta ner systemen. Då är det förmodligen lite mer komplext att förutse allt programmet kan utsättas för.

[Andax]

Nu var det en herrans massa år sedan jag gick en kurs i säkerhetskritisk programvara (enl DO-178B), men vad som slog mig var att det var att det täcker in processen kring utveckling av programvaran så att man t.ex. har code coverage etc, men inte om vad man försöker göra. Antaganden om hur systemet man ska styra kan vara helt helt fel.

Ta t.ex. fallet med 911 (nödnummer i USA) där man antog ett maxvärde på ett ID på 1000000. Det var ju ett fel i antagandet om hur många som kunde ringa. När det överbelastades kraschade systemet. Ingen utvecklingsprocess hade ju hittat det. Det är ju mer en fråga om hur insiktsfull programmeraren är om problemet hen ska lösa. Nu fanns det egentligen ingen anledning av programmeraren att sätta just 1000000. Hen kunde likväl satt ett 1000 ggr större maxvärde och det skulle aldrig ha kraschat.

[Nerre]

Men med korrekta utvecklingsmetoder så även om man antar ett maxvärde på en miljon så skriver man programmet så att det inte gör nåt okontrollerat om det blir mer än 1 miljon.

Även om indata anges vara begränsat i omfånget så ska man räkna med att det kan vara utanför gränserna och då ha felhanteringsrutiner som tar hand om det.

[hummel]

För i alla fall inbyggda system inom rimlig storlek går det att skriva program på ett sådant sätt att man garanterat testar varje rad (100%) kod i programmet.

Visst, 100 % code coverage vid testning är väl ett rimligt mål, men det betyder bara att all kod har blivit exekverad minst en gång. Det ger ingen som helst garanti för att koden är felfri (att den inte kraschar med andra indata, eller ens att den exekverade koden gör det den ska med de indata som användes).

Använder testvektorer för att täcka in det.
Bara använda state machines för att göra det möjligt att testa allt.

[arvidb]

För att täcka in vad? Att den exekverade koden gjorde det den skulle med de indata som användes? Ja det är ju lämpligt i så fall.

Hur använder ni state machines för att göra det möjligt att testa allt?

[Nerre]

Med en state machine finns det ett begränsat antal states och ett begränsat antal övergångar mellan dessa. Det blir med andra ord ett begränsat antal testfall att testa.

Det kräver dock att den är konstruerad så att man kan "ställa upp" testlägen utan att behöva stega sig igenom alla föregående states. Hur man gör det i mjukvarulösningar vet jag inte riktigt, med hårdvara så bygger man in skiftregister för att skifta in och ut alla interna bitar för att kunna ställa in valfri utgångspunkt. (Boundary scan t.ex.)

(När jag pluggade till elektroingenjör på KTH läste vi en kurs som just handlade om att designa för testbarhet. Det är alltså en "konstart" i sig, att designa så det blir testbart på ett enkelt sätt. Och jag är övertygad om att man kan göra precis samma sak med mjukvara. Om man inte förstår hur man designar för testbarhet så antar jag att det verkar omöjligt, men det är bara för att man inte förstår hur man gör.)

Edit: Hittade ett par bra presentationen här:

(efter denna kommer det minst en till om samma ämne)

[arvidb]

Om man ska implementera en state machine så kan man ju enligt artikeln i lillahusets andra tråd t.o.m. bevisa matematiskt att ens state machine gör det den är designat till att göra genom att använda "model-based software development".

Men att skriva state machines är ju ganska specifikt; jag förstod det som att hummel menade att det är möjligt att testa vilka (små) program som helst till 100 %, och tyckte att det då vore intressant att få veta hur man gör det.

[Mr Andersson]

Det är ju skillnad på att testa en state machine, och att använda en sm för att utföra testerna. Jag tolkar hummels inlägg som det senare.

Jag påstår att det är omöjligt att göra ett test som täcker 100% utan att testa 100% av all möjlig indata. Även om det går att matematiskt/statistiskt bevisa att koden är felfri kan det finnas kompilator- eller hårdvarubuggar som man inte vet om.

[lillahuset]

Det som förbryllar mig mest är att det finns en massa (nåja ett gäng iallafall) folk här i forumet som verkar ha väldigt svårt för konceptet att det är i stort sett omöjligt att BEVISA att ett program är FELFRITT.

[Mr Andersson]

Jo det håller jag med om. Man kan (teoretiskt) bevisa att kodsnuttar är felfria. Men ett helt program.. Om det inte är extremt simpelt så tvivlar jag att det går.

T.ex. float output = input / 2.0f;
Det går relativt enkelt att teoretiskt bevisa att koden delar all indata (som ryms i datatypen) med 2. Att faktiskt bevisa att det stämmer i verkligheten innebär att testa all möjlig indata, i alla möjliga kombinationer, på all hårdvara som programmet ska köras på (vilket innebär en oändlig mängd indata).

Edit/förtydligande: Tester kan ge ett rimligt antagande att koden är felfri (för de specifika fallen som testerna täcker). Men det är långt ifrån samma sak som att bevisa att inga buggar finns.

[lillahuset]

RIMLIGT, ja då är jag med. Glöm inte varianter på kompilatorer och bibliotek.
Jag har själv vid ett flertal tillfällen sett konsulter vi anlitade och anställda introducera fel i våra program bara för att de uppgraderade verktygen till senaste versionen. Gärna precis innan deadline för leverans. Det var verktyg som var "top of the line" så inget billigt krafs. Det slutade med att jag sammankallade hela gänget och upplyste dem att de inte fick byta verktyg utan min tillåtelse. Annars jävlar!