Лабораторная Робота ООП №1. Класифікація#2. Класифікація видів тестування за ознаками. I. За ступенем автоматизації
 Скачать 34.77 Kb.
|
|
Класифікація видів тестування за ознаками. I. За ступенем автоматизації: 1. Ручне тестування (manual testing) - це процес ручної перевірки програмного забезпечення на помилки. Тестувальник має відігравати роль користувача програми й використовувати властивості програми для знаходження помилок у роботі програми. Для професійного тестування тестувальник часто користується написаним планом тестування з варіантами тестування (test cases). 2. Автоматизоване тестування (automated testing)- частина процесу тестування на етапі контролю якості в процесі розробки програмного забезпечення. Воно використовує програмні засоби для виконання тестів і перевірки результатів виконання, що допомагає скоротити час тестування і спростити його процес. Перші спроби «автоматизації» з'явилися в епоху операційних систем DOS і CP/M. Тоді вона полягала у видачі додатком команд через командний рядок і аналізі результатів. Трохи пізніше додалися віддалені виклики через API для роботи з мережі. Вперше про автоматизоване тестування згадується в книзі Фредеріка Брукса «Міфічний людино-місяць», де йдеться про перспективи використання модульного тестування. Але по-справжньому автоматизація тестування стала розвиватися тільки в 1980-х роках. Існує два основних підходи до автоматизації тестування: тестування на рівні коду і GUI-тестування. До першого типу належить, зокрема, модульне тестування. До другого — імітація дій користувача за допомогою спеціальних тестових фреймворків. Найпоширенішою формою автоматизації є тестування додатків через графічний інтерфейс користувача. Популярність такого виду тестування пояснюється двома факторами: по-перше, додаток тестується тим же способом, яким його буде використовувати людина, по-друге, можна тестувати додаток, не маючи при цьому доступу до вихідного коду. GUI-автоматизація розвивалася протягом 4 поколінь інструментів і технік: 1. Утиліти запису і відтворення (capture/playback tools) — записують дії тестувальника під час ручного тестування. Вони дозволяють виконувати тести без прямої участі людини протягом тривалого часу, значно збільшуючи продуктивність і усуваючи «безглузде» повторення одноманітних дій під час ручного тестування. У той же час, будь-яка мала зміна ПЗ, що тестується вимагає перезапису ручних тестів. Тому це перше покоління інструментів не ефективне і не масштабоване. 2. Сценарії (Scripting) — форма програмування на мовах, спеціально розроблених для автоматизації тестування ПЗ — пом'якшує багато проблем capture/playback tools. Але розробкою займаються програмісти високого рівня, які працюють окремо від тестувальників, що безпосередньо запускають тести. До того ж скрипти найбільше підходять для тестування GUI і не можуть бути впровадженими, пакетними або взагалі будь-яким чином об'єднані в систему. Нарешті, зміни в ПЗ, яке тестується вимагають складних змін у відповідних скриптах, і підтримка все більше зростаючої бібліотеки тестуючих скриптів стає зрештою непереборним завданням. 2. Опис видів тестування Інсталяційне тестування Інсталяційне тестування запевняє, що система встановлена правильно і коректно працює на апаратному забезпеченні конкретного клієнта. Тестування сумісності Основною метою якого є перевірка коректної роботи продукту в певному середовищі. Середовище може включати в себе наступні елементи: Апаратна платформа Мережеві пристрої Периферія (принтери, CD/DVD-приводи, веб-камери та ін.); Операційна система (Unix, Windows, MacOS, …) Бази даних (Oracle, MS SQL, MySQL, …) Системне програмне забезпечення (веб-сервер, фаєрвол, антивірус, …) Браузери (Internet Explorer, Firefox, Opera, Chrome, Safari) Смоук тестування (Smoke testing) Мінімальний набір тестів на явні помилки. Цей тест зазвичай виконується самим програмістом. Програму, що не пройшла такий тест, не має сенсу передавати на глибше тестування. Регресивне тестування Виявляє помилки у вже протестованих ділянках початкового коду. Такі помилки — коли після внесення змін до програми перестає працювати те, що мало б працювати, — називають регресивними помилками. Регресивне тестування (за деякими джерелами) включає: new bug-fix — перевірка виправлення знайдених дефектів; old bug-fix — перевірка, що виявлені раніше й виправлені дефекти не відтворюються в системі знову; side-effect — перевірка того, що не порушилася працездатність працюючої раніше функціональності, якщо її код міг бути зачеплений під час виправлення деяких дефектів в іншій функціональності.    Функціональне тестування. Перевіряє, чи реалізовані функціональні вимоги, тобто можливості ПЗ в певних умовах вирішувати завдання, потрібні користувачам. Функціональні вимоги визначають, що саме робить продукт, які завдання вирішує. Функціональні вимоги включають в себе: Функціональна придатність Точність Можливість до взаємодії Відповідність стандартам та правилам Захищеність 3. Рівні тестування Модульне тестування. Відноситься до тестів, які перевіряють функціональність певного розділу коду, зазвичай на функціональному рівні. В об'єктно-орієнтованому середовищі, це, як правило, тестування на рівні класу, а мінімальні модульні тести містять у собі конструктори та деструктори. Такі типи тестів зазвичай пишуться розробниками під час роботи над кодом (стиль «білої скриньки»), щоб впевнитись, що дана функція працює так, як очікувалося. Одна функція може мати кілька тестів, щоб переглянути всі випадки використання коду. Модульне тестування саме по собі не може перевірити функціонування частини ПЗ, а використовується щоб гарантувати, що основні блоки ПЗ працюють незалежно один від одного. Модульне тестування — це процес розробки ПЗ, що включає в себе синхронізовані застосування широкого спектру для запобігання дефектів та для виявлення стратегій з метою зниження ризиків розробки ПЗ, часу та витрат. Воно виконується розробником ПЗ або інженером, під час будівельної фази життєвого циклу розробки ПЗ. Модульне тестування спрямоване на усунення помилок проектування. Ця стратегія спрямована на підвищення якості одержуваного ПЗ, до такого рівня, як вимагає процес контролю якості. Залежно від очікуваної організації розробки ПЗ, модульне тестування може включати статичний аналіз коду, аналіз потоку даних аналізу метрик, експертні оцінки коду, аналізу покриття коду та інші методи перевірки ПЗ. Інтеграційне тестування. Інтеграційне тестування є типом тестування ПЗ, яке прагне перевірити інтерфейси між компонентами від програмного дизайну. Програмні компоненти можуть бути інтегровані як в рамках ітеративного підходу, так і всі разом. Інтеграційне тестування працює над виявленням дефектів у інтерфейсах та взаємодії інтегрованих компонентів (модулів). Воно проводиться до тих пір, поки великі групп тестованих компонентів ПЗ, які відповідають потрібній архітектурі, починають працювати як система. Рівні інтеграційного тестування: компонентний інтеграційний рівень (Component Integration testing). Перевіряється взаємодія між компонентами системи після проведення компонентного тестування; системний інтеграційний рівень (System Integration Testing). Перевіряється взаємодія між різними системами після проведення системного тестування. 4. Техніка тестування Існує багато прийомів тестування ПЗ. Деякі з них перевершують інші, деякі можна використовувати сукупно з вними для кращих результатів. Нижче представлений список основних прийомів тестування: 1. Ручне тестування – тести виконуються людьми з наперед складеними, або визначеними для кожного випробування тестовими даними. 2. Автоматизоване тестування – тести виконуються спеціальними інструментами або самостійними процесами і можуть повторюватися багато раз. Тестові дані попередньо вводяться або генеруються. 3. Регресивне тестування – тести, зазвичай автоматизовані, мають на меті виявлення негативного впливу змін в програмі на функції, що пройшли попередні перевірки. 4. Димове тестування – тести, спрямовані на швидку перевірку базової функціональності, з метою виявлення, чи новий білд (версія програми чи її певного модуля) вартий тестування. 5. Дослідницьке тестування – тести, що виконуються за відсутністю специфікацій. Тестер розроблює власну систему тестування, яка базується на накопиченому їм досвіді та оцінює ризики, створюючи сценарії тестування. 1. Фази тестування Фази тестування: Створення тестового набору (Test Suit) для конкретного середовища тестування (Testing Environment) Прогон програми на тестах з отриманням протоколу результатів тестування (Test Log) результатів виконання програми на наборі тестів з метою прийняття рішення про продовження або зупинку тестування. Класи еквівалентності (Equivalence class): Підхід полягає в наступному: вхідні / вихідні дані розбиваються на класи еквівалентності, за принципом, що програма веде себе однаково з кожним представником окремого класу. Таким чином, немає необхідності тестувати всі можливі вхідні дані, необхідно перевірити по окремо взятому представнику класу. Клас еквівалентності – це набір значень змінної, який вважається еквівалентним. Тестові сценарії еквівалентні, якщо: Вони тестують одне і те ж; Якщо один з них знаходить помилку, то й інші виявлять її; Якщо один з них не знаходить помилку, то й інші не виявлять її. Еквівалентне розбиття: Розробка тестів методом чорного ящика, в якому тестові сценарії створюються для перевірки елементів еквівалентної області. Як правило, тестові сценарії розробляються для покриття кожній області як мінімум один раз. Приклад: Припустимо, ми тестуємо Інтернет-магазин, який продає олівці. У замовленні необхідно вказати кількість олівців (максимум для замовлення – 1000 штук). Залежно від замовленої кількості олівців змінюється вартість: 1 – 100 – 10 грн. за олівець; 101 – 200 – 9 грн. за олівець; 201 – 300 – 8 грн. за олівець і т.д. З кожною новою сотнею, ціна зменшується на гривню. 2. Особливості вимог програмного забезпечення. Вимоги (Requirements) до програмного забезпечення – сукупність тверджень щодо атрибутів, властивостей, або якостей програмної системи, що підлягає реалізації: 1. Одиничність – Вимога описує одну і тільки одну річ. 2. Завершеність – Вимога повністю визначена в одному місці і вся необхідна інформація присутня. 3. Послідовність – Вимога не суперечить іншим вимогам і повністю відповідає зовнішній документації. 4. Атомарність – Вимога не може бути розбита на ряд більш детальних вимог без втрати завершеності. 5. Відстежування – Вимога повністю або частково відповідає діловим потребам як заявлено зацікавленими особами і задокументовано. 6. Актуальність – Вимога не стала застарілою з часом. 7. Здійснимість – Вимога може бути реалізовано в межах проекту. 8. Недвозначність – Вимога коротко визначена без звернення до технічного жаргону та інших прихованих формулювань. Вона виражає об’єктивні факти, можлива одна і тільки одна інтерпретація. Визначення не містить нечітких фраз. Використання негативних тверджень заборонено. 9. Обов’язковість – Вимога представляє певну характеристику, відсутність якої призведе до неповноцінності рішення, яка не може бути проігнорована. 10. Верифікованість – Реалізованість вимоги може бути визначена через один з чотирьох можливих методів: огляд, демонстрація, тест чи аналіз. Методи тетування: 1. Білий ящик (White Box) – цей метод заснований на тому, що розробник тесту має доступ до коду програм і може писати код, який пов’язаний з бібліотеками ПЗ, що тестується. 2. Чорний ящик (Black Box) – цей метод заснований на тому, що тестувальник має доступ до ПЗ тільки через ті ж інтерфейси, що і замовник або користувач, або зовнішні інтерфейси, що дозволяють іншому комп’ютеру або іншому процесу підключитися до системи для тестування. 3. Сірий ящик (Grey Box) – поєднує елементи двох попередніх підходів. 3. Характеристики якості програмного забезпечення. Якість програмного забезпечення — характеристика програмного забезпечення, ступінь відповідності ПЗ до вимог. При цьому вимоги можуть трактуватись по-різному, що породжує декілька незалежних визначень терміну. Якість ПЗ – набір властивостей продукту (сервісу або програм), що характеризують його здатність задовольнити встановлені або передбачувані потреби замовника. Поняття якості має різні інтерпретації залежно від конкретної програмної системи і вимог до неї. Якість коду може визначатись різними критеріями. Деякі з них мають значення тільки з точки зору людини. Наприклад, форматування тексту програми — неважливо для комп'ютеру, але може мати велике значення для супроводу. Багато з існуючих стандартів кодування, що визначають специфічні для мови програмування угоди та задають низку правил, мають на меті полегшити супровід ПЗ в майбутньому. Також існують інші критерії, що визначають чи «гарно» написаний код, наприклад, такі, як структурованість — ступінь логічного розділення коду на блоки. Деякі фактори: Прочитність коду Легкість підтримки, тестування, відлагодження, виправляння помилок, рефакторингу та портування Низька складність коду Коректність обробки винятків Характеристики якості ПЗ Стандарт ISO/IEC 9126 регламентує зовнішні і внутрішні характеристики якості. Перші відображають вимоги до функціонування програмного продукту. Для кількісного встановлення критеріїв якості, за якими буде здійснюватися перевірка і підтвердження відповідності ПЗ заданим вимогам, визначаються відповідні зовнішні вимірювані властивості (зовнішні атрибути) ПЗ, метрики (наприклад, час виконання окремих компонентів), діапазони зміни значень і моделі їх оцінки. Метрики використовуються на стадії тестування або функціонування і називаються зовнішніми метриками. Вони являють собою моделі оцінки атрибутів. Внутрішні характеристики якості і внутрішні атрибути ПЗ використовуються для складання плану досягнення необхідних зовнішніх характеристик якості продукту. Для квантифікації внутрішніх характеристик якості застосовують внутрішні метрики, як інструмент перевірки відповідності проміжних продуктів внутрішнім вимогам до якості, які формулюються на процесах, що передують тестуванню. Зовнішні і внутрішні характеристики якості відображають властивості самого ПЗ (працюючого або не працюючого), а також погляд замовника і розробника на таке ПЗ. Безпосереднього кінцевого користувача ПЗ цікавить експлуатаційна якість ПЗ – сукупний ефект від досягнення характеристик якості, що виміряється строком результату, а не властивістю самого ПЗ. Це поняття ширше, ніж будь-яка окрема характеристика (наприклад, зручність використання або надійність). |