үй › Орнату және конфигурациялау › Бағдарламалық өнімді сынау. Оның ішіндегі басқа функцияларды пайдаланатын функцияның функционалдығын қалай тексеруге болады? Қатысты тестілеуді өзгерту

Бағдарламалық өнімді сынау. Оның ішіндегі басқа функцияларды пайдаланатын функцияның функционалдығын қалай тексеруге болады? Қатысты тестілеуді өзгерту

Жарты сағат ішінде апаттан кейін бағдарламаны 18 рет қайта іске қосып, содан кейін ғана мониторды тікелей терезеге лақтыра алатындай төзімділік танытсаңыз да, бұл бағдарламамен жұмыс істеу ыңғайлырақ болатынына келісесіз, егер ол «апатылмаса» ».

Сіз жасаған бағдарламаның істен шығуы, қатып қалуы немесе қажетті әрекеттерін орындамау жағдайлары өте сирек болатынына қалай көз жеткізуге болады?

Нақты жауап бұл сұрақЖоқ. Бірақ ғасырлар бойы дана ғалымдар бұл тақырыпты жылдар бойы ойластырып, егер ол барлық бағдарламалық қателерді жоймаса, кем дегенде оларды жою әрекетінің елесін тудыратын құрал таба алды.

Және бұл құрал деп аталады СЫНАҚ бағдарламалық өнім .

Дана адамдардың айтуынша, тестілеу – даму сапасын қамтамасыз етудің ең қалыптасқан тәсілдерінің бірі бағдарламалық қамтамасыз етужәне жиынтыққа кіреді тиімді құралдар заманауи жүйебағдарламалық өнімнің сапасын қамтамасыз ету.

Бағдарламалық өнімнің сапасы өнімнің тұтынушысы, демеушісі, соңғы пайдаланушысы, өнімді әзірлеушілері мен сынақшылары, қолдау инженерлері, маркетинг сияқты мүдделі тараптардың көзқарасы бойынша өнімнің қаншалықты «жақсы» екенін анықтайтын қасиеттер жиынтығымен сипатталады. , оқыту және сату персоналы. Қатысушылардың әрқайсысында өнім туралы және оның қаншалықты жақсы немесе жаман екендігі, яғни өнімнің сапасы қаншалықты жоғары екендігі туралы әртүрлі түсінік болуы мүмкін. Осылайша, өнім сапасын қамтамасыз ету мәселесін қою мүдделі тараптарды, олардың сапа критерийлерін анықтау, содан кейін осы критерийлерді қанағаттандыратын оңтайлы шешімді табу міндетін тудырады.

Қашан және кім?

Тәжірибелі әзірлеушілердің пікірінше, бағдарламалық өнімді тестілеу оны жасаудың басынан бастап жүргізілуі керек. Бірақ сонымен бірге тәжірибелі әзірлеушілердің өздері тестілеуге қатыспауы керек, өйткені бұл корольдік мәселе емес. Бағдарламалық өнімді тестерлер деп аталатын арнайы оқытылған қызметкерлер сынауы керек, өйткені тіпті ең тәжірибелі әзірлеуші тіпті соңғы оптикалық құралдарды пайдаланып, өз қатесін көре алмайды.

Дегенмен, барлық әзірлеушілер бағдарламалық өнімді мақсат бойынша жіктеу тұрғысынан тестілеуді екі сыныпқа бөлу керек деп келіседі:

Функционалды тестілеу
Функционалды емес тестілеу

Функционалды тестілеу

Функционалдық тестілеу бағдарламалық өнімнің осы өнімді жасауға арналған техникалық шарттарда көрсетілген функционалдық талаптарға сәйкестігін тексеруді білдіреді. Қарапайым тілмен айтқанда, функционалдық тестілеу бағдарламалық өнімнің барлық қажетті функцияларды орындайтынын тексереді.

Сонымен, сіз функционалдық тестілеуді өткізуді шештіңіз. Сіз техникалық сипаттаманы қарап, функционалдық талаптарды оқып, кем дегенде, олардың тестілеуді жүргізуге болатын тәртіпте емес екенін түсінесіз. Ұзақ уақыт бұрын басқалардың бұл сәйкессіздікті байқағанына және оны қалай жеңуге болатынын анықтағанына таң қаласыз.

Функционалдық тестілеуді өткізу үшін техникалық бақылау бөлімінің қызметкерлері құжаттық бағдарлама мен қосымшаның (API) функционалдығын тексеру әдістемесін әзірлеуде. PMI құжатында бағдарламалық өнімді сынау сценарийлерінің (сынақ жағдайлары) тізімі бар егжей-тегжейлі сипаттамақадамдар. Тестілеу сценарийінің әрбір қадамы пайдаланушының (тестілеуші маманның) әрекеттерімен және күтілетін нәтижелермен - бағдарламаның осы әрекеттерге жауабымен сипатталады. Сынақ бағдарламасы мен әдістемесі нақты режимде бағдарламалық өнімнің жұмысын имитациялауы керек. Бұл тестілеу сценарийі жүйенің болашақ пайдаланушылары орындайтын операцияларды талдау негізінде құрылуы керек және тек әзірлеушіге түсінікті жасанды түрде құрастырылған манипуляциялар тізбегі болмауы керек дегенді білдіреді.

Әдетте, функционалдық тестілеу екі деңгейде жүргізіледі:

Компоненттік (бірлік) тестілеу. Бағдарламалық өнімнің жеке құрамдас бөліктерін сынау, олардың ерекшеліктеріне, тағайындалуына және функционалдық ерекшеліктеріне бағытталған.
Интеграциялық тестілеу. Бұл түрітестілеу құрамдас тестілеуден кейін жүргізіледі және басқару ағындары мен деректер алмасу деңгейінде әртүрлі ішкі жүйелердің өзара әрекеттесуіндегі ақауларды анықтауға бағытталған.

Функционалды емес тестілеу

Функционалды емес тестілеу бағдарламалық өнімнің эргономика немесе өнімділік сияқты қасиеттерін бағалайды.

Менің ойымша, тестілеудің бұл түрінің маңыздылығы түсінікті және негіздеуді қажет етпейді. Өйткені, егер, мысалы, жүйе өнімділігі жеткіліксіз болса, пайдаланушылар өздерінің әрекеттеріне жауап беру үшін жарты күн күтуге тура келетінін бәрі түсінеді, бұл олардың жаппай күту күйіне әкелуі мүмкін.

Аты айтып тұрғандай, функционалды емес тестілеу бағдарламалық өнімнің функционалдық емес талаптарға сай келетінін тексереді. техникалық тапсырмаоның құрылуы үшін. Ал, функционалдық тестілеудегідей, функционалдық емес тестілеуге арналған тест бағдарламасы мен әдістемесі әзірленеді.

Agile дәуіріндегі енгізілген бағдарламалық қамтамасыз етуді тексеру және сәйкестік

Өнеркәсіптік стандарттарға сәйкестік сіз елеусіз қалдыратын немесе кейінірек жасай алатын нәрсе емес; ол ендірілген бағдарламалық жасақтаманы (бағдарламалық қамтамасыз етуді) әзірлеу процесінің ажырамас бөлігі болып табылады. Авионика, автомобиль жасау және денсаулық сақтау сияқты кейбір салалар үшін күрделі және ақаусыз ендірілген жүйелерді әзірлеуде сапа стандарттарын қатаң сақтау өнімді нарыққа шығару үшін өте маңызды. Дәстүрлі түрде тестілеу стандарттармен реттелетін салалар үшін енгізілген жүйелерді әзірлеуде маңызды рөл атқарды. Дегенмен, соңғы жылдары қалыптасқан сынақ тәжірибелері мен процестері, олардың мұндай жобалардағы орны мен рөлі айтарлықтай өзгерді. Бұл ойынды өзгертуші болды және ойын ережелері өзгерген кезде, жеңіске жету үшін олармен бірге өзгерту керек.

Жаңа, озық технологиялардың ұдайы дамуы кезінде компаниялар нарыққа сенімді, қауіпсіз, қолдануға оңай және басқа жүйелермен үйлесімді өнімдерді жылдам ұсынуы керек - тек тез өзгеретін технологиялық әлемде адасып қалмау үшін. Мұндай жағдайда бағдарламалық жасақтаманы әзірлеу процесі қатаң дәйекті және тестілеу ең соңында орындалатын дәстүрлі сарқырама үлгісі өткеннің еншісіне айналады. DevOps және Agile әдістері барған сайын танымал бола түсуде, өйткені олар инженерлерге бұрын бір-бірін орындаған тапсырмаларды бір уақытта орындауға мүмкіндік береді.

Өнімділік сынағы

Өнімділікті сынау кезеңінде бірінші қадам жүктемені тексеру болып табылады, оның мақсаты жүйенің нақты жұмыс режиміне жақын режимде сыртқы әсерлерге барабар жауап беретінін тексеру болып табылады.

Жүктемелік тестілеуден басқа, сынақтар ең аз аппараттық және максималды жүктеме жағдайында жүргізіледі - стресс-тестілеу, сондай-ақ өңделген ақпараттың максималды көлемдеріндегі сынақтар - көлемдік сынау.

Тестілеудің тағы бір түрі бар: тұрақтылық пен сенімділікті тестілеу, ол бағдарламалық өнімді қалыпты жағдайда ұзақ мерзімді тестілеуді ғана емес, сонымен қатар қысқа мерзімді стресстік жүктемелерден кейін оның қалыпты жұмысына оралу мүмкіндігін қамтиды.

Тестілеуге арналған құжаттама

Жоғарыда айтылғандай, тестілеу ГОСТ 34.603-92 сәйкес әзірленген бағдарламаға және сынақ әдістемесіне сәйкес жүзеге асырылады.

Тестілеуді жүзеге асыру үшін бағдарламалық өнім жұмысының барлық режимдерін сынау үшін жеткілікті мәліметтерді қамтуы тиіс сынақ жағдайы әзірленеді. Әдетте, сынақ жағдайын нақты деректер негізінде тапсырыс беруші мен мердігер бірлесіп жасайды.

Өнімділікті тексерудің барлық түрлерін жүргізу үшін көбінесе деректер генераторы деп аталады, бұл мүмкіндік береді автоматты режимөнімділікті бағалау кезінде объективті нәтижеге жету үшін деректердің жеткілікті көлемін жасау.

Тестілеу кезінде тестілеудің барлық кезеңдері мен қадамдарының аяқталуы туралы ақпарат және тестілеу кезінде алынған ескертулер бар тестілеу хаттамасы жасалады.

Сынақ нәтижесі теріс болса, кемшіліктер түзетіліп, қайта тексеріледі.

Барлау тестілеу

Барлау тестілеу ( ad hoc тестілеу — функционалдық тестілеудің ішкі түрі. Ол нақты құжаттама мен талаптар жоқ, икемді әзірлеу әдістерімен жылдам дамып келе жатқан жобаларда қолданылады. Барлау тестілеу — бағдарламалық қамтамасыз етуді тестілеудегі ең жоғары пилотаж. Сапалық тестілеу жоғары білікті мамандар және толығымен дерлік орындаушыға, оның тәжірибесіне, біліміне (пәндік салада да, тестілеу әдістерінде де) және мәнге тез жету қабілетіне байланысты.

Стресс тестілеу

Жүктеме сынағы - жүктеме кезінде сыналатын жүйенің өнімділігін талдау процесі. Жүктемені сынаудың мақсаты қолданбаның сыртқы жүктемелерге төтеп беру қабілетін анықтау болып табылады. Әдетте, сынақтар бірнеше кезеңде жүзеге асырылады.

1. Сынақ сценарийлерін құру

Тиімді талдау үшін сценарийлер нақты пайдалану жағдайларына мүмкіндігінше жақын болуы керек. Ерекшеліктер әрқашан мүмкін екенін түсіну маңызды, тіпті ең егжей-тегжейлі сынақ жоспары бір жағдайды қамтымауы мүмкін.

2. Тест конфигурациясын әзірлеу

Сынақ сценарийлеріне ие бола отырып, жүктемені арттыру тәртібін бөлу маңызды. Табысты талдау үшін өнімділікті бағалау критерийлерін (жауап беру жылдамдығы, сұранысты өңдеу уақыты және т.б.) анықтау қажет.

3. Сынақ тестін өткізу

Сынақтарды жүргізу кезінде сценарийлердің орындалуын және сынақтан өтіп жатқан жүйенің жауабын уақтылы бақылау маңызды. Жоғары жүктемелерді эмуляциялау күрделі аппараттық және бағдарламалық қамтамасыз ету инфрақұрылымын қажет етеді. Кейбір жағдайларда жұмыстың құнын төмендету үшін математикалық модельдеу әдістері қолданылады. Төмен жүктемелерде алынған деректер негізге алынады және жуықталады. Имитациялық жүктеменің деңгейі неғұрлым жоғары болса, бағалаудың дәлдігі соғұрлым төмен болады. Дегенмен, бұл әдіс шығындарды айтарлықтай азайтады.

Сынақтарды автоматтандыру

Автоматтандырылған тестілеудің басты ерекшелігі - регрессиялық сынақтарды жылдам жүргізу мүмкіндігі. Автоматтандырудың негізгі артықшылықтары (Worsoft есебіне сәйкес) қызметкерлердің тиімділігін арттыру, ақауларды ертерек анықтау және т.б. жоғары сапабизнес-процестер. Бұл артықшылықтар елеулі кемшілікпен өтеледі: жоғары құны – сынақ автоматтандыруды енгізу мен қолдаудың жоғары құнына байланысты компаниялардың шамамен 50% әлі де негізінен қолмен тестілеуді пайдаланады.

Қолдану мүмкіндігін тексеру

Кез келген қолданба пайдалану үшін жасалады. Пайдаланудың қарапайымдылығы бағдарламаның маңызды сапа көрсеткіші болып табылады. АТ индустриясы қолайлылықты сәтті түзетілгеннен кейін жобалардың көптеген мысалдарын біледі. Аудитория неғұрлым кең болса, соғұрлым ыңғайлылық факторы маңызды. Пайдалануға жарамдылық тестілеу пайдаланушы әрекетін егжей-тегжейлі талдауды қамтиды. Эргономиканы бағалау үшін іскерлік тапсырманы орындау жылдамдығы туралы ғана емес, сонымен қатар пайдаланушының эмоциялары, мимикасы және дауыс тембрі туралы деректер болуы маңызды.

Конфигурация сынағы

Конфигурацияны тестілеу қолданбаның әртүрлі платформаларда жұмыс істейтініне сенімділік береді, сондықтан пайдаланушылардың максималды саны үшін. WEB қолданбалары үшін әдетте кросс-браузерді тестілеу таңдалады. Windows қолданбалары үшін - әртүрлі тестілеу операциялық жүйелержәне бит өлшемдері (x86, x64). Конфигурациялық тестілеудің маңызды құрамдас бөлігі сынақ инфрақұрылымы болып табылады: сынақтарды жүргізу үшін сынақ машиналарының паркін үнемі күтіп ұстау керек. Олардың саны 5-тен бірнеше ондағанға дейін өзгереді.

Интеграциялық тестілеу

Егер жобаңызда бірнеше құрамдас болса, ол интеграциялық тестілеуді қажет етеді. Күрделі қолданбалы архитектурамен сапаны қамтамасыз етудің қажетті шарты бағдарлама бөліктерінің өзара әрекеттесуін тексеру болып табылады. Тестілеу «ұшты-ұшты» жағдайларды әзірлеу және өткізу арқылы жүзеге асырылады. Интеграциялық тестілеу құрамдас тестілеуден кейін жүргізіледі. Сондықтан тестілеу жағдайларының іскерлік бағытын сақтай отырып, құрамдас тестілеу тәжірибесін ескеру өте маңызды.

Стресс тестілеу

Әрбір жүйенің шегі бар қалыпты жұмыс істеуі. Шектеуден асып кеткен кезде жүйе күйзеліске түседі және оның мінез-құлқын айтарлықтай өзгертеді. Стресс-тестілеу қалыпты жұмыс істеу шегінен асатын жағдайларда қолданбаның жұмысын тексереді. Бұл әсіресе «сыни» бағдарламалар үшін маңызды: банктік бағдарламалық қамтамасыз ету, авиация саласының бағдарламалары, медицина. Стресс-тестілеу тек бағдарламалық жасақтаманы әзірлеу сатысында ғана емес, сонымен қатар ұзақ уақыт бойы жүйенің мінез-құлық деректерін алу және өңдеу үшін бүкіл операциялық циклде жүзеге асырылады.

Мәліметтерді алу функциясы бар делік, ол өткен пайдаланушы идентификаторы туралы ақпарат картасын қайтарады. Енді бұл функция үш түрлі карта түрін жасау үшін source-a , source-b және source-c 3 функциясын пайдаланады. Енді біз осы карталардың барлығын бір картаға біріктіріп, деректерден ораламыз.

Мен деректерді тексеру кезіндекілттер үшін деректердің қолжетімділігін тексеруім керек пе? A source-a, source-b және source-c параметрлерінің біреуі сәтсіз болса, бұл функцияның бірлік сынақтарынан өтпеуі мағынасы бар ма? Егер бұл функцияның жұмысы деректерді біріктіру болса және ол болса, бұл жеткілікті болуы керек, солай емес пе?

2 жауап

Берілген пайдаланушы идентификаторы туралы ақпарат картасын қайтаратын деректер алу функциясы бар делік.

Тамаша. Содан кейін сіз оны тексеруіңіз керек. Берілген идентификатор үшін дұрыс деректерді қайтарып жатырсыз ба?

енді бұл функция үш түрлі карталар түрін жасау үшін source-a, source-b және source-c 3 функциясын пайдаланады.

Сынақта қандай іске асыру мәліметтерін елемеу керек. Сіз сынап жатқанның бәрі жұмыс бірлігіңіздің (бұл әдіс) орындауы тиіс нәрсені орындауы (идентификаторды алып, сол идентификатор үшін XYZ деректерін қайтарыңыз). Қалайбұл әдіс шын мәнінде маңызды емес - түптеп келгенде, бұл бірлік сынағының негізгі артықшылығы - әдісті іске асыруды қайта өңдеуге болады және сынақ оны дұрыс жасағаныңызды тексереді.

Дегенмен, сізге деректер көздерін мазақ ету керек болуы мүмкін, сондықтан бір сәтте сынақ бұл кодтың қалай жұмыс істейтінін білуі керек. Мұнда сіз үш бәсекелес мақсатты теңестіруіңіз керек: тестті оқшаулау (деректерді келемеждеу арқылы), тестті талаптар мен прагматизмге бағыттау.

Өйткені, бұл маңызды код. Нақты кодты қолдауға арналған сынақтар бар, көп уақыт жұмсайды және жылтыратуды тексеру қиындықтары сынақтар сияқты пайдалы емес. жасау .

Бірлікті тестілеу кезінде тек бір сыныптың функционалдығын тексеру керек, егер сіздің source-a, source-b және source-c әдістері басқа сыныптарды шақырса, сіз оларды мазақ етуіңіз керек (олар өз сыныптарында бірлік сыналуы керек).

Интеграциялық тестілеу кезінде сіз олардың арасындағы өзара әрекеттесетін бірнеше сыныптардың әрекетін сынап жатырсыз, бұл сіздің деректер алу функциясы шығарылып жатқан деректердің дұрыстығын тексеруі керек дегенді білдіреді (көз-a, бастапқы-b және бастапқы-c дұрыс және деректер дұрыс қосылған).

Бірлік сынақтары қарапайым және көбірек бағытталған және оларды әзірлеушілер жазуы керек. Интеграциялық сынақтар әдетте салыстырмалы түрде тез ескіреді (бар болса). ішкі компонентөзгертілді), оларды орындауды қиындатады. QA профилі арқылы жасалуы керек.

Бұл сұраққа нақты жауап жоқ. Бірақ ғасырлар бойы ең дана ғалымдар бұл тақырыпты жылдар бойы ойластырды және егер ол барлық бағдарламалық қателерді жоймаса, кем дегенде оларды жою әрекетінің елесін тудыратын құрал таба алды.

Және бұл құрал деп аталады Бағдарламалық өнімді сынау.

Дана адамдардың пікірінше, Тестілеу бағдарламалық қамтамасыз етуді әзірлеу сапасын қамтамасыз етудің ең қалыптасқан әдістерінің бірі болып табылады және қазіргі заманғы бағдарламалық өнім сапасын қамтамасыз ету жүйесінің тиімді құралдарының жиынтығына кіреді.

Қашан және кім?

Функционалды тестілеу
Функционалды емес тестілеу

Функционалды тестілеу

Функционалдық тестілеуді өткізу үшін техникалық бақылау бөлімінің қызметкерлері құжаттық бағдарлама мен қосымшаның (API) функционалдығын тексеру әдістемесін әзірлеуде. PMI құжатында қадамдардың егжей-тегжейлі сипаттамасы бар бағдарламалық өнімді сынау сценарийлерінің (сынақ жағдайлары) тізімі бар. Тестілеу сценарийінің әрбір қадамы пайдаланушының (тестілеуші маманның) әрекеттерімен және күтілетін нәтижелермен - бағдарламаның осы әрекеттерге жауабымен сипатталады. Сынақ бағдарламасы мен әдістемесі нақты режимде бағдарламалық өнімнің жұмысын имитациялауы керек. Бұл тестілеу сценарийі жүйенің болашақ пайдаланушылары орындайтын операцияларды талдау негізінде құрылуы керек және тек әзірлеушіге түсінікті жасанды түрде құрастырылған манипуляциялар тізбегі болмауы керек дегенді білдіреді.

Әдетте, функционалдық тестілеу екі деңгейде жүргізіледі:

Компоненттік (бірлік) тестілеу. Бағдарламалық өнімнің жеке құрамдас бөліктерін сынау, олардың ерекшеліктеріне, тағайындалуына және функционалдық ерекшеліктеріне бағытталған.
Интеграциялық тестілеу. Тестілеудің бұл түрі компоненттерді тестілеуден кейін жүргізіледі және басқару ағындары мен деректер алмасу деңгейінде әртүрлі ішкі жүйелердің өзара әрекеттесуіндегі ақауларды анықтауға бағытталған.

Функционалды емес тестілеу

Аты айтып тұрғандай, функционалды емес тестілеу бағдарламалық өнімнің функционалды емес талаптарға сәйкестігін оны жасаудың техникалық сипаттамаларынан тексереді. Ал, функционалдық тестілеудегідей, функционалдық емес тестілеуге арналған тест бағдарламасы мен әдістемесі әзірленеді.

Agile дәуіріндегі енгізілген бағдарламалық қамтамасыз етуді тексеру және сәйкестік

Өнімділік сынағы

Тестілеуге арналған құжаттама

Тиімділікті тексерудің барлық түрлерін жүргізу үшін өнімділікті бағалау кезінде объективті нәтижеге қол жеткізу үшін деректердің жеткілікті мөлшерін автоматты түрде жасауға мүмкіндік беретін деректер генераторы деп аталатындар жиі жасалады.

Сынақ нәтижесі теріс болса, кемшіліктер түзетіліп, қайта тексеріледі.

Барлау тестілеу

Стресс тестілеу

1. Сынақ сценарийлерін құру

2. Тест конфигурациясын әзірлеу

3. Сынақ тестін өткізу

Сынақтарды автоматтандыру

Автоматтандырылған тестілеудің басты ерекшелігі - регрессиялық сынақтарды жылдам жүргізу мүмкіндігі. Автоматтандырудың негізгі артықшылықтары (Worsoft есебіне сәйкес) қызметкерлердің тиімділігін арттыру, ақауларды ертерек анықтау және бизнес-процестердің жоғары сапасы болып табылады. Бұл артықшылықтар елеулі кемшілікпен өтеледі: жоғары баға – сынақ автоматтандыруды енгізу мен қолдаудың жоғары құнына байланысты компаниялардың шамамен 50% әлі де негізінен қолмен тестілеуді пайдаланады.

Қолдану мүмкіндігін тексеру

Конфигурация сынағы

Конфигурацияны тестілеу қолданбаның әртүрлі платформаларда жұмыс істейтініне сенімділік береді, сондықтан пайдаланушылардың максималды саны үшін. WEB қолданбалары үшін әдетте кросс-браузерді тестілеу таңдалады. Windows қолданбалары үшін - әртүрлі операциялық жүйелерде және бит жылдамдығында тестілеу (x86, x64). Конфигурациялық тестілеудің маңызды құрамдас бөлігі сынақ инфрақұрылымы болып табылады: сынақтарды жүргізу үшін сынақ машиналарының паркін үнемі күтіп ұстау керек. Олардың саны 5-тен бірнеше ондағанға дейін өзгереді.

Интеграциялық тестілеу

Стресс тестілеу

Кез келген жүйенің қалыпты жұмыс істеуінің шегі бар. Шектеуден асып кеткен кезде жүйе күйзеліске түседі және оның мінез-құлқын айтарлықтай өзгертеді. Стресс-тестілеу қалыпты жұмыс істеу шегінен асатын жағдайларда қолданбаның жұмысын тексереді. Бұл әсіресе «сыни» бағдарламалар үшін маңызды: банктік бағдарламалық қамтамасыз ету, авиация саласының бағдарламалары, медицина. Стресс-тестілеу тек бағдарламалық жасақтаманы әзірлеу сатысында ғана емес, сонымен қатар ұзақ уақыт бойы жүйенің мінез-құлық деректерін алу және өңдеу үшін бүкіл операциялық циклде жүзеге асырылады.

Барлық түрлердің ішінде функционалдық тестілеу заңды түрде жетекші орынды алады, өйткені бағдарлама ең алдымен дұрыс жұмыс істеуі керек, әйтпесе пайдаланудың қарапайымдылығы, қауіпсіздік және жеткілікті жылдамдық мүлдем пайдасыз болады. Тестілеудің әртүрлі әдістерін меңгерумен қатар, ең тиімді нәтиже алу үшін әрбір маман тестті қалай дұрыс өткізу керектігін түсінуі керек.

Функционалды тестілеу: негізгі күштерді қайда бағыттау керек?

Құрылғыны және жүйені тестілеу үшін;

«Ақ» немесе «қара» ұяшықты белгілеу үшін;

Қолмен тестілеу және автоматтандыру үшін;

Жаңа функционалдылықты тексеру үшін немесе;

«Теріс» немесе «оң» сынақтар үшін.

Барлық осы қызмет бағыттарының арасында әр саланың артықшылықтарын барынша пайдалана отырып, күш-жігерді теңестіру үшін «орта» болатын дұрыс жолды табу маңызды.

Бағдарламалық қамтамасыз етуді тексеру жүргізіледі әртүрлі жолдар, олардың бірі қара жәшік немесе деректерге негізделген тестілеу.

Бұл жағдайда бағдарлама «қара жәшік» тұрғысынан ұсынылған және бағдарламаның мінез-құлқы спецификацияға сәйкес келмейтін жағдайларды анықтау үшін сынақ жүргізіледі. Барлық қателер деректерді басқару арқылы анықталады, ол толық тестілеу арқылы жүзеге асырылады, яғни барлық мүмкіншіліктерді пайдаланады

Егер бағдарлама үшін команданың орындалуы оның алдындағы оқиғаларға байланысты болса, онда ол барлық ықтимал тізбектерді тексеруді қажет етеді. Көптеген жағдайларда толық тестілеуді жүргізу мүмкін емес екені анық, сондықтан олар көбінесе барлық кіріс деректерінің шағын жиынында бағдарламаны іске қосумен шектелетін қолайлы немесе ақылға қонымды опцияны таңдайды. Бұл опция спецификациялардан ауытқуларға толық кепілдік береді.

Функционалды тестілеу дұрыс тестті таңдауды қамтиды. Сонымен қатар, олар үшін жинақтарды құрудың келесі әдістерін ажырату әдеттегідей:

Шекаралық талдау;

Эквивалентті бөлім;

Қате туралы болжам;

Себептер мен салдарлардың байланысын талдау.

Олардың әрқайсысын бөлек қарастыруға болады.

Шекаралық талдау. Шектік мәндер әдетте эквиваленттілік кластарының шекарасында орналасқан мәндер ретінде түсініледі. Мұндай жерлерде қатені табу ықтималдығы жоғары. Мұндай әдісті қолдану маманнан белгілі бір шығармашылықты, сондай-ақ қарастырылып отырған осы нақты мәселеге мамандануды талап етеді.

Эквивалентті бөлім. Енгізу параметрлерінің барлық мүмкін жиынтықтары бірнеше эквиваленттік кластарға бөлінеді. Деректер ұқсас қателерді анықтау принципі негізінде біріктірілген. Егер бір сыныптың жиыны қатені көрсетсе, эквиваленттері де оны көрсетеді деп жалпы қабылданған. Функционалды тестілеу бұл әдісекі кезеңде жүзеге асырылады: біріншісінде эквиваленттік сыныптар анықталады, ал екіншісінде арнайы сынақтар қалыптасады.

Себеп-салдар байланысын талдау. Жүйе осындай тексерулерді жүргізу арқылы өнімділігі жоғары сынақтарды таңдай алады. Бұл жағдайда себеп ретінде жеке кіріс шарты қабылданады, ал нәтиже ретінде шығыс шарты көрінеді. Әдіс себептердің барлық түрлерін белгілі бір салдарға жатқызу идеясына, яғни сол себепті-салдарлық байланыстарды нақтылауға негізделген. Бағдарламалық өнімді тестілеу бірнеше кезеңдерде жүзеге асырылады, нәтижесінде себептер мен одан туындайтын салдарлар тізімі алынады.

әзірлеушілердің жұмыс стандарттарынан немесе енгізу жоспарларынан әдейі ауытқулары;
функционалдық және интерфейстік талаптардың спецификациялары әзірлеу стандарттарын сақтамай жасалады, бұл бағдарламалардың жұмыс істеуінің бұзылуына әкеледі;
әзірлеу процесін ұйымдастыру – жоба менеджерінің ресурстарын (адамдық, техникалық, бағдарламалық және т.б.) жетілмеген немесе жеткіліксіз басқару және жоба элементтерін тестілеу және біріктіру мәселелері.

ISO/IEC 12207 стандартының ұсыныстарына негізделген тестілеу процесін қарастырайық және әрбір өмірлік цикл процесінде анықталған қателердің түрлерін берейік.

Талаптарды әзірлеу процесі. Жүйенің бастапқы тұжырымдамасын және жүйеге қойылатын бастапқы талаптарды анықтау кезінде талдаушылар спецификация қателерін жібереді жоғарғы деңгейжүйелер мен пәндік саланың концептуалды моделін құру.

Бұл процестегі типтік қателер:

соңғы пайдаланушыларға қойылатын талаптар спецификациясының сәйкессіздігі - бағдарламалық қамтамасыз етудің операциялық ортамен немесе пайдаланушылармен өзара әрекеттесуінің дұрыс спецификациясы;
бағдарламалық қамтамасыз етудің жеке және жалпы қасиеттеріне тұтынушылардың талаптарын сақтамау;
функционалдық сипаттамаларды дұрыс сипаттамау;
тұтынушылардың талаптарын орындаудың барлық аспектілері үшін құралдардың болмауы және т.б.

Жобалау процесі.Компоненттерді жобалаудағы қателер алгоритмдерді, басқару логикасын, деректер құрылымдарын, интерфейстерді, деректер ағынын модельдеу логикасын, енгізу/шығару пішімдерін және т.б. сипаттау кезінде орын алуы мүмкін. Бұл қателер аналитиктердің спецификацияларындағы ақауларға және дизайн кемшіліктеріне негізделген. Олар мыналарға қатысты қателерді қамтиды:

қоршаған ортамен пайдаланушы интерфейсінің анықтамасымен;
функцияларының сипаттамасымен (компоненттер жиынтығын тексеру кезінде анықталған компоненттердің мақсаттары мен міндеттерінің сәйкессіздігі);
ақпаратты өңдеу процесін анықтаумен және процестер арасындағы өзара әрекеттесу (құрамдас бөліктер мен процестердің байланыстарын дұрыс анықтаудың нәтижесі);
жеке құрамдастарды және тұтастай бағдарламалық қамтамасыз етуді сипаттау кезінде деректер мен олардың құрылымдарының қате спецификациясымен;
модульдік алгоритмдерді дұрыс сипаттамаумен;
пайда болу шарттарын анықтаумен мүмкін қателербағдарламада;
жоба үшін қабылданған стандарттар мен технологияларды бұзады.

Кодтау кезеңі.Бұл кезеңде жүйені әзірлеу және жөндеу кезіндегі жобалау ақауларының, бағдарламашылар мен менеджерлердің қателіктерінің нәтижесі болып табылатын қателер туындайды. Қателердің себептері:

кіріс параметрлерінің, массив индекстерінің, цикл параметрлерінің, шығыс нәтижелерінің, 0-ге бөлудің және т.б. мәндерін бақылаудың болмауы;
шақырылатын ішкі бағдарламалардан, функциялардан және т.б. қайтару кодтарын талдау кезінде ретсіз жағдайларды дұрыс өңдеу;
кодтау стандарттарын бұзу (жаман пікірлер, қисынсыз модульдерді бөлужәне құрамдас және т.б.);
әртүрлі объектілерді немесе бір объектінің әртүрлі атауларын белгілеу үшін бір атауды пайдалану, нашар атау мнемотехникасы; - әртүрлі әзірлеушілердің бағдарламаға сәйкес келмейтін өзгертулері және т.б.

Тестілеу процесі.Бұл процесте бағдарламашылар мен тестерлер құрастыру және тестілеу технологиясын орындау, сынақ жиынтықтары мен сынақ сценарийлерін таңдау және т.б. кезінде қателер жібереді. Мұндай қателерден туындаған бағдарламалық жасақтамадағы ақаулар анықталуы, жойылуы және құрамдас бөліктерінің статистикасына әсер етпеуі керек. жалпы бағдарламалық қамтамасыз ету қателері.

Техникалық қызмет көрсету процесі.Техникалық қызмет көрсету процесінде пайдалану құжаттамасындағы кемшіліктер мен ақаулардан, өзгерту және оқуға қабілеттілік көрсеткіштерінің жеткіліксіздігінен, сондай-ақ бағдарламалық қамтамасыз етуді жүргізуге және/немесе жетілдіруге жауапты тұлғалардың біліксіздігінен туындаған қателер анықталады. Енгізілетін өзгерістердің сипатына қарай, осы кезеңде алдыңғы кезеңдердегі бұрын аталған қателерге ұқсас кез келген дерлік қателер орын алуы мүмкін.

Бағдарламаларда кездесетін барлық қателер әдетте келесі кластарға бөлінеді [7.12]:

логикалық және функционалдық қателер;
есептеу және орындау уақытындағы қателер;
енгізу/шығару және деректерді өңдеу қателері;
интерфейс қателері;
деректер көлемінің қателері және т.б.

Логикалық қателералгоритм логикасының бұзылуының, айнымалылар мен операторлардың ішкі сәйкессіздігінің, сондай-ақ бағдарламалау ережелерінің себебі болып табылады. Функционалдық қателер – дұрыс анықталмаған функциялардың салдары, оларды қолдану тәртібінің бұзылуы немесе олардың орындалуының толық болмауы және т.б.

Есептеу қателерібастапқы деректердің және орындалған формулалардың дәл болмауынан, әдіс қателерінен, есептеу операцияларын немесе операндтарды дұрыс қолданбаудан туындайды. Орындау қателері сұранысты өңдеу жылдамдығын немесе бағдарламаны қалпына келтіру уақытын қамтамасыз етпеумен байланысты.

Енгізу/шығару қателеріал деректермен манипуляциялау - бұл мәліметтерді бағдарламаны орындауға сапасыз дайындаудың, мәліметтер базасына енгізу немесе одан алу кезіндегі сәтсіздіктердің салдары.

Интерфейс қателеріжеке элементтердің бір-бірімен қарым-қатынасындағы қателерге сілтеме жасайды, олар арасында деректерді беру кезінде, сондай-ақ операциялық ортамен өзара әрекеттесу кезінде көрінеді.

Көлем қателерідеректерге қатысты және енгізілген қол жеткізу әдістері мен деректер қоры өлшемдері жүйелік ақпараттың нақты көлемін немесе оларды өңдеу қарқындылығын қанағаттандырмауының салдары болып табылады.

Қателердің берілген негізгі кластары бағдарламалық құрамдастардың әртүрлі типтеріне тән және олар бағдарламаларда әртүрлі тәсілдермен көрінеді. Осылайша, деректер қорымен жұмыс істеу кезінде деректерді ұсыну және манипуляциялау кезінде қателер пайда болады, логикалық қателерқолданбалы деректерді өңдеу процедураларын көрсетуде және т.б. Есептеу бағдарламаларында есептеу қателері, ал басқару және өңдеу бағдарламаларында логикалық және функционалдық қателер басым болады. Әртүрлі функцияларды жүзеге асыратын көптеген әртүрлі бағдарламалардан тұратын бағдарламалық құралда қателер болуы мүмкін әртүрлі түрлері. Интерфейс қателері мен көлемді бұзу жүйенің кез келген түріне тән.

Бағдарламалардағы қателердің түрлерін талдау бағдарламалық жасақтаманың дұрыстығын қамтамасыз ету үшін сынақ жоспарлары мен сынақ әдістерін құрудың міндетті шарты болып табылады.

Бағдарламалық жасақтаманы әзірлеуді қолдау құралдарын (CASE технологиялары, модельдер мен бағдарламаларды жобалаудың объектілі-бағытталған әдістері мен құралдары) әзірлеудің қазіргі кезеңінде бағдарламалық қамтамасыз ету ең жиі кездесетін қателерден қорғалған және сол арқылы келесі қателердің пайда болуын болдырмайтын дизайн жүзеге асырылады. бағдарламалық құрал ақаулары.

Қате мен сәтсіздік арасындағы байланыс.Бағдарламада қатенің болуы, әдетте, оның жұмысы кезінде бағдарламалық қамтамасыз етудің істен шығуына әкеледі. «Қате-сәтсіздіктің» себеп-салдарлық байланыстарын талдау үшін келесі әрекеттер орындалады:

жобалау және бағдарламалау технологияларындағы кемшіліктерді анықтау;
жобалау процесіндегі кемшіліктер мен адам қателері арасындағы байланыс;
ақауларды, кемшіліктерді және мүмкін болатын қателерді, сонымен қатар дамудың әрбір кезеңіндегі ақауларды жіктеу;- жобаның спецификациясындағы, бағдарлама үлгілеріндегі қателердің салдары ретінде белгілі бір әзірлеу процесінде жіберілген адам қателерін және объектідегі ақауларды салыстыру;
өмірлік циклдің барлық кезеңдерінде тексеру және қателерден қорғау, сондай-ақ дамудың әрбір кезеңінде ақауларды анықтау;
ақаулар мен ақаулар туралы ақпаратты оқшаулау, жинау және талдау әдістері мен өзара байланыстар жүйесін әзірлеу үшін бағдарламалық қамтамасыз етудегі ақаулар мен ақауларды салыстыру;
бағдарламалық қамтамасыз етуді құжаттау және тестілеу процестеріне тәсілдерді әзірлеу.

Қателік қателік себеп-салдарының түпкілікті мақсаты белгілі бір сыныптардағы қателерді сынау және анықтау әдістері мен құралдарын, сондай-ақ бірнеше деректер жиынында тестілеуді аяқтау критерийлерін анықтау болып табылады; бағдарламалық қамтамасыз етуді әзірлеу, тестілеу және техникалық қызмет көрсету процесін ұйымдастыруды жетілдіру жолдарын анықтауда.

Міне, ақау түрлерінің келесі классификациясы:

жалпы жүйелік бағдарламалық қамтамасыз ету жұмыс істемейтін аппараттық құрал;
ақпаратты енгізудегі және байланыс арналары арқылы деректерді берудегі қателерден, сондай-ақ енгізу құрылғыларының істен шығуынан (аппараттық құралдардың ақауларының салдары) туындаған ақпараттық;
эргономикалық, оның машинамен өзара әрекеттесу кезіндегі оператордың қателерінен туындаған (бұл ақаулық екінші реттік ақау болып табылады және ақпараттық немесе функционалдық ақауларға әкелуі мүмкін);
бағдарламалық қамтамасыз ету, егер компоненттерде қателер болса және т.б.

Кейбір қателер талаптарды анықтаудағы, дизайндағы, шығыс кодын жасаудағы немесе құжаттамадағы кемшіліктердің нәтижесі болуы мүмкін. Екінші жағынан, олар бағдарламаны әзірлеу кезінде немесе бағдарламаның жеке элементтерінің интерфейстерін әзірлеу кезінде (параметрлер тәртібінің бұзылуы, аз немесе көп параметрлер және т.б.) түзіледі.

Қателердің көздері.Қателер жобаны, құрамдас бөліктерді, кодты және құжаттаманы әзірлеу кезінде туындауы мүмкін. Әдетте, олар бағдарламалық жасақтаманы орындау немесе техникалық қызмет көрсету кезінде ең күтпеген және әртүрлі нүктелерде анықталады.

Бағдарламадағы кейбір қателер талаптарды анықтаудағы, дизайндағы, кодты жасаудағы немесе құжаттамадағы кемшіліктердің нәтижесі болуы мүмкін. Екінші жағынан, қателер бағдарламаны немесе оның элементтерінің интерфейстерін әзірлеу кезінде пайда болады (мысалы, байланыс параметрлерін орнату тәртібі бұзылғанда – талап етілгеннен аз немесе көп және т.б.).

Қателердің себебі - тұтынушы талаптарын түсінбеу; жобалық құжаттардағы талаптардың дұрыс көрсетілмеуі және т.б. Бұл тапсырыс беруші ұсынғандай жұмыс істемейтін кейбір жүйелік функциялардың жүзеге асырылуына әкеледі. Осыған байланысты, тапсырыс беруші мен әзірлеуші арасында талаптардың кейбір бөлшектерін нақтылау үшін бірлескен талқылау жүргізіледі.

Жүйені әзірлеу тобы жүйе сипаттамасының синтаксисі мен семантикасын да өзгерте алады. Дегенмен, кейбір қателер анықталмауы мүмкін (мысалы, бұл мәлімдемелердің индекстері немесе айнымалы мәндері дұрыс орнатылмаған).

Санаттағы танымал: