Рівень 15. Автоматизовані сценарії
Рівень 15
Сценарії автоматизації тестування
Привіт! Ми, зоряні роботи, навчимо тебе думати як робот, тестувати як робот, діяти як робот
У цьому рівні ми розглянемо принципи складання автоматизованих сценаріїв тестування та методології підходу до автоматизації. І справді, ти виявиш, що для написання автотестів потрібно думати не як людина, а як робот. Не в сенсі рухатися ривками під електронну музику, а в тому, що всі дії мають бути детермінованими (чітко визначеними та виміряними кількісно). Роботу не скажеш: «Перевір-но мені, що сайт виглядає добре», — йому треба сказати: «Перевір, що розмір хедера — 300 х 500 пікселів». Про це й поговоримо.
Автоматизоване тестування — це процес, який потребує великої кількості часу та кваліфікації
Етапи автоматизованого тестування:
- Ручне тестування функціоналу (вивчення)
- Вибір інструмента автоматизації
- Вивчення цього інструмента
- Вибір стратегії автоматизації
- Оцінка часових рамок і створення плану автоматизації
- Написання програмного коду тестів
- Налагодження та впровадження тестів
Визначення автоматизованого тестування
Автоматизоване тестування — це:
Набір практик, підходів і методів, які в сукупності дозволяють автоматизувати тестові сценарії (за допомогою сторонніх щодо системи утиліт або програмних продуктів, включно із середовищем розробки), а також забезпечують виконання активностей, спрямованих на тестування ПЗ.
Практичні міркування:
- Автоматизоване тестування — це вид тестів, а не фаза тестування
- Автоматизація тестування не починається після якогось іншого етапу тестування, а є незалежним етапом
- Потенційно майже будь-який тест може бути автоматизований
- Не всі тести мають бути автоматизовані
- Для завдань автоматизованого тестування рекомендується проєктний підхід.
- Проєктний підхід у завданнях автоматизованого тестування: Автоматизація тестування — проєкт усередині проєкту з розробки тестів Unit-тестування — частина автоматизації тестування, яку виконують самі програмісти Автоматизація потребує проєктного підходу до її етапів: планування, виділення ресурсів, проєктування, виконання та аналіз отриманих результатів Результати проєкту з автоматизації мають покривати заздалегідь визначені аспекти якості системи, що перебуває під тестом
Роботи завжди готові тобі допомогти, головне — навчи нас, запрограмуй, і ми зробимо все, що попросиш!
Види автоматизованого тестування
Залежно від об'єктів тестування виділяють такі види автоматизованого тестування:
- Функціональне тестування
- Нефункціональне тестування, або тестування продуктивності
- GUI-тести
- Тестування баз даних
Функціональне тестування дозволяє:
- Визначити відповідність заявлених функціональних вимог функціональності, реалізованій у системі під тестом
- Визначити, наскільки система регресувала порівняно з попереднім зафіксованим станом
- Переконатися в тому, що виявлені й виправлені раніше помилки не проявляються знову
- Виконати прогін тестів на максимально можливій кількості підтримуваних апаратно-програмних конфігурацій
- Використовувати для прогону тестів неробочий час тестувальників
- Виділити тестування усталеного функціоналу та нової функціональності
Тестування продуктивності дозволяє:
- Визначити час реакції застосунку
- Визначити, яку кількість користувачів може підтримувати система
- Визначити оптимальну конфігурацію системи
Навантажувальне тестування дозволяє:
- Перевірити продуктивність на різних програмно-апаратних конфігураціях
- Перевірити продуктивність системи за різних обсягів даних
- Визначити поведінку системи під стресовим навантаженням
Розуміння автоматизованого сценарію
- Фундамент автоматизованого сценарію
- Бізнес-транзакції
- Дії/операції
- Дані та параметризація
- Результати та контрольні точки
- Обробка виняткових ситуацій
- Аналіз отриманих результатів
- Практичні міркування
Фундамент автоматизованого сценарію
- За структурою автоматизований сценарій аналогічний тестовому сценарію для ручного тестування
- Основою для автоматизації є лише заздалегідь спроєктований тест, що покриває заявлену функціональність системи
- Допоміжна тестова функціональність, наприклад та, що повертає систему в консистентний стан після збою, має реалізовуватися окремими щодо тестових скриптів модулями. Така функціональність не повинна включатися в аналіз тестового покриття.
Бізнес-транзакції
- Бізнес-транзакція: послідовність дій та операцій, спрямованих на досягнення значущого для бізнесу або етапу технологічного процесу результату. Характеристики бізнес-транзакцій успадковуються від характеристик транзакцій із теорії баз даних
- Бізнес-транзакція — рекомендована величина вимірювання результатів автоматизованого тестового покриття
- Найкритичнішим із погляду навантажувального тестування параметром бізнес-транзакції є час
- Бізнес-транзакції в інформаційних системах, як правило, призводять до створення, видалення або зміни даних
- Бізнес-транзакції в системі — критерій вимірювання результатів навантажувального тестування
Слава роботам!
Дії/операції
- Операція — послідовність кроків/дій, що реалізується кінцевим користувачем, системним агентом або процесом, чи ж стороннім щодо системи актором, виконання якої призводить до значущого для користувача, системи або процесу, що автоматизується, результату
- Операція, або кінцева дія в системі, — атомарна одиниця автоматизації, яку можна використовувати під час планування
Дані та параметризація
- Вхідні дані та параметри тестів мають бути визначені на етапі проєктування тестування
- Дані, зовнішні щодо автоматизованого скрипту, мають зберігатися в зовнішніх підключуваних файлах під версійним контролем
Результати та контрольні точки
- Результати виконання тестового сценарію та час/«місце» контролю отриманих результатів мають бути визначені під час проєктування тестування
- Саме зіставлення очікуваних і отриманих результатів і є основним завданням автоматизованого сценарію
Обробка виняткових ситуацій
- Тест, окрім безпосередньо логіки виконання операцій «кінцевим користувачем», має включати логіку обробки виняткових ситуацій, а також мати пов'язану з ним спеціальну функціональність, що повертає систему в консистентний стан
Аналіз отриманих результатів
- Ідеальним із погляду аналізу результатів тестування можна вважати тест, який надає для аналізу в разі збою робочі дані (значення внутрішніх тестових змінних та «маркери» тестових даних) і «знімок» робочого стану системи (останні N рядків лога, скриншоти, дамп пам'яті тощо)
Практичні міркування
- Автоматизований тест, який потребує присутності тестувальника для оцінки результату тестування (ситуація, коли тест не дає однозначної відповіді, пройдено його чи ні) або для приведення системи в консистентний стан, не є завершеним і не може виконуватися багаторазово без участі «оператора».
- Зверніть увагу на акуратний опис тест-кейсів, призначених для автоматизації
Не смій недооцінювати роботів, ми настільки круті, що нам навіть поклонялися єгиптяни!
Коли тестування і розробка об'єднуються
Тестування на ранній стадії, наприклад під час написання коду, — колись інноваційна ідея, що дедалі більше приживається в масах, адже веде до значного підвищення якості коду. Пишіть тести заздалегідь — і ви матимете шанс виграти «кришталеву зірку» переможця галактичної першості. Крім того, можливості перевірити роботу коду та попередньо його налагодити, безсумнівно, підвищують швидкість розробки.
Але навіть знаючи все це, ми ще дуже далекі від часу, коли написання тестів до написання коду стане загальним стандартом. Так само як TDD стало наступним етапом еволюції екстремального програмування (eXP) і висунуло на перший план інфраструктуру для unit-тестування, наступний стрибок еволюції було зроблено з того рівня, де перебуває TDD. У цьому випадку від TDD еволюціонували до його інтуїтивного родича: behavior-driven development (BDD) — розробки, заснованої на поведінці. Але давайте по порядку.
Усі ці методики належать до гнучких методологій розробки програмного забезпечення. Нагадаємо, що гнучка методологія розробки (Agile) — це серія підходів до розробки програмного забезпечення, орієнтованих на використання ітеративної розробки, динамічне формування вимог і забезпечення їх реалізації в результаті постійної взаємодії всередині самоорганізованих робочих груп (Dev, QA, Product ...). Існує кілька методик, що належать до класу гнучких методологій розробки, зокрема екстремальне програмування, DSDM, Scrum, FDD, TDD, BDD, але нас цікавлять лише ті з них, що пов'язані з тестуванням
Розробка через тестування — TDD
Розробка через тестування (англ. test-driven development, TDD) — це сучасний стандарт розробки програмного забезпечення, який ґрунтується на повторенні дуже коротких циклів розробки: спочатку пишеться тест, що покриває бажану зміну, потім пишеться код, який дозволить пройти тест, і наприкінці проводиться рефакторинг нового коду до відповідних стандартів. Кент Бек, якого вважають винахідником цієї техніки, стверджував у 2003 році, що розробка через тестування дає змогу бути впевненим у продуктивності свого коду, що зрештою зменшує загальний час розробки. У 1999 році, коли розробка через тестування з'явилася, вона була тісно пов'язана з концепцією «спочатку тест» (англ. test-first), яку застосовують в екстремальному програмуванні, проте згодом виокремилася в незалежну методологію. В основі лежить unit-тест — це програмна процедура, яка дозволяє або підтвердити, або спростувати працездатність коду.
Техніку TDD легко уявити за допомогою такої схеми:
Тепер я докладніше поясню, як це працює:
1. На основі специфікації, мокапів та іншої вихідної документації пишеться тест. Для програми, яку ще навіть не написано. Якщо запустити такий тест, логічно, що він упаде.
2. Програміст пише код, створює програму, а тест править за індикатор. Щойно тест буде пройдено — код готовий.
3. Рефакторинг. Тест доробляється/переробляється внаслідок зміни вимог, за потреби додаються нові параметри. Рідко коли фічу приймають з першого разу.
Цей цикл може повторюватися n разів, доки програма не досягне бажаного стану.
Хмм... Чудова техніка! Я завжди вважав, що першим був тест, а вже потім код. Але я ось не розумію, яка тут роль тестувальника, якщо TDD — це підхід до програмування?
Чудове запитання для такої бляшанки, як ти! Ну, по-перше, ми вивчаємо процес автоматизації, а по-друге, нам необхідно навчитися процесу розробки через поведінку, в основі якого якраз і лежить TDD. Крім того, ми вступаємо в нову еру розробки, у якій тестувальник пише тести ще до того, як отримав програму в роботу. Власне, наш падаван уже навчився цього, працюючи з тест-планом.
Розробка, заснована на поведінці
Після того як ми дізналися, що сучасні методики розробки об'єднуються з тестуванням, утворюючи TDD, далі TDD еволюціонувало і утворило BDD (behavior-driven development), або розробку через поведінку. Швидше за все, ці абревіатури вже вас заплутали, і все злилося в суцільну абревіатурну кашу.
Але давайте звернемося до думки експертів.
Метт Вінн, один із розробників інтерпретатора BDD для фреймворку Cucumber Limited, передає суть технології так:
«Практики BDD досліджують, виявляють, визначають, а потім втілюють цю поведінку програмного забезпечення, використовуючи спілкування, конкретні приклади та автоматизовані тести».
Хане, мені здається чи це складна тема? Давай присядемо й усе гарненько обміркуємо. Для початку хотілося б дізнатися, як узагалі прийшли до ідеї BDD?
Я, як завжди, поспішаю рятувати галактику від ситхів, але маю хвилинку, щоб усе розкласти по поличках. Ось уяви: разом у зв'язці завжди працюють продакт-менеджер, тестувальник, програміст і замовник. І потрібно написати тести так, щоб:
а) Вони були зрозумілі кожному з них
б) Вони були структуровані за «зарезервованими фразами», щоб до тесту можна було прив'язати код автотесту
в) Тести були лаконічними
г) Кроки були універсальними, і їх можна було повторно використовувати в наступних тестах.
Як ти думаєш, що з вивченої тобою документації відповідає цим критеріям?
Давай перебирати все по порядку:
1) Тест-кейс. Я думаю, він не підійде ні за лаконічністю — вони зазвичай досить довгі й докладні, ні за структурованістю: вони годяться лише для ручного тестування.
2) Чек-лист лаконічний, але зрозумілий здебільшого лише тестувальнику, та й не структурований як треба. Теж ні.
3) Також не підійде use case / user story, це більше для продактів.
Хане Соло, варіантів немає, нам потрібне щось нове!
Ти мислиш правильно! До такого самого висновку прийшли й ті, хто практикував BDD. Потрібен підхід, який об'єднає тестувальників, програмістів, продактів, бізнес-аналітиків, замовників і дасть їм документацію, яку використовує й розуміє кожен. Тож давай попросимо Магістра пролити на нас мудрість BDD.
Як ви зрозумієте зі схеми нижче, BDD — це технологія створення тестових сценаріїв, яка накладається на TDD-тести й робить їх зрозумілими всім!
У підході BDD немає нічого революційного. Це просто еволюційне відгалуження підходу TDD, де слово «тест» замінено словом «повинен». Якщо відкласти слова вбік, багато хто знайде поняття «повинен» природнішим для процесу розробки, ніж поняття «тест». Мислення в термінах функціональності (того, що код має робити) призводить до підходу, коли спочатку пишуться класи для перевірки специфікації, які, своєю чергою, можуть виявитися дуже ефективним інструментом реалізації.
Як ви вже самі з'ясували, підхід BDD полягає в тому, щоб спробувати з'ясувати, чого ваш клієнт або бізнес хоче від програмного забезпечення, перш ніж почати над ним працювати. Перший спосіб зробити це — фактично співпрацювати з цими людьми.
Щойно ми отримаємо цю співпрацю, потрібно якось записати те, що матиме сенс для кожного, хто це переглядає, щоб будь-хто міг прийти й подивитися на це пізніше, зрозуміти, і якщо захоче — прокоментувати. Щоб досягти цього, потрібно використовувати загальнозрозумілу мову.
Люди часто використовують слова «Given», «When», «Then», «And» (укр. «Дано», «Коли», «Тоді», «І»), щоб побудувати ланцюжок логічних міркувань. Тож давайте застосовувати ці слова як ключові для побудови наших тестів, зрозумілих усім.
Отже, наш тестовий документ називатиметься сценарієм і використовуватиме лише ключові фрази для кожного кроку. Спочатку ми дамо переклад, а далі використовуватимемо лише англійські фрази. Наш сценарій будуватиметься за такою структурою:
GIVEN <context>
WHEN <event>
THEN <outcome>
Як це працює:
Дано <я приводжу систему, що тестується, у вихідний стан для тесту>
Коли <Я виконую дію>
Тоді <Я перевіряю результат>
А тепер приклад:
GIVEN Я залогінений у системі як користувач
WHEN Я відкриваю список вхідних повідомлень
THEN Я бачу 20 останніх повідомлень
Магістре, а як мені бути, якщо я хочу виконати дві дії для одного зі станів і не хочу їх поєднувати, тому що спільного в них нічого немає?
У такому разі використовують ключове слово AND. Таким чином можна додати допоміжний крок до будь-якого з ключових слів. Але не варто зловживати словом AND, адже якщо у вас забагато доповнень, то, найімовірніше, вам потрібно розбити ваш великий сценарій на менші.
Приклад використання AND:
GIVEN Я видаляю користувача <username> з бази даних
AND Я реєструю користувача <username> на сайті
WHEN Я заходжу на сайт під новим користувачем
THEN Я бачу привітання нового користувача
AND Я закриваю вікно привітання
Параметризація сценаріїв
Підкажіть, шановний Магістре, чи бувала у вашому житті ситуація, коли вам потрібно було повторити один і той самий тест, але з різними вхідними даними?
Я поки що не розумію, до чого ти хилиш, падаване. Так, раніше ми багаторазово виконували в тест-кейсах схожі перевірки з однаковими кроками, але різними вхідними даними, і записували їх, копіюючи кроки.
Усе вірно, і я так робив на третьому рівні, але мені завжди здавалося, що це можна якось уніфікувати та скоротити. Я вигадував різні таблиці з кроками та даними, але жодна з
них не виглядала достатньо привабливою, щоб стати еталоном.
Так воно й було, доки не почали активно використовувати BDD. Тоді, при використанні невеликих автотестів, знадобилася їх параметризація, щоб уникнути багаторазового дублювання. Придумали контурний сценарій (Scenario Outline). Він нічим не відрізняється від звичайного, крім того, що значення параметрів для тесту на кожному колі змінюються на наступні зі списку.
Щось мені закортіло випити свіжого соку. Давай напишемо сценарій для робота, який готує яблучний фреш. При цьому і фрукти для соку, і очікуваний результат ми вкажемо як параметри в самому тесті.
Feature: Навчання 03. Свіжий фреш.
Scenario: Готуємо фреш
Given Я кладу "яблука" в блендер
When Я вмикаю блендер
Then яблука мають перетворитися на "яблучний сік"
Цей приклад тесту містить зовнішню параметризацію: замість яблука можна вписати будь-який фрукт і його сік, і тест при цьому залишиться коректним. Головне — виконати кроки так, щоб вони були універсальними. Зазвичай у таких випадках оперують вхідними даними.
Хоча було б надто накладно обмежуватися лише яблуками, нехай робот уміє готувати будь-який фреш. Щоб зробити тест по-справжньому параметричним, ми замінимо конкретні яблука на абстрактні фрукти. А щоб відрізняти циклічно-параметричний сценарій від нециклічного, називатимемо його Scenario Outline (циклічний сценарій). Давайте спробуємо замовити роботу сік із «фрукта». Важливо розуміти, що будь-який циклічний сценарій має бути параметризованим.
Feature: Навчання 04. Параметричний фреш.
Scenario: Готуємо фреш із будь-якого "фрукта"
Given Я кладу "фрукти" в блендер
When Я вмикаю блендер
Then Фрукти мають перетворитися на "сік"
Examples: Соки
| фрукт | сік |
| яблуко | яблучний сік |
| тасиліанський огірок | тасиліанський сік |
Examples: Електроприлади
| пристрій | сік |
| Iphone X | токсичний сік |
| Samsung Galaxy S9 | токсичний сік |
Як ви бачите з цього прикладу, у тест як параметри можна подавати будь-які дані, але й результат має бути відповідним (інакше тест не пройде). Під час запуску тесту на кожному колі він проходитиме з новим параметром із таблиці, доки не пройде їх усі.
Приклади робочих сценаріїв Магістра
@login @settings @onboarding
Feature: chorus log in tests for all available ways: login/pass, google, microsoft, self-serve
BDD-тест може бути простим, містячи лише Given, When, Then;
@login
Scenario: Login tests with via email and password
Given I restart driver And I go to home page
When I do log in with registered email user
Then I check I am at account page
Але часто потрібні допоміжні кроки, які додаються через And;
@xray
@pop
Scenario: opening first card on X-ray page leads to popup containing relevant trackers
Given I am on xray tab of target call
When I click on the first Card
Then corespondent card is displayed
And all trackers are collapsed
And displayed moments count matches actual amount
And I close x-ray moment Popup
Як ми вивчили, буває також зовнішня параметризація сценарію тестовими даними;
@account_page
Scenario: share transcript item
Given I am at transcript of a target call
When I select "3" transcript item
And I open the transcript's menu
And I select "Share Moment" from transcript menu
When click edit share
Then Start time for share equals to moment time
And I close share popup window by clicking "X"
Також цілком може використовуватися разом і проста параметризація, і циклічна параметризація. Одні параметри просто передаються, а інші змінюються в кожному циклі.
@account_search_bar_mobile
Scenario Outline: I search the calls for <search_text> via search bar and clear with x
Given I am at mobile account page starting state
When I go to call "4 - Needs Analysis" on the mobile account page
And I search for "<search_text>"
Then I find expected results for "<search_text>" search
And Mobile section "transcript" is active
And I make sure transcript search bar is closed and cleared by clicking on clear search
Examples: Text Searches
| search_text |
| hi |
| pricing OR okay |
А в цьому прикладі ми спостерігаємо використання лише циклічної параметризації
@moments
@moments_search
Scenario Outline: Search for specific moment, adds result to legend
Given I am at moments search starting state
And I set timeframe filter to "Last 52 Weeks"
And I click apply for filter popup
When I input and select in search <moment_name>
And I select <moment_name> suggestion
Then <moment_name> appear in search bar
And For each moment from search bar exists graph name
Examples: moments names
| moment_name |
| Citizenship |
| Goals |
Аналіз результатів запуску автотестів
Далі наведено ознайомчий фрагмент результатів запуску автоматизованих сценаріїв у форматі BDD. І сьогодні я навчу тебе розуміти мову роботів. Для цього R2D2 розшифрує всі значення лог-файлів. Після цього ти навчишся розуміти й аналізувати результати автотестів.
Мій усе ще юний джедаю тестування, хочу втішити тебе тим, що мова роботів завжди однозначна. У нас не буває натяків чи двозначностей. Усе так, як є. Хіба що нюанс у тому, що це англійською: саме ця мова визнана основною для всіх роботів. Далі я дам пояснення для всіх важливих команд та етапів у баг-репорті.
Перш ніж мій нетерплячий робо-друг проаналізує баг-репорт, я розповім трохи про його історію. Цей лог було отримано під час запуску автотесту на одному з моїх дааавніх проєктів. Ми тоді займалися перетворенням людської мови. Так от, ця система дозволяє об'єднувати записи мови в плейлисти, і саме для цієї фічі було створено цей тестовий набір під назвою playlists_page. Тести записано за допомогою методики BDD, а виконано мовою Python.
Тобі б лише побалакати! Не так важливо, до якого проєкту й мови належать автотести, нам зараз важливо навчитися читати логи, адже практично всі використовують фреймворк Selenium, і помилки, що виникають під час падіння тестів, практично однакові для всіх мов! Отже, переходимо до розбору лога! По ходу я даватиму тобі посилання на технологічні системи, які використовувалися, просто для ознайомлення.
Running with gitlab-runner 10.0.1 (e991d1b4)
on gitlab-runner-18.194.129.84 (be743b2e)
Using Docker executor with image docker.affectlayer.com:5000/al/automation-ci:5.0 ...
Using docker image sha256:53e5a6b45f119e089b21856075b2ae0e8605eb2edebd725869ec4a7da3813dca for predefined container...
Pulling docker image docker.affectlayer.com:5000/al/automation-ci:5.0 ...
Using docker image docker.affectlayer.com:5000/al/automation-ci:5.0 ID=sha256:80a33c4c7b02376166eb6fb1fae24073a8590fd631e35a13e93e4774b38ed43e for build container...
Running on runner-be743b2e-project-26-concurrent-3 via 1b70c615557b...
Cloning repository...
Cloning into '/builds/affectlayer/system_tests'...
Checking out d03637d8 as system_tests#54-new-pipeline...
Skipping Git submodules setup
$ export DBUS_SESSION_BUS_ADDRESS=/dev/null
$ echo $FRONTEND_LINK
$ mkdir -p dist
$ if [ -z "$FRONTEND_LINK" ];then CHORUS_LINK=$PROD_LINK; else CHORUS_LINK="${FRONTEND_LINK}"; fi
$ if [ -z "$RUN_MODE" ];then RUN_MODE='@self_service'; else RUN_MODE="${RUN_MODE}"; fi
$ if [ $RUN_MODE != '@self_service' ];then RUN_MODE='@nothing'; fi
$ echo $FRONTEND_LINK
$ echo $CHORUS_LINK
hello.chorus.ai
$ export TZ=$TIME_ZONE
$ Xvfb :1 -screen 5 1920x1200x8 &
$ export DISPLAY=:1.5
$ behave --tags=$RUN_MODE -k -D build_id=$BUILD_ID -D username=selfserve8@selfservechorus.com -D password=aA1\!aA1\!a -D user_type=self-serve -D chorus_link=$CHORUS_LINK -D timeout=$TIMEOUT || behave @rerun_failing.features --tags=$RUN_MODE -k -D build_id=$BUILD_ID -D username=selfserve8@selfservechorus.com -D password=aA1\!aA1\!a -D user_type=self-serve -D chorus_link=$CHORUS_LINK -D timeout=$TIMEOUT
waiting for version to update...600 seconds
@self_service @all @playlists
Feature: playlists # features/playlists.feature:4
@all @playlists @self_service @new_playlist @playlists_page
Scenario: Creating a new playlist via playlists page # features/playlists.feature:11
Given I am in playlists page # features/steps/playlists.py:15
When I create a new playlist # features/steps/playlists.py:30
Then toast pops up and disappears # features/steps/playlists.py:38
And a new empty playlist is created # features/steps/playlists.py:49
@self_service @playlists_page @existing_playlist
Scenario: It should not be possible to add a playlist with existing playlist's name # features/playlists.feature:20
Given I am in playlists page # features/steps/playlists.py:15
When I create a new playlist with existing name # features/steps/playlists.py:67
Then "existing playlist" error message appears # features/steps/playlists.py:81
And created playlist exists only once # features/steps/playlists.py:92
@self_service @playlists_page @deleting_playlist
Scenario: When I delete a playlist I created it is deleted # features/playlists.feature:29
Given I am in playlists page # features/steps/playlists.py:15
Given I create a playlist # features/steps/playlists.py:128
When I delete last created playlist # features/steps/playlists.py:134
Then last created playlist is deleted, even after refreshing the page # features/steps/playlists.py:145
And I delete all created playlists # features/steps/playlists.py:139
@all @self_service @playlists_page @search_playlist
Scenario: Only relevant playlists appear when searching playlists # features/playlists.feature:49
Given I am in playlists page # features/steps/playlists.py:15
Given a list with more than one playlist # features/steps/playlists.py:99
When I search for the exact name of one of them (that does not contain the other) # features/steps/playlists.py:105
Then only playlists with relevant names appear # features/steps/playlists.py:118
Test for feature [u'self_service', u'all', u'playlists'] completed
waiting for version to update...600 seconds
@self_service @all @playlists-mobile
Feature: playlists # features/playlists_mobile.feature:4
@self_service @all @playlists-mobile
Scenario: Check pre-defined playlist # features/playlists_mobile.feature:18
Given I am at playlist mobile starting state # features/steps/playlists_mobile.py:12
When I select playlist Default_not_empty_playlist # features/steps/playlists_mobile.py:29
Then I check Playlsit moments list as expected # features/steps/playlists_mobile.py:50
Assertion Failed: Incorrect opp of first moment
And I check name is Default_not_empty_playlist and owner of playlist is the main header user # None
@self_service @all @playlists-mobile
Scenario: Play playlist # features/playlists_mobile.feature:27
Given I am at playlist mobile starting state # features/steps/playlists_mobile.py:12
When I select playlist Default_not_empty_playlist # features/steps/playlists_mobile.py:29
And I activate account ghost # features/steps/playlists_mobile.py:98
And I press the playlist play button # features/steps/playlists_mobile.py:116
Then Playlist is played # features/steps/playlists_mobile.py:104
When I press the playlist pause button # features/steps/playlists_mobile.py:122
And Playlist is paused # features/steps/playlists_mobile.py:110
@self_service @all @playlists-mobile
Scenario: Only relevant playlists appear when searching playlists # features/playlists_mobile.feature:39
Given I am at playlist mobile starting state # features/steps/playlists_mobile.py:12
When I search for Default_not_empty_playlist of in mobile playlists # features/steps/playlists_mobile.py:76
Then I check search result is Default_not_empty_playlist # features/steps/playlists_mobile.py:86
Test for feature [u'self_service', u'all', u'playlists-mobile'] completed
waiting for version to update...600 seconds
@self_service @trial
Feature: Trial for self serve # features/trial.feature:3
@self_service @trial
Scenario: when i log into chorus with a user on trial top right corner should show remaining trial time # features/trial.feature:7
Given I am at chorus logged in as self serve # features/steps/trial.py:7
When I set end time for five days on self serve user # features/steps/trial.py:44
When I am logged in as self serve i see trial bar # features/steps/trial.py:13
Then I click on extend trial # features/steps/trial.py:19
And I move to trial page # features/steps/trial.py:26
No handlers could be found for logger "behave"
@self_service @trial
Scenario: when i go to chorus trial page and invite sales reps # features/trial.feature:34
Given I am at chorus logged in as self serve # features/steps/trial.py:7
When I set end time for five days on self serve user # features/steps/trial.py:44
Then I click on extend trial # features/steps/trial.py:19
And I click on invite sales reps # features/steps/trial.py:75
And I set end time for five days on self serve user # features/steps/trial.py:44
........ тут ще купа пройдених тестів ......
@self_service @trial_mobile
Scenario: when i go to chorus mobile trial and change trial time to unlimited # features/trial_mobile.feature:34
Given I am at chorus mobile logged in as self serve # features/steps/trial_mobile.py:8
When I set end time to unlimited on self serve user # features/steps/trial.py:51
Then web time will show unlimited on mobile # features/steps/trial_mobile.py:28
Test for feature [u'self_service', u'trial_mobile'] completed
Failing scenarios:
features/playlists_mobile.feature:18 Check pre-defined playlist
@self_service @all @playlists-mobile
Scenario: Check pre-defined playlist # features/playlists_mobile.feature:18
Given I am at playlist mobile starting state # features/steps/playlists_mobile.py:12
When I select playlist Default_not_empty_playlist # features/steps/playlists_mobile.py:29
Then I check Playlsit moments list as expected # features/steps/playlists_mobile.py:50
Assertion Failed: Incorrect opp of first moment
Test for feature [u'self_service', u'all', u'playlists-mobile'] completed
And I check name is Default_not_empty_playlist and owner of playlist is the main header user # None
@all @login
Scenario: Login tests with sales force credentials # features/login.feature:8
Given I restart driver # features/steps/onboarding_selfserve.py:23
And I go to chorus page # features/steps/login.py:12
When I log in with registered sfdc user # features/steps/login.py:68
Traceback (most recent call last):
File "/usr/local/lib/python2.7/dist-packages/behave/model.py", line 1329, in run
match.run(runner.context)
File "/usr/local/lib/python2.7/dist-packages/behave/matchers.py", line 98, in run
self.func(context, *args, **kwargs)
File "features/steps/login.py", line 80, in sfdc_login
login_page.login_to_sfdc(Constants.SFDC_ONBOARDING_EMAIL, Constants.SFDC_ONBOARDING_PASSWORD)
File "/builds/affectlayer/system_tests/drivers/landing_page/new_login_page.py", line 76, in login_to_sfdc
sf_login_page.name_input().add_text(username)
File "/builds/affectlayer/system_tests/drivers/landing_page/sales_force_login_page.py", line 15, in name_input
return Input(self.wait_component_to_load((By.ID, "username")))
File "/builds/affectlayer/system_tests/drivers/basic_components/page_base.py", line 20, in wait_component_to_load
EC.visibility_of_element_located(by_locator))
File "/usr/local/lib/python2.7/dist-packages/selenium/webdriver/support/wait.py", line 71, in until
value = method(self._driver)
File "/usr/local/lib/python2.7/dist-packages/selenium/webdriver/support/expected_conditions.py", line 127, in __call__
return _element_if_visible(_find_element(driver, self.locator))
File "/usr/local/lib/python2.7/dist-packages/selenium/webdriver/support/expected_conditions.py", line 398, in _find_element
return driver.find_element(*by)
File "/usr/local/lib/python2.7/dist-packages/selenium/webdriver/remote/webdriver.py", line 843, in find_element
'value': value})['value']
File "/usr/local/lib/python2.7/dist-packages/selenium/webdriver/remote/webdriver.py", line 306, in execute
response = self.command_executor.execute(driver_command, params)
File "/usr/local/lib/python2.7/dist-packages/selenium/webdriver/remote/remote_connection.py", line 464, in execute
return self._request(command_info[0], url, body=data)
File "/usr/local/lib/python2.7/dist-packages/selenium/webdriver/remote/remote_connection.py", line 488, in _request
resp = self._conn.getresponse()
File "/usr/lib/python2.7/httplib.py", line 1136, in getresponse
response.begin()
File "/usr/lib/python2.7/httplib.py", line 453, in begin
version, status, reason = self._read_status()
File "/usr/lib/python2.7/httplib.py", line 417, in _read_status
raise BadStatusLine(line)
httplib.BadStatusLine: ''
@xray @play
Scenario: playing a moment from x-ray card # features/call_xray.feature:41
Given I am on xray tab of target call # features/steps/x-ray.py:16
Traceback (most recent call last):
File "/usr/local/lib/python2.7/dist-packages/behave/model.py", line 1329, in run
match.run(runner.context)
File "/usr/local/lib/python2.7/dist-packages/behave/matchers.py", line 98, in run
self.func(context, *args, **kwargs)
File "features/steps/x-ray.py", line 22, in step_impl
context.account_page.wait_until_account_page_finished_loading()
File "/builds/affectlayer/system_tests/drivers/account_page/account_page_executor.py", line 301, in wait_until_account_page_finished_loading
self.wait_for_chorus_page_to_load()
File "/builds/affectlayer/system_tests/drivers/basic_components/page_base.py", line 60, in wait_for_chorus_page_to_load
self.wait_for_component_disappear((By.CSS_SELECTOR, 'div.chorus-loading'), 60)
File "/builds/affectlayer/system_tests/drivers/basic_components/page_base.py", line 40, in wait_for_component_disappear
.until(EC.invisibility_of_element_located(by_locator))
File "/usr/local/lib/python2.7/dist-packages/selenium/webdriver/support/wait.py", line 80, in until
raise TimeoutException(message, screen, stacktrace)
selenium.common.exceptions.TimeoutException: Message:
3 features passed, 1 failed, 28 skipped
13 scenarios passed, 1 failed, 230 skipped
5 steps passed 9, 1 failed, 1519 skipped,
Took 4m33sec
Привіт! Як ти, напевно, зрозумів, винятки можуть бути зовсім різних типів, і логічно, що вони не можуть випасти в одному лозі. Тому список найпоширеніших винятків я зібрав для тебе окремо.
Привіт, я думаю, що ти чудово зрозумів матеріал. Але якщо чесно, у мене залишилися запитання щодо всіх цих фразочок TDD, BDD. Кажуть, матеріал краще засвоюється, якщо його пояснити іншому. Я хотів би знати:
Яка роль тестувальника в розробці через тестування?
Як працює методологія TDD?
У чому суть методології BDD?
Навіщо потрібна зовнішня параметризація, якщо в тесті немає циклічної параметризації?
Що таке виняток в автоматизації?
Домашнє завдання і практика
У практичному завданні тобі доведеться показати, що ти можеш думати як робот. Стати майстром над роботами. Для імплементації автотесту на рівні 17 тобі доведеться спочатку написати автоматизовані сценарії. Автоматизувати ми будемо наш улюблений сайт печива! Створити потрібно сценарії для перевірки:
- Перевірити роботу галереї на головній (збільшення картинки)
- Перевірити надсилання повідомлення на сторінці contact us
- Перевірка навігації по меню
- Замовлення однієї з цукерок (властивості — параметри)
- Замовлення печива (тип — параметр)
- Зміна кількості товарів у кошику (кількість — параметр)
- Оформлення замовлення в кошику
У цьому завданні тобі потрібно написати 7 BDD-сценаріїв у Google Doc, а завдання надсилати через форму. До речі, у Магістра для тебе теж є завданнячко.