Как да станете тест автоматизатор, SavePearlHarbor

Още едно копие на пристанището

Главно меню

Навигация на публикации

Как да станете тест автоматизатор?

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

Случва се и по-лошо - мениджърът / PM / и т.н. ... идват при техните ръчни тестери и казват: „Слушай, може би ние автоматизираме нашите тестове - това ще ни спести много време и пари. Кажете ми какви книги имате нужда и какви курсове.

0. Да започнем с грешките, които не бива да допускаме:

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

Всичко това е добре, но само в допълнение към рецептата, която е описана по-долу. В никакъв случай не трябва да започвате с това.1. На първо място, трябва да изберете език за програмиранеНе инструмент, не TestComplete, не макроподобно ровене из екрана. Обектно-ориентиран език за програмиране. Веднъж работих малко с C #, след това избрах Java - и все още не съжалявам за избора си. Но няма да настоявам. Мога само да кажа, че все още не съм срещнал нито един проблем, който да не може да бъде решен в Java - дори приложение на Delphi се тества през WinAPI (но е по-добре да използвате Delphi DUnit и т.н. за такива задачи).

Така,ще научим за примитиви, класове, обекти, полиморфизъм, капсулиране, интерфейси, абстрактни класове, статични полета, цикли, масиви, листове, карти, потоци и така нататък… Това обучение ще продължи като цяло през цялото време, дори когато вече автоматизирате тестването. Но на основното ниво - Junior Java Developer - трябва (ако изберете Java) да сте запознати с езика и да имате подходящите умения, тъй като основната локализация на възникналия проблем лежи на вашите рамене. Забравете за „но имам скрипт, грешката се възпроизвежда неразбираемо как и неразбираемо защо“ - вашата задача е разработчикът да знае, че човек може да намери грешки тук, без дори да стартира приложението. Няма да повярвате колко внезапно се повишава качеството на даден продукт, когато има човек, който не само надушва неприятния код, но и може да предложи решения за подобрение.

Плавно преминахме към

2. Използване на шаблони за проектиране за разработване на тестова рамка.ДА-ДА. Отворихте, например, Selenium, копирахте безмислено всякакви примери, написахте 1000 теста върху получената „рамка“. Клиентът идва в бизнеса, казва „Трябва да преработя нещо тук“, бизнесът идва при разработчика - „трябва да се адаптираме малко към пазара тук“, разработчикът записва всичко по отличен начин, - 90% от тестовете падат. Те идват на автоматизатора „променихме малко тук, трябва да подредим тестовете“, а автоматизаторът в отговор „има работа за един месец“ ... Ами сега ... Архитектурата на рамката, която пишете, трябва не само да бъде гъвкава, но трябва постоянно да се стреми да минимизира времето за преработване на съществуващи тестове и писане на нови. В идеалния случай, ако разработчик и автоматизатор седнат да поправят нещо едновременно, тогава автоматизаторът трябва да направи всичко по-бързо и да предостави на разработчиканякаква форма на TDD.

При създаването на такава прекрасна архитектура ни помагат дизайнерските модели и тяхното компетентно използване ... Builder, Facade, Factory, Null Object, Singleton, Adapter и много други модели активно помагат при решаването на такива проблеми. Добрата архитектура на тестовата рамка е благословия за вас, за разработчиците, за бизнеса… и в крайна сметка за потребителя. Не забравяйте, че експоненциалното нарастване на ресурсите за поддръжка на тестове с линеен растеж/промяна във функционалността показва, че е време да прецизирате архитектурата на двигателя. Най-пълният списък с модели с примери на Java може да бъде намерентук. Отделно ще отбележа шаблона на Page Object, но е по-добре първо да се запознаете с класическите.

3. Използване на библиотекиНещата, които плавно се сливат с всякакви задачи, са външни API, библиотеки, драйвери и други изкушения. Selenium - тестване на мрежата, Robotium/Espresso - тестване на Android, Fest/Jemmy - тестване на Java Swing, JemmyFX - тестване на JavaFX, прекрасни Apache HttpComponents - правене на заявки и тестване на много API, GSON - помага за пренасяне на json до обектния модел и обратно, и така нататък до безкрайност... Има много красиви библиотеки, написани за почти всяка задача - можете да прочетете за някои от тяхтук. Не се страхувайте, че има много от тях - вече знаете достатъчно, за да изберете какво подхожда / харесва / се вписва в архитектурата. Например, за тестване на Java Swing приложения, използвам JUnit, Fest, Mockito и широките възможности на java.lang.reflect - този набор е повече от достатъчен за мен.

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

4.Планиране на тестове/Писане на тестовеВ тази статия не говоря за факта, че идеята за 100% покритие, скриптове и т.н. е пагубна за всеки проект. Като цяло класическите подходи за тестване са вредни при автоматизираното тестване - например изолирани входни данни за тестове. Като цяло вашите умения вече играят роля тук, способността да мислите аналитично, способността да се съмнявате в това, което си струва да се съмнявате и да не търсите проблем там, където не може да бъде. Добрите тестови скриптове са като добър интерфейс...те не могат да бъдат перфектни. Моят опит дава следната статистика: 5% от всички сценарии осигуряват 95% покритие на функционалността. В настоящия проект имаме 180 пълноценни функционални теста за почти 2 години работа, които ни осигуряват тези 95% - 99%, шест успешни внедрявания - изходът е няколко ниски коментара, които изобщо не повлияха на основната функционалност и лоялността на клиентите и бяха бързо коригирани. Но заради тях е нерентабилно да се ограждат още 2000 теста чисто пари - това говоря за мениджъри и бизнеси, които мечтаят за 100% покритие. Повярвай ми, нямаш нужда от това. Тук ще направя уговорка, ако не говорим за автоматично тестване на сигурността или таксуването - тук рисковете не трябва да се минимизират, а по възможност да се сведат до нула. Но това е друга история...

Разбира се, можете да си помислите „даааа“, но...

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

P.S.До бизнеса, ръководители, специалисти по подбор на персонал:

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