модулі перевіряються не ізольовано один від одного, тому потрібні або тільки драйвери, або тільки заглушки.
А
B C D
E F
мал. 1
При порівнянні покрокового і монолітного тестування можна відмітити наступні переваги першого підходу:
1) менша трудомісткість (для прикладу на мал. 1 при монолітному тестуванні потрібно 5 драйверів і 5 заглушок; при покроковому тестуванні потрібні або тільки 5 драйверів - якщо модулі підключаються “знизу вгору ", - або тільки 5 заглушок - якщо модулі підключаються “зверху вниз");
2) більш раннє виявлення помилок в інтерфейсах між модулями (їх збирання починається раніше, ніж при монолітному тестуванні );
3) легше відладка, тобто локалізація помилок (вони в основному пов'язані з останнім з підключених модулів );
4) більш досконалі результати тестування (більш ретельна перевірка спільного використання модулів).
Є переваги і у монолітного тестування:
1) менше витрата машинного часу (хоч через більшу складність відладки може бути потрібна додаткова перевірка програми і ця перевага буде зведена на немає);
2) надається більше можливостей для організації паралельної роботи на початковому етапі тестування.
Загалом більш доцільним є вибір покрокового тестування. При його використанні можливі дві стратегії підключення модулів: низхідна і висхідна.
Низхідне тестування починається з головного (або верхнього) модуля програми, а вибір наступного модуля, що підключається відбувається з числа модулів, що викликаються з вже протестованих. Одна з основних проблем, виникаючих при низхідному тестуванні, - створення заглушок. Це тривіальна задача, т. к. як правило недостатньо, щоб в заглушці виконувався висновок відповідного інформаційного повідомлення і повернення завжди одних і тих же значень вихідних даних.
Інша проблема, яку необхідно вирішувати при низхідному тестуванні, - форма представлення тестів в програмі, оскільки, як правило, головний модуль отримує вхідні дані не безпосередньо, а через спеціальні модулі введення, які при тестуванні на початку замінюються заглушками. Для передачі в головний модуль різних тестів треба або мати декілька різних заглушок, або записати ці тести в файл у зовнішній пам'яті і за допомогою заглушки прочитувати їх.
Оскільки після тестування головного модуля процес перевірки може продовжуватися по-різному, потрібно дотримуватися наступних правил:
а) модулі, що містять операції введення-висновку, повинні підключатися до тестування як можна раніше;
б) критичні (тобто найбільш важливі ) для програми загалом модулі також повинні тестуватися насамперед.
12
Основні переваги низхідного тестування:
вже на ранній стадії тестування є можливість отримати працюючий варіант програми, що розробляється;
швидко можуть бути виявлені помилки, пов'язані з організацією взаємодія з користувачем.
Недоліки низхідної стратегії продемонструються з допомогою мал. 2.
Допустимо, що на наступному кроці тестування заглушка модуля Н замінюється його реальним текстом. Тоді
1) може виявитися важким або навіть неможливим побудувати такий тест на вході модуля J, якому відповідав би будь-яка задана наперед послідовность значень даних на вході модуля Н;
2) не завжди виявиться можливим легко оцінити відповідність значень даних на вході модуля J необхідним тестам для перевірки модуля Н;
3) т. я. результати виконання програми на побудованому для перевірки модуля Н тесті виводяться не їм, а модулем I, може виявитися важким відновлення дійсних результатів роботи модуля Н.
Інші проблеми, які можуть виникати при низхідному тестуванні:
з'являється знада поєднання низхідного проектування з тестуванням, що, як правило, безрозсудно, так як проектування - процес інтерактивний і в ньому неминучий повернення на верхні рівні і виправлення прийнятих раніше рішень, що знецінює результати вже проведеного тестування;
може виникнути бажання перейти до тестування модуля наступного рівня до завершення тестування попереднього по об'єктивних причинах (необхідності створення декількох версій заглушок, використання модулями верхнього рівня ресурсів модулів нижніх рівнів).
При висхідному тестуванні перевірка програми починається з термінальних модулів (тобто тих, які не викликають не яких інших модулів програми). Ця стратегія багато в чому протилежна низхідному тестуванню (зокрема, переваги стають недоліками і навпаки).
Немає проблеми вибору наступного модуля, що підключається - враховується лише те, щоб він викликав тільки вже протестовані модулі. На відміну від заглушок драйвери не повинні мати декілька версій, тому їх розробка в більшості випадків простіше (крім того, використання коштів автоматизації і відладки полегшує створення якраз драйверів, а не заглушок).
Інші достоїнства висхідного тестування:
оскільки немає проміжних модулів (модуль, що тестується є для робочого варіанту програми модулем самого верхнього рівня), немає проблем, пов'язаних з можливістю або тружністю завдання тестів;
немає можливості поєднання проектування з тестуванням;
немає труднощів, що спричиняють бажання перейти до тестування наступного модуля, не завершивши перевірки попереднього.
Основними недоліком висхідного тестування є те, що перевірка всієї структури програмного комплексу, що розробляється можлива тільки на завершальній стадії тестування.
Хоч однозначного висновку про переваги тієї або іншої стратегії пошагового тестування зробити не можна (треба враховувати конкретні характеристики програми, що тестується ), в більшості випадків більш переважним є висхідне тестування.
На третьому етапі тестування програмних комплексів (тестуванні функцій) використовуються передусім методи функціонального тестування.
ФУНКЦІОНАЛЬНЕ ТЕСТУВАННЯ
Огляд методів проектування тестів при функціоналному тестуванні почнемо з методу зквівалентного роздріблення.
Так як нашою метою є побудови безлічі тестів, що характеризується найвищою імовірністю виявлення більшості помилок в програмі, що тестується, то тест з цієї безлічі повинен:
1) зменшувати (більш ніж на одиницю) число інших тестів, які повинні бути разроблені для досягнення зазделегідь поставленої мети “задовільного" тестування;
2) покривати собою значну частину інших можливих тестів.
Іншими словами:
1) кожний тест повинен містити в собі перевірку найбільшого числа вхідних, що задаються зовнішньою специфікацією умові (обмежень на вхідні дані) для того, щоб мінімізувати загальне