- •Поняття технології конструювання програмного забезпечення.
- •Класичний життєвий цикл.
- •Макетування.
- •Характеристика стратегій конструювання пз.
- •Інкрементна модель.
- •Спіральна модель.
- •Важковагові та полегшені процеси. Xp – процес.
- •Швидка розробка додатків, rad.
- •Компонентно-орієнтована модель. Моделі якості процесів конструювання.
- •Сторони зацікавлені в продукції.
- •Користувачі. Покупці. Інвестори.
- •Вимоги до пз кожної з сторін.
- •Атрибути якості пз: практичність, відмовостійкість, надійність, ремонтопридатність.
- •Визначення архітектури пз.
- •Опис архітектури пз.
- •Універсальна мова моделювання (uml).
- •Інші базові засоби для створення архітектури.
- •Основні компоненти мови. Призначення мови. Термінологія uml.
- •Процес керування проектом. Планування.
- •Планування проектних задач.
- •Розмірно-орієнтовані метрики.
- •Функціонально-орієнтовані метрики.
- •Виконання оцінки проекту на основі loc- та fp-метрик.
- •Дослідження під моделей моделі cocomo, cocomo II.
- •Конструктивна модель вартості.
- •Модель композиції додатку.
- •Модель раннього етапу проектування.
- •Модель етапу пост архітектури.
- •Структурний аналіз.
- •Основи проектування програмних систем.
- •Класичні методи проектування.
- •Основні поняття та принципи тестування пз.
- •Особливості тестування «білого ящику».
- •Способи тестування базового шляху.
- •Способи тестування умов.
- •Спосіб тестування потоків даних.
- •Тестування циклів.
- •Особливості тестування «чорного ящику».
- •Спосіб розбиття по еквівалентності.
- •Спосіб аналізу граничних значень.
- •Спосіб діаграм причин-наслідків.
- •Дослідження способів структурного та функціонального тестування на прикладах.
- •Методика тестування програмних систем.
- •Тестування правильності.
- •Системне тестування .
- •Мистецтво налагоджування.
- •Основні принципи об’єктна-орієнтованої методології розробки програмної системи (оом пс).
- •Оо Аналіз.
- •Об’єкти та класи.
- •Діаграми в uml.
- •Механізми розширення в uml.
- •Діаграма варіантів використання.
- •Дослідження діаграми варіантів використання.
- •Діаграма класів.
- •2. Асоціації:
- •Дослідження діаграми класів.
- •Діаграма станів.
- •Дослідження діаграми станів.
- •Діаграма діяльності.
- •Дослідження діаграми діяльності.
- •Діаграма послідовності.
- •Дослідження діаграми послідовності.
- •Діаграма кооперації.
- •Дослідження діаграми кооперації.
- •Діаграма компонентів.
- •Дослідження діаграми компонентів.
- •Діаграма розгортування.
- •Дослідження діаграми розгортування.
- •Загальні відомості case-засобів.
- •Case-засоби. Класифікація case-засобів.
- •Порівняння життєвого циклу програмного забезпечення при традиційній розробці і розробці з використанням case-засобів.
- •Концептуальні основи case-технології.
- •Технологія впровадження –засобів.
- •Оцінка і вибір –засобів.
- •Засоби функціонального моделювання.
- •Характеристики case–засобів Silverrun.
- •Характеристики case–засобів jam.
- •Загальна характеристика case-системи Rational Rose.
- •Розробка діаграм у середовищі Rational Rose.
- •Початок роботи над проектом у середовищі Rational Rose.
Спосіб діаграм причин-наслідків.
Діаграма причинно-наслідкових зв'язків - Це спосіб проектування тестових варіантів, які забезпечують формальний запис логічних умов і відповідних дій. При цьому зазвичай використовується автоматний підхід до вирішення завдання.
Кроки способу побудови діаграм причинно-наслідкових зв'язків:
1) Для кожного модуля перераховуються причини, тобто умови введення або класи еквівалентності умов введення, а також слідства, тобто дії або умови виведення. Кожній причини і наслідку присвоюється свій ідентифікатор.
2) Розробляється граф причинно-наслідкових зв'язків.
3) Граф перетворюється в таблицю рішень.
4) Стовпці таблиці рішень перетворюються в тестові варіанти.
Базові символи для запису графів причин і наслідків: причини позначаються символом (Cause), слідства позначаються символом (Effects).
Кожен вузол графа може перебувати в стані 0 або 1. Причому 0 означає, що стан відсутній, а 1-стан присутній.
функція тотожності встановлює, що якщо значення дорівнює 1, то значення теж дорівнює 1, в іншому випадку значення дорівнює 0.
функція НЕ встановлює, що якщо значення дорівнює 1, то приймає значення 0, в іншому випадку дорівнює 1.
функція АБО встановлює, що якщо або дорівнює 1, то також дорівнює 1, в іншому випадку дорівнює 0.
функція І встановлює, що якщо и рівні 1, то теж дорівнює 1, в іншому випадку дорівнює 0.
Часто певні поєднання величин неможливі через синтаксичних або зовнішніх обмежень. У цьому випадку використовуються наступні позначення обмежень.
обмеження E (Exclusive) встановлює, що E має бути істинним, якщо хоча б одна з причин a або b не можуть приймати значення 1 одночасно.
обмеження I(Inclusive) встановлює, що, принаймні, одна з причин a, b або c повинна дорівнювати 1, тобто a, b і c не можуть приймати значення 0 одночасно.
обмеження O (Only lone) встановлює, що одна і тільки одна з величин a або b повинна бути дорівнює 1.
обмеження R (Requires) встановлює, що якщо a приймає значення 1, то і величина b повинна приймати значення 1.
Обмеження для наслідків M (Masks) встановлює, що якщо слідство a має значення 1, то наслідок b має прийняти значення 0.
Дослідження способів структурного та функціонального тестування на прикладах.
Структу́рне тестува́ння, також називають тестуванням за принципом «білої скриньки» або «скляної скриньки» (англ. White box testing або англ. Glass box testing), полягає у перевірці внутрішньої структури елементів системи.
Основним видом тестування є функціональне. Функціональне тестування застосовують для програмного забезпечення у цілому, а також для програмних об’єктів будь-якого рівня (процедури, модулі, підсистеми, системи). Структурне тестування доповнює функціональне. Цей вид тестування можливий для рівня не вище рівня програмного модуля. Виконання функціонального і структурного тестування системи може бути здійснене незалежно одне від одного.
Методи структурного тестування
Структурне тестування програмного забезпечення може бути реалізоване такими методами:
тестуванням маршрутів;
тестуванням циклів;
тестуванням обробки даних.
Тестування маршрутів
Тестування структури маршрутів програмних модулів виконують шляхом перевірки коректності виділених маршрутів виконання програм і виявлення логічних помилок формування маршрутів. На практиці за відсутності впорядкованого аналізу потоків управління деякі маршрути у програмі (до 50%) виявляються пропущеними під час тестування. Тому перше завдання, яке вирішують під час тестування структури програмних модулів, — це отримання інформації про повну сукупність реальних маршрутів виконання. Наочне подання реалізованих маршрутів дозволяє впорядковано контролювати повноту їхнього тестування та до деякої міри охороняє від випадкового пропуску окремих маршрутів. У результаті тестування набуває запланованого систематичного характеру. Для забезпечення коректності програми всі маршрути можливого виконання програмного модуля повинні бути перевірені під час її створення та тим самим визначають складність повного тестування.
Тестування циклів
Наявність циклів у програмних модулях здатне різко збільшувати складність їхнього тестування.Повне, вичерпне тестування повинне охоплювати перевірку кожного маршруту у циклі за усіх можливих ітерацій циклу та для усіх сполучень циклів з маршрутами ациклічної частини програми. На складність тестування циклу впливає його структура та два параметри: число маршрутів у тілі циклу та число ітерацій циклу. За умови зростання кожного з цих параметрів пропорційно зростає їхній добуток, а отже, і складність тестування. Тому вичерпне тестування реальних складних програм із циклами практично неможливе.
Тестування обробки даних
Функціонування будь-якої програми можна розглядати як обробку потоку даних, переданих від входу у програму до її виходу. Вхідні дані послідовно використовуються для визначення ряду проміжних результатів аж до одержання необхідного набору вихідних даних.
Наслідки помилок у програмі можуть проявлятися як зміни деяких змінних у процесі обчислень і як повне перекручування або відсутність на виході величин, що вимагаються. Тестування програмного модуля доцільно проводити на впорядкованих наборах даних з урахуванням ступеня їхнього впливу на вихідні результати.
Особливості функціонального(чорного ящика) тестування
Тестування чорного ящика дозволяє отримати поєднання вхідних даних, що забезпечують повну перевірку всіх функціональних вимог до програми. Програмний продукт при функціональному тестуванні розглядається як чорний ящик, поведінка якого можна визначити тільки шляхом дослідження його входів і відповідних виходів. При такому підході бажано мати:
1) набір, утворений вхідними даними, який призводить до аномалій поведінки програми;
2) набір, утворений такими вхідними даними, які демонструють дефекти програми.
Будь-який спосіб тестування чорного ящика повинен:
1) виявити такі вхідні дані, які з високою ймовірністю призводять до аномалій поведінки програми;
2) сформулювати такі очікувані результати, які з високою ймовірністю виявляють наявність дефектів.
У багатьох випадках визначення таких тестових варіантів грунтується на попередньому досвіді тестувальників. Вони використовують свої знання і розуміння в області визначення для ідентифікації тестових варіантів, які ефективно виявляють дефекти.
Принцип чорного ящика не альтернативний принципом білого ящика. Швидше це доповнює підхід, який виявляє інший клас помилок.
Тестування чорного ящика забезпечує пошук наступних категорій помилок:
1) некоректних або відсутніх функцій;
2) помилок інтерфейсу;
3) помилок у зовнішніх структурах даних або в доступі до зовнішньої базі даних;
4) помилок характеристик апаратних пристроїв;
5) помилок ініціалізації і завершення.
Подібна категорія помилок не дозволяє виявити тестування білого ящика.
На відміну від тестування білого ящика, яке виконується на ранній стадії тестування програмного забезпечення, тестування чорного ящика застосовується на пізніх стадіях тестування. При тестуванні чорного ящика нехтують керуючою структурою програми і концентрують увагу на інформаційній галузі визначення програмної системи.
Технологія тестування чорного ящика орієнтована на вирішення таких завдань:
1) Скорочення необхідної кількості тестових варіантів через перевірки нестатичних, а динамічних аспектів системи;
2) Виявлення класів помилок, а не окремих помилок.
