Комплексне тестування. Проектування комплексного тіста. Виконання комплексного тіста.
Комплексне тестування
Комплексне тестування, ймовірно, найнезрозуміліша форма тестування. В усякому разі комплексне тестування не є тестуванням усіх функцій повністю зібраної системи; тестування такого типу називається тестуванням зовнішніх функцій. Комплексне тестування - процес пошуків невідповідності системи її початковим цілям. Елементами, що беруть участь в комплексному тестуванні, служать сама система, опис цілей продукту і уся документація, яка поставлятиметься разом з системою. Зовнішні специфікації, які були ключовим елементом тестування зовнішніх функцій, грають лише незначну роль в комплексному тестуванні.
Частина аргументів на користь цього має бути вже очевидною: вимірні цілі потрібні, щоб визначити правила для процесів проектування. Інші міркування повинні прояснитися зараз. Якщо цілі сформульовані, наприклад, у вигляді вимоги, щоб система була досить швидкою, цілком надійною і щоб в розумних межах забезпечувалася безпека, тоді немає способу визначити при тестуванні, в якій мірі система досягає своїх цілей.
Якщо ви не сформулювали мети вашого продукту або якщо ці цілі неизмеримы, ви не можете виконати комплексне тестування.
Комплексне тестування може бути процесом і контролю, і випробувань. Процесом випробувань воно є тоді, коли виконується в реальному середовищі користувача або в обстановці, яка спеціально створена так, щоб нагадувати середовище користувача. Проте така розкіш часто недоступна з ряду причин, і в подібних випадках комплексне тестування системи є процесом контролю (тобто виконується в імітованій, або тестовою, середовищу). Наприклад, у разі бортової обчислювальної системи космічного корабля або системи протиракетного захисту питання про реальне середовище (запуск справжнього космічного корабля або постріл справжньою ракетою) зазвичай не стоїть. Крім того, як ми побачимо далі, деякі типи комплексних тестів не осуществимы в реальній обстановці з економічних міркувань, і краще всього виконувати їх в модельованому середовищі.
Проектування комплексного теаа
Комплексне тестування - найбільш творчий з усіх видів тестування, що обговорювалися досі. Розробка хороших комплексних тестів вимагає часто навіть більше винахідливості, чим само проектування системи. Тут немає простих рекомендацій типу тестування усіх гілок або побудови функціональних діаграм. Проте наступні 15 пунктів дають деяке уявлення про те, які види тестів можуть знадобитися (мал. 5.3).
Тестування стресів. Поширений недолік великих систем полягає в тому, що вони функціонують нібито нормально при слабкому або помірному навантаженні, але виходять з ладу при великому навантаженні і в стресових ситуаціях реального середовища. Тестування стресів є спробами піддати систему крайньому "тиску", наприклад, спробу одночасно підключити до системи розподілу часу 100 терміналів, наситити банківську систему потужним потоком вхідних повідомлень або систему управління - процесами аварійних сигналів від усіх її процесів.
Одна з причин, по якій тестування стресів опускають (окрім очевидних логічних проблем, що розглядаються в наступному розділі), полягає в тому, що персонал, що займається тестуванням, хоча і визнає потенційну користь таких тестів, вважає, що такі жорсткі стресові ситуації ніколи не виникнуть в реальному середовищі. Це припущення рідко виправдовується. Наприклад, бувають випадки, коли усі користувачі системи розподілу часу намагаються підключитися в один і той же час (наприклад, коли сталася відмова системи на 1-2 хвилини і система тільки що відновлена). У банківських систем, обслуговуючих термінали покупців, бувають пікові навантаження в перші години роботи магазинів і під час обідньої перерви.
• Тестування об'єму. Тоді як при тестуванні стресів робиться спроба піддати систему серйозним навантаженням в короткий інтервал часу, тестування об'єму є спробою пред'явити системі великі об'єми даних протягом тривалішого часу. На вхід компілятора слід подати до безглуздості величезну програму. Програма обробки текстів - величезний документ. Чергу зада-, ний операційної системи слід заповнити до межі. Мета тестування об'єму - показати, що система або програма не може обробляти дані в кількостях, вказаних в їх специфікаціях.
• Тестування конфігурації. Багато систем, наприклад операційні системи або системи управління файлами, забезпечують роботу різних конфігурацій апаратури і програмного забезпечення. Число таких конфігурацій часто занадто велике, щоб можна було перевірити усі варіанти. Проте слід тестувати принаймні максимальну і мінімальну конфігурації. Система має бути перевірена зі всяким апаратним пристроєм, який вона обслуговує, або зі всякою програмою, з якою вона повинна взаємодіяти. Якщо сама програмна система допускає декілька конфігурацій (тобто покупець може вибрати тільки певні частини або варіанти системи), має бути тестована кожна з них.
• Тестування сумісності. Системи, що в більшості своїй розробляються, не є абсолютно новими; вони є поліпшенням колишніх версій або заміною застарілих систем. У таких випадках на систему, ймовірно, накладається додаткова вимога сумісності, відповідно до якої взаємодія користувача з колишньою версією повинна повністю зберегтися і в новій системі. Наприклад, можливо, буде потрібно, щоб в новому випуску операційної системи мова управління завданнями, мова спілкування з терміналом і скомпільовані прикладні програми, що використалися раніше, могли застосовуватися без змін. Такі вимоги сумісності слід тестувати. Як періодично підкреслювалося при розмові про усі інші форми тестування, мета при тестуванні сумісності повинна полягати в тому, щоб показати наявність несумісності.
• Тестування захисту. Оскільки увага до питань збереження секретності в суспільстві зростає, до більшості систем пред'являються певні вимоги по забезпеченню захисту від несанкціонованого доступу. Наприклад, операційна система повинна усунути всяку можливість для програми користувача побачити дані або програму іншого користувача. Адміністративна інформаційна система не повинна дозволяти підлеглому отримати відомості про зарплату тих, хто стоїть вище за нього по службових сходах. Мета тестування захисту - порушити секретність в системі. Один з методів - найняти професійну групу "зломщиків", т. е. людей з досвідом руйнування засобів забезпечення захисту в системах. Для тестування захисту важливо побудувати такі тести, які
порушать програмні засоби захисту, наприклад, механізм захисту пам'яті операційної системи або механізми захисту даних системи управління базою даних. Одним з шляхів розробки подібних тестів є вивчення відомих проблем захисту в цих системах і генерація тестів, які дозволяють перевірити, як вирішуються аналогічні проблеми в тестованій системі.
• Тестування вимог до пам'яті. При проектуванні багатьох систем ставляться цілі, що визначають об'єм основної і вторинної пам'яті, яку системі дозволено використовувати в різних умовах. За допомогою спеціальних тестів треба спробувати показати, що система цих цілей не досягає.
• Тестування продуктивності. При розробці багатьох програм ставиться завдання - забезпечити їх продуктивність, або ефективність. Визначаються такі характеристики, як час відгуку і рівень пропускної спроможності при певному навантаженні і конфігурації устаткування. Перевірка системи в цих випадках зводиться до демонстрації того, що ця програма не задовольняє поставленим цілям. Тому необхідно розробити тести, за допомогою яких можна спробувати показати, що система не має необхідної продуктивності.
• Тестування налаштування. На жаль, процедури налаштування багатьох систем складні. Тестування процесу налаштування системи дуже важливе, оскільки одна з ситуацій, що найбільш бентежать, з якими стикається покупець, полягає в тому, що він виявляється не в змозі навіть настроїти нову систему.
Тестування надійності/готовності. Звичайно, призначення усіх видів тестування - підвищити надійність тестованої програми, але якщо в початковому документі, що відбиває цілі програми, є особливі вказівки, що стосуються надійності, можна розробити спеціальні тести для її перевірки. Ключовий момент в комплексному тестуванні полягає в спробі довести, що система не задовольняє початковим вимогам до надійності (середній час між відмовами, кількість помилок, здатність до виявлення, виправленню помилок і/або стійкість до помилок і т. д.). Тестування надійності украй складно, та все ж слід постаратися тестувати якомога більше цих вимог. Наприклад, в систему можна навмисно внести помилки (як апаратні, так і програмні), щоб тестувати засоби виявлення, виправлення і забезпечення стійкості. Інші вимоги до надійності тестувати майже неможливо.
Література
133.Зелковиц М., Шоу А., Гэннон Дж. Принципы разработки программного обеспечения: Пер. с англ.— М.: Мир, 1982 — 368 с., ил.
134.Іващук В.В. Курс лекцій «Засоби мультимедіа в нових інформаційних технологіях» Національний університет харчових технологій.-К.: НУХТ, 2011. – 77 с.
135.Когутяк М.І., Дранчук М.М., Когуч Я.Р., Шавранський М.В., Лещій Р.М. Автоматизація неперервних технологічних процесів в нафтовій та газовій промисловості: Навчальний посібник.–Івано-Франківськ: Факел, 2006.–385с.
136.Конспект лекцій з дисципліни “Системи технологій” : к. т. н., доц. Фесенко М.С. Алчевськ ДонДТУ 2006, 70 стр.
137.Кухнюк Н.В., викладач Технічного коледжу. Інтерактивний комплекс. з дисципліни “Автоматизація технологічних процесів”. 2008, 227 ст.
138.Ларман Крэг. Применение UML и шаблонов проектирования. 2-е издание.: Пер. с англ. – М. Вильямс, 2004-624 с.:ил.
139.Проць, О.А. Данилюк, Т.Б. Лобур. Автоматизація неперервних технологічних процесів. Навчальний посібник для технічних спеціальностей вищих навчальних закладів. – Тернопіль: ТДТУ ім. І.Пулюя, 2008. – 239 с.
140.С.В.Шаповал, Н.Г.Морковська. Конспект лекцій з курсу „Системи технологій” Харків. ХНАМГ, 2005.- 70 с.
141.Microsoft Corporation Принципы проектирования и разработки программного обеспечения. Учебный курс MCSD/Пер. с англ. -2-е издание. Русская Редакция, 2002 – 736 стр., ил.
142.Гагарина Л. Г., Кокорева Е. В., Виснадул Б. Д. Технология разработки программного обеспечения: учебное пособие / под ред. Л. Г Гагариной. — М.: ИД «ФОРУМ»: ИНФРА-М, 2008. — 400 с.: ил. — (Высшее образование).
143.Галіцин В.К., Сидоренко Ю.Т., Потапенко С.Д. Технологія програмування і створення програмних продуктів: Навч. посіб. — К.: КНЕУ, 2009. — 372 с.
144.Гужва В. М. Інформаційні системи і технології на підприємствах: Навч. посібник. — К.: КНЕУ, 2001. — 400 c.