<\/span><\/h3>\n <\/p>\n
Statisk och dynamisk testning \u00e4r tv\u00e5 olika metoder f\u00f6r att verifiera programvara, med sina egna styrkor, svagheter och anv\u00e4ndningsomr\u00e5den. Att direkt v\u00e4lja mellan den ena och den andra \u00e4r inte ett realistiskt scenario eftersom de har olika funktioner.<\/p>\n
Statisk testning handlar om att vara proaktiv och identifiera problem s\u00e5 tidigt som m\u00f6jligt. Det handlar om att hitta och l\u00f6sa problem innan de uppst\u00e5r.<\/p>\n
Dynamisk testning \u00e4r mer reaktiv eftersom den letar efter buggar genom att k\u00f6ra koden. Ja, i allm\u00e4nhet \u00e4r det mer tids- och resurskr\u00e4vande \u00e4n statisk testning. Det hittar dock defekter som annars skulle ha uppt\u00e4ckts med enbart statisk testning.<\/p>\n
Det verkliga svaret h\u00e4r \u00e4r att genom att anv\u00e4nda statisk och dynamisk testning tillsammans kan du se till att din kod och relaterade dokument h\u00e5ller m\u00e5ttet och att programvaran uppfyller intressenternas f\u00f6rv\u00e4ntningar.<\/p>\n
<\/p>\n
<\/span>Vad testas under statisk testning?<\/strong><\/span><\/h2>\n![\"Olika](\"https:\/\/www.zaptest.com\/wp-content\/uploads\/2023\/09\/api-testing-1-jpg.webp\")
<\/p>\n
Statisk testning tittar p\u00e5 design, kod och dokument som utg\u00f6r ditt projekt. L\u00e5t oss g\u00e5 igenom de saker som testare beh\u00f6ver se upp f\u00f6r att s\u00e4kerst\u00e4lla en omfattande statisk testmetod.<\/p>\n
<\/span>1. Granskning av dokumentation<\/strong><\/span><\/h3>\nEn av de f\u00f6rsta delarna av statisk testning inneb\u00e4r en grundlig genomg\u00e5ng av dokumentationen. H\u00e4r \u00e4r n\u00e5gra av de dokument som hamnar under lupp.<\/p>\n
<\/span>Dokument med verksamhetskrav<\/strong><\/span><\/h4>\nTestarna granskar dokumentet med verksamhetskraven och s\u00e4kerst\u00e4ller att de p\u00e5 ett korrekt s\u00e4tt f\u00e5ngar intressenternas behov och \u00f6verensst\u00e4mmer med verksamhetsm\u00e5len.<\/p>\n
<\/span>Kravspecifikationer f\u00f6r programvara (SRS)<\/strong><\/span><\/h4>\nI dokumentet Software requirement specifications (SRS) beskrivs programvarans funktion och anv\u00e4ndbarhet. Statisk testning k\u00f6r regeln \u00f6ver detta dokument och s\u00e4kerst\u00e4ller att det korrekt beskriver programvarans funktionalitet, inklusive beroenden och anv\u00e4ndargr\u00e4nssnitt.<\/p>\n
<\/span>Konstruktionsdokument<\/strong><\/span><\/h4>\nKonstruktionsdokument granskas ocks\u00e5 f\u00f6r att s\u00e4kerst\u00e4lla att de uppfyller krav och specifikationer. Testare kontrollerar UML (Unified Modeling Language), datafl\u00f6de och arkitekturdiagram f\u00f6r att s\u00e4kerst\u00e4lla att de uppfyller projektkraven.<\/p>\n
<\/span>Dokument om anv\u00e4ndningsfall och anv\u00e4ndarber\u00e4ttelser<\/strong><\/span><\/h4>\nVid statisk testning granskas \u00e4ven anv\u00e4ndardokument och anv\u00e4ndarber\u00e4ttelser f\u00f6r att se hur de matchar de funktionella och icke-funktionella aspekterna av programvaran. I dessa dokument beskrivs lyckade anv\u00e4ndningsomr\u00e5den (avsedd framg\u00e5ngsrik anv\u00e4ndning), alternativa fl\u00f6den, edge cases och potentiella fel.<\/p>\n
<\/span>Testfall<\/strong><\/span><\/h4>\nDetta tidiga teststadium \u00e4r ett tillf\u00e4lle att granska testfall f\u00f6r att s\u00e4kerst\u00e4lla att de har tillr\u00e4cklig t\u00e4ckning, resurser, l\u00e4mpliga tekniker, realistiska tidsplaner och s\u00e5 vidare. Dessutom kommer granskningarna ocks\u00e5 att unders\u00f6ka om resultaten av testfallen \u00e4r detaljerade och realistiska.<\/p>\n
<\/p>\n
<\/span>2. Granskning av kod<\/strong><\/span><\/h3>\nD\u00e4refter kommer den kod som anv\u00e4nds f\u00f6r applikationen att granskas. H\u00e4r \u00e4r n\u00e5gra av de omr\u00e5den som testteamen kommer att titta n\u00e4rmare p\u00e5.<\/p>\n
<\/span>Syntaxfel<\/strong><\/span><\/h4>\nTestare och utvecklare g\u00e5r igenom koden och letar efter syntaxfel, stavfel, felaktiga variabelnamn, saknad interpunktion och andra misstag, sm\u00e5 eller stora, som kan orsaka fel n\u00e4r koden slutligen k\u00f6rs.<\/p>\n
<\/span>D\u00f6d kod<\/strong><\/span><\/h4>\nD\u00f6d kod, \u00e4ven kallad o\u00e5tkomlig kod, \u00e4r en del av ett programs k\u00e4llkod som inte kan exekveras p\u00e5 grund av problem med kontrollfl\u00f6det.<\/p>\n
<\/span>Oanv\u00e4nda variabler<\/strong><\/span><\/h4>\nStatisk testning kommer ocks\u00e5 att leta efter oanv\u00e4nda variabler, som deklareras men aldrig faktiskt exekveras av en kompilator.<\/p>\n
<\/span>\u00d6vertr\u00e4delser av kodningsstandarder<\/strong><\/span><\/h4>\nKodningsstandarder avser en upps\u00e4ttning b\u00e4sta praxis, regler och riktlinjer f\u00f6r kodning i ett visst spr\u00e5k. Statisk testning s\u00e4kerst\u00e4ller att b\u00e4sta praxis f\u00f6ljs, vilket g\u00f6r det enklare f\u00f6r andra att redigera, korrigera och uppdatera koden.<\/p>\n
<\/span>Logiska brister<\/strong><\/span><\/h4>\nLogiska brister kan inneb\u00e4ra att k\u00e4llkoden fungerar felaktigt men inte kraschar. Statiska granskningar syftar till att identifiera och l\u00f6sa dessa problem innan koden k\u00f6rs.<\/p>\n
<\/span>Datafl\u00f6den<\/strong><\/span><\/h4>\nTestarna unders\u00f6ker ocks\u00e5 hur data fl\u00f6dar in i och ut ur systemet. Denna granskning omfattar alla interaktioner som data kommer att ha inom programvaran.<\/p>\n
<\/span>Kontroll av fl\u00f6den<\/strong><\/span><\/h4>\nEtt annat omr\u00e5de som unders\u00f6ks \u00e4r kontrollfl\u00f6det. Denna granskning utforskar exekveringsordningen f\u00f6r koduttalanden och s\u00e4kerst\u00e4ller att saker och ting utf\u00f6rs i r\u00e4tt ordning f\u00f6r att s\u00e4kerst\u00e4lla att programvaran beter sig som avsett.<\/p>\n
<\/span>S\u00e4kerhetsproblem<\/strong><\/span><\/h4>\nStatisk testning kommer ocks\u00e5 att unders\u00f6ka eventuella s\u00e4kerhetsproblem i k\u00e4llkoden.<\/p>\n
<\/p>\n
<\/span>Statiska tekniker vid testning av programvara<\/strong><\/span><\/h2>\n![\"f\u00f6rdelar](\"https:\/\/www.zaptest.com\/wp-content\/uploads\/2023\/09\/pexels-thisisengineering-3862619-jpg.webp\")
<\/p>\n
Nu n\u00e4r du vet vilka saker som unders\u00f6ks vid statisk testning \u00e4r det dags att se hur dessa granskningar utf\u00f6rs.<\/p>\n
Det finns tv\u00e5 prim\u00e4ra statiska testtekniker inom programvarutestning som du beh\u00f6ver k\u00e4nna till f\u00f6r att kunna genomf\u00f6ra omfattande programvarutestning. De \u00e4r granskningsprocessen och statisk analys.<\/p>\n
<\/p>\n
<\/span>1. Granskningsprocessen vid statisk provning<\/strong><\/span><\/h3>\nGranskningsprocessen \u00e4r den f\u00f6rsta delen av implementeringen av statiska tekniker i programvarutestning. Tanken \u00e4r att hitta och ta bort fel i programvarans design. Vanligtvis finns det fyra huvudsteg i granskningsprocessen f\u00f6r statisk testning.<\/p>\n
<\/span>Informell granskning<\/strong><\/span><\/h4>\nEn informell granskning \u00e4r precis vad det l\u00e5ter som: en ostrukturerad brainstormingrunda d\u00e4r utvecklare, testare och intressenter kan utforska potentiella problem och l\u00e4gga fram fr\u00e5gor och f\u00f6rslag om programvaran. Det \u00e4r ett tillf\u00e4lle att identifiera eventuella stora brister eller problem innan du g\u00e5r vidare till n\u00e4sta steg.<\/p>\n
<\/span>Genomg\u00e5ngar<\/strong><\/span><\/h4>\nGenomg\u00e5ngar \u00e4r en chans f\u00f6r testteam att g\u00e5 djupare. Ofta inneb\u00e4r det att en eller flera experter g\u00e5r igenom dokumentationen f\u00f6r att s\u00e4kerst\u00e4lla att allt st\u00e4mmer \u00f6verens med aff\u00e4rs- och systemkraven.<\/p>\n
<\/span>Peer review<\/strong><\/span><\/h4>\nI n\u00e4sta steg granskar ingenj\u00f6rerna varandras k\u00e4llkod f\u00f6r att se om de kan uppt\u00e4cka fel som m\u00e5ste \u00e5tg\u00e4rdas innan programvaran k\u00f6rs.<\/p>\n
<\/span>Inspektion<\/strong><\/span><\/h4>\n