![](/user_photo/2706_HbeT2.jpg)
- •Лекція 0. Вступ. Цілі, завдання і місце курсу
- •1. Мета викладання курсу
- •2. Завдання вивчення курсу
- •3. Дисципліни, засвоєння яких необхідне при вивченні курсу
- •4. Характеристика курсу
- •5.1. Література
- •5.2. Інформаційні ресурси мережі Інтернет
- •Лекція 1. Введення у технологію програмування
- •1. Термінологія індустрії ПЗ
- •1.1. Програмування
- •1.2. IT-проекти
- •1.3. Програми і програмне забезпечення (програмні продукти)
- •2. Бізнес і IT-проекти. Ринок ПЗ.
- •3. Про предмет
- •5. Виникнення Технології розробки ПЗ
- •5.1. Коротка історія програмування
- •5.2. Терміни “Технологія”, “Методологія” і “Програмна інженерія”
- •5.3. Стратегії розробки ПЗ
- •6. Огляд технологій програмування
- •6.1. Структурне програмування
- •6.2. Модульне програмування
- •6.4. Компонентне програмування
- •6.5. Висновки з лекції
- •Лекція 2. Елементи програмної інженерії
- •1. Програмна інженерія, основні поняття
- •1.1. Інженери і програмні інженери
- •1.2. Програмна інженерія як інженерна дисципліна
- •1.3. Область дії програмної інженерії
- •2. Цілі програмних інженерів
- •2.1. Поняття “якості” програмного продукту
- •2.2. Створення ПЗ повинно вкладатися до бюджету
- •2.3. Створення ПЗ повинно вкладатися в терміни
- •3. Забезпечення надійності розробки ПЗ
- •3.1. Забезпечення точності інтерпретації
- •3.2. Подолання бар'єру між користувачем і розробником
- •3.3. Контроль ухвалюваних рішень
- •3.4. Програмні інженери і наукове середовище
- •4. Складність програмної системи
- •4.1. Методи боротьби зі складністю
- •5. Моделі якості процесів розроблення ПЗ
- •Лекція 3. Організація технологічного процесу розробки ПЗ
- •1. Процес створення програмного забезпечення
- •1.1. Основні стадії типового процесу створення ПП
- •2. Життєвий цикл та моделі процесу розробки ПЗ
- •2.1. Каскадна модель (Waterfall model)
- •2.2. Макетування (прототипіювання)
- •2.3. Інкрементна модель
- •2.4. Модель Швидкої Розробки (RAD)
- •2.5. Спіральна модель
- •3. “Важкі” і “полегшені” процеси
- •4. ХР-процесс
- •Лекція 4. Оцінка програмного проекту по СОСОМО
- •1. Процес управління проектом
- •1.1. Початок проекту
- •1.2. Оцінювання, заходи і метрики
- •1.3. Процес оцінки
- •1.4. Аналіз ризиків
- •1.5. Планування
- •1.6. Трасування і контроль
- •2. Планування проектних завдань
- •3. Розмірно-орієнтовані метрики
- •4. Функціонально-орієнтовані метрики
- •5. Оцінка проекту на основі LOC- і FP-метрик
- •Лекція 5. Проектування програмних систем
- •1. Особливості процесу синтезу програмних систем
- •2. Особливості етапу проектування
- •3. Структуризація системи
- •4. Моделювання управління
- •5. Декомпозиція підсистем на модулі
- •6. Модульність
- •7. Інформаційна закритість
- •8. Зв'язність модуля
- •8.1. Функціональна зв'язність
- •8.2. Інформаційна зв'язність
- •8.3. Комунікативна зв'язність
- •8.4. Процедурна зв'язність
- •8.5. Часова зв'язність
- •8.7. Випадкова Зв'язність
- •8.8. Визначення зв'язності модуля
- •9. Зчеплення модулів
- •10. Складність програмної системи
- •11. Характеристики ієрархічної структури програмної системи
- •Лекція 6. ПОБУДОВА АРХІТЕКТУРИ ПП
- •1. Поняття архітектури програмного засобу.
- •2. Основні принципи проектування архітектури
- •3. Основні питання архітектора ПП
- •4. Архітектурні стилі (шаблони) ПП
- •5. Поєднання архітектурних стилів
- •6. Основні класи архітектур ПП
- •6.1. Цілісна програма
- •6.2. Архітектура ППП
- •6.3. Архітектура, заснована на шині повідомлень
- •6.4. Архітектура клієнт/сервер
- •6.6. Багатошарова архітектура
- •6.8. Компонентна архітектура
- •6.10. Сервісно-орієнтована архітектура
- •7. 4. Контроль архітектури ПП
- •Лекція 7. Розробка Програм, Модульне Програмування
- •1. Поняття модульного програмування
- •1.1. Основні характеристики програмного модуля.
- •1.2. Методи розробки структури програми.
- •1.3. Контроль структури програми.
- •2. Розроблення програмних модулів
- •2.1. Порядок розробки програмного модуля
- •2.2. Структурне програмування модуля
- •2.3. Покрокова деталізація і поняття про псевдокод.
- •Лекція 8. Тестування і відлагодження ПЗ
- •1. Основні поняття тестування і відлагодження
- •2. Основні підходи і принципи відлагодження.
- •2.1. Заповіді відлагодження.
- •2.2. Автономна відладка модулів
- •2.3. Проміжна відладка програмного засобу
- •2.4. Комплексна відладка програмного засобу.
- •3. Організація процесу тестування ПЗ
- •3.1. Тестування елементів
- •3.2. Інтегральне Тестування ПП
- •3.3. Низхідне тестування інтеграції
- •3.4. Висхідне тестування інтеграції
- •3.5. Порівняння низхідного і висхідного тестування інтеграції
- •4. Види Тестування
- •4.1. Тестування правильності
- •4.2. Системне тестування
- •4.3. Тестування відновлення
- •4.4. Тестування безпеки
- •4.5. Стресове тестування
- •4.6. Тестування продуктивності
Лекція 8. Тестування і відлагодження програмного засобу
4.Види Тестування
4.1.Тестування правильності
Після закінчення тестування інтеграції програмна система зібрана в єдиний корпус, інтерфейсні помилки виявлені і відкоректовані. Тепер починається останній крок програмного тестування — тестування правильності. Мета — підтвердити, що функції, описані в специфікації вимог до ПС, відповідають очікуванням замовника [64] [69].
Підтвердження правильності ПС виконується за допомогою тестів «чорного ящика», що демонструють відповідність вимогам. При виявленні відхилень від специфікації вимог створюється список недоліків. Як правило, відхилення і помилки, виявлені при підтвердженні правильності, вимагають зміни термінів розробки продукту.
Важливим елементом підтвердження правильності є перевірка конфігурації ПС. Конфігурацією ПС називають сукупність всіх елементів інформації, ПС, що виробляються в процесі конструювання. Мінімальна конфігурація ПС включає наступні базові елементи:
1)системну специфікація;
2)план програмного проекту;
3)специфікацію вимог до ПС; працюючий або паперовий макет;
4)попереднє керівництво користувача;
5)специфікація проектування;
6)лістинги початкових текстів програм;
7)план і методикутестування; тестові варіанти і отримані результати;
8)керівництво по роботі і інсталяції;
9)ехе-код виконуваної програми;
10)опис бази даних;
11)керівництво користувача по настройці;
12)документи супроводу, звіти про проблеми, запити супроводу, звіти про конструкторські зміни;
13)стандарти і методики конструювання ПС.
Перевірка конфігурації гарантує, що всі елементи конфігурації ПС правильно розроблені, враховані і достатньо деталізовані для підтримки етапу супроводу в життєвому циклі ПС.
Розробник не може передбачити, як замовник реально використовуватиме ПС. Для виявлення помилок, які здатний знайти тільки кінцевий користувач, використовують процес, що включає альфа- і бета-тестування.
Альфа-тестірованіє проводиться замовником в організації розробника. Розробник фіксує всі виявлені замовником помилки і проблеми використання.
Бета-тестування проводиться кінцевим користувачем в організації замовника. Розробник в цьому процесі участі не приймає. Фактично, бета-тестування — це реальне застосування ПС в середовищі, яке не управляється розробником. Замовник сам записує всі виявлені проблеми і повідомляє про них розробника. Бета-тестування проводиться протягом фіксованого терміну (близько року). За наслідками виявлених проблем розробник змінює ПС і тим самим готує продукт повністю на базі замовника.
4.2.Системне тестування
Системне тестування має на увазі вихід за рамки області дії програмного проекту і проводиться не тільки програмним розробником. Класична проблема системного тестування — вказівка причини. Вона виникає, коли розробник одного системного елементу звинувачує розробника іншого елементу в причині виникнення дефекту. Для захисту від подібного звинувачення розробник програмного елементу винен:
передбачити засоби обробки помилки, які тестують всі введення інформації від інших елементів системи;
провести тести, що моделюють невдалі дані або інші потенційні помилки інтерфейсу ПС; записати результати тестів, щоб використовувати їх як доказ невинності у разі «вказівки
причини»; взяти участь в плануванні і проектуванні системних тестів, щоб гарантувати адекватне тестування
ПС.
93
Лекція 8. Тестування і відлагодження програмного засобу Кінець кінцем системні тести повинні перевіряти, що всі системні елементи правильно об'єднані і
виконують призначені функції. Розглянемо основні типи системних тестів [13] [52].
4.3.Тестування відновлення
Багато комп'ютерних систем повинні відновлюватися після відмов і відновлювати обробку в межах заданого часу. В деяких випадках система повинна бути відмовостійкою, тобто відмови обробки не повинні бути причиною припинення роботи системи. У інших випадках системна відмова повинна бути усунений в межах заданого кванта часу, інакше замовникові завдається серйозного економічного збитку.
Тестування відновлення використовує самі різні шляхи для того, щоб змусити ПС відмовити, і перевіряє повноту виконаного відновлення. При автоматичному відновленні оцінюються правильність повторної ініціалізації, механізми копіювання контрольних крапок, відновлення даних, перезапуск. При ручному відновленні оцінюється, чи знаходиться середній час відновлення в допустимих межах.
4.4.Тестування безпеки
Комп'ютерні системи дуже часто є мішенню незаконного проникнення. Під проникненням розуміється широкий діапазон дій: спроби хакерів проникнути в систему із спортивного інтересу, помста розсерджених службовців, злом шахраями для незаконної наживи.
Тестування безпеки перевіряє фактичну реакцію захисних механізмів, вбудованих в систему, на проникнення.
В ході тестування безпеки випробувач грає роль зломщика. Йому дозволено все: спроби дізнатися пароль за допомогою зовнішніх засобів; атака системи за допомогою спеціальних утиліт, що аналізують захист;
придушення, приголомшення системи (у надії, що вона відмовиться обслуговувати клієнтів); цілеспрямоване введення помилок в надії проникнути в систему в ході відновлення; проглядання несекретних даних в надії знайти ключ для входу в систему.
Звичайно, при необмеженому часі і ресурсах хороше тестування безпеки зламає будь-яку систему. Завдання проектувальника системи — зробити ціну проникнення вищою, ніж ціна отримуваної в результаті проникнення інформації.
4.5.Стресове тестування
На попередніх кроках тестування способи «білого» і «чорного ящиків» забезпечували повну оцінку нормальних програмних функцій і якості функціонування. Стресові тести проектуються для нав'язування програмам ненормальних ситуацій. По суті, проектувальник стресового тесту питає, як сильно можна розхитати систему, перш ніж вона відмовить?
Стресове тестування проводиться при ненормальних запитах на ресурси системи (по кількості, частоті, розміру-об'єму).
Приклади:
генерується 10 переривань в секунду (при середній частоті 1,2 переривань в секунду); швидкість введення даних збільшується прямо пропорціонально їх важливості (щоб визначити
реакцію вхідних функцій); формуються варіанти, що вимагають максимуму пам'яті і інших ресурсів;
генеруються варіанти, що викликають переповнювання віртуальної пам'яті; проектуються варіанти, що викликають надмірний пошук даних на диску.
По суті, випробувач намагається зруйнувати систему. Різновид стресового тестування називається тестуванням чутливості. У деяких ситуаціях (зазвичай в математичних алгоритмах) дуже малий діапазон даних, що міститься у межах правильних даних системи, може викликати помилкову обробку або різке пониження продуктивності. Тестування чутливості виявляє комбінації даних, які можуть викликати нестабільність або неправильність обробки.
94
Лекція 8. Тестування і відлагодження програмного засобу
4.6.Тестування продуктивності
Усистемах реального часу і вбудованих системах неприпустимо ПО, яке реалізує необхідні функції, але не відповідає вимогам продуктивності.
Тестування продуктивності перевіряє швидкість роботи ПО в комп'ютерній системі. Продуктивність тестується на всіх кроках процесу тестування. Навіть на рівні елементу при проведенні тестів «білого ящика» може оцінюватися продуктивність індивідуального модуля. Проте, поки всі системні елементи не об'єднаються повністю, не може бути встановлена дійсна продуктивність системи. Іноді тестування продуктивності поєднують із стресовим тестуванням. При цьому нерідко потрібний спеціальний апаратний і програмний інструментарій. Наприклад, часто потрібне точне вимірювання використовуваного ресурсу (процесорного циклу і т. д.). Зовнішній інструментарій регулярно відстежує інтервали виконання, реєструє події (наприклад, переривання) і машинні стани. За допомогою інструментарію випробувач може виявити стани, які приводять до деградації і можливих відмов системи.
95