- •Пояснювальна записка
- •Розділ 1 структурне тестування програмного забезпечення
- •Тема 1.1 Класифікація принципів тестування програмного забезпечення
- •1. Структурні критерії (клас і)
- •2. Функціональні критерії (клас II)
- •3. Стохастичні критерії (клас III)
- •4. Мутаційний критерій (клас IV)
- •Тема 1.2 Переваги та недоліки принципів тестування
- •Тема 1.3 Кроки способу тестування базового шляху
- •Тема 1.4 Спосіб тестування потоків даних
- •Тема 1.5 Тестування вкладених циклів
- •Розділ 2 функціональне тестування програмного забезпечення
- •Тема 2.1 Спосіб тестування діаграм причин-наслідків
- •Тема 2.2 Тестування елементів
- •Тема 2.3 Переваги та недоліки низхідного та висхідного тестування
- •Тема 2.4 Стресове тестування та тестування виробності
- •Тема 2.5 Переваги та недоліки різних методів відлагодження
- •Тема 3.1 Особливості інтеграційного тестування для об’єктно-орієнтованого програмування
- •Тема 3.2 Переваги та недоліки системного та регресійного тестування
- •Тема 3.3 Тестування поверхневої та поглибленої структури системи
- •Тема 3.4 Тестування взаємодії класів
- •Тема 3.5 Переваги та недоліки ручного та автоматизованого тестування
- •Розділ 4 особливості індустріального тестування
- •Тема 4.1 Оцінка якості тестування
- •Тема 4.2 Використання специфікацій вимог до розробки тестів
- •Тема 4.3 Автоматизація тестування з допомогою скриптів
- •Тема 4.4 Документування та життєвий цикл дефекту
- •Розділ 5 принципи розробки програм для тестування
- •Тема 5.1 Особливості моделей апаратного забезпечення
- •Тема 5.2 Тестування Verilog-моделей
- •Тема 5.3 Тестування на етапі супроводу
- •Тема 5.4 Встановлення, наладка та використання пакету Everest
- •Тема 5.5 Документування результатів роботи тестового пакету
Тема 4.2 Використання специфікацій вимог до розробки тестів
Завдання: законспектувати тему до зошита у вигляді відповідей на контрольні запитання, що містяться в кінці теми.
При розробці тестів, заснованих на функціональній специфікації продукту, вимоги до продукту є основним джерелом, що визначає, які тести будуть розроблені. Для кожної вимоги пишеться один або більше тестів, які в сукупності повинні перевірити виконання даної вимоги в продукті.
Приклад використання специфікації вимог для розробки тестів.
Нехай заданий наступний фрагмент набору вимог для моделі обміну транзакціями:
Функція DoTransaction повинна приймати адресу й дані, відповідно до параметрів, створювати в черзі новий елемент, заповнювати його адресну частину й частину полів даних переданою інформацією й ініціювати транзакцію
Функція DoAddressTenure повинна приймати адресу відповідно до параметрів, створювати в черзі новий елемент і заповнювати його адресну частину
Функція DoDataTenure повинна приймати дані відповідно до параметрів, знаходити в черзі перший елемент із частково незаповненими полями даних, доповнювати його переданою інформацією й ініціювати транзакцію
Концептуальне описання набору тестів, що перевіряє специфікацію, може виглядати в такий спосіб:
Викликати DoTransaction з адресою й даними. Перевірити появу в черзі ще одного елемента. Перевірити поява на шині транзакції із правильними адресою й даними.
Викликати DoAddressTenure з адресою. Перевірити появу в черзі ще одного елемента. Перевірити відсутність нової транзакції на шині.
Викликати DoDataTenure з даними. Перевірити заповнення полів даних. Перевірити поява на шині транзакції із правильними адресою й даними
Тестування сценаріїв
Розробка тестів, заснованих на використанні сценаріїв, здійснюється за наступною методикою:
Визначається модель використання, що включає операційне оточення продукту й "акторів". Актором може бути користувач, інший продукт, апаратна частина тощо, тобто всі, із чим продукт обмінюється інформацією. Поділ на оточення й акторів умовне й служить для опису оптимальних способів використання продукту.
Розробляються сценарії використання продукту. Описання сценарію залежно від продукту й обраного підходу може бути строго певним, параметризованным або дозволяти деякий ступінь невизначеності. Наприклад, опис сценарію мовою MSC допускає завдання параметризованих сценаріїв з можливістю перевпорядкування подій.
Розробляється набір тестів, що покривають задані сценарії. З врахуванням ступеня невизначеності, закладеної в сценарії, кожний тест може покривати один сценарій, кілька сценаріїв, або, навпаки, частина сценарію.
Використання сценаріїв не вимагає наявності повної формальної специфікації вимог, але зате може зажадати більше часу на розробку й аналіз.
Ще одна особливість тестування сценаріїв полягає в тому, що цей метод направляє тестування на перевірку конкретних режимів використання продукту, що дозволяє знаходити дефекти, які метод тестування по вимогах може пропустити.
Приклад використання специфікації вимог для розробки тестів.
Так, для розглянутого вище прикладу можливе створення наступного сценарію й тестів.
Сценарій: користувач має дві незалежні нитки керування, одна з яких відповідає за генерацію повних транзакцій за допомогою DoTransaction, а інша - за збір транзакцій з адресної частини й частини даних, коли ця інформація приходить із різних джерел. Таким чином, друга нитка використає виклики до DoAddressTenure і DoDataTenure.
Опис тестів: Викликати DoAddressTenure c адресою А1, викликати DoTransaction з адресою А2 і даними D2, викликати DoDataTenure з даними D1. Перевірити послідовну появу на шині двох транзакцій: {А1, D1} і {А2, D2}
При виконанні цього тесту було, зокрема, виявлено, що функція DoTransaction була реалізована через виклики до DoAddressTenure і DoDataTenure, що приводило до появи на шині транзакцій виду {А1, D2} і {А2, D1}. Подібний дефект може бути виявлений на превелику силу, якщо розробляти тести, ґрунтуючись тільки на специфікації вимог.
Контрольні запитання:
Приведіть приклад розробки тестів за специфікацією вимог.
Що розуміють під тестуванням сценаріїв?
Як відбувається розробка тестів за допомогою сценаріїв?
