Практична робота № 5
Тема: Проектування об’єктно-орієнтованих тестових варіантів
Мета: розглянути застосування методик системного тестування до тестування об’єктно-орієнтованих програмних систем.
Хід роботи
1. Організаційна частина
а) готовність групи до заняття;
б) психоемоційний настрій;
в) перевірка присутніх;
2. Актуалізація опорних знань студентів:
а) повідомлення теми та мети;
б) повідомлення основних тем, по яким відбувається практична робота.
3. Закріплення вмінь та навичок студентів
Теоретичні відомості. Системне тестування якісно відрізняється від інтеграційного та модульного рівнів. Воно розглядає систему в цілому та застосовується на рівні користувацьких інтерфейсів. Основним завданням системного тестування є виявлення дефектів, що пов’язані з роботою системи в цілому, таких як неправильне використання ресурсів системи, непередбачувані комбінації даних користувацького рівня, несумісність з оточенням, непередбачені сценарії використання, відсутня або неправильна функціональність, незручність в використанні та ін.. В даному випадку побудова спеціальної тестової системи не обов’язкова, проте обсяги даних на цьому рівні такі, що зазвичай більш ефективним підходом є повна або часткова автоматизація тестування. Існує два принципово різних підходи до системного тестування. В першому для побудови тестів використовують вимоги до системи: для кожної вимоги будується тест, який її перевіряє. Тестувальник тільки перевіряє відповідність системи вимогам. В другому підході основою для побудови тестів є уявлення про способи використання продукту та про задачі, які він вирішує. На основі більш-менш формальної моделі користувача створюються випадки використання системи, по яким будуються тестові варіанти.
Вхідні дані для кожного сценарію необхідно обирати наступним чином:
ідентифікувати всі значення (вхідні дані), які можуть задавати суб’єкти для випадків використання;
визначити класи еквівалентності для кожного типу вхідних даних;
побудувати таблицю зі списком значень з різних класів еквівалентності;
побудувати тестові випадки на базі таблиці з врахуванням зовнішніх обмежень.
4. Основна частина заняття:
В практичні роботі при побудові тестових варіантів використати обидва підходи, описані в теоретичних відомостях, та діяти наступним чином:
- на основі вимог визначити випадки використання (use case);
- на основі кожного випадку використання (use case) побудувати сценарії;
- для кожного сценарію розробити тестові випадки (набори тестів).
Завдання: виконати проектування тестового випадку для модулю, специфікація якого приведена нижче.
Використаємо модуль „Прийом підшипника на склад”. Послідовно приходять 3 підшипники. Система запитує їх з вхідної комірки, приймає параметри підшипника, що надійшов, та зберігає їх до бази даних. При надходженні підшипника (статус складу - 32) система запитує термінал підшипника, формує та посилає команду Складу – „Прийняти підшипник” та отримує відповідь зі Складу про результати виконання команди.
Приклад виконання роботи
Розглянемо приклад. Дано описання випадку використання (use case) модулю „Підбір підшипників для осі”. Послідовно приходять два підшипники, надходить запит від осі. При надходженні запиту від осі система підбирає два підшипники з тих, що є на складі та видає їх в вихідну комірку.
Згідно специфікації, система постійно запитує Склад та Термінал Осі. При надходженні підшипника (статус складу - 32) система запитує термінал підшипника, формує та посилає команду Складу – „Прийняти підшипник” та отримує відповідь зі Складу про результати виконання команди. При надходженні осі (надходженні параметрів осі при опитуванні терміналу осі) система повинна підібрати підшипники з тих, що є на складі, сформувати команди для їх видачі, надіслати їх складові та отримати відповідь про результати виконання команди.
Покрокове описання тестового випадку приведене на малюнку 3.
В покроковому описанні тестового випадку не враховуються можливі альтернативні шляхи поведінки системи.
Специфікація тестового випадку № 1.
Стан оточення (вхідні дані):
Статус складу (StoreStat=32). Надійшов підшипник.
Статус обміну з терміналом підшипника (0 – підшипник є) та його параметри (RollerPar="0 NewUser Depot1 123456 1 12 1 1").
Статус обміну з терміналом осі (1 – осі немає) та її параметри (AxlePar="1 NewUser Depot1 123456 1 0 12 12").
Статус команди (CommandStatus=0). Команда успішно прийнята.
Повідомлення від складу (StoreMessage=1). Команда успішно виконана.
Очікувана послідовність подій (вихідні дані):
система запитує статус складу (виклик функції GetStoreStat) та отримує 0 NewUser Depot1 123456 1 12 1 1;
система запитує параметри підшипника (виклик функції GetRollerPar ) та отримує NewUser Depot1 123456 1 12 1 1;
система запитує параметри осі (виклик функції GetAxlePar) та отримує 1 NewUser Depot1 123456 1 0 12 12;
система додає в чергу команд складу на останнє місце команду SendR (отримати з приймальника в комірку, виклик функції SendStoreCom ) та отримує повідомлення про те, що команда успішно прийнята – 0;
система запитує склад про результати виконання команди (виклик функції GetStoreMessage) та отримує повідомлення про те, що команда успішно виконана – 1;
система запитує статус складу (виклик функції GetStoreStat) та отримує 32;
система запитує параметри підшипника (виклик функції GetRollerPar ) та отримує 0 NewUser Depot1 123456 1 12 1 1;
система запитує параметри осі (виклик функції GetAxlePar) та отримує 1 NewUser Depot1 123456 1 0 12 12;
система додає в чергу команд складу на перше місце команду GetR (отримати з приймальника до комірки, виклик функції SendStoreCom) та отримує повідомлення про те, що команда успішно прийнята – 0;
система запитує склад про результати виконання команди (виклик функції GetStoreMessage) та отримує повідомлення про те, що команда успішно виконана – 1.
Описання процесу системного тестування:
Аналіз. Система, що тестується, аналізується (перевіряється) на наявність деяких властивостей, яким необхідно приділити особливу увагу, та визначаються відповідні тестові випадки.
Побудова. Вибрані на стадії аналізу тестові випадки переводяться на мову програмування.
Виконання та аналіз результатів. Відбувається виконання тестових випадків. Отримані результати аналізуються, для того, щоб визначити, чи успішно пройшла система випробувань на тестовому наборі. Процес запуску тестових випадків та аналізу отриманих результатів повинен бути детально описаний в тестових випадках.
Підсумок: таким чином, побудова об’єктно-орієнтованих тестових варіантів є основною для розробки тестів системного тестування. Для побудови тестових варіанті необхідно використовувати специфікацію програмної системи.
5. Контрольні запитання:
1. Дайте визначення системного тестування.
2. Які обмеження накладає використання об’єктно-орієнтованого програмування?
6. Узагальнення та систематизація вмінь і навичок.
7. Підведення підсумків заняття.
8. Самостійна робота: за розглянутим прикладом самостійно виконати завдання та відповісти на контрольні запитання.