Kuidas testimine toimub. Testid tarkvara arendusprotsessis. Tööriistad ja infrastruktuur

See artikkel pakub laiendatud nimekirja küsimustest (ja vastustest), mida potentsiaalne tööandja saab tarkvara testijatele küsida. Artikkel on üles ehitatud küsimuste-vastuste vormingus ning sisaldab eelkõige küsimusi testimise automatiseerimise, sertifitseerimise kohta ISTQB ja CSTE ja palju muud, mis võimaldab hinnata ettevalmistuse taset. Loodame, et pärast artikli lugemist saate valmistuda intervjuudeks või vähemalt vastata küsimustele enesekindlamalt.

AT. Mis on dünaamiline testimine?

O. See on testimine, käivitades erinevate sisendväärtustega koodi või programmi ja kontrollides tulemusi.

AT. Mis on GUI testimine?

O. GUI (graafiline kasutajaliides) testimine: tarkvara liidest testitakse, et veenduda, et see vastab nõuetele.

AT. Mis on ametlik testimine?

O. Tarkvara verifitseerimine, vastavalt testimisplaanile, testimisprotseduuridele ja sellega seotud dokumentatsioonile, arvestades kliendi soove.

AT. Mis on riskipõhine testimine?

O. Määratakse süsteemi olulisemad osad, seejärel kehtestatakse nende testimise järjekord, seejärel järgneb tegelik testimine.

AT. Mis on varajane testimine?

O. Testimine tehakse võimalikult varakult, et SDLC-s varakult tuvastada defekte. See võimaldab defekte kiiremini avastada ja kõrvaldada, säästes kulusid.

AT. Mis on ammendav testimine?

O. Funktsionaalsuse testimine, kasutades kehtetuid ja kehtivaid sisendandmeid ja eeldusi.

AT. Mis on defektide kogunemine?

O. Isegi väike moodul või funktsionaalsus võib sisaldada mitmeid defekte, mistõttu tuleb funktsionaalsuse testimisele rohkem tähelepanu pöörata.

AT. Mis on pestitsiidide paradoks?

O. Kui olemasolevad testjuhtumid ei suuda defekte tuvastada, võib olla väärt testjuhtumite lisamist/ülevaatamist, et leida rohkem defekte.

AT. Mis on staatiline testimine?

O. Koodi kontrollimine käsitsi ilma programmita. Selle protsessi käigus leitakse koodis probleeme, kui seda üle vaadatakse ja nõuetega võrreldakse.

AT. Mis on positiivne test?

O. Testimine, mis viiakse läbi rakenduses, et teha kindlaks, kui hästi süsteem toimib. Seda lähenemisviisi tuntakse sagedamini kui "läbikatset".

AT. Mis on negatiivne test?

O. Negatiivsete stsenaariumide testimine tarkvaras: kas süsteem annab vea, kui peaks või mitte.

AT. Mis on otsast lõpuni testimine?

O. Süsteemi üldise funktsionaalsuse testimine, sealhulgas andmete integreerimine moodulites.

AT. Mis on uurimuslik testimine?

O. See on rakenduse uuring, et saada aimu selle funktsionaalsusest, lisades (või muutes) olemasolevaid testjuhtumeid paremaks testimiseks.

AT. Mis on ahvi testimine?

O. Rakenduse testimine ilma plaanita, valikuliste kohtade testimine, et leida keerulisi süsteemitõrkeid ja seejärel defekte, mis selleni viisid.

AT. Mis on mittefunktsionaalne testimine?

O. Süsteemi erinevate mittefunktsionaalsete aspektide valideerimine, nagu kasutajaliidesed, ühilduvus, jõudlus jne.

O. Kontrollige, kui lihtne on lõppkasutajatel rakendust mõista ja hallata.

O. Kontrollitakse, kui hästi on rakenduses kõik turvatingimused rakendatud.

O. Süsteemi erinevate omaduste tõhususe analüüs - reaktsiooniaeg, üldine jõudlus, et teha kindlaks, kui kiiresti süsteem koormuse all töötab.

AT. Mis on koormustestimine?

O. Rakenduse funktsionaalsuse ja jõudluse analüüs erinevates tingimustes.

AT. Mida stress-testimine?

O. Süsteemi stabiilsuse kontrollimine normaalse töö piire ületavates tingimustes. Või süsteemiressursside vähendamine ja koormuse hoidmine teatud tasemel, et kontrollida, kuidas rakendused käituvad.

AT. Mis on protsess?

O. Protsess on praktikate kogum konkreetse eesmärgi saavutamiseks; võib hõlmata tööriistu, meetodeid, materjale ja inimesi.

AT. Mis on konfiguratsioonihaldus?

O. Tarkvaraarenduse muudatuste leidmise, korraldamise ja kontrollimise protsess. Või tarkvaraarendusprojekti jälgimise ja juhtimise metoodika.

O. Joonistamine:

• katseplaan
• Testi stsenaariumid
• testjuhtumid
• Testjuhtumite läbiviimine
• Tulemuste kontrollimine
• Defektidest teatamine
• Defektide jälgimine
• Sulgemisdefektid
• Testi vabastamine

AT. Mida CMMI tähendab?

O. Capability Maturity Model Integration (arenguprotsesside küpsuse mudel).

AT. Mis on programmianalüüs?

O. Programmi lähtekoodi mitteametlik analüüs defektide tuvastamiseks ja programmeerimistehnikate kontrollimiseks.

O.Üksikute programmide, moodulite või koodielementide testimine.

AT. Mis on integratsioonitaseme testimine?

O. Asjakohaste programmide, moodulite (või koodiühikute) testimine.

AT. Mis on süsteemitaseme testimine?

O. Kogu arvutisüsteemi testimine kõikidele moodulitele. Selline testimine võib hõlmata funktsionaalset ja struktuurilist testimist.

AT. Mis on alfa testimine?

O. Kogu arvutisüsteemi testimine enne kasutaja testimise (UAT) faasi.

AT. Mis on UAT?

O. Arvutisüsteemi testimine kliendi poolt, et kontrollida, kas süsteem vastab nõuetele.

AT. Mis on testiplaan?

O. Dokument, mis kirjeldab testimise ulatust, lähenemisviisi, ressursse ja ajakava, mis identifitseerib testitavad üksused, üksikud funktsioonid, testimisülesanded, konkreetseid teste läbi viivad inimesed ja täiendavat planeerimist nõudvad riskid.

AT. Mis on testskript?

O. Kõigi võimalike katsealade tuvastamine.

AT. Mis on ECP (ekvivalentsusklassi partitsioon)?

O. Testjuhtumite genereerimise meetod.

AT. Mis on defekt?

O. Mis tahes ebatäiuslikkus tarkvara töös. Või kui oodatud tulemus ei vasta rakenduse tegelikule toimimisele.

AT. Mis on kriitilisus?

O. Määrab defektitaseme funktsionaalsest vaatepunktist, s.t. kui kriitiline on defekt rakendusele.

AT. Mis on prioriteet?

O. Näitab defekti parandamise kiireloomulisust.

AT. Mis on kordustestimine?

O. Rakenduse uuesti testimine, et näha, kas vead on parandatud.

O. Olemasolevate funktsionaalsete ja mittefunktsionaalsete piirkondade kontrollimine pärast rakenduse üksikute osade muutmist või uue funktsionaalsuse lisamist.

AT. Mis on taastumistest?

O. Kontrollitakse süsteemi võimet tulla toime mõne ootamatu olukorraga.

AT. Mis on globaliseerumise testimine?

O. Rakenduse käivitamise võimalust olenemata selle geograafilisest ja kultuurilisest keskkonnast testitakse. Keele, kuupäeva, vormingu ja valuuta muutmise võimalust kontrollitakse, kui rakendus on välja töötatud mitme riigi kasutajatele.

AT. Mis on lokaliseerimise testimine?

O. Kontrollige, kas rakendus sobib konkreetsele kohalikule kasutajarühmale, kultuurilistele ja geograafilistele tingimustele.

AT. Mis on installi testimine?

O. Tarkvara eduka installimise võimalust kontrollitakse vastavalt installidokumentatsioonile.

AT. Mis on eemaldamise testimine?

O. Tarkvara desinstallimise võimaluse kontrollimine.

AT. Mis on ühilduvuse testimine?

O. Kontrollitakse rakenduse ühilduvust muu tarkvara ja riistvaraga.

AT. Mis on testimisstrateegia?

O. See on testiplaani osa, mis kirjeldab, kuidas testimist tehakse ja mis tüüpi testimist tuleb teha.

AT. Mis on testjuhtum?

O. Testjuhtum on kindlate sammude kogum, mille abil testitakse süsteemi funktsionaalsust.

AT. Mis on äriprotsesside valideerimise testjuhtum?

O. See testjuhtum on kirjutatud teatud tingimuse või nõude testimiseks.

AT. Kuidas määratakse hea test?

O. Testjuhtum, millel on kõrge defektide tuvastamise prioriteet.

AT. Mis on kasutusjuhtude testimine?

O. Selline testimine teeb kindlaks, kas tarkvara on loodud vastavalt kasutusjuhtumile.

AT. Mis on defekti vanus?

O. Aeg avastamiskuupäeva ja defekti sulgemise kuupäeva vahel.

AT. Mis on Showstopperi defekt?

O. Defekt, mis sunnib testimisprotsessi peatama.

O. See on STLC viimane etapp. Juhtkond koostab testiaruanded, selgitab olemasolevate andmete põhjal projektistatistikat.

AT. Mis on ämbritestimine?

O. Bucket Testing ehk A/B testimine. Erineva kujunduse kõige sagedamini uuritud mõju on veebisaitide mõõdik. Saidi kaks versiooni töötavad ühel või mitmel veebilehel, et teha kindlaks klikkide erinevus.

AT. Mis on testi alguse ja lõpu kriteeriumid?

O. Käivituskriteeriumid – protsess, mis peab olemas olema süsteemi alguses. See võib olla:

• SRS-tarkvara
• Kasutusjuhtum
• Testjuhtum
• Katseplaan

Täitmise kriteerium määrab taotluse valmisoleku vabastamiseks. See võib olla:

• Testi tulemused
• Mõõdikud
• Testi analüüsi aruanne

AT. Mis on valuuta testimine?

O. See on keeruline kasutajate testimine samaaegse rakendusele juurdepääsu kontrollimiseks, et kontrollida mõju koodile, moodulile või andmebaasile. Peamiselt tuvastab koodis ummikseisud.

O. Veebirakenduste testimine toimub veebisaidil laadimise, jõudluse, turvalisuse, funktsionaalsuse, liidese, ühilduvuse ja muude kasutatavusega seotud probleemide kontrollimiseks.

O. Elementide testimine (või külgtestimine) võimaldab kontrollida lähtekoodi üksikute moodulite tööd.

AT. Mis on liidese testimine?

O. Liidese testimine kontrollib üksikute moodulite koostoimet. Kõige sagedamini kasutatakse GUI-rakenduste kasutajaliidese testimiseks.

AT. Mis on gamma testimine?

O. Gamma testimine toimub siis, kui tarkvara on väljalaskmiseks valmis, kontrollitakse vastavust nõuetele.

Märkimisväärne osa tootmisprotsessist põhineb tarkvara testimisel. Mis see on ja kuidas selliseid tegevusi läbi viiakse, arutatakse selles artiklis.

Mida nimetatakse testimiseks?

Selle all mõeldakse protsessi, mille käigus käivitatakse tarkvara, et tuvastada koodi ebaõige toimimise kohad. Keerulised sisendandmed koostatakse teadlikult parima tulemuse saavutamiseks. Tõendaja põhieesmärk on luua optimaalsed võimalused ebaõnnestumiseks, kuigi mõnikord saab arendatud programmi testimist lihtsustada tavapäraseks funktsionaalsuse ja funktsioonide toimimise kontrollimiseks. See säästab aega, kuid sageli kaasneb sellega tarkvara ebausaldusväärsus, kasutajate rahulolematus jne.

Tõhusus

See, kui hästi ja kiiresti vigu leitakse, mõjutab oluliselt vajaliku kvaliteediga tarkvara arendamise kulusid ja kestust. Niisiis, hoolimata asjaolust, et testijad saavad mitu korda vähem palka kui programmeerijad, ulatub nende teenuste maksumus tavaliselt 30–40% -ni kogu projekti maksumusest. See on tingitud töötajate arvust, kuna vea otsimine on ebatavaline ja üsna keeruline protsess. Kuid isegi kui tarkvara on läbinud kindla arvu teste, pole 100% garantiid, et vigu ei esine. Me lihtsalt ei tea, millal nad ilmuvad. Selleks, et motiveerida testijaid valima selliseid testimistüüpe, mis tõenäolisemalt vea leiavad, kasutatakse erinevaid motiveerimisvahendeid: nii moraalseid kui ka materiaalseid.

Tööle lähenemine

Optimaalne olukord on see, kui rakendatakse erinevaid mehhanisme tagamaks, et tarkvaras ei esineks algusest peale vigu. Selleks on vaja hoolitseda pädeva arhitektuurilise projekteerimise, selge lähteülesande eest, samuti on oluline mitte teha korrektiive seoses sellega, kui töö projektiga on juba alanud. Sel juhul seisab testija ees ülesandeks leida ja tuvastada väike arv vigu, mis lõpptulemusse jäävad. See säästab nii aega kui ka raha.

Mis on test?

See on kontrollija tegevuse oluline aspekt, mis on vajalik programmikoodi vigade edukaks tuvastamiseks. Need on vajalikud rakenduse õigsuse kontrollimiseks. Mis sisaldub testis? See koosneb nende algandmetest ja väärtustest, mis tuleks saada tulemusena (või vahepealsetena). Probleemide ja ebakõlade edukamaks tuvastamiseks tuleks testid kirjutada pärast algoritmi väljatöötamist, kuid programmeerimist pole alustatud. Lisaks on vajalike andmete arvutamisel soovitav kasutada mitut lähenemisviisi. Sel juhul suureneb vea leidmise tõenäosus, kuna saate koodi uurida teisest vaatenurgast. Põhjalikud testid peaksid võimaldama kontrollida valmis tarkvaratoote välismõjusid ja selle tööalgoritme. Eriti huvitavad on piiravad ja degenereerunud juhtumid. Nii on vigadega tegevuste praktikas sageli võimalik avastada, et tsükkel töötab korda vähem või rohkem, kui oli planeeritud. Oluline on ka arvuti testimine, tänu millele saab erinevatel masinatel kontrollida vastavust soovitud tulemusele. See on vajalik selleks, et tagada tarkvara töötamine kõigis arvutites. Lisaks on mitmeplatvormiliste arenduste loomisel oluline arvuti testimine, millel arendust tehakse.

Vigade leidmise kunst

Programmid on sageli suunatud suure hulga andmetega töötamiseks. Kas see tuleb tõesti täielikult luua? Ei. Programmi "miniaturiseerimise" praktika on muutunud laialt levinud. Sel juhul on andmemaht mõistlikult vähenenud võrreldes sellega, mida tuleks kasutada. Vaatame näidet: on programm, mis loob 50x50 maatriksi. Teisisõnu peate käsitsi sisestama 2500 tuhat väärtust. See on kindlasti võimalik, kuid see võtab väga kaua aega. Kuid jõudluse kontrollimiseks saab tarkvaratoode maatriksi, mille mõõtmed on 5x5. Selleks peate sisestama juba 25 väärtust. Kui sel juhul täheldatakse normaalset, vigadeta töötamist, tähendab see, et kõik on korras. Kuigi ka siin on lõkse, mis seisnevad selles, et miniaturiseerimise käigus tekib olukord, mille tulemusena muutused muutuvad kaudseks ja kaovad ajutiselt. See on ka väga haruldane, kuid siiski juhtub, et ilmnevad uued vead.

Püüdletud eesmärgid

Tarkvara testimine ei ole lihtne ülesanne, kuna seda protsessi ei saa täielikult vormistada. Suurtel programmidel pole peaaegu kunagi vajalikku täpset viidet. Seetõttu kasutatakse juhendina mitmeid kaudseid andmeid, mis aga ei suuda täielikult kajastada silutavate tarkvaraarenduste omadusi ja funktsioone. Pealegi tuleb need valida nii, et õige tulemus arvutataks juba enne tarkvaratoote testimist. Kui seda ette ei tehta, siis on kiusatus kõike umbkaudselt läbi mõelda ja kui masina tulemus jääb ettenähtud vahemikku, siis tehakse ekslik otsus, et kõik on õige.

Kontrollimine erinevates tingimustes

Programmide testimine toimub reeglina mahus, mis on vajalik funktsionaalsuse minimaalseks kontrollimiseks piiratud vahemikus. Tegevus viiakse läbi parameetrite ja nende töötingimuste muutmisega. Testimisprotsessi võib jagada kolme etappi:

• Kontrollige tavatingimustes. Sel juhul testitakse väljatöötatud tarkvara põhifunktsionaalsust. Saadud tulemus peaks olema ootuspärane.
• Kontrollimine hädaolukordades. Nendel juhtudel tähendab see piiriandmete saamist, mis võib loodud tarkvara jõudlust negatiivselt mõjutada. Näiteks võib tuua ülisuurte või väikeste numbritega töö või üldiselt saadud teabe täieliku puudumise.
• Erandi kontroll. See hõlmab andmete kasutamist, mis jäävad töötlemisest kaugemale. Sellistes olukordades on väga halb, kui tarkvara tajub neid arvutamiseks sobivatena ja annab usutava tulemuse. Sellistel juhtudel tuleb hoolikalt tagasi lükata kõik andmed, mida ei saa õigesti töödelda. Samuti on vaja selle kohta teavet anda kasutajale.

Tarkvara testimine: tüübid

Tarkvara ilma vigadeta on väga raske luua. See võtab palju aega. Hea toote saamiseks kasutatakse sageli kahte tüüpi testimist: "Alfa" ja "Beeta". Mis need on? Alfatestimisest rääkides tähendab see kontrolli, mille arenduspersonal ise “labori” tingimustes läbi viib. See on kontrollimise viimane etapp enne programmi lõppkasutajatele levitamist. Seetõttu püüavad arendajad maksimaalselt ümber pöörata. Töö hõlbustamiseks saab andmeid logida, et luua probleemide ja paranduste ajalugu. Beetatestimine viitab tarkvara tarnimisele piiratud arvule kasutajatele, et nad saaksid programmi kasutada ja tuvastamata jäänud vead. Antud juhul on omapäraks see, et sageli kasutatakse tarkvara muul kui ettenähtud otstarbel. Tänu sellele tuvastatakse rikkeid seal, kus varem midagi ei märgatud. See on täiesti normaalne ja te ei pea selle pärast muretsema.

Testimise lõpetamine

Kui eelmised etapid olid edukalt läbitud, jääb üle teha vastuvõtutest. Sel juhul muutub see pelgaks formaalsuseks. Selle kontrolli käigus kinnitatakse, et lisaprobleeme ei leita ja tarkvara saab turule lasta. Mida olulisem on lõpptulemus, seda hoolikamalt tuleks kontrolli läbi viia. On vaja tagada, et kõik etapid oleksid edukalt läbitud. Selline näeb välja kogu testimisprotsess. Nüüd tutvume tehniliste üksikasjadega ja räägime kasulikest tööriistadest, nagu testimisprogrammid. Mis need on ja millistel juhtudel neid kasutatakse?

Automatiseeritud testimine

Varem arvati, et arendatud tarkvara dünaamiline analüüs on liiga raske lähenemine, mida on ebaefektiivne kasutada defektide tuvastamiseks. Kuid programmide keerukuse ja mahu suurenemise tõttu on ilmnenud vastupidine seisukoht. Automatiseeritud testimist kasutatakse seal, kus kättesaadavus ja turvalisus on esmatähtsad. Ja need peaksid olema iga sisendi jaoks. Sellise testimise jaoks sobivad näiteks järgmised programmid: võrguprotokollid, veebiserver, liivakast. Järgmisena vaatleme mõnda näidist, mida sellisteks tegevusteks kasutada. Kui olete huvitatud tasuta testimisprogrammidest, siis on nende hulgast üsna raske kvaliteetseid leida. Kuid väljakujunenud projektidest on häkitud "piraat" versioone, nii et saate pöörduda nende teenuste poole.

Laviin

See tööriist aitab tuvastada defekte, testides programme dünaamilise analüüsi režiimis. See kogub andmeid ja analüüsib arendatud objekti täitmisteed. Tester on varustatud sisendandmete komplektiga, mis põhjustab tõrke või läheb mööda olemasolevatest piirangutest. Hea verifitseerimisalgoritmi olemasolu tõttu töötatakse välja suur hulk võimalikke olukordi. Programm võtab vastu erinevaid sisendandmete komplekte, mis võimaldavad simuleerida märkimisväärset hulka olukordi ja luua tingimused, kus rikke ilmnemine on kõige tõenäolisem. Programmi oluliseks eeliseks on heuristilise mõõdiku kasutamine. Kui on probleem, leitakse suure tõenäosusega rakenduse viga. Kuid sellel programmil on piirangud, näiteks ainult ühe märgistatud sisendpesa või faili kontrollimine. Toimingute (nt programmide testimise) sooritamisel sisaldab see üksikasjalikku teavet nullosutitega seotud probleemide, lõpmatute tsüklite, valede aadresside või teekide kasutamisest tingitud tõrgete kohta. Loomulikult pole see tuvastatud vigade täielik loetelu, vaid ainult nende levinumad näited. Kahjuks peavad arendajad puudused parandama - automaatsed tööriistad ei sobi nendeks eesmärkideks.

KLEE

See on hea mälu testimise programm. See suudab pealt kuulata umbes 50 süsteemikõnet ja suurt hulka virtuaalseid protsesse, täites seega paralleelselt ja eraldi. Aga üldiselt ei otsi programm üksikuid kahtlaseid kohti, vaid töötleb maksimaalselt võimalikku koodikogust ja analüüsib kasutatavaid andmeedastusteed. Seetõttu sõltub programmi testimise aeg objekti suurusest. Kontrollimisel panustatakse sümboolsetele protsessidele. Need on üks võimalikest viisidest testitava programmi ülesannete täitmiseks. Tänu paralleelsele tööle saate analüüsida paljusid uuritava rakenduse töövõimalusi. Iga tee jaoks salvestatakse pärast testimise lõppu sisendandmete komplektid, millest test algas. Tuleb märkida, et KLEE-d kasutavad testimisprogrammid aitavad tuvastada suure hulga kõrvalekaldeid, mida ei tohiks olla. See võib leida probleeme isegi rakendustes, mida on arendatud aastakümneid.

Kasutatavuse testimine aitab suurendada saidi või veebipoe konversiooni, leida kasutajate varjatud kavatsusi ja soove ning teha otsus lisafunktsionaalsuse arendamiseks. See pole ainus saidi uurimise meetod. Tehke ülesannete põhjal otsus meetodi valiku kohta. Vajadusel

leidke liideses vigu või kontrollige kasutajate stsenaariumide mugavust, testige saidi kasutatavust. Kui soovite võrrelda kahe maandumisvaliku teisendamist, on parem teha A/B-test.

Testimise eesmärgid on igal ettevõttel erinevad: keegi testib prototüüpi või kontseptsiooni, keegi testib hüpoteese, keegi uurib kasutajate stsenaariume, seega on meetodid ja mõõdikud erinevad. Kuid läbiviimise reeglid, ettevalmistamise etapid ja kaasasolevate dokumentide komplekt on sarnased. Koostatud üksikasjalikud juhised saidi kasutatavuse testimise läbiviimiseks.

Kust alustada

Sihid ja eesmärgid. Seadke testimise põhieesmärk, mis määrab edasise suuna: ülesanded, ülesanded, meetodid ja vastajate valik. Eesmärgist lähtuvalt sõnastage probleem või ülesanne. See võib olla väljatöötatud toote testimine või vigade otsimine pärast ümberkujundamist. Näiteks muutis ettevõte tellimislehe kujundust, misjärel konverteerimine vähenes. Testimise abil saavad teadlased aru, miks see juhtus ja mida teha.

Hüpoteesid. Esitage hüpotees, et uuring kinnitab või lükkab ümber. Oletame, et hotelli broneerides tellivad kasutajad lennujaamatransfeeri eraldi sõnumiga, ilma spetsiaalset tellimisvormi kasutamata. Sel juhul võib hüpoteesi variant olla järgmine: "kasutajad ei saa aru, et see on ülekande tellimise vorm, või peavad selle täitmist tülikaks."

Stsenaariumid. Eraldi testige kasutaja käitumise stsenaariume – kuidas inimesed saidiga suhtlevad. Igal lehel on oma skript. Selle loomiseks vasta neljale küsimusele:

1. Kust kasutaja tuli?
2. Mida ta sellel lehel nägema peaks?
3. Mis eesmärgil ta lehele tuli?
4. Kuidas peaks visiit lõppema?

Kasutaja skript ei pea olema pikk ja keeruline. Mõnikord, mida lühem on suhtlus, seda parem on konversioon. Näiteks kassette, laadijaid, objektiive tarniva ettevõtte jaoks on kiirus oluline, mistõttu on soovitav, et kasutaja saaks kohe aru, et kättetoimetamisteenus talle sobib.

Kui saidile tulevad erinevad külastajate rühmad, koostage iga rühma jaoks oma käitumisstsenaariumid. Oletame, et hulgi- ja jaemüügisaidil on kolm klientide rühma: suured hulgimüüjad, väikesed hulgimüüjad ja jaemüüjad. Looge iga rühma jaoks eraldi jaotised ja kirjutage näidisküsimuste vastuste põhjal stsenaariumid.

Mida saab mõõta

Kvantitatiivne uuring alati konkreetne ja fokusseeritud, suunatud numbriliste näitajate saamisele. See võib olla saidil tegevuse lõpetamiseks kuluv aeg või ülesande täitnud vastajate protsent. Jah/ei tulemusi saab esitada ka numbritena. Näiteks viige need kahendsüsteemi: jah - 1 punkt, ei - 0 punkti.

Tihti kasutatakse testimisel Jacob Nielseni meetodit, mis teisendab tulemused protsendiks ja arvutab välja edukuse protsendi. Soovitame hindamisskaalat lihtsustada ja kasutada kolme võimalust.

• teostatakse iseseisvalt - 100%;
• teeme seda moderaatori abiga - 50%;
• ebaõnnestus - 0%.

Et teha kindlaks, kui sageli kasutajatel probleeme esineb, arvutage nende sagedus. Selleks loe kokku vastajate arv, kes ei saanud sama probleemi tõttu ülesannet täita. Andke testis osalejatele samad ülesanded, siis on sagedusnäidik usaldusväärne.

Kvalitatiivne uuring valida, et saada palju erinevaid kommentaare, mõista kasutajate mõtteviisi, leida peidetud probleeme. Testimine põhineb avatud ja paindlikel küsimustel. Selleks viiakse läbi intervjuu, mis näitab vastajate rahulolu astet. Kvalitatiivse uurimistöö läbiviimiseks on palju meetodeid ja küsimustikke.

Näiteks Kano mudel, mille töötas välja Jaapani teadlane. Selle abiga saate teada mitte ainult saidi praeguse versiooniga rahulolu, vaid ka kasutajate ootusi. Kõik vastajate vastused teisendatakse punktideks ja järjestatakse ootuste skaalal alates "Mulle meeldib" ja "Ma ootan seda" kuni "Mulle ei meeldi ja ma ei saa sellega leppida". Selle tulemusena koostavad teadlased graafiku, mis näitab, mida publik täpselt arvab:

• enesestmõistetavaks;
• saidi konkurentsieelis;
• omadused, mis neid rõõmustavad;
• tähtsusetu.

Kvalitatiivse uurimistöö tulemuste põhjal on vaja saadud tulemusi õigesti tõlgendada. Võib-olla teevad vastajad palju huvitavaid ettepanekuid, kuid hindavad neid tehnilise teostuse ja arenduskulude osas. Igal juhul proovige täpselt aru saada, millist vajadust nende ettepanek katab. See on vajalik selleks, et leida oma ettevõttele sobiv viis saidi kasutatavuse parandamiseks.

Millist meetodit valida

Vaatlus- kõige lihtsam meetod: vastaja töötab nagu tavaliselt, moderaator jälgib ja analüüsib tema tegevust. Lõpuks täidab vastaja küsimustiku ja jagab oma muljeid saidi kohta. Meetod on hea, sest kasutaja suhtleb saidiga loomulikult, teda ei survesta ümbritsevad asjaolud.

Kuid sellel on ka puudus: vastaja täidab küsimustiku pärast testi täitmist, mistõttu ta ei pruugi täpselt mäletada, miks ta seda nii või teisiti tegi. See tooks siis kaasa vastaja tegevuse väära tõlgendamise.

Mõeldes valjusti. Selle populaarse meetodi pakkus välja Jakob Nielsen. Selle olemus seisneb selles, et kasutaja hääldab kõik oma tegevused valjusti. Sellise käitumisega hakkavad vastajad aga ülesannete täitmisel läbimõeldumalt suhtuma ja osa loomulikkusest läheb kaduma.

Dialoog moderaatoriga. Meetod sobib kõige paremini prototüüpide ja kontseptsioonide kvalitatiivsete uuringute läbiviimiseks. Testimise ajal suhtlevad vastajad aktiivselt moderaatoriga, esitavad talle küsimusi ja annavad kohe tagasisidet.

varju meetod. Kolm osalejat töötavad korraga: vastaja, moderaator ja ekspert. Vastaja täidab vabalt ja iseseisvalt ülesandeid, moderaator fikseerib, ekspert kommenteerib vastaja tegevust.

Tagasivaade. See on meetod, mis ühendab endas vaatlemise ja "valjusti mõtlemise". Esmalt täidab vastaja ülesandeid, seejärel vaatab oma tegevustest videosalvestist ja kommenteerib neid. Peamine puudus on testimisaja märkimisväärne pikenenud.

Kuidas testida

Isiklik kontakt. Las moderaator loob vastajatega sõbraliku kontakti. Rääkige testimisest ja selle eesmärkidest, juhtige osalejale tähelepanu, et tema vastused aitavad ettevõttel toodet paremaks muuta. Viige läbi lühike infotund, milles selgitage ülesannete olemust, kirjeldage testimisprotseduuri.

Dokumentatsioon. Allkirjastage vastajaga vajalikud dokumendid: isikuandmete töötlemise leping ja vajadusel testitulemuste mitteavaldamise leping. Kui lapsed osalevad testimises, allkirjastage vanematega dokument, mis kinnitab nende nõusolekut uuringus osaleda.

proovitestimine vajalik, kui toode on keeruline või ülesanded võivad vastajatele raskusi tekitada. Nii saavad nad saidiga tuttavaks ja mõistavad nõudeid. Kui teil on suur ja pikk uuring, tehke enne peamist proovitesti. Nii leiate ettevalmistuses puudused ja kõrvaldate need.

Pea meeles

Kasutaja suhtlemine iga saidi kasutatavusega peab olema tõhus, produktiivne ja rahuldust pakkuv. Püüdke vastata kasutaja ootustele. Selleks katsetage prototüüpe, praegust või uut saidikujundust. Probleemide ilmnemisel või praeguse jõudluse parandamiseks viige läbi testimine.

Materjali koostas Svetlana Sirvida-Llorente.

Nagu teate, äris staatilisi seisundeid pole. Ettevõte peab pidevalt arenema, et vastata hetke turuolukorrale, klientide ja omanike vajadustele. Pärast arenduse peatamist hakkab projekt kohe lagunema. Näiteks ei saa te luua veebipoodi, lisada saidile 200 toodet ja teenida igakuist kasumit 100 tuhat rubla. Selleks, et projekti kasumlikkus vähemalt ei langeks, peab ettevõtja pidevalt sortimenti laiendama, reklaamide ja kasuliku sisu avaldamise kaudu suurendama publiku ulatust, parandama saidi käitumismõõdikuid ja konversioonimäära.

Üks veebiprojektide arendamise tööriistu on A/B testimine. See meetod võimaldab teil mõõta vaatajaskonna eelistusi ja mõjutada saidi peamisi toimivusnäitajaid, sealhulgas konversioone, lehel veedetud aega, keskmist tellimuse väärtust, põrkemäära ja muid mõõdikuid. Sellest artiklist saate teada, kuidas A/B testimist õigesti läbi viia.

Mis on A/B testimine

A/B testimine on turundustehnika, mida kasutatakse veebilehe toimivuse hindamiseks ja haldamiseks. Seda meetodit nimetatakse ka split testimiseks (ingliskeelsest split testing - eraldi testimine).

A/B testimine võimaldab hinnata kahe veebilehe versiooni kvantitatiivset toimivust ning võrrelda neid omavahel. Tükeldatud testimine aitab hinnata ka lehe muudatuste, näiteks uute kujunduselementide või tegevusele kutsumise lisamise tõhusust. Selle meetodi kasutamise praktiline tähendus on leida ja rakendada lehe komponente, mis suurendavad selle tõhusust. Pöörake veelkord tähelepanu, A/B testimine on rakenduslik turundusmeetod, mille abil saate konversiooni mõjutada, müüki stimuleerida ja veebiprojekti kasumlikkust tõsta.

Jagatud testimine algab olemasoleva veebilehe (A, kontrollleht) mõõdikute hindamisest ja selle täiustamise võimaluste otsimisest. Näiteks olete loonud veebipoe. Kujutage ette, et selle poe sihtleht on 2% konversioonimääraga. Turundaja soovib seda näitajat tõsta 4%-ni, seega plaanib ta muudatusi, mis aitavad seda probleemi lahendada.

Oletame, et spetsialist arvab, et konversiooninupu värvi muutmine neutraalsest sinisest agressiivseks punaseks muudab selle paremini nähtavaks. Et näha, kas see toob kaasa rohkem müüki ja rohkem konversioone, loob turundaja veebilehe täiustatud versiooni (B, uus leht).

Split testimise tööriistade abil jagab ekspert liikluse lehtede A ja B vahel juhuslikult kaheks ligikaudu võrdseks osaks. Suhteliselt pooled külastajatest jõuavad lehele A ja teised pooled lehele B. Samal ajal peab turundaja silmas liiklusallikaid. Testimise paikapidavuse ja objektiivsuse tagamiseks on vaja saata lehtedele A ja B 50% külastajatest, kes said saidile sotsiaalvõrgustike, loomuliku otsingu, kontekstuaalse reklaami jms kaudu.

Pärast piisava teabe kogumist hindab turundaja testi tulemusi. Nagu eespool öeldud, on lehe A konversioonimäär 2%. Kui lehel B oli see 2,5%, siis muutmise nupu muutmine sinisest punaseks suurendas maandumise tõhusust tõesti. Konversioonimäär ei saavutanud aga soovitud 4%. Seetõttu otsib turundaja veelgi võimalusi lehe täiustamiseks A / B testimise kaudu. Sellisel juhul toimib punase teisendusnupuga leht kontrolllehena.

Mida testida

Nagu eespool märgitud, on jagatud testimine rakendatav meetod, mis võimaldab teil mõjutada veebisaidi erinevaid mõõdikuid. Seetõttu sõltub testimisobjekti valik eesmärkidest ja eesmärkidest, mille turundaja endale seab.

Näiteks kui teie sihtlehe põrkemäär on 99% ja enamik külastajaid lahkub sihtlehelt 2–3 sekundi jooksul pärast maandumist, võiksite kaaluda lehe visuaalsete komponentide muutmist. A/B testi abil saab turundaja leida parima lehepaigutuse valiku, valida atraktiivse värvilahenduse ja pildid ning kasutada loetavat fonti. Ja kui turundaja seisab silmitsi ülesandega tellimuste arvu suurendada, võib ta proovida vastavat konversioonivormi muuta. Tükeldatud test aitab spetsialistil valida optimaalse nupu värvi, parima tekstivaliku, väljade arvu tellimisvormis või selle asukoha.

Kõige sagedamini testivad turundajad järgmisi veebilehtede elemente:

• Konversiooninuppude tekst ja välimus, samuti nende asukoht.
• Toote nimetus ja kirjeldus.
• Konversioonivormide mõõtmed, välimus ja asukoht.
• Lehekülje paigutus ja kujundus.
• Toote hind ja muud äriettepaneku elemendid.
• Tootepildid ja muud illustratsioonid.
• Teksti hulk lehel.

Milliseid jagatud testimise tööriistu kasutada

A/B-testimiseks peab turundaja kasutama üht spetsialiseeritud teenust. Kõige populaarsem neist on Google'i sisukatsed, mis on saadaval Analyticsi süsteemi kasutajatele. Kuni 2012. aasta keskpaigani kandis see tööriist nime Google Website Optimizer. Sellega saate testida erinevaid leheelemente, sealhulgas pealkirju, fonte, teisendusnuppe ja vorme, pilte ja palju muud. Sisukatsetuste teenus jääb tasuta, mis on selle üks peamisi eeliseid. Selle puudused hõlmavad vajadust töötada HTML-koodiga.

Jagatud testimiseks saate kasutada ka järgmisi Venemaa ja välismaiseid tööriistu:

• Optimizely on Internetis kõige populaarsem tasuline A/B testimisteenus. Selle kasutamise hind on sõltuvalt tellimuse tüübist vahemikus 19–399 dollarit. Selle teenuse eelised hõlmavad võimalust luua eksperimente visuaalses liideses, mis säästab turundajat testitavate lehtede HTML-koodiga töötamisest.
• RealRoi.ru on veel üks kodumaine teenus, mis võimaldab teil läbi viia A / B testimist. Peamiste eeliste hulgas võib välja tuua selle, et see on tasuta ja väga lihtne kasutada. Kuidas see töötab, näete üksikasjalikult järgmisest videost:
• Visual Website Optimizer on tasuline teenus, mis võimaldab testida lehe erinevaid elemente. Selle tööriista kasutamiseks peab turundaja olema tuttav HTML-koodiga. Tellimuse hinnad jäävad vahemikku 49–249 dollarit.
• Unbounce on teenus, mis on loodud sihtlehtede loomiseks ja optimeerimiseks. Eelkõige võimaldab see teil läbi viia A / B testimist. Selle kasutamise maksumus on 50–500 dollarit kuus. Kodumaine analoog - LPGgeneraator. See teenus võimaldab testida ainult sellega loodud lehti.

Kuidas sisukatsetega A/B-testida

Google Analyticsi katsete teenus võimaldab teil üheaegselt testida lehe viie variatsiooni tõhusust. Seda kasutades saavad turundajad läbi viia A/B/N testimist, mis erineb tavalistest A/B katsetest võimalusega jälgida mitme uue lehe toimivust, millest igaühel võib olla mitu uut elementi.

Turundajal on võimalus iseseisvalt määrata testimisega seotud liikluse osakaalu. Testi minimaalne kestus on kaks nädalat, maksimaalne on kolm kuud. Spetsialist saab andmed analüüsi tulemuste kohta e-posti teel.

Testi jagamiseks sisukatsetega toimige järgmiselt.

1. Logige sisse oma Google Analyticsi kontole, valige sait, mille toimivust soovite testida. Pärast seda valige menüü "Käitumine – katsed".

1. Sisestage vastavasse vormi testitava lehe URL ja klõpsake nuppu "Alusta katset".

1. Valige testimiseks nimi ja eesmärk. Määrake katses osaleva liikluse protsent. Otsustage, kas soovite testi edenemise kohta meiliteateid saada. Pärast vajalike valikute valimist klõpsake nuppu "Järgmine".

1. Valige testitava lehe variatsioonid. Lisage need sobivatesse vormidesse ja klõpsake nuppu Edasi.

1. Looge katse kood. Kui te ei tea, kuidas seda lehele manustada, valige suvand "Saada kood veebihaldurile". Kui te HTML-koodi mainimise peale higi ei löö, valige suvand "Sisesta kood käsitsi".

Valige "Sisesta kood käsitsi", kui teate, kuidas HTML-koodi käsitleda

1. Kopeerige eelmisel joonisel märgitud kood ja kleepige see juhtlehe lähtekoodi. Kood tuleb sisestada vahetult sildi järele . Pärast selle toimingu lõpetamist klõpsake nuppu "Salvesta muudatused".

1. Kontrollige kontrolllehel testkoodi ja klõpsake nuppu "Alusta katset". Pange tähele, et kood tuleb lisada ainult kontrolllehele.

Esimesi testitulemusi saate hinnata mõne päeva jooksul pärast katse algust. Katsetulemuste jälgimiseks valige loendist sobiv katse ja minge aruannete lehele.

Ideid, mida tuleks kindlasti katsetada split-testinguga

Nagu eespool märgitud, aitab A/B testimine suurendada veebilehtede tõhusust. Selle turundusmeetodi tulemuste saavutamiseks peab turundaja genereerima ideid, mis võivad teatud saidi mõõdikuid positiivselt mõjutada. Te ei saa lihtsalt laest muudatusi võtta, neid rakendada ja tõhusust testida. Näiteks saidi mõõdikud tõenäoliselt ei muutu, kui otsustate lihtsalt muuta lehe tausta sinisest heleroheliseks.

Turundaja peab nägema viise lehtede täiustamiseks ja mõistma, miks need peaksid töötama. Jagatud testimine aitab lihtsalt testida spetsialisti eeldusi. Iga turundaja satub aga vahel olukorrast, kus kõik ideed on testitud, kuid soovitud tulemust pole saavutatud. Kui leiate end sellisest olukorrast, proovige rakendada järgmisi muudatusi ja vaadake, kas need toimivad.

• Eemaldage teisendusvormilt lisaväljad. Võib-olla ei taha teie potentsiaalsed tellijad oma passiandmeid avaldada.
• Lisage konversioonilehele sõnad "tasuta" või tasuta. Publik muidugi teab, et uudiskirja tellimine on tasuta. Kuid mõnikord teeb sõna tasuta tõelisi imesid, sest tasuta äädikas on magus.
• Postitage oma sihtlehele video. Sellel on tavaliselt positiivne mõju mitmetele mõõdikutele, sealhulgas põrkemäärale, konversioonimäärale ja lehel viibitud ajale.
• Pikendage perioodi, mille jooksul kasutajad saavad teie toodet tasuta testida. See on lihtne ja tõhus viis tarkvara ja veebiteenuseid müüvate ettevõtete konversioonide suurendamiseks.
• Katsetage teisendusnuppude värvi. Mõnel juhul töötavad agressiivsed punased nupud hästi. Kuid mõnikord ärritavad need kasutajaid. Kasutage oma saidi jaoks kõige tõhusama nupuvärvi leidmiseks A/B-testi.
• Lubage boonuseid 10 või 100 esimesele ostjale (tellijale). Ärge kiirustage seda lubadust tühistama isegi pärast reklaamikampaania lõppu. Paljud kasutajad ei ootagi õnnelike sekka sattumist, vaid reageerivad alateadlikult kasumlikule pakkumisele.

Kuidas ja miks testida lehtede erinevaid variatsioone

Tükeldatud testimine võimaldab hinnata veebilehtede muudatuste tõhusust. See turundusmeetod on rakendanud väärtust. See võimaldab teil peaaegu pidevalt lehti täiustada, täiustades erinevaid mõõdikuid.

Selle või selle muudatuse testimiseks peate looma lehe uue versiooni ja salvestama vana. Mõlemal valikul peavad olema erinevad URL-id. Pärast seda peaksite kasutama jagatud testide läbiviimiseks mõnda teenust, näiteks sisukatseid. Katsetulemusi võib hinnata vähemalt kaks nädalat pärast katse algust.

Kas teie arvates tasub A/B testida? Millistel juhtudel jääb see turundusmeetod ajaraiskamiseks?

Tänapäeval pööravad paljud ettevõtted ja koolituskeskused oma tähelepanu veebipõhisele testimisele, olles tundnud kõiki eeliseid, mida see teadmiste ja oskuste testimise tööriist endaga kaasa toob. Seetõttu kerkib järjest rohkem küsimusi, kuidas selline testimine toimub, millised nõuded tarkvarale esitatakse ja kuidas tulemuste objektiivsust kontrollida. Selles artiklis käsitleme kõiki asjakohaseid küsimusi.

Mis on veebipõhine testimine?

Me kõik mäletame õpilaste aegu, mil astusime värisevate kätega klassiruumi ja vastasime eksami ajal õpetaja küsimustele. Inimesed kogevad intervjuu ajal sarnaseid emotsioone, püüdes näidata oma parimat külge ja demonstreerida oma teadmisi. On lihtne mõista, et mõlemal protseduuril on palju ühist ja need nõuavad tavaliselt osalejate isiklikku kohalolekut.

Aga mis siis, kui õpilased või tööle kandideerijad on teistes linnades? Tööotsijatele kolimise eest tasumine on kulukas ettevõtmine. See kehtib ka koolituskeskustes kaugõppes õppivate inimeste kohta. Just nende probleemide lahendamiseks on vaja veebipõhist testimissüsteemi – võimalust uurida ja määrata inimese oskusi Interneti kaudu. Kõik, mida vajate, on arvuti ja Interneti-ühendus.

Tavaliselt kasutatakse veebipõhist testimist erinevates vormides – need võivad olla küsimustikud, keele- ja numbritestid, abstraktsed-loogilised ülesanded. Mõnikord peate programmi küsimustele suuliselt vastama. Meetodid on alati erinevad ja sõltuvad organisatsiooni seatud eesmärkidest.

Online testimine koolituskeskuste jaoks

Testimine koolituskeskustes on tööriist, mis võimaldab objektiivselt hinnata suure hulga õpilaste teadmisi ja oskusi minimaalse aja- ja rahalise ressursiga. Veebitestid on alati positiivselt meelestatud ja neid saab läbi viia üldises korras või individuaalse ajakava järgi, õpilaste iseseisva tööna.

See kaugõppesüsteemi (LMS) baasil ehitatud tööriist on saavutanud suure populaarsuse, sest võimaldab oluliselt laiendada auditooriumi ja kohandada teste iga koolituskeskuse individuaalsetele vajadustele. Möödas on õpilaste testimisega seotud paberimajanduse ajad.

Infotehnoloogiad pakuvad tänapäeval laia valikut meetodeid ja tehnikaid arvutipõhise teadmiste testimise korraldamiseks. Veebitesti saab korraldada väga kiiresti, just siis, kui see on kõige asjakohasem ja nõudlikum. Ja spetsialist saab seda ise teha, omades minimaalset kogemust arvuti omamisel. Need põhjused on viinud teadmiste kaugkontrolli meetodi populaarsuseni erakoolituskeskustes ja avalik-õiguslikes ülikoolides.

Personaliosakondade veebipõhine hindamine

Praegu kasutatakse professionaalset testimist valiku esimese etapina mitte ainult paljudes suurettevõtetes, vaid ka väikestes ettevõtetes. Kandidaatide käitumise, motivatsiooni, võimete ja teadmiste määramiseks peavad taotlejad täitma automatiseeritud veebitestid.

Seda kontrollimise vormi saab kasutada ka ettevõtte töötajate koolitamise protsessis, et jälgida edusamme. Tänu sellele süsteemile kontrollitakse töötajate tegelikke omadusi, nende psühholoogilisi ja professionaalseid omadusi, vastavust ametikohtade nõuetele, samuti tehakse kindlaks spetsialistide potentsiaal.

Sellise testimise peamiseks eeliseks võib nimetada korralduse mugavust ja kulutõhusust. Ärge unustage objektiivsust, sest arvuti ees on kõik võrdsed. Ametikohale kandideerija või töötaja saab vabalt keskenduda vastustele, näidates tõelist teadmiste taset. Siiski väärib märkimist, et selline test ei saa täielikult asendada isiklikku suhtlemist ja anda absoluutselt täpset ülevaadet katsealuste oskustest.

Interneti-testide korraldamine

Ettevõtte või koolituskeskuse baasil eksami läbiviimiseks on vajalik kaugõppesüsteemis kasutusele võtta vastav moodul. Kõige sagedamini kasutatakse LMS Moodle'i kaubanduslikke laiendusi (mooduleid) - see süsteem on tasuta ja serverisse installimine ei võta rohkem kui 10 minutit. Teadmiste testimiseks on olemas ka valmis veebipõhised teenused, kuid te ei saa anda täit garantiid nende süsteemide objektiivsusele, mida te ei halda.

Oluline on, et põhifunktsioonid (testide loomine, läbiviimine, kontrollimine) oleksid moodulis kvaliteetselt realiseeritud. Enne töö alustamist peab kasutaja täitma registreerimisvormi, hankima oma individuaalse numbri. Üks peamisi nõudeid testimise korraldamisel on väljatöötatud tulemuste hindamise süsteem. Tavaliselt antakse õige vastuse eest üks punkt, vale eest null. Kuid on ka keerukamaid hindamisalgoritme, mida kasutatakse psühholoogilistes ja muudes väga spetsiifilistes testides.

Kuidas hinnata veebipõhise hindamise moodulit?

Interneti-testimiseks lahendust valides tuleb ennekõike tähelepanu pöörata selle funktsionaalsusele ja kasutusmugavusele. Seetõttu esitatakse moodulitele tavaliselt järgmised nõuded:

• Juurdepääs testimisele ja haldusele läbi tavalise veebibrauseri.
• Võimalus lisada artiklitest mis tahes vormingus faile koos lingiga.
• Testitulemustel põhinev kvaliteetne aruandlussüsteem koos diagrammide väljundiga.
• Oskus luua psühholoogilisi teste.
• IPv6 standardi tugi.
• Kohandatav hindamissüsteem iga testi jaoks (skoorid, protsendid).
• Meedia sisu kasutamine testiküsimustes.
• Erinevat tüüpi küsimuste olemasolu: valikvastustega, ühe valikuga, suvaline sisestus.
• Automaatne testi kinnitamine.
• Mugav ja venestatud liides.

Tulemuste kontroll

Kaugtestimise ja -uuringu puhul on põhiprobleemiks kontroll tulemuste usaldusväärsuse üle. Seetõttu võetakse pettuse võimaluse minimeerimiseks ja testimise objektiivsuse tagamiseks erimeetmeid:

• Juurdepääs õpperessurssidele toimub ainult individuaalsete paroolide või identifikaatorite abil.
• Testide kaitsmiseks väljastpoolt tuleva volitamata juurdepääsu eest kasutatakse šifreid ja kodeeringuid.
• Testprogramme käitavad administraatorid ainult parooliga.
• Täiendavate tehniliste vahendite (veebikaamerate) kasutamine.
• Vastamise tähtaeg, vastusevariantide juhusliku segamise kasutamine.
• Statistilise kaitse kasutamine testimise ajal on nende protokollide hindamine spetsiaalsete algoritmidega, mis võimaldavad tuvastada võltsimist.

Need ja teised meetodid on loodud läbiviidud testimise usaldusväärsuse ja täpsuse tagamiseks ning on juba tõestanud oma tõhusust. Kuid loomulikult on peamine garantii vastutustundlike töötajate professionaalsus ja hästi koordineeritud töö eksami ajal.

Nagu näete, on veebipõhine testimissüsteem laialt levinud ja seda on juba pikka aega rakendanud paljud ettevõtted, mitte ainult seetõttu, et see on äärmiselt tulus ja ökonoomne lahendus, vaid ka seetõttu, et see võimaldab teil kiiresti korraldada teadmiste testimist, saades võimalikult objektiivse tulemuse. .

Usun, et kvaliteetse sisu abil saab konkurente edestada, võita lugeja usalduse ja muuta temast tänulik klient.