Лекція 3.
Тема: Критерії вибору тестів
Мета: ознайомити студентів з поняттям ідеального критерію та шляхами наближення до нього в реальних ситуаціях. Розглянути відомі на сьогодні методи формування критеріїв тестових наборів з перевагами та недоліками. Навести відповідні приклади.
Яку аналогію можна провести між формулою та програмним кодом?
В чому полягає сенс формального обґрунтування істинності формул?
До чого зводиться даний метод в найпростішому випадку?
Чи має метод значиму перевагу?
В чому полягає інтерпретаційний підхід?
В чому незручність використання методу?
Що таке налагодження ПЗ?
Що таке процес трансляції програми?
Дайте визначення статичного тестування.
Дайте визначення динамічного тестування.
Хто такий або що таке оракул?
Які методи протоколювання проміжних обчислень ви можете назвати?
Що таке Контрольна точка?
Що таке режим «останову»?
Дайте визначення траси.
Дайте визначення дампу.
Перерахуйте та коротко охарактеризуйте фази тестування.
В чому полягає основна проблема тестування?
Дайте визначення Керуючого графу програми.
Дайте визначення Шляху.
Дайте визначення Гілки – шляху.
ПЛАН
1 Вимоги до ідеального критерію тестування
2 Структурні критерії (клас I).
3 Функціональні критерії (клас II)
4 Стохастичні критерії (клас III)
5 Мутаційний критерій (клас IV).
Вимоги до ідеального критерію можна сформулювати наступним чином:
Критерій повинен бути достатнім, тобто показувати, коли деяка кінцева безліч тестів достатня для тестування даної програми.
Критерій повинен бути повним, тобто у випадку помилки повинен існувати тест із безлічі тестів, що задовольняють критерію, що розкриває помилку.
Критерій повинен бути надійним, тобто будь-які дві безлічі тестів, що задовольняють йому, одночасно повинні розкривати або не розкривати помилки програми.
Критерій повинен легко перевірятися.
Для нетривіальних класів програм у загальному випадку не існує повного й надійного критерію, що залежить від програм або специфікацій.
Тому ми прагнемо до ідеального загального критерію через реальні складові.
Класи критеріїв
Структурні критерії використають інформацію про структуру програми (критерії так званого "білого ящика")
Функціональні критерії формулюються в описі вимог до програмного виробу ( критерії так називаного "чорного ящика" )
Критерії стохастичного тестування формулюються в термінах перевірки наявності заданих властивостей у теститованого додатка, засобами перевірки деякої статистичної гіпотези.
Мутаційні критерії орієнтовані на перевірку властивостей програмного виробу на основі підходу Монте-Карло.
Структурні критерії використовують модель програми у вигляді "білого ящика", що припускає знання вихідного тексту програми або специфікації програми у вигляді потокового графа керування. Структурна інформація зрозуміла й доступна розроблювачам підсистем і модулів додатка, тому даний клас критеріїв часто використається на етапах модульного й інтеграційного тестування (Unit testing, Integration testing).
Структурні критерії базуються на основних елементах КГП, операторах, гілках і шляхах.
Умова критерію тестування команд (критерій С0) - набір тестів у сукупності повинен забезпечити проходження кожної команди не менш одного разу. Це слабкий критерій, він, як правило, використається в великих програмних системах, де інші критерії застосувати неможливо.
Умова критерію тестування гілок (критерій С1) - набір тестів у сукупності повинен забезпечити проходження кожної гілки не менш одного разу. Це досить сильний і при цьому економічний критерій, оскільки безліч гілок у тестованому додатку зазвичай не така вже і велика. Даний критерій часто використається в системах автоматизації тестування.
Умова критерію тестування шляхів (критерій С2) - набір тестів у сукупності повинен забезпечити проходження кожного шляху не менш 1 разу. Якщо програма містить цикл (особливо з неявно заданим числом ітерацій), то число ітерацій обмежується константою (часто - 2, або числом класів вихідних шляхів).
В прикладі 3.1 наведений зразок простої програми. Розглянемо умови її тестування у відповідно
void Method (int x)
{
if (x>17)
x = 17-x;
if (x==-13)
x = 0;
}
3.1. Приклад простої програми, для тестування за структурними критеріями
Тестовий набір з одного тесту, задовольняє критерію команд (C0):
(X, Y)={(xвх=30, xвих=0)} покривають всі оператори траси 1-2-3-4-5-6
Тестовий набір із двох тестів, задовольняє критерію гілок (C1):
(X, Y)={(30,0), (17, 17)} додає 1 тест до безлічі тестів для С0 і трасу 1-2-4-6. Траса 1-2-3-4-5-6 проходить через всі гілки досяжні в операторах if за умови true, а траса 1-2-4-6 через всі галузі, досяжні в операторах if за умови false.
Тестовий набір із чотирьох тестів, задовольняє критерію шляхів (C2):
(X,Y)={(30,0), (17,17), (-13,0), (21,-4)}
Набір умов для двох операторів if c мітками 2 й 4 наведений у таблиця 3.1
|
Таблиця 3.1 Умови операторів if |
||||
|
|
(30,0) |
(17,17) |
(-13,0) |
(21,-4) |
|
2 if (x>17) |
> |
≤ |
> |
|
|
4 if (x==-13) |
≠ |
≠ |
= |
≠ |
Критерій шляхів С2 перевіряє програму більш ретельно, ніж критерії - C1, однак навіть якщо він задовільний, немає підстав затверджувати, що програма реалізована у відповідності зі специфікацією.
Структурні критерії не перевіряють відповідність специфікації, якщо вона не відбита в структурі програми. Тому при успішному тестуванні програми за критерієм C2 ми можемо не помітити помилку, пов'язану з невиконанням деяких умов специфікації вимог.
Функціональний критерій - найважливіший для програмної індустрії критерій тестування. Він забезпечує контроль ступеня виконання вимог замовника в програмному продукті. Оскільки вимоги формулюються до продукту в цілому, вони відбивають взаємодію тестованого додатка з оточенням. При функціональному тестуванні переважно використається модель "чорного ящика". Проблема функціонального тестування - це, насамперед, трудомісткість; справа в тому, що документи, що фіксують вимоги до програмного виробу (Software requirement specification, Functional specification і т.п.), як правило, досить об'ємні, але тим не менш, перевірка повинна бути всеосяжною.
Нижче наведені часткові види функціональних критеріїв.
Тестування пунктів специфікації - набір тестів у сукупності повинен забезпечити перевірку кожного тестованого пункту не менш одного разу.
Специфікація вимог може містити сотні й тисячі пунктів вимог до програмного продукту й кожна із цих вимог при тестуванні повинна бути перевірена відповідно до критерію не менш чим одним тестом
Тестування класів вхідних даних - набір тестів у сукупності повинен забезпечити перевірку представника кожного класу вхідних даних не менш одного разу.
При створенні тестів класи вхідних даних зіставляються з режимами використання тестованого компоненту або підсистеми додатка, що помітно скорочує варіанти перебору, що враховують при розробці тестових наборів. Варто помітити, що перебираючи відповідно до критерію величини вхідних змінних (наприклад, різні файли - джерела вхідних даних), ми змушені застосовувати потужні тестові набори. Дійсно, поряд з обмеженнями на величини вхідних даних, існують обмеження на величини вхідних даних у всіляких комбінаціях, у тому числі перевірка реакцій системи на появу помилок у значеннях або структурах вхідних даних. Облік цього різноманіття - процес трудомісткий, що створює складності для застосування критерію.
Тестування правил - набір тестів у сукупності повинен забезпечити перевірку кожного правила, якщо вхідні й вихідні значення описуються набором правил деякої граматики.
Варто помітити, що граматика повинна бути досить простою, щоб трудомісткість розробки відповідного набору тестів була реальною (уписувалася в термін й штат фахівців, виділених для реалізації фази тестування)
Тестування класів вихідних даних - набір тестів у сукупності повинен забезпечити перевірку представника кожного вихідного класу, за умови, що вихідні результати заздалегідь не класифіковані, причому окремі класи результатів ураховують, у тому числі, обмеження на ресурси або на час (time out).
При створенні тестів класи вихідних даних зіставляються з режимами використання тестованого компоненту або підсистеми, що помітно скорочує варіанти перебору, що враховують при розробці тестових наборів.
Тестування функцій - набір тестів у сукупності повинен забезпечити перевірку кожної дії, реалізованої тестованим модулем, не менш одного разу.
Дуже популярний на практиці критерій, що, однак, не забезпечує покриття частини функціональності тестованого компонента, зв'язаної зі структурними й поведінковими властивостями, опис яких не зосереджено в окремих функціях (тобто опис зосереджений по компоненті).
Критерій тестування функцій поєднує часткові особливості структурних і функціональних критеріїв. Він базується на моделі "напівпрозорого ящика", де явно зазначені не тільки входи й виходи тестованого компонента, але також склад і структура використовуваних методів (функцій, процедур) і класів.
Комбіновані критерії для програм і специфікацій - набір тестів у сукупності повинен забезпечити перевірку всіх комбінацій несуперечливих умов програм і специфікацій не менш одного разу.
При цьому всі комбінації несуперечливих умов треба підтвердити, а умови протиріч варто виявити й ліквідувати.
Приклад застосування функціональних критеріїв тестування для розробки набору тестів за критерієм класів вхідних даних
Нехай для рішення завдання тестування системи "Система керування автоматизованим комплексом зберігання підшипників" (див. Додаток 1, FS) був розроблений наступний фрагмент специфікації вимог:
Зробити опитування статусу складу (викликати функцію GetStoreStat ). Додати в журнал повідомлень запис "СИСТЕМА : Запитана статус СКЛАДУ". Залежно від отриманого значення зробити наступні дії:
Отриманий статус складу = 32. У прийомний осередок складу надійшов підшипник. Система повинна:
Додати в журнал повідомлень запис "СКЛАД : Статус СКЛАДУ = 32".
Одержати параметри підшипника, що надійшов, з термінала підшипника (повинна бути викликана функція GetRollerPar ).
Додати в журнал повідомлень запис "СИСТЕМА: Запитані параметри підшипника".
Залежно від повернутої функцією GetRollerPar значення повинні бути виконані наступні дії ( таблиця 3.2):
|
Таблиця 3.2. Дії за результатами функції GetRollerPar |
|
|
Значення, повернутої функцією GetRollerPar |
Дії системи |
|
... |
... |
|
0 |
|
|
1 |
Додати в журнал повідомлень запис "ТЕРМИНАЛ ПОДШИПНИКА: 1 - немає даних " |
|
... |
... |
Зробити опитування термінала осі (викликати функцію одержання повідомлення від термінала - GetAxlePar ). У журнал повідомлень повинне бути додане повідомлення "СИСТЕМА : Запитані параметри осі". Залежно від повернутої функцією GetAxlePar значення повинні бути виконані наступні дії ( таблиця 3.3):
|
Таблиця 3.3. Дії за результатами функції GetAxlePar |
|
|
Значення, повернутої функцією GetAxlePar |
Дії системи |
|
... |
... |
|
1 |
Додати в журнал повідомлень запис "ТЕРМИНАЛ ОСИ: 1 - немає даних " |
|
... |
... |
Визначимо класи вхідних даних для параметра - статус складу:
Статус складу = 0 (правильний).
Статус складу = 4 (правильний).
Статус складу = 16 (правильний).
Статус складу = 32 (правильний).
Статус складу = будь-яке інше значення (помилковий).
Тепер розглянемо тестові випадки:
Тестовий випадок 1 (покриває клас 4):
Стан оточення (вхідні дані - X ):
Статус складу - 32.
...
Очікувана послідовність подій (вихідні дані - Y ):
Система запитує статус складу (виклик функції GetStoreStat ) і одержує 32
...
Тестовий випадок 2 (покриває клас 5):
Стан оточення (вхідні дані - X ):
Статус складу - 12dfga.
...
Очікувана послідовність подій (вихідні дані - Y ):
Система запитує статус складу (виклик функції GetStoreStat ) і відповідно до пункту специфікації при помилковому значенні статусу складу в журнал додається повідомлення "СКЛАД : ПОМИЛКА : Невизначений статус".
...