Що таке динамічне тестування? Типи, методи та приклади
Томас Гамільтон
⚡ Розумний підсумок
Динамічне тестування виконує програму та спостерігає за тим, як запущений код поводиться з реальними вхідними даними, завдяки чому тестувальники можуть перевірити функціональність, продуктивність та стабільність, які не можуть виявити жодні перевірки документації.
Що таке динамічне тестування?
Динамічне тестування — це метод тестування програмного забезпечення, який використовується для перевірки динамічної поведінки програмного коду. Основною метою динамічного тестування є дослідження поведінки програмного забезпечення з динамічними змінними — змінними, які не є постійними — та пошук слабких місць у середовищі виконання програмного забезпечення. Код має бути виконаний для перевірки динамічної поведінки.
Тестування є перевірка та підтвердження, і для завершення тестування потрібні обидві версії. Верифікація здійснюється за допомогою статичного тестування, яке переглядає вимоги, проектну документацію та код без їх запуску. Валідація здійснюється за допомогою динамічного тестування, яке запускає збірку та порівнює фактичні функції програми з тим, що вона повинна робити.
У таблиці нижче їх можна одразу розрізнити.
| Аспект | Статичне тестування (верифікація) | Динамічне тестування (валідація) |
| Code виконано | Немає | Так |
| Типові види діяльності | Revогляди, обхідні огляди, інспекції, статичний аналіз | Виконання тестових випадків на всіх рівнях тестування |
| Відповідь на запитання | Чи правильно ми створюємо продукт? | Чи створюємо ми правильний продукт? |
| Знайдено дефекти | Неоднозначні вимоги, порушення стандартів кодування, мертвий код | Неправильний вивід, витоки пам'яті, помилки синхронізації, збої інтеграції |
| Починає | Як тільки артефакт існує | Після того, як виконуваний файл збірки існує |
| Відносна вартість ремонту | Нижче, оскільки дефекти виявляються раніше | Вища, оскільки дефекти проявляються пізніше |
Приклад динамічного тестування
Короткий робочий приклад показує, як динамічне тестування поводиться на практиці.
Припустимо, що тестується сторінка входу. Вона має два поля: Ім'я користувача та Пароль, а ім'я користувача обмежене буквено-цифровими символами.
Коли користувач вводить ім'я користувача як «Guru99», система приймає його. Коли користувач вводить «Guru99@123”, програма видає повідомлення про помилку. Цей результат показує, що код діє динамічно на основі введених користувачем даних.
Таким чином, динамічне тестування означає роботу з реальною системою, надання вхідних даних та порівняння фактичної поведінки програми з очікуваною — іншими словами, роботу з системою з метою пошуку помилок.
Таким чином, динамічне тестування — це процес перевірки програмного застосунку так, як це зробив би кінцевий користувач у різних середовищах, щоб створити правильне програмне забезпечення.
Що робить динамічне тестування?
Головна мета динамічних тестів — забезпечити належну роботу програмного забезпечення під час та після встановлення, забезпечуючи стабільну роботу програми без суттєвих недоліків. Жодне програмне забезпечення не є повністю безпомилковим, і тестування може показати наявність дефектів, але ніколи їх відсутність.
Динамічні тести також забезпечують узгодженість усього програмного забезпечення, як показано на цьому прикладі.
У банківській програмі є кілька екранів, таких як «Мої рахунки», «Переказ коштів» та Bill Оплата. Усі вони містять поле суми.
Припустимо, що в полі «Мої рахунки» відображається сума 25 000, у полі «Переказ коштів» – 25 000 доларів США, а Bill На екрані оплати відображається $25000. Сума та сама, але спосіб її відображення відрізняється, що робить програмне забезпечення несумісним.
Узгодженість не обмежується функціональністю. Вона також охоплює такі стандарти, як продуктивність, зручність використання та сумісність, тому динамічне тестування має таке велике значення.
Види динамічного тестування
Динамічне тестування поділяється на дві категорії.
- білий Box Тестування
- Black Box Тестування
На діаграмі нижче ці дві категорії зіставлені з рівнями тестування, що знаходяться нижче.
Кожен тип та його цільове призначення описані нижче.
білий Box Тестування — метод тестування програмного забезпечення, за якого внутрішня структура та дизайн відомі тестувальнику. Його головна мета — перевірити, як система працює на основі коду. Його переважно виконують розробники або «білі» тестувальники, які мають знання програмування.
Black Box Тестування — метод тестування, за якого внутрішня структура, код та дизайн НЕ відомі тестувальнику. Його головна мета — перевірити функціональність тестованої системи. Цей тип тестування вимагає виконання повного набору тестів, виконується переважно тестувальниками та не потребує знань програмування.
Тестування чорної скриньки знову ж таки класифікується на два типи.
- Функціональне тестування
- Нефункціональне тестування
Функціональне тестування
Функціональне тестування виконується для перевірки відповідності всіх розроблених функцій функціональним специфікаціям. Це здійснюється шляхом виконання функціонального тестові справи написаний командою контролю якості. На цьому етапі система тестується шляхом надання вхідних даних, перевірки вихідних даних та порівняння фактичних результатів з очікуваними.
Існують різні рівні функціонального тестування, найважливішими з яких є чотири, наведені нижче.
- Unit Testing — модуль — це невеликий, тестований фрагмент коду. Модульне тестування виконується на окремому модулі програмного забезпечення розробниками.
- Інтеграційне тестування — виконується після модульного тестування шляхом об’єднання окремих тестованих модулів. Його виконують або розробники, або тестувальники.
- Тестування системи — виконується для того, щоб переконатися, що система працює відповідно до вимог. Зазвичай його виконують тестувальники, коли система повністю готова, після того, як збірка випущена команді контролю якості.
- Тестування прийняття — виконується для перевірки того, чи відповідає система бізнес-вимогам і чи готова вона до використання або розгортання. Зазвичай це виконують кінцеві користувачі.
Нефункціональне тестування
Нефункціональне тестування – це метод тестування, який не зосереджується на функціональних аспектах, а натомість зосереджується на нефункціональних атрибутах системи, таких як витоки пам'яті, продуктивність або надійність. Нефункціональне тестування виконується на всіх рівнях тестування.
Існує багато методів нефункціонального тестування, найважливішими з яких є п'ять наведених нижче.
- Тестування продуктивності — перевіряє, чи є час відгуку системи нормальним, відповідно до вимог, за бажаного мережевого навантаження.
- Тестування відновлення — перевіряє, наскільки добре система відновлюється після збоїв та апаратних відмов.
- Тестування сумісності — перевіряє, як система поводиться в різних середовищах.
- Тестування безпеки — перевіряє надійність застосунку, гарантуючи, що доступ до системи мають лише авторизовані користувачі та ролі.
- Тестування на зручність — перевіряє зручність використання системи кінцевими користувачами та те, наскільки комфортно цим користувачам з нею працювати.
Методи динамічного тестування
Після визначення типів, наступним питанням є те, як насправді виконується динамічний тестовий цикл.
Методи динамічного тестування в STLC складається з таких завдань, як аналіз вимог до тестів, планування тестування, розробка та реалізація тестових випадків, налаштування тестового середовища, виконання тестових випадків, звітування про помилки та, нарешті, закриття тесту. Кожне завдання в динамічному тестуванні залежить від завершення попереднього завдання в процесі тестування.
У рамках STLC, фактичний процес динамічного тестування починається з розробки тестового випадку. На діаграмі нижче показано послідовність дій, кожна з яких описана після неї.
Перш ніж розпочати процес, необхідно узгодити стратегію, якої слід дотримуватися для динамічного тестування.
Стратегія тестування повинна зосереджуватися головним чином на доступних ресурсах та часових рамках. Виходячи з цих двох факторів, необхідно задокументувати мету тестування, обсяг тестування, фази або цикли тестування, тип середовища, припущення або проблеми, з якими можна зіткнутися, та ризики.
Після того, як стратегія визначена та прийнята керівництвом, починається фактичний процес проектування тестового випадку.
Розробка та впровадження тестів
На цьому етапі команда визначає наступне.
- Функції для перевірки
- Умови випробування, отримані з цих характеристик
- Елементи покриття, отримані з умов тестування
- Тестові випадки, отримані з елементів покриття
Чорна скринька методи розробки тестів такі як розбиття еквівалентності, аналіз граничних значень, тестування таблиці рішень та тестування переходу станів перетворюють тестову умову на конкретний набір виконуваних випадків.
Налаштування тестового середовища
Команда тестове середовище завжди має бути подібним до виробничого середовища. На цьому етапі встановлюється збірка, а тестові машини керуються та налаштовуються.
Виконання тесту
На цьому етапі тестові випадки фактично виконуються, або вручну, або за допомогою автоматизація, а фактичні результати записуються порівняно з очікуваними результатами.
Звіт про помилку зафіксовано
Виходячи з виконання, якщо очікувані та фактичні результати не збігаються, тестовий випадок має бути позначений як Невдалий, а помилка має бути зафіксована в управління дефектами процесу.
Переваги динамічного тестування
- Динамічне тестування виявляє дефекти, які вважаються занадто складними або складними для виявлення, і які статичний аналіз взагалі не може охопити.
- Програмне забезпечення виконується від початку до кінця, що підвищує якість як продукту, так і проекту.
- Динамічне тестування є важливим засобом виявлення загроз безпеці в працюючій системі.
- Помилки, пов'язані лише з виконанням, такі як витоки пам'яті, проблеми з синхронізацією та збої інтеграції, виникають тут і ніде більше.
Недоліки динамічного тестування
- Динамічне тестування займає багато часу, оскільки виконання програми або коду вимагає великої кількості ресурсів.
- Це збільшує вартість проекту, оскільки він не починається на ранній стадії життєвого циклу програмного забезпечення, а проблеми, виправлені на пізніших етапах, коштують дорожче.
- Продукційне середовище та реалістичні тестові дані є обов'язковими умовами, і їх створення та підтримка вимагають зусиль.
