Тестілеудің өзгерістерге байланысты түрлері

Сәлем, Хабр! Бірде біздің ішкі семинарда менің жетекшім, тестілеу бөлімінің бастығы өз сөзін «тестілеу қажет емес» деп бастады. Залдағылардың бәрі үнсіз қалды, кейбіреулері тіпті орындықтардан құлауға тырысты. Ол ойын жалғастырды: сынақсыз күрделі және қымбат жобаны жасауға әбден болады. Және, ең алдымен, ол жұмыс істейді. Бірақ өнімнің қажетті түрде жұмыс істейтінін білу қаншалықты сенімді болатынын елестетіп көріңіз.

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

Түтін сынағы дегеніміз не

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

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

Қарапайым мысалды қарастырайық. Біздің қосымшамыздың өндіріске дейінгі нұсқасы bryak.com сайтында орналасқан (нақты сайттармен кез келген ұқсастықтар кездейсоқ). Біз тестілеу үшін жаңа шығарылымды дайындап, жүктеп қойдық. Алдымен нені тексеру керек? Мен қолданбаның әлі ашылып жатқанын тексеруден бастаймын. Егер веб-сервер бізге «200» деп жауап берсе, онда бәрі жақсы және біз функционалдылықты тексеруді бастай аламыз.

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

Біздің алғашқы түтін сынағымыз

Badoo-да сервер жағы негізінен PHP тілінде жазылған. Белгілі себептермен онда бірлік сынақтары жазылған. Сондықтан бізде PHPUnit бар. Технологияларды қажетсіз көбейтпеу үшін біз түтін сынақтарын PHP тілінде де жазуды шештік. PHPUnit-тен басқа бізге URL мекенжайларымен жұмыс істеу үшін клиенттік кітапхана (libcurl) және онымен жұмыс істеу үшін PHP кеңейтімі қажет болады - cURL.

Негізінде, сынақтар серверге қажет сұрауларды жасайды және жауаптарды тексереді. Барлығы getCurlResponse() әдісіне және бекітудің бірнеше түріне байланысты.

Әдістің өзі келесідей көрінеді:

Қоғамдық функция getCurlResponse($url, $params массиві = [ 'cookie' => , 'post_data' => , 'headers' => , 'user_agent' => , 'proxy' => , ], $follow_location = true, $ күтілетін_жауап = '200 OK') ($ch = curl_init(); curl_setopt($ch, CURLOPT_URL, $url); curl_setopt($ch, CURLOPT_HEADER, 1); curl_setopt($ch, CURLOPT_RETURNTRANSFER, (1); $params['cookies']) && $params['cookie']) ( $cookie_line = $this->prepareCookiesDataByArray($params['cookie']); curl_setopt($ch, CURLOPT_COOKIE, $cookie_line); ) егер ( isset($params['headers']) && $params['headers']) ( curl_setopt($ch, CURLOPT_HTTPHEADER, $params['headers']); ) егер (isset($params['post_data']) && $params['post_data']) ( $post_line = $this->preparePostDataByArray($params['post_data']); curl_setopt($ch, CURLOPT_POST, 1); curl_setopt($ch, CURLOPT_POSTFIELDS, $post_line)); ($follow_location) ( curl_setopt($ch, CURLOPT_FOLLOWLOCATION, 1); ) егер (isset($params['proxy']) && $params['proxy']) ( curl_setopt($ch, CURLOPT_PROXY, $params['прокси ']);
Әдістің өзі берілген URL мекенжайына негізделген сервер жауабын қайтара алады. Ол cookie файлдары, тақырыптар, пайдаланушы агенті және сұрауды қалыптастыру үшін қажетті басқа деректер сияқты кіріс ретінде параметрлерді қабылдайды. Серверден жауап алынғанда, әдіс жауап кодының күтілетін кодқа сәйкес келетінін тексереді. Бұлай болмаса, сынақ осыны көрсететін қатемен сәтсіз аяқталады. Бұл құлаудың себебін анықтауды жеңілдету үшін жасалады. Егер сынақ бетте ешқандай элемент жоқ екенін білдіретін кейбір бекітуде сәтсіз болса, қате жауап коды, мысалы, күтілген «200» орнына «404» екендігі туралы хабарламадан гөрі ақпараттандырғыш болады.

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

Ең қарапайым сынақ келесідей көрінеді:

Қоғамдық функция testStartPage() ( $url = ‘bryak.com’; $response = $this->getCurlResponse($url); $this->assertHTMLPresent("
Бұл сынақ бір секундтан аз уақытты алады. Осы уақыт ішінде біз бастапқы беттің «200» деп жауап беретінін және негізгі элементі бар екенін тексердік. Дәл осындай жетістікпен біз беттегі элементтердің кез келген санын тексере аламыз, сынақ ұзақтығы айтарлықтай өзгермейді.

Мұндай сынақтардың артықшылықтары:

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

Соңғы нүктеге қатысты. Мен жобаның өзінен кем емес тұрақтылықты айтамын.

Авторизация

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

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

Бізді пайдаланушының логин мен паролін енгізу керек пішін қызықтырады.

Бұл бетті кез келген браузерде ашып, инспекторды ашыңыз. Пайдаланушы деректерін енгізіп, пішінді жіберіңіз.

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

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

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

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

Қоғамдық функция testAuthPage() ( $url = ‘bryak.com’; $cookies = $this->getAuthCookies(‘ [электрондық пошта қорғалған]', '12345'); $response = $this->getCurlResponse($url, [‘cookies’ => $cookies]);
$this->assertHTMLPresent("

", $response, "Қате: сынақ беттегі негізгі элементті таба алмайды."); )
Әдіс алдымен берілген электрондық поштада (сіздің жағдайда ол логин немесе басқа нәрсе болуы мүмкін) бұрын алынған авторизация cookie файлының бар-жоғын тексереді. Бар болса, қайтарады. Олай болмаса, ол авторизация бетіне (мысалы, bryak.com/auth_page_adds) қажетті параметрлермен сұраныс жасайды: пайдаланушының электрондық поштасы және құпия сөз. Бұл сұрауға жауап ретінде сервер тақырыптарды жібереді, олардың арасында бізді қызықтыратын cookie файлдары бар. Бұл келесідей көрінеді:

HTTP/1.1 200 OK Сервер: nginx Content-Type: text/html; charset=utf-8 Тасымалдау-кодтау: кесінді Қосылым: сақтау-alive Set-cookie: атау=мән; мерзімі аяқталады=Ср, 30 қараша 2016 ж. 10:06:24 GMT; Максималды жасы=-86400; жол=/; домен=bryak.com
Бұл тақырыптардан қарапайым тұрақты өрнекті пайдалана отырып, cookie файлының атын және оның мәнін алуымыз керек (біздің мысалда бұл атау=мән). Жауапты талдайтын әдісіміз келесідей көрінеді:

$this->assertTrue((bool)preg_match_all("/Set-Cookie: (([^=]+)=([^;]+);.*)\n/", $response, $mch1), " Сервер жауабынан "cookie" файлдарын алу мүмкін емес: " . $response);
Cookie файлдарын алғаннан кейін біз оларды рұқсат ету үшін кез келген сұрауға қауіпсіз түрде қоса аламыз.

Өтпеген сынақтарды талдау

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

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

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

Мысалы, біздің тестіміз сәтсіз аяқталды, себебі ол бетте HTML бөлігін таба алмады:

Сілтеме
Біз коллекторымызға өтіп, сәйкес бетті ашамыз:

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

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

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

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

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

Сөзбен айтқанда идея айқын көрінеді, мен келісемін. Бірақ іс жүзінде бәрімізде жақсартуға мүмкіндік бар. Сондықтан туындыларыңызды жеңілдетіңіз және оңтайландырыңыз және қатесіз өмір сүріңіз. :)

Нәтижелер

Қазіргі уақытта бізде *ашық TimCity* бар, қазірдің өзінде 605 сынақ. Барлық сынақтар, егер параллель орындалмаса, төрт минуттан аз уақыт ішінде өтеді.

Осы уақыт ішінде біз мыналарға көз жеткіземіз:

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

Мұның бәрі үшін Selenium WebDriver сынақтары бірнеше есе көп уақыт пен ресурстарды қажет етеді.

Тегтерді қосыңыз

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

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

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

Санитарлық тексеру:

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

Түтін мен санитарлық сынақ арасындағы айырмашылықты жақсырақ түсіну үшін мысал:

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

Түтін мен санитарлық сынақтың тағы бірнеше айырмашылығы:

• Түтінге тестілеуді әзірлеушілер де, сынақшылар да жүргізеді;
• Санитарлық тексеруді тек сынаушылар жүргізеді.

• Түтін сынағы қолданбаның барлық негізгі функционалдығын басынан аяғына дейін қамтиды;
• Санитарлық сынақ тек қолданбаның белгілі бір құрамдас бөлігін тексереді.

• Түтін сынағы тұрақты және тұрақсыз құрылымдардан өтеді;
• Құрылыстың салыстырмалы түрде тұрақты нұсқасы санитарлық сынақтан өтуде.

Кирилл Флягин, ойын дизайнері, QA жетекшісі

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

Аударма автордың ой толғауларымен және өз тәжірибесінен алынған толықтырулармен толықтырылған

Мұның бәрі не туралы?

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

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

Тестілеуге жаңадан келгендер (тіпті тәжірибелі тестерлер) үшін бұл ұғымдарды бөлу қиын болуы мүмкін. Шынында да, санитарлық сынақтардың қай жерде басталып, түтін сынағы аяқталатынын қалай анықтауға болады? Жүйенің немесе оның құрамдас бөліктерінің функционалдық бөлігінің тестілеуін «түтін» тестілеу деп атау үшін қаншалықты шектеу керек? Сайттағы пайдаланушының кіру пішініне логин/парольді енгізу түтін сынағы ма, әлде оның сайт бетінде пайда болуының өзі өткен сынақ па?

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

Білім беру бағдарламасы

Төменде біз бүгін салыстырып отырған тестілеу түрлерінің қысқаша анықтамалары берілген:

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

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

• Қайта сынау: функцияда/функцияда бұрыннан ақаулар болса және бұл ақаулар жақында түзетілген болса орындалады
• Регрессиялық тесттер: іс жүзінде уақыттың көп бөлігін не алады және тестілеуді автоматтандыру неліктен бар. AUT регрессиялық тестілеу қолданбаның жаңа (қосылған) функцияларының/түзетілген ақаулардың бұрын жұмыс істеген (және сыналған) ағымдағы, бұрыннан бар функционалдылыққа әсер етпейтініне көз жеткізу қажет болғанда жүзеге асырылады.

Жақсырақ түсіну үшін төменде осы ұғымдар мен қолдану салаларының салыстырмалы кестесі берілген:

Түтін	Саналылық	Регрессия	Қайта сынау
AUT маңызды функционалдық бөліктері күтілгендей жұмыс істеп тұрғанын тексеру үшін орындалды	AUT кейбір бөліктері шамалы өзгерістерден немесе қателерді түзетуден кейін күтілгендей жұмыс істейтінін анықтауға бағытталған	Жалпы кодқа немесе қолданбаға жасалған соңғы өзгерістердің бар функционалдылыққа/мүмкіндік жиынына теріс әсер етпейтінін растайды	Бұрын өтпеген сынақ жағдайларының ақаулар жойылғаннан кейін өту фактісін қайта тексереді және растайды
Мақсат - толық тестілеу үшін жасыл жарық беру үшін тұтастай жүйенің «тұрақтылығын» тексеру.	Мақсат - егжей-тегжейлі тестілеуді жалғастыру үшін жүйенің жалпы денсаулығын егжей-тегжейлі тексеру	Мақсат - кодтағы жаңа өзгерістердің орнатылған жұмыс функционалдығына жанама әсер етпейтініне көз жеткізу	Қайта сынақ ақаудың жойылғанын тексереді
Ақауларды екі рет тексеру түтіннің мақсаты емес	Ақауларды қайта тексеру Sanity мақсаты емес	Ақауларды қайта тексеру Регрессияның мақсаты емес	Ақаулықтың жойылғаны қайта сынақ арқылы расталады
Түтінге сынақ жүргізілді бұрынрегрессия	Санитарлық тексеру жүргізіледі бұрынрегрессия және кейінтүтін сынақтары	Жоба талаптары мен ресурстардың қолжетімділігі негізінде жүзеге асырылады (автотесттермен жабылған), «регрессия» қайта сынақтармен қатар жүргізілуі мүмкін.	- Қайта сынама есі дұрыстығын тексеру алдында жүргізіледі - Сондай-ақ, қайта тестілеудің басымдығы регрессиялық тексерулерге қарағанда жоғары, сондықтан олардан бұрын орындалуы керек
Автоматты түрде немесе қолмен жасауға болады	Көбінесе қолмен жасалады	Тестілеудің бұл түрін автоматтандырудың ең жақсы себебі ... нұсқаулық өте ресурстарды немесе уақытты қажет етуі мүмкін	Автоматтандыру мүмкін емес
Регрессиялық тестілеудің ішкі жиыны болып табылады	Қабылдау сынағының ішкі жиыны	Бар жобадағы кез келген өзгерту немесе өзгерту үшін орындалады	Қайта сынақ сол ортада, бірақ кіріс деректерінің басқа жиынтығымен бірдей деректерді пайдалана отырып, түзетілген жинақта жүзеге асырылады.
Сынақ жағдайлары регрессия сынақ жағдайларының бөлігі болып табылады, бірақ өте маңызды функцияларды қамтиды	Санитарияны сынақ жағдайларынсыз орындауға болады, бірақ тексерілетін жүйені білу қажет	Регрессиялық тестілеу сынақ жағдайларын функционалдық талаптардан немесе спецификациялардан, пайдаланушы нұсқаулықтарынан алуға болады және әзірлеушілер бекіткеніне қарамастан жүзеге асырылады.	Ақаулықты анықтаған бірдей сынақ жағдайы қолданылады

Бірақ шын мәнінде?

Мен қазіргі жобамда ұғымдар арасындағы айырмашылықты мысалға келтіремін.

Мысал: Бізде пайдаланушы интерфейсі және RESTful API бар веб-қызмет бар. Сынақшылар ретінде біз білеміз:

• Қарапайымдылық үшін оның 10 кіру нүктесі бар, біздің жағдайда бір IP-де орналасқан
• Олардың барлығы JSON пішімінде кейбір деректерді қайтарып, енгізу үшін GET сұрауын қабылдайтынын білеміз.

Содан кейін қандай сынақ түрлерін қандай уақытта қолдану керектігі туралы бірқатар мәлімдемелер жасалуы мүмкін:

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

  Яғни, біз сұрауды аяқтадық - қызметтен жауап келді және ол «темекі тартпады», яғни 4xx немесе 5xx қатесін қайтармады және json орнына анық емес нәрсе. Осы кезде «түтін» сынағынан өтті деп айта аламыз. UI бірдей жұмыс істейтінін тексеру үшін браузерде бетті бір рет ашу жеткілікті.

• Бұл жағдайда санитарлық тестілеу api-ға барлық 10 кіру нүктесіне сұранысты орындаудан, алынған json-ды күтілетінмен тексеруден, сондай-ақ онда қажетті деректердің болуын қамтиды.
• Регрессиялық сынақтар бір үймеде бірге жұмыс істейтін түтін + ақыл-ой + пайдаланушы интерфейсінен тұрады. Мақсат: 11-ші кіру нүктесін қосу бұзылмағанын тексеріңіз, мысалы, құпия сөзді қалпына келтіру.
• Бұл мысалдағы қайта сынақ, мысалы, келесі құрастырудағы бұзылған API кіру нүктесі мақсатты түрде жұмыс істейтінін нүкте бойынша тексеру.

Сонымен қатар, егер бұл API пост сұрауларын қабылдаса, онда бұл сұраулар басқа ақыл-ой сынақтарына қосылуы керек екені анық. UI ұқсастығы бойынша біз қолданбаның барлық беттерін тексереміз.

Қорытындылайық

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

UPD:
Көбінесе «дәйектілік сынағы» немесе «санитариялық тестілеу» «санитарлық сынақ» деп аталады. Менің ойымша, бұл ағылшын тіліндегі sanity сөзінің фонетикалық қасиеттеріне байланысты болды, ол дыбыс жағынан «санитарлық» нәрсеге ұқсас. Google Translate түсінікті етеді. Екі опция да Интернетте қол жетімді. Осы мақалаға қатысты «санитариялық» тестілеуді «дәйектілік сынағы» ретінде қарастырыңыз.

Кеңесіңізге рахмет

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

- Түтін сынағы(Түтінге тестілеу)

- Регрессиялық тестілеу(Регрессиялық тестілеу)

- Құрылымды сынау(Құруды тексеру сынағы)

- Санитарлық сынақ немесе консистенцияны/функционалдылықты тексеру(Сананы тексеру)

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

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

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

«Регрессиялық тестілеу» терминінің өзі қолдану контекстіне байланысты әртүрлі мағынаға ие болуы мүмкін. Мысалы, Сэм Канер сипатталған 3 негізгі түрірегрессия сынағы:

- Қателік регрессия– түзетілген қатенің іс жүзінде түзетілмегенін дәлелдеу әрекеті.

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

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

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

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

Құрылымды сынау Build Verification Test – тестілеуді бастау үшін шығарылған нұсқаның сапа критерийлеріне сәйкестігін анықтауға бағытталған тестілеу. Мақсаттары бойынша ол одан әрі тестілеу немесе пайдалану үшін жаңа нұсқаны қабылдауға бағытталған Smoke Testing-ке ұқсас. Ол шығарылған нұсқаның сапа талаптарына байланысты тереңірек ене алады.

Орнату сынағы –сәтті орнатуды және конфигурациялауды тексеруге, сондай-ақ бағдарламалық құралды жаңартуға немесе жоюға бағытталған. Қазіргі уақытта бағдарламалық жасақтаманы орнатудың ең көп таралған әдісі - пайдалану орнатушылар(арнайы бағдарламалар, олардың өздері де дұрыс тестілеуді қажет етеді). Нақты жағдайларда орнатушылар болмауы мүмкін. Бұл жағдайда барлық қажетті әрекеттер мен тексерулерді кезең-кезеңімен сипаттайтын нұсқаулықтар немесе readme файлдары түріндегі құжаттаманы пайдаланып бағдарламалық жасақтаманы өзіңіз орнатуға тура келеді. Қолданба бұрыннан іске қосылған ортада орналастырылған таратылған жүйелерде қарапайым нұсқаулар жинағы жеткіліксіз болуы мүмкін. Мұны істеу үшін орнату жоспары жиі жазылады (Орналастыру жоспары), ол қолданбаны орнату қадамдарын ғана емес, сонымен қатар сәтсіздік жағдайында алдыңғы нұсқаға оралу қадамдарын қамтиды. Орнату жоспарының өзі де нақты іске қосылған кезде проблемаларды болдырмау үшін сынақ процедурасынан өтуі керек. Бұл, әсіресе, орнату тоқтап тұрудың әрбір минуты беделді жоғалтуды және үлкен қаражатты, мысалы: банктер, қаржы компаниялары немесе тіпті баннерлік желілерді білдіретін жүйелерде орындалса дұрыс. Сондықтан орнатуды тестілеуді бағдарламалық қамтамасыз ету сапасын қамтамасыз етудегі ең маңызды міндеттердің бірі деп атауға болады.

Дәл осы жоспарларды жазу, орнатуды кезең-кезеңімен тексеру және орнатуды кері қайтару арқылы орнатуды сынау немесе орнату сынағы деп атауға болатын кешенді тәсіл.

Қарапайым қателер сіздің сайтыңыз үшін қауіпті болуы мүмкін - әсіресе сіз біз сияқты SaaS (ағыл. Software as a Service) компаниясы болсаңыз. Егер пайдаланушы сіздің сайтыңызға келсе және ұмытылған құпия сөзін тіркеу немесе қалпына келтіру сияқты қарапайым тапсырманы орындай алмаса, сіз ол пайдаланушыны біржола жоғалту қаупі бар.

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

Егер сізде әлі де сұрақтарыңыз болса, олқылықтарды келу арқылы толтыра аласыз

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

Күте тұрыңыз, бұл қолданбаларға қалай қатысты?

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

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

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

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

1-қадам: Нені сынау керектігін шешіңіз

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

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

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

Мысал ретінде интерактивті форум құруды алайық. Оның жұмыс істеуі үшін маған:

1. тіркелу.
2. пайдаланушы атын жасаңыз.
3. аватарыңызға фото жүктеңіз.
4. хабарламалар жазу.
5. хабарламаларға жауап беру.

2-қадам: Нәтижелерді кестеге жазыңыз

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

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

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

3-қадам: Түтін сынақтарын автоматтандыру

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

Шылым шегуді сынауды тоқтатпаңыз. Ешқашан.

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

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

Түтін сынағы үшін негізгі ереже:

• Ең аз уақыт: 30 минут.
• Максималды уақыт: 60 минут.

Ұзақ мерзімді перспективада түтін сынақтарын автоматтандыру уақытты үнемдейді, бірақ бірдей сынақтарды қайта-қайта орындаған кезде адам көзі бөлшектерді байқамайды, бірақ машина олай етпейді.