Тестування модулів і комплексне тестування

 

-1-

При автономному налагодженні ПЗ кожен модуль насправді тестується в деякому програмному оточенні, крім випадку, коли програма складається тільки з одного модуля. Це оточення складається з інших модулів, частина яких є модулями тестуючої програми, що вже налагоджені, а частина - модулями, що керують налагодженням (віладочними модулями). У процесі автономного налагодження ПЗ виконується нарощування програми, яка тестується, налагодженими модулями: при переході до налагодження наступного модуля в його програмне оточення додається останній налагоджений модуль. Такий процес нарощування програмного оточення налагодженими модулями називається інтеграцією програми [10.1].

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

При спадному тестуванні оточення модуля, який тестується в якості відладочних модулів містять відладочні імітатори (заглушки) деяких ще не налагоджених модулів. До таких модулів відносяться, насамперед, усі модулі, до яких може звертатися модуль, від лагодження якого проводиться, а також ще не налагоджені модулі, до яких можуть звертатися вже налагоджені модулі (включені в це оточення). Деякі з цих імітаторів при налагодженні одного модуля можуть змінюватися для різних тестів.

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

До переваг висхідного тестування відносяться:

·  простота підготовки тестів,

·  можливість повної реалізації плану тестування модуля.

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

Недоліками висхідного тестування є наступні його особливості:

·  тестові дані готуються, як правило, не в тій формі, що розрахована на користувача (крім випадку, коли налагоджується останній, головний, модуль програм);

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

·  необхідність спеціального тестування сполучення модулів.

До переваг спадного тестування відносяться наступні його особливості:

· більшість тестів готується у формі, розрахованої на користувача;

· у багатьох випадках щодо невеликий обсяг відладочного програмування (імітатори модулів, як правило, дуже прості і кожний придатний для великого числа, нерідко - для усіх, тестів);

· відпадає необхідність тестування сполучення модулів.

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

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

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

Автономне тестування модуля доцільно здійснювати в чотири послідовно виконуваних кроки.

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

Крок 2. Перевірте текст модуля, щоб переконатися, що кожен напрямок будь-якого розгалуження буде пройдений хоча б на одному тесті. Додайте відсутні тести.

Крок 3. Перевірте текст модуля, щоб переконатися, що для кожного циклу існують тести, що забезпечують, принаймні, три наступні ситуації: тіло циклу не виконується жодного разу, тіло циклу виконується один раз і тіло циклу виконується максимальне число раз. Додайте відсутні тести.

Крок 4. Перевірте текст модуля, щоб переконатися, що існують тести, що перевіряють чутливість до окремих особливих значень вхідних даних. Додайте відсутні тести.

Комбінований підхід. Найчастіше застосовують комбінований підхід: модулі верхніх рівнів тестують низхідним способом, а модулі нижніх рівнів - висхідним.

Цей спосіб дозволяє з одного боку почати з тестування інтерфейсу, з іншої -

забезпечує якісне автономне тестування модулів нижчих рівнів.

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

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

 

 

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

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

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

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

Тестування документації по застосуванню ПЗ. Метою тестування є пошук непогодженості документації по застосуванню із сукупністю програм ПЗ, а також виявлення незручностей, що виникають при застосуванні ПЗ. Цей етап безпосередньо передує підключенню користувача до завершення розробки ПЗ (тестуванню визначення вимог до ПЗ і атестації ПЗ), тому дуже важливо розроблювачам спочатку самим скористатися ПЗ так, як це буде робити користувач. Усі тести на цьому етапі готуються винятково на підставі тільки документації по застосуванню ПЗ. Насамперед, повинні тестуватися можливості ПЗ як це робилося при тестуванні зовнішніх функцій, але тільки на підставі документації по застосуванню. Повинні бути протестовані всі неясні місця в документації, а також усі приклади, використані в документації. Далі тестуються найбільш важкі випадки застосування ПЗ із метою знайти порушення вимог відносності легкості застосування ПЗ.

Тестування визначення вимог до ПЗ. Метою тестування є з'ясування, якою мірою ПЗ не відповідає пред'явленому визначенню вимог до нього. Особливість цього виду тестування полягає в тім, що його здійснює покупець чи організація-користувач ПЗ. Звичайно це тестування виробляється за допомогою контрольних - типових задач, для яких відомий результат рішення. У тих випадках, коли розроблювальне ПЗ повинно прийти на зміну іншої версії ПЗ, що вирішує хоча б частину задач розроблювального ПЗ, тестування виробляється шляхом рішення загальних задач за допомогою як старого, так і нового ПЗ (з наступним зіставленням отриманих результатів).