1.3. Об’єкти та види тестування
1.3.1. Основні класифікації дій з тестування
Аналіз задач тестування і розподіл дій з тестування по процесах ЖЦ ПС (див. табл. 1.1) дозволяє виділити п’ять критеріїв їх класифікації:
1) спрямованість: демонстраційне тестування, що засвідчує прийнятно малу кількість відмов ПС, та деструктивне тестування, призначене для максимального виявлення відмов та дефектів;
2) рівень, що спільно визначається типом тестованого об’єкта і типом пошукуваних помилок;
3) статус формованих рішень: тестування впродовж розроблення ПС/випробування;
4) перевірювані характеристики (цілі) якості;
5) час проведення в ЖЦ ПС: первинне, регресійне, повторне, димове, санітарне, Альфа і Бета.
Стандарт ДСТУ 3918-99 [8] визначає чотири рівні тестування, а ДСТУ 2853-94 – види випробувань в ЖЦ ПС, впорядковані за ступенем важливості рішень на підставі їх результатів (див. рис. 1.5). У приймальних випробуваннях реалізується п’ятий рівень тестування – приймальне тестування.
Перед випуском ПС здійснюється Альфа і Бета тестування. Для цього ПС надається обмеженій групі користувачів – внутрішніх (Альфа) або зовнішніх (Бета), що експлуатують її, повідомляючи розробнику про виявлені проблеми. Знайдені відмови і дефекти свідчать про якість виконаного раніше тестування. На відміну від експлуатаційних випробувань під час дослідної експлуатації ПС, Альфа і Бета-тестування зазвичай виконується для ПС ринкового призначення, а не для конкретного замовника.
1.3.2. Види тестування
Види тестування ПС, залежно від їх цілей, можна умовно розподілити на функціональні, нефункціональні та пов'язані із змінами, які подано на рис. 1.6.
Тестування функцій (Functional testing, тестування на відповідність, тестування коректності) спрямоване на виявлення невідповідностей спостережуваної поведінки ПС специфікаціям (зовнішнім і внутрішнім) та визначенні повноти функціонального покриття щодо них. Виконується на всіх рівнях, зазвичай у середовищі розробки за планами на підставі специфікацій функціональних вимог. Переваги – імітація фактичного використання ПС, а недоліки – можливість пропуску логічних помилок у програмному забезпеченні й вірогідність надлишкового тестування.
Тестування безпеки (Security and Access Control Testing) – перевірка можливості несанкціонованого доступу до ПС. Виконується шляхом моделювання можливих атак зовнішніх користувачів (у тому числі інших ПС) з метою «зламати» систему захисту.
Тестування взаємодії (Interoperability Testing) – це функціональне тестування, що перевіряє здатність ПС взаємодіяти з одним і більш компонентами або системами і включає тестування сумісності (compatibility testing) та інтеграційне тестування.
Рис 1.5 – Рівні тестування та види випробувань в процесі конструювання ПС
Рис 1.6 – Склад видів тестування в ЖЦ ПС
Тестування продуктивності (Performance testing) визначає масштабовність ПС за навантаження, при цьому вимірюється час виконання вибраних операцій за певних інтенсивностей їх виконання, визначаються кількості одночасних користувачів ПС, межі прийнятної продуктивності при збільшенні навантаження, досліджується продуктивністьна високих, граничних, стресових навантаженнях. Включає:
тестування навантаження(load testing) – перевірку працездатності ПС при очікуваних нормальних навантаженнях;
стресове тестування (stress testing) – перевірка працездатності ПС за нестандартних умов (надмірних/відсутніх навантажень) та її відновлюваності ;
стабільності/надійності (Stability/Reliability Testing) – перевірка працездатності ПС за тривалого тестування з середнім рівнем навантаження. Перевіряється насамперед відсутність витоку пам’яті, перезапусків серверів під навантаженням та інші аспекти саме стабільності роботи. Тестування надійності виконується на наборах даних, вибраних випадковим чином з вхідного простору відповідно до операційного профілю;
тестування об'єму (volume testing) – перевірка внутрішньопрограмних або системних обмежень, пов'язаних, наприклад, з великими масивами даних, граничними об'ємами БД та іншими характеристиками об'єму.
Тестування інсталяції (Installation Testing) виконується в середовищі експлуатації (в процесі «Інсталяція ПС») на рівні системного тестування. Включає тестування плану інсталяції ПС із зовнішніх носіїв і/або відповідних програм - інсталяторів.
Тестування зручності використання (Usability Testing) спрямоване на встановлення ступеня зручності використання створеного продукту, його засвоюваності, зрозумілості й привабливості для користувачів в контексті заданих умов. Цей вид тестування надає чотириелементну оцінку рівня зручності використання ПС, а саме: продуктивності (efficiency), правильності (accuracy), активізації в пам'яті (recall) та емоційної реакції (emotional response). Часто включає також тестування документації (on-line, довідкової служби, підсистеми навчання). Не маючи нічого спільного з тестуванням функціональності інтерфейсу користувача, він тільки виконується на цьому інтерфейсі і зазвичай потребує залучення експерта в предметній області.
Тестування на відмову й відновлення (Failover/Recovery Testing) – перевірка процедур відновлення ПС системи після збоїв, специфічна для ПС.
Конфігураційне тестування (Configuration Testing) – перевірка роботи ПЗ в різних конфігураціях ПС (заявлених платформах, підтримуваних драйверах, різних конфігураціях комп'ютерів тощо).
Димове тестування (Smoke Testing) – поверхнева перевірка працездатності всіх модулів ПС та наявності в них швидко виявлюваних критичних і блокуючих дефектів. Походить з інженерної практики: “тестування нового устаткування вважалося успішним, якщо з установки не пішов дим”. Його підвидом є функціональне тестування збірки (Build Verification Testing), за результатами якого встановлена версія ПЗ приймається, або ж ні, на подальше тестування, в експлуатацію чи для поставки замовнику.
Регресійне тестування (Regression Testing) призначене для перевірки змін у ПС або в її оточенні (усунення дефекту, злиття коду, міграція до іншої ОС, БД, веб-сервер або сервер застосунків) для підтвердження відсутності змін у поведінці вже існуючої функціональності. Полягає в повторенні підмножини вже виконаних функціональних чи нефункціональних тестів та розробці нових тестів для перевірки правильності внесених змін. На відміну від повторного, регресійне тестування планується, і при його плануванні вирішується проблема вибору мінімального набору регресійних тестів.
Санітарне тестування (Sanity Testing) – вузькоспрямований підвид регресійного тестування для доказу того, що конкретна функція виконується згідно з вимогами в специфікації. Зазвичай виконується вручну для визначення працездатності певної частини застосунку після змін у ній або в її оточенні. На відміну від димового, призначеного для покриття тестами якомога більшого функціоналу в найкоротші терміни, санітарне тестування спрямоване на поглиблене дослідження окремої функції.
Література до Лекції 1
1. Андон Ф.И., Коваль Г.И., Коротун Т.М., Лаврищева Е.М., Суслов В.Ю Основы инженерии качества программных систем. – 2-е изд., перераб. и доп. – К.: Академпериодика, 2007. – 672 с.
2. ДСТУ 2844 ДСТУ 2844-94. Програмні засоби ЕОМ. Забезпечення якості. Терміни та визначення.
3. ISO/IEC 9126-1:2001 Software engineering - Product quality -Part 1: Quality model.
4. IEEE 830-1998. Recommended Practice for Software Requirements Specifications. New York: IEEE, 1998.
5. IEEE 1233-1998. Guide for Developing System Requirements Specifications. New York: IEEE, 1998.
6. Gelperin D., Hetzel B. Growth Software Testing // Commum. ACM, 1988.-V. 31.- № 6.- P. 687-695.
7. Software Engineering Body Knowledge (SWEBOK). // ISO/IEC JTC1/SC7 N2517, Software & System Engineering Secretariat, Canada, 2004. – 202 р
8. ДСТУ 3918-99. Інформаційні технології. Процеси життєвого циклу програмного забезпечення.