Integrasjonstesting på eksemplet på et ekte prosjekt. Ukonvensjonelle tester

Merknad: Forelesningen er den andre av tre som undersøker nivåene i verifiseringsprosessen. Temaet for denne forelesningen er prosessen med integrasjonstesting, dens oppgaver og mål. Organisatoriske aspekter ved integrasjonstesting vurderes - strukturell og tidsmessig klassifisering av integrasjonstestmetoder, planlegging av integrasjonstesting. Formålet med denne forelesningen: å gi en ide om prosessen med integrasjonstesting, dens tekniske og organisatoriske komponenter

20.1. Oppgaver og mål med integrasjonstesting

Resultatet av testing og verifikasjon av de enkelte modulene som utgjør programvaresystemet bør være konklusjonen at disse modulene er internt konsistente og oppfyller kravene. Individuelle moduler fungerer imidlertid sjelden alene, så neste oppgave etter å ha testet individuelle moduler er å teste riktigheten av samspillet mellom flere moduler kombinert til en enkelt helhet. Slik testing kalles integrering. Hensikten er å sørge for at systemkomponentene fungerer riktig sammen.

Integrasjonstesting også kalt systemarkitekturtesting. På den ene siden skyldes dette navnet at integrasjonstester inkluderer å sjekke alle mulige typer interaksjoner mellom programvaremoduler og elementer som er definert i systemarkitekturen – dermed sjekker integrasjonstester fullstendighet interaksjoner i den testede implementeringen av systemet. På den annen side er resultatene av integrasjonstester en av hovedkildene til informasjon for prosessen med å forbedre og raffinere systemarkitekturen, intermodul- og interkomponentgrensesnitt. Det vil si fra dette synspunktet, integrasjonstester sjekker riktighet interaksjoner mellom systemkomponenter.

To moduler kan tjene som et eksempel på å kontrollere korrektheten av interaksjon, hvorav den ene samler protokollmeldinger om mottatte filer, og den andre viser denne protokollen på skjermen. Systemets funksjonskrav sier at meldinger skal vises i omvendt kronologisk rekkefølge. Imidlertid lagrer meldingslagringsmodulen dem i foroverrekkefølge, mens utgangsmodulen bruker stabelen til å sende dem ut i omvendt rekkefølge. Enhetstester som påvirker hver modul individuelt vil ikke gi noen effekt her - den motsatte situasjonen er ganske reell, der meldinger lagres i omvendt rekkefølge, og sendes ut ved hjelp av en kø. Du kan bare oppdage et potensielt problem ved å sjekke interaksjonen mellom moduler ved hjelp av integrasjonstester. Nøkkelpunktet her er at meldinger sendes ut i omvendt kronologisk rekkefølge av systemet som helhet, dvs. ved å sjekke utdatamodulen og finne ut at den sender ut meldinger i direkte rekkefølge, kan vi ikke garantere at vi har funnet en defekt.

Som et resultat av integrasjonstesting og eliminering av alle identifiserte feil, oppnås en konsistent og komplett arkitektur av programvaresystemet, dvs. det kan betraktes som integrasjonstesting er testing av arkitektur og funksjonelle krav på lavt nivå.

Integrasjonstesting, som regel, er en iterativ prosess der funksjonaliteten til et stadig større sett med moduler testes.

20.2. Organisering av integrasjonstesting

20.2.1. Strukturell klassifisering av integrasjonstestmetoder

Som regel gjennomføres integrasjonstesting etter fullført enhetstesting for alle integrerte moduler. Dette er imidlertid ikke alltid tilfelle. Det er flere metoder for å utføre integrasjonstesting:

oppover testing;
monolittisk testing;
ovenfra og ned testing.

Alle disse teknikkene er basert på kunnskap om systemets arkitektur, som ofte er avbildet i form av blokkdiagrammer eller funksjonskalldiagrammer. Hver node i et slikt diagram representerer en programvaremodul, og pilene mellom dem representerer anropsavhengigheter mellom moduler. Hovedforskjellen mellom integrasjonstestmetoder ligger i bevegelsesretningen langs disse diagrammene og i bredden av dekning i én iterasjon.

Oppstrøms testing. Ved bruk av denne metoden antas det at alle programvaremodulene som utgjør systemet først testes og først deretter kombineres de for integrasjonstesting. Med denne tilnærmingen er lokaliseringen av feil betydelig forenklet: hvis modulene testes separat, er feilen i deres felles arbeid problemet med grensesnittet. Med denne tilnærmingen er omfanget av søket etter problemer for testeren ganske smalt, og derfor er sannsynligheten for å identifisere feilen riktig mye høyere.

Ris. 20.1.

Derimot, stigende metode testing har en betydelig ulempe - behovet for å utvikle en driver og stubber for enhetstesting før integrasjonstesting og behovet for å utvikle en driver og stubber under integrasjonstesting av deler av systemmodulene (fig. 20.1)

På den ene siden er drivere og stubber et kraftig testverktøy, på den andre siden krever utviklingen betydelige ressurser, spesielt når sammensetningen av integrerte moduler endres, med andre ord ett sett med drivere for enhetstesting av hver modul, en separat driver og stubber for testing av integrering av to moduler kan være nødvendig. fra et sett, en separat en for testing av integrering av tre moduler, etc. Dette er først og fremst fordi modulintegrasjon fjerner behovet for noen stubber og krever også en driverendring som støtter nye tester som påvirker flere moduler.

Monolittisk testing tyder på at de enkelte komponentene i systemet ikke er seriøst testet. Den største fordelen med denne metoden er fraværet av behovet for å utvikle et testmiljø, sjåfører og stubber. Etter utviklingen av alle moduler utføres integrasjonen deres, deretter kontrolleres hele systemet. Denne tilnærmingen må ikke forveksles med systemtesting, som er tema for neste forelesning. Til tross for at monolittisk testing kontrollerer driften av hele systemet som helhet, er hovedoppgaven med denne testingen å bestemme problemene med interaksjon mellom individuelle moduler i systemet. Systemtestingens oppgave er å evaluere de kvalitative og kvantitative egenskapene til systemet når det gjelder deres aksept for sluttbrukeren.

Monolittisk testing har en rekke alvorlige mangler.

Det er svært vanskelig å identifisere kilden til feilen (identifiser den feilaktige kodebiten). De fleste moduler bør antas å ha en feil. Problemet koker ned til å bestemme hvilken av feilene i alle involverte moduler som førte til resultatet. I dette tilfellet er det mulig å pålegge feileffekter. En feil i en modul kan også blokkere testing av en annen.
Vanskelig å organisere feilrettinger. Som et resultat av testing fikser testeren det funnet problemet. Feilen i systemet som forårsaket dette problemet vil bli fikset av utvikleren. Siden enheter som testes som regel er skrevet av forskjellige personer, oppstår problemet - hvem av dem er ansvarlig for å finne en løsning på feilen? Med en slik "kollektiv uansvarlighet" kan graden av eliminering av defekter falle kraftig.
Testprosessen er dårlig automatisert. Fordelen (det er ingen ekstra programvare som følger med testprosessen) blir til en ulempe. Hver endring som gjøres krever at alle tester gjentas.

Testing nedover forutsetter at integrasjonstestprosessen følger utviklingen. Først testes kun det øverste kontrollnivået i systemet, uten moduler på lavere nivå. Deretter integreres moduler på lavere nivå gradvis med moduler på høyere nivå. Som et resultat av å bruke denne metoden er det ikke behov for drivere (driverens rolle utføres av en modul på høyere nivå i systemet), men behovet for stubber er fortsatt (]. I kjernen er denne tilnærmingen ikke en ny type integrasjonstesting, endrer den bare minimumselementet som følge av integrasjonen. Når du integrerer moduler i prosedyreprogrammeringsspråk, kan du integrere et hvilket som helst antall moduler, forutsatt at stubber utvikles.Når du integrerer klasser i klynger, er det en ganske løs begrensning på fullstendigheten av funksjonaliteten til klyngen. Men selv når det gjelder objektorienterte systemer, er det mulig å integrere et hvilket som helst antall klasser ved å bruke stub-klasser.

Uavhengig av integrasjonstestmetoden som brukes, er det nødvendig å ta hensyn til i hvilken grad integrasjonstester dekker funksjonaliteten til systemet. I arbeidet ble det foreslått en metode for å estimere dekningsgrad basert på kontrollanrop mellom funksjoner og datastrømmer. Med en slik vurdering må koden til alle moduler på strukturskjemaet til systemet utføres (alle noder må dekkes), alle anrop må utføres minst én gang (alle forbindelser mellom noder på strukturdiagrammet må dekkes), alle sekvenser av anrop må utføres minst én gang (alle stier på strukturdiagrammet må dekkes) .

Integrasjonstesting skaper sjelden overskrifter i informasjonsteknologi-delen. Omfanget av integrasjonsfeil kan ikke sammenlignes med hensyn til graden av kritikalitet og mengden tap som oppstår ved sikkerhetsfeil.

En virksomhet som forbereder seg på å lansere et produkt på markedet planlegger også sjelden integrasjonstesting. Vanligvis sjekkes løsningens funksjonalitet (innenfor rammeverket), programvarens evne til å fungere i ulike nettlesere og operativsystemer (henholdsvis testing på tvers av nettlesere og på tvers av plattformer), eller produktlokalisering (hvis vi snakker om slippe løsningen til det internasjonale markedet).

Men viktigheten av integrasjonstesting kan ikke undervurderes. Kompetent integrasjonstesting er et av hovedtrinnene på veien mot utgivelsen av et pålitelig produkt.

Hva er testing og hvordan gjøres det?

Det første du tenker på er integrasjonen av produktet med betalingstjenester. Dette er absolutt et viktig aspekt for testere å sjekke, men langt fra det eneste.

Bedrifter i dag er avhengige av mange programvareløsninger: nettside, ERP-systemer, CRM, CMS. Kvaliteten på behandlingen av brukerforespørsler, hastigheten på tjenestetilbudet og suksessen til virksomheten som helhet avhenger av integrasjonen av alle systemer.

Ved å bruke eksempelet på et reelt prosjekt a1qa vil vi vise hvilke systemintegrasjon som kan testes og hva som kreves av teamet for å få relevante testresultater.

Integrasjonstesting: Prosjektoversikt

Kunde

a1qa ble kontaktet av en representant for et populært engelskspråklig magasin. Publikasjonen er tilgjengelig både på papir og på nett. a1qa-teamet fokuserte på å teste nettportalen.

Prosjektmål

I tillegg til portalfunksjonaliteten måtte teamet teste abonnementsmodulen, som besto av flere komponenter. Denne modulen var spesielt viktig, siden det var han som var ansvarlig for å tjene penger på nettversjonen av tidsskriftet.

For å implementere abonnementsfunksjonen og administrere den, brukte kunden følgende programvareløsninger:

eZ Publish CMS-løsning. Funksjonen er å gi alle data om abonnementer ved hjelp av ulike filtre: type abonnement, dets varighet, gjeldende rabatter, bonuser og så videre.
Nettstedet som brukeren samhandler med systemet gjennom.
Salesforce CRM. Funksjonen er å lagre data om brukere og abonnementene de har kjøpt. Et valgfritt tillegg lar kundeteamet administrere kjøpte abonnementer, samt opprette nye og vurdere gamle abonnementer.
Zuoras SaaS-løsning for fakturering og betalingsbehandling.
Datautveksling mellom systemer utføres ved hjelp av Mule ESB servicebussen.
Database som et Business Intelligence-verktøy.
Salesforce Marketing Cloud er et e-post- og kommunikasjonsverktøy for brukere.
Drupal ble tidligere brukt i stedet for eZ Publish. For øyeblikket er det fortsatt et system som lagrer data om registrerte brukere og et verktøy for å publisere artikler, video og lydinnhold.

Abonnementsprosessen var strukturert som følger:

Forbereder et datasett, oppretter et abonnement.
Gir brukeren mulighet til å kjøpe et abonnement etter å ha lagt inn personlige data og betalingsdata.
Ordrebehandling av en tredjepart som leverer tjenester til klienten på dette området.

Kundens mål

Klienten ønsket å frigjøre prosessen fra tredjeparter. For å gjøre dette var det nødvendig å sørge for at det utviklede abonnementssystemet problemfritt kunne løse alle oppgaver uten deltagelse fra tredjeparter.

Testoppgave

A1qa-teamet måtte bekrefte at produktet var i stand til å utføre de tildelte funksjonene. I løpet av prosjektet ble noen komponenter utviklet fra bunnen av, noen ble konfigurert på grunnlag av ferdige.

Det var viktig å sjekke hvordan de samhandler med hverandre og svare på spørsmålet: er hele systemet i stand til å løse de nødvendige oppgavene?

a1qa integrasjonsteststrategi

De viktigste forretningsprosessene som systemet må utføre er definert: opprette, kansellere, pause og gjenoppta et abonnement, endre betalingsinformasjon for et abonnement, etc.
Testdokumentasjon er utviklet under hensyntagen til alle mulige variasjoner. Variasjoner - ulike alternativer for å utføre operasjoner (for eksempel kansellering av et abonnement kan skje på forespørsel fra kunden, eller kan gjøres automatisk hvis betalingsdataene ble avvist av banken), samt ulike parametere (for eksempel produkt type). Dokumentasjonen måtte inkludere bekreftelse på at for eksempel opprettelse av abonnement ville lykkes for alle produkter innenfor hver forretningsprosess.
Gjennomføring av testing, som besto av å gå gjennom hver forretningsprosess fra startkomponenten (hvor den ble initiert) gjennom alle mellomliggende til de siste (eller siste), verifisere at all data er overført riktig, og at de forventede hendelsene faktisk skjer.

De fleste prosessene innebar overføring av data fra én modul (oftest fra Salesforce) til alle de andre. Hvis utgangspunktet ikke var SF, gikk informasjon fra modulen til MuleESB, og deretter til SF, og derfra til alle de andre (igjen, gjennom MuleESB).

Omtrent 40 % av alle arbeidskostnadene til QA-teamet ble brukt på integrasjonstesting.

Vanskeligheter

De fleste vanskelighetene med å gjennomføre integrasjonstesting var forårsaket av utilstrekkelig utvikling av krav i den innledende fasen av prosjektet. Det var lavkvalitetskrav som forårsaket mange defekter og ustabilitet i systemet som helhet.

La oss forklare. Opprinnelig så kravene ut som et sett med brukerhistorier (User Story) i JIRA og inneholdt kun overskrifter uten noen forklaring. De ble oftest laget av utviklere.

A1qa-teamet satte i gang endringer i tilnærmingen til skrivekrav: nå legges det nødvendigvis til beskrivelser og akseptkriterier for dem, det lages mellomliggende oppgaver med en klar definisjon av hvem som har ansvaret for hva.

Automatisering av integrasjonstesting

Testautomatisering er et komplekst problem som krever nøye sammenligning av alle fordeler og ulemper.

Automatisering av integrasjonstesting krever en enda mer forsiktig tilnærming. På den ene siden reduserer utviklingen av autotester tiden for testutførelse. På den annen side er autotester effektive når du arbeider med repeterende eller i det minste forutsigbare datasett.

Og når du abonnerer, er dette ikke alltid tilfelle: dataene oppdateres jevnlig og kaotisk. Derfor ble testingen hovedsakelig utført manuelt.
Det var først sent i prosjektet at automatisering ble innført. Hvilke testtilfeller har blitt automatisert? Nøkkelforretningsprosesser ble valgt ut. For hver forretningsprosess ble det foreskrevet varianter av passasjen. De testsakene som dekket vanlige og stabile forretningsprosesser ble automatisert. Dermed ga automatisering maksimal dekning med optimal innsats.

resultater

Arbeidet med prosjektet pågår, men vi kan allerede nå si at systemet fungerer pålitelig. Hver komponent utfører sin rolle. Og til sammen bidrar de til å nå målet – å sikre en smidig drift av forretningsprosesser som er viktige for kunden.

Oppsummering

Integrasjonstesting er obligatorisk dersom prosjektet involverer prosesser med kompleks forretningslogikk som involverer ulike systemer.

For å gjennomføre effektiv testing, for å oppdage alle feil og mangler, må testteamet:

Forstå strukturen til produktet, vite hvordan alle moduler samhandler med hverandre;
Eier detaljene i prosjektet. Dette er viktig for å skrive gode testcases, analysere testkjøringsresultater, velge mellom manuell og automatisert testing.

Hvordan bestiller man integrasjonstesting?

For en gratis konsultasjon om integrasjonstesting, fyll ut .

Oversettelse: Anna Radionova

Det finnes mange typer programvaretester. BDD-praksis kan brukes på alle aspekter av testing, men BDD-rammeverk brukes ikke i alle typer tester. Atferdsscenarier er faktisk funksjonelle tester - de sjekker at det testede produktet fungerer som det skal. Verktøy kan brukes til ytelsestesting, mens BDD-rammeverk ikke er designet for dette formålet. Formålet med denne artikkelen er hovedsakelig å beskrive rollen til BDD-automatisering i testpyramiden. Les BDD 101: Manuell testing for å forstå hvordan BDD gjelder for manuell testing. (All informasjon om BDD finner du på Automation Panda BDD-siden)

Pyramide av testing

Likevel, BDD-praksis kan brukes på enhetstester. Hver enhetstest bør fokusere på en kjernekomponent: ett kall, en enkelt variasjon, en bestemt kombinasjon av innganger; på oppførsel.Etter utviklingen skiller funksjonsatferdsspesifikasjonen klart enhetstester fra tester på høyere nivå. Funksjonsutvikleren er også ansvarlig for å skrive enhetstestene, mens en annen ingeniør er ansvarlig for integrasjonen og ende-til-ende-testene. Atferdsspesifikasjonen er en slags gentlemansavtale om at enhetstester vil være en egen enhet.

Integrasjon og ende-til-ende-testing

Test BDD-rammeverk manifesterer seg tydeligst på integrerings- og ende-til-ende-nivåene for testing.

Atferdsspesifikasjoner beskriver entydig og kortfattet hva testsaken er fokusert på. Trinn kan skrives på integrerings- eller ende-til-ende-nivå. Tjenestetester kan skrives med atferdsspesifikasjoner, for eksempel i Karate. End-to-end-tester er faktisk flertrinns integrasjonstester. Ta en titt på følgende eksempel, som ved første øyekast ser ut til å være en grunnleggende brukeropplevelsesmodell, men som faktisk er en massiv ende-til-ende-test:

Gitt en bruker er logget inn på sosiale medier
Når brukeren skriver et nytt innlegg
Deretter brukerens hjemmefeed viser det nye innlegget
Og Hjemmestrømmene for alle venner viser det nye innlegget

En enkel publikasjon i et sosialt nettverk inkluderer prosessene med å samhandle med grensesnittet, ringe backend-tjenester og gjøre endringer i databasen i sanntid. Hele veien gjennom systemet er beskrevet. De automatiserte trinnene kan dekke disse nivåene eksplisitt eller implisitt, men de er definitivt dekket av testen.

Lange ende-til-ende-tester

Begrepene blir ofte forstått forskjellig av forskjellige mennesker. Når folk sier «ende-til-ende-tester», mener de lange, sekvensielle tester: tester som dekker ulike produktatferd én etter én. Denne uttalelsen får BDD-tilhengere til å grøsse, da den strider mot den grunnleggende regelen for BDD: ett scenario, en oppførsel. Selvfølgelig, ved hjelp av BDD-rammeverk, kan du skrive lange ende-til-ende-tester, men du må tenke nøye gjennom om det er verdt å gjøre det og nøyaktig hvordan.

Det er fem grunnleggende prinsipper for å skrive lange ende-til-ende-skript i BDD:

Ikke bekymre deg for dette. Hvis BDD-prosessen er satt opp riktig, er hver enkelt atferd allerede fullt dekket av testtilfeller. Hvert scenario må dekke alle input- og output-ekvivalensklasser. Dermed vil langsiktige ende-til-ende-scenarier i utgangspunktet være en duplisering av testdekning. I stedet for å kaste bort tid på utvikling, er det bedre å forlate automatiseringen av lange ende-til-ende-skript som de som har liten verdi og vie mer tid til manuell og utforskende testing.
Slå sammen eksisterende skript til nye. Hvert When-Then-par representerer en individuell atferd. Trinn fra eksisterende skript kan omdefineres til andre skript med bare mindre refaktorisering nødvendig. Dette bryter med god Gherkin-praksis og kan føre til lange skript, men det er den mest praktiske måten å gjenbruke trinn for omfattende ende-til-ende-skript. De fleste BDD-rammeverk støtter ikke trinnbestilling, og hvis de gjør det, må trinnene skrives om for å få koden til å fungere. (Denne tilnærmingen er den mest praktiske, men mindre tradisjonell.)
Legg inn valideringer i gitte og når trinn. Denne strategien unngår duplisering av When-Then-par og sikrer at sjekker blir utført. Riktigheten av hvert trinn kontrolleres gjennom hele prosessen ved hjelp av agurktekst. Det kan imidlertid være nødvendig med en rekke nye trinn.
Behandle en atferdssekvens som en unik individuell atferd. Dette er den beste måten å tenke på lange ende-til-ende-scenarier, som det forbedrer atferdstenkningen. Et kontinuerlig skript er bare verdifullt hvis det anses som unik oppførsel. Manuset bør skrives for å fremheve denne unike karakteren. Ellers er ikke dette skriptet som skal brukes. Slike manus er ofte deklarative og på høyt nivå.
Ikke bruk BDD-rammeverk og skriv tester utelukkende med automatiseringsverktøy. Gherkin er designet for å samarbeide om atferd, mens lange ende-til-ende-tester løser problemer med QA-arbeidsbelastning. En virksomhet kan gi atferdsspesifikasjoner, men vil aldri skrive ende-til-ende-tester. Å omskrive atferdsspesifikasjoner til lange ende-til-ende-skript kan blokkere utvikling. En mye bedre løsning er sameksistens: akseptprøver kan skrives med Gherkin, mens langvarige ende-til-ende-tester kan skrives med programmeringsverktøy. Begge testpakkene kan automatiseres ved å bruke samme kodebase, de kan ha de samme støttemodulene og til og med trinndefinisjonsmetoder.

Velg tilnærmingen som passer best for laget ditt.

Klasser og typer prøver.

Det er to hovedklasser av tester: tradisjonell Og ukonvensjonell.

Testen har komposisjon, integritet Og struktur. Det består av:

oppdrag;
regler for deres anvendelse;
karakterer for å fullføre hver oppgave;
anbefalinger for tolkning av testresultater.

Test integritet betyr forholdet mellom oppgaver, deres tilhørighet til en felles målt faktor. Hver testoppgave utfører sin tildelte rolle, og derfor kan ingen av dem fjernes fra testen uten tap av målekvalitet.

Teststruktur danner en måte å koble oppgaver med hverandre. I utgangspunktet er dette den såkalte faktorstruktur, der hver oppgave er relatert til andre gjennom felles innhold og felles variasjon i testresultater.

Den tradisjonelle testen er en enhet av minst tre systemer:

innholdssystem for kunnskap, beskrevet av språket til den testede akademiske disiplinen;
et formelt system av oppgaver med økende vanskelighetsgrad;
statistiske kjennetegn på oppgaver og resultater av fagene.

Den tradisjonelle pedagogiske testen bør vurderes i to vesentlige betydninger: som en metode for pedagogisk måling og som et resultat av anvendelsen av testen.

de st er et system av oppgaver som danner den beste metodiske integritet. Testens integritet er et stabilt samspill av oppgaver som danner testen som et system i utvikling.

Homogene tester

Tradisjonelle tester inkluderer tester homogen Og heterogen.

Homogen test representerer et system av oppgaver med økende vanskelighetsgrad, spesifikk form og spesifikt innhold - et system laget med sikte på en objektiv, høykvalitets og effektiv metode for å vurdere strukturen og måle beredskapsnivået til studenter i en akademisk disiplin.

Homogene tester er mer vanlig enn andre. I pedagogikk er de skapt for å kontrollere kunnskap i en akademisk disiplin eller i en seksjon av en slik, for eksempel, voluminøs akademisk disiplin som fysikk. I en homogen pedagogisk prøve er det ikke tillatt å bruke oppgaver som avslører andre egenskaper. Tilstedeværelsen av sistnevnte bryter med kravet om disiplinær renhet av den pedagogiske testen. Tross alt måler hver test noe forhåndsbestemt.

Heterogene tester

heterogen test representerer et system av oppgaver med økende vanskelighetsgrad, spesifikk form og spesifikt innhold - et system laget med sikte på en objektiv, høykvalitets og effektiv metode for å vurdere strukturen og måle beredskapsnivået til studenter i flere akademiske disipliner.

Ofte inkluderer slike tester også psykologiske oppgaver for å vurdere nivået på intellektuell utvikling.

Vanligvis brukes heterogene tester for en helhetlig vurdering av en skoleutdannet, personlighetsvurdering ved søknad om jobb, og for å velge de mest forberedte søkerne for opptak til universiteter. Siden hver heterogene test består av homogene tester, utføres tolkningen av testresultatene i henhold til svarene på oppgavene til hver test (her kalles de skalaer) og i tillegg, gjennom ulike metoder for aggregering av poeng, forsøkes det. å gi en samlet vurdering av beredskapen i faget.

Tolking av testresultater utføres hovedsakelig på testologiens språk, basert på aritmetisk gjennomsnitt, modus eller median og på såkalte persentilnormer, som viser hvor mange prosent av testpersonene som har et testresultat som er dårligere enn noen test. emne tatt til analyse med testresultatet. Denne tolkningen kalles normativt orientert.

Integrative tester

Integrativ kan kalles en test bestående av et system med oppgaver som oppfyller kravene til integrert innhold, testform, økende vanskelighetsgrad for oppgaver rettet mot en generalisert sluttdiagnose av beredskapen til en utdannet ved en utdanningsinstitusjon.

Diagnostikk utføres ved å presentere slike oppgaver, der de riktige svarene krever integrert (generalisert, tydelig sammenkoblet) kunnskap innen to eller flere akademiske disipliner. Opprettelsen av slike tester gis bare til de lærere som har kunnskap om en rekke akademiske disipliner, forstår den viktige rollen til tverrfaglige forbindelser i læring, er i stand til å lage oppgaver, de riktige svarene krever at studentene har kunnskap om ulike disipliner. og evnen til å anvende slik kunnskap.

Integrativ testing innledes av en organisasjon integrerende læring. Dessverre vil den nåværende klassetimeformen for å gjennomføre klasser, kombinert med overdreven fragmentering av akademiske disipliner, sammen med tradisjonen med å undervise individuelle disipliner (i stedet for generaliserte kurs), hindre innføringen av en integrerende tilnærming i læringsprosessen og kontrollen beredskap i lang tid fremover.

Fordelen med integrative tester fremfor heterogene ligger i det større informative innholdet i hver oppgave og i det mindre antallet oppgaver i seg selv.

Adaptive tester

Hensiktsmessigheten av adaptiv kontroll følger av behovet for å rasjonalisere tradisjonell testing.

Hver lærer forstår at det ikke er nødvendig for en godt forberedt elev å få enkle og veldig enkle oppgaver, fordi sannsynligheten for en riktig løsning er for stor. I tillegg har ikke lette materialer et merkbart utviklingspotensial. Symmetrisk, på grunn av den høye sannsynligheten for en feil beslutning, gir det ingen mening å gi vanskelige oppgaver til en svak student. Det er kjent at vanskelige og svært vanskelige oppgaver reduserer læringsmotivasjonen til mange elever.

Den viktigste egenskapen til adaptive testelementer er deres vanskelighetsgrad, oppnådd empirisk, noe som betyr at før de går inn i banken, blir hvert element empirisk testet på et tilstrekkelig stort antall typiske studenter i populasjonen av interesse. Ordet "kontingent av interesse" er her ment å representere betydningen av det mer strenge konseptet kjent i vitenskapen "generell befolkning".

Testing har følgende fordeler fremfor andre metoder for pedagogisk kontroll:

øke hastigheten på å kontrollere kvaliteten på assimilering av kunnskap og ferdigheter av studenter;

implementering, selv om det er overfladisk, men fullstendig dekning av alt pedagogisk materiale;

· redusere virkningen av den negative innvirkningen på testresultatene av slike faktorer som humør, ferdighetsnivå og andre egenskaper hos en bestemt lærer, dvs. minimering av den subjektive faktoren ved vurdering av svar;

høy objektivitet og, som et resultat, en større positiv stimulerende effekt på elevens kognitive aktivitet;

· Orientering til moderne tekniske midler, for bruk i miljøet for dataopplæring og kontrollsystemer;

muligheten for matematisk og statistisk behandling av kontrollresultater, og som et resultat øke objektiviteten til pedagogisk kontroll;

Implementering av prinsippet om individualisering og differensiering av trening gjennom bruk av adaptive tester;

evnen til å øke hyppigheten og regelmessigheten av kontroll ved å redusere tiden til å fullføre oppgaver og automatisere kontrollen;

· lette prosessen med integrering av landets utdanningssystem i det europeiske.

Tester kan klassifiseres i henhold til følgende kriterier:

1. Fagområde for tester: enkeltfag, flerfag, integrerende.
Integrativ kan kalles en test som består av slike oppgaver, hvor de riktige svarene krever integrert (sammenhengende, generalisert) kunnskap om to eller flere akademiske disipliner. Bruk av slike prøver på skolen, både kontrollerende og undervisning, er et utmerket middel for å implementere tverrfaglige sammenhenger i undervisningen.

2. Generell orientering om utformingen av testen: normativt orientert eller kriterieorientert (fagorientert).
På normativ tilnærming, tester er utviklet for å sammenligne fagene når det gjelder nivået på utdanningsprestasjoner.
Det viktigste kjennetegnet domenespesifikke testing er tolkningen av testen med tanke på dens semantiske innhold. Det legges vekt på et veldefinert innholdsområde (hva testtakere kan og vet), snarere enn hvordan de ser ut mot andres bakgrunn.

3.Didaktisk-psykologisk testorientering: prestasjonstest for å kontrollere teorikunnskap; en prestasjonstest for å kontrollere ferdigheter og evner av ulik grad av kompleksitet i et gitt emne, en læringsevnetest (diagnostisering av reelle læringsmuligheter i et gitt spekter av fag- eller sykluskunnskap - matematisk, språklig, etc.).

4.Orientering til et visst stadium av kontroll: tester av forkontroll, tester av gjeldende kontroll, tester av sluttkontroll.

5. Subjektets dominerende aktivitet ved utføring av tester muntlig, skriftlig, datamaskin.

6. Antall kontrollobjekter: tester som har ett kontrollobjekt (for eksempel antall operasjoner utført på riktig nivå) eller flere (kvalitet, kvantitet, hastighet, streng rekkefølge, bevissthet om de samme operasjonene).

7. Graden av homogenitet av testelementer: tester med homogene eller heterogene former for oppgavekonstruksjon.

8. Hastighetsfaktor: høyhastighet (med obligatorisk fiksering av utførelsestid) og saktehastighet.

9. Test organisasjonsform: masse, individuell, gruppe.

Separat, den såkalte tilpasningsdyktig tester basert på prinsippet om individualisering av læring. Hver lærer forstår at det ikke gir noen mening for en god elev å gi enkle og veldig enkle oppgaver, akkurat som det ikke gir noen mening å gi vanskelige oppgaver til en svak elev. I teorien om pedagogiske målinger ble det funnet et mål på oppgavers vanskelighetsgrad og et mål på kunnskapsnivå, sammenlignbare i én skala. Etter fremkomsten av datamaskiner dannet dette tiltaket grunnlaget for metoden for adaptiv kontroll av kunnskap, hvor vanskelighetsgraden og antall oppgaver som presenteres er regulert avhengig av elevenes svar.

Integrasjonstesting- dette er testing av en del av et system som består av to eller flere moduler. Hovedoppgaven med integrasjonstesting er å finne defekter knyttet til feil i implementering og tolkning av grensesnittinteraksjon mellom moduler.

Fra et teknologisk synspunkt er integrasjonstesting en kvantitativ utvikling av enhetstesting, fordi den, akkurat som enhetstesting, opererer med grensesnitt for moduler og undersystemer og krever opprettelse av et testmiljø, inkludert stubber (Stub) i stedet for manglende moduler. Hovedforskjellen mellom enhets- og integrasjonstesting ligger i målene, det vil si i typene defekter som oppdages, som igjen bestemmer strategien for valg av inputdata og analysemetoder. Spesielt på nivået av integrasjonstesting brukes ofte metoder knyttet til å dekke grensesnitt, for eksempel kall til funksjoner eller metoder, eller analysere bruken av grensesnittobjekter, som globale ressurser, kommunikasjonsverktøy levert av operativsystemet.

Problemet løst med metoden integrasjonstesting, - testing av koblinger mellom moduler som implementeres under utførelse av programvaren til komplekse K. Integrasjonstesting bruker "white box"-modellen på modulnivå. Siden teksten til programmet er kjent for testeren i detalj før han kaller alle modulene som er inkludert i det testede komplekset, er bruken av strukturelle kriterier på dette stadiet mulig og begrunnet.

Integrasjonstesting brukes på stadiet med å sette sammen enhetstestede moduler til et enkelt kompleks. Det er to metoder for å sette sammen moduler:
Monolitisk, preget av samtidig integrering av alle moduler i et testkompleks
trinnvis, som er karakterisert ved en trinnvis (modulær) oppbygging av et programkompleks med trinnvis testing av det sammensatte komplekset. I en inkrementell metode er det to strategier for å legge til moduler:
o "Top-down" og tilhørende testing nedenfra og opp.
o "Bottom up" og følgelig nedadgående testing.

Egendommer monolittisk testing er som følger: for å erstatte moduler som ikke ble utviklet på testtidspunktet, bortsett fra den øverste, er det nødvendig å i tillegg utvikle drivere (testdriver) og/eller stubber (stub) som erstatter moduler på lavere nivå som var savnet på tidspunktet for testøkten.

Sammenligning av den monolittiske og integrerte tilnærmingen gir følgende:
Monolittisk testing krever mye arbeid knyttet til ytterligere utvikling av drivere og stubber og med vanskeligheten med å identifisere feil som vises i rommet til den sammensatte koden.
Trinn for trinn testing på grunn av den lavere kompleksiteten ved å identifisere feil på grunn av den gradvise økningen i volumet av koden som testes, og følgelig lokaliseringen av det ekstra området til koden som testes.
Monolittisk testing gir store muligheter for parallellisering av arbeid, spesielt i startfasen av testing.

Egendommer ovenfra og ned testing er som følger: organisering av et miljø for den kjørbare sekvensen av samtaler av testede moduler av testede moduler, konstant utvikling og bruk av stubber, organisering av prioritert testing av moduler som inneholder utvekslingsoperasjoner med miljøet, eller moduler som er kritiske for algoritmen under test.

Feil ovenfra og ned testing:
Problemet med å utvikle tilstrekkelig "intelligente" stubber, dvs. stubber som kan brukes til å modellere ulike driftsmoduser for komplekset, nødvendig for testing
Kompleksiteten ved å organisere og utvikle et miljø for å implementere utførelse av moduler i ønsket rekkefølge
Parallell utvikling av moduler på øvre og nedre nivå fører til ikke alltid effektiv implementering av moduler på grunn av justering (spesialisering) av ennå ikke testede moduler på lavere nivåer til allerede testede moduler på øvre nivå

Feil oppover testing:
Forsinkelse i å sjekke de konseptuelle egenskapene til komplekset som testes
Behovet for å utvikle og bruke drivere

Funksjoner ved integrasjonstesting for prosedyreprogrammering

Prosessen med å konstruere et sett med tester i strukturell testing bestemmes av prinsippet som konstruksjonen av Program Model Graph (PGM) er basert på. Settet med testveier og genereringen av tester som tilsvarer testveiene avhenger av dette.

Den første tilnærmingen til programvareutvikling er prosessuell (modulær) programmering. Tradisjonell prosedyreprogrammering innebærer å skrive kildekode i en imperativ (imperativ) stil, foreskrive en viss sekvens av kommandoutførelse, samt beskrive et programvareprosjekt ved bruk av funksjonell dekomponering. Språk som Pascal og C er avgjørende. I dem bestemmer rekkefølgen til kildelinjene med kode rekkefølgen som kontroll overføres i, inkludert sekvensiell utførelse, valg av betingelser og gjenutførelse av programseksjoner. Hver modul har flere inngangspunkter (ett for streng koding) og flere utgangspunkter (ett for streng koding). Komplekse programvareprosjekter har en modulær-hierarkisk struktur, og enhetstesting er det første trinnet i programvaretestingsprosessen. Å bygge en grafmodell av en modul er en triviell oppgave, og testing utføres nesten alltid i henhold til C1-grendekningskriteriet, dvs. hver bue og hvert toppunkt på modulgrafen må være inneholdt i minst én av testbanene.