Відкривається passed smoke test виконати перевірку що. Тестування

• Tutorial

Доброго вам дня!

Хочу зібрати всю необхідну теорію з тестування, яку запитують на співбесідах у trainee, junior і трошки middle. Власне, я зібрав уже багато. Мета цього посту в тому, щоб спільно додати втрачене і виправити/перефразувати/додати/зробитиЩоЩе з тим, що вже є, щоб стало добре і можна було взяти все це і повторити перед черговою співбесідою про всяк випадок. Втім, колеги, прошу під кат, кому почерпнути щось нове, кому систематизувати старе, а кому зробити свій внесок.

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

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

У темі: визначення тестування, якість, верифікація / валідація, цілі, етапи, тест план, пункти тест плану, тест дизайн, техніки тест дизайну, traceability matrix, tets case, чек-лист, дефект, error/deffect/failure, баг репорт , severity vs priority, рівні тестування, види / типи, підходи до інтеграційного тестування, принципи тестування, статичне та динамічне тестування, дослідницьке / ad-hoc тестування, вимоги, життєвий цикл бага, стадії розробки програмного забезпечення, decision table, qa/qc/test Engineer, діаграма зв'язків.

Поїхали!

Тестування програмного забезпечення- перевірка відповідності між реальною та очікуваною поведінкою програми, що здійснюється на кінцевому наборі тестів, обраному певним чином. У більш широкому сенсі, тестування - це одна з технік контролю якості, що включає активності з планування робіт (Test Management), проектування тестів (Test Design), виконання тестування (Test Execution) і аналізу отриманих результатів (Test Analysis).

Якість програмного забезпечення (Software Quality)- це сукупність параметрів програмного забезпечення, які належать до його здатності задовольняти встановлені та передбачувані потреби.

Верифікація (verification)- це процес оцінки системи або її компонентів з метою визначення, чи задовольняють результати поточного етапу розробки умов, сформованих на початку цього етапу. Тобто. чи виконуються наші цілі, терміни, завдання розробки проекту, визначені на початку поточної фази.
Валідація (validation)- це визначення відповідності розроблюваного ПЗ очікуванням та потребам користувача, вимогам до системи.
Також можна зустріти іншу інтерпретацію:
Процес оцінки відповідності продукту явним вимогам (специфікаціям) і є верифікація (verification), водночас оцінка відповідності продукту очікуванням та вимогам користувачів є валідація (validation). Також часто можна зустріти таке визначення цих понять:
Validation - 'is ​​this the right specification?'.
Verification - 'is ​​the system correct to specification?'.

Цілі тестування
Підвищити ймовірність того, що додаток, призначений для тестування, працюватиме правильно за будь-яких обставин.
Підвищити ймовірність того, що програма, призначена для тестування, буде відповідати всім описаним вимогам.
Надання актуальної інформації про стан продукту зараз.

Етапи тестування:
1. Аналіз
2. Розробка стратегії тестування
та планування процедур контролю якості
3. Робота з вимогами
4. Створення тестової документації
5. Тестування прототипу
6. Основне тестування
7. Стабілізація
8. Експлуатація

Тест план (Test Plan)- це документ, що описує весь обсяг робіт із тестування, починаючи з опису об'єкта, стратегії, розкладу, критеріїв початку та закінчення тестування, до необхідного в процесі роботи обладнання, спеціальних знань, а також оцінки ризиків з варіантами їх вирішення.
Відповідає на запитання:
Що треба випробувати?
Що тестуватимете?
Як тестуватимете?
Коли тестуватимете?
Критерії початку тестування.
Критерії закінчення тестування.

Основні пункти тест плану
У стандарті IEEE 829 перераховані пункти, з яких повинен (нехай може) складатися тест-план:
a) Test plan identifier;
b) Introduction;
c) Test items;
d) Features to be tested;
e) Features not to be tested;
f) Approach;
g) Item pass/fail criteria;
h) Suspension criteria and resumption requirements;
i) Test deliverables;
j) Testing tasks;
k) Економічні потреби;
l) Responsibilities;
m) StafÞng and training needs;
n) Schedule;
o) Risks and contingencies;
p) Approvals.

Тест дизайн- це етап процесу тестування ПЗ, на якому проектуються та створюються тестові випадки (тест кейси), відповідно до визначених раніше критеріїв якості та цілей тестування.
Ролі, відповідальні за тест дизайн:
Тест аналітик – визначає «ЩО тестувати?»
Тест дизайнер – визначає «ЯК тестувати?»

Техніки тест дизайну

Еквівалентний Поділ (Equivalence Partitioning – EP). Як приклад, у вас є діапазон допустимих значень від 1 до 10, ви повинні вибрати одне правильне значення всередині інтервалу, скажімо, 5, і одне неправильне значення поза інтервалом - 0.

Аналіз Граничних Значень (Boundary Value Analysis – BVA). Якщо взяти приклад вище, як значення для позитивного тестування виберемо мінімальну і максимальну межі (1 і 10), і значення більше і менше меж (0 і 11). Аналіз Граничний значень може бути застосований до полів, записів, файлів, або до будь-яких сутностей, що мають обмеження.

Причина/Слідство (Cause/Effect - CE). Це, як правило, введення комбінацій умов (причин) для отримання відповіді від системи (Слідство). Наприклад, ви перевіряєте можливість додавати клієнта, використовуючи певну екранну форму. Для цього вам необхідно буде ввести кілька полів, таких як "Ім'я", "Адреса", "Номер Телефону", а потім натиснути кнопку "Додати" - ця "Причина". Після натискання кнопки «Додати» система додає клієнта в базу даних і показує його номер на екрані - це «Слідство».

Вичерпне тестування (Exhaustive Testing – ET)- Це крайній випадок. У межах цієї техніки ви повинні перевірити всі можливі комбінації вхідних значень, і в принципі це має знайти всі проблеми. Насправді застосування цього методу неможливо, через велику кількість вхідних значень.

Traceability matrix- Матриця відповідності вимог - це двовимірна таблиця, що містить відповідність функціональних вимог (functional requirements) продукту та підготовлених тестових сценаріїв (test cases). У заголовках колонок таблиці розташовані вимоги, а заголовках рядків - тестові сценарії. На перетині - відмітка, що означає, що вимога поточної колонки покрита тестовим сценарієм поточного рядка.
Матриця відповідності вимог використовується QA-інженерами для валідації покриття продукту тестами. МСТ є невід'ємною частиною тест-плану.

Тестовий випадок (Test Case)- це артефакт, що описує сукупність кроків, конкретних умов і параметрів, необхідних для перевірки реалізації функції або її частини, що тестується.
Приклад:
Action Expected Result Test Result
(passed/failed/blocked)
Open page «login» Login page is opened Passed

Кожен тест кейс повинен мати 3 частини:
PreConditions Список дій, які призводять систему до стану придатного для проведення основної перевірки. Або перелік умов, виконання яких свідчить, що система перебуває у придатному щодо основного тесту стану.
Test Case Description Список дій, що переводять систему з одного стану в інший, для отримання результату, на підставі якого можна зробити висновок про задоволення реалізації, поставленим вимогам
PostConditions Список дій, що переводять систему в початковий стан (стан до проведення тесту - initial state)
Види Тестових Випадків:
Тест кейси поділяються за очікуваним результатом на позитивні та негативні:
Позитивний тест кейс використовує тільки коректні дані і перевіряє, що програма правильно виконала функцію, що викликається.
Негативний тест кейс оперує як коректними так і некоректними даними (мінімум 1 некоректний параметр) і ставить за мету перевірку виняткових ситуацій (спрацьовування валідаторів), а також перевіряє, що функція, що викликається додатком, не виконується при спрацьовуванні валідатора.

Чек-лист (check list)- це документ, що описує, що має бути протестовано. При цьому чек-аркуш може бути абсолютно різного рівня деталізації. Наскільки детальним буде чек-лист залежить від вимог до звітності, рівня знання продукту співробітниками та складності продукту.
Як правило, чек-лист містить лише дії (кроки), без очікуваного результату. Чек-лист менш формалізований, ніж тестовий сценарій. Його доречно використовувати тоді, коли тестові сценарії будуть надмірними. Також чек-лист асоціюються із гнучкими підходами у тестуванні.

Дефект (він же баг)- це невідповідність фактичного результату виконання програми очікуваного результату. Дефекти виявляються на етапі тестування програмного забезпечення, коли тестувальник проводить порівняння отриманих результатів роботи програми (компонента або дизайну) з очікуваним результатом, описаним у специфікації вимог.

Error- Помилка користувача, тобто він намагається використовувати програму іншим способом.
Приклад - вводить літери на поля, де потрібно вводити цифри (вік, кількість товару тощо.).
У якісній програмі передбачені такі ситуації та видаються повідомлення про помилку (error message), з червоним хрестиком.
Bug (дефект)- Помилка програміста (або дизайнера або ще кого, хто бере участь у розробці), тобто коли в програмі щось йде не так як планувалося і програма виходить з-під контролю. Наприклад, коли ніяк не контролюється введення користувача, в результаті невірні дані викликають краші або інші "радості" у роботі програми. Або всередині програма побудована отже спочатку відповідає тому, що від неї очікується.
Failure- збій (причому не обов'язково апаратний) у роботі компонента, всієї програми чи системи. Тобто є такі дефекти, які призводять до збоїв (A defect caused the failure) і існують такі, які не призводять. UI-дефекти, наприклад. Але апаратний збій, що ніяк не пов'язаний із software, теж є failure.

Баг Репорт (Bug Report)- це документ, що описує ситуацію або послідовність дій, що призвела до некоректної роботи об'єкта тестування, із зазначенням причин та очікуваного результату.
Шапка
Короткий опис (Summary) Короткий опис проблеми, що явно вказує на причину та тип помилкової ситуації.
Проект (Project) Назва проекту, що тестується
Компонент програми (Component) Назва частини або функції продукту, що тестується
Номер версії (Version) Версія на якій було знайдено помилку
Серйозність (Severity) Найбільш поширена п'ятирівнева система градації серйозності дефекту:
S1 Блокуючий (Blocker)
S2 Критичний (Critical)
S3 Значний (Major)
S4 Незначний (Minor)
S5 Тривіальний (Trivial)
Пріоритет (Priority) Пріоритет дефекту:
P1 Високий (High)
P2 Середній (Medium)
P3 Низький (Low)
Статус (Status) Статус бага. Залежить від процедури та життєвого циклу бага (bug workflow and life cycle)

Автор (Author) Творець баг репорту
Призначений на (Assigned To) Ім'я співробітника, призначеного для вирішення проблеми
Оточення
ОС/Сервіс Пак і т.д. / Браузера + версія / ... Інформація про оточення, на якому було знайдено баг: операційна система, сервіс пак, для WEB тестування - ім'я та версія браузера і т.д.
…
Опис
Кроки відтворення (Steps to Reproduce) Кроки, якими можна легко відтворити ситуацію, що призвела до помилки.
Фактичний Результат (Result) Результат, отриманий після проходження кроків до відтворення
Очікуваний результат (Expected Result) Очікуваний правильний результат
Доповнення
Файл з логами, скріншот або будь-який інший документ, який може допомогти прояснити причину помилки або вказати на спосіб вирішення проблеми.

Severity vs Priority
Серйозність (Severity) – це атрибут, що характеризує вплив дефекту на працездатність програми.
Пріоритет (Priority) - це атрибут, що вказує на черговість виконання завдання чи усунення дефекту. Можна сміливо сказати, що це інструмент менеджера з планування робіт. Що пріоритет, то швидше потрібно виправити дефект.
Severity виставляється тестувальником
Priority - менеджером, тимлідом чи замовником

Градація Серйозності дефекту (Severity)

S1 Блокуюча (Blocker)
Блокуюча помилка, що приводить додаток у неробочий стан, в результаті якого подальша робота з системою, що тестується, або її ключовими функціями стає неможлива. Вирішення проблеми необхідне для подальшого функціонування системи.

S2 Критична (Critical)
Критична помилка, неправильно працююча ключова бізнес логіка, дірка в системі безпеки, проблема, що призвела до тимчасового падіння сервера або деяка частина системи, що призводить до неробочого стану, без можливості вирішення проблеми, використовуючи інші вхідні точки. Вирішення проблеми необхідне для подальшої роботи з ключовими функціями системою, що тестується.

S3 Значна (Major)
Значна помилка, частина основної бізнес-логіки працює некоректно. Помилка не критична або є можливість для роботи з функцією, що тестується, використовуючи інші вхідні точки.

S4 Незначна (Minor)
Незначна помилка, що не порушує бізнес логіку частини програми, що тестується, очевидна проблема користувальницького інтерфейсу.

S5 Тривіальна (Trivial)
Тривіальна помилка, що не стосується бізнес логіки програми, погано відтворювана проблема, малопомітна за допомогою інтерфейсу користувача, проблема сторонніх бібліотек або сервісів, проблема, що не впливає на загальну якість продукту.

Градація Пріоритету дефекту (Priority)
P1 Високий (High)
Помилка має бути виправлена ​​якнайшвидше, т.к. її наявність є критичною для проекту.
P2 Середній (Medium)
Помилка має бути виправлена, її наявність не критична, але вимагає обов'язкового рішення.
P3 Низький (Low)
Помилка має бути виправлена, її наявність не критична, і не вимагає термінового рішення.

Рівні Тестування

1. Модульне тестування (Unit Testing)
Компонентне (модульне) тестування перевіряє функціональність та шукає дефекти в частинах програми, які доступні та можуть бути протестовані окремо (модулі програм, об'єкти, класи, функції тощо).

2. Інтеграційне тестування (Integration Testing)
Перевіряють взаємодію між компонентами системи після проведення компонентного тестування.

3. Системне тестування (System Testing)
Основним завданням системного тестування є перевірка як функціональних, і функціональних вимог у системі загалом. При цьому виявляються дефекти, такі як неправильне використання ресурсів системи, непередбачені комбінації даних рівня користувача, несумісність з оточенням, непередбачені сценарії використання, відсутня або неправильна функціональність, незручність використання і т.д.

4. Операційне тестування (Release Testing).
Навіть якщо система задовольняє всім вимогам, важливо переконатися в тому, що вона задовольняє потреб користувача і виконує свою роль у середовищі своєї експлуатації, як це було визначено у бізнес-моделі системи. Слід врахувати, що бізнес модель може містити помилки. Тому важливо провести операційне тестування як фінальний крок валідації. Крім цього, тестування в середовищі експлуатації дозволяє виявити і нефункціональні проблеми, такі як: конфлікт з іншими системами, суміжними в галузі бізнесу або програмних та електронних оточення; недостатня продуктивність системи серед експлуатації та інших. Вочевидь, що перебування подібних речей на стадії впровадження - критична і дорога проблема. Тому так важливо проведення не тільки верифікації, а й валідації з ранніх етапів розробки ПЗ.

5. Приймальне тестування (Acceptance Testing)
Формальний процес тестування, який перевіряє відповідність системи вимогам та проводиться з метою:
визначення чи задовольняє система приймальним критеріям;
винесення рішення замовником чи іншою уповноваженою особою приймається додаток чи ні.

Види/типи тестування

Функціональні види тестування
Функціональне тестування (Functional testing)
Тестування безпеки (Security and Access Control Testing)
Тестування взаємодії (Interoperability Testing)

Нефункціональні види тестування
Усі види тестування продуктивності:
o навантажувальне тестування (Performance and Load Testing)
o стресове тестування (Stress Testing)
o тестування стабільності чи надійності (Stability / Reliability Testing)
o об'ємне тестування (Volume Testing)
Тестування установки (Installation testing)
Тестування зручності користування (Usability Testing)
Тестування на відмову та відновлення (Failover and Recovery Testing)
Конфігураційне тестування (Configuration Testing)

Пов'язані зі змінами види тестування
Димове тестування (Smoke Testing)
Регресійне тестування (Regression Testing)
Повторне тестування (Re-testing)
Тестування складання (Build Verification Test)
Санітарне тестування або перевірка узгодженості/справності (Sanity Testing)

Функціональне тестуваннярозглядає заздалегідь зазначену поведінку і ґрунтується на аналізі специфікацій функціональності компонента чи системи загалом.

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

Тестування взаємодії (Interoperability Testing)- це функціональне тестування, що перевіряє здатність програми взаємодіяти з одним і більше компонентами або системами і включає тестування сумісності (compatibility testing) та інтеграційне тестування

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

Стресове тестування (Stress Testing)дозволяє перевірити наскільки додаток і система загалом працездатні за умов стресу і оцінити здатність системи до регенерації, тобто. до повернення до нормального стану після припинення дії стресу. Стресом у цьому контексті може бути підвищення інтенсивності виконання операцій до дуже високих значень або зміна аварійної конфігурації сервера. Також одним із завдань при стресовому тестуванні може бути оцінка деградації продуктивності, таким чином цілі стресового тестування можуть перетинатися з метою тестування продуктивності.

Об'ємне тестування (Volume Testing). Завданням об'ємного тестування є отримання оцінки продуктивності зі збільшенням обсягів даних у базі даних додатку

Тестування стабільності чи надійності (Stability / Reliability Testing). Завданням тестування стабільності (надійності) є перевірка працездатності програми при тривалому (багатогодинному) тестуванні із середнім рівнем навантаження.

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

Тестування зручності користування- це метод тестування, спрямований на встановлення ступеня зручності використання, навченості, зрозумілості та привабливості для користувачів продукту, що розробляється в контексті заданих умов. Сюди також входить:
Тестування інтерфейсу користувача (англ. UI Testing) - це вид тестування дослідження, що виконується з метою визначення, чи зручний деякий штучний об'єкт (такий як веб-сторінка, інтерфейс користувача або пристрій) для його передбачуваного застосування.
User eXperience (UX) - відчуття, яке випробовує користувач під час використання цифрового продукту, тоді як User interface - це інструмент, що дозволяє здійснювати інтеракцію «користувач - веб-ресурс».

Тестування на відмову та відновлення (Failover and Recovery Testing)перевіряє тестований продукт з точки зору здатності протистояти та успішно відновлюватися після можливих збоїв, що виникли у зв'язку з помилками програмного забезпечення, відмови обладнання або проблемами зв'язку (наприклад, відмова мережі). Метою даного виду тестування є перевірка систем відновлення (або дублюючих основний функціонал систем), які, у разі виникнення збоїв, забезпечать збереження та цілісність даних продукту, що тестується.

Конфігураційне тестування (Configuration Testing)- спеціальний вид тестування, спрямований на перевірку роботи програмного забезпечення при різних конфігураціях системи (заявлених платформах, драйверах, що підтримуються, при різних конфігураціях комп'ютерів і т.д.)

Димова (Smoke)тестування розглядається як короткий цикл тестів, що виконується для підтвердження того, що після складання коду (нового або виправленого) додаток, що встановлюється, стартує і виконує основні функції.

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

Повторне тестування- Тестування, під час якого виконуються тестові сценарії, що виявили помилки під час останнього запуску, для підтвердження успішності виправлення цих помилок.
У чому різниця між regression testing та re-testing?
Re-testing - перевіряється виправлення багів
Regression testing - перевіряється те, що виправлення багів не вплинуло інші модулі ПЗ і викликало нових багів.

Тестування складання або Build Verification Test- Тестування спрямоване на визначення відповідності, випущеної версії, критеріям якості для початку тестування. За своїми цілями є аналогом Димового Тестування, спрямованого на прийняття нової версії в подальше тестування або експлуатацію. Вглиб воно може проникати далі, залежно від вимог якості випущеної версії.

Санітарне тестування- це вузькоспрямоване тестування достатнє для доказу того, що конкретна функція працює відповідно до заявлених у специфікації вимог. Є підмножиною регресійного тестування. Використовується для визначення працездатності певної частини програми після змін вироблених у ній чи навколишньому середовищі. Зазвичай виконується вручну.

Передбачення помилки (Error Guessing – EG). Це коли тест аналітик використовує свої знання системи та здатність до інтерпретації специфікації щодо того, щоб «передбачити» за яких вхідних умов система може видати помилку. Наприклад, специфікація каже: "користувач повинен ввести код". Тест аналітик буде думати: «Що, якщо я не введу код?», «Що, якщо я введу неправильний код? ", і так далі. Це і є передбачання помилки.

Підходи до інтеграційного тестування:

Знизу нагору (Bottom Up Integration)
Усі низькорівневі модулі, процедури або функції збираються докупи і потім тестуються. Після чого збирається наступний рівень модулів щодо інтеграційного тестування. Даний підхід вважається корисним, якщо всі або практично всі модулі, що розробляється, готові. Також цей підхід допомагає визначити за результатами тестування рівень готовності програми.

Зверху донизу (Top Down Integration)
Спочатку тестуються всі високорівневі модулі і поступово один за одним додаються низькорівневі. Усі модулі нижчого рівня симулюються заглушками з аналогічною функціональністю, потім у міру готовності заміняються реальними активними компонентами. Таким чином, ми проводимо тестування зверху вниз.

Великий вибух ("Big Bang" Integration)
Усі або практично всі розроблені модулі збираються разом у вигляді закінченої системи або її основної частини, а потім проводиться інтеграційне тестування. Такий підхід дуже добрий для збереження часу. Проте якщо тест кейси та його результати записані не так, то сам процес інтеграції сильно ускладниться, що стане перепоною для команди тестування при досягненні основної мети інтеграційного тестування.

Принципи тестування

Принцип 1- Тестування демонструє наявність дефектів (Testing shows presence of defects)
Тестування може показати, що дефекти є, але не може довести, що їх немає. Тестування знижує ймовірність наявності дефектів, що у програмному забезпеченні, але, навіть якщо дефекти були виявлено, це доводить його коректності.

Принцип 2- Вичерпне тестування є недосяжним (Exhaustive testing is impossible)
Повне тестування з допомогою всіх комбінацій вводів і передумов фізично нездійсненно, крім виняткових випадків. Замість вичерпного тестування повинні використовуватися аналіз ризиків та встановлення пріоритетів, щоб точніше сфокусувати зусилля з тестування.

Принцип 3- Раннє тестування (Early testing)
Щоб знайти дефекти якомога раніше, активності з тестування повинні бути розпочаті якомога раніше в життєвому циклі розробки програмного забезпечення або системи, і повинні бути сфокусовані на певних цілях.

Принцип 4- Скупчення дефектів (Defects clustering)
Зусилля тестування повинні бути зосереджені пропорційно до очікуваної, а пізніше реальної щільності дефектів по модулях. Як правило, більша частина дефектів, виявлених при тестуванні або спричинили основну кількість збоїв системи, міститься в невеликій кількості модулів.

Принцип 5- Парадокс пестициду (Pesticide paradox)
Якщо ті самі тести будуть проганятися багато разів, зрештою цей набір тестових сценаріїв більше не знаходитиме нових дефектів. Щоб подолати цей «парадокс пестициду», тестові сценарії повинні регулярно рецензуватися та коригуватися, нові тести мають бути різнобічними, щоб охопити всі компоненти програмного забезпечення, або системи, та знайти якнайбільше дефектів.

Принцип 6- Тестування залежить від контексту (Testing is concept depending)
Тестування виконується по-різному, залежно від контексту. Наприклад, програмне забезпечення, в якому критично важлива безпека, тестується інакше, ніж сайт електронної комерції.

Принцип 7- Помилка про відсутність помилок (Absence-of-errors fallacy)
Виявлення та виправлення дефектів не допоможуть, якщо створена система не підходить користувачеві та не задовольняє його очікуванням та потребам.

Статичне та динамічне тестування
Статичне тестування відрізняється від динамічного тим, що виробляється без запуску програмного коду продукту. Тестування здійснюється шляхом аналізу програмного коду (code review) чи скомпільованого коду. Аналіз може проводитись як вручну, так і за допомогою спеціальних інструментальних засобів. Метою аналізу є раннє виявлення помилок та потенційних проблем у продукті. Також до статичного тестування відноситься тестування специфікації та іншої документації.

Дослідницьке / ad-hoc тестування
Найпростіше визначення дослідницького тестування - це розробка та виконання тестів одночасно. Що є протилежністю сценарного підходу (з його наперед визначеними процедурами тестування, неважливо ручними або автоматизованими). Дослідницькі тести, на відміну від сценарних тестів, не визначені заздалегідь і не виконуються точно відповідно до плану.

Різниця між ad hoc та exploratory testing у тому, що теоретично, ad hoc може провести будь-хто, а для проведення exploratory необхідна майстерність та володіння певними техніками. Зауважте, що певні техніки це не тільки техніки тестування.

Вимоги- це специфікація (опис) те, що має бути реалізовано.
Вимоги описують те, що потрібно реалізувати, без деталізації технічного боку рішення. Що, а не як.

Вимоги до вимог:
Коректність
Недвозначність
Повнота набору вимог
Несуперечність набору вимог
Перевірюваність (тістопридатність)
Трасування
Розуміння

Життєвий цикл бага

Стадії розробки ПЗ- це етапи, які проходять команди розробників програмного забезпечення, перш ніж програма стане доступною для широкого кола користувачів. Розробка ПЗ починається з початкового етапу розробки (стадія «пре-альфа») і продовжується стадіями, на яких продукт доопрацьовується та модернізується. Фінальним етапом цього процесу стає випуск ринку остаточної версії програмного забезпечення («загальнодоступного релізу»).

Програмний продукт проходить такі стадії:
аналіз вимог до проекту;
проектування;
реалізація;
тестування продукту;
Використання та підтримка.

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

Життєвий цикл розробки ПЗ:
Пре-альфа
Альфа
Бета
Реліз-кандидат
Реліз
Пост-реліз

Таблиця ухвалення рішень (decision table)- чудовий інструмент для упорядкування складних бізнес вимог, які мають бути реалізовані у продукті. У таблицях рішень подано набір умов, одночасне виконання яких має призвести до певної дії.

QA/QC/Test Engineer


Отже, ми можемо побудувати модель ієрархії процесів забезпечення: Тестування - частина QC. QC – частина QA.

Діаграма зв'язків- це інструмент управління якістю, що ґрунтується на визначенні логічних взаємозв'язків між різними даними. Застосовується цей інструмент для зіставлення причин та наслідків із досліджуваної проблеми.

Привіт, Хабре! Якось на нашому внутрішньому семінарі мій керівник – голова відділу тестування – розпочав свою промову зі слів «тестування не потрібне». У залі всі притихли, дехто навіть намагався впасти зі стільців. Він продовжив свою думку: без тестування цілком можливо створити складний та дорогий проект. І, швидше за все, він працюватиме. Але уявіть, наскільки впевненіше ви почуватиметеся, знаючи, що продукт працює як треба.

У Badoo релізи відбуваються досить часто. Наприклад, серверна частина нарівні з desktop web релізується двічі на день. Так що ми не з чуток знаємо, що складне та повільне тестування – камінь спотикання розробки. Швидке тестування – це щастя. Отже, сьогодні я розповім про те, як у компанії Badoo влаштовано smoke-тестування.

Що таке smoke-тестування

В оригінальному застосуванні smoke-тестування призначене для перевірки найпростіших і очевидних кейсів, без якої будь-який інший вид тестування буде невиправдано зайвим.

Давайте розглянемо найпростіший приклад. Передпродакшн нашого додатка знаходиться за адресою bryak.com (будь-які збіги з реальними сайтами випадкові). Ми підготували та залили туди новий реліз для тестування. Що варто перевірити насамперед? Я б почав з перевірки того, що програма все ще відкривається. Якщо web-сервер нам відповідає «200», то все добре і можна приступати до перевірки функціоналу.

Як автоматизувати таку перевірку? В принципі, можна написати функціональний тест, який підніматиме браузер, відкриватиме потрібну сторінку і переконуватись, що вона відобразилася як треба. Проте, це рішення має низку мінусів. По-перше, це довго: процес запуску браузера займе більше часу, ніж перевірка. По-друге, це вимагає підтримки додаткової інфраструктури: задля такого простого тесту нам потрібно десь тримати сервер із браузерами. Висновок: треба вирішити задачу інакше.

Наш перший smoke-тест

По суті тести просто роблять потрібні нам запити на сервер і перевіряють відповіді. Все пов'язане з методом getCurlResponse() і кількох типах асертів.

Сам метод виглядає приблизно так:

Public function getCurlResponse($url, array $params = [ 'cookies' => , 'post_data' => , 'headers' => , 'user_agent' => , 'proxy' => , ], $follow_location = true, $ expected_response = '200 OK') ( $ch = curl_init(); curl_setopt($ch, CURLOPT_URL, $url); curl_setopt($ch, CURLOPT_HEADER, 1); $params['cookies']) && $params['cookies']) ( $cookie_line = $this->prepareCookiesDataByArray($params['cookies']); curl_setopt($ch, CURLOPT_COOKIE, $cookie_line); ) if ( isset($params['headers']) && $params['headers']) ( curl_setopt($ch, CURLOPT_HTTPHEADER, $params['headers']); ) if (isset($params['post_data'])) && $params['post_data']) ( $post_line = $this->preparePostDataByArray($params['post_data']); curl_setopt($ch, CURLOPT_POST, 1); curl_setopt($ch, CURLOPT_POSTFIELDS, $post_line)); ($follow_location) ( curl_setopt($ch, CURLOPT_FOLLOWLOCATION, 1); ) if (isset($params['proxy']) && $params['proxy']) ( curl_setopt($ch, CURLOPT_PROXY, $params['proxy) ']); ) if (isset($params['user_agent']) && $params['user_agent']) ( $user_agent = $params['user_agent']; ) else ( $user_agent = USER_AGENT_DEFAULT; ) curl_setopt($ch, CURLOPT_USERAGENT, $user_agent); curl_setopt($ch, CURLOPT_AUTOREFERER, 1); $response = curl_exec($ch); $this->logActionToDB($url, $user_agent, $params); if ($follow_location) ( $this->assertTrue((bool)$response, "Empty response was received. Curl error: " . curl_error($ch) . ", errno: " . curl_errno($ch))); $this ->assertServerResponseCode($response, $expected_response);) curl_close($ch); return $response; )
Сам метод вміє по заданому URL повертати відповідь сервера. На вхід приймає параметри, такі як cookies, headers, user agent та інші дані, необхідні формування запиту. Коли отримано відповідь від сервера, метод перевіряє, що код відповіді збігається з очікуваним. Якщо це не так, тест падає з помилкою, яка повідомляє про це. Це зроблено для того, щоб було простіше визначити причину падіння. Якщо тест впаде на якомусь асерті, повідомивши нам, що на сторінці немає якогось елемента, помилка буде менш інформативною, ніж повідомлення про те, що код відповіді, наприклад, «404» замість «200».

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

Найпростіший тест виглядає приблизно так:

Public function testStartPage() ( $url = 'bryak.com'; $response = $this->getCurlResponse($url); $this->assertHTMLPresent("
Такий тест проходить менш ніж за секунду. За цей час ми перевірили, що стартова сторінка відповідає «200» і на ній є елемент body. З тим самим успіхом ми можемо перевірити будь-яку кількість елементів на сторінці, тривалість тесту суттєво не зміниться.

Плюси таких тестів:

• швидкість - тест можна запускати так часто, як це потрібно. Наприклад, на кожну зміну коду;
• не вимагають спеціального софту та заліза для роботи;
• їх нескладно писати та підтримувати;
• вони стабільні.

Авторизація

Найпростіший варіант - авторизаційна cookie. Якщо додати її до запиту, сервер нас «дізнається». Таку cookie можна захардкодити в тесті, якщо її час життя досить великий, а можна отримувати автоматично, надсилаючи запити на сторінку авторизації. Давайте розглянемо другий варіант.

Нас цікавить форма, куди треба ввести логін та пароль користувача.

Відкриваємо цю сторінку у будь-якому браузері та відкриваємо інспектор. Вводимо дані користувача і зробимо форму.

В інспекторі з'явився запит, який треба імітувати в тесті. Можна подивитися, які дані, крім очевидних (логін та пароль), надсилаються на сервер. Для кожного проекту по-різному: це може бути remote token, дані будь-яких cookies, отриманих раніше, user agent і так далі. Кожен із цих параметрів доведеться попередньо отримати у тесті, перш ніж сформувати запит на авторизацію.

В інструментах розробника будь-якого браузера можна скопіювати запит, вибравши Copy as CURL. У такому вигляді команду можна вставити в консоль та розглядати там. Там її можна випробувати, змінивши або додавши параметри.

У відповідь на запит сервер поверне нам cookies, які ми будемо додавати в подальші запити, щоб тестувати авторизовані сторінки.

Оскільки авторизація – досить довгий процес, авторизаційну cookie я пропоную одержувати лише один раз для кожного користувача та зберігати десь. У нас, наприклад, такі cookies зберігаються у масиві. Ключем є логін користувача, а значенням – інформація про них. Якщо для наступного користувача ще немає ключа, авторизуємося. Якщо є – робимо запит, що цікавить нас, відразу.

Public function testAuthPage() ( $url = 'bryak.com'; $cookies = $this->getAuthCookies(' [email protected]', '12345'); $response = $this->getCurlResponse($url, ['cookies' => $cookies]); $this->assertHTMLPresent(" ", $response, "Error: test cannot find body element on the page."); )
Як ми бачимо, додався метод, який отримує авторизаційну cookie і просто додає її в подальший запит. Сам метод реалізується досить просто:

Public function getAuthCookies($email, $password) ( // check if cookie already has been got If (array_key_exist($email, self::$known_cookies)) ( return self::$known_cookies[$email]; ) $url = self::DOMAIN_STAGING .'/auth_page_adds';$post_data = ['email' => $email, 'password' => $password]; post_data]), $cookies = $this->parseCookiesFromResponse($response);
Метод спочатку перевіряє, чи є для даного e-mail (у вашому випадку це може бути логін або ще щось) вже отримана раніше авторизаційна cookie. Якщо є, він її повертає. Якщо ні, він запитує на авторизаційну сторінку (наприклад, bryak.com/auth_page_adds) з ​​необхідними параметрами: e-mail і пароль користувача. У відповідь на цей запит сервер надсилає заголовки, серед яких є cookies, що нас цікавлять. Виглядає це приблизно так:

HTTP/1.1 200 OK Server: nginx Content-Type: text/html; charset=utf-8 Transfer-Encoding: chunked Connection: keep-alive Set-Cookie: name=value; expires=Wed, 30-Nov-2016 10:06:24 GMT; Max-Age = -86400; path=/; domain=bryak.com
З цих заголовків нам за допомогою нескладного регулярного виразу треба отримати назву cookie та її значення (у нашому прикладі це name = value). У нас метод, який парсить відповідь, виглядає так:

$this->assertTrue((bool)preg_match_all("/Set-Cookie: (([^=]+)=([^;]+);.*)\n/", $response, $mch1), " Cannot get "cookies" from server response. Response: ". $response);
Після того, як cookies отримані, ми можемо сміливо додавати їх до будь-якого запиту, щоб зробити його авторизованим.

Розбір тестів, що падають

Насамперед я хотів би порадити максимально атомізувати тести. Не варто в одному тесті перевіряти 50 різних кейсів. Чим тест простіше, тим із ним простіше буде надалі.

Ще корисно збирати артефакти. Коли наш тест падає, він зберігає останню відповідь сервера HTML-файлик і закидає в сховище артефактів, де цей файл можна відкрити з браузера, вказавши назву тесту.

Наприклад, тест у нас впав на тому, що не може знайти на сторінці шматочок HTML:

Link
Ми заходимо на наш колектор та відкриваємо відповідну сторінку:

З цією сторінкою можна працювати так само, як з будь-якою іншою HTML-сторінкою у браузері. Можна за допомогою CSS-локатора спробувати розшукати зниклий елемент і, якщо його дійсно немає, вирішити, що він змінився, або загубився. Можливо ми знайшли баг! Якщо елемент на місці, можливо, ми помилилися в тесті – треба уважно подивитися в цей бік.

Ще спростити життя допомагає логування. Ми намагаємося логувати всі запити, які робив тест, що впав, так, щоб їх легко можна було повторити. По-перше, це дозволяє швидко руками зробити набір аналогічних дій для відтворення помилки, по-друге – виявити тести, що часто падають, якщо такі у нас є.

Крім допомоги у розборі помилок, описані вище логи допомагають нам формувати список авторизованих та неавторизованих сторінок, які ми протестували. Дивлячись на нього, легко шукати та усувати прогалини.

Останнє, але не важливо, що можу порадити – тести повинні бути настільки зручними, наскільки це можливо. Чим простіше їх запустити, тим частіше їх використовуватимуть. Чим зрозуміліший та лаконічніший звіт про падіння, тим уважніше його вивчать. Чим простіше архітектура, тим більше тестів буде написано і тим менше часу займатиме написання нового.

Якщо вам здається, що тестами користуватись незручно – швидше за все вам не здається. З цим необхідно боротися якнайшвидше. В іншому випадку ви ризикуєте в якийсь момент почати звертати менше уваги на ці тести, а це вже може призвести до помилки на продакшн.

На словах думка здається очевидною, згоден. Але насправді всім нам є куди прагнути. Тож спрощуйте та оптимізуйте свої твори та живіть без багів. :)

Підсумки

За цей час ми переконуємось, що:

• наш проект відкривається всіма мовами (яких у нас понад 40 на продакшені);
• для основних країн відображаються коректні форми оплати з відповідним набором способів оплати;
• коректно працюють основні запити до API;
• коректно працює лендинг для редиректів (у тому числі і на мобільний сайт за відповідного користувача-агента);
• усі внутрішні проекти відображаються правильно.

• Smoke test на Jargon File (англ.)

Wikimedia Foundation. 2010 .

Дивитись що таке "Smoke test" в інших словниках:

smoke test- noun Оцінка методу випробування для легенів в drain pipes or chimneys, щоб встановити штучний кукурудза, триматися за допомогою кукурудзи Bomb Main Entry: smoke … Useful english dictionary

smoke test- Test made to determine completeness of combustion … Dictionary of automotive terms

smoke test- 1. noun a) A test for leaks involving blowing smoke в tube or pipe. b) Попередній тест на нову конструктивну частину електричного обладнання, що містить лише застосування електричної напруги, що робить не те, що егрегиусный wiring ... ... Вікно

Smoke testing- Це термін, який використовується в площині, woodwind repair, електроніки, комп'ютерного розвитку software, і проектування промисловості. Це refers to на першому тесті зроблено після реагування або першої assembly для того, щоб зробити певну віру, що система під час тесту буде… … Wikipedia

Smoke testing- bzw. Rauchtest is ein Begriff aus dem Englischen, gebräuchlich im handwerklichen Bereich (z. B. in der Klempnerei, Elektronik oder beim Bau von Holzblasinstrumenten) wie auch in der Softwareentwicklung. Es bezeichnet den ersten… … Deutsch Wikipedia

Smoke- is collection of airborne solid and liquid particulates and gases [

Test suite- У розробці програмного забезпечення, в обчислювальних приладах, як і раніше відомо, як validation suite , є колекція тестових випадків, які будуть впроваджені для того, щоб бути використані в обліковий запис програмного забезпечення для того, щоб виявити певну версію behaviours. A test suite often… … Wikipedia

Smoke bomb- A smoke bomb is a firework designed to produce smoke upon ignition. У той час як є гальм generation devices, що є схиблені від війнпланів, терм кермовий бомба використовує три типи пристроїв: # Smoke ball is hollow, cherry ... ... Wikipedia

Привіт, Хабре! Якось на нашому внутрішньому семінарі мій керівник – голова відділу тестування – розпочав свою промову зі слів «тестування не потрібне». У залі всі притихли, дехто навіть намагався впасти зі стільців. Він продовжив свою думку: без тестування цілком можливо створити складний та дорогий проект. І, швидше за все, він працюватиме. Але уявіть, наскільки впевненіше ви почуватиметеся, знаючи, що продукт працює як треба.

У Badoo релізи відбуваються досить часто. Наприклад, серверна частина нарівні з desktop web релізується двічі на день. Так що ми не з чуток знаємо, що складне та повільне тестування – камінь спотикання розробки. Швидке тестування – це щастя. Отже, сьогодні я розповім про те, як у компанії Badoo влаштовано smoke-тестування.

Що таке smoke-тестування

В оригінальному застосуванні smoke-тестування призначене для перевірки найпростіших і очевидних кейсів, без якої будь-який інший вид тестування буде невиправдано зайвим.

Давайте розглянемо найпростіший приклад. Передпродакшн нашого додатка знаходиться за адресою bryak.com (будь-які збіги з реальними сайтами випадкові). Ми підготували та залили туди новий реліз для тестування. Що варто перевірити насамперед? Я б почав з перевірки того, що програма все ще відкривається. Якщо web-сервер нам відповідає «200», то все добре і можна приступати до перевірки функціоналу.

Як автоматизувати таку перевірку? В принципі, можна написати функціональний тест, який підніматиме браузер, відкриватиме потрібну сторінку і переконуватись, що вона відобразилася як треба. Проте, це рішення має низку мінусів. По-перше, це довго: процес запуску браузера займе більше часу, ніж перевірка. По-друге, це вимагає підтримки додаткової інфраструктури: задля такого простого тесту нам потрібно десь тримати сервер із браузерами. Висновок: треба вирішити задачу інакше.

Наш перший smoke-тест

По суті тести просто роблять потрібні нам запити на сервер і перевіряють відповіді. Все пов'язане з методом getCurlResponse() і кількох типах асертів.

Сам метод виглядає приблизно так:

Public function getCurlResponse($url, array $params = [ 'cookies' => , 'post_data' => , 'headers' => , 'user_agent' => , 'proxy' => , ], $follow_location = true, $ expected_response = '200 OK') ( $ch = curl_init(); curl_setopt($ch, CURLOPT_URL, $url); curl_setopt($ch, CURLOPT_HEADER, 1); $params['cookies']) && $params['cookies']) ( $cookie_line = $this->prepareCookiesDataByArray($params['cookies']); curl_setopt($ch, CURLOPT_COOKIE, $cookie_line); ) if ( isset($params['headers']) && $params['headers']) ( curl_setopt($ch, CURLOPT_HTTPHEADER, $params['headers']); ) if (isset($params['post_data'])) && $params['post_data']) ( $post_line = $this->preparePostDataByArray($params['post_data']); curl_setopt($ch, CURLOPT_POST, 1); curl_setopt($ch, CURLOPT_POSTFIELDS, $post_line)); ($follow_location) ( curl_setopt($ch, CURLOPT_FOLLOWLOCATION, 1); ) if (isset($params['proxy']) && $params['proxy']) ( curl_setopt($ch, CURLOPT_PROXY, $params['proxy) ']); ) if (isset($params['user_agent']) && $params['user_agent']) ( $user_agent = $params['user_agent']; ) else ( $user_agent = USER_AGENT_DEFAULT; ) curl_setopt($ch, CURLOPT_USERAGENT, $user_agent); curl_setopt($ch, CURLOPT_AUTOREFERER, 1); $response = curl_exec($ch); $this->logActionToDB($url, $user_agent, $params); if ($follow_location) ( $this->assertTrue((bool)$response, "Empty response was received. Curl error: " . curl_error($ch) . ", errno: " . curl_errno($ch))); $this ->assertServerResponseCode($response, $expected_response);) curl_close($ch); return $response; )
Сам метод вміє по заданому URL повертати відповідь сервера. На вхід приймає параметри, такі як cookies, headers, user agent та інші дані, необхідні формування запиту. Коли отримано відповідь від сервера, метод перевіряє, що код відповіді збігається з очікуваним. Якщо це не так, тест падає з помилкою, яка повідомляє про це. Це зроблено для того, щоб було простіше визначити причину падіння. Якщо тест впаде на якомусь асерті, повідомивши нам, що на сторінці немає якогось елемента, помилка буде менш інформативною, ніж повідомлення про те, що код відповіді, наприклад, «404» замість «200».

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

Найпростіший тест виглядає приблизно так:

Public function testStartPage() ( $url = 'bryak.com'; $response = $this->getCurlResponse($url); $this->assertHTMLPresent("
Такий тест проходить менш ніж за секунду. За цей час ми перевірили, що стартова сторінка відповідає «200» і на ній є елемент body. З тим самим успіхом ми можемо перевірити будь-яку кількість елементів на сторінці, тривалість тесту суттєво не зміниться.

Плюси таких тестів:

• швидкість - тест можна запускати так часто, як це потрібно. Наприклад, на кожну зміну коду;
• не вимагають спеціального софту та заліза для роботи;
• їх нескладно писати та підтримувати;
• вони стабільні.

Авторизація

Найпростіший варіант - авторизаційна cookie. Якщо додати її до запиту, сервер нас «дізнається». Таку cookie можна захардкодити в тесті, якщо її час життя досить великий, а можна отримувати автоматично, надсилаючи запити на сторінку авторизації. Давайте розглянемо другий варіант.

Нас цікавить форма, куди треба ввести логін та пароль користувача.

Відкриваємо цю сторінку у будь-якому браузері та відкриваємо інспектор. Вводимо дані користувача і зробимо форму.

В інспекторі з'явився запит, який треба імітувати в тесті. Можна подивитися, які дані, крім очевидних (логін та пароль), надсилаються на сервер. Для кожного проекту по-різному: це може бути remote token, дані будь-яких cookies, отриманих раніше, user agent і так далі. Кожен із цих параметрів доведеться попередньо отримати у тесті, перш ніж сформувати запит на авторизацію.

В інструментах розробника будь-якого браузера можна скопіювати запит, вибравши Copy as CURL. У такому вигляді команду можна вставити в консоль та розглядати там. Там її можна випробувати, змінивши або додавши параметри.

У відповідь на запит сервер поверне нам cookies, які ми будемо додавати в подальші запити, щоб тестувати авторизовані сторінки.

Оскільки авторизація – досить довгий процес, авторизаційну cookie я пропоную одержувати лише один раз для кожного користувача та зберігати десь. У нас, наприклад, такі cookies зберігаються у масиві. Ключем є логін користувача, а значенням – інформація про них. Якщо для наступного користувача ще немає ключа, авторизуємося. Якщо є – робимо запит, що цікавить нас, відразу.

Public function testAuthPage() ( $url = 'bryak.com'; $cookies = $this->getAuthCookies(' [email protected]', '12345'); $response = $this->getCurlResponse($url, ['cookies' => $cookies]); $this->assertHTMLPresent(" ", $response, "Error: test cannot find body element on the page."); )
Як ми бачимо, додався метод, який отримує авторизаційну cookie і просто додає її в подальший запит. Сам метод реалізується досить просто:

Public function getAuthCookies($email, $password) ( // check if cookie already has been got If (array_key_exist($email, self::$known_cookies)) ( return self::$known_cookies[$email]; ) $url = self::DOMAIN_STAGING .'/auth_page_adds';$post_data = ['email' => $email, 'password' => $password]; post_data]), $cookies = $this->parseCookiesFromResponse($response);
Метод спочатку перевіряє, чи є для даного e-mail (у вашому випадку це може бути логін або ще щось) вже отримана раніше авторизаційна cookie. Якщо є, він її повертає. Якщо ні, він запитує на авторизаційну сторінку (наприклад, bryak.com/auth_page_adds) з ​​необхідними параметрами: e-mail і пароль користувача. У відповідь на цей запит сервер надсилає заголовки, серед яких є cookies, що нас цікавлять. Виглядає це приблизно так:

HTTP/1.1 200 OK Server: nginx Content-Type: text/html; charset=utf-8 Transfer-Encoding: chunked Connection: keep-alive Set-Cookie: name=value; expires=Wed, 30-Nov-2016 10:06:24 GMT; Max-Age = -86400; path=/; domain=bryak.com
З цих заголовків нам за допомогою нескладного регулярного виразу треба отримати назву cookie та її значення (у нашому прикладі це name = value). У нас метод, який парсить відповідь, виглядає так:

$this->assertTrue((bool)preg_match_all("/Set-Cookie: (([^=]+)=([^;]+);.*)\n/", $response, $mch1), " Cannot get "cookies" from server response. Response: ". $response);
Після того, як cookies отримані, ми можемо сміливо додавати їх до будь-якого запиту, щоб зробити його авторизованим.

Розбір тестів, що падають

Насамперед я хотів би порадити максимально атомізувати тести. Не варто в одному тесті перевіряти 50 різних кейсів. Чим тест простіше, тим із ним простіше буде надалі.

Ще корисно збирати артефакти. Коли наш тест падає, він зберігає останню відповідь сервера HTML-файлик і закидає в сховище артефактів, де цей файл можна відкрити з браузера, вказавши назву тесту.

Наприклад, тест у нас впав на тому, що не може знайти на сторінці шматочок HTML:

Link
Ми заходимо на наш колектор та відкриваємо відповідну сторінку:

З цією сторінкою можна працювати так само, як з будь-якою іншою HTML-сторінкою у браузері. Можна за допомогою CSS-локатора спробувати розшукати зниклий елемент і, якщо його дійсно немає, вирішити, що він змінився, або загубився. Можливо ми знайшли баг! Якщо елемент на місці, можливо, ми помилилися в тесті – треба уважно подивитися в цей бік.

Ще спростити життя допомагає логування. Ми намагаємося логувати всі запити, які робив тест, що впав, так, щоб їх легко можна було повторити. По-перше, це дозволяє швидко руками зробити набір аналогічних дій для відтворення помилки, по-друге – виявити тести, що часто падають, якщо такі у нас є.

Крім допомоги у розборі помилок, описані вище логи допомагають нам формувати список авторизованих та неавторизованих сторінок, які ми протестували. Дивлячись на нього, легко шукати та усувати прогалини.

Останнє, але не важливо, що можу порадити – тести повинні бути настільки зручними, наскільки це можливо. Чим простіше їх запустити, тим частіше їх використовуватимуть. Чим зрозуміліший та лаконічніший звіт про падіння, тим уважніше його вивчать. Чим простіше архітектура, тим більше тестів буде написано і тим менше часу займатиме написання нового.

Якщо вам здається, що тестами користуватись незручно – швидше за все вам не здається. З цим необхідно боротися якнайшвидше. В іншому випадку ви ризикуєте в якийсь момент почати звертати менше уваги на ці тести, а це вже може призвести до помилки на продакшн.

На словах думка здається очевидною, згоден. Але насправді всім нам є куди прагнути. Тож спрощуйте та оптимізуйте свої твори та живіть без багів. :)

Підсумки

За цей час ми переконуємось, що:

• наш проект відкривається всіма мовами (яких у нас понад 40 на продакшені);
• для основних країн відображаються коректні форми оплати з відповідним набором способів оплати;
• коректно працюють основні запити до API;
• коректно працює лендинг для редиректів (у тому числі і на мобільний сайт за відповідного користувача-агента);
• усі внутрішні проекти відображаються правильно.

Після проведення необхідних змін, таких як виправлення бага/дефекту, програмне забезпечення має бути перетестовано для підтвердження того, що проблема була дійсно вирішена. Нижче наведено види тестування, які необхідно проводити після встановлення програмного забезпечення, для підтвердження працездатності програми або правильності здійсненого виправлення дефекту:

- Димове тестування(Smoke Testing)

- Регресійне тестування(Regression Testing)

- Тестування складання(Build Verification Test)

- Санітарне тестування або перевірка узгодженості/справності(Sanity Testing)

Концепція димове тестуванняпішло з інженерного середовища. При введенні в експлуатацію нового обладнання (заліза) вважалося, що тестування пройшло вдало, якщо з установки не пішов дим. В області тестування програмного забезпечення, воно спрямоване на поверхневу перевірку всіх модулів програми на предмет працездатності і наявність критичних і блокуючих дефектів, що швидко знаходяться. За результатами димового тестування робиться висновок про те, приймається чи ні встановлена ​​версія програмного забезпечення в тестування, експлуатацію чи постачання замовнику. Для полегшення роботи, економії часу та людських ресурсів рекомендується впровадити автоматизацію тестових сценаріїв для димового тестування.

Регресійне тестування– це вид тестування, спрямований на перевірку змін, зроблених у додатку або навколишньому середовищі (починання дефекту, злиття коду, міграція на іншу операційну систему, базу даних, веб-сервер або сервер програми), для підтвердження того факту, що існуюча раніше функціональність працює як і раніше (див. також Санітарне тестування або перевірка узгодженості/справності). Регресійними можуть бути як функціональні,так і нефункціональнівипробування.

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

Сам собою термін «Регресійне тестування», залежно від контексту використання може мати різний зміст. Сем Канер, наприклад, описав 3 основних типирегресійного тестування:

- Регресія багів (Bug regression)- Спроба довести, що виправлена ​​помилка насправді не виправлена.

- Регресія старих багів (Old bugs regression)- Спроба довести, що недавня зміна коду або даних зламало виправлення старих помилок, тобто. старі баги почали знову відтворюватись.

- Регресія побічного ефекту (Side effect regression)– спроба довести, що нещодавня зміна коду або даних зламала інші частини програми, що розробляється.

Санітарне тестування або перевірка узгодженості/справності (Sanity Testing) –це вузькоспрямоване тестування, достатнє для доказу того, що конкретна функція працює відповідно до заявлених у специфікації вимог. Є підмножиною регресійного тестування. Використовується для визначення працездатності певної частини програми після змін вироблених у ній чи навколишньому середовищі. Зазвичай виконується вручну.

Відмінність санітарного тестування від димового.У деяких джерелах помилково вважають, що санітарне та димове тестування – це те саме. Ми ж вважаємо, що ці види тестування мають «вектори руху», напрями в різні боки. На відміну від димового (Smoke testing), санітарне тестування (Sanity testing) спрямоване вглиб функції, що перевіряється, тоді як димове направлено вшир, для покриття тестами якомога більшого функціоналу в найкоротші терміни.

Тестування складання(Build Verification Test) – це тестування, спрямоване визначення відповідності, випущеної версії, критеріям якості початку тестування. За своїми цілями є аналогом Димового Тестування, спрямованого на прийняття нової версії в подальше тестування або експлуатацію. Вглиб воно може проникати далі, залежно від вимог якості випущеної версії.

Тестування Установки (Installation Testing) -спрямовано на перевірку успішної інсталяції та налаштування, а також оновлення або видалення програмного забезпечення. На даний момент найбільш поширена установка ПЗ за допомогою інсталяторів(спеціальних програм, які самі собою так само вимагають належного тестування). У реальних умовах інсталяторів може бути. У цьому випадку доведеться самостійно виконувати установку програмного забезпечення, використовуючи документацію у вигляді інструкцій або readme файлів, що крок за кроком описують всі необхідні дії та перевірки. У розподілених системах, де програма розгортається на вже працюючому оточенні, простого набору інструкцій може бути мало. Для цього часто пишеться план установки (Deployment Plan), що включає не тільки кроки по інсталяції програми, але і кроки відкату (roll-back) до попередньої версії, у разі невдачі. Сам по собі план установки також має пройти процедуру тестування, щоб уникнути проблем при видачі в реальну експлуатацію. Особливо це актуально, якщо установка виконується на системи, де кожна хвилина простою – це втрата репутації та великої кількості коштів, наприклад: банки, фінансові компанії чи навіть банерні мережі. Тому тестування установки можна назвати одним із найважливіших завдань щодо забезпечення якості програмного забезпечення.

Саме такий комплексний підхід із написанням планів, покроковою перевіркою встановлення та відкату інсталяції, повноправно можна назвати тестуванням установки або Installation Testing.