Vika

Virhe- tai ohjelmistovirheet tai ohjelmisto -poikkeama usein myös keula ( englanniksi kutsutaan), termit ovat ohjelmistotekniikasta , jolla järjestelmäkomponentit ohjelmisto, poikkeamat viitataan vaadittuun tai haluttuun kohdetilaan. Tämä voi tapahtua, jos z. B. tietty määritelmän määritelmä on väärä tai se on toteutettu väärin , ja se johtaa aluksi sisäiseen virhetilaan ohjelmassa , mikä puolestaan ​​johtaa odottamattomaan käyttäytymiseen tai tulokseen, kun ohjelma suoritetaan.

Ohjelmavirheiden mahdollisimman kattava havaitseminen ja poistaminen, yleensä ohjelmistokehitysprosesseissa , ts. H. Ennen ohjelmistojen todellista "tuottavaa" käyttöä käy läpi " ohjelmistotestaus " -projektivaihe , jonka aikana suoritetaan validointi. Prosessin aikana tapahtuvat virheet ovat yleisiä, ja testauksen tavoitteena on löytää ne, kun taas käytön aikana ilmenevät virheet voivat edustaa kriittisiä poikkeavuuksia / toimintahäiriöitä virheen vaikutuksesta riippuen. Käytännössä tietokoneohjelmat esiintyvät harvoin ilman ohjelmavirheitä. Ohjelmien laatuominaisuus tunnetaan mm. vika tiheys . Se kuvaa virheiden lukumäärää 1000 koodiriviä ( kilon lähdekoodiriviä ) tai toimintopistettä kohti .

Niin kutsutut debuggerit , joiden avulla ohjelma voidaan suorittaa ja ohjata askel askeleelta, ovat hyödyllisiä erityisiä välineitä ohjelmien virheiden syiden etsimiseen . Erityisen kriittisten ohjelmistojen (esim. Lentokoneen ohjaus) tapauksessa suoritetaan toisinaan (monimutkainen) muodollinen vahvistus .

Tallennukseen ja dokumentointiin käytetään ns. Vikaseurantaa (kuten Bugzilla tai Mantis ). Näitä ovat virheraportit sekä parannusehdotukset ja käyttäjien tai yleisten prosessien pyynnöt (ns. Ominaisuuspyynnöt ). Katso myös vianhallinta .

Ohjelmavirheen poistamisprosessia kutsutaan puhekielessä virheenkorjaukseksi . Parannuksen tulosta kutsutaan teknisellä tavalla virheenkorjaukseksi, korjaukseksi tai ohjelmistopäivitykseksi .

Määritelmät

Ohjelma tai ohjelmisto virhe on, perustuvat yleiseen määritelmä " virhe "

"Vaatimuksen täyttämättä jättäminen (EN ISO 9000: 2005)".

Virhe määritetään tällöin erityisesti

"TODELLISEN (havaitut, määritetyt, lasketut tilat tai prosessit) poikkeama TARGETista (määritellyt, oikeat tilat ja prosessit), jos se ylittää ennalta määritetyn toleranssin rajan [joka voi olla myös 0]."

Mukaan ISTQB termi 'virhe' muodostuu seuraavista yhteyksissä:

• viallinen toiminta (Englanti Error)

"Ihmisen toiminta, joka johtaa virhetilaan ([IEEE 610: n mukaan])"

• ... johtaa virhetilaan (englanninkielinen vika)

"Vika (sisäinen vikatilanne) osassa tai järjestelmässä, joka voi heikentää tuotteen vaadittua toimintaa ..."

• vikailmiö voi (engl. laiminlyönti) johtavat

"Sisäinen virhe [ohjelman] suorittamisessa virheellisenä toimintana tai tuloksena tai järjestelmän toimintahäiriönä."

Esimerkki jako nollalla : Virheellinen toiminta: Nollaa mahdollisena syöttöarvona ei tarkistettu / suljettu pois; Virhetila: Ohjelma on (mahdollisesti huomaamatta) viallinen; Epäonnistuminen: syöttäminen Tyhjäarvo aiheuttaa runtime error kun suorittamalla komennon .

Ilmaisuja, kuten ongelma, vika, poikkeama, poikkeama, puute käytetään myös synonyyminä varten ”virhe” tai sen lisäksi. Tämä tarkoittaa, että "virheen vakavuus" voidaan erottaa myös käsitteellisesti, esim. B. ohjelmointityylisääntöjen rikkominen , virheellisten tulosten saaminen tai ohjelman lopettaminen .

"Bug" synonyyminä ohjelmavirheelle

Mark II Aiken Relay -laskurin lokikirja -sivu ensimmäisellä virheellä (1947)

Sana bug tarkoittaa englanniksi " Schnabelkerf ; Bug "ja puhekielessä" maaseudun niveljalkaiset "tai" (hyönteisen kaltaiset) tuholaiset ". Vuonna ammattikieltä amerikkalaisten insinöörien , merkityksessä "vika" tai "rakentaminen virhe" on todistettu loppupuolelta lähtien 19th century; Tämä sanan käyttö perustuu (vitsi) ajatukseen, että pienet ryömivät karjat sekoittavat vaihteiston, linjan jne. Vanhin todiste on kaksi Thomas Edisonin kirjettä vuodelta 1878 William Ortonille , Western Unionin presidentille ja Tivadar Puskásille , puhelinkeskuksen keksijälle , jossa sanotaan:

kuten

Edison ei ole keksijä, mutta ainakin keskeinen todistaja tuolloin kiertäneen sanan merkitykselle. Termin yhdistäminen tietokoneisiin ulottuu mahdollisesti tietokoneiden edelläkävijään Grace Hopperiin . He levittivät tarinan siitä, että 9. syyskuuta 1945 koi toiminut releen toimintahäiriössä Mark II Aiken Relay Calculator -tietokoneessa . Koi poistettiin, juuttui lokikirjaan ja sille annettiin seuraava huomautus: ” Ensimmäinen todellinen vian tapaus löydettiin. ”(Saksa:“ Ensimmäinen kerta, kun ”tuholaisia” todella löydettiin. ”). Legenda termin löytämisestä jatkuu, vaikka lokikirjamerkintä osoittaa, että termi oli jo käytössä. Lisäksi Grace Hopper oli väärässä vuonna: Tapaus todella tapahtui 9. syyskuuta 1947. Vastaava sivun päiväkirjasta pidettiin tässä Naval Surface Warfare Centre Computer Museum of Yhdysvaltain laivaston vuonna Dahlgren , Virginia 1990-luvun alkupuolelle . Tämä lokipäiväkirja koineen on tällä hetkellä Smithsonian -instituutissa .

Virheiden tyypit

In Software Engineering (katso myös) erotetaan välillä seuraavanlaisia virheitä ohjelmissa:

• Leksiset virheet ovat merkkijonoja, joita ei voida tulkita, eli määrittelemättömät tunnisteet (muuttujat, funktiot, kirjaimet ...)
• Syntaksivirheet ovat käytetyn ohjelmointikielen kielioppisääntöjen rikkomuksia, esimerkiksi varattujen symbolien (esim. Puuttuvat hakasulkeet) virheellinen käyttö, tyyppiristiriidat, virheellinen parametrimäärä.

Leksiset ja syntaksivirheet estävät yleensä viallisen ohjelman kokoamisen, ja siksi ne tunnistetaan varhaisessa vaiheessa. Ohjelmointikielillä, joita tulkitaan peräkkäin , ohjelma katkeaa yleensä vain syntaktisesti / sanallisesti virheellisessä kohdassa.

• Semanttiset virheet ovat virheitä, joissa ohjelmoitu käsky on syntaktisesti oikea, mutta sisällöltään kuitenkin virheellinen, esimerkiksi komentokoodin sekoitus, väärä parametrijärjestys, jota ei voida tunnistaa syntaktisesti.
• Loogiset virheet koostuvat ongelmanratkaisumenetelmästä, joka on yksityiskohtaisesti väärä, esimerkiksiväärän johtopäätöksen , väärin tulkitun spesifikaation tai yksinkertaisesti laiminlyönnin tai kirjoitusvirheen vuoksi. Esimerkkejä: plus sijasta miinus, pienempi sijasta pienempi / yhtä suuri, jne. Toleranssi tällaisia virheitä ja attribuutti kielioppion ohjelmointikieliä, jotka ontarkoitettu rajoittamaan niitä, kuten osoituksen yhteensopivuuttaja tietotyypit , ovathyvin erilaisiariippuen käytetystä ohjelmointikielestä ja voi olla vaikea ymmärtää tietoturva -aukkoja ja aiheuttaa ohjelman kaatumisia.
• Suunnitteluvirheet ovat virheitä peruskäsitteessä, joko ohjelmistoa koskevien vaatimusten määrittelyssä tai ohjelmistosuunnittelun kehittämisessä, jonka perusteella ohjelma kehitetään. Vaatimusten määrittelyssä esiintyvät virheet johtuvat usein tiedon puuttumisesta aihealueesta, jolle ohjelmisto on kirjoitettu, tai käyttäjien ja kehittäjien välisistä väärinkäsityksistä. Toisaalta suoraan ohjelmistosuunnittelussa esiintyvät virheet johtuvat usein ohjelmistokehittäjän kokemuksen puutteesta , strukturoimattomasta ohjelmoinnista tai myöhemmistä virheistä, jotka johtuvat vaatimusten määrittelyssä olevista virheistä . Muissa tapauksissa suunnittelu on kasvanut ajan myötä ja muuttuu sekavaksi ajan myötä, mikä puolestaan ​​voi johtaa suunnitteluvirheisiin, kun ohjelmaa kehitetään edelleen. Usein ohjelmointi suoritetaan suoraan ilman oikeaa konseptia , mikä voi johtaa suunnitteluvirheisiin, varsinkin jos ohjelmisto on monimutkaisempi. Virheissä vaatimusten määrittelyssä ja ohjelmistosuunnittelussa kustannus- tai aikapaineet ovat usein ongelma. Tyypillinen suunnitteluvirhe on koodin toistaminen , joka ei johda suoraan ohjelmavirheisiin, mutta joka voidaan helposti jättää huomiotta ohjelmiston ylläpidon , ohjelmakoodin muuttamisen tai laajentamisen aikana ja johtaa väistämättä haittavaikutuksiin.
• Virhe käyttökonseptissa. Ohjelma käyttäytyy eri tavalla kuin yksittäiset tai monet käyttäjät odottavat, vaikka se on teknisesti virheetön.

Muut virheilmoitukset

• Suorituksenaikaiset virheet : Vaikka yllä mainitut virheet tarkoittavat todella viallista ohjelmaa, jota ei voida suorittaa tai se tuottaa vääriä tuloksia, "oikea" ohjelma voi myös aiheuttaa virheitä suoritettaessa. Suorituksenaikaiset virheet ovat kaikenlaisia ​​virheitä, joita esiintyy ohjelman käsittelyn aikana. Tilanteesta riippuen syy voi olla esimerkiksi epäsopiva ohjelmaympäristö (esim. Väärä käyttöjärjestelmäversio , väärät parametrit kutsuttaessa ohjelmaa (myös aliohjelmana ), väärät syöttötiedot jne.)

Suorituksenaikaiset virheet voivat näkyä monella tavalla. Ohjelma näyttää usein ei -toivottua käyttäytymistä, ääritapauksissa ohjelman suoritus keskeytetään ("kaatuminen") tai ohjelma menee tilaan, jossa se ei enää hyväksy käyttäjän syötteitä ("jäädyttää", "ripustaa").

Toista mediatiedosto

Esimerkki ohjelmavirheestä

Jos ohjelmointikielillä, joissa ei ole automaattista roskien keräystä (esim. C tai C ++ ), muistia ei enää vapauteta käytön jälkeen, ohjelma vie pitkällä aikavälillä yhä enemmän muistia. Tätä tilannetta kutsutaan muistivuodoksi . Samankaltaisia ​​ongelmia voi kuitenkin ilmetä myös ohjelmointikielissä, joissa on automaattinen roskien keräys (esim. Java tai C # ), jos esimerkiksi esineitä kerätään hallitsemattomasti alhaisen tason ohjelmoinnin vuoksi . Vielä kriittisempiä ovat ohjelmoijan vahingossa vapauttamat muistialueet, joihin usein viitataan edelleen riippuvilla osoittimilla , koska tämä voi johtaa ohjelmiston täysin hallitsemattomaan käyttäytymiseen. Jotkin ajonaikaiset ympäristöt eivät yleensä salli tällaisia ​​ohjelmoitavia muistin vapautuksia. On myös vikoja vuorovaikutuksessa muiden ohjelmien kanssa.

• Virheet kääntäjässä, ajonaikaisessa ympäristössä tai muissa kirjastoissa. Tällaisia ​​virheitä on yleensä erityisen vaikea ymmärtää, koska ohjelman käyttäytyminen tällaisissa tapauksissa ei vastaa sen semantiikkaa. Erityisesti kääntäjän ja ajonaikaisen ympäristön odotetaan siksi olevan erityisen luotettava.
• Regressio bug ( regressio tarkoittaa "askel taaksepäin") on virhe, joka tulee näkyviin vain myöhemmässä ohjelman versio. Nämä ovat usein havaitsemattomia sivuvaikutuksia virheenkorjauksista tai ohjelmamuutoksista muualla.
• Fyysisistä käyttöolosuhteista johtuvat virheet . Monenlaiset tapahtumat, kuten sähkömagneettiset kentät, säteily, lämpötilan vaihtelut, tärinä jne., Voivat myös johtaa virheisiin järjestelmissä, jotka on muuten konfiguroitu ja joita käytetään eritelmien mukaisesti. Tämän tyyppiset virheet ovat hyvin epätodennäköisiä, niitä on erittäin vaikea havaita ja niillä voi olla kohtalokkaita seurauksia reaaliaikaisissa sovelluksissa. Tilastollisista syistä niitä ei kuitenkaan voida sulkea pois. Kuuluisa "bitin putoaminen" muistiin tai kiintolevylle kuvattujen vaikutusten vuoksi on esimerkiksi tällainen virhe. Tällaisen virheen seurauksena (esim. Järjestelmän kaatuminen tai kyvyttömyys käynnistää, koska järjestelmätiedosto on josta muut ohjelmavirheet on yleensä erittäin vaikea erottaa, usein epäillään toista syytä, varsinkin kun tällaista virhettä ei usein voida toistaa.
• Ohjelmavirheet vs. ohjelmistovirheet: Sikäli kuin näitä kahta termiä ei ymmärretä synonyymeinä, '' ohjelmistovirheille '' voidaan soveltaa myös laajempaa määritelmää - tietokoneohjelman ja ohjelmiston merkityseron mukaisesti : Tämän mukaan virheitä tai puutteita dokumentaatiossa olisi myös ohjelmistovirheitä riippumatta siitä, johtivatko ne viallisiin ohjelmiin. Virheellisiä tietoja (tämä termi on myös määritetty ohjelmistolle määritelmän mukaan) ei pitäisi pitää ohjelmavirheenä, vaan pikemminkin, jos ollenkaan, ohjelmistovirheenä.

Joissakin projekteissa termiä bug ei käytetä, vaan esimerkiksi metabugs, jossa vika on osa tehtäväluetteloa. Joissakin projekteissa käytetään termiä "ongelmat", koska tämä termi ei rajoitu virheisiin.

Esimerkkejä virheistä, joilla on erityinen mediavaikutus, on luettelossa ohjelmavirheesimerkkejä .

Taloudellinen merkitys

Ohjelmistovirheet ovat ohjelmistokehittäjille paljon enemmän kuin vain ärsyttäviä liitännäisolosuhteita; ne aiheuttavat huomattavia kustannuksia liiketoiminnallisesta ja taloudellisesta näkökulmasta . IX -tutkimus 1/2006 osoitti z. B. seuraavat Saksalle määritetyt arvot:

• Keskisuurten ja suurten yritysten ohjelmistovirheistä johtuvat vuosittaiset tappiot ovat noin 84,4 miljardia euroa
• Ohjelmavirheiden poistamiseen käytetään vuosittain noin 14,4 miljardia euroa (35,9% IT -budjetista) .
• Viallisista ohjelmistoista johtuvista tietokonevikoista johtuvat tuottavuushäviöt ovat noin 70 miljardia euroa

Samassa tutkimuksessa tarkastellaan myös ohjelmistojen laadun kehitystä vuosina 2002-2004 - tuloksena:

• epäonnistuneiden hankkeiden määrä nousi 15 prosentista 18 prosenttiin
• onnistuneiden hankkeiden osuus laski 34 prosentista 29 prosenttiin
• kustannuksia ylittävien hankkeiden määrä nousi 43 prosentista 56 prosenttiin
• määräaikoja myöhästyneiden hankkeiden määrä nousi 82 ​​prosentista 84 prosenttiin
• sopivien toimintojen hankkeiden määrä laski 67 prosentista 64 prosenttiin

Yhdysvaltain liittohallituksen korkeimman tilintarkastustuomioistuimen raportti uusista projekteista (1985) osoittaa erityisen paljon epäonnistumisia, joiden mukaan

• 27% maksetuista ohjelmistoista ei koskaan toimitettu,
• 52% ei koskaan työskennellyt,
• 18% käytettiin vasta laajan kunnostuksen jälkeen.
• Vain 3% tilatuista ohjelmistoista täytti sovitut sopimusehdot.

Standish Group International totesi: Keskimäärin hankkeet ylittävät

• hankkeen kustannukset alun perin 89%
• aikataulutetuista tapaamisista 222%.

Ewusi-Menach tunnistettiin seuraavat tekijät , kuten syitä hankkeen peruutuksia huonon ohjelmistojen laatu:

• Tavoite epäselvä
• Väärä projektitiimin ammatti
• Riittämätön laadunvarmistus
• Teknisen osaamisen puute
• Riittämätön lähtötilanteen huomioon ottaminen
• Käyttäjien osallistumisen puute

Ohjelmavirheiden välttäminen ja korjaaminen

Yleensä mitä aikaisemmin kehitysprosessissa virhe ilmenee ja mitä myöhemmin se havaitaan, sitä enemmän aikaa vie virheen korjaaminen.

Suunnittelun aikana

Tärkeintä on hyvä ja asianmukainen suunnitteluprosessi. On jo olemassa useita menettelytapamalleja , joista voidaan valita sopiva.

Analyysivaiheessa

Yksi ongelma on se, että ohjelman oikeellisuus voidaan osoittaa vain asianmukaisesti muotoiltua spesifikaatiota vastaan. Tällaisen määrityksen luominen voi kuitenkin olla yhtä monimutkaista ja virhealtista kuin itse ohjelman ohjelmointi.

Yhä abstraktimpien ohjelmointimallien ja ohjelmointityylien , kuten toiminnallisen ohjelmoinnin , olio-ohjelmoinnin , sopimussuunnittelun ja näkökulmallisen ohjelmoinnin, kehittäminen auttaa muun muassa välttämään virheitä ja yksinkertaistamaan vianetsintää. Käytettävissä olevista tekniikoista on valittava sopiva tekniikka ongelmaan. Tärkeä asia tässä on se, että kokeneiden ohjelmoijien on oltava käytettävissä kullekin paradigmalle, muuten syntyy usein päinvastainen vaikutus.

On myös erittäin hyödyllistä antaa kehitystyökalujen hoitaa mahdollisimman monta virheiden välttämisen tehtävää luotettavasti ja automaattisesti. B. helpotetaan jäsennellyn ohjelmoinnin avulla . Tämä koskee yhtäältä säätimiä, kuten näkyvyyssääntöjä ja tyyppiturvallisuutta , sekä pyöreiden viittausten välttämistä, jotka kääntäjä voi hyväksyä ennen ohjelmien kääntämistä , mutta myös ohjauksia, jotka voidaan suorittaa vain ajon aikana, kuten indeksi tarkastuksia varten tietokenttien tai tyyppi tarkistaa esineiden olio-ohjelmointi.

Suunnitteluvaiheessa

Ohjelmistoasiantuntijat ovat yhtä mieltä siitä, että käytännössä jokainen ei-triviaali ohjelma sisältää virheitä. Siksi on kehitetty tekniikoita ohjelmien virheiden käsittelemiseksi suvaitsevaisesti. Näitä tekniikoita ovat puolustava ohjelmointi , poikkeusten käsittely , redundanssi ja ohjelmien seuranta (esim. Vahtikoira -ajastimien käyttäminen) sekä ohjelman uskottavuuden tarkistus kehityksen aikana ja tiedot ohjelman aikana.

Ohjelmoitaessa

Lisäksi tarjotaan useita kehittyneitä sovelluksia, jotka analysoivat joko lähdekoodia tai binaarikoodia ja yrittävät löytää usein automaattisesti tehtäviä virheitä. Tämä luokka sisältää ohjelmat suorituksen seurantaan, jotka yleensä havaitsevat luotettavasti väärät muistin käyttömuistit ja muistivuodot . Esimerkkejä ovat vapaasti saatavilla oleva työkalu Valgrind ja kaupallinen Purify . Toinen testiohjelmien luokka sisältää sovelluksia, jotka analysoivat staattisesti lähde- tai binaarikoodia, kuten suljettujen resurssien etsiminen ja raportointi ja muut ongelmat. Näitä ovat FindBugs , Lint ja Splint .

Kun testataan

On järkevää, että testi kehitetään ennen varsinaista ohjelmaa. Tämä varmistaa, että testiä ei kirjoiteta vastaamaan jo kirjoitettua ohjelmaa . Tämä voidaan tehdä aikana analyysin tai suunnitteluvaiheessa määrittämällä testi tapauksissa perustuu selityksessä . Testitapausten määrittäminen tässä ohjelmistokehityksen alkuvaiheessa mahdollistaa myös ohjelman vaatimusten testattavuuden ja täydellisyyden tarkistamisen. Eritelmän perusteella määritetyt testitapaukset ovat hyväksymistestien perusta - niitä kehitetään jatkuvasti koko kehitysprosessin ajan ja z. B. voidaan valmistaa testiautomaatiota varten .

Jotkut ohjelmistotoimittajat suorittavat joskus testivaiheita julkisesti ja julkaisevat beta -versioita, jotta he voivat testata ja kommentoida eri käyttäjien arvaamattomasti erilaisia ​​käyttöolosuhteita.

Toiminnallinen

Jos virhe ilmenee käytön aikana, sen vaikutukset on pyrittävä pitämään mahdollisimman alhaisina ja toiminta -alaa rajoittamalla luomalla "suojaseiniä" tai "suojatoimia". Tämä edellyttää toisaalta kykyä havaita virheitä ja toisaalta pystyä reagoimaan virheeseen riittävästi.

Esimerkki virheiden havaitsemisesta tietokoneohjelman ajon aikana ovat väitteet , joiden avulla haetaan ehtoja, jotka täyttyvät aina ohjelman suunnittelun mukaisesti. Muita mekanismeja ovat poikkeusten käsittely , kuten ansa ja poikkeus.

Toteuttamalla todistuskanavan ohjelmisto voi taata ja varmistaa luotettavuutensa jossain määrin ajon aikana.

Virheetön

Täydellinen vapaus virheistä ohjelmistoissa, jotka ylittävät tietyn monimutkaisuusrajan, ei käytännössä ole saavutettavissa eikä todennettavissa. Kun monimutkaisuus lisääntyy, yleiskuva vähenee, varsinkin jos ohjelmointiin osallistuu useita ihmisiä. Jopa kallis tai laajasti testattu ohjelmisto sisältää ohjelmointivirheitä. Käytettävien ohjelmien tapauksessa puhutaan sen sijaan kestävyydestä eikä virheistä . Ohjelmistoa pidetään kestävänä, jos virheitä esiintyy vain hyvin harvoin ja ne aiheuttavat sitten vain pieniä haittoja eivätkä aiheuta suuria vahinkoja tai menetyksiä.

Erityistapauksissa on mahdollista todistaa, että ohjelmassa ei ole virheitä (määritettyjen vaatimusten osalta). Erityisesti alueilla, joilla ohjelmistojen käyttöön liittyy suuria taloudellisia, taloudellisia tai inhimillisiä riskejä, kuten Esimerkiksi sotilaallisiin tai lääketieteellisiin tarkoituksiin tai ilmailuteollisuudessa käytettäviin ohjelmistoihin käytetään myös (muodollista) tarkistusta , jota kutsutaan ohjelmiston oikeellisuudeksi. Valtavien ponnistelujen vuoksi tällä menetelmällä on kuitenkin tiukat rajat, ja siksi sitä on käytännössä mahdotonta toteuttaa monimutkaisilla ohjelmilla (katso myös ennustettavuus ). Nyt on kuitenkin olemassa työkaluja, jotka omien tietojensa mukaan voivat toimittaa tämän näytön nopeasti ja luotettavasti ainakin osittain ( ajonaikaiset virheet ).

Matemaattisen todentamisen lisäksi on myös käytännön todentamismuoto, joka kuvataan laadunhallintastandardissa ISO 9000 . Sen avulla virhe muodostuu muodollisesti vain, jos vaatimus ei täyty. Sitä vastoin työn tulos (ja siten myös ohjelmisto ) voidaan kuvata virheettömäksi, jos se todistettavasti täyttää kaikki vaatimukset. Vaatimuksen täyttyminen määritetään testeillä . Jos kaikki vaatimukselle määritellyt testit tuottavat odotetut tulokset, vaatimus on täytetty. Jos tämä koskee kaikkien vaatimusten testejä (olettaen, että testaus on oikea ja täydellinen), päätellään, että vaatimuksissa ei ole virheitä. Jos testien perusteet ovat virheellisiä tai puutteellisia, ohjelmisto ei edelleenkään toimi "toivotulla tavalla".

Puutteiden luokittelu

Tapahtuvat virheet käsitellään yleensä järjestelmällisesti virheiden hallinnassa . IEEE-standardin 1044 (ohjelmistojen poikkeavuuksien luokittelu) mukaan jokainen virhe käy läpi niin kutsutun luokitusprosessin, joka koostuu neljästä vaiheesta: tunnistus, analyysi (tutkimus), käsittely (toiminta) ja päättäminen (disposition). Kussakin näistä vaiheista suoritetaan hallinnolliset toimet, jotka kirjaavat, luokittelevat ja tunnistavat vaikutukset.

Kriteerit, joiden mukaan virheet voidaan luokitella, ovat: (esimerkkien kanssa):

• Virhetyyppi: Erotetaan toisistaan: leksikaaliset virheet (tuntematon viite), syntaktiset virheet (unohdettu puolipiste), semanttiset virheet (väärä ilmoitus ), ajonaikaiset virheet (väärin muotoiltu syöttötieto) ja loogiset virheet (plus miinuksen sijaan, silmukka) virheitä , ...)
• virheen syy: epätarkat määritykset, käännetyt numerot, väärä kaava, tarkistamattomat (väärät) syöttötiedot ...
• ajankohta, jolloin virhe tapahtui ('väärä toiminto'): Jo ohjelmaspesifikaatiossa, koodiluonnoksessa, koodauksessa, ...
• Virheen ilmenemisaika ("virhevaikutus"): Perusero johtuu siitä, ilmeneekö virhe ohjelman kehittämisen aikana, esimerkiksi testauksen aikana (tässä tapauksessa tämä on normaali tapaus) vai tuottavassa toiminnassa (missä se usein edustaa kriittistä tilannetta) vika).
• löytöaika: mitä pidempi "virheen viipymisaika", sitä enemmän aikaa vievä i. A. Korjaustoimenpide jatkuu.
• virheen vaikutus (vaikutukset): näyttövirheet, virheelliset tulokset, ohjelman lopetus, ulkoiset vaikutukset ...
• Vianmäärityksen ponnistelut ja kesto: minimaalinen ... erittäin korkea; välittömästi ... erittäin pitkä kesto;
• Käsittelyn tila: tapahtunut, tutkittu, korjausjärjestys käynnissä, mahdollinen uusintatesti , ..., valmis

Avulla mittareita, "tulokset [ja havainnot virheistä] olisi myös syytä etsiä syitä takana ongelmia". "Virheluokitukset muodostavat perustan standardoiduille virheidenkäsittelymenettelyille ja tukevat myös jatkuvaa laadun parantamista laadunhallinnan kannalta ." Kutakin virhettä koskevia lisätietoja, kuten yksityiskohtainen virheen kuvaus, ohjelmat, asiaan liittyvät henkilöt jne. poistaa virheet ja dokumentoida ne. Lisätietoja on BITKOM -oppaassa.

Yksinkertaisuuden vuoksi virheet käsittelyprosessin ohjelmavirheet jaetaan usein vain luokkiin / luokkiin, kuten A, B, C ... tai 1, 2, 3 ... jne. Virheen vakavuuden mukaan, joka sisältää myös virheen vaikutuksen ja sen korjaamiseen tarvittavat ponnistelut. Esimerkkejä on BITKOM -ohjeissa, erityisesti liitteessä.

Ohjelmavirheiden seuraukset

Ohjelmavirheiden seuraukset voivat vaihdella suuresti ja ilmetä monin eri tavoin. Jos virheitä havaitaan kehitysprosessin aikana, virheen seuraukset rajoittuvat myös ohjelmiston tarkistamiseen (koodikorjaukset, konseptin tarkistus, dokumentaatio ...) - riippuen tilanteesta, jolla on suurempi tai pienempi vaikutus hankkeen budjettiin ja projektin kesto. Toisaalta virheillä, jotka tunnistetaan vain tuotannollisessa toiminnassa, on usein kriittisempi vaikutus, esimerkiksi ne voivat aiheuttaa prosessihäiriöitä tai tuotantokatkoksia, vahingoittaa imagoa, aiheuttaa asiakkaiden ja markkinoiden menetyksen, aiheuttaa takaisinvelvollisuutta tai jopa vaarantaa yrityksen olemassaolosta. Pahimmassa tapauksessa virheet teknisissä sovelluksissa voivat johtaa katastrofeihin.

Esimerkkejä ohjelmavirheistä ja niiden seurauksista on luettelossa ohjelmavirheesimerkkejä .

Ohjelmavirheiden toistettavuus

Jotkin ohjelmavirheet ovat erittäin vaikeita tai mahdottomia toistaa luotettavasti. Jos aiemmin epäonnistunut prosessi toistetaan ilmeisesti muuttumattomissa olosuhteissa, on todennäköistä, että näitä virheitä ei ilmaista uudelleen. Tähän käyttäytymiseen on kaksi mahdollista syytä: Toisaalta virheen aktivoinnin ja lopulta ilmenneen ongelman välillä voi olla viiveitä, esimerkiksi ohjelman kaatuminen, joka peittää todellisen syyn ja vaikeuttaa tunnistamista. Toisaalta muut ohjelmistojärjestelmän osat (laitteisto, käyttöjärjestelmä, muut ohjelmat) voivat vaikuttaa tarkasteltavan ohjelman virheiden käyttäytymiseen. Esimerkki tästä ovat virheet, joita esiintyy samanaikaisissa ympäristöissä, joissa synkronointi on riittämätöntä (tarkemmin sanottuna: sekvensointi ). Tästä johtuvien kilpa -olosuhteiden vuoksi prosessit voidaan käsitellä järjestyksessä, joka johtaa ajonaikaiseen virheeseen. Jos sama toimenpide toistetaan, on mahdollista, että prosessien järjestys on erilainen eikä ongelmia synny.

Lisää aiheita

• Katso "epäkypsien" ohjelmistojen toimittamisen periaate banaaniperiaatteesta # Banaanitavarat .
• Ohjelmistot, joita (usein tarjotaan ilmaiseksi) esim. B. on puutteita tietoturvassa, selkeydessä tai käyttökelpoisuudessa; katso crapware

kirjallisuus

• William E. Perry: Ohjelmistotestaus. Mitp-Verlag, Bonn 2002, ISBN 3-8266-0887-9 .
• Elfriede Dustin, Jeff Rashka, John Paul: Ohjelmiston automaattinen testaus . Menettely, käsittely ja suorituskyky. Springer, Berliini et ai. 2001, ISBN 3-540-67639-2 .
• Cem Kaner, Jack Falk, Hung Quoc Nguyen: Tietokoneohjelmiston testaus. 2. painos. John Wiley & Sons, New York NY et ai. 1999, ISBN 0-471-35846-0 .

nettilinkit

Wikisanakirja: vikoja  - selityksiä merkityksistä, sanojen alkuperästä, synonyymeistä, käännöksistä

• 25 vaarallisinta ohjelmointivirhettä (englanti)
• SQS: Vuoden 2012 näyttävimmät ohjelmistovirheet. In: Computerwoche. 17. tammikuuta 2013, käytetty 20. tammikuuta 2013 . 

Yksilöllisiä todisteita

1. ↑ ^{a b c} M. Pol, T. Koomen, A. Spillner: Testausprosessin hallinta ja optimointi. dpunkt.Verlag, Heidelberg 2002, ISBN 3-89864-156-2 .
2. ↑ Spillner et ai. Käytännön tiedon ohjelmistotesti - testinhallinnan lukunäyte, luku. 1.1 Perustiedot / määritelmä virheiden ( Memento joulukuusta 17 2010 in Internet Archive ) (PDF) dpunkt.de
3. ↑ Merriam-Webster Unabridged Dictionary (iOS-App, 2016): vika: a) hyönteinen tai muu hiipivä tai indeksoiva selkärangaton ... b) mikä tahansa tietty hyönteinen, jota pidetään yleisesti erityisen vastenmielisenä ... c) Hemiptera-luokan hyönteinen , erityisesti: a alaryhmän Heteroptera jäsen ...
4. ↑ The Papers of Thomas A. Edison, voi. 4, toim. Paul B. Israel, Baltimore ja Lontoo, 1993. Online [1].
5. ^ Fred R. Shapiro: Tietokonevirheen etymologia: historia ja kansanperinne . Julkaisussa: American Speech 62: 4, 1987, s.376-378.
6. ↑ ^{a b} informatik.uni-oldenburg.de
7. ↑ iX-Magazin , Study Software Test Management , oli aiemmin saatavilla IX-kioskissa ( Memento 9. tammikuuta 2013 Internet-arkistossa )
8. ↑ ^{a b} Wallmüller: Software Quality Management in Practice, beck-shop.de (PDF; 612 kB), Hanser, München 2001, ISBN 978-3-446-21367-8 .
9. ↑ Junginger: Arvopohjainen riskienhallinta tiedonhallinnassa . 2005, ISBN 3-8244-8225-8 .
10. ^ Georg Edwin Thaller -ohjelmistotesti, vahvistus ja validointi 2002, ISBN 978-3-88229-198-8 .
11. ↑ my.safaribooksonline.com
12. ↑ IEEE -standardiluokitus ohjelmiston poikkeavuuksia varten. (PDF) IEEE Standards Board, 1993, s. 32 , käyty 22. marraskuuta 2014 (valkoinen kirja; asiakirja Paywallin takana). 
13. ↑ ^{a b c} Ohjelmistojen vikaluokitus. BITKOM, joulukuu 2007, arkistoitu alkuperäisestä 16. huhtikuuta 2019 ; luettu 11. huhtikuuta 2021 .