Мени

Врсте испитивања аутоматизације и неке заблуде

types automation testing

Испробајте Наш Инструмент За Елиминисање Проблема

Научите различите типове тестирања аутоматизације са неким заблудама о аутоматизацији теста:

У овом другом делу серија туторијала о аутоматизацији тестова , Укратко ћу описати врсте аутоматизованих тестова, а затим, што је најважније, разјаснићу неке заблуде о аутоматизацији тестова.

Шта је испитивање аутоматизације?

Тестирање аутоматизације може се дефинисати као начин извођења низа тестова изнова и изнова, без потребе за ручним извршавањем. Увођење тестова аутоматизације у вашу стратегију тестирања начин је да уштедите новац и време.

врсте испитивања аутоматизације

Шта ћете научити:

Врсте испитивања аутоматизације

Врсте тестова за аутоматизацију дефинишу које врсте пакета за тестирање могу бити аутоматизоване. Многи тестери бркају ову тему са типовима оквира за аутоматизацију који одређују како ћете свој тестни пакет дизајнирати у пакет аутоматизације који се може лако извршити.

У овом чланку ћемо пажљиво погледати типове испитивања аутоматизације и на крају ћемо кратко погледати оквире аутоматизације.

Врсте аутоматизације

Хајде да детаљно разумемо горње класификације:

Аутоматизација заснована на врсти испитивања

Аутоматизација функционалних тестова:

Функционални тестови су написани за тестирање пословне логике која стоји иза апликације. Аутоматизација ових писаних скрипти значи потврђивање пословне логике и функционалности која се очекује од апликације.

Аутоматизација нефункционалних испитивања:

Нефункционални тестови дефинишу не-пословне захтеве апликације. То су захтеви који се односе на перформансе, сигурност, базе података итд. Ови захтеви могу остати стални или се могу прилагодити величини софтвера.

Аутоматизација заснована на фази испитивања

Аутоматизација јединичних тестова:

Ови тестови се изводе током саме фазе развоја, у идеалном случају од стране програмера након завршетка развоја и пре предаје система тестерима на тестирање.

Аутоматизација АПИ тестова:

АПИ тестови се изводе током фазе интеграције. Њих може покренути тим за развој или тестирање и могу се покренути пре или након израде слоја корисничког интерфејса за апликацију. Ови тестови циљају тестирање на основу захтева и одговора на којима је изграђена апликација.

Аутоматизација тестова заснованих на корисничком интерфејсу:

Тестови засновани на корисничком интерфејсу се изводе током фазе извршавања теста. Њих посебно врше тестери и покрећу се само једном пре него што им се преда УИ апликације. Они тестирају функционалност и пословну логику апликације са предњег краја апликације.

Аутоматизација заснована на врсти испитивања

Јединствени тестови:

Јединствени тестови су тестови који се граде за тестирање кода апликације и обично су уграђени у сам код. Они циљају стандарде кодирања, на пример како су написане методе и функције.

Ове тестове чешће пишу сами програмери, међутим, у данашњем свету се од тестера аутоматизације такође може тражити да их напишу.

Извршавање ових тестова и без добијања грешака у њима значит ће да ће се ваш код компајлирати и покренути без икаквих проблема са кодом. Ови тестови обично не циљају функционалне аспекте апликације, а како циљају код, прикладније је да их аутоматизујете како би могли да се покрећу како и када то захтева програмер.

Тестови дима:

Тест дима је познати тест изведен у животном циклусу теста. То су тестови након израде, они се извршавају одмах након што се било која изградња изда из апликације како би се осигурало да апликација и даље функционише након завршетка израде.

Ово је мали пакет за тестирање и нешто ће се извршити више пута, па има смисла аутоматизовати га. Ови тестови ће обично бити функционалне природе и у зависности од врсте примене, за њих се може одабрати алат.

АПИ тестови:

АПИ тестирање је постало веома познато у последњих неколико година. Апликације изграђене на АПИ архитектури могу да изврше ово тестирање.

У АПИ тестирању, тестери потврђују пословни слој апликације провером комбинација захтев-одговор за различите АПИ-је на којима је апликација изграђена. АПИ тестови се такође могу обавити као део интеграционих тестова у наставку.

Тестови интеграције:

је мрежни кључ вифи лозинка

Тест интеграције, као што и само име сугерише, подразумева тестирање апликације интегрисањем свих модула и провером функционалности апликације.

Тестирање интеграције може се обавити путем АПИ тестирања или се може извршити путем слоја корисничког интерфејса апликације.

УИ тестови:

УИ тестови се раде из УИ слоја или фронтенда апликације. Они могу циљати тестирање функционалности или једноставно тестирање УИ елемената апликације.

Уобичајена пракса је аутоматизација корисничког интерфејса за тестирање функционалности. Међутим, аутоматизација ГУИ карактеристика једна је од сложенијих аутоматизација.

Регресиони тестови:

како написати план теста

Један од најчешће аутоматизованих тестова је пакет за регресион тест. Регресија је, као што можда већ знате, тест који се врши на крају тестирања новог модула како би се осигурало да ниједан од постојећих модула није на њега утицао.

Понавља се након сваке нове итерације тестирања, а главни случајеви испитивања остају фиксирани са обично неколико нових додатака након нове итерације. Како се често изводи, готово сви тест тимови покушавају да аутоматизују овај пакет.

Аутоматизација као континуирана интеграција:

Непрекидна интеграција се можда поново изводи на самим аутоматизованим регресионим тестовима, међутим, у постизању ЦИ, омогућавамо покретање регресије или идентификованог пакета тестова сваки пут када се изврши нова примена.

Сигурносни тестови:

Испитивање сигурности може бити како функционално, тако и нефункционално тестирање које укључује тестирање апликације на рањивости. Функционални тестови ће се састојати од тестова који се односе на ауторизацију итд., Док нефункционални захтеви могу бити тест за убризгавање СКЛ-а, скриптирање на више локација итд.

Тестови перформанси и контрола квалитета:

Тестови перформанси су нефункционални тестови који циљају захтеве као што су испитивање оптерећења, напрезања, скалабилности апликације.

Тестови прихватања:

Тестови прихватања поново потпадају под функционалне тестове који се обично раде како би се осигурало да ли су испуњени критеријуми прихватања које је дао клијент.

До сада смо описали врсту тестова који се могу аутоматизовати и разне исте класификације, све класификације ће на крају довести до истих крајњих резултата аутоматизованог скупа тестова. Као што смо раније рекли, потребно је мало разумевања како се они разликују од оквира.

Када идентификујете тестове које желите да аутоматизујете из горње класификације, мораћете да дизајнирате своју логику на начин да те тестове извршите глатко, без много ручне интервенције. Оквири улазе у овај дизајн ручног пакета за тестирање у аутоматизовани пакет за тестирање.

Сада ћемо истражити 3 главна типа аутоматизације тестова

  1. Јединствено тестирање
  2. АПИ тестирање
  3. ГУИ тестирање

# 1) Аутоматизована јединична испитивања

Аутоматизовани јединични тестови написани су за тестирање нивоа кода. Грешке се идентификују у функцијама, методама и рутинама које су написали програмери.

Неке компаније траже од програмера да самостално тестирају јединице, а неке ангажују специјализоване ресурсе за аутоматизацију испитивања. Ови ресурси имају приступ изворном коду и пишу јединичне тестове како би разбили производни код.

Због присуства јединичних тестова, кад год се компајлира код, сви јединични тестови се покрећу и говоре нам резултат ако све функције раде. Ако било које јединично тестирање не успе, то значи да је сада присутна грешка у производном коду.

Неки од најпопуларнијих алата присутних на тржишту укључују НУнит и ЈУнит . Мицрософт такође нуди сопствени оквир за јединствено тестирање, тзв МСТест . Прегледајте веб локације ових алата и они ће вам пружити још примера и упутстава о томе како писати јединствене тестове.

#два) Аутоматизоване Веб услуге / АПИ тестови

Интерфејс за програмирање апликација (АПИ) омогућава софтверу да разговара са другим софтверским апликацијама. Као и сваки други софтвер, АПИ-је треба тестирати. У овој врсти тестирања ГУИ обично није укључен.

Оно што овде тестирамо су обично функционалност, усклађеност и безбедносни проблеми. У веб апликацијама можемо тестирати захтев и одговор наше апликације да ли су они безбедни и шифровани.

Ово је један од примера где можемо да користимо АПИ тестирање. Најпопуларнији алат за тестирање АПИ-ја је САПУН која има и бесплатну и плаћену верзију. Постоје и други алати које можете користити према својим потребама.

# 3) Аутоматизовани ГУИ тестови.

Ова врста аутоматизованог тестирања је најтежи облик аутоматизације, јер укључује тестирање корисничког интерфејса апликације.

Тешко је јер су ГУИ веома подложни променама. Али ова врста тестирања је такође најближа ономе што ће корисници радити са нашом апликацијом. Како ће корисник користити миш и тастатуру, аутоматизовани ГУИ тестови такође опонашају исто понашање коришћењем миша и тастатуре за кликање или писање на објекте присутне у корисничком интерфејсу.

Због тога грешке можемо наћи рано и могу се користити у многим сценаријима као што су регресијско тестирање или попуњавање образаца за што је потребно превише времена.

Најпопуларнији алати за тестирање ГУИ укључују Обједињено функционално тестирање микрофокуса (УФТ) , Селен , Тест је завршен и Кориснички интерфејс који кодира Мицрософт (који је део издања Висуал Студио ултимате и премиум издања).

Баш као и типови тестова аутоматизације, такође постоји више врста оквира.

Оквири за аутоматизацију

Неки од најчешће коришћених оквира за аутоматизацију укључују:

  • Линеарно (снимање и репродукција)
  • Вођена кључним речима
  • Дата Дривен
  • Модел објекта странице
  • Модуларни

Даље читање => Оквири за аутоматизацију

Врсте, оквир и алати

Као што видите, први корак у процесу аутоматизације је идентификација врсте аутоматизације, затим можете да идентификујете оквир за дизајн и имајући их на уму да можете одабрати алате који одговарају вашим потребама.

Алати за аутоматизацију

На основу врсте тестирања коју циљате и врсте оквира који ћете можда желети да око њега направите, доступни су следећи алати:

  • Селен : Веома моћан алат за тестирање веб апликација. Пружа подршку за више прегледача.
  • Јунит и Нунит: Алати које програмери углавном користе за Унит тестирање.
  • КТП : Одличан алат за не-веб апликације и долази са уграђеним спремиштем објеката.
  • Сикули: Алат отвореног кода за ГУИ тестирање.
  • Кориснички интерфејс сапуна: Алат за тестирање АПИ-ја.
  • Буди сигуран: Библиотека за стварање АПИ тест оквира.
  • аппиум : Алат који подржава тестирање на мобилним уређајима, тестирање изворних апликација, хибридно тестирање и тестирање мобилних веб апликација.
  • Јметер : Алат који се користи за тестове перформанси.
  • ТестНГ: ТестНГ сам по себи није алат за аутоматизацију, али пружа велику подршку оквирима за аутоматизацију изграђеним са селеном, апијем, будите сигурни итд.

Даље читање => Испитајте алате за аутоматизацију

Заблуде о испитивању аутоматизације

Током година чуо сам неке заблуде о аутоматизацији тестова. Мислим да бих и њих требало да очистим у овом чланку.

Заблуда бр. 1. Аутоматизација је ту да замени ручне тестере.

Аутоматизација теста помаже тестерима да тестирање учине бржим и на много поузданији начин. Никада не може заменити људе.

Аутоматизацију теста сматрајте аутомобилом. Ако ходате, требаће вам око 20 минута да стигнете до куће. Али ако користите аутомобил, стићи ћете за два минута. Возач аутомобила сте и даље ви, човек, али .. аутомобил помаже човеку да брже постигне свој циљ. Такође, већина ваше енергије се штеди, јер нисте ходали. Тако ову енергију можете користити за обављање важнијих ствари.

Исто важи и за тестирање аутоматизације. Користите га за брзо тестирање већине поновљених, дугих и досадних тестова и уштеду времена и енергије за фокусирање и тестирање нове и важне функционалности.

Као Јамес Бацх рекао је диван цитат:

„Алати не тестирају. Само људи тестирају. Алати изводе само радње које „помажу“ људима да тестирају. „

Алати могу кликтати на објекте. Али где да кликнете, увек ће вам рећи ручни тестер. Мислим да сте сада схватили моју поенту.

Заблуда бр. 2 . Све под сунцем може се аутоматизовати

Ако покушате да аутоматизујете 100% својих тест случајева, можда ћете то моћи да урадите, али ако бисте то могли да урадите, наша прва поента постаје нетачна. Ако је све аутоматизовано, шта ће онда радити ручни тестер?

Збуњен? Јел тако?

Заправо, поента је у томе да не можете аутоматизовати 100% својих тест случајева. Јер ми као тестери верујемо да ниједна апликација не може бити 100% тестирана. Увек ће постојати неки сценарији који ћемо пропустити. Увек ће бити грешака које се јављају само када клијенти користе вашу апликацију.

Ако апликација не може бити 100% тестирана, како онда можете обећати 100% аутоматизацију?

Такође, врло су мале шансе да ћете моћи да аутоматизујете све постојеће тестове. Увек постоје сценарији које је тешко аутоматизовати, а лакше је ручно.

На пример , Један корисник ће унети податке, други корисник ће одобрити податке, трећи корисник ће видети податке, а четвртом кориснику је забрањено да гледа податке. Ови сценарији се могу аутоматизовати, али ће вам требати пуно времена и труда. Тако ће бити лакше ако то урадите само ручно.

Запамтите, користимо аутомобиле да бисмо се удаљили, али на путу могу бити дугачки сигнали, потрошња горива, проблеми са паркинг простором, наплата паркинга и још много главобоље. У неким сценаријима само прошетамо и стигнемо до одредишта :) .

Стога не бисте требали покушавати да аутоматизујете све. Аутоматизујте само оне сценарије који су важни и оне којима ручно треба пуно времена.

Заблуда бр. 3 . Аутоматизација укључује само снимање и репродукцију.

како писати ефикасне тестове

Молим вас, не живите у свету фантазије. Ову фантазију уствари стварају лажни огласи различитих добављача алата за аутоматизацију. Кажу да само снимате и репродукујете кораке и да ће ваши тестови бити аутоматизовани. Па, то је велика лаж!

Аутоматизација је све, а не само снимање и репродукција. Чисти инжењери аутоматизације обично уопште не користе функцију снимања и репродукције. Снимање и репродукција се обично користе да би се стекла идеја како алат генерише скрипту за наше кораке.

Једном када се упознамо са скриптирањем, увек користимо скрипте за креирање аутоматизованих тестова. Запамтити, морате знати програмирање ако желите да се бавите аутоматизацијом тестова . С друге стране, немојте бити неугодни ако не знате програмирање. Као и било који други задатак, програмирање се такође може научити вежбањем и преданошћу.

Знам људе који чак и нису из рачунарске науке, али уче да програмирају и сада су сјајни инжењери аутоматизације. У Мицрософту ангажују тестере који се могу бавити програмирањем. Они се зову СДЕТ (Инжењери за развој софтвера за тест). У првом реду описа посла стоји „СДЕТ напишите пуно кода ...“.

Научите да програмирате, не бежите од тога. То ће вас створити невероватан тестер .

Закључак

Надам се да би вам овај чланак помогао да разјасните неке концепте повезане са аутоматизацијом тестова.

Покрили смо висок ниво различитих врста испитивања аутоматизације, са различитим начинима класификације.

Главне класификације укључују:

  • Аутоматизација заснована на врсти испитивања (функционално или нефункционално).
  • Аутоматизација заснована на фази испитивања (јединица, АПИ или УИ).
  • Аутоматизација заснована на различитим врстама тестова (више типова испитивања).

Такође смо навели разне алате који се могу користити за ове врсте аутоматизованог тестирања.

У нашем предстојећем чланку ћемо разговарати о корак по корак поступак од како започети аутоматизацију тестирања у вашој организацији .

ПРЕВ Туториал # 1 |. | СЛЕДЕЋА Лекција # 3

Препоручено читање

^