<\/span><\/h3>\n <\/p>\n
Statisk og dynamisk test er to forskellige tilgange til at verificere software med hver deres styrker, svagheder og v\u00e6rkt\u00f8jer. At v\u00e6lge direkte mellem den ene og den anden er ikke et realistisk scenarie, fordi de har forskellige funktioner.<\/p>\n
Statisk test handler om at v\u00e6re proaktiv og identificere problemer s\u00e5 tidligt som muligt. Det handler om at finde og l\u00f8se problemer, f\u00f8r de opst\u00e5r.<\/p>\n
Dynamisk test er mere reaktiv, fordi den leder efter fejl ved at k\u00f8re koden. Ja, generelt er det mere tids- og ressourcekr\u00e6vende end statisk test. Men den finder fejl, som ellers ville blive opdaget ved statisk test alene.<\/p>\n
Det rigtige svar her er, at ved at bruge statisk og dynamisk test sammen kan du sikre, at din kode og relaterede dokumenter er i orden, og at softwaren stemmer overens med interessenternes forventninger.<\/p>\n
<\/p>\n
<\/span>Hvad bliver testet under statisk test?<\/strong><\/span><\/h2>\n![\"Forskellige](\"https:\/\/www.zaptest.com\/wp-content\/uploads\/2023\/09\/api-testing-1-jpg.webp\")
<\/p>\n
Statisk test ser p\u00e5 det design, den kode og de dokumenter, der udg\u00f8r dit projekt. Lad os se n\u00e6rmere p\u00e5 de ting, som testere skal holde \u00f8je med for at sikre en omfattende statisk testtilgang.<\/p>\n
<\/span>1. Gennemgang af dokumentation<\/strong><\/span><\/h3>\nEn af de f\u00f8rste dele af statisk test involverer en grundig gennemgang af dokumentationen. Her er nogle af de dokumenter, der kommer under lup.<\/p>\n
<\/span>Dokumenter med forretningskrav<\/strong><\/span><\/h4>\nTesterne unders\u00f8ger forretningskravsdokumentet og sikrer, at de trofast indfanger interessenternes behov og stemmer overens med forretningsm\u00e5lene.<\/p>\n
<\/span>Specifikationer for softwarekrav (SRS)<\/strong><\/span><\/h4>\nDokumentet Software requirement specifications (SRS) skitserer softwarens funktion og anvendelighed. Statisk test k\u00f8rer reglen over dette dokument og sikrer, at det n\u00f8jagtigt beskriver softwarens funktionalitet, herunder afh\u00e6ngigheder og brugergr\u00e6nseflader.<\/p>\n
<\/span>Designdokumenter<\/strong><\/span><\/h4>\nDesigndokumenter gennemg\u00e5s ogs\u00e5 for at sikre, at de opfylder krav og specifikationer. Testere tjekker UML (Unified Modeling Language), dataflow og arkitektoniske diagrammer for at sikre, at de matcher projektets krav.<\/p>\n
<\/span>Use case-dokumenter og brugerhistorier<\/strong><\/span><\/h4>\nStatisk test unders\u00f8ger ogs\u00e5 user case-dokumenter og user stories for at se, hvordan de matcher de funktionelle og ikke-funktionelle aspekter af softwaren. Dokumenterne skitserer “happy paths” (tilsigtet succesfuld brug), alternative flows, “edge cases” og potentielle fejl.<\/p>\n
<\/span>Test cases<\/strong><\/span><\/h4>\nDenne tidlige testfase er en mulighed for at unders\u00f8ge testcases for at sikre, at de har tilstr\u00e6kkelig d\u00e6kning, ressourcer, passende teknikker, realistiske tidsplaner og s\u00e5 videre. Derudover vil gennemgangen ogs\u00e5 unders\u00f8ge, om resultaterne af testcases er detaljerede og realistiske.<\/p>\n
<\/p>\n
<\/span>2. Gennemgang af kode<\/strong><\/span><\/h3>\nDern\u00e6st vil den kode, der er brugt til applikationen, blive gennemg\u00e5et. Her er nogle af de omr\u00e5der, som testteams vil kigge p\u00e5.<\/p>\n
<\/span>Syntaksfejl<\/strong><\/span><\/h4>\nTestere og udviklere kigger p\u00e5 koden og unders\u00f8ger den for syntaksfejl, sl\u00e5fejl, forkerte variabelnavne, manglende tegns\u00e6tning og andre fejl, sm\u00e5 eller store, som vil for\u00e5rsage fejl, n\u00e5r koden endelig eksekveres.<\/p>\n
<\/span>D\u00f8d kode<\/strong><\/span><\/h4>\nD\u00f8d kode, ogs\u00e5 kaldet uopn\u00e5elig kode, er en del af et programs kildekode, som ikke kan udf\u00f8res p\u00e5 grund af problemer med kontrolflowet.<\/p>\n
<\/span>Ubrugte variabler<\/strong><\/span><\/h4>\nStatisk test vil ogs\u00e5 holde \u00f8je med ubrugte variabler, som er deklareret, men aldrig udf\u00f8rt af en compiler.<\/p>\n
<\/span>Overtr\u00e6delse af kodningsstandarder<\/strong><\/span><\/h4>\nKodningsstandarder henviser til et s\u00e6t af bedste praksisser, regler og retningslinjer for kodning i et bestemt sprog. Statisk test sikrer, at best practice overholdes, hvilket g\u00f8r det lettere for andre at redigere, rette og opdatere koden.<\/p>\n
<\/span>Logiske fejl<\/strong><\/span><\/h4>\nLogiske fejl kan betyde, at kildekoden fungerer forkert, men ikke g\u00e5r ned. Statiske reviews fors\u00f8ger at identificere og l\u00f8se disse problemer, f\u00f8r koden eksekveres.<\/p>\n
<\/span>Datastr\u00f8mme<\/strong><\/span><\/h4>\nTesterne unders\u00f8ger ogs\u00e5, hvordan data flyder ind og ud af systemet. Denne gennemgang omfatter alle interaktioner, som data vil have i softwaren.<\/p>\n
<\/span>Kontrol af str\u00f8mme<\/strong><\/span><\/h4>\nEt andet omr\u00e5de, der unders\u00f8ges, er kontrolflow. Denne gennemgang unders\u00f8ger eksekveringsr\u00e6kkef\u00f8lgen af kodes\u00e6tninger og sikrer, at tingene udf\u00f8res i den rigtige r\u00e6kkef\u00f8lge for at sikre, at softwaren opf\u00f8rer sig efter hensigten.<\/p>\n
<\/span>Sikkerhedss\u00e5rbarheder<\/strong><\/span><\/h4>\nStatisk test vil ogs\u00e5 unders\u00f8ge eventuelle sikkerhedshuller i kildekoden.<\/p>\n
<\/p>\n
<\/span>Statiske teknikker i softwaretest<\/strong><\/span><\/h2>\n![\"fordele](\"https:\/\/www.zaptest.com\/wp-content\/uploads\/2023\/09\/pexels-thisisengineering-3862619-jpg.webp\")
<\/p>\n
Nu hvor du ved, hvilke ting der unders\u00f8ges under statisk test, er det tid til at se, hvordan disse unders\u00f8gelser udf\u00f8res.<\/p>\n
Der er to prim\u00e6re statiske testteknikker inden for softwaretest, som du skal kende for at gennemf\u00f8re omfattende softwaretest. Det er gennemgangsprocessen og den statiske analyse.<\/p>\n
<\/p>\n
<\/span>1. Review-processen i statisk test<\/strong><\/span><\/h3>\nReview-processen er den f\u00f8rste del af implementeringen af statiske teknikker i softwaretest. Ideen her er at finde og fjerne fejl fra softwaredesignet. Der er typisk fire hovedfaser i den statiske testgennemgangsproces.<\/p>\n
<\/span>Uformel gennemgang<\/strong><\/span><\/h4>\nEn uformel gennemgang er pr\u00e6cis, hvad det lyder som: en ustruktureret brainstorming-runde, hvor udviklere, testere og interessenter kan udforske potentielle problemer og stille sp\u00f8rgsm\u00e5l og forslag til softwaren. Det er en mulighed for at identificere eventuelle store fejl eller problemer, f\u00f8r man g\u00e5r videre til de n\u00e6ste faser.<\/p>\n
<\/span>Gennemgange<\/strong><\/span><\/h4>\nWalkthroughs er en chance for testteams til at g\u00e5 dybere. Ofte involverer de en eller flere fageksperter, der gennemg\u00e5r dokumentationen for at sikre, at alt stemmer overens med forretnings- og systemkrav.<\/p>\n
<\/span>Peer review<\/strong><\/span><\/h4>\nDet n\u00e6ste trin er, at ingeni\u00f8rerne unders\u00f8ger hinandens kildekode for at se, om de kan finde fejl, der skal rettes, f\u00f8r softwaren eksekveres.<\/p>\n
<\/span>Inspektion<\/strong><\/span><\/h4>\n