Алғашқы компьютерлердің пайда болуы — компьютерлік бағдарламалардың пайда болуына себеп болды. Ал бағдарламалау, кез-келген адам сияқты іс жүзінде қателіктерсіз жұмыс жасай алмайды. Бұл мақалада тестілеуге талдау жүргізіледі.
Түйінді сөздер: бағдарламалық қамтама, тестілеу, тестілік сценарийлер, тестілеуге байланысты стандарттар.
В статье рассматривается роль процесса тестирование в разработке программного обеспечения. Проанализированы основные этапы и задачи тестирования ПО.
Ключевые слова: программное обеспечение, тестирование, тестовые сценарии, стандарты тестирования.
Бағдарламалық жасақтаманы тестілеу
Бағдарламалық жасақтаманы тестілеу — ақауларды анықтау және өнім сапасын жақсарту үшін бағдарламалық жасақтаманы және тиісті құжаттарды талдау процесі. Бағдарламалық жасақтаманы тестілеу — бағдарламаның іс жүзіндегі мінез-құлқы мен оның күтілетін мінез-құлқының нақты жолмен таңдалған тестілердің соңғы жиынтығына сәйкестігін тексеруге арналған бағдарламалық өнімдерді зерттеу және сынау процесі (ISO / IEC TR 19759: 2005).
Әртүрлі уақытта және түрлі дереккөздерден тестілеуге түрлі анықтамалар берілді, соның ішінде:
Қате табу мақсатында бағдарламаны орындау процесі.
Интеллектуалдық тәртіпті сенімді бағдарламалық қамтамасыз етуді алуға бағытталған, оны тексерудің қажеті жоқ.
Техникалық зерттеушілік бағдарлама, оның сапасы туралы ақпаратты мүдделі тараптардың белгілі бір ауқымы бойынша алуға болады.
Бағдарламаның іс жүзіндегі мінез-құлқының және белгілі бір жолмен орындалатын сынақтардың соңғы жиынтығындағы күтілетін мінез-құлықтың сәйкестігін тексеру.
Бағдарламаны арнайы жағдайларда жүзеге асыруға мониторинг жүргізу және осы негізде оның жұмысының кез-келген аспектілерін бағалау.
Бағдарламаның мінез-құлқының дұрыс емес, жағымсыз немесе спецификацияға сәйкес келмейтін жағдайларды анықтауға бағытталған процесс.
Бағдарламалық қамтамасыз етуді жоспарлауға, дайындау мен бағалауға және олармен байланысты жұмыстардың нәтижелеріне байланысты, олардың белгіленген мақсаттарға қолайлы екенін көрсету үшін сипатталған талаптарды қанағаттандыратындығын анықтау үшін өмірлік циклі, динамикалық және статикалық барлық әрекеттерін қамтитын процесс ақауларды анықтау.
2000-шы жылдары «бизнес-технологияларды оңтайландыру» тұжырымдамасы (БТО) оған қосылған кезде тестілеудің кеңірек анықтамасы пайда болды. БТО бизнес-мақсаттарға сәйкес ақпараттық технологиялардың дамуын басқарады. Негізгі тәсіл — қажетті сапа, өнімділік, қолжетімділік деңгейін қамтамасыз ету үшін бағдарламалық жасақтаманың даму кезеңінің барлық сатыларының маңыздылығын бағалау және барынша арттыру. Тестілеуді түсінуге едәуір әсер еткен «сынақпен басқарылатын басқару (сынақ негізінде дамыту, TDD)» сияқты икемді даму әдіснамалары мен тәсілдері пайда болды. Автоматтандыру сынағы қазірдің өзінде көптеген жобалардың қарапайым ажырамас бөлігі ретінде қабылданды және тестілеу процесінің жетекшісі бағдарламаның талаптарға сай келуімен емес, сонымен қатар түпкі пайдаланушыны өз мәселелерін тиімді шешуге қабілеттілігімен қамтамасыз ету керек деп ойлады.
Егер біз негізгі сипаттамаларды қысқаша сипаттайтын болсақ, біз келесідей нәрсеге ие боламыз: икемді әдіснама және икемді тестілеу, даму үдерісімен терең интеграциялау, автоматтандыруды кеңінен қолдану, технология мен құралдардың орасан зор жиынтығы, кросс-функционалды топ (тестерлер мен бағдарламашылар бір-бірінің жұмысын көптеген жолдармен орындай алады).
Тестілеуге байланысты стандарттар
Компьютерлер кеңінен таралған қолдану аймақтарында пайдаланылады және олардың дұрыс жұмыс істеуі бизнеске және адамның қауіпсіздігіне өте маңызды. Сондықтан жоғары сапалы бағдарламалық өнімдерді әзірлеу немесе таңдау өте маңызды. Бағдарламалық жасақтаманың сапасын кешенді түрде бағалау және тиісті сапаны қамтамасыз етудің маңызды факторы болып табылады. Бұған бағдарламалық өнімді пайдалану мақсатына қарай тиісті сапа сипаттамаларын анықтау арқылы қол жеткізуге болады. Мақұлданған немесе кеңінен танылған индикаторларды қолдана отырып, мүмкіндігінше бағдарламалық өнімнің әрқайсысының тиісті сапалық сипаттамасы көрсетілуі және бағалануы маңызды.
ISO / IEC 9126 (1991): Бағдарламалық өнімді бағалау. Осы қажеттіліктерді қолдау үшін әзірленген сапалық сипаттамалар мен оларды пайдалану бойынша ұсынымдар алты сапа сипаттамасын анықтады және бағдарламалық өнімдерді бағалау процесінің үлгісін сипаттады.
Әрбір сапа сипаттамасы (мысалы, бейімделу) одан әрі атрибуттарға бөлінеді. Атрибут — бағдарламалық өнімде тексеруге немесе өлшеуге болатын нысан. Атрибуттар стандартта анықталмайды, себебі олар әртүрлі бағдарламалық өнімдермен ерекшеленеді.
Бағдарламалық өнім кең мағынада анықталады: ол орындалатын файлдарды, бастапқы кодты, архитектуралық сипаттамаларды және т. б. қамтиды. Нәтижесінде пайдаланушы тұжырымдамасы операторларға, сондай-ақ бағдарлама кітапханалары сияқты құрамдастардың пайдаланушылары болып табылатын бағдарламашыларға қолданылады.
Бұл стандарт ұйымдардың бағдарламалық өнімдердің сапалы үлгісін анықтау үшін негіз болып табылады. Сонымен бірге, ол әрбір ұйымға өз үлгісін нақты анықтау үшін қалдырады. Мұны, мысалы, сапа атрибуттарының қолжетімділік дәрежесін бағалайтын сапа шаралары үшін мақсатты мәндерді көрсету арқылы жасауға болады.
БҚ тестілеу түрлері
Тестілеу түрлерін жіктеуге әдеттегідей бірнеше белгілер бар. Әдетте төмендегілер ерекшеленеді.
– Объект бойынша тестілеу;
– Жүйенің ішкі құрылымын білу бойынша;
– Автоматтандыру дәрежесі бойынша;
– Оқшаулау дәрежесі бойынша;
– Уақыт бойынша тестілеу;
– Сценарийлердің позитивтілігінің негізінде;
– Тестілеуге дайындық дәрежесі бойынша.
Функционалдық тестілеу алдын-ала анықталған мінез-құлықты қарастырады және тұтастай алғанда немесе жүйенің функционалдық ерекшелігін талдауға негізделген.
Функционалдық тестілер жүйенің функцияларына негізделеді және тестілеудің барлық деңгейінде (компонент, интеграция, жүйе, қабылдау) орындалуы мүмкін. Әдетте, бұл функциялар талаптарға, функционалдық ерекшеліктерге немесе жүйені пайдалану жағдайларында сипатталады.
Бағдарламалық жасақтамадағы өнімділікті тестілеу — компьютерлік жүйенің немесе оның бір бөлігінің қандай да бір жүктемеде қаншалықты жылдам жұмыс істейтінін анықтау үшін жүргізілетін тест. Ол сондай-ақ масштабталу, сенімділік және ресурс тұтынуы сияқты жүйелік сапаның басқа атрибуттарын тексеруге және растауға қызмет етеді.
Өнімділікті тестілеу — информатика саласында өнімділік техникасы саласында жұмыс жасаудың негізгі бағыттарының бірі, ол кодтаудың негізгі кезеңінің басталуына дейін модельдеу және жүйелік жобалау кезеңінде өнімділікті есепке алуға ұмтылады.
Өнімділікті тестілеу кезінде келесі салалар ерекшеленеді:
Жүктемені тексеру — өнімділікті тестілеудің қарапайым түрі. Жүктемені сынау әдетте күтілетін жүктеме бойынша бағдарламаның әрекетін бағалау үшін жасалады. Бұл жүктеме, мысалы, уақыт аралығындағы транзакциялардың нақты санын орындайтын, қолданбаның бір уақытта пайдаланушылардың күтілетін санын қамтуы мүмкін. Бұл тестілеу әдетте барлық маңызды бизнес-транзакциялардың жауап беру уақытын алуға мүмкіндік береді. Деректер базасын, қосымшалар сервисін, желіні және т. с.с. бақылаған жағдайда тесттің бұл түрі кейбір қосымшалардағы тартыстарды анықтай алады.
Стресс-тестілеу, әдетте, қосымшаның өткізу жолағының шекараларын түсіну үшін қолданылады. Бұл сынақ төтенше немесе теңестірілмеген жүктемелер кезінде жүйенің сенімділігін анықтау үшін және ағымдағы жүктеме күтілетін максимумнан айтарлықтай асып кетсе, жеткілікті жүйе өнімділігі туралы сұрақтарға жауап береді.
Тұрақтылықты тестілеу қосымшаның күтілген жүктемені ұзақ уақытқа төтеп бере алатынын қамтамасыз ету үшін жүргізіледі. Мұндай тестілеу жүргізілгенде, қолданбадағы жадты пайдалану ықтимал ағып кетулерді анықтау үшін бақыланады. Сонымен қатар, мұндай тестілеу өнімділіктің нашарлауын анықтайды, бұл өңдеу жылдамдығының төмендеуіне және / немесе сынақтың басталуымен салыстырғанда ұзақ жұмысдан кейін қолданудың жауап уақытының көбеюіне әкеледі.
Конфигурация тестілеуі — дәстүрлі өнімділік тестілеуінің басқа түрі. Бұл жағдайда жүйенің жұмысын қолданбалы жүктеме тұрғысынан тестілеудің орнына өнімділіктің әсері конфигурацияда өзгереді. Осындай тестілеудің жақсы мысалы жүктемені теңестірудің әр түрлі әдістерімен тәжірибе болуы мүмкін. Конфигурацияны тестілеу жүктемелік, стресті немесе тұрақтылықты сынаумен біріктірілуі мүмкін.
Юзабилити тесті — өнім белгілі бір мақсаттарға жету үшін тиісті тиімділік, тиімділік және қанағаттану дәрежесі бар белгілі бір контекстте өнім пайдаланылатын дәреже. Пайдалану мүмкіндігі соңғы пайдаланушылардың бағдарламалық жасақтаманың қолданылу дәрежесін көрсетеді. Пайдаланушы мен бағдарламалық жасақтама өзара әрекеттесуді пайдаланушы интерфейстері арқылы жүзеге асырғандықтан, қолданылатын тұжырымдама ең алдымен пайдаланушы интерфейстерін дамыту процесіне қатысты болады.
GUI-ті тестілеу тестілеудің қосымшасынан жүйенің графикалық пайдаланушы интерфейсін тексеру процесі болып табылады. GUI-ті тексеру — экранның басқару элементтерімен, мысалы, мәзір түймелерін, белгішені және барлардың барлық түрлерін — құралдар тақталарын, мәзір жолақтарын, диалогтық терезені және тағы басқаны тексеруді қамтиды. Интерфейсті
тестілеу — қосымшаның немесе оның компоненттерінің интерфейстерін тестілеуге бағытталған тестілеу. ISTQB-глоссарий бойынша тестілеудің осы түрі интеграционды тестілеуге жатады және қолданбалы бағдарламалау интерфейсі(API testing) және командалық жол интерфейсі (CLI) тестілеуі ретінде әрекет ете алады. Алайда көптеген дереккөздер интерфейсті тестілеуден және пайдаланушы интерфейсін тікелей тестілеуден (GUI тестілеуден) өтуді ұсынады.Қауіпсіздікті тестілеу — әртүрлі шабуылдарға бағдарламалық қамтамасыз етудің осалдығын бағалау.
Үйлесімділікті тестілеу — өнімнің белгілі бір ортасында дұрыс жұмыс істеуін тексеру болып табылатын функционалды емес тестілеудің бір түрі.
Қара жәшікті тестілеу кезінде сынаушы бағдарламаға тек тұтынушы немесе пайдаланушы сияқты интерфейстер арқылы немесе басқа компьютерге немесе басқа процесті сынау үшін жүйеге қосылуға мүмкіндік беретін сыртқы интерфейстер арқылы қол жеткізе алады. Мысалы, тестілеу құрамдас іс жүзінде осы оқиғалар нақты пернесін басып тұрыңыз және тінтуірдің сол сияқты жауап себеп деп, егер барлық жақсы өтеді деп сеніммен өзара іс-қимыл процестердің механизмін көмегімен бағдарламаны тексеру үшін пернелерін немесе тінтуірдің түймелерін басуға болады. Әдетте, қара жәшікті тестілеу жүйеге қойылатын талаптарды сипаттайтын спецификацияларға немесе басқа құжаттарға сәйкес жүргізіледі. Әдетте, осы типтегі тестілеуде қамту критерийі талаптарды қамтитын және модельді қамтитын (модельді тестілеуде) кіріс деректерінің құрылымын жабудан тұрады.
Ақ жәшікті (мөлдір жәшік деп те аталады) тестілеу кезінде тест әзірлеушісі бағдарламалардың бастапқы кодын қол жеткізе алады және сыналатын бағдарламалық жасақтама кітапханасымен байланысты кодты жаза алады. Бұл компонент тестілеуіне тән, жүйенің тек кейбір бөліктері ғана сыналады. Ол құрылымның құрамдас бөліктері белгілі бір деңгейде жұмыс істейтін және тұрақты болуын қамтамасыз етеді. Ақ жолақты тестілеу кезінде кодты қамту ауқымдары немесе мутация сынақтары қолданылады.
Сұр жәшікті тестілеу кезінде әзірлеуші бастапқы коды қол бар, бірақ тесттерді іске асыру код, әдетте, талап етілмейді.
Қолмен тестілеу — тестілеу жағдайларын автоматтандыру құралдарын қолданбастан адам қолмен жүргізетінін тексеру. Төзімділік, байқау, шығармашылық, стандартты емес эксперименттер жасау мүмкіндігі, сондай-ақ «жүйенің ішінде», яғни «жүйенің ішінде» не болып жатқанын көре білу және түсіну қабілеті сияқты, белгілі бір уақыттарда тестерлерден қарапайым, қолдануға сыртқы әсерлер оның ішкі процестеріне айналды.
Бағдарламалық жасақтаманы автоматтандырылған тестілеу бағдарламалық қамтамасыз етуді әзірлеу процесінің сапасын бақылау кезеңінде тестілеу процесінің бір бөлігі болып табылады. Ол тестілеуді орындау және тестілеу уақытын қысқартуға және оның процесін жеңілдетуге көмектесетін орындау нәтижелерін тексеру үшін бағдарламалық құралдарды пайдаланады.
Тестілеуге жартылай автоматтандырылған тестілеу — адам және компьютер қатысады.
Компонентті тестілеу — тестілеу үшін ықтимал ықтимал компоненттерді, мысалы, бөлек класты немесе функцияны тестілеу. Көбіне компоненттерді бағдарламалық жасақтама әзірлеушілер тексереді.
Интеграциялық тестілеу — интерфейстер компоненттер, кіші жүйелер немесе жүйелер арасында тексеріледі. Егер осы кезеңде уақыттық резерв бар болса, онда тестілеу келесі жүйенің біртіндеп қосылуымен итерационды жүзеге асырылады.
Регрессиялық тестілеу (латын regressio ағылшын regression testing — кері қозғалысы) — бағдарламалық қамтамасыз тестілеу барлық түрлері үшін ұжымдық атауы, бастапқы кодты бұрын сынақтан бөліктерінде қателер анықтауға бағытталған. Мұндай қателер — бағдарламадағы өзгерістер жұмыс істемей қалса, жұмыс істеуі — бұл регрессиялық қателер деп аталады.
Модульді тестілеу (unit testing, module testing, component testing) басқа да ұқсас бөліктерден оқшаулануға болатын қолданбаның жеке бөліктерін сынауға бағытталған. Бұл тест орындау кезінде сынып жекелеген функцияларын немесе әдістерін, сыныптар өздері, сынып, шағын кітапхана, қолданудың кейбір бөліктерінің өзара іс-қимылды сынақтан болады. Жиі, бұл тестілеу түрін арнайы технологиялар мен құралдар, тест автоматтандыру, қатты тиісті сынақ жағдайларда дамуына жеңілдетеді және тездетеді пайдаланып жүзеге асырылады.
Көп жағдайларда тегін және ашық бағдарламалық қамтамасыз ету үшін альфа-тестілеу сатысы кодтың функционалды мазмұны, ал бета-тестілеу қатені түзету кезеңі болып табылады. Сонымен қатар, әдетте, дамудың әр кезеңінде соңғы пайдаланушыларға жұмыс нәтижесі аралық болады.
Ақ жәшік тестілеуі және қара жәшік тестілеуі — код орындалады деп болжайды, және айырмашылығы тек тестілеуші иеленген ақпарат болып табылады. Екі жағдайда да бұл динамикалық тестілеу.
Статикалық тестілеу кезінде бағдарлама коды орындалмайды — бағдарламаны талдау арнайы құралдармен қолмен есептелетін немесе талданатын бастапқы кодқа негізделеді. Кейбір жағдайларда дереккөз емес, аралық код.5 (мысалы, MSID-дегі код немесе код) талданады.
Сондай-ақ статикалық тестілеу талаптарды, спецификацияларды, құжаттаманы тестілеуді қамтиды.
Тестілік сценарийлер
Тестерлер түрлі деңгейлердегі тестілік сценарийлерді пайдаланады: құрамдас ретінде де, интеграция және жүйелік тестілеу. Тесттік сценарийлер, әдетте, сәтсіздіктің ықтималдығы ең көп болатын немесе уақыт бойынша табылған қате қымбат болуы мүмкін компоненттерді тексеру үшін жазылады.
«Альфа» және «бета» (тестілеу әдістері бойынша тестілеу қоғамдастықтың көлемі мен шектеулеріне, жанама, және т. б.) өнім шығарғанға дейін кезеңдерде орындалса, «ақ жәшікті» және «қара жәшікті» тестілеу жолдары арқылы тестерлер көздеген мақсатқа жетеді.
Бета-тестілеу әдетте қара жәшіктің әдісімен шектеледі. Осылайша, «бета-тестілеу» термині бағдарламаның күйін көрсете алады, не ол тестерлердің белгілі бір тобын және осы топ жүзеге асыратын процесті көрсетуі мүмкін. Яғни, бағдарлама қазірдің өзінде «бета-кезеңде» болғанымен, ол тестілеуді жалғастыра алады, бірақ бұл жағдайда ол «бета» сынағының бөлігіне жатпайды.
Жіктелудің бұл түрі жасанды болып табылады, өйткені «ішіндегі» ол белгілі бір құралдар мен жеке әдістерді қолдана отырып, қолданбаның тиісті функцияларына және ерекшеліктеріне ғана назар аудара отырып, осы контексте ерекшеленетін бірдей тестілеу түрлері туралы болады.
Веб-қосымшалардың тестілеуі үйлесімділік тестілеу (атап айтқанда — кросс-браузерді тестілеу), өнімділікті тестілеу, құралдардың кең ауқымын пайдалана отырып, тестілеуді автоматтандыру саласында қарқынды жұмыс жасауды қамтиды.
Ұялы қосымшаларды тестілеу ақ үйлесімділік тестілеуіне, өнімділікті оңтайландыруға (клиенттің энергияны тұтынуды төмендету бөлігін қоса алғанда), мобильді құрылғылардың эмуляторларын пайдалану арқылы автоматтандыруды сынауды қажет етеді.
Үстелдік қосымшаларды тестілеу — бұл жіктеуде тізімделгендердің ішіндегі ең классикалық сипаты және оның ерекшеліктері қолданба доменіне, сәулет өнерінің нюанстарына, негізгі сапа көрсеткіштеріне және т. б. байланысты.
Бұл жіктеуді ұзақ уақыт бойы жалғастыруға болады. Мысалы, консольдық қосымшаларды тестілеуді және қосымшаларды GUI-қосымшаларымен тестілеуді, серверлік қосымшаларды тестілеуді, клиенттік қосымшаларды тестілеуді және т. б. қоса тестілеуді жеке қарастыра аламыз.
Классификацияның бұл түрі жасанды болып табылады және тек өтінімнің бөлек бөлігіне назар аударуды көрсетеді.
Таныстыру деңгейін тестілеу «сыртқы әлеммен» (екі пайдаланушы және басқа бағдарламалар) өзара әрекеттесуге жауапты қосымшаның бөлігіне шоғырланған. Мұнда пайдаланудың қарапайымдылығы, интерфейстің жылдамдығы, браузерлермен үйлесімділігі, интерфейстер жұмысының дұрыстығына қатысты мәселелер зерттелді.
Деректер деңгейін тестілеу деректерді сақтауға және кейбір деректерді өңдеуге (көбінесе дерекқорда немесе басқа сақтау қоймаларында) жауапты қосымшаның бөлігіне шоғырланған. Мұнда ерекше қызығушылық — деректерді тестілеу, бизнес ережелеріне сәйкестігін тексеру, тестілеуді орындау.
Тестілеу жағдайлары бойынша тестілеу алдын-ала дайындалған сынақ жағдайлары, тест тапсырмаларының жиынтығы және басқа да құжаттамалар негізінде орындалатын формалды тәсіл болып табылады. Бұл тестілеудің ең кең таралған әдісі, ол сонымен қатар процесті қатаң жүйелендіру, метриканы пайдаланудың қарапайымдылығы және онжылдықтарда әзірленген ұсыныстардың кең спектрі арқасында қолданбалы зерттеулердің максималды толықтығына қол жеткізуге мүмкіндік береді.
Зерттеу тестілеуі — ішінара ресімделген тәсіл болып табылады, онда тестерлер таңдалған сценарийге өтініммен жұмыс жасайды, бұл өз кезегінде өтінімді толығымен зерделеу үшін іске асыру процесінде жетілдіріледі. Зерттеуді тестілеуде табысқа жетудің кілті — бұл дисфункционалды, ойластырылмайтын операцияларды жасау емес, сценарий бойынша жұмыс жасау. Сессияға негізделген тест деп аталатын арнайы сценарий әдісі де бар. Сценарийлерге балама ретінде, қолданбада әрекеттерді таңдағанда, бақылау тізімдері кейде пайдаланылуы мүмкін, содан кейін бұл тестілеу тест тізіміне негізделген сынақ деп аталады.
Әдебиеттер:
- Святослав Куликов. Тестирование программного обеспечения. Базовый курс EPAM Systems, 2015–2016. — 289 с.
- Сайт Selenium [Электронный ресурс] Режим доступа открытый, URL: https://www.seleniumhq.org/ (22.05.2018)
- Форум [Электронный ресурс] Режим доступа открытый, URL: http://automated-testing.info/ (21.05.2018)
- Kolawa, Adam; Huizinga, Dorota (2007). Automated Defect Prevention: Best Practices in Software Management. Wiley-IEEE Computer Society Press. p. 74. ISBN 0–470–04212–5.
- «Proceedings from the 5th International Conference on Software Testing and Validation (ICST). Software Competence Center Hagenberg. «Test Design: Lessons Learned and Practical Implications».
- Brian Marick. «When Should a Test Be Automated?". StickyMinds.com. Retrieved 2009–08–20.
