Зміст лекції

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

Системне тестування виконується над проектом з допомогою методів „чорного ящика”. Структура програми не має ніякого значення, для перевірки доступні тільки входи та виходи, що доступні користувачеві. Тестуванню підлягають коди та користувацька документація.

Категорії тестів системного тестування:

• повнота рішення функціональних задач;

• стресове тестування – на граничних обсягах навантаження вхідного потоку;

• коректність використання ресурсів (проблеми пам’яті, повернення ресурсів );

• оцінка працездатності;

• ефективність захисту від викривлення даних та некоректних дій;

• перевірка інсталяції та конфігурації на різних платформах;

• коректність документації.

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

Регресійне тестування. Це цикл тестування, який виконується при внесені змін на фазі системного тестування або супроводу продукту. Головною проблемою регресійного тестування є вибір між повним та частковим пере тестуванням та поповненням тестових наборів. При частковому пере тестуванні контролюються тільки ті частини проекту, що пов’язані зі зміненими компонентами. На ГМП – це шляхи, що містять змінені вузли та, як правило, це методи та класи, що лежать вище модифікованих по рівню, але такі що містять їх в своєму контексті. Пропуск великого об’єму тестів, що характерно для етапу системного тестування, вдається здійснити без втрат якісних показників продукту тільки з допомогою регресійного підходу. Отримавши звіт про помилку, програміст аналізує початковий код, знаходить помилку та виправляє її та модульно або регресійно тестує результат. В свою чергу тестувальник, перевіряючи внесені програмістом зміни, повинен:

• перевірити та підтвердити виправлення помилки. Для цього необхідно виконати вказаний у звіті тест, з допомогою якого була знайдена помилка;

• спробувати відтворити помилку якимось іншим способом;

• протестувати наслідки виправлення. Можливо, що внесені виправлення привнесли помилку до коду, який до цього добре працював.

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

Таблиця 3.2 Характеристики модульного, інтеграційного та системного тестування.

	Модульне	Інтеграційне	Системне
Типи дефектів	Локальні дефекти, такі як опечатки в реалізації алгоритму, неправильні операції, логічні та математичні вирази, цикли, помилки в використанні локальних ресурсів, рекурсія і т.п.	Інтерфейсні дефекти, такі як неправильне трактування параметрів та їх формат, неправильне використання системних ресурсів та засобів комунікації.	Відсутня або некоректна функціональність, незручність використання, непередбачені дані та їх комбінації, непередбачені або не підтримані сценарії роботи, помилки сумісності, помилки користувацької документації помилки переносу на різні платформи, проблеми працездатності, інсталяції, інше.
Необхідність в системі тестування	Так	Так	Ні (*)
Ціна розробки системи тестування	Низька	Низька до помірної	Помірна до високої або неприйнятної
Ціна процесу тестування	Низька	Низька	Висока

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

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

Тема: Проектування об’єктно-орієнтованих тестових варіантів

Мета: ознайомити студентів з методиками проектування об’єктно-орієнтованих тестових варіантів; розглянути приклади розробки тестів.

Література:

1. Котляров В.П. „Основи тестування програмного забезпечення ” Інтернет – університет інформаційних технологій – ІНТУІТ.ру, 2006

2. Орлов С. А., „Технології розробки програмного забезпечення: Підручник для вузів ”. – Спб.: Пітер, 2004р.

Хід заняття

1. Організаційна частина

а) готовність групи до заняття;

б) психоемоційний настрій;

в) перевірка присутніх;

2. Актуалізація опорних знань студентів:

а) повідомлення теми та мети;

б) повідомлення основних тез теми.

3. Викладення нового матеріалу:

План лекції:

1. Характеристики ООП, що необхідно враховувати при тестуванні

2. Тестування, засноване на помилках

3. Тестування, засноване на сценаріях

4. Узагальнення та систематизація знань.

5. Підведення підсумків заняття.

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

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