Тема 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}. Подібний дефект може бути виявлений на превелику силу, якщо розробляти тести, ґрунтуючись тільки на специфікації вимог.

 

Контрольні запитання:

1. Приведіть приклад розробки тестів за специфікацією вимог.

2. Що розуміють під тестуванням сценаріїв?

3. Як відбувається розробка тестів за допомогою сценаріїв?

 

Тема 4.3 Автоматизація тестування з допомогою скриптів

Завдання: законспектувати тему до зошита у вигляді відповідей на контрольні запитання, що містяться в кінці теми.

 

Розглянемо генерацію коду з мови MSC. Тест, описаний вище, формалізований мовою MSC (мал.. 4.2). Тут кожна стрілка з позначкою DoTransaction, DoAddressTenure або DoDataTenure представлет собою виклик відповідної функції продукту з передачею параметрів. Стрілка checkTr відповідає перевірці проходження по шині транзакції з відповідними параметрами. Кожна зі стрілок діаграми генератором тестів перетвориться в здійсненний код, при цьому стрілкам, що представляють собою виклики функцій може відповідати досить просту й маленьку ділянку коду, що викликає відповідну функцію й перевіряє її вихідне значення на наявність помилок.

Мал. 4.2 Формальний запис сценарного тесту на MSC

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

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

Мал. 4.3 Формальний запис сценарного тесту на MSC з використанням паралелізму.

 

 

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

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

 

Контрольні запитання:

1. Що представляє собою формальний запис сценарного тесту на основі MSC?
2. Які переваги надає застосування формальних записів тестів на MSC?
3. Як використовується паралелізм для генерації тестів?
4. Які переваги дає застосування паралелізму в генерації тестів мовою MSC?

 

Тема 4.4 Документування та життєвий цикл дефекту

Завдання: законспектувати тему до зошита у вигляді відповідей на контрольні запитання, що містяться в кінці теми.

 

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

— ідентифікацію елемента конфігурації й/або етапу життєвого циклу ПЗ, де був виявлений дефект;

— ідентифікацію елемента конфігурації, який необхідно модифікувати, або опис процесу, що повинен бути змінений;

— опис дефекту, достатній для його розуміння й усунення;

— опис коригувальних дій, призначених для усунення зареєстрованого дефекту.

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

Примітка. Дефекти, пов'язані із процесами життєвого циклу ПЗ, і дефекти, пов'язані із програмними засобами, можуть бути зафіксовані в окремих системах звітності про дефекти.

Вимоги до виконання даних робіт:

— повинне бути підготовлене повідомлення про дефект, що описує невідповідність процесу планам, відсутність вихідних даних або аномальне поводження ПЗ, а також про початі коригувальні дії;

— звітність про дефекти повинна передбачати ідентифікацію елементів, що зачіпають конфігурації, або визначення робіт, що зачіпають процеси, звітність про стан повідомлень про дефекти, твердження й закриття повідомлень про дефекти;

— повідомлення про дефекти, для яких потрібні коригувальні дії відносно програмного засобу або вихідних даних процесів життєвого циклу ПЗ, повинні активізувати роботи з контролю змін.

Примітка. Звітність про дефекти й роботи з контролю змін є взаємозалежними.

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

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

— вхідна інформація системи повинна складатися з повідомлень про дефекти/зміни;

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

— кожний дефект повинен бути класифікований по категоріям і пріоритетам;

— повинен бути виконаний аналіз для виявлення можливих тенденцій у зареєстрованих дефектах;

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

Контрольні запитання:

1. Які дані повинні містити в собі повідомлення про дефекти?
2. Що є метою створення звітності про дефекти?
3. Які вимоги застосовуються до робіт на етапі корегування та трасування дефектів?
4. Яким вимогам має відповідати система після виконання корегувальних дій?