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

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

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

Зміст лекції

Кожен дефект, виявлений у процесі тестування, повинен бути задокументований і відстежений. При виявленні нового дефекту його заносять у базу дефектів. Для цього найкраще використати спеціалізовані бази, що підтримують зберігання й відстеження дефектів - типу DDTS. При занесенні нового дефекту рекомендується вказувати, як мінімум, наступну інформацію:

- Найменування підсистеми, у якій виявлений дефект.

- Версія продукту (номер build), на якому дефект був знайдений.

- Опис дефекту.

- Опис процедури (кроків, необхідних для відтворення дефекту).

- Номер тесту, на якому дефект був виявлений.

- Рівень дефекту, тобто ступінь його серйозності з погляду критеріїв якості продукту або замовника.

Занесений у базу дефектів новий дефект перебуває в стані "New". Після того, як команда розроблювачів проаналізує дефект, він переводиться в стан "Open" із вказівкою конкретного розроблювача, відповідального за виправлення дефекту. Після виправлення дефект переводиться розроблювачем у стан "Resolved". При цьому розроблювач повинен вказати наступну інформацію:

- Причину виникнення дефекту.

- Місце виправлення, як мінімум, з точністю до виправленого файлу.

- Короткий опис того, що було виправлено.

- Час, витрачений на виправлення.

Після цього тестувальник перевіряє, чи дійсно дефект був виправлений і якщо це так, переводить його в стан "Verified". Якщо тестувальник не підтвердить факт виправлення дефекту, то стан дефекту змінюється знову на "Open".

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

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

- Перелік функціональності відповідно до пунктів вимог, запланований для тестування на даному циклі, і реальні дані по ньому.

- Кількість виконаних тестів - заплановане й реально виконане.

- Час, витрачений на тестування кожної функції, і загальний час тестування.

- Кількість знайдених дефектів.

- Кількість повторно відкритих дефектів.

- Відхилення від запланованої послідовності дій, якщо такі мали місце.

- Висновки про необхідні коректування в системі тестів, які повинні бути зроблені до наступного тестового циклу.

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

1)Тестові метрики. Існує устояний набір тестових метрик, що допомагає визначити ефективність тестування й поточний стан продукту. До таких метрик відносяться наступні:

- Покриття функціональних вимог.

- Покриття коду продукту. Найбільш застосовна для модульного рівня тестування.

- Покриття множини сценаріїв.

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

- Співвідношення кількості знайдених дефектів з кількістю тестів на дану функцію продукту. Сильна розбіжність цих двох величин говорить або про неефективність тестів (коли велика кількість тестів знаходить мало дефектів) або про погану якість даної ділянки коду (коли знайдена велика кількість дефектів на не дуже великій кількості тестів).

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

2) Огляди тестів і стратегії. Тестовий код і стратегія тестування, зафіксовані у вигляді документів, помітно поліпшуються, якщо піддаються колективному обговоренню. Такі обговорення називаються оглядами (review). Існує прийнята в організації процедура проведення й оцінки результатів огляду. Огляди поряд з тестуванням утворять потужний набір методів боротьби з помилками з метою підвищення якості продукту. Цілі оглядів тестової стратегії й тестового коду різні.

Цілі огляду тестової стратегії:

- Установити достатність перевірок, забезпечуваних тестуванням.

- Проаналізувати оптимальність покриття або адекватність розподілу кількості планованих тестів по функціональності продукту.

- Проаналізувати оптимальність підходу до розробки коду, генерації коду, автоматизації тестування.

Цілі огляду тестового коду:

- Установити відповідність тестового набору тестової стратегії.

- Перевірити правильність кодування тестів.

- Оцінити досягнутий ступінь якості коду, виходячи з вимог по стандартах, простоті підтримки, наявності коментарів і т.п.

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

Лекція 2 (2 години)

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