Indlejret kvalitetssikring (QA) og testning

Indlejret testning er en proces, der verificerer funktionaliteten og kvaliteten af firmware/software og hardwaredele i et slutprodukt. Det sikrer, at produktet opfylder forretningskravene og ikke har nogen defekter eller problemer. Indlejret testning kontrollerer, om software og hardware fungerer godt sammen i produktet under forskellige forhold.

Contact

Nøglefunktioner

Electronics testing and validation

- Gennemgang af diagrammet og printkortet baseret på de tekniske krav - Analyse af signalledning og strømintegritet - Test og validering af printkortets routing-problemer - Verifikation af signalet på alle indgange og udgange - Test af strømstyring og strømfordeling - Test af temperaturområde i et termisk kamera

Embedded firmware/software testing

- Kodegennemgang for hvert modul baseret på standarder - Udarbejdelse af enhedstests for hvert kodemodul - Udarbejdelse af funktionelle tests for at demonstrere det faktiske arbejde - Udførelse af hardware- og firmware-tilbageføringstests - Forberedelse af et testværktøj til at indsamle og analysere testresultater med logs - Manuel testning med en liste over testcases

Mechanical parts testing and validation

- Inspektion af enhedsdele fremstillet ved trykning eller sprøjtestøbning og sammenligning med det originale design - Kvalitetsverifikation og materialernes anvendelighed - Test af temperaturområde i et termisk kamera - Vibrationstest - Verifikation af IP-standarder og test baseret på krav

Mobile Application testing

- Kodegennemgang for hvert modul baseret på standarder - Enheds-, manual- og funktionstest for hvert modul - UI/UX-sammenlignende test med det oprindelige design - Test for forskellige skærmstørrelser, opløsninger og platformversioner - Hastigheds- og belastningstest af kommunikation via BLE, WIFI og NFC - Stress-, kompatibilitets- og lokaliseringstest

Værktøjer, vi bruger

Projektproces

Hardware QA Firmware QA Mechanical QA Mobile app QA

Verifikation af signalerne

Når ingeniøren arbejder med samlede printkort, etablerer han en forbindelse mellem en laboratoriestrømforsyning med en strømgrænse og indstiller den passende indgangsspænding. Derefter kontrollerer han spændingerne og strømmene på hver kritisk del af printkortet ved hjælp af et laboratoriemultimeter. Baseret på de opnåede resultater opretter han et errata-dokument og foretager eventuelle nødvendige rettelser på det aktuelle printkort (såsom lodning af komponenter, ledninger osv.).

Test af kredsløbsbeskyttelse

Vores tekniker udfører test på alle input/output-ben på printkortet i henhold til printkortets krav. For eksempel udfører de test af den maksimale inputspænding, ESD (ved hjælp af en højspændingsgenerator og et veludstyret laboratorium), polaritetsomvendingstest (ved at skifte polariteten på inputkilden) osv. Efter evaluering af testresultaterne opdateres errata-dokumentet i overensstemmelse hermed.

Test af strømforbrug

For enheder med lavt strømforbrug, der bruger batterier, viser denne proces sig at være den mest tidskrævende, fordi vores ingeniør udfører omfattende test af strømforbrug og strømmålinger for alle enhedens driftstilstande (arbejde, inaktiv, dvale og dyb dvaletilstand) på hver kritisk komponent. Derefter genereres en tabel med resultaterne, som sammenlignes med de teoretiske beregninger baseret på databladet. Hvis resultaterne afviger væsentligt fra de teoretiske forventninger, identificerer ingeniøren den/de komponent(er), der forårsager uoverensstemmelsen (nogle gange kræver dette genlodning af komponenter eller overskæring/lodning af nogle ledninger).

Antennematchtestning

For enheder, der inkluderer en RF-komponent på printkortet, er antennematchtestning afgørende. Vores ingeniør forbinder en vektoranalysator direkte til RF-input/output-kredsløbet med en antenne eksklusive transmitter-IC'en og kontrollerer impedanskarakteristikaene ved arbejdsfrekvensen. Normalt bør impedansen ligge tæt på 50 ohm ved arbejdsfrekvensen. Hvis ikke, skal passende komponenter til RF-kredsløbet vælges for at opnå 50 ohm (før designfasen er simulering af RF-output-kredsløbet afgørende).

Funktionstest med testfirmware

Funktionstest med testfirmware er et meget vigtigt trin. Når det er bekræftet, at enheden ikke har potentielle strøm- og forbindelsesproblemer, fortsætter teknikeren med at udføre funktionstest ved hjælp af testfirmware. Dette kontrollerer hver hardwareafhængig del, f.eks. temperatursensor, hukommelse, grænseflader, og opretter en testlog med resultaterne.

Test af opvarmning og temperaturområde

Vi begynder at teste varme- og temperaturområdet, når vi har en fuldt funktionel enhed og testfirmwaren. Ingeniøren placerer enheden i et termisk kammer og ændrer temperaturen fra minimum til maksimum arbejdsområde med lav hastighed og små trin. Baseret på testen udarbejder ingeniøren en detaljeret rapport med resultater.

EMI/EMC-evaluering

Et af de sidste trin før certificering af enheden er at udføre fortestning i vores laboratorium. Til dette bruger vi et spektrometer op til 26 GHz udstyret med forskellige antenner til forskellige frekvenser. Vi kontrollerer enhedens spektrum i forskellige arbejdstilstande og sørger for, at det passer inden for det tilladte område. Efter dette trin lejer vi et eksternt laboratorium til den fulde EMI/EMC-testning. Yderligere detaljer og en rigtig testvideo kan findes nedenfor (https://droid-technologies.com/main/services/precer) og se en video (https://www.youtube.com/watch?v=zCEabo3tVxQ).

Kodeanalyse med en statisk analysator

Vi bruger en kodeanalysator til at kontrollere kodens overholdelse og kvalitet i henhold til den standard (MISRA, ANSI osv.) og det sprog (C, C++), vi bruger. Dette hjælper os med at spare tid på fejlretning og gøre koden mere professionel.

Kodegennemgang

Kodegennemgang udført af en anden professionel ingeniør er en vigtig del af arbejdet. Vi opdeler projektet i mindre opgaver, hver med sin egen Git-gren og kode. Når en opgave er færdig, sender vi en merge-anmodning til udviklingsgrenen og udfører kodegennemgang ved hjælp af Github/Gitlab-mekanismer (vi følger Google-baseret kodestil med ændringer til Embedded C/C++).

Dækkode via enheds- eller funktionstest af hvert modul

Hver kodefunktion/metode/modul bør testes med enheds- eller funktionstests som en del af en professionel projekttilgang. For hver simpel opgave (kodemodul) skriver vi tests, instruktioner og udfører test med rapportgenerering.

Hastigheds- og belastningstest med optimering

Hver firmware skal være så strømbesparende som muligt, og det er svært at opnå en ideel ydeevne. Men vi prøver. Til dette måler vi ydeevnen af hver enkelt medvirkende kodekonstruktion, foretager kodeanalyser, og hvis det er muligt, optimerer vi kodehastigheden.

Manuel test af hvert kodemodul

Efterhånden som de funktionelle tests eller forretningslogikken er udført, udarbejder vi en instruktion til manuel testning af hvert kodemodul. Denne instruktion indeholder detaljerede testtrin med resultater for hvert trin. Baseret på testningen udarbejder vi en rapport til fejlretning og forbedringer.

Regressionstest

Da hvert kodemodul er blevet dækket af tests og testet, skal der udføres en komplet regressionstest af projektet med alle arbejdssager. Baseret på dette vil der blive udarbejdet en testrapport, foretaget rettelser og udgivet.

Kodeanalyse ved hjælp af en statisk analysator

Vi anvender en kodeanalysator for at sikre kodeoverholdelse og kvalitet i henhold til de standarder, vi overholder. Dette sparer tid på fejlretning og forbedrer kodens professionalisme.

Kodegennemgang

Kodegennemgang udført af en anden professionel ingeniør er en vigtig del af arbejdet. Vi opdeler projektet i mindre opgaver, hver med sin egen Git-gren og kode. Når opgaven er færdig, sender vi en merge-anmodning til udviklingsgrenen og udfører kodegennemgangen ved hjælp af Github/Gitlab-mekanismer.

Dækkode via enheds- eller funktionstest af hvert modul

UI/UX sammenlignende test

Vi tester først applikationen med vores team, inklusive en UX/UI-designer med omfattende erfaring, for at sikre, at alt passer godt og giver en overlegen brugeroplevelse på tværs af forskellige mobile enheder og skærmstørrelser. I andet trin involverer vi brugerne i at teste appen og give feedback.

Hastigheds- og belastningstest med optimering

Det er udfordrende at optimere ydeevnen og opnå den ideelle hastighed for hver applikation. Vi måler ydeevnen af hver kompleks kodestruktur, udfører kodeanalyse og, når det er muligt, optimerer koden for hastighed.

Stresstest

Stresstestning er en kritisk del af udviklingen af mobilapps. Vores udviklingsteam simulerer en tung belastning af applikationen ved manuelt at interagere med appen og skrive tests for at simulere en aktiv bruger, der bruger alle appens funktioner, herunder at sende og modtage store mængder data. Under denne proces analyserer vi, hvordan appen bruger systemressourcer såsom hukommelse og processorkraft.

Lokaliseringstestning

Lokaliseringstest udføres i flere trin. Vi opretter adskillige emulatorer med forskellige regionale indstillinger (grænsefladesprog, lokalisering, OS-version) og kører appen på hver af dem. Vi udfører også praktisk testning i forskellige regioner med rigtige brugere og indsamler feedback fra forskellige lande.

Manuel test af hvert kodemodul

Regressionstest

Når hvert kodemodul er dækket af tests og testet individuelt, udfører vi en komplet regressionstest af hele projektet med alle relevante use cases. Baseret på resultaterne genereres en testrapport, og nødvendige rettelser og forbedringer implementeres inden udgivelsen.

Simulering

Dette trin er afgørende for at verificere designdetaljerne i et CAD-værktøj. Ingeniøren udfører simuleringer for at evaluere parametre som temperaturområde med opvarmning og afkøling, detaljernes styrke med forskellige materialer, visualisering af bevægelige dele i enheden og sprøjtestøbningsprocessen.

Gennemgå designet af en anden ingeniør

Gennemgangen kontrollerer de designede filer for de mekaniske dele og udarbejder en rapport baseret på tekniske krav og designstandarder

Evaluering af prototyper i produktionskvalitet

Efterhånden som den/de designede del(e) er blevet fremstillet (trykt, maskinbearbejdet), gennemgår vi disse dele og kontrollerer kvaliteten baseret på tolerancer specificeret i den tekniske dokumentation, standarder og andre designfiler. Baseret på dette udarbejder vi en rapport til forbedring.

Evaluering af enhedens monteringsproces

Baseret på monteringstegningen begynder vi at samle og evaluere: monteringshastighed, bekvemmelighed og kvalitet. Baseret på dette udarbejder vi en rapport til forbedring.

Evaluering af brugeroplevelsen og ergonomiske materialer

For at sikre en positiv brugeroplevelse og ergonomisk design (hvis nødvendigt) testes færdigsamlede enheder af vores team med hjælp fra en UX-ekspert. Derudover inviteres brugerne til at teste enhederne og give feedback, som samles i en rapport med henblik på yderligere forbedringer.

Funktionstest

Dette trin involverer test af den samlede enhed med alle eksterne dele, inklusive printkort og mekaniske komponenter. En tjekliste med testcases følges for at vurdere effektiviteten, og en rapport udarbejdes for at identificere områder, der kræver forbedring.

Temperaturområdemåling i et termisk kamera

Den samlede enhed placerer ingeniøren i et termisk kammer og ændrer temperaturen fra minimum til maksimum arbejdsområde med lav hastighed og små trin. Baseret på testen udarbejder ingeniøren en detaljeret rapport med resultater.

Vibrationstestning

Den samlede enhed er forbundet til et vibrationsstativ, og vibrationsniveauet varieres fra minimum til maksimum arbejdsområde med lav hastighed og små trin. En detaljeret rapport med resultater udarbejdes baseret på testen.

IP-beskyttelsestest

Et af de sidste vigtige trin er IP-testning (Ingress Protection), der udføres i specielle kameraer, der giver kontrol over faktorer som luftfugtighed, vand- og lufttryk samt støvtæthed i henhold til IP-standardkrav. IP-testning udføres baseret på enhedens krav, og der genereres en rapport for at dokumentere resultaterne.