• Лекція 8
• Уніфікований процес розробки. Реалізація та тестування
  • 8.1 Життєвий цикл ПЗ в RUP
  • 8.2 Реалізація та тестування в RUP
  • 8.3 Модель реалізації (implementation model)
    • 8.3.1 Робочий процес. Реалізація
    • 8.3.2 Склад моделі реалізації
    • 8.3.3 План складання
  • 8.4 Модель тестування (test model)
    • 8.4.1 Склад моделі тестування
  • 8.5 Модель тестування та відповідальності
  • 8.6 Робочий процес тестування
    • 8.6.1 Артефакти: Тестовий приклад
    • 8.6.2 Завдання для формування тестових прикладів
    • 8.6.3 Артефакти: Тестові приклади (Test Cases)
    • 8.6.4 Артефакти: Дефект
  • 8.7 Види тестування
    • 8.7.1 За рівнем знання системи:
    • 8.7.2 За часом виконання тестування:
    • 8.7.3 За об’єктом тестування:
    • 8.7.4 За ступенем автоматизації:
    • 8.7.5 За ступенем ізольованості компонентів:
    • 8.7.6 За ступенем підготовленості до тестування:
    • 8.7.7 За ознакою позитивності сценаріїв:
  • 8.8 Тестування в різних моделях ЖЦ

Лекція 8

Уніфікований процес розробки. Реалізація та тестування

8.1        Життєвий цикл ПЗ в RUP

8.2        Реалізація та тестування в RUP

8.3        Модель реалізації (implementation model)

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

8.3.1        Робочий процес. Реалізація

8.3.2        Склад моделі реалізації

Модель реалізації дає опис як реалізуються класи проектування у вигляді компонентів.

Приклади стереотипів компонентів моделі реалізації

Типи стереотипів залежать від середовища розробки

8.3.3        План складання

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

План складання для кожного білду містить:

• перелік ВВ, які мають бути реалізовані в ході ітераціїї

• елементи моделі реалізації, потрібні для створення білду.

Приклад 1. Діаграма компонентів сайту (базові елементи)

Приклад 1. Діаграма компонентів пакету Admin (архітектура MVC)

8.4        Модель тестування (test model)

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

Дає опис як виконувані компоненти моделі реалізації тестуються на цілісність та проходять системні тести.

8.4.1        Склад моделі тестування

8.5        Модель тестування та відповідальності

8.6        Робочий процес тестування

8.6.1        Артефакти: Тестовий приклад

Тестовий приклад – один спосіб тестування системи, що містить предмет тестування, вхідні дані, результат та умови тестування.

Предмет тестування – системні вимоги, реалізація яких можлива під час тестування та не потребує великих витрат.

Артефакти: Тестові приклади (Test Cases)

Перевірка ВВ:

Тестування ВВ або сценарію ВВ – включає підтвердження результатів взаємодії актора із системою: передумови, постумови, яким ВВ повинен відповідати та послідовність дій ВВ;

Тестування проекту реалізації ВВ або сценарію реалізації – включає підтвердження взаємодії компонентів реалізації.

8.6.2        Завдання для формування тестових прикладів

Тестовий приклад (Test Cases)

Для проведення тестування часто формують стратегію тестування (Test_Strategy) і тестові випадки(Test Cases).

Документ із стратегією тестування має наступну структуру:

1 Вступ

1.1 Постановка мети документу

2 Цілі тестування

2.1 Опис проекту

2.2 Тестові виключення

3 Підхід до тестування

3.1 Передумови для тестування

3.2 Критерії якості

3.3 Документи із результатами

3.4 Види тестування

3.5 Основні фази тестування

3.6 Тестове оточення

3.7 Тестові припущення

3.8 Результати виконання (статуси)тестів

3.9 Інструменти тестування

3.10 Процедура звітності щодо дефектів

3.11 Пріоритизація дефектів

Назва тесту – змістовне пояснення суті тесту. Наприклад, «Запуск приложения, проверка правильности отображения главной формы и 3-х drop-down элементов Меню».

1. Загальні передумови (Common Prerequisites):

UC02 Load File виконаний.

Тестові випадки (Test Cases)

1. Загальні передумови (Common Prerequisites): БД зареєстрована, веб-сервер запущений.

2. Тестування вимоги UC05 Select X Data.

2.1Передумови (Prerequisites): UC02 Load File виконаний

8.6.3        Артефакти: Тестові приклади (Test Cases)

Тестування системи

• Тести інсталяції – перевірка встановлення системи на платформі користувача та роботи системи під час установки;

• Тести конфігурації – перевірка коректності роботи системи при різних конфігураціях:

  • Від'ємні тести – тести перевірки стійкості системи;

  • Стрес-тести – виявлення проблем під час роботи системи в умовах недостачі ресурсів або коли ресурси вичерпані.

Артефакти: процедура тестування

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

Загальна процедура тестування:

1. 1. Визначається, що об'єкт, який перевіряється, повинен бути створений;

   2. Виклик активного агенту для перевірки об'єкту;

   3. Результат перевірки порівнюється із очікуваним.

Артефакти: Тестовий компонент

Тестовий компонент (ТК) автоматизує процедури тестування або їх частини.

ТК розроблюються за допомогою:

• мов сценаріїв;

• мов програмування;

• утиліт автоматизації тестування.

8.6.4        Артефакти: Дефект

Дефект (bug) – симптом наявності в системи проблеми, яку потрібно вирішити.

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

База даних помилок (приклад структури)

• хто знайшов помилку, дата;

• опис помилки;

• модуль, в якому помилку знайшли;

• версія продукту;

• статус помилки;

• важливість (severity) помилки;

• пріоритет помилки.

Статуси:

open: знайдена;

fixed: виправлена;

can't reproduce: неможливо повторити;

by design: помилка проектувальників;

won’t fix: це не помилка;

postponed: зараз виправити важко, виправимо в наступній версії;

regression: виправлена помилка з'явилась знову.

Важливість:

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

Критична (Critical) - неправильно працює ключова бізнес логіка, або діра в системі безпеки, або частина системи в неробочому стані. Необхідне рішення проблеми.

Значна (Major) - частина основної бізнес логіки не функціонує належним чином. Помилка не критична або є можливість роботи з тестованої функціє через інші точки входу.

Незначна (Minor) - не порушує бізнес логіку частини програми, яка тестується або є очевидною проблемою користувацького інтерфейсу.

Тривіальна (Trivial) – не стосується бізнес логіки, або малопомітна у інтерфейсі користувача, або не впливає на якість продукту.

Пріорітети:

highest: неможливо поставити продукт з такою помилкою, не можна перейти до наступної версії;

high: поставити не можемо, але можна перейти до наступної версії;

medium: можемо та виправимо;

low: «косметичні» покращення – залишимо до наступної версії.

Артефакти: План тестування

План тестування – опис стратегії тестування, виділених ресурсів та графік робіт.

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

Структура стратегії тестування (Test Strategy)

1 Вступ

1.1 Мета документу

2 Цілі тестування

2.1 Опис проекту

2.2 Тестові виключення

3 Підхід до тестування

3.1 Передумови для тестування

3.2 Критерії якості

3.3 Документи із результатами

3.4 Види тестування

3.5 Основні фази тестування

3.6 Тестове оточення

3.7 Тестові припущення

3.8 Результати виконання (статуси)тестів

3.9 Інструменти тестування

3.10 Процедура звітності щодо дефектів

3.11 Пріоритети дефектів

8.7        Види тестування

8.7.1        За рівнем знання системи:

чорний ящик (Black-box testing) – без перегляду програмного коду;

білий ящик (White-box testing) – тестування із вивченням коду програми;

сірий ящик (Gray-box testing) – тестування із частковим вивченням коду програми.

8.7.2        За часом виконання тестування:

альфа-тестування (Alpha testing) – перевірка роботи ПЗ перед передачею в експлуатацію силами компанії-розробника;

півгодинне тестування (Smoke testing) – коротка перевірка функцій системи, як правило, один тест для кожної функції;

тестування нової функціональності (New feature testing);

регресійне тестуванн (Regression testing) – перевірка роботи вже протестованих модулів;

тестування під час передачі ПЗ (Acceptance testing);

бета-тестування (Beta testing) – тестування ПЗ перед випуском сторонніми силами.

8.7.3        За об’єктом тестування:

функціональне (Functional testing) – перевірка виконання заданих функцій;

тестування продуктивності (Performance testing) – перевірка стабільності роботи програми або її частини при заданому навантаженні (Load testing), при перевантаженні (Stress testing) та тривалому середньому навантаженні (Stability testing);

юзабіліті-тестування (Usability testing) – перевірка ергономічності ПЗ;

перевірка інтерфейсу користувача (UI testing);

перевірка безпеки (Security testing) – тестування роботи системи з точки зору безпеки інформації;

тестування сумісноті (Compatibility testing) – нефункціональне тестування, метою якого є перевірка коректної роботи ПЗ у певному оточенні.

8.7.4        За ступенем автоматизації:

ручне тестування (Manual testing);

автоматизоване тестуванняя (Automated testing);

напівавтоаматизоване тестування (Semiautomated testing).

8.7.5        За ступенем ізольованості компонентів:

компонентне тестування (Component / Unit testing) – перевірка коректності окремого модуля або компонента системи;

інтеграційне тестування (Integration testing) – перевірка роботи модулів, об’єднаних у групу;

системне тестування (System / end-to-end testing) – перевірка роботи зібраного ПЗ з метою встановлення відповідності очікуваним функціям.

8.7.6        За ступенем підготовленості до тестування:

формальне тестування (Formal testing) – тестування відповідно до плану, встановлених процедур;

інтуїтивне тестування (Ad hoc testing) – тестування без попереднього плану дозволяє на раніх стадіях виявляти помилки.

8.7.7        За ознакою позитивності сценаріїв:

перевірка позитивних сценаріїв (Positive testing);

перевірка негативних сценаріїв (Negative testing).

8.8        Тестування в різних моделях ЖЦ

Використання діаграм UML на прикладі процесів RUP