- •Інженерні основи програмного забезпечення
- •Поняття програмна інженерія. Що вивчає дисципліна «Програмна інженерія»?
- •Поняття системотехніка, бізнес-реінжиніринг.
- •Історія виникнення програмної інженерії.
- •Еволюційна модель розробки програмного забезпечення. Переваги та недоліки.
- •Формальна модель розробки програмного забезпечення. Переваги та недоліки.
- •Модель розробки програмного забезпечення на основі раніше створених компонентів. Переваги та недоліки.
- •Ітераційні моделі розробки програмного забезпечення. Переваги та недоліки.
- •Модель покрокової розробки програмного забезпечення. Переваги та недоліки.
- •Инструменты тестирования:
- •Мови моделювання програмного забезпечення.
- •Методи структурного аналізу.
- •Інформаційне моделювання Мартіна.
- •Структура та архітектура програмного забезпечення
- •Архітектура програмного забезпечення. Проектування архітектури.
- •Архітектурна модель клієнт-сервер.
- •Архітектурна модель абстрактної машини.
- •Архітектурні моделі управління (виклик-повернення та централізоване).
- •Проблемно-залежні архітектури програмного забезпечення.
- •Архітектура розподілених систем.
- •Багатопроцесорна архітектура програмного забезпечення.
- •Архітектура corba.
- •Моделі об’єктно-орієнтованого проектування програмного забезпечення.
- •Проектування систем реального часу.
- •Проектування з повторним використанням компонентів.
- •Проектування інтерфейсу програмного забезпечення.
- •Документування програмних продуктів.
- •Поняття документація на програмне забезпечення, програмний документ. Типи документації.
- •Організації що публікують стандарти.
- •Типовий набір документації проекту.
- •Основні стандарти розробки програмних систем і програмного забезпечення.
- •Стандарти вимог, архітектури, якості і тестування програмного забезпечення.
- •Стандарти серії гост 34.Ххх та гост 19.Ххх.
- •Процеси за стандартом iso/іec 12207.
- •Процеси за стандартом iso/іec 15288.
- •Поняття вимоги. Етапи формування вимог. Рівні вимог.
- •Які розділи містить звіт про виконану роботу та заявку на розробку програмного забезпечення?
- •Склад і зміст робіт на стадії «Опис програмного забезпечення».
- •Поняття ескізний проект. Склад і зміст робіт на стадії «Ескізний проект».
- •Що описує Технічне завдання (тз). З яких етапів складається розробка тз та на основі якого стандарту?
- •З яких розділів складається технічне завдання?
- •Що описує Технічний проект (тп)? з яких етапів складається розробка технічного проекту?
- •Види забезпечень.
- •Статичні і динамічні методи тестування.
- •Тестування «білої скриньки»
- •Тестування «чорної скриньки».
- •Метод "сірої скриньки".
- •Види тестування.
- •Рівні тестування.
- •Помилки на етапах життєвого циклу програмного забезпечення.
- •Поняття помилки, дефекту та відмови.
- •Класи помилок в програмному забезпеченні.
- •Тест план (Test Plan). Тестовий сценарій (Test Cases). Процедури тестування (Test Procedures). Баг Репорт (Bug Report).
- •Моделі якості та надійності програмних систем
- •Якість програмного забезпечення. Модель якості за рівнями.
- •Показники якості.
- •Атрибути функціональності, надійності та зручності застосування.
- •Атрибути ефективності, супроводу та переносимості.
- •Метрики програмного продукту.
- •Метрики процесу створення продукту та використання.
- •Методи оцінки значень показників якості.
- •Методи управління програмним проектом
- •Поняття надійності програмного забезпечення.
- •Класифікації моделей надійності за Гоєлем.
- •Класифікації моделей надійності за Хетчем.
- •Інженерія надійності програмного забезпечення та її складові.
- •На яких процесах жц здійснюється перевірка надіності?
- •Поняття сертифікація програмного забезпечення. Види сертифікації продукту.
- •Евристична модель надійності.
- •Модель надійності Нельсона.
- •Модель надійності Джелінскі-Моранді.
- •Статистична модель надійності Міллса.
- •Поняття Проект (Project). Менеджмент проекту (Project Management). Масштаб проекту (Project Scope).
- •Головні цілі менеджменту проекту.
- •Процес менеджменту проекту.
- •Модель процесу керування проектом.
- •Учасники проекту з розробки програмного забезпечення.
- •Ролі в групі розробників проекту.
- •Мережні методи планування і керування проектом.
- •Метод критичного шляху – срм.
- •Метод аналізу й оцінки проекту – pert.
- •Види планів організації проекту.
- •Моніторинг проекту.
- •Модель оцінки вартості проекту cocomo.
- •Модель оцінки вартості проекту cocomo іі.
- •Поняття ризику у проекті. Причини ризику в проекті.
- •Види ризиків. Моніторинг і контроль ризиків.
- •Поняття конфігурації. Елементи конфігурації.
- •Поняття супроводу програмного забезпечення. Хто здійснює супровід.
- •Поняття підтримки програмного забезпечення. Структура іт-супроводу.
- •Поняття програмна археологія. Інструменти і методи програмної археології.
Тестування «білої скриньки»
Відома: внутрішня структура програми.
Досліджуються: внутрішні елементи програми і зв'язки між ними.
Об'єктом тестування тут є не зовнішня, а внутрішня поведінка програми. Перевіряється коректність побудови всіх елементів програми та правильність їхньої взаємодії один з одним. Зазвичай аналізуються керуючі зв'язки елементів, рідше — інформаційні зв'язки. Тестування за принципом «білого ящика» характеризується ступенем, в якому тести виконують або покривають логіку (вихідний текст) програми.
Особливості тестування «білої скриньки»
Зазвичай тестування «білої скриньки» засноване на аналізі керуючої структури програми. Програма вважається повністю перевіреною, якщо проведено вичерпне тестування маршрутів (шляхів) її графа управління.
У цьому випадку формуються тестові варіанти, в яких:
Гарантується перевірка всіх незалежних маршрутів програми.
Знаходяться гілки True, False для всіх логічних рішень.
Виконуються всі цикли (у межах їхніх кордонів та діапазонів).
Аналізується правильність внутрішніх структур даних.
Недоліки тестування «білої скриньки»:
Кількість незалежних маршрутів може бути дуже велика.
Повне тестування маршрутів не гарантує відповідності програми вихідним вимогам до неї.
У програмі можуть бути пропущені деякі маршрути.
Не можна виявити помилки, поява яких залежить від даних.
Переваги тестування «білої скриньки» пов'язані з тим, що принцип «білої скриньки» дозволяє врахувати особливості програмних помилок:
Кількість помилок мінімально в «центрі» і максимально на «периферії» програми.
Попередні припущення про ймовірність потоку керування або даних у програмі часто бувають некоректними. У результаті типовим може стати маршрут, модель обчислень за яким опрацьована слабо.
При записі алгоритму програмного забезпечення у вигляді тексту на мові програмування можливе внесення типових помилок трансляції (синтаксичних та семантичних).
Деякі результати в програмі залежать не від вихідних даних, а від внутрішніх станів програми.
Кожна з цих причин є аргументом для проведення тестування за принципом «білої скриньки». Тести «чорної скриньки» не зможуть реагувати на помилки таких типів.
Тестування «чорної скриньки».
Відомі: функції програми.
Досліджується: робота кожної функції на всій області визначення.
Основне місце програми тестів «чорної скриньки» — інтерфейс ПЗ.
Ці тести демонструють:
Як виконуються функції програми.
Як приймаються вихідні дані.
Як виробляються результати.
Як зберігається цілісність зовнішньої інформації.
При тестуванні «чорної скриньки» розглядаються системні характеристики програм, ігнорується їхня внутрішня логічна структура. Вичерпне тестування, як правило, неможливе. Наприклад, якщо в програмі 10 вхідних величин і кожна приймає по 10 значень, то кількість тестових варіантів становитиме 10^10 . Тестування «чорної скриньки» не реагує на багато особливостей програмних помилок.
Тестування «чорної скриньки» (функціональне тестування) дозволяє отримати комбінації вхідних даних, які забезпечують повну перевірку всіх функціональних вимог до програми. Програмний виріб тут розглядається як «чорна скринька», чию поведінку можна визначити тільки дослідженням його входів та відповідних виходів. При такому підході бажано мати:
Набір, утворений такими вхідними даними, які призводять до аномалій у поведінці програми (назвемо його IT);
Набір, утворений такими вхідними даними, які демонструють дефекти програми (назвемо його OT).
Будь-який спосіб тестування «чорної скриньки» повинен:
Виявити такі вхідні дані, які з високою ймовірністю належать набору IT;
Сформулювати такі очікувані результати, які з високою імовірністю є елементами набору OT.
Принцип «чорної скриньки» не альтернативний принципу «білої скриньки». Скоріше це доповнює підхід, який виявляє інший клас помилок.
Тестування «чорної скриньки» забезпечує пошук наступних категорій помилок:
Некоректних чи відсутніх функцій;
Помилок інтерфейсу;
Помилок у зовнішніх структурах даних або в доступі до зовнішньої бази даних;
Помилок характеристик (необхідна ємність пам'яті і т. д.);
Помилок ініціалізації та завершення.
Подібні категорії помилок способами «білої скриньки» не виявляються.
