Меню

Видове тестове за автоматизация и някои заблуди

types automation testing

Опитайте Нашия Инструмент За Премахване На Проблемите

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

В тази втора част на серия уроци за автоматизация на тестове , Ще опиша накратко видовете автоматизирани тестове и след това най-важното ще изчистя някои заблуди относно автоматизацията на тестовете.

Какво е тестване за автоматизация?

Тестването за автоматизация може да бъде определено като начин за повторно изпълнение на набор от тестове, без да се налага да ги изпълнявате ръчно. Въвеждането на тестове за автоматизация във вашата тестова стратегия е начин да спестите пари и време.

видове тестове за автоматизация

Какво ще научите:

Видове тестове за автоматизация

Видовете тестове за автоматизация определят какъв тип тестови набори могат да бъдат автоматизирани. Много тестери бъркат тази тема с типовете рамки за автоматизация, които определят как ще проектирате вашия тестов пакет в пакет за автоматизация, който може да бъде изпълнен удобно.

В тази статия ще разгледаме отблизо видовете тестване на автоматизацията и накрая ще разгледаме накратко рамките за автоматизация.

Видове автоматизация

Нека разберем подробно горните класификации:

Автоматизация въз основа на вида на изпитването

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

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

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

Нефункционалните тестове определят нефинансовите изисквания на приложението. Това са изискванията, свързани с производителността, сигурността, базите данни и др. Тези изисквания могат да останат постоянни или да бъдат мащабирани според размера на софтуера.

Автоматизация на базата на фазата на тестване

Автоматизация на единични тестове:

безплатен конвертор на youtube в mp4 за mac

Тези тестове се изпълняват по време на самата фаза на разработка, в идеалния случай от разработчика след завършване на разработката и преди предаване на системата на тестерите за тестване.

Автоматизация на API тестове:

API тестовете се изпълняват по време на фазата на интеграция. Те могат да се изпълняват от екипа за разработка или тестване и могат да се изпълняват преди или след изграждането на потребителския интерфейс за приложението. Тези тестове са насочени към тестването въз основа на заявката и отговора, върху които е изградено приложението.

Автоматизация на тестове, базирани на потребителски интерфейс:

Тестовете, базирани на потребителски интерфейс, се изпълняват по време на фазата на изпълнение на теста. Те се изпълняват специално от тестерите и се изпълняват само веднъж, преди потребителският интерфейс на приложението да им бъде предаден. Те тестват функционалността и бизнес логиката на приложението от предния край на приложението.

Автоматизация въз основа на вида на тестовете

Единични тестове:

Unit Tests са тестовете, които са изградени за тестване на кода на приложение и обикновено са вградени в самия код. Те са насочени към стандартите за кодиране, като например как са написани методите и функциите.

Тези тестове се пишат по-често от самите разработчици, но в днешния свят тестерите за автоматизация също могат да бъдат помолени да ги напишат.

Изпълнението на тези тестове и получаването на грешки от тях ще означава, че вашият код ще се компилира и изпълнява без проблеми с кода. Тези тестове обикновено не са насочени към функционалните аспекти на приложението и тъй като са насочени към код, е по-подходящо да ги автоматизирате, така че да могат да се изпълняват както и когато се изисква от разработчика.

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

Тестът за дим е известен тест, извършен в жизнения цикъл на теста. Това са тестове след компилация, те се изпълняват незабавно след като всяко компилиране е дадено от приложението, за да се гарантира, че приложението все още функционира след завършване на компилацията.

Това е малък тестов пакет и е нещо, което ще се изпълнява многократно и по този начин има смисъл да се автоматизира. Тези тестове обикновено са от функционален характер и в зависимост от вида на приложението може да се избере инструмент за тях.

API тестове:

API тестването стана много известно през последните няколко години. Приложения, изградени върху архитектурата на API, могат да извършват това тестване.

При тестване на API тестерите валидират бизнес слоя на приложението, като проверяват комбинациите заявка-отговор за различните API, на които е изградено приложението. API тестовете също могат да бъдат направени като част от тестовете за интеграция по-долу.

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

Интеграционният тест, както подсказва самото име, означава тестване на приложението чрез интегриране на всички модули и проверка на функционалността на приложението.

Интеграционното тестване може да се извърши чрез API тестване или може да се направи чрез UI слоя на приложението.

UI тестове:

Тестовете на потребителския интерфейс се извършват от потребителския интерфейс или от интерфейса на приложението. Те могат да бъдат насочени към тестване на функционалността или просто да тестват UI елементите на приложение.

Автоматизирането на потребителския интерфейс за тестване на функционалността е често срещана практика. Автоматизирането на функциите на GUI обаче е една от по-сложните автоматизации.

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

Един от най-често автоматизираните тестови пакети е тестовият пакет за регресия. Регресията, както вече знаете, е тестът, който се прави в края на тестването на нов модул, за да се гарантира, че нито един от съществуващите модули не е бил засегнат от него.

Повтаря се след всяка нова итерация на тестване и основните тестови случаи остават фиксирани с обикновено няколко нови допълнения след нова итерация. Тъй като често се изпълнява, почти всички тестови екипи се опитват да автоматизират този пакет.

Автоматизация като непрекъсната интеграция:

Непрекъснатата интеграция може отново да се изпълнява на самите автоматизирани тестове за регресия, но при постигане на CI ние даваме възможност за регресия или идентифициран тестов пакет да се изпълняват всеки път, когато е направено ново внедряване.

Тестове за сигурност:

Тестването на сигурността може да бъде както функционално, така и нефункционален тип тестване, което включва тестване на приложението за уязвимости. Функционалните тестове ще съставят тестове, свързани с упълномощаване и т.н., докато нефункционалните изисквания може да са тест за SQL инжектиране, скриптове между сайтове и т.н.

Тестове за ефективност и контрол на качеството:

Тестовете за ефективност са нефункционални тестове, които са насочени към изискванията като тестване на натоварване, стрес, мащабируемост на приложението.

Тестове за приемане:

Тестовете за приемане отново попадат в функционални тестове, които обикновено се правят, за да се гарантира дали критериите за приемане, дадени от клиента, са изпълнени.

Досега сме описали вида на тестовете, които могат да бъдат автоматизирани и различни класификации на едни и същи, всички класификации в крайна сметка ще доведат до едни и същи крайни резултати от автоматизиран набор от тестове. Както казахме по-рано, е необходимо малко разбиране за това как те се различават от рамките.

След като сте идентифицирали тестовете, които искате да автоматизирате от горната класификация, ще трябва да проектирате логиката си по начин, който да изпълнява тези тестове безпроблемно, без много ръчна намеса. Този дизайн на ръчен тестов пакет в автоматизиран тестов пакет е мястото, където влизат рамките.

Сега ще разгледаме Топ 3 типа автоматизация на тестовете

  1. Единично тестване
  2. API тестване
  3. GUI тестване

# 1) Автоматизирани модулни тестове

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

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

Поради наличието на модулни тестове, когато кодът се компилира, всички модулни тестове се изпълняват и ни казват резултата, че ако цялата функционалност работи. Ако някой модулен тест се провали, това означава, че вече има грешка в производствения код.

Някои от най-популярните инструменти, присъстващи на пазара, включват NUnit и JUnit . Microsoft също предоставя собствена рамка за модулно тестване, наречена MSTest . Прегледайте уебсайтовете на тези инструменти и те ще ви предоставят още примери и уроци за това как да пишете модулни тестове.

sql заявки примери с отговори pdf

# две) Автоматизирани уеб услуги / API тестове

Интерфейс за приложно програмиране (API) дава възможност на софтуера да разговаря с други софтуерни приложения. Както всеки друг софтуер, API трябва да бъдат тествани. При този тип тестване GUI обикновено не участва.

Това, което тестваме тук, обикновено са проблемите с функционалността, съответствието и сигурността. В уеб приложенията можем да тестваме заявката и отговора на нашето приложение, че ако са защитени и криптирани или не.

Това е един от примерите, където можем да използваме API тестване. Най-популярният инструмент за API тестване е САПУН който има както безплатни, така и платени версии. Има и други инструменти, които можете да използвате според вашите нужди.

# 3) Автоматизирани GUI тестове.

Този тип автоматизирано тестване е най-трудната форма на автоматизация, тъй като включва тестване на потребителски интерфейс на приложението.

Трудно е, тъй като графичните интерфейси са силно обект на промяна. Но този тип тестване също е най-близо до това, което потребителите ще правят с нашето приложение. Тъй като потребителят ще използва мишката и клавиатурата, автоматизираните GUI тестове също имитират същото поведение, като използват мишката и клавиатурата, за да щракват или пишат в обекти, присъстващи в потребителския интерфейс.

Поради това можем да открием грешки по-рано и може да се използва в много сценарии като регресионно тестване или попълване на формуляри, което отнема твърде много време.

Най-популярните инструменти за тестване на GUI включват Унифицирано функционално тестване с микрофокус (UFT) , Селен , Тестът завършен и Кодиран потребителски интерфейс на Microsoft (което е част от окончателните и първокласни издания на Visual Studio).

Подобно на видовете тестове за автоматизация, има и няколко типа рамки.

Рамки за автоматизация

Някои често използвани рамки за автоматизация включват:

  • Линеен (Запис и възпроизвеждане)
  • Управлявана по ключови думи
  • Управлявани данни
  • Модел на обект на страница
  • Модулни

Допълнително четене => Рамки за автоматизация

Видове, рамка и инструменти

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

Инструменти за автоматизация

Въз основа на типа тестване, към който се насочвате, и вида на рамката, която може да искате да изградите около него, са налични следните инструменти:

  • Селен : Много мощен инструмент за тестване на уеб приложения. Осигурява поддръжка на множество браузъри.
  • Джунит и Нунит: Инструменти, използвани главно за модулно тестване от разработчиците.
  • QTP : Страхотен инструмент за не-уеб приложения и се предлага с вградено хранилище на обекти.
  • Сикули: Инструмент с отворен код за тестване на GUI.
  • Потребителски интерфейс на сапун: Инструмент за API тестване.
  • Бъдете спокойни: Библиотека за създаване на рамка за тестване на API.
  • апиум : Инструмент, който поддържа мобилно тестване, тестване на собствено приложение, хибридно и тестване на мобилни уеб приложения.
  • Jmeter : Инструмент, който се използва за тестове за ефективност.
  • TestNG: TestNG не е инструмент за автоматизация сам по себе си, но осигурява чудесна поддръжка на рамки за автоматизация, изградени със селен, апий, бъдете сигурни и т.н.

Допълнително четене => Тествайте инструменти за автоматизация

Заблуди относно тестването за автоматизация

През годините съм чувал някои заблуди относно автоматизацията на тестовете. Мисля, че трябва да ги изчистя и в тази статия.

Погрешно схващане # 1. Автоматизацията е тук, за да замени ръчните тестери.

уебсайтове за изтегляне на YouTube видеоклипове безплатно

Автоматизацията на тестовете е да помогне на тестерите да направят тестването по-бързо и по много надежден начин. Той никога не може да замести хората.

Мислете за автоматизацията на тестовете като за кола. Ако ходите, ще ви отнеме около 20 минути, за да стигнете до дома си. Но ако използвате кола, ще стигнете след две минути. Шофьорът на колата все още сте вие, човек, но .. колата помага на човека да постигне целта си по-бързо. Освен това по-голямата част от енергията ви се спестява, тъй като не сте ходили. По този начин можете да използвате тази енергия за извършване на по-важни неща.

Същото важи и за тестовете за автоматизация. Използвате го, за да тествате бързо повечето си повтарящи се, дълги и скучни тестове и спестявате време и енергия, за да фокусирате и тествате нова и важна функционалност.

Като Джеймс Бах каза чудесен цитат:

„Инструментите не тестват. Тестват само хора. Инструментите извършват само действия, които „помагат“ на хората да тестват. „

Инструментите могат да кликват върху обекти. Но къде да щракнете, винаги ще ви каже ръчен тестер. Мисля, че сега разбрахте моята точка.

Погрешно схващане # 2 . Всичко под слънцето може да бъде автоматизирано

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

Объркан? Нали?

Всъщност въпросът е, че не можете да автоматизирате 100% от вашите тестови случаи. Тъй като ние като тестери вярваме, че нито едно приложение не може да бъде тествано на 100%. Винаги ще има някои сценарии, които ще пропуснем. Винаги ще има грешки, които се появяват само когато вашето приложение ще бъде използвано от клиентите.

Ако приложението не може да бъде тествано на 100%, тогава как можете да обещаете 100% автоматизация?

Също така има много малък шанс да можете да автоматизирате всичките си съществуващи тестови случаи. Винаги има сценарии, които са трудни за автоматизиране и са по-лесни за ръчно изпълнение.

Например , Един потребител ще въведе данните, вторият потребител ще одобри данните, третият потребител ще прегледа данните и на четвъртия потребител е забранено да преглежда данните. Тези сценарии могат да бъдат автоматизирани, но те ще отнемат много време и усилия. Така че ще бъде по-лесно, ако просто направите това ръчно.

Не забравяйте, че ние използваме автомобили, за да стигнем до разстояние, но може да има дълги сигнали по пътя, ще има разход на гориво, ще има проблеми с паркомястото, такси за паркиране и много повече главоболие. В някои сценарии просто вървим пеша и стигаме до нашата дестинация :) .

По този начин не трябва да се опитвате да автоматизирате всичко. Автоматизирайте само онези важни сценарии и тези, които отнемат много време, за да ги направите ръчно.

Погрешно схващане # 3 . Автоматизацията включва само запис и възпроизвеждане.

Моля, не живейте във фантастичен свят. Тази фантазия всъщност се създава от фалшиви реклами от различни доставчици на инструменти за автоматизация. Казват, че просто записвате и възпроизвеждате стъпките си и тестовите ви случаи ще бъдат автоматизирани. Е, това е голяма лъжа!

Автоматизацията е всичко, а не само запис и възпроизвеждане. Инженерите за чиста автоматизация обикновено изобщо не използват функция за запис и възпроизвеждане. Записът и възпроизвеждането обикновено се използват, за да се добие представа как инструментът генерира скрипт за нашите стъпки.

След като се запознаем със скриптове, ние винаги използваме скриптове за създаване на автоматизирани тестове. Помня, трябва да знаете програмиране, ако искате да направите автоматизация на тестовете . От друга страна, не бъдете обезсърчени, ако не знаете програмиране. Подобно на всяка друга задача, програмирането също може да се научи с практика и отдаденост.

Познавам хора, които дори не са от компютърни науки, но се научават да програмират и сега са страхотни инженери по автоматизация. В Microsoft те наемат тестери, които могат да се занимават с програмиране. Те се наричат SDET (Инженери за разработка на софтуер за тест). Първият ред от описанието на длъжността казва „SDET’s write a lot of code ....“.

Моля, научете се да програмирате, не бягайте от него. Ще ви направи невероятен тестер .

Заключение

Надявам се тази статия да ви е помогнала да изчистите някои концепции, свързани с автоматизацията на тестовете.

Обхванахме високо ниво на различни видове тестове за автоматизация, с различни начини за класификация.

Основните класификации включват:

  • Автоматизация, базирана на Тип тестване (функционално или нефункционално).
  • Автоматизация, базирана на фазата на тестване (Unit, API или UI).
  • Автоматизация, базирана на различните видове тестове (множество типове тестове).

Също така изброихме различните инструменти, които могат да се използват за тези видове автоматизирани тестове.

В предстоящата ни статия ще обсъдим стъпка по стъпка процедура на как да стартирате автоматизация на тестове във вашата организация .

PREV Урок # 1 | СЛЕДВАЩ Урок # 3

Препоръчително четене

^