До цієї групи зазвичай відносять:
- Підтверджувальне тестування – Confirmation testing (ISQTB)
- Регресійне тестування – Regression testing (ISTQB)
- Димове тестування – Smoke testing
- Тестування працездатності – Sanity testing
- Тестування супроводу – Maintenance testing
Тестування супроводу вже було розглянуто у пості про тестування зручності супроводу. Тому зосередимося на перших чотирьх типах тестування.
Підтверджувальне тестування та Регресійне тестування
Коли в систему вносяться зміни або для виправлення дефекту, або через нову чи змінену функціональність, слід провести тестування, щоб підтвердити, що зміни виправили дефект або реалізували функціональні можливості належним чином і не спричинили жодних непередбачуваних несприятливих наслідків.
Підтверджувальне тестування: після усунення дефекту програмне забезпечення необхідно перевірити для впевненості в тому, що дефект дійсно було усунуто. Програмне забезпечення також може бути перевірено за допомогою нових тестів, щоб охопити зміни, необхідні для усунення дефекту.
Щонайменше кроки для відтворення помилок, викликаних дефектом, необхідно виконати повторно в новій версії програмного забезпечення. Метою підтверджувального тесту є підтвердження того, чи було успішно виправлено початковий дефект.
Регресійне тестування: можливо, що зміна, внесена в одну частину коду, будь то виправлення чи зміна іншого типу, може випадково вплинути на поведінку інших частин коду, незалежно від того, в межах того самого компонента, в інших компонентах тій же системі або навіть в інших системах.
Зміни можуть включати зміни в середовищі, такі як нова версія операційної системи або системи керування базами даних.
Такі ненавмисні побічні ефекти називаються регресією. Регресійне тестування передбачає виконання тестів для виявлення таких небажаних побічних ефектів.
Підтверджувальне тестування означає повторне тестування дефекту або помилки, щоб переконатися, що його було усунуто. Якщо дефект не усунуто, то його потрібно відкрити заново (reopen). Якщо дефект виправлено, то його закривають.
Регресійне тестування означає перевірку програмного забезпечення внаслідок внесення змін в його код. Це робиться для того, щоб новий код не вплинув на інші частини програмного забезпечення.
Отже, регресійне тестування визначається як тип тестування програмного забезпечення для підтвердження того, що нещодавня зміна програми чи коду не вплинула негативно на наявні функції. Іншими словами це повний або частковий вибір уже виконаних тестів, які повторно виконуються, щоб переконатися, що існуючі функції працюють нормально. Цей тип тестування проводиться для того, щоб переконатися, що нові зміни коду не мають побічних ефектів на існуючі функції.
Методи регресійного тестування
Для ефективного забезпечення якості програмного забезпечення можна застосувати різні методи регресійного тестування:
- Повторно протестувати все: Це один із методів регресійного тестування, зокрема із застосуванням набору регресійних тестів. У цьому випадку всі тести в наявному тестовому сегменті або наборі потрібно виконати повторно. Це дорогий спосіб, оскільки вимагає багато часу та ресурсів.
- Вибір тестів для тестування регресії: це техніка, за якої виконуються деякі вибрані тести з набору тестів. Це допомагає перевірити, чи впливає змінений код на програмне забезпечення чи ні. Тут тестові кейси поділяються на дві частини. Повторно використовувані тестові кейси можна використовувати в наступних циклах регресії, тоді як застарілі тестові кейси – ні.
- Пріоритезація тестових випадків: залежить від впливу на бізнес, критичності та частоти використання.
Вибір тестів для регресії
За галузевими даними було виявлено, що велика кількість дефектів, про які повідомили клієнти, були спричинені виправленнями помилок. Це призвело до побічних ефектів, тому вибір тестових кейсів для регресійного тестування є непростим завданням.
Ефективний набір регресійних тестів можна створити, вибравши такі типи тестів:
- Тестові кейси модулів, які часто містять дефекти.
- Тестові кейси для функцій, які часто використовуються
- Тестові кейси, які перевіряють ключові характеристики продукту
- Тестові кейси функцій, які зазнали змін.
- Інтеграційні набори
- Складні тестові кейси
- Тестові кейси граничних значень
- Негативні тести
Позитивне / Негативне тестування
За принципами роботи з додатком тестування можна поділити на:
- Позитивне – всі дії з додатком виконуються згідно з інструкціями чи керівництвом, жодних некоректних дій чи даних не допускається.
- Негативне – в роботі з програмним додатком виконуються некоректні дії чи використовуються дані, які потенційно можуть призвести до помилки.
Автоматизація регресії
Selenium – популярна платформа з відкритим кодом, яка використовується для автоматизації веб-браузерів. Його ключовий компонент, Selenium WebDriver, надає простий API для взаємодії з веб-елементами, що дозволяє розробникам автоматизувати такі завдання, як натискання кнопок, заповнення форм і навігація сторінками. Завдяки підтримці кількох мов програмування та браузерів Selenium широко використовується для веб-тестування та автоматизації.
Watir – що розшифровується як Web Application Testing in Ruby, є системою тестування з відкритим вихідним кодом, яка фокусується на автоматизації веб-браузерів за допомогою мови програмування Ruby. Він пропонує зручний та інтуїтивно зрозумілий API, який використовує виразний синтаксис Ruby для взаємодії з веб-елементами та імітації дій користувача, таких як натискання кнопок і заповнення форм. Ключова відмінність Watir полягає в його повній інтеграції з Ruby, що робить його улюбленим вибором для тестувальників і розробників, які віддають перевагу Ruby.
IBM DevOps Test UI (Rational Functional Tester) – це автоматизований інструмент функціонального та регресійного тестування для графічного інтерфейсу користувача та тестування на основі даних. Він підтримує низку програм, включаючи веб-додатки, .Net, Java, Siebel, SAP тощо. Платний.
Katalon Studio – це рішення для автоматизованого тестування, яке використовує фреймворки Selenium і Appium для веб-тестування, тестування API, мобільних пристроїв і комп’ютерів. Має обмежену безкоштовну версію.
TestComplete – розроблений компанією SmartBear Software, є автоматизованим інструментом тестування інтерфейсу користувача, який дозволяє створювати автоматизовані функціональні тести для настільних, веб- та мобільних додатків. Платний.
Smoke testing та Sanity testing
Димове тестування — це техніка тестування програмного забезпечення, яка виконується, щоб переконатися, що критично важливі фічі програмного забезпечення працюють як очікується.
Це тестування виконується перед виконанням будь-яких детальних функціональних або регресійних тестів. Основна мета димового тестування — відхилити програмне забезпечення з дефектами, щоб команда тестувальників не втрачала час на тестування непридатного програмного забезпечення.
Тестування на працездатність – це різновид тестування програмного забезпечення , яке виконується після отримання збірки програмного забезпечення з незначними змінами в коді чи функціональності, щоб переконатися, що через ці зміни не виникає жодних проблем. Мета полягає в тому, щоб визначити, чи запропоновані функції працюють приблизно так, як очікувалося. Якщо тест на працездатність проходить невдало, збірка відхиляється, щоб заощадити час і кошти, пов’язані з більш ретельним тестуванням.
Наприклад, якщо функція, що відповідає за розрахунки видає результат 2*2=3, тоді наврядчи є сенс тестувати більш складні операції, такі як розрахунок складних відсотків, наприклад.
Smoke | Sanity |
Перевіряє стабільність нової збірки | Перевіряє стабільність нових функцій або змін коду в існуючій збірці |
Охоплює ключові функції наскрізними перевірками | Охоплює певні модулі, у код яких внесено зміни |
Може виконуватися як тестувальниками, так і розробниками | Зазвичай виконується тестувальниками |
Часто визначаються як підтип приймального тестування (є позиції, що можна відносити до регресійного тестування) | Підтип регресійного тестування |
В цьому відео поговоримо про:
00:00 Типи тестування пов’язані зі змінами
03:00 Підтверджувальне та регресійне тестування
06:30 Методи регресійного тестування
08:16 Вибір тестів для регресії
09:38 Позитивне та негативне тестування (ліричний відступ)
10:51 Автоматизація регресії
15:59 Smoke testing та Sanity testing