top-image
top-image
UppdragslänkAnmällänkKundlänk

Anmälan till uppdrag 4710

XDin anmälan har skickats
Testautomatisering
LabWiew,XML,CI,ATML,Jenkins,JTAG,Azure DevOps
Testledare
Gbg
Detta är en väldigt grov testplan. Den är skriven med minimal kunskap om produkten och organisationsstrukturen. Första halvan av dokumentet bör inte vara med i den slutgiltiga testplanen, men listar saker som är bra att ha i åtanke när testplanen utvecklas. Arbetsflöde Första stegen Ãr att samla information så man kan ta bra beslut senare. 1. Gå igenom produkten som ska testas. 2. Gå igenom existerande testfall och testmiljöer. 3. Gå igenom krav och saker som ska testas. 4. Slutför testplanen nu när man har mer information. Sedan blir det mer agilt flöde: 5. Skriv testspecifikationer. 6. Välj och utveckla verktygen som behövs. 7. Implementera testfall. Varför testa? Under utvecklingen Hitta fel tidigt innan de blir dyra att åtgärda. Vid leverans Bevisa att produkten uppfyller kraven. Vid produktion Verifiera att producerad hårdvara är felfri. Vid reparation Förenkla felsökning av trasiga produkter. Varför automatisera testning? Automatiserade tester kan vara en del av Continuous Integration (CI). Automatiserade tester kan testa i en stor input-rymd (t.ex. Testa alla kombinationer av 1 GHz till 10 GHz och -10 C till +50 C med 10 MHz och 1 C steg). Vissa saker kan vara svårt att testa manuellt (t.ex. "Testa att de rapporterade transformerade koordinaterna stämmer överens med den simulerade signalen). Saker att tänka pà Automatiska tester måste verifieras manuellt. Verifiera att testfallet upptäcker fel som testaren manuellt skapar. Testresultat måste följas upp för att testfallen ska ha värde. Man måste identifiera ifall ett misslyckat testresultat beror på ett fel i produkten eller i testfallet. Helst ska man kunna lita på testfallen, men ifall testfallen utvecklas parallellt med produkten så är det vara svårt att utveckla felfria testfall. Tester måste underhållas när krav eller design ändras. Alla tester måste inte automatiseras. Vissa tester är enklare och billigare att testa manuellt. Ta med testledaren från starten av produktens utveckling. Det gör det enklare att designa ett testbart system och kan vara ett bra verktyg för systemutvecklarna. Nivåer av testning Unit-tester skrivs av programmeraren som utvecklar modulen som ska testas. Testerna är en del av Continuous Integration (CI) och körs automatiskt vid varje commit eller pull request (beroende på hur lång tid som testerna tar att köra). Unit-testerna måste vara skrivna och alla unit-tester måste gå igenom innan den nya koden får mergeas. Resultatet av unit-testningen visas i byggverktyget (Jenkins?) och i versionshanteraren för källkoden (Bitbucket / Azure Devops?). System/Integrations-tester designas av testledaren tillsammans med testutvecklaren, och implementeras av testutvecklaren. Resultatet av integrationstesterna sparas i JUnit XML eller Automatic Test Markup Language (ATML). Integrationstester som går snabbt att köra bör vara en del av CI. Verktyg för integrationstester: LabView är ett av de vanligaste verktygen för att utveckla integrationstester. Det har ett grafiskt programmeringsspråk och är utvecklat av National Instruments. Att utveckla en ny testplatform är det enklaste alternativet. Det kan dock bli dyrt beroende på hur mycket man måste utveckla runt testfallen, till exempel styrning av instrument och hantering av testresultat. SMR är testplatformen som används i Järfälla. CCTP Ãr en ny testplatform som utvecklas i Arboga, Sydafrika, Järfälla, och Göteborg. Platformen Ãr inte redo att användas än, men är ett bra alternativ i framtiden. GUI-tester utvecklas av testledaren eller testutvecklaren. Hur GUI-testerna fungerar beror mycket på hur produkten fungerar och vilka tekniker som används. Ifall det går så vill man använda objekt-baserad testning där man hänvisar till GUI-komponenter programmatiskt istället för att simulera användar-input med koordinater. Hårdvaru-tester utvecklas av testutvecklaren tillsammans med en utvecklare som kan hårdvaran. JTAG bör användas.

Personuppgifter -*obligatorisk uppgift

Hemuppgifter

CV o Personligt brev (Word,PDF,Text) / Foto (JPEG)

Företagsuppgifter - Om du är anställd eller företagare

Tipsuppgifter - Var fick du tips om KonsultPoolen