- •Поняття технології конструювання програмного забезпечення.
- •Класичний життєвий цикл.
- •Макетування.
- •Характеристика стратегій конструювання пз.
- •Інкрементна модель.
- •Спіральна модель.
- •Важковагові та полегшені процеси. 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.
Спосіб розбиття по еквівалентності.
Розбиття по еквівалентності - найпопулярніший спосіб тестування «чорного ящика».
У цьому способі вхідні область даних програми ділиться на класи еквівалентності. Для кожного класу еквівалентності розробляється один тестовий варіант.
Клас еквівалентності - набір даних з загальними властивостями. Обробляючи різні елементи класу, програма повинна вести себе однаково. Інакше кажучи, при обробці будь-якого набору з класу еквівалентності в програмі задіюється один і той же набір операторів (і зв'язків між ними).
Класи еквівалентності можуть бути визначені по специфікації на програму.
Клас еквівалентності включає безліч значень даних, допустимих або неприпустимих за умовами введення.
Умова введення може задавати;
Певне значення.
Діапазон значень.
Безліч конкретних величин.
Булева умова.
Сформулюємо правила формування класів еквівалентності.
якщо умова введення задає діапазон n ... m, то визначається один допустимий і два неприпустимих класу еквівалентності.
якщо умова введення задає конкретне значення a, то визначається один допустимий і два неприпустимих класу еквівалентності.
якщо умова введення задає безліч значень {a, b, c}, то визначається один допустимий і один неприпустимий клас еквівалентності.
якщо умова введення задає логічне значення, наприклад true, то визначається один допустимий і один неприпустимий клас еквівалентності.
Після побудови класів еквівалентності розробляються тестові варіанти.
Тестовий варіант вибирається так, щоб перевірити відразу найбільшу кількість властивостей класу еквівалентності.
Спосіб аналізу граничних значень.
Як правило, більша частина помилок відбувається на кордонах області введення, а не в центрі. Аналіз граничних значень полягає в отриманні тестових варіантів, які аналізують граничні значення. Даний спосіб тестування доповнює спосіб розбиття по еквівалентності.
Основні відмінності аналізу граничних значень від розбиття по еквівалентності:
тестові варіанти створюються для перевірки тільки ребер класів еквівалентності.
При створенні тестових варіантів враховують не тільки умови введення, а й область виводу.
Сформулюємо правила аналізу граничних значень.
якщо умова введення задає діапазон n ... m, то тестові варіанти повинні бути побудовані:
для значень n і m.
для значень трохи лівіше n і трохи правіше m на числовій осі.
2. Якщо умова введення задає дискретну безліч значень, то створюються тестові варіанти:
1. для перевірки мінімального і максимального із значень.
2. для значень трохи менше мінімуму та трохи більше максимуму.
3. Правила 1 і 2 застосовуються до умов області виведення.
4. Якщо внутрішні структури даних програми мають визначені межі, то розробляються тестові варіанти, що повторюють ці структури на їх межах.
5. Якщо вхідні або вихідні дані програми є впорядкованими множинами (наприклад, послідовним файлом, лінійним списком, таблицею), то треба тестувати обробку першого і останнього елементів цих множин.
Більшість розробників використовують цей спосіб інтуїтивно. При застосуванні описаних правил тестування цих кордонів буде більш повним, у зв'язку з чим зросте ймовірність виявлення помилки.