Підведення підсумків заняття. 6. Домашнє завдання:вивчити матеріал лекції.

6. Домашнє завдання: вивчити матеріал лекції.

7. Самостійне вивчення: опрацювати тему „Переваги та недоліки ручного та автоматизованого тестування” з Методичного посібника для самостійної роботи або з будь-якого іншого джерела (наприклад, мережі Інтернет).

Зміст лекції

Використання різних підходів до тестування визначається їх ефективністю відносно умов, що визначаються промисловим проектом. В реальних випадках робота групи тестування планується так, щоб розробка тестів починалася з моменту затвердження вимог до програмного продукту та продовжувалась паралельно з розробкою дизайну та коду продукту. В результаті, до початку системного тестування створюються тестові набори, що містять тисячі тестів. Великий набір тестів забезпечує всебічну перевірку функціональності продукту та гарантує якість продукту, але пропуск такої кількості тестів на етапі системного тестування представляє проблему. Її рішення лежить в області автоматизації тестування, тобто автоматизації розробки. Розглянемо приклад.

Структура програми Р тесту:

Загрузка тесту (X,Y*)

Запуск модулю, що тестується

Порівняння отриманих результатів Y з еталонним Y*

Структура комплексу, що тестується

ModF <- МоdF1

МоdF2

МоdF3 <- МоdF31

МоdF32

Структура тестуючого модулю

Mod TestModF:

Mod TestМодF1

Mоd TestМодF2

Mоd TestМодF3

P TestМодF

Mоd TestModF1:

P TestМодF1

Mоd TestModF2:

P TestМодF2

Mоd TestModF3:

Mod TestМодF31

Mоd TestМодF32

P TestМодF3

В цьому прикладі приведені структура тесту, структура комплексу, що тестується, та структура тестуючого модулю. Особливістю структури кожного з тестуючих модулів Мі є запуск тестуючої програми Рі після того, як кожен з модулів Mij, що входять в контекст модулю Mi, буде протестований. В цьому випадку запуск тестуючого модулю забезпечує рекурсивний спуск до програм тестування модулів нижнього рівня, а потім виконує тестування рівнів, що лежать вище, в умовах того, що ті що лежать нижче, вже протестовані. Тестові набори подібної структури орієнтовані на автоматичне керування пропуском тестового набору в тестовому циклі. Важливою перевагою подібної організації є можливість регулювання нижнього рівня, до якого потрібно доходити в циклі тестування. В цьому випадку контекст редуційованих в конкретному тестовому циклі модулів помічається як базовий, що не підлягає тестуванню. Наприклад, якщо контекст модулю ModF3: (ModF31, ModF32) – помічений як базовий, то в результаті рекурсивний спуск буде стосуватися тільки модулів ModF1, ModF2, ModF3 та модулю ModF, який лежить вище. Описаний спосіб організації тестових наборів з успіхом застосовується в системах автоматизації тестування.

Власне, використання ефективної системи автоматизації тестування зменшує до мінімуму (наприклад, до однієї ночі) час прогону тестів, без якого неможливо підтвердити факт росту якості (зменшення кількості помилок) продукту. Системне тестування відбувається в рамках циклів тестування(періодів пропусків розробленого тестового набору над build додатку, що розробляється). Перед кожним циклом фіксується розроблений або виправлений build, на який заносяться знайдені в результаті тестового прогону помилки. Потім помилки виправляються, та на наступний цикл тестування надається новий build. Закінчення тестування співпадає з експериментально підтвердженим висновком про досягнутий рівень якості відносно обраного критерію тестування або про зниження щільності не знайдених помилок до деякої раніше оговореної величини. Можливість обмежити цикл тестування межею в одну добу або в декілька годин підтримується виключно за рахунок засобів автоматизації тестування.

Рис. 3.2. Структура інструментальної системи автоматизації тестування

На рис. 3.2 представлена узагальнена структура системи автоматизації тестування, в якій створюється та зберігається наступна інформація:

- набір тестів, який достатній для покриття додатку, що тестується, відповідно до обраного критерію тестування – як результат ручної або автоматичної розробки (генерації) тестових наборів та драйвер /монітор пропуску тестового набору. Результати прогону тестового набору зафіксовані в Log – файлі, що містить траси („ протоколи ”), які представляють собою реалізовані при тестовому прогоні послідовності деяких подій (значення окремих змінних або їх сукупностей) та точки реалізації цих подій на графі програми. В склад трас можуть входити послідовності явно та неявно заданих міток, які задають шляхи реалізації трас на керуючому графі програми, сукупності значень змінних на цих мітках, величини проміжних результатів, що досягнуті на деяких мітках і т.д.

- статистика тестового циклу, яка містить: 1) результати пропуску кожного тесту з тестового набору та їх порівняння з еталонними величинами; 2) факти, що стали основою для прийняття рішення про продовження або про закінчення тестування; 3)критерій покриття та ступінь його задоволення, що досягнута в циклі тестування.

Результатом аналізу кожного прогону є список проблем, в вигляді помилок та дефектів, який заноситься в базу розвитку проекту. Далі проходить робота над помилками, де кожна знайдена проблема ідентифікується, відноситься до відповідного модулю та розробника, їй надається свій пріоритет, а також вона відстежується, що надає гарантію її вирішення (виправлення та віднесення до списку відомих проблем, вирішення яких з тих чи інших причин відкладається) в наступних build. Виправлений та зібраний для тестування build проходить на наступний цикл тестування, і цикл повторюється, доки потрібна якість програмного комплексу не буде досягнута. В цьому ітераційному процесі засоби автоматизації тестування забезпечують швидкий контроль результатів виправлення помилок та перевірку рівня якості, який досягнуто в продукті.

Витрати тестування. Інтенсивність знаходження помилок на одиницю витрат та надійність тісно пов’язані з часом тестування та, відповідно, з гарантією якості продукту. Чим більше трудовитрат вкладається в процес тестування, тим менше помилок в продукті залишається непоміченим. Проте досконалість в індустріальному програмуванні має межі, які перш за все пов’язані з витратами на отримання програмного продукту, а також з перебільшенням якості, яке не затребуване замовником додатку. Знаходження оптимуму - дуже відповідальна задача тестувальника та менеджера проекту.

Рух до зменшення числа помилок, що залишилися, або до якості продукту приводить до застосуванню різних методів відлагодження та тестування залежно від вдосконалення інструментарію та методів тестування, що застосовуються. На практиці популярні наступні методи тестування та відлагодження, що впорядковані по пов’язаним з їх застосуванням витрати:

- статичні методи тестування;

- модульне тестування;

- інтеграційне тестування;

- системне тестування;

- тестування реального оточення та реального часу.

Залежність ефективності застосування перелічених методів та їх здатності до знаходження відповідних класів помилок. З часом, в міру знаходження більш складних помилок та дефектів, ефективність низькозатратних методів падає разом з кількістю знайдених помилок.

Звідси можна зробити висновок, що всі методи тестування не тільки мають право на існування, але й мають свою нішу, де вони добре знаходять помилки, тоді як поза нішею їх ефективність падає. Тому необхідно суміщати різні методи та стратегії відладки та тестування з метою забезпечення запланованої якості програмного продукту.

Дата добавления: 2015-07-15