netyčiniai kūrėjų nukrypimai nuo darbo standartų ar įgyvendinimo planų;
funkcinių ir sąsajų reikalavimų specifikacijos sudaromos nesilaikant kūrimo standartų, dėl ko sutrikdomas programų veikimas;
kūrimo proceso organizavimas – netobulas arba nepakankamas projekto vadovo resursų (žmogiškųjų, techninių, programinių ir kt.) valdymas bei projekto elementų testavimo ir integravimo klausimai.

Pažvelkime į testavimo procesą, pagrįstą ISO/IEC 12207 standarto rekomendacijomis, ir nurodykime klaidų tipus, kurie aptinkami kiekviename gyvavimo ciklo procese.

Reikalavimų rengimo procesas. Nustatydami pradinę sistemos koncepciją ir pradinius sistemos reikalavimus, analitikai daro klaidas nurodydami aukščiausią sistemos lygį ir kurdami konceptualų dalykinės srities modelį.

Tipiškos šio proceso klaidos yra šios:

reikalavimų specifikacijos galutiniams vartotojams neadekvatumas - neteisinga programinės įrangos sąveikos su operacine aplinka arba su vartotojais specifikacija;
individualių ir bendrųjų programinės įrangos savybių klientų reikalavimų nesilaikymas;
neteisingas funkcinių charakteristikų aprašymas;
įrankių trūkumas visais klientų reikalavimų įgyvendinimo aspektais ir kt.

Projektavimo procesas.Klaidos projektuojant komponentus gali atsirasti aprašant algoritmus, valdymo logiką, duomenų struktūras, sąsajas, duomenų srautų modeliavimo logiką, įvesties/išvesties formatus ir kt. Šios klaidos yra pagrįstos analitiko specifikacijų defektais ir projektavimo trūkumais. Tai apima klaidas, susijusias su:

su vartotojo sąsajos su aplinka apibrėžimu;
su funkcijų aprašymu (dedamųjų tikslų ir uždavinių netinkamumas, kuris aptinkamas tikrinant komponentų rinkinį);
su informacijos apdorojimo proceso ir procesų sąveikos apibrėžimu (neteisingo komponentų ir procesų ryšių nustatymo rezultatas);
neteisingai nurodant duomenis ir jų struktūras aprašant atskirus komponentus ir visą programinę įrangą;
su neteisingu modulio algoritmų aprašymu;
nustatant įvykio sąlygas galimos klaidos programoje;
pažeidžiant projektui priimtus standartus ir technologijas.

Kodavimo etapas.Šiame etape atsiranda klaidų, kurios atsiranda dėl projektavimo defektų, programuotojų ir vadovų klaidų kuriant ir derinant sistemą. Klaidų priežastys yra šios:

įvesties parametrų, masyvo indeksų, kilpos parametrų, išvesties rezultatų, padalijimo iš 0 ir tt verčių nekontroliavimas;
neteisingas netaisyklingų situacijų valdymas analizuojant grąžinimo kodus iš iškviestų paprogramių, funkcijų ir pan.;
kodavimo standartų pažeidimas (blogi komentarai, neracionalūs modulių paskirstymas ir komponentas ir kt.);
vieno pavadinimo naudojimas skirtingiems objektams žymėti arba skirtingi vieno objekto pavadinimai, prasta vardų mnemonika; - skirtingų kūrėjų nenuoseklūs programos pakeitimai ir kt.

Testavimo procesas.Šiame procese klaidų daro programuotojai ir testuotojai, vykdydami surinkimo ir testavimo technologijas, parenkant testų rinkinius ir testavimo scenarijus ir pan. Programinės įrangos gedimai, atsiradę dėl tokio pobūdžio klaidų, turi būti identifikuoti, pašalinti ir neturėti įtakos komponentų klaidų statistikai. ir programinė įranga apskritai.

Priežiūros procesas.Techninės priežiūros proceso metu nustatomos klaidos, atsirandančios dėl eksploatacinės dokumentacijos trūkumų ir defektų, nepakankamų modifikavimo ir skaitomumo rodiklių, taip pat už programinės įrangos priežiūrą ir/ar tobulinimą atsakingų asmenų nekompetentingumo. Atsižvelgiant į daromų pakeitimų pobūdį, šiame etape gali atsirasti beveik bet kokių klaidų, panašių į anksčiau išvardytas klaidas ankstesniuose etapuose.

Visos programose pasitaikančios klaidos paprastai skirstomos į šias klases [7.12]:

loginės ir funkcinės klaidos;
skaičiavimo ir vykdymo klaidos;
įvesties/išvesties ir duomenų manipuliavimo klaidos;
sąsajos klaidos;
duomenų kiekio klaidos ir kt.

Loginės klaidos yra algoritmo logikos pažeidimo, vidinio kintamųjų ir operatorių nenuoseklumo, taip pat programavimo taisyklių priežastis. Funkcinės klaidos yra neteisingai apibrėžtų funkcijų, jų taikymo eiliškumo pažeidimo ar jų įgyvendinimo neišsamumo ir kt.

Skaičiavimo klaidos atsiranda dėl šaltinių duomenų ir įdiegtų formulių netikslumo, metodų klaidų, neteisingo skaičiavimo operacijų ar operandų taikymo. Vykdymo laiko klaidos yra susijusios su nepakankamu užklausų apdorojimo greičiu arba programos atkūrimo laiku.

I/O klaidos o duomenų manipuliavimas yra nekokybiško duomenų paruošimo programai vykdyti, gedimų įvedant juos į duomenų bazes ar iš jų išimant padarinys.

Sąsajos klaidos nurodo atskirų elementų santykio vienas su kitu klaidas, kurios pasireiškia perduodant duomenis tarp jų, taip pat sąveikaujant su operacine aplinka.

Garsumo klaidos yra susiję su duomenimis ir yra pasekmė to, kad įdiegti prieigos būdai ir duomenų bazių dydžiai netenkina realių sistemos informacijos apimčių ar jų apdorojimo intensyvumo.

Pateiktos pagrindinės klaidų klasės būdingos įvairių tipų programinės įrangos komponentams ir programose jos pasireiškia įvairiai. Taigi dirbant su duomenų baze atsiranda duomenų pateikimo ir manipuliavimo klaidų, loginių klaidų nurodant taikomas duomenų apdorojimo procedūras ir pan.. Skaičiavimo programose vyrauja skaičiavimo klaidos, o valdymo ir apdorojimo programose – loginės ir funkcinės klaidos. Programinėje įrangoje, kurią sudaro daugybė įvairių įgyvendinamų programų skirtingos funkcijos, gali būti klaidų skirtingi tipai. Sąsajos klaidos ir garsumo pažeidimai būdingi bet kokio tipo sistemoms.

Programų klaidų tipų analizė yra būtina sąlyga bandymo planų ir bandymo metodų kūrimas, siekiant užtikrinti programinės įrangos teisingumą.

Šiuo metu programinės įrangos kūrimo pagalbinių priemonių (CASE technologijos, objektiniai metodai ir įrankiai modeliams ir programoms kurti) kūrimo stadijoje vykdomas toks projektavimas, kuriame programinė įranga yra apsaugota nuo didžiausio tipines klaidas ir taip apsaugo nuo programinės įrangos defektų atsiradimo.

Klaidos ir nesėkmės ryšys.Klaidos buvimas programoje, kaip taisyklė, sukelia programinės įrangos gedimą jos veikimo metu. Norint išanalizuoti „klaidos-gedimo“ priežasties ir pasekmės ryšius, atliekami šie veiksmai:

projektavimo ir programavimo technologijų trūkumų nustatymas;
santykį tarp projektavimo proceso trūkumų ir žmogiškųjų klaidų;
gedimų, ydų ir galimų klaidų, taip pat defektų klasifikavimas kiekviename kūrimo etape - žmogiškųjų klaidų, padarytų tam tikrame kūrimo procese, ir objekto defektų palyginimas, kaip projekto specifikacijos, programos modelių klaidų pasekmė;
tikrinimas ir apsauga nuo klaidų visuose gyvavimo ciklo etapuose, taip pat defektų nustatymas kiekviename kūrimo etape;
programinės įrangos defektų ir gedimų palyginimas, siekiant sukurti sąsajų sistemą ir informacijos apie gedimus ir defektus lokalizavimo, rinkimo ir analizės metodus;
požiūrių į programinės įrangos dokumentavimo ir testavimo procesus kūrimas.

Galutinis klaidų ir nesėkmių priežastinio ryšio tikslas yra apibrėžti tam tikrų klasių klaidų tikrinimo ir aptikimo metodus ir priemones, taip pat daugelio duomenų rinkinių testavimo užbaigimo kriterijus; nustatant būdus, kaip pagerinti programinės įrangos kūrimo, testavimo ir priežiūros proceso organizavimą.

Štai tokia gedimų tipų klasifikacija:

aparatinė įranga, kurioje neveikia visos sistemos programinė įranga;
informacinis, atsiradęs dėl įvesties duomenų ir duomenų perdavimo ryšio kanalais klaidų, taip pat įvesties įrenginių gedimo (aparatinės įrangos gedimų pasekmė);
ergonomiškas, atsirandantis dėl operatoriaus klaidų jam sąveikaujant su mašina (šis gedimas yra antrinis gedimas ir gali sukelti informacijos ar funkcinių sutrikimų);
programinė įranga, jei yra komponentų klaidų ir pan.

Kai kurios klaidos gali atsirasti dėl reikalavimų apibrėžimo, projektavimo, išvesties kodo generavimo ar dokumentacijos trūkumų. Kita vertus, jie generuojami kuriant programą arba kuriant atskirų programos elementų sąsajas (parametrų eiliškumo pažeidimas, mažiau ar daugiau parametrų ir pan.).

Klaidų šaltiniai.Klaidos gali atsirasti kuriant projektą, komponentus, kodą ir dokumentaciją. Paprastai jie aptinkami vykdant ar prižiūrint programinę įrangą netikėčiausiuose ir skirtinguose taškuose.

Kai kurios programos klaidos gali atsirasti dėl reikalavimų apibrėžimo, projektavimo, kodo generavimo ar dokumentacijos trūkumų. Kita vertus, klaidos susidaro kuriant programą ar jos elementų sąsajas (pavyzdžiui, kai pažeidžiama ryšio parametrų nustatymo tvarka – mažiau ar daugiau nei reikalaujama ir pan.).

Klaidų priežastis – klientų reikalavimų nesuvokimas; netikslūs reikalavimų nurodymai projektiniuose dokumentuose ir pan. Tai lemia tai, kad yra įdiegtos kai kurios sistemos funkcijos, kurios neveiks taip, kaip siūlo užsakovas. Šiuo atžvilgiu vyksta bendras užsakovo ir rengėjo aptarimas dėl kai kurių reikalavimų detalių, siekiant juos išsiaiškinti.

Sistemos kūrimo komanda taip pat gali pakeisti sistemos aprašymo sintaksę ir semantiką. Tačiau kai kurios klaidos gali būti neaptiktos (pavyzdžiui, šių teiginių indeksai arba kintamieji yra neteisingai nustatyti).

Funkcinis testavimas yra viena iš pagrindinių testavimo rūšių, kurios užduotis – nustatyti sukurtos programinės įrangos atitiktį pirminiams užsakovo funkciniams reikalavimams. Tai yra, funkcinis testavimas leidžia patikrinti gebėjimą informacinė sistema tam tikromis sąlygomis išspręskite vartotojams reikalingas problemas.

Priklausomai nuo prieigos laipsnio sistemos kodas Galima išskirti du funkcinių testų tipus:

testavimas juoda dėžė(juodoji dėžė) – atlieka funkcinius testus be prieigos prie sistemos kodo,
white box testing – funkcinis testavimas su prieiga prie sistemos kodo.

Juodosios dėžės testavimas atliekamas nežinant vidinių sistemos mechanizmų ir priklauso nuo išorinių jos veikimo apraiškų. Šis testavimas tikrina programinės įrangos elgseną esant įvairiems įvesties duomenims ir vidinę sistemų būseną. Baltosios dėžės testavimo atveju bandomieji atvejai sukuriami pirmiausia remiantis programinės įrangos sistemos kodu. Taip pat yra išplėstinis juodosios dėžės testavimo tipas, apimantis kodo tyrimą - vadinamoji pilkoji dėžutė.

Pagrindiniai privalumai

Funkcinės programinės įrangos testavimas visiškai imituoja tikrąjį sistemos naudojimą.
Leidžia greitai nustatyti sistemos programinės įrangos klaidas ir taip išvengti daugelio problemų dirbant su ja ateityje.
Sutaupoma ištaisius klaidas anksčiau programinės įrangos gyvavimo ciklo metu.

Pagrindiniai funkcinio testavimo etapai

Paruošimas

Vykdant

Paruošimas

Atliekama pirminių dokumentų apie sistemą analizė: funkciniai ir verslo reikalavimai, techninės specifikacijos, projekto pasas. Taip pat rengiamas ir tvirtinamas bandymų planas, bandomieji atvejai, susitarimas dėl projekto terminų, iteracijų skaičiaus ir galimos rizikos įvertinimas. Užduotys šiame etape atliekamos kartu su užsakovo atstovais.

Vykdant

Funkcinis testavimas atliekamas rankiniu būdu, naudojant iš anksto parengtus testavimo scenarijus, visos rastos klaidos įvedamos į klaidų sekimo sistemą. Jeigu klientas tokios sistemos neturi, galime: pateikti testų valdymo sistemą mūsų svetainėje; pateikti licencijas klientui; panaudoti kliento turimas lėšas; daryti tik biuro komplektas; pristatyti klientui testavimo procesą nemokamais įrankiais.

Parengiamos ir suderinamos testavimo ataskaitos su aptiktų nukrypimų sąrašu ir rekomendacijomis sistemai tobulinti. Esant poreikiui organizuojami naudotojų mokymai.

Įrankiai

Testų valdymas atliekamas specializuotose sistemose.

Funkcinis testavimas- tai programinės įrangos testavimas, siekiant patikrinti funkcinių reikalavimų įgyvendinamumą, ty programinės įrangos gebėjimą tam tikromis sąlygomis išspręsti vartotojams reikalingas problemas. Funkciniai reikalavimai nustato, ką tiksliai programinė įranga daro ir kokias užduotis sprendžia.

Funkciniai reikalavimai apima:

Funkcinis fitnesas tinkamumas).

Tikslumas tikslumu).

Gebėjimas bendrauti sąveika).

Standartų ir taisyklių laikymasis laikymasis).

Sauga (anglų k.) saugumo).

Saugumo testavimas

[redaguoti | redaguoti šaltinio tekstą]

Medžiaga iš Vikipedijos – laisvosios enciklopedijos

Saugumo testavimas- programinės įrangos pažeidžiamumo įvairioms atakoms įvertinimas.

Kompiuterinės sistemos labai dažnai yra nelegalaus įsibrovimo taikinys. Infiltracija reiškia daugybę veiksmų: įsilaužėlių bandymus įsiskverbti į sporto sistemą, nepatenkintų darbuotojų kerštą, sukčių įsilaužimą siekiant neteisėtos naudos. Saugumo testavimas patikrina, kaip sistemoje įmontuoti apsaugos mechanizmai iš tikrųjų reaguoja į įsibrovimą. Saugumo testavimo metu testuotojas atlieka užpuoliko vaidmenį. Jam leidžiama viskas:

bando sužinoti slaptažodį išorinėmis priemonėmis;

atakuoti sistemą naudojant specialios komunalinės paslaugos, analizuojant apsaugas;

slopinimas, sistemos užvaldymas (tikintis, kad ji atsisakys aptarnauti kitus klientus);

tikslingas klaidų įvedimas, tikintis prasiskverbti į sistemą atkūrimo metu;

nuskaito neįslaptintus duomenis, tikėdamasis rasti prisijungimo raktą.

Turint neribotą laiką ir išteklius, geras saugumo patikrinimas sugadins bet kurią sistemą. Sistemos kūrėjo tikslas – kad įsiskverbimo kaina būtų didesnė už gautos informacijos kainą.

Programinės įrangos apkrovos testavimas[redaguoti | redaguoti šaltinio tekstą]

Terminas Testavimas nepalankiausiomis sąlygomis gali būti naudojamas įvairiomis reikšmėmis profesionalioje programinės įrangos testavimo aplinkoje. Apskritai kalbama apie numatomo programos naudojimo modeliavimą imituojant kelis vartotojus vienu metu. Taigi toks testavimas labiausiai tinka kelių vartotojų sistemoms, dažniausiai naudojant kliento-serverio architektūrą (pavyzdžiui, interneto serverius). Tačiau panašiai galima išbandyti ir kitų tipų programinės įrangos sistemas. Pavyzdžiui, tekstas arba grafikos redaktorius galite priversti perskaityti labai didelį dokumentą; ir finansinis paketas – generuokite ataskaitą pagal kelių metų duomenis. Tinkamiausiai suplanuotas apkrovos bandymas duos tikslesnius rezultatus.

Pagrindinis apkrovos testavimo tikslas – sukurti tam tikrą sistemos apkrovą, kurios tikimasi (pavyzdžiui, per virtualius vartotojus) ir, dažniausiai, naudojant identišką programinę ir techninę įrangą, stebėti sistemos veikimą.

1 pavyzdys:

Žiniatinklio paslauga su krepšelio funkcijomis skirta 100 vartotojų, kurie laikosi tam tikro scenarijaus (nurodytų veiksmų nurodytomis proporcijomis):

25 vartotojai peržiūri prekę ir atsijungia.

25 vartotojai įdeda prekę į krepšelį, išsiregistruoja ir atsijungia nuo sistemos.

25 vartotojai naudojasi prekių grąžinimo funkcija ir atsijungia.

25 vartotojai prisijungia ir nerodo jokios veiklos.

Tokiu atveju apkrovos testavimas turėtų imituoti tipinį darbo su žiniatinklio paslauga scenarijų, aprašytą aukščiau, kad įsitikintumėte, jog sistema yra paruošta pradėti gaminti. Tokiu atveju analizei galima paimti visos sistemos arba kiekvieno sistemos mazgo našumo rodiklius.

Idealiu atveju apkrovos testavimo sėkmės kriterijai yra sistemos veikimo reikalavimai, kurie suformuluojami ir dokumentuojami sistemos funkcinių reikalavimų kūrimo etape prieš programuojant pagrindinius architektūrinius sprendimus. Tačiau dažnai nutinka taip, kad tokie reikalavimai nebuvo aiškiai suformuluoti arba nebuvo suformuluoti iš viso. Tokiu atveju bus atliktas pirmasis apkrovos bandymas teismo procesas(Anglų) tiriamasis apkrovos bandymas) ir turi būti pagrįsti pagrįstomis prielaidomis apie numatomą aparatinės įrangos apkrovą ir išteklių suvartojimą.

Vienas iš optimaliausių būdų, kaip naudoti apkrovos testavimą sistemos našumui įvertinti, yra testavimas ankstyvame kūrimo etape. Apkrovos bandymas pirmuosiuose architektūrinio sprendimo parengties etapuose, siekiant nustatyti jo gyvybingumą, vadinamas „koncepcijos įrodymo“ testavimu.

Pagrindiniai apkrovos testavimo principai[taisyti | redaguoti šaltinio tekstą]

Toliau pateikiami kai kurie eksperimentiniai faktai, apibendrinti pagal principus, taikomus atliekant veikimo testavimą apskritai ir taikomus bet kokio tipo našumo bandymams (ypač apkrovos bandymams).

1. Prašymų unikalumas

Net ir sukūrę realų darbo su sistema scenarijų, pagrįstą jos naudojimo statistika, turite suprasti, kad šiam scenarijui visada bus išimčių.

Skirtingų X ir Y užklausų vykdymo laiko sklaidos paskirstymo iliustracija.

Kada 1 pavyzdys tai gali būti vartotojas, pasiekiantis unikalius žiniatinklio paslaugos puslapius, kurie skiriasi nuo visų kitų.

2. Sistemos reakcijos laikas

Apskritai sistemos atsako laikas priklauso nuo normalaus pasiskirstymo funkcijos.

Visų pirma, tai reiškia, kad atliekant pakankamą matavimų skaičių, galima nustatyti tikimybę, su kokia sistemos atsakas į užklausą pateks per tam tikrą laiko intervalą.

3. Sistemos atsako laiko priklausomybė nuo šios sistemos pasiskirstymo laipsnio.

Sklaida Normalus sistemos atsako į užklausą laiko pasiskirstymas yra proporcingas lygiagrečiai tokias užklausas apdorojančių sistemos mazgų ir užklausų vienam mazgui skaičiaus santykiui.

Tai reiškia, kad sistemos atsako laiko sklaidą vienu metu įtakoja užklausų skaičius viename sistemos mazge ir pačių mazgų skaičius, kurių kiekvienas prideda tam tikrą atsitiktinį delsą apdorojant užklausas.

4. Sistemos reakcijos laiko kitimas

Iš 1, 2 ir 3 teiginių taip pat galime daryti išvadą, kad atlikus pakankamai daug užklausų apdorojimo laiko matavimų, bet kurioje sistemoje visada atsiras užklausų, kurių apdorojimo laikas viršija reikalavimuose apibrėžtus maksimumus; Be to, kuo ilgesnis bendras eksperimento laikas, tuo aukštesni bus nauji maksimumai.

Į šį faktą reikia atsižvelgti formuojant sistemos veikimo reikalavimus, taip pat atliekant reguliarius apkrovos bandymus.

5. Apkrovos profilio atkūrimo tikslumas

Reikiamas apkrovos profilių atkūrimo tikslumas tampa brangesnis, kuo daugiau sistemoje yra komponentų.

Sudėtingose sistemose dažnai neįmanoma atsižvelgti į visus apkrovos profilio aspektus, nes kuo sudėtingesnė sistema, tuo daugiau laiko reikės suprojektuoti, programuoti ir palaikyti tinkamą apkrovos profilį, o tai ne visada būtina. Optimalus požiūris šiuo atveju yra balansas tarp testavimo kūrimo sąnaudų ir sistemos funkcionalumo aprėpties, todėl daromos prielaidos apie poveikį bendram tam tikros testuojamos sistemos dalies veikimui.

Integracijos testavimas(Anglų) Integracijos testavimas, kartais vadinamas angliškais. Integracija ir testavimas, anglų kalbos santrumpa. I&T) yra vienas iš programinės įrangos testavimo etapų, kai atskiri programinės įrangos moduliai sujungiami ir testuojami kaip grupė. Paprastai integracijos testavimas atliekamas po vieneto testavimo ir prieš sistemos testavimą.

Integravimo testavimas kaip įvestį priima vienetus, kurie buvo išbandyti vienetais, sugrupuoja juos į didesnius rinkinius, atlieka tų rinkinių testavimo plane nurodytus testus ir pateikia juos kaip išvestį ir įvestį tolesniam sistemos testavimui.

Integravimo testavimo tikslas – patikrinti projektuojamų mazgų atitiktį funkciniams, priėmimo ir patikimumo reikalavimams. Šių projektavimo vienetų – modulių sąjungos, rinkinio ar grupės – testavimas atliekamas per jų sąsają, naudojant juodosios dėžės testavimą.

Visi programinės įrangos testavimo tipai, atsižvelgiant į siekiamus tikslus, galima suskirstyti į tokias grupes: 1) funkcinius; 2) nefunkcionalus; 3) susiję su pokyčiais.

Funkciniai testai yra pagrįsti funkcijomis ir funkcijomis, taip pat sąveika su kitomis sistemomis ir gali būti pateikiami visais testavimo lygiais: komponentų / vienetų testavimas, integravimo testavimas, sistemos testavimas ir priėmimo testavimas ). Funkciniai testavimo tipai tiria išorinį sistemos elgesį. Toliau pateikiami dažniausiai pasitaikantys funkcinių testų tipai:

- Funkcinis testavimas(Funkcinis testavimas)

- Saugumo testavimas(Saugumo ir prieigos kontrolės testavimas)

- Sąveikos testavimas(Sąveikos bandymas)

Funkcinis testavimas.Šio tipo testavimas patikrina, ar įdiegtos funkcijos atitinka reikalavimus, Techninės specifikacijos, specifikacijos, įvairūs kiti projektavimo dokumentai ir tiesiog vartotojo lūkesčiai. Kiekviena programos funkcija yra išbandyta ir visos jos derinamos. Visi naudojimo atvejai yra ištirti. Tikrinamas saugomų ir išvestų duomenų tinkamumas, jų apdorojimo būdai, įvesties duomenų apdorojimas, duomenų saugojimo būdai, duomenų importo ir eksportavimo būdai ir kt. priklausomai nuo taikymo specifikos.

Funkciniai testai yra pagrįsti sistemos atliekamomis funkcijomis ir gali būti atliekami visais testavimo lygiais (komponentas, integracija, sistema, priėmimas). Paprastai šios funkcijos aprašomos reikalavimuose, funkcinėse specifikacijose arba kaip naudojimo atvejai.

Funkcionalumo testavimas gali būti atliekamas dviem aspektais: “ reikalavimus»; « verslo procesas».

Išbandymas perspektyvoje“ reikalavimus» naudoja sistemos funkcinių reikalavimų specifikaciją kaip bandymo atvejų projektavimo pagrindą. Tokiu atveju reikia sudaryti sąrašą, kas bus tikrinama, o kas ne, pagal rizikas suskirstyti reikalavimams prioritetus (jeigu tai nepadaryta reikalavimų dokumente) ir pagal tai nustatyti testavimo atvejų prioritetus. Tai leis jums susikaupti ir nepraleisti svarbiausių funkcijų testuojant.

Išbandymas perspektyvoje“ verslo procesas"naudoja žinias apie šiuos verslo procesus, apibūdinančius kasdienio sistemos naudojimo scenarijus. Šiuo požiūriu bandomieji scenarijai paprastai yra pagrįsti sistemos naudojimo atvejais.

Privalumai funkcinis testavimas: imituoja faktinį sistemos naudojimą. Trūkumai funkcinis testavimas: programinės įrangos loginių klaidų galimybė; pervertinimo galimybė.

Tai gana įprasta funkcinio testavimo automatika.

Saugumo testavimas. Testavimo strategija, naudojama sistemos saugumui patikrinti, taip pat rizikai, susijusiai su visapusišku programos apsaugos, įsilaužėlių, virusų atakomis ir neteisėta prieiga prie konfidencialių duomenų, analizei. Saugumo testavimas gali būti atliekamas automatiškai arba rankiniu būdu, įskaitant teigiamų ir neigiamų bandymų atvejų peržiūrą. Remiantis trimis pagrindiniais principus- Tai konfidencialumą, vientisumą ir prieinamumą(konfidencialumas, vientisumas, prieinamumas)

Konfidencialumas yra tam tikrų išteklių ar informacijos slėpimas. Konfidencialumas gali būti suprantamas kaip prieigos prie ištekliaus apribojimas tam tikrai vartotojų kategorijai arba, kitaip tariant, kokiomis sąlygomis vartotojas turi teisę pasiekti tam tikrą išteklį.

Apibrėžiant sąvoką yra du pagrindiniai kriterijai vientisumas:

1. Pasitikėk. Tikimasi, kad išteklius tinkamu būdu pakeis konkreti vartotojų grupė.

2. Žala ir atstatymas. Tuo atveju, kai duomenis sugadino ar neteisingai pakeičia įgaliotas ar neteisėtas vartotojas, būtina nustatyti, kiek svarbi yra duomenų atkūrimo procedūra.

Prieinamumas reiškia reikalavimus, kad ištekliai turi būti prieinami įgaliotam vartotojui, vidiniam objektui ar įrenginiui. Paprastai kuo kritiškesnis išteklius, tuo aukštesnis turi būti pasiekiamumo lygis.

Sąveikos testavimas. Su vystymusi tinklo technologijos ir interneto sąveika skirtingos sistemos, paslaugos ir programos įgavo didelę reikšmę, nes dėl bet kokių su tuo susijusių problemų gali sumažėti įmonės autoritetas, o tai lems finansinių nuostolių. Todėl sąveikos bandymai turėtų būti vertinami labai rimtai.

Sąveikos testavimas – Tai yra funkcinis testavimas, kurio metu tikrinamas programos gebėjimas sąveikauti su vienu ar daugiau komponentų ar sistemų, įskaitant suderinamumo ir integravimo testavimą.

Programinė įranga su geros savybės sąveiką galima lengvai integruoti su kitomis sistemomis, nereikalaujant jokių didelių pakeitimų. Šiuo atveju pakeitimų skaičius ir laikas, reikalingas jiems atlikti, gali būti naudojamas sąveikai įvertinti.

Atsižvelgiant į šiandienos galimybes, kiekvienas Petya ir Vasya gali kurti svetaines. Tačiau kaip šiame greitai besikeičiančiame technologijų pasaulyje išlikti išskirtiniu ir sužavėti vartotojus?

Vaikinai, raktas į jūsų kliento širdį yra ne kas kita, kaip „kokybė“. Kad ir kokią sudėtingą svetainę kurtumėte, kokybė yra vienintelis veiksnys, skatinantis bet kokį verslą ir vedantis į pagrindinį tikslą – pritraukti klientus.

Jūsų svetainė yra tam tikras internetinis langas, pristatantis jūsų verslą žmonėms realiame pasaulyje. Kiekvienas jūsų svetainės objektas, pradedant nuo svetainės spalvos, dizaino, funkcionalumo, įskaitant naršymo paprastumą, ir net turinio įkėlimo laikas, iš tikrųjų yra svarbus.

Kaip galite užtikrinti, kad visi šie komponentai būtų sutvarkyti nepriekaištingai ir itin tiksliai? Teisinga funkcionalumo analizė ir testavimas yra neatsiejama projekto kūrimo ciklo dalis, kur į scenarijų įtraukiamas ir kokybės užtikrinimas.

Žiniatinklio kūrėjų kontrolinis sąrašas

1. Dizaino meistriškumas

Čia jūs turite pažvelgti į dalykus iš savo kliento perspektyvos ir kaip jie nori, kad jų verslas atrodytų potencialiems klientams. Svetainė yra platforma, kuri tikslinei auditorijai pateikia veidrodinį jų produkto vaizdą.

Suteikite savo dizainui unikalumo ir užtikrinkite, kad neviršytumėte kliento dizaino koncepcijų ir specifikacijų, kad pasiektumėte laukiamų rezultatų.

2. Turinio valdymas pagal aukštus standartus

Senas geras posakis „Turinys yra karalius“ nesikeičia: jis visada valdys internetinės rinkodaros pasaulyje. Sutvarkytas turinys, kuris taip pat yra šviežias, interaktyvus, skaitomas ir suprantamas, atvers duris į jūsų kliento širdį.

Tyrimai ir apklausos rodo, kad vartotojai linkę išbūti svetainėje vos kelias sekundes, iš kurių net mažiau laiko praleidžia skaitydami turinį. Štai kodėl būtina atkreipti ypatingą dėmesį į šį punktą. Tik geras svetainės turinys privers lankytoją likti svetainėje.

Aptarkime kai kuriuos dalykus, kurie padės sukurti svetainę su nuline klaidų tikimybe.

3. Kūrybingas su sveiku protu

Jūsų svetainės išvaizda yra tarsi lakmuso popierėlis, kuris nustato, ar jūsų svetainė gali patikti jūsų auditorijai. Todėl būtina, kad ji būtų patraukli ir tuo pat metu nekrenta į akis.

Atminkite, kad pirmas įspūdis visada yra geriausias!

Štai kodėl turėtumėte laikytis šių taisyklių, susijusių su svetainės turiniu:

Protingas erdvės panaudojimas
Pakanka baltos vietos jūsų turiniui, kad jis kvėpuotų
Nėra netinkamų vaizdų
Geras skaitomumas
Venkite kontrastingų spalvų ir netinkamų šriftų dydžių
Venkite neveikiančių nuorodų
Privalomas kelių naršyklių suderinamumas
Nepamirškite svetainėje pakeisti savo el. pašto ID
Metai Autorių teisės turi nurodyti svetainės paleidimo metus

4. Turinys yra svetainės karalius

Kaip aptarta, svetainė yra platforma, pristatanti verslą pasaulinei auditorijai. Atminkite, kad svetainėje apsilankys ne tik vietiniai žmonės, bet ir daugybė žmonių iš įvairių pasaulio šalių. Būkite pasirengę susidurti su jais ir patenkinti jų poreikius.

Pasirinkto turinio tipas ir jo pateikimo būdas iš tikrųjų vaidina svarbų vaidmenį, kai turite didelę auditoriją, ypač dėl to, kad kasdien vis labiau stengiamasi patenkinti vartotojų skonį.

Kai leidžiate laiką ir pinigus kurdami išskirtinį savo svetainės turinį, turite patikrinti jo kokybę, kad įsitikintumėte, jog jis atitinka jūsų auditorijos interesus neprarandant kokybės ir unikalumo.

Štai keletas bendrųjų turinio atrankos taisyklių, kurių reikia laikytis norint gauti geresnių rezultatų:

Štai keletas įprastų praktikų, kurių reikia kuo greičiau atsikratyti, kad pasiektumėte geresnių rezultatų:

Venkite rašybos ir gramatinių klaidų
Pateikite tarpus tarp žodžių
Privalomi tarpai po skyrybos ženklų
Pradėkite sakinį didžiąja raide
Patikrinkite, ar nėra neatitikimų
Venkite netvarkingo turinio išdėstymo

5. Funkcionalumas

Įsivaizduokite, kad neseniai gavote gražų dvarą, bet negalite užrakinti durų. Išleidote visus sunkiai uždirbtus pinigus dvaro, kuris būtų atviras visiems, statybai. Kokia iš to nauda? Tas pats pasakytina ir apie jūsų svetainę. Jūs tikrai daug dirbote kurdami svetainę, kuri yra be galo graži, bet ji neveikia pagal... Techniniai reikalavimai klientas.

Kaip tikitės, kad jūsų klientas atkreips klientų ar potencialių klientų dėmesį, naudodamas tokią svetainę? Viskas veltui! Dabar nustok jaudintis!

Štai keletas patarimų, kurie padės jums su jo funkcionalumu:

Užtikrinkite tinkamą navigaciją
Venkite klaidų siųsdami pranešimus pagal prenumeratą, Kontaktinė informacija ir tt
Pateikite komentarus svetainės prisijungimo ir registracijos skyriuose
Patikrinkite, ar visos nuorodos veikia
Dukart patikrinkite el. prekybos funkcijas

6. Elektroninės prekybos funkcionalumas

Elektroninės prekybos svetainės yra ne kas kita, kaip internetinės parduotuvės, kuriose žmonės perka vienu spustelėjimu arba bakstelėdami išmanųjį telefoną. Turite nuolat sekti tendencijas ir kurti novatoriškas idėjas, kurios pamaitins jų dvasią.

Parodymo sukūrimas yra tiesiogiai proporcingas interneto vartotojų skaičiui jūsų svetainėje. Štai kodėl būtina suprasti, ko klientai ieško tokiose svetainėse:

Trumpas pakrovimo laikas
Galimybė ištrinti, pridėti, užsisakyti ir pan.
Įėjimo ir išėjimo galimybė
Teisingi sandorio skaičiavimai

Atminkite, kad jūs nesate vieni, siekdami tobulos el. prekybos svetainės, o visi kiti yra taip pat susikaupę kaip jūs. Net ilgėjantis įkėlimo laikas gali išjungti jūsų klientus.

Yra tam tikri programavimo standartai, kurių turėtumėte pradėti laikytis šiandien, kad sumažintumėte įkėlimo laiką iki nulio arba iki minimumo.

Kai kurie iš jų paminėti žemiau:

Neveikiančių nuorodų pašalinimas
Susikoncentruokite į turinį
Vaizdo optimizavimas
Didelių failų optimizavimas
Naudojant Pure CSS
PHP kodų optimizavimas

7. El

Galima daug ką nuveikti su El. paštas. Tai gali būti nuo tiesiog vertingos informacijos pateikimo iki didžiulių verslo sandorių. Taigi įsitikinkite, kad jūsų laiškų siuntimas niekada nepavyks. Taip pat nepamirškite patvirtinti savo el. pašto adreso.

8. Raginimas veikti (CTA)

Raginimas veikti – tai ryšys tarp jūsų potencialių klientų dominančio organinio turinio ir didesnės vertės programos puslapio (nukreipimo puslapio), kuris savo ruožtu yra pakankamai aktualus ir įdomus, kad įtikintų jūsų lankytojus užpildyti trumpą formą.

CTA yra viena iš labiausiai pasiteisinusių strategijų norint atkreipti vartotojo dėmesį, todėl mes tai rekomenduojame. Visų pirma įsitikinkite, kad jis veikia. Jūsų raginimas veikti tikrai turėtų pasiekti tikslą, jis turėtų būti aiškus ir tikslus.

Jei jis gali turėti kontrastingą spalvą nuo spalvų schema tinklalapį, o tuo pačiu įsilieti į bendrą dizainą, jis bus efektyvesnis.

Tobulumas – tai daug mažų dalykų, padarytų teisingai!

Dabar, kai baigėme su pagrindiniais svetainės kūrimo elementais, panagrinėkime kitus svarbius veiksnius, į kuriuos reikia nedelsiant atkreipti dėmesį.

Standartinių patvirtinimo pranešimų teikimas
Stiliaus ir spalvų derinių patvirtinimo teikimas paštu panašiai kaip svetainėje
Privalomas įmonės logotipas
Įmonės pavadinimas adresu
Suderinamumas tarp naršyklių
404 klaidos puslapio nustatymas
Pasirinkite visas nuorodas ir mygtukus

Paskutinis, bet ne mažiau svarbus dalykas – kas padarys jūsų svetainę patogią vartotojui!

Kontrolinis sąrašas klientams

Kas yra šis asmuo, kuriam kuriate svetainę? Tai asmuo, kuris ketina kurti verslą ir parduoti per svetainę, ir akivaizdu, kad tai nėra galutinis vartotojas, bet jis vis tiek yra klientas, kuriam jūs dirbate.

Jei nežinote, ko jis nori, kaip ketinate suteikti jam svetainę, skirtą jo galutiniams vartotojams?

Logotipo kontrolinis sąrašas

Svetainės logotipas yra toks pat svarbus kaip ir kitų svetainės komponentų kūrimas. Taigi, kai jūsų klientui reikia svetainės su logotipu, čia yra keletas dalykų, kuriuos turėtumėte atlikti.

Ar logotipas susijęs su verslu?
Ar logotipas telpa pačioje svetainėje?
Ar ilgai tai išliks žiūrovų atmintyje?

Apskritai dizaino kontrolinis sąrašas

Nors jau aptarėme būtinus svetainės peržiūros elementus, bendras kontrolinis sąrašas taip pat reikalingas, kai kalbama apie kodavimo dalį:

Dokumento formatas, kurį naudojate svetainėje
Svetainėje naudojamų simbolių rinkinys
Ar jūsų svetainėje įdiegtas tinkamas HTML arba XHTML?
Ar savo svetainėje įdiegėte tinkamą CSS?
Ar įdiegėte klases ar identifikatorius, kurie nėra svarbūs jūsų svetainei?
Kokį kodą įdiegėte savo svetainėje?
Patikrinkite, ar neveikia nuorodos! Neignoruokite to, galbūt jūs to nežinote, bet jų gali būti daug!
Svetainės greitis kiekviename puslapyje?
Ar jūsų svetainėje yra „JavaScript“ klaidų?

Tai turbūt viskas! Tikimės, kad mūsų sąrašo pagalba galėsite susikurti šauniausias svetaines!