Metodes van toetsing sagteware en vergelyk kan word. Toets metode van "black box" toets en die metode van "wit boks"

Toets sagteware (SW) identifiseer gapings, tekortkominge en foute in die kode wat aangespreek moet word. Dit kan ook gedefinieer word as die proses van evaluering van die funksies en korrektheid van die sagteware met die hulp van die analise. Basiese metodes van integrasie en toetsing van sagteware programme en verseker gehalte is om die spesifikasie, ontwerp en kodering, betroubaarheid assessering, validering en verifikasie toets.

metodes

Die hoofdoel van sagteware toets - bevestiging van die gehalte van sagteware stelsel deur sistematiese debugging aansoeke onder noukeurig gekontroleerde toestande hul volledigheid en akkuraatheid, sowel as die opsporing van verborge foute te bepaal.

Die metodes van verifikasie (toets) programme kan verdeel word in statiese en dinamiese.

Die voormalige sluit informele, monitering en tegniese hersiening, inspeksie, stap vir stap analise, ouditering, sowel as statiese data vloei analise en bestuur.

Dinamiese tegnieke is:

1. Wit boks toets. Dit is 'n Gedetailleerde studie van die interne logika en struktuur van die program. Dit is nodig om kennis van die bron-kode.
2. Black box toets. Hierdie tegniek vereis nie enige kennis oor die innerlike werking van die aansoek vereis. Ons is van mening net die basiese aspekte van die stelsel, nie verband hou met of wat verband hou met 'n paar van sy interne logiese struktuur.
3. Grys boks metode. Dit kombineer twee vorige benaderings. Debugging met 'n beperkte kennis van die interne funksionering van die aansoek is gekombineer met kennis van die basiese aspekte van die stelsel.

deursigtige toets

Die wit boks metode met behulp van toetsantwoordstelle beheer struktuur van die prosedurele ontwerp. Hierdie tegniek maak dit moontlik om die implementering foute, soos swak bestuur kode stelsel openbaar deur die analise van 'n deel van die innerlike werking van die sagteware. Hierdie toets metodes is van toepassing op die integrasie, module en stelsel vlakke. Die tester moet toegang tot die bronkode te hê en dit te gebruik om uit te vind wat eenheid onbehoorlik optree.

Toetsprogramme deur wit-box het die volgende voordele:

• Dit maak dit moontlik om 'n fout in die verborge kode op te spoor deur die verwydering van onnodige lyne;
• die gebruik van newe-effekte;
• maksimum dekking is behaal deur die skryf van 'n toets script.

nadele:

• hoë-koste proses, wat geskoolde debugger;
• baie paaie bly onverkende omdat deeglike ondersoek van alle moontlike versteekte foute is baie kompleks;
• sommige van die kode sal ongesiens geslaag.

Wit boks toets word soms na verwys deur die toets van 'n deursigtige of oop boks, strukturele, logiese toets, wat gebaseer is op die bron-kode, en logika argitektuur.

Die hoof variëteite:

1) die toets van die vloei beheer - strukturele strategie met behulp van die program beheer vloeimodel en as ten gunste van meer eenvoudige maniere om minder meer kompleks;

2) Die tak is ontwerp om te studeer debugging elke opsie (waar of vals) van elke beheer operateur, wat ook 'n gekombineerde oplossing;

3) toets van die belangrikste pad, wat die tester toelaat om logiese kompleksiteit maatstaf prosedurele projek te vestig vir isoleer 'n basis stel uitvoering paaie;

4) die nagaan van die data stroom - die vloei beheer strategie van navorsing deur die notas tel inligting oor die advertensie en gebruik die program veranderlikes;

5) siklusse van die toets - ten volle gefokus op die korrekte werking van sikliese prosesse.

gedrags- ontfouting

Black box toets behandel die sagteware as 'n "black box" - inligting oor die innerlike werking van die program is nie getel en nagegaan net die basiese aspekte van die stelsel. In hierdie geval, die toetser moet die stelsel argitektuur weet sonder toegang tot die bronkode.

Voordele van hierdie benadering:

• doeltreffendheid vir groot-kode segment;
• verlig van persepsie tester;
• gebruiker perspektief is duidelik geskei van die ontwikkelaar perspektiewe (programmeerder en tester is onafhanklik van mekaar);
• vinniger skepping van toets.

Toets sagteware black box metode het die volgende nadele:

• inderdaad 'n beperkte aantal toets gevalle uitgevoer, wat lei tot beperkte dekking;
• 'n gebrek aan 'n duidelike spesifikasie moeilik om toetsantwoordstelle ontwikkel;
• lae doeltreffendheid.

Ander name vir hierdie tegnologie - gedrags-, nie-deursigtige, funksionele toetsing en ontfouting metode van 'n geslote boks.

Hierdie kategorie kan die volgende insluit sagteware toets tegnieke:

1) gelykstaande aan partisie, wat die stel van toetsdata as insette sagteware module data is afgebreek in afsonderlike dele kan verminder;

2) randwaarde analise fokus op die verifikasie van grense of uiterste perk waardes - die minimum, maksimum en tipiese waardes van fout;

3) fuzzing - wat gebruik word om die soektog deur die skryf van foute of beskadig data poluiskazhennyh in outomatiese of semi-outomatiese modus te implementeer;

4) aanklagte van oorsaaklikheid - 'n tegniek wat gebaseer is op die skepping van grafieke en die bepaling van die verhouding tussen die optrede en sy redes: identiteit, ontkenning, logiese OF en logiese EN - die vier hoofkarakters, die uitdrukking van die verhouding tussen oorsaak en gevolg;

5) verifikasie van ortogonale skikkings toegepas op probleme met 'n relatief klein insette gebied van meer as die moontlikheid van uitputtende navorsing;

6) toets al pare - 'n tegniek waar 'n stel van toets waardes behels alle moontlike binêre kombinasies van elke paar insette parameters;

7) debugging staat oorgang - 'n tegniek nuttig vir die beheer van die status van die masjien, sowel as om te navigeer deur die GUI gebruiker.

Black box toets: Voorbeelde

swart-box tegniek is gebaseer op die spesifikasies, dokumentasie, en beskrywings van die sagteware koppelvlak of stelsel. Daarbenewens kan jy modelle (formeel of informeel) gebruik, wat die verwagte gedrag van die sagteware.

Tipies, is hierdie metode wat gebruik word vir die opsporing van gebruikerskoppelvlak en vereis interaksie met die aansoek deur die bekendstelling van 'n versameling en resultate data - vanaf die skerm, uit die verslae of drukstukke.

Die tester dus in wisselwerking met die sagteware deur die skryf, deur op te tree op die skakelaars, knope of ander koppelvlakke. Die keuse van insette data, kan die einde van administrasie of reeks gebeurtenisse lei tot 'n groot aantal van kombinasies, soos in die volgende voorbeeld.

Hoeveel toetse moet maak ten einde al die moontlike waardes vir die 4 vensters vlag en een-off veld te gaan, stel die tyd in sekondes? By berekening met die eerste oogopslag is eenvoudig: 4 velde met twee moontlike state - 24 = 16, wat moet vermenigvuldig met die aantal moontlike posisies 00-99, maw 1600 moontlik toetse.

Maar hierdie berekening is verkeerd: ons kan bepaal wat die veld twee-punt ook 'n ruimte kan bevat, met ander woorde dit bestaan uit twee alfanumeriese posisies en kan alfanumeriese karakters, spesiale karakters, spasies, ens So sluit, indien .... stelsel is 'n 16-bit rekenaar, draai 216 = 65536 een vir elke posisie in die gevolglike 4294967296 toets gevalle wat moet word vermenigvuldig met 16 kombinasies van vlae wat 'n totaal van 68.719.476 736. As hulle uit te voer gee op 1 toets per sekonde, die totale vervolg olzhitelnost toets is 2 177,5 jaar. Vir 32 of 64-bit stelsels, die duur selfs meer.

Daarom is daar 'n behoefte aan hierdie tydperk tot 'n aanvaarbare vlak te verminder. So, moet die tegnieke toegepas word op die aantal toets gevalle te verminder sonder vermindering van die omvang van die toets.

ekwivalensie skeiding

Die ekwivalent verdeling is 'n eenvoudige metode wat van toepassing is vir enige veranderlikes wat in die sagteware, hetsy inset of uitset waardes, simboliese, numeriese, en ander. Dit is gebaseer op die beginsel dat al die data van die een ekwivalent van die verdeling op dieselfde manier hanteer sal word en deur die dieselfde instruksies.

Gedurende die toets, gekies een verteenwoordiger van elke bepaalde ekwivalensie partisie. Dit laat jou toe om stelselmatig te verminder die aantal moontlike toets gevalle sonder verlies van dekking van opdragte en funksies.

Nog 'n gevolg van hierdie verdeling is om die kombinatoriese ontploffing tussen die verskillende veranderlikes en die gepaardgaande vermindering van toets gevalle te verminder.

Byvoorbeeld, in (1 / x) ^1/2 met behulp van drie data rye, drie ekwivalent verdeling:

1. Alle positiewe getalle sal in dieselfde manier behandel word en moet korrek resultate gee.

2. Alle negatiewe getalle hanteer word op dieselfde manier met dieselfde resultaat. Dit is verkeerd, want die wortel van 'n negatiewe getal is denkbeeldige.

3. Zero sal afsonderlik hanteer word en gee die fout "deling deur nul". Dit is 'n afdeling met 'n enkele waarde.

So, sien ons drie afsonderlike afdelings, waarvan een is verminder tot 'n enkele waarde. Daar is 'n "korrekte" artikel, wat betroubare resultate gee, en twee "verkeerd" met verkeerde resultate.

randwaardeprobleme analise

Verwerking op die grense van die ekwivalent skeiding kan anders gedoen word as wat verwag is. Ondersoek van limiet waardes - 'n bekende metode van ontleding van die gedrag van die sagteware in sulke gebiede. Hierdie tegniek maak dit moontlik om sulke foute te identifiseer:

• onbehoorlike gebruik van relasionele operateurs (<,>, =, ≠, ≥, ≤);
• enkele fout;
• probleme in siklusse en iterasies,
• verkeerde tipes of grootte van veranderlikes gebruik vir die berging van inligting;
• kunsmatige beperkings verband hou met datatipes en veranderlikes.

deurskynende toets

grys boks metode verhoog die toets dekking, kan jy fokus op al die moeilike vlakke van die stelsel deur 'n kombinasie van swart en wit tegnieke.

Die gebruik van hierdie tegniek, moet die toetser vir die ontwikkeling van toets waardes kennis van interne datastrukture en algoritmes het. Voorbeelde van grys-box toets metodes is soos volg:

• argitektoniese model;
• Unified Modeling Language (UML);
• staat model (eindige toestand masjien).

In die metode van die grys blokkie om toets gevalle ontwikkel bestudeer modules in wit ingenieurswese kodes en werklike toets is uitgevoer op die koppelvlakke van die swart tegnologie programme.

Hierdie toets metodes het die volgende voordele:

• kombinasie van voordele tegnikus wit en swart bokse;
• Tester is gebaseer op die koppelvlak en funksionele spesifikasie, en nie die bronkode;
• debugger kan groot toets gevalle maak;
• tjek is gemaak van die punt van die lig van die gebruiker, nie die ontwerper van die program;
• skep persoonlike toetsontwikkeling;
• objektiwiteit.

nadele:

• toets dekking is beperk, want daar is geen toegang tot die bronkode;
• die kompleksiteit van die defekte in verspreide toepassings;
• baie maniere bly onverkende;
• As die sagteware ontwikkelaar die toets van stapel gestuur het, dan kan verdere ondersoek oormatige wees.

Nog 'n naam vir die grys boks tegnieke - deurskynende debugging.

Hierdie kategorie sluit sulke metodes van toetsing:

1) ortogonale verskeidenheid - die gebruik van 'n subset van alle moontlike kombinasies;

2) matriks debugging met behulp van die toestand van die program data;

3) regressiewe inspeksie gedoen op die nuwe veranderinge aan die sagteware;

4) sjabloon toets wat die ontwerp en argitektuur van 'n goeie program ontleed.

Vergelyking van sagteware toets tegnieke

Die gebruik van dinamiese metodes lei tot 'n kombinatoriese ontploffing van die aantal toetse wat ontwikkel moet word, geïmplementeer en uitgevoer. Elke tegniek moet pragmaties gebruik word, neem sy beperkinge in ag.

Die enigste ware metode bestaan nie, daar is net diegene wat meer geskik is vir die spesifieke konteks is. Strukturele ingenieurswese ons in staat stel om 'n nuttelose of kwaadwillige kode te vind, maar dit is kompleks en is nie van toepassing op groot programme. Metodes wat gebaseer is op die spesifikasies - die enigstes wat in staat is om die vermiste kode identifiseer is, maar hulle kan 'n buitestaander nie identifiseer. Sommige tegnieke is meer geskik vir 'n spesifieke toetsvlak, tipe fout of konteks as die ander.

Hier is die belangrikste verskille tussen die drie dinamiese toets tegnieke - word 'n vergelyking tafel tussen die drie vorme van debugging sagteware.

aspek	Die swart boks metode	Grys boks metode	Wit-box metode
Beskikbaarheid van inligting oor die samestelling van die program	Ondersoek net die basiese aspekte van	Gedeeltelike kennis oor die interne struktuur van die program	Volle toegang tot die bronkode
Graad van fragmentasie van die program	lae	sentrale	hoë
Wat produseer ontfouting?	Eindgebruikers, testers en ontwikkelaars	Eindgebruikers, ontwikkelaars en debug gers	Ontwikkelaars en testers
basis	Toets is gebaseer op die eksterne noodsituasies.	Diagramme databasis, data vloeidiagramme, staat van interne kennis van die algoritme en argitektuur	Die interne toestel is ten volle bewus
Die graad van dekking	Minder omvattende en vereis 'n minimum van tyd	sentrale	Potensieel die mees omvattende. Tydrowend
Data en interne grense	Debug net deur trial and error	Kan nagegaan die data domeine en interne grense, as hulle bekend	Die beste toets data domeine en interne grense
Geskiktheid toets algoritme	geen	geen	Ja

outomatisering

Outomatiese metodes van sagteware toets is baie vereenvoudig die proses van inspeksie, ongeag van die tegniese omgewing en die konteks van die. Hulle word gebruik in twee gevalle:

1) om die vervelige, herhalende of noukeurige take soos lêer vergelyking met 'n paar duisend rye om tyd vry te stel vir konsentrasie van die toetser meer belangrike punte outomatiseer;

2) vir die uitvoering van die dop of take wat nie maklik deur mense uitgevoer word soos prestasie verifikasie of ontleding reaksie tyd wat gemeet kan word in honderdstes van 'n sekonde.

Toets gereedskap kan geklassifiseer word in verskillende maniere. Die volgende afdeling is gebaseer op die take wat hulle ondersteun:

• toets bestuur, wat projekbestuur ondersteuning, weergawes, konfigurasies, risiko-analise, toets dop, foute, gebreke, en verslaggewing gereedskap sluit;
• vereistes bestuur, wat die stoor vereistes en spesifikasies sluit, maak seker hulle vir volledigheid en dubbelsinnigheid, hul prioriteit en die naspeurbaarheid van elke toets;
• kritiese oorsig en statiese analise, insluitend vloei monitering en take, opname en berging van kommentaar, defek opsporing en beplande verbeterings bestuur skakels na Voëlaftiklyste en reëls, dop kommunikasie brondokumente en kode statiese analise om defekte op te spoor, die nakoming van die standaarde van die skryf-kode, analise van strukture en afhanklikhede, berekening van die metrieke parameters van die kode en argitektuur. Daarbenewens gebruik opstellers, ontleder, kragopwekkers en verhoudings van kruisverwysings;
• modellering, wat gereedskap vir modellering sakegedrag sluit en toets die modelle;
• toetsontwikkeling verseker die geslag van data na verwagting op grond van omstandighede en gebruikerskoppelvlak modelle en kode, daarin slaag om te skep of lêers en databasisse, boodskappe, data validering te verander op grond van die reëls van die bestuur, statistiese analise van die voorwaardes en risiko's;
• 'n kritiese beskouing van die invoer van die data deur middel van 'n grafiese gebruikerskoppelvlak, API, command line gebruik van comparatoren te help identifiseer suksesvolle en onsuksesvolle toetse;
• ondersteuning debugging omgewing wat jou toelaat om die vermiste hardeware of sagteware, in Vol. h. Simulasie toerusting wat gebaseer is op die vasgestelde opbrengs subset, terminale emulators, selfone en netwerke, die omgewing vir die beheer van tale, bedryfstelsels en vervang hardeware deur die vervanging van die vermiste komponente bestuurder, fiktiewe modules, ens, sowel as gereedskap vir die opneem van en die wysiging van die OS versoek die beperking CPU simulasie, RAM, ROM, of netwerk .;
• .. 'N vergelyking van data lêers, databases, check die verwagte resultate tydens en na die toets voltooi is, insluitend dinamiese en joernaal vergelyking, outomatiese "Orakels";
• laag meting vir die lokalisering van die geheue lekkasies en verkeerde sy beheer gedrag te skat stelsel onder gesimuleerde vrag genereer vrag aansoeke, databasisse, netwerke of bedieners in 'n realistiese scenario van groei vir meting, ontleding en verifikasie van verslag stelsel bronne;
• sekuriteit;
• prestasietoetsing, vrag en dinamiese analise;
• ander gereedskap, in Vol. h. om die spelling en sinsbou, check netwerk sekuriteit, die beskikbaarheid van alle webblaaie en ander.

perspektief

Met die veranderende neigings in die sagteware-industrie, die proses van debugging is ook onderhewig aan verandering. Daar is nuwe metodes van sagteware toets, soos 'n diens-orientirovannae argitektuur (SOA), draadlose tegnologie, mobiele dienste, en so aan. E., oopgemaak het nuwe maniere van toets sagteware. Sommige van die veranderinge wat in die bedryf verwag oor die volgende paar jaar word hieronder gelys:

• testers sal 'n liggewig model wat ontwikkelaars in staat wees om jou kode te gaan sal wees verskaf;
• ontwikkeling van toets metodes, insluitend besigtiging en modellering programme op 'n vroeë stadium, sal baie van die teenstrydighede uit te skakel;
• teenwoordigheid van verskeie onderskeppings toets sal die tyd van die fout opsporing verkort;
• Statiese ontleder en opsporing beteken om meer wyd gebruik word;
• die gebruik van minerale matrikse, soos dekking van die spesifikasie, sal die omvang van die model en kode dekking die ontwikkeling van projekte te bepaal;
• kombinatoriese gereedskap toelaat testers om die prioriteitsgebiede vir ontfouting bepaal;
• testers sal 'n meer intuïtief en waardevolle dienste regdeur die ontwikkeling van sagteware proses te verskaf;
• debug gers kan gereedskap en sagteware toets metodes geskryf in en interaksie met 'n verskeidenheid van programmeertale te skep;
• Ontfouting kundiges sal meer professioneel opgelei.

Sal vervang word deur 'n nuwe sake-georiënteerde sagteware toets metodes, die manier van interaksie met die stelsels en die inligting wat hulle verskaf, terwyl die vermindering van risiko's en die verhoging van die voordele van die besigheid veranderinge verander.