what is automation testing
Пълно ръководство за стартиране на тестове за автоматизация на вашия проект:
Какво е тестване за автоматизация?
Тестването за автоматизация е техника за тестване на софтуер за тестване и сравняване на действителния резултат с очаквания резултат. Това може да се постигне чрез писане на тестови скриптове или с помощта на какъвто и да е инструмент за тестване на автоматизация. Тестовата автоматизация се използва за автоматизиране на повтарящи се задачи и други тестови задачи, които са трудни за ръчно изпълнение.
Искате ли да започнете теста за автоматизация на вашия проект, но борите ли се с най-основните стъпки, както е споменато по-долу:
- Как да въведем автоматизация във вашия проект?
- Как да изберем най-добрия и правилен инструмент за автоматизация?
- Как да разработваме скриптове ефективно?
- Как да изпълнявам и поддържам тестови скриптове?
- И накрая кои са най-добрите практики, които трябва да следвате за успешно тестване на автоматизацията?
Днес сме планирали да обогатим вашите знания с поредица уроци на тема „ Първи стъпки с тестване за автоматизация ”. Тази серия уроци за автоматизация ще отговори на всички горепосочени въпроси стъпка по стъпка с прости примери.
Нека да разгледаме поредицата от уроци за стартиране на автоматизация на вашия проект !!
Процес на автоматизация от край до край:
Урок №1 : Най-доброто ръководство за стартиране на автоматизация на вашия проект
Урок # 2: Видове автоматизирани тестове и някои заблуди
Урок № 3: 10 стъпки за въвеждане на автоматизация във вашия проект
Урок № 4: Ръководството от А до Я за избора на най-добрия инструмент за автоматизация
Урок № 5: Рамки за разработка на скриптове и автоматизация
Урок № 6: Изпълнение и отчитане на автоматизация
Урок # 7: Най-добри практики и стратегии за автоматизация на тестове
Съвети за автоматизация:
Урок № 8: 10 съвета, които трябва да прочетете, преди да автоматизирате работата си по тестване
Урок № 9: Как се различава планирането на тестове за ръчни проекти и проекти за автоматизация
Урок № 10: Кога да избера автоматизация?
Урок # 11: Предизвикателства на теста за автоматизация
Урок # 12: Ръководство за прилагане на доказателство за концепция (POC) в автоматизацията
Урок № 13: Как да изберем правилни тестови случаи за автоматизация
Урок # 14: Как да превеждам ръчни тестови случаи в скриптове за автоматизация
Кариера в автоматизацията:
Урок # 15: Съвети как да станете по-добър тестер за автоматизация
Урок # 16: Автоматизация на тестовете - Специализирана кариера ли е? Могат ли нормалните тестери да правят и автоматизация?
Популярни инструменти за автоматизация:
Урок # 17: 31+ най-добри безплатни урока за обучение по селен
Урок # 18: QTP уроци
Урок № 19: Инструмент за тестване на уеб услуги SoapUI
Урок # 20: HP LoadRunner за тестване на производителността
Рамки за автоматизация:
Урок # 21: Защо ни е необходима рамка за автоматизация
Урок # 22: Най-популярните рамки за автоматизация
Автоматизация в Agile:
Урок № 23: Как да внедрим ефективна автоматизация в пъргавия свят
Други инструменти за автоматизация:
Урок # 24: Най-добрите инструменти за тестване на автоматизацията
Урок # 25: Инструмент за автоматизация на графичния интерфейс на Sikuli
Урок # 26: PowerShell: Автоматизация на потребителския интерфейс за настолни приложения с PowerShell
Урок # 27: Catalon Automation Recorder (Selenium IDE Alternative)
Урок # 28: Geb Tool: Автоматизация на браузъра с помощта на Geb Tool
Урок # 29: AutoIt: Как да се справя с изскачащите прозорци на Windows с помощта на AutoIt
Урок № 30: Краставица: Автоматизация с помощта на инструмент за краставици и селен
Урок # 31: Инструмент за тестване на транспортир за тестване от край до край на приложения AngularJS
Тестване на мобилната автоматизация:
Урок № 32: Урок за ръководство на Appium Studio
Урок # 33: Урок за Appium за начинаещи
Урок # 34: Урок за Selendroid: Android Mobile Automation Framework
Урок # 35: Урок на Ranorex: Мощен инструмент за тестване на настолни компютри, уеб и мобилни устройства
Примери за автоматизация на конкретни домейни:
Урок # 36: Автоматизация на JAVA / J2EE приложения
Подготовка за интервю за работа по автоматизация:
Урок # 37: Въпроси за интервю за тестване на автоматизация
Урок # 38: Въпроси за интервю за селен
Нека разгледаме първия урок от поредицата „The Ultimate Guide to Automation Testing“ !!
Какво ще научите:
- Какво е тестване за автоматизация?
- Автоматизация - рентабилен метод за регресивно тестване
- Сценарии, които изискват автоматизация
- Правилни тестове за автоматизация
- Какво НЕ да се автоматизира?
- Прост пример за тестова автоматизация
- Какво представляват твърденията?
- Заключение
- Препоръчително четене
Какво е тестване за автоматизация?
Ако софтуерът може да направи всичко тогава, защо софтуерът не може да тества софтуер?
Това изказване звучи ли ви логично?
Ако отговорът е да, тогава поздравления, сега мислите за автоматизация на тестовете, която е централната точка, която ще обсъдим в тази поредица от информативни уроци.
Представете си себе си в първия ден на вашата работа като SQA. Представено ви е приложение, което да бъде тествано. Това е ERP приложение, съдържащо 100s формуляри и хиляди отчети. Започвате вашето изследователско тестване, като отворите формуляр, който съдържа около 50 различни полета.
Опитвате се да въведете произволни данни в тази форма, което отне около 20 минути. След това натискате подаване. Уола !! Показва се съобщение за грешка, което изглежда като необработено изключение. Ставате много щастливи. Гордо си отбелязвате стъпките и съобщавате за грешката във вашата система за управление на грешки. Голямо усилие, чувствате се наистина уверени и енергични. Продължавате тестването до края на деня и намирате още грешки. „Удивителен първи ден“, помислихте си.
Сега идва на следващия ден, разработчикът е отстранил проблема и пуска нова версия на компилацията. Тествате същия формуляр със същите стъпки и установихте, че грешката е отстранена. Маркирате го фиксиран. Голямо усилие. Вие сте допринесли за качеството на продукта, като сте идентифицирали тази грешка и тъй като тази грешка е отстранена, качеството се подобрява.
Сега идва третият ден, разработчикът отново пусна по-нова версия. Сега отново трябва да тествате този формуляр, за да сте сигурни, че не е открит проблем с регресията. Същите 20 минути. Сега се чувствате малко отегчени.
Сега си представете, че след 1 месец по-нови версии излизат непрекъснато и при всяко издание трябва да тествате тази дълга форма плюс 100 други подобни форми, само за да сте сигурни, че няма регресия.
Сега се чувствате ядосани. Чувствате се уморени . Започвате да прескачате стъпки. Попълвате около 50% от общите полета. Вашата точност не е еднаква, енергията ви не е същата и определено стъпките ви не са еднакви.
И един ден клиентът съобщава за същата грешка в същата форма. Чувствате се жалко. Сега се чувствате несигурни. Мислите, че не сте достатъчно компетентни. Мениджърите поставят под въпрос способностите ви.
Имам новина за вас; това е историята на 90% от ръчните тестери там. Вие не сте различни.
Проблемите с регресията са най-болезнените проблеми. Ние сме хора. И не можем да правим едно и също нещо с еднаква енергия, скорост и точност всеки ден. Това правят машините. Това е, за което се изисква автоматизация, за да се повтарят същите стъпки със същата скорост, точност и енергия, както бяха повторени за първи път.
java срещу c ++, което е по-добре
Надявам се да разберете моята точка !!
Когато възникне такава ситуация, трябва да автоматизирате своя тест. Тестовата автоматизация е ваш приятел . Това ще ви помогне да се съсредоточите върху нова функционалност, докато се грижите за регресиите. С автоматизацията можете да попълните този формуляр за по-малко от 3 минути.
Скриптът ще запълни всички полета и ще ви каже резултата заедно със снимки на екрана. В случай на неуспех, той може да определи мястото, където тестовият случай е неуспешен, като по този начин ви помага да го възпроизведете с лекота.
Автоматизация - рентабилен метод за регресивно тестване
Първоначално разходите за автоматизация са наистина по-високи. Той включва разходите за инструмента, след това разходите за ресурса за тестване за автоматизация и неговото / нейното обучение.
Но когато скриптовете са готови, те могат да бъдат изпълнявани стотици пъти многократно със същата точност и доста бързо. Това ще спести много часове ръчно тестване. Така разходите постепенно намаляват и в крайна сметка се превръщат в рентабилен метод за Регресионно тестване .
Сценарии, които изискват автоматизация
Горният сценарий не е единственият случай, когато ще ви е необходим тест за автоматизация. Има няколко ситуации, които не могат да бъдат тествани ръчно.
Например ,
- Сравняване на две изображения пиксел по пиксел.
- Сравняване на две електронни таблици, съдържащи хиляди редове и колони.
- Тестване на приложение под товара на 100 000 потребители.
- Бенчмаркове за ефективност.
- Тестване на приложението в различни браузъри и паралелно на различни операционни системи.
Тези ситуации изискват и трябва да бъдат тествани с инструменти.
И така, кога да се автоматизира?
Това е ера на пъргава методология в SDLC, където разработването и тестването ще вървят почти паралелно и е много трудно да се реши кога да се автоматизира.
Обмислете следните ситуации, преди да влезете в автоматизацията
- Продуктът може да е в примитивните си етапи, когато продуктът дори няма потребителски интерфейс, на тези етапи трябва да имаме ясна мисъл какво искаме да автоматизираме. Следва да се помнят следните точки.
- Тестовете не трябва да са остарели.
- Тъй като продуктът се развива, трябва да е лесно да избирате скриптовете и да добавяте към тях.
- Много е важно да не се увличате и да сте сигурни, че скриптовете са лесни за отстраняване на грешки.
- Не опитвайте автоматизация на потребителския интерфейс на много начални етапи, тъй като потребителският интерфейс е подложен на чести промени, като по този начин ще доведе до отказ на скриптове. Доколкото е възможно, изберете автоматизация на ниво API / Non UI ниво, докато продуктът се стабилизира. Автоматизацията на API е лесна за отстраняване и отстраняване на грешки.
Как да решим най-добрите случаи на автоматизация:
Автоматизацията е неразделна част от тестовия цикъл и е много важно да решим какво искаме да постигнем с автоматизацията, преди да решим да автоматизираме.
Ползите, които автоматизацията изглежда предоставя, са много привлекателни, но в същото време зле организираният пакет за автоматизация може да развали цялата игра. Тестерите може в крайна сметка да отстранят грешките и да поправят скриптовете през повечето време, което да доведе до загуба на време за тестване.
Тази поредица ви обяснява как един пакет за автоматизация може да бъде направен достатъчно ефективен, за да вземе правилните тестови случаи и да даде правилните резултати със скриптовете за автоматизация, които имаме.
Също така, обхванах отговорите на въпроси като кога да автоматизирам, какво да автоматизирам, какво да не автоматизирам и как да стратегирам автоматизация.
Правилни тестове за автоматизация
Най-добрият начин да се справим с този проблем е бързо да измислим „Стратегия за автоматизация“, която отговаря на нашия продукт.
Идеята е да групираме тестовите случаи, така че всяка група да ни даде различен вид резултат. Илюстрацията, дадена по-долу, показва как бихме могли да групираме подобни тестови случаи в зависимост от продукта / решението, което тестваме.
Нека сега да се потопим дълбоко и да разберем какво всяка група може да ни помогне да постигнем:
# 1) Направете тестов пакет от всички основни функционалности Положителни тестове . Този пакет трябва да бъде автоматизиран и когато този пакет се изпълнява срещу компилация, резултатите се показват незабавно. Всеки скрипт, който се провали в този пакет, води до дефект S1 или S2 и тази конкретна компилация може да бъде дисквалифицирана. Така че спестихме много време тук.
Като допълнителна стъпка можем да добавим този автоматизиран тестов пакет като част от BVT (Тестове за проверка на изграждането) и да проверим скриптовете за автоматизация на QA в процеса на изграждане на продукта. Така че, когато компилацията е готова, тестерите могат да проверят резултатите от теста за автоматизация и да решат дали компилацията е подходяща или не за инсталация и по-нататъшен процес на тестване.
Това ясно постига целите на автоматизацията, които са:
- Намалете усилията за тестване.
- Намерете бъгове на по-ранни етапи.
# две) След това имаме група от Тестове от край до край .
При големите решения тестването на функционалността от край до край има ключово значение, особено по време на критичните етапи на проекта. Трябва да имаме няколко скрипта за автоматизация, които засягат и крайните тестове на решения. Когато този пакет се изпълнява, резултатът трябва да показва дали продуктът като цяло работи както се очаква или не.
Трябва да се посочи тестовият пакет за автоматизация, ако някой от компонентите за интеграция е счупен. Този пакет не трябва да обхваща всяка малка характеристика / функционалност на решението, но трябва да обхваща работата на продукта като цяло. Винаги, когато имаме алфа или бета или други междинни версии, тогава такива скриптове са полезни и дават известна степен на доверие на клиента.
За да разберем по-добре, нека приемем, че тестваме портал за онлайн пазаруване , като част от тестовете от край до край трябва да обхващаме само ключовите участващи стъпки.
Както е дадено по-долу:
- Потребителски вход.
- Прегледайте и изберете елементи.
- Възможност за плащане - това обхваща тестовете на предния край.
- Управление на бекенд поръчки (включва комуникация с множество интегрирани партньори, проверка на запасите, изпращане на имейл до потребителя и т.н.) - това ще помогне за тестовата интеграция на отделни парчета, а също и на същността на продукта.
Така че, когато се изпълни един такъв скрипт, той дава увереност, че решението като цяло работи добре.!
# 3) Третият набор е Тестове, базирани на характеристики / функционалност .
За пример , Може да разполагаме с функционалността за преглед и избор на файл, така че когато автоматизираме това, можем да автоматизираме случаите, за да включим избора на различни типове файлове, размери на файлове и т.н., така че да се направи тестване на характеристиките. Когато има някакви промени / допълнения към тази функционалност, този пакет може да служи като пакет за регресия.
# 4) Следващият в списъка ще бъде Тестове, базирани на потребителски интерфейс. Можем да имаме друг пакет, който ще тества чисто базирани на потребителския интерфейс функционалности като страниране, ограничение на символите в текстовото поле, бутон на календара, падащи менюта, графики, изображения и много такива функции, ориентирани само към потребителския интерфейс. Неуспехът на тези скриптове обикновено не е много критичен, освен ако потребителският интерфейс не работи напълно или някои страници не се появяват според очакванията!
# 5) Можем да имаме още един набор от тестове, които са лесни, но много трудоемки, за да се извършват ръчно. Досадни, но прости тестове са идеалните кандидати за автоматизация, например въвеждането на данни за 1000 клиенти в базата данни има проста функционалност, но изключително досадно да се извършва ръчно, такива тестове трябва да бъдат автоматизирани. Ако не, те в крайна сметка се игнорират и не се тестват.
Какво НЕ да се автоматизира?
По-долу са дадени няколко теста, които не трябва да бъдат автоматизирани.
# 1) Отрицателни тестове / тестове за срив
Не бива да се опитваме да автоматизираме отрицателни или отказоустойчиви тестове , тъй като за тези тестове тестерите трябва да мислят аналитично и отрицателните тестове не са наистина ясни, за да дадат резултат или неуспех, който може да ни помогне.
Отрицателните тестове ще се нуждаят от много ръчна намеса, за да симулират действителен сценарий за възстановяване след бедствие. Само за пример ние тестваме функции като надеждността на уеб услугите - за да го обобщим тук, основната цел на такива тестове би била да причинят умишлени грешки и да видим колко добре продуктът успява да бъде надежден.
Симулирането на горните откази не е просто, това може да включва инжектиране на някои мъничета или използване на някои инструменти между тях, а автоматизацията не е най-добрият начин да отидете тук.
# 2) Ad hoc тестове
Тези тестове може да не са релевантни за даден продукт по всяко време и това може дори да е нещо, което тестващият би могъл да измисли на този етап от инициирането на проекта, а също така усилията за автоматизиране на ad hoc тест трябва да бъдат валидирани спрямо критичността на характеристиката, която тестовете засягат.
Например , Тестер, който тества функция, която се занимава със компресия / криптиране на данни, може да е направил интензивни ad-hoc тестове с разнообразие от данни, типове файлове, размери на файлове, повредени данни, комбинация от данни, използвайки различни алгоритми, в няколко платформи и т.н.
Когато планираме за автоматизация може да поискаме да дадем приоритет и да не правим изчерпателна автоматизация на всички ad hoc тестове само за тази функция и в крайна сметка да имаме малко време за автоматизиране на останалите ключови характеристики.
# 3) Тестове с масивна предварителна настройка
Има тестове, които изискват огромни предпоставки.
Например, Може да имаме продукт, който се интегрира със софтуер на трета страна за някои от функциите, тъй като продуктът се интегрира с всяка система за опашки за съобщения, която изисква инсталиране в система, настройване на опашки, създаване на опашки и т.н.
3rdпартийният софтуер може да бъде всичко и настройката може да е сложна по своята същност и ако такива скриптове са автоматизирани, те винаги ще зависят от функцията / настройката на този софтуер на трета страна.
Предварителните условия включват:
В момента нещата може да изглеждат прости и изчистени, тъй като и двете странични настройки са направени и всичко е наред. Виждали сме много пъти, че когато даден проект навлезе във фазата на поддръжка, проектът се премества в друг екип и в крайна сметка те отстраняват грешки в такива скриптове, където действителният тест е много прост, но скриптът се проваля поради 3rdпроблем със софтуера на партията.
Горното е само пример, като цяло следете тестовете, които имат трудоемки предварителни настройки за прост тест, който следва.
Прост пример за тестова автоматизация
Когато тествате софтуер (в мрежата или работния плот), обикновено използвате мишка и клавиатура, за да изпълните стъпките си. Инструментът за автоматизация имитира същите стъпки, като използва скриптове или език за програмиране.
Например , ако тествате калкулатор и тестовият случай е, че трябва да добавите две числа и да видите резултата. Скриптът ще изпълни същите стъпки, като използва мишката и клавиатурата.
как да отворя apk файлове на windows
Примерът е показан по-долу.
Стъпки за ръчен тест:
- Стартиране на калкулатор
- Натиснете 2
- Натиснете +
- Натиснете 3
- Натиснете =
- Екранът трябва да показва 5.
- Затворете калкулатора.
Скрипт за автоматизация:
//the example is written in MS Coded UI using c# language. [TestMethod] public void TestCalculator() { //launch the application var app = ApplicationUnderTest.Launch('C:\Windows\System32\calc.exe'); //do all the operations Mouse.Click(button2); Mouse.Click(buttonAdd); Mouse.Click(button3); Mouse.Click(buttonEqual); //evaluate the results Assert.AreEqual('5', txtResult.DisplayText,”Calculator is not showing 5); //close the application app.Close(); }
Горният скрипт е просто дублиране на ръчните ви стъпки. Сценарият е лесен за създаване и лесен за разбиране.
Какво представляват твърденията?
Вторият последен ред на сценария се нуждае от още обяснения.
Assert.AreEqual (“5”, txtResult.DisplayText, ”Калкулаторът не показва 5);
Във всеки тестов случай имаме някакъв очакван или прогнозиран резултат в края. В горния скрипт очакваме, че „5“ трябва да се покаже на екрана. Действителният резултат е резултатът, който се показва на екрана. Във всеки тестов случай сравняваме очаквания резултат с действителния резултат.
Същото важи и за тестовете за автоматизация. Единствената разлика тук е, че когато правим това сравнение в тестовата автоматизация, то се нарича нещо друго във всеки инструмент.
Някои инструменти го наричат „ Твърдение ”, Някои го наричат„ контролно-пропускателен пункт ”, А някои го наричат„ валидиране ”. Но по принцип това е само сравнение. Ако това сравнение не успее, за E.g. екран показва 15 вместо 5, тогава това твърдение / контролна точка / валидиране е неуспешно и тестовият ви случай е отбелязан като неуспешен.
Когато тестовият случай е неуспешен поради твърдение, това означава, че сте открили грешка чрез автоматизация на теста. Трябва да го докладвате на вашата система за управление на грешки, както обикновено при ръчно тестване.
В горния скрипт изпълнихме твърдение във втория последен ред. 5 е очаквания резултат, txtResult . DisplayText е действителният резултат и ако те не са равни, ще ни се покаже съобщение, че „Калкулаторът не показва 5“.
Заключение
Често тестерите срещат крайни срокове и мандати за автоматизиране на всички случаи, за да подобрят оценките за тестване.
Има някои често срещани „погрешни“ възприятия за автоматизацията.
Те са:
- Можем да автоматизираме всеки тестов случай.
- Автоматизираните тестове ще намалят изключително много времето за тестване.
- Не се въвеждат грешки, ако скриптовете за автоматизация работят гладко.
Трябва да сме наясно, че автоматизацията може да намали времето за тестване само за някои видове тестове. Автоматизирането на всички тестове без никакъв план или последователност ще доведе до масивни скриптове, които са тежка поддръжка, често се провалят и също се нуждаят от много ръчна намеса. Също така, в постоянно развиващите се продукти скриптовете за автоматизация могат да остареят и да се нуждаят от постоянни проверки.
Групирането и автоматизирането на правилните кандидати ще спести много време и ще даде всички предимства на автоматизацията.
Този отличен урок може да бъде обобщен само в 7 точки.
Тестване за автоматизация:
- Дали тестването се извършва програмно.
- Използва инструмента за контрол на изпълнението на тестове.
- Сравнява очакваните резултати с действителните резултати (твърдения).
- Може да автоматизира някои повтарящи се, но необходими задачи ( E.g. Вашите регресионни тестове).
- Може да автоматизира някои задачи, които са трудни за ръчно изпълнение (E.g.Сценарии за тестване на натоварване).
- Скриптовете могат да се изпълняват бързо и многократно.
- Рентабилен е в дългосрочен план.
Тук автоматизацията е обяснена с прости думи, но това не означава, че винаги е лесно да се направи. В нея има предизвикателства, рискове и много други пречки. Има много начини, по които автоматизацията на тестовете може да се обърка, но ако всичко върви добре, тогава ползите от автоматизацията на тестовете са наистина огромни.
Предстоящи в тази поредица:
В предстоящите ни уроци ще обсъдим няколко аспекта, свързани с автоматизацията.
Те включват:
- Видове автоматизирани тестове и някои заблуди.
- Как да въведете автоматизация във вашата организация и да избегнете често срещаните клопки, когато правите автоматизация на тестове.
- Процесът на избор на инструмент и сравнение на различни инструменти за автоматизация.
- Рамки за разработка на скриптове и автоматизация с примери.
- Изпълнение и отчитане на тестова автоматизация.
- Най-добри практики и стратегии за автоматизация на тестове.
Желаете ли да научите повече за всяка концепция за тестване за автоматизация? Внимавайте и следете нашия списък с предстоящи уроци от тази поредица и не се колебайте да изразите мислите си в раздела за коментари по-долу.
Препоръчително четене
- Процес на автоматизирано тестване от 10 стъпки: Как да започнете тестване на автоматизация във вашата организация
- Урок за Geb - Тестване за автоматизация на браузъра с помощта на Geb Tool
- Инструмент за тестване за автоматизация на графичния интерфейс на Sikuli - Ръководство за начинаещи, Част 2
- Ръководство стъпка по стъпка за внедряване на доказателство за концепция (POC) в тестовете за автоматизация
- Най-добри инструменти за тестване на софтуер 2021 г. [Инструменти за автоматизация на QA теста]
- Тестерите губят ли сцеплението си при тестване поради автоматизация?
- Предизвикателства при ръчно тестване и автоматизация
- 10 съвета, които трябва да прочетете, преди да автоматизирате работата си по тестване