Vocabulary for Test Automation Engineers

Автоматизація тестування має свій власний багатий словник. Якщо ви працюєте інженером з автоматизації тестування — або якщо ви тісно співпрацюєте з QA — можливість обговорювати концепції тестування точно англійською мовою зробить ваші перегляди коду, обговорення архітектури і документації набагато ефективнішими.

Цей посібник містить найважливіші терміни щодо структури тестування, інструментів і стратегії якості.

---

Випробування архітектури

Тестова піраміда

Піраміда тестування є моделлю, яка описує ідеальне розподіл тестів у програмному проекті. Він був популяризований Майком Коном, а пізніше вдосконалений Мартіном Фаулером.

• ** Одиночні тести ** (основа піраміди) — багато, швидко, дешево, ізольовано
• ** Тести інтеграції ** (середній) — менше, тестування взаємодії компонентів
• ** Перевірка всіх компонентів системи ** (верхня частина) — найменше, повільно, перевірка всієї системи

“Наш набір тестів не слідує піраміді — у нас більше тестів від початку до кінця, ніж тестів на одиницю, саме тому конвеєр займає сорок хвилин для запуску.” “Ми перевертаємо піраміду. Метою цього кварталу є замінити крихкі E2E тести швидкими, цілевказуючими тестами інтеграції. “

Пробний ланцюг

** Система тестування ** — це набір програмного забезпечення, інструментів і даних, які використовуються для автоматичного виконання тестів і повідомлення про їх результати.

“Тестовий набір запускає середовище Docker Compose перед кожним запуском тесту і розбиває його після запуску.” “Ми успадкували тестовий набір від попередньої команди - він працює, але погано задокументований і важко розширити.”

---

Тестові дані і налаштування

Fixtures

** Встановлення ** — це дані і налаштування середовища, які потрібні для запуску тесту. Пристрої забезпечують, що кожен тест починається з відомого, послідовного стану.

“База даних запускає трьох користувачів і дві організації перед запуском кожного тестового пакету.”

• “Ми пересунули наші інструменти у спільний модуль, щоб кожен тестовий файл міг імпортувати їх без дублювання.” *

Налаштування і розбирання

** Setup ** (або beforeEach / beforeAll ) виконується перед тестуванням. ** Teardown ** (або afterEach / afterAll ) очищає після тестування.

“Налаштування створює тимчасовий контейнер S3; розбирання вилучає його і весь його вміст після завершення тестування.”

Двійкове тестування

** test double ** — це будь- який об’ єкт, який замінює реальну залежність у тесті. До підтипів належать:

• ** Мок ** — дублікат, який записує виклики і може перевіряти очікування
• ** Stub ** — подвійний, який повертає заздалегідь визначені значення
• ** Spy ** — подвійний, який обгортає реальний об’ єкт і записує виклики
• ** False ** — спрощена робоча реалізація (наприклад, база даних у пам’ яті)

• “Ми заблокували шлюз платежу, щоб повернути відповідь про успіх без здійснення реальних викликів API.” *
• “Модель перевіряє, чи було викликано службу сповіщення десь один раз з правильним ідентифікатором користувача.” *

---

Випробування якості

Проводяться тестові випробування

flaky test це тест, який іноді проходить, а іноді провалюється з причин, не пов’ язаних з кодом під час тестування - зазвичай проблеми з часом, мережеві залежності або спільний стан.

*“У нас близько п’ятнадцяти тестів з тріщинами в наборі E2E. Вони викликають фальшиві невдачі в CI і розмивають довіру команди в трубопроводі». * “Недосконале тестування гірше, ніж відсутність тестування — воно навчає інженерів ігнорувати помилки.”

** Поширені причини лущення: **

• Умови гонки або залежності часу
• Перевірки, що діляться змінним станом
• Покладатися на зовнішні послуги
• Недетерміністичне тестове замовлення

“Ми поставили на карантин тести з тріщинами в окремому завданні, щоб вони не блокували розгортання, поки ми розслідуємо.”

Assertions

** твердження ** — це речення у тесті, яке перевіряє чи відповідає фактичний вивід очікуваному виводу. Якщо твердження зазнає невдачі, то і тест зазнає невдачі.

“Тест стверджує, що код стану відповіді 201 і що повернений ідентифікатор є коректним UUID.” “Ми використовуємо м’які утвердження у наших тестах API, щоб всі помилки утверджень були зібрані і повідомлені разом, а не зупинялися на першій помилці.”

---

Тестові моделі

Об’єктна модель сторінки (POM)

** Модель об’ єкта сторінки ** — це шаблон проектування для автоматизації тестування інтерфейсу користувача, у якому кожна сторінка (або компонент) програми представлена як клас. Методи тестування взаємодіють зі сторінкою за допомогою цього класу, а не безпосередньо за допомогою селекторів DOM.

• “Ми переробили наші тести Playwright, щоб використовувати модель об’ єкта сторінки. Тепер, коли змінюється сторінка входу, ми оновлюємо тільки один клас замість тридцяти тестових файлів.”*
• “Клас LoginPage містить всі селектори і взаємодії потоку реєстрації, що робить тестовий код зрозумілим і зручним для користувача.” *

Перевірка даних

** Тестування за допомогою даних ** виконує одну і ту ж логіку тестування на декількох наборах вхідних даних, які зазвичай містяться у таблиці або зовнішньому файлі.

“Ми використовуємо підхід, заснований на даних, для наших тестів перевірки — одна і та ж тестова функція працює проти сорока комбінацій дійсних і недійсних вхідних даних.”

Контрактне тестування

** Тестування контрактів ** перевіряє, чи дві служби (зазвичай, споживач і постачальник) погоджуються щодо структури API або повідомлень між ними. Пакт - це найпоширеніший інструмент.

• “Ми додали тести контрактів між інтерфейсом і службою користувача, щоб будь- які зміни API були виявлені перед розгортанням.” *

---

Метрика та звітність

Покриття коду

** Покриття коду ** вимірює відсоток виробничого коду, який використовується пакетом тестування. Серед звичайних типів — покриття рядка, покриття гілки і покриття команди.

“Ми маємо 78% покриття рядків, але наше покриття гілок становить лише 52% — що означає, що багато умовної логіки не перевірено.”

Перевірити ступінь лущення

• “Наш рівень тріщини в наборі E2E становить близько 8%. Промислова ціль нижче 1%.”*

---

Практичні фрази для тестування інженерів автоматизації

• • “Ця перевірка не є детермінованою — нам потрібно знайти і вилучити залежність часу.” *
• • « Пристрій не скидає спільний стан між тестами, що спричиняє зараження між тестами. » *
• “Я б рекомендував пересунути це твердження в рівень тестування інтеграції, а не в рівень E2E — там його буде набагато швидше запускати.”
• “Ми повинні додати тут тест контракту, щоб захистити від порушень змін до цього API.”
• • “Об’ єкт сторінки містить логіку селекторів, отже, тест читається як специфікація.” *

---

Точний словник тестування дозволяє краще розуміти плани тестування, краще переглядати код і більш продуктивно обговорювати стратегію якості. Наведені вище терміни є стабільними у більшості технологічних стеків і будуть вам корисними у Python, JavaScript, Java і інших мовах.

Національний мовний стандарт: спільні вимоги до мовлення

Як нерідний мовець, що розвивається в професійному середовищі, особливо в тестуванні програмного забезпечення, ви швидко усвідомите, що технічний словник є лише частиною виклику. * Спосіб *, у який ви спілкуєтеся — ваша фраза, тон і розуміння тонких нюансів — може значно вплинути на співпрацю з колегами, особливо під час перегляду коду або при поясненні складних сценаріїв тестування. Це не просто про знання слів; це про передачі значення чітко і ефективно. Однією з найчастіших перешкод є інтерпретація зворотного зв’язку, часто доставляється з рівнем точності, який може здатися неясним для когось, хто пристосовується до більш формальної англійської мови. Наприклад, рецензент може прокоментувати невдалий тест як «це має бути більш надійним» без відразу вказати * чому * надійність відсутня. Ця неоднозначність може призвести до марного часу і розчарування — як для вас, так і для рецензента. Аналогічно, під час розмов Slack, обговорюючи результати тестів, уникнення надмірно буквальних перекладів технічних термінів є критичним. Просто сказати «тест зазнав невдачі» може не передати невідкладність або потенційну основну проблему так ефективно, як щось на зразок «Регресійний тест для входу користувача постійно повертає помилку; нам потрібно дослідити»

Іншою областю, де ретельне формулювання стає важливим, є описи запитів на завантаження. Коли змінюється деталізація, найкраще не просто вказати * що * ви зробили, а зосередитись на * чому *. Замість « Виправлено помилку X », розгляньте « Впроваджено механізм повторних спроб для виклику API, щоб обробляти проблеми з мережею, які спричиняли хибні негативні результати у тестовому наборі Y. » Це демонструє розуміння, активне вирішення проблем і допомагає рецензентам швидко зрозуміти контекст вашої роботи. Крім того, навчання сформулювати свій процес мислення - пояснювати як ви прийшли до певного рішення - є безцінним. Навіть якщо кінцевий розв’язок не ідеальний, демонстрація чітких міркувань будує довіру і заохочує конструктивний зворотній зв’язок. Ви можете почути такі фрази, як « Давайте дослідимо альтернативні підходи » або « Чи можемо ми розглянути використання [фрейму/бібліотеки] для цього?» Це запрошення до обговорення, а не критика вашої початкової роботи. Пам’ ятайте, активний підхід до спілкування сприяє більш продуктивному та продуктивному середовищі тестування.

Також важливо визнати, що різні команди мають трохи відмінні конвенції. Деякі команди можуть надавати перевагу короткості в повідомленнях Slack, в той час як інші надають перевагу докладним поясненням. Спостерігайте, як спілкуються ваші колеги, і відповідно змінюйте свій стиль. Не бійтеся ввічливо просити про пояснення, якщо щось не зрозуміло — набагато краще шукати розуміння, ніж робити припущення. Нарешті, активне пошуки зворотнього зв’язку на вашому письмовому спілкуванні - особливо описи PR - може значно поліпшити вашу ясність і ефективність. Швидкий перегляд колегою може підкреслити області, у яких ви можете вдосконалити ваші фрази або надати більше контексту.

Ось приклад використання pytest для налаштування тестового середовища з інструментами:

import pytest

@pytest.fixture(scope="session")
def database_connection():
    # Simulate establishing a database connection
    print("Connecting to the database...")
    yield "test_database"  # Return a placeholder for testing purposes
    print("Closing database connection.")

Цей інструмент надає вам послідовне, попередньо налаштоване середовище для ваших тестів, забезпечуючи повторюваність і скорочуючи час налаштування. scope="session" забезпечує, що з’єднання з базою даних встановлюється тільки один раз за тестовий сеанс, покращуючи продуктивність. Використання інструментів ефективно демонструє чітке розуміння принципів автоматизації тестування і сприяє більш надійним і надійним тестовим наборам.