5.44M

Category:

software

Види тестування. Заняття 6

1.

13
04
21
Заняття № 6
Види тестування
Король Артур

16
07
20
Короткий огляд лекції
Після запуску коду виконання:
Статичне.
Динамічне
За доступом до коду та архітектури програми
Black box.
White box.
За рівнем деталізації програми.
Модульна (Unit).
Інтеграційне (Integration).
Системне (System).
За рівнем автоматизації.
Ручне (Manual)
Автоматизоване (Automation).
© 2021 P lay tech plc
playtech.com

3.

Короткий огляд лекції
• За принципами роботи із додатком.
Позитивне та негативне.
• За ступенем важливості функцій, що тестуються.
Димове (Smoke).
Критичний тест (Critical path test).
• За цілями та завданнями:
функціональне.
Нефункціональне.
Пов'язані зі змінами
© 2021 P lay tech plc
playtech.com

4.

Mindmap
© 2021 P lay tech plc
playtech.com
4

5.

Класифікація із запуску коду на виконання:
Статичне тестування – тестування без запуску коду на виконання.
В рамках цього підходу тестування можуть піддаватися:
o Документи (вимоги, тест-кейси, описи архітектури додатка, схеми баз даних тощо).
o Графічні прототипи (наприклад, ескізи інтерфейсу користувача).
o Код програми (що часто виконується самими програмістами в рамках аудиту коду)
o Параметри (налаштування) середовища виконання програми.
o Підготовлені тестові дані.
Динамічне тестування – тестування із запуском коду на виконання.
o Запускатися виконання може як код всього докладання повністю (системне
тестування), і код кількох взаємозалежних частин̆. Основна ідея цього виду тестування
полягає в тому, що перевіряється реальна поведінка (частини) програми.
© 2021 P lay tech plc
playtech.com
5

6.

Класифікація з доступу до коду та архітектури:
Метод білої скриньки (white box testing, open box testing, clear box testing, glass box
testing) — тестувальник має доступ до внутрішньої структури і коду програми, а також
є достатньо знань для розуміння побаченого.
Метод чорної скриньки (black box testing, closed box testing, specification-based
testing) — у тестувальника або немає доступу до внутрішньої структури і коду
докладання, або недостатньо знань їхнього розуміння, або він свідомо не
звертається до них у процесі тестування.
Метод сірої скриньки (gray box testing) — комбінація методів білої скриньки та
чорної скриньки, яка полягає в тому, що до частини коду та архітектури у
тестувальника доступ є, а до частини — ні
© 2021 P lay tech plc
playtech.com

7.

Переваги методу «чорної скриньки»
• Тестувальник не повинен мати (глибокі) знання в
галузі програмування.
• Поведінка додатку досліджується в контексті
реального середовища виконання і враховує її вплив.
• Поведінка програми досліджується в контексті
реальних користувальницьких сценаріїв.
• Тест-кейси можна створювати на стадії появи
стабільних вимог.
• Процес створення тест-кейсів дозволяє виявити
дефекти вимог.
• Допускає створення тест-кейсів, які можна
багаторазово використовувати на різних проектах.
© 2021 P lay tech plc
playtech.com
7

8.

9.

За рівнем деталізації програми:
• Модульне (компонентне) тестування (unit testing, module testing,
component testing) спрямоване на перевірку окремих невеликих частин
програми, які (як правило) можна досліджувати ізольовано від інших подібних
частин.
• Інтеграційне ((integration testing, component integration testing, pairwise
integration testing, system integration testing) - спрямовано перевірку взаємодії
між кількома частинами докладання (кожна з яких, своєю чергою, перевірена
окремо на стадії модульного тестування).
• Системне тестування (system testing) спрямоване на перевірку всього
додатка як єдиного цілого, зібраного з частин, перевірених на двох
попередніх стадіях.
© 2021 P lay tech plc
playtech.com
9

10.

Не плутаємо рівні тестування та види тестування
Класифікація по ISTQB:
Альтернативна
класифікація
>>>
© 2021 P lay tech plc
playtech.com

11.

Класифікація за принципами роботи з додатком:
• Позитивне тестування (positive testing) спрямоване дослідження додатку у
ситуації, коли всі дії виконуються суворо за інструкцією без будь-яких
помилок, відхилень, введення невірних даних, і т.д. Якщо позитивні тесткейси завершуються помилками, це тривожна ознака - програма працює
неправильно навіть в ідеальних умовах.
• Негативне тестування (negative testing, invalid testing) — спрямоване на
дослідження роботи програми у ситуаціях, коли з ним виконуються
некоректні операції та/або використовуються дані, що потенційно призводять
до помилки (розподіл на нуль). Користувачі припускаються помилок,
зловмисники усвідомлено «ламають» додаток, у середовищі роботи
програми виникають проблеми).
• Висновок: негативних
позитивних.
© 2021 P lay tech plc
playtech.com
тест-кейсів
виявляється
значно
більше,
ніж
11

12.

16
07
20
Класифікація за ступенем важливості функцій, що
тестуються:
(!) Увага! Можлива плутанина, викликана тим, що єдиного загальноприйнятого
набору класифікацій не існує, і дві з них мають схожі назви:
• «За рівнем деталізації програми» = «за рівнем тестування».
• «За (зменшенням) ступеня важливості тестованих функцій» = «за рівнем
функціонального тестування»
Димове тестування - перевірка найважливішої функціональності програмного
продукту.Тестування критичного шляху - перевірка функціональності, що
використовується типовими користувачами в повсякденній діяльності.Розширене
тестування - перевірка всієї заявленої функціональності
© 2021 P lay tech plc
playtech.com

13.

14.

За ступенем формалізації:
• Тестування на основі тест-кейсів (scripted testing, test case-based testing) формалізований підхід, в якому тестування проводиться на основі заздалегідь
підготовлених тест-кейсів, наборів тест-кейсів та іншої документації.
• Дослідницьке тестування (exploratory testing) — частково формалізований підхід,
у межах якого тестувальник виконує роботу з додатком за вибраним сценарієм,
який, своєю чергою, доопрацьовується під час виконання з метою повного
дослідження докладання.
• Вільне (інтуїтивне) тестування (ad hoc testing) - повністю неформалізований
підхід, в якому не передбачається використання ні тест-кейсів, ні чек-листів, ні
сценаріїв - тестувальник повністю спирається на свій професіоналізм та інтуїцію
(experience-based testing) для спонтанного виконання з додатком дій, які, на його
думку, можуть виявити помилку.
© 2021 P lay tech plc
playtech.com
14

15.

16
07
20
За цілями та завданнями:
• Функціональне тестування (functional testing) - вид тестування, спрямований на
перевірку коректності роботи функціональності програми (коректність реалізації
функціональних вимог).
• Нефункціональне тестування (non-functional testing) — вид тестування,
спрямований на перевірку нефункціональних особливостей програми (коректність
реалізації нефункціональних вимог), таких як зручність використання, сумісність,
продуктивність, безпека і т.д.
• + пов'язані зі змінами (види тестування)
© 2021 P lay tech plc
playtech.com

16.

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

17.

Усі види тестування продуктивності:
• Навантажувальне тестування - це автоматизоване тестування, що імітує роботу певної
кількості бізнес користувачів на будь-якому загальному (розділюваному ними) ресурсі.
• Стресове тестування (Stress Testing) дозволяє перевірити наскільки додаток і система в
цілому працездатні в умовах стресу і також оцінити здатність системи до регенерації, тобто.
до повернення до нормального стану після припинення впливу стресу. Стресом у цьому
контексті може бути підвищення інтенсивності виконання операцій до дуже високих значень
або аварійна зміна конфігурації сервера. Також одним із завдань при стресовому тестуванні
може бути оцінка деградації продуктивності, таким чином цілі стресового тестування можуть
перетинатися з цілями тестування продуктивності.
• Тестування стабільності або надійності (Stability/Reliability Testing) - завданням тестування
стабільності (надійності) є перевірка працездатності програми при тривалому
(багатогодинному) тестуванні із середнім рівнем навантаження.
• Об'ємне тестування (Volume Testing). Завданням об'ємного тестування є отримання оцінки
продуктивності зі збільшенням обсягів даних у базі даних докладання.
© 2021 P lay tech plc
playtech.com
17

18.

Нефункціональні види тестування:
• Тестування установки спрямовано на перевірку успішної
інсталяції та настройки, а також оновлення або видалення
програмного забезпечення.
• Конфігураційне тестування (Configuration Testing) спеціальний вид тестування, спрямований на перевірку
роботи
програмного
забезпечення
при
різних
конфігураціях
системи
(заявлених
платформах,
підтримуваних драйверах, при різних конфігураціях
комп'ютерів і т.д.)
• Тестування на відмову та відновлення (Failover and
Recovery Testing) перевіряє тестований продукт з точки
зору здатності протистояти і успішно відновлюватися після
можливих збоїв, що виникли у зв'язку з помилками
програмного забезпечення, відмови обладнання або
проблемами зв'язку (наприклад, відмова мережі).
© 2021 P lay tech plc
playtech.com
18

19.

Нефункціональне тестування:
• Тестування
інтерфейсу
користувача
(GUI
Testing)
—
функціональна
перевірка
інтерфейсу на відповідність вимогам — розмір,
шрифт, колір, consistent behavior.
• Тестування зручності використання (usability
testing) - тестування, спрямоване на дослідження
того, наскільки кінцевому користувачеві зрозуміло,
як працювати з продуктом (understandability,
learnability, operability), а також на те, наскільки йому
подобається
використовувати
продукт
(attractiveness)
© 2021 P lay tech plc
playtech.com
19

20.

Пов'язані зі змінами види тестування:
Після проведення необхідних змін, таких як виправлення бага/дефекту, програмне
забезпечення має бути перетестовано для підтвердження того факту, що проблема
була дійсно вирішена:
Димове тестування (Smoke Testing)
Регресійне тестування (Regression Testing)
Тестування складання (Build Verification Test)
Санітарне тестування
або перевірка узгодженості/справності
(Sanity Testing)
© 2021 P lay tech plc
playtech.com
20

21.

Пов'язані зі змінами види тестування:
• Димове (Smoke) тестування розглядається як короткий цикл тестів, що виконується для
підтвердження того, що після складання коду (нового або виправленого) додаток, що
встановлюється, стартує і виконує основні функції.
• Регресійне тестування - це вид тестування спрямований на перевірку змін, зроблених у додатку
або навколишньому середовищі (починання дефекту, злиття коду, міграція на іншу операційну
систему, базу даних, веб сервер або сервер програми), для підтвердження того факту, що існуюча
раніше функціональність працює як і раніше.
• Повторне тестування - тестування, під час якого виконуються тестові сценарії, що виявили
помилки під час останнього запуску, для підтвердження успішності виправлення цих помилок. В
чому різниця між regression testing і re-testing? Re-testing — перевіряється виправлення багів
Regression testing — перевіряється те, що виправлення багів, а також будь-які зміни в коді
програми, не вплинули на інші модулі ПО і не викликало нових багів.
• Тестування збірки або Build Verification Test — тестування спрямоване на визначення
відповідності, випущеної версії, критеріям якості для початку тестування.
• Санітарне тестування - це вузькоспрямоване тестування достатнє для доказу того, що конкретна
функція працює відповідно до заявлених у специфікації вимог. Зазвичай виконується вручну.
© 2021 P lay tech plc
playtech.com
21

Види тестування. Заняття 6

1.

2.

3.

4.

5.

6.

7.

8.

9.

10.

11.

12.

13.

14.

15.

16.

17.

18.

19.

20.

21.

22.

23.

24.

25.