- •Галузева система управління якістю методи оцінки показників якості програмного забезпечення програмно-технічних комплексів критичного призначення Отраслевая система управления качеством
- •1 Сфера застосування
- •2 Нормативні посилання
- •3 Терміни та визначення понять
- •3.2 Безпека програмного забезпечення
- •3.8 Життєвий цикл системи
- •3.9 Інструментальний засіб (case-інструмент)
- •3.10 Категорія критичності програмного забезпечення
- •3.13 Надійність програмного забезпечення
- •3.15 Оцінювання якості програмного забезпечення
- •3.16 Показники (характеристики) якості програмного забезпечення
- •3.19 Програмно-технічний комплекс
- •4 Познаки та скорочення
- •5 Методи оцінювання показників якості програмного забезпечення критичного призначення
- •5.1 Методи оцінювання показників якості програмного забезпечення
- •5.2 Інспекції процесів розроблення програмного забезпечення
- •5.3 Методи тестування програмного забезпечення
- •5.3.1 Загальні положення щодо тестування програмного забезпечення
- •5.3.2 Методи функціонального тестування програмного забезпечення
- •5.3.2.1 Загальні положення щодо функціонального тестування програмного забезпечення
- •5.3.2.2 Тестування транзакцій
- •5.3.2.3 Тестування областей вхідних даних
- •5.3.2.4 Тестування синтаксису
- •5.3.2.5 Тестування логічних умов
- •5.3.2.6 Тестування станів
- •5.3.3 Метод структурного тестування програмного забезпечення
- •5.3.3.1 Загальні положення щодо структурного тестування програмного забезпечення
- •5.3.3.2 Тестування маршрутів
- •5.3.3.3 Тестування циклів
- •5.3.3.4 Тестування обробки даних
- •5.4 Методи статичного аналізу програмного забезпечення
- •5.4.1 Загальні положення щодо статичного аналізу програмного забезпечення
- •5.4.2 Аналіз потоку управління
- •5.4.3 Аналіз потоку даних
- •5.4.4 Метрична оцінка програмного забезпечення
- •5.5 Метод імовірнісної оцінки надійності програмного забезпечення
- •5.5.1 Загальні положення щодо імовірнісної оцінки надійності програмного забезпечення
- •5.5.2 Оброблення статистичних даних про відмови програмного забезпечення
- •5.5.3 Визначення параметрів моделей надійності
- •5.5.3.3 Мнпз, їхні допущення та аналітичні співвідношення
- •5.5.3.4 Модель Джелінського–Моранді
- •5.5.3.5 Модель Гела–Окумото
- •5.5.3.6 Модель базова s-подібна
- •5.5.3.7 Модель Шика–Уолвертона
- •5.5.3.8 Перша геометрична модель Моранди
- •5.5.3.9 Модель Муси–Окумото
- •5.5.3.10 Метод максимуму правдоподібності
- •5.5.3.11 Метод найменших квадратів
- •5.5.3.12 Приклади застосування моделей надійності програмного забезпечення
- •5.5.3.12.2 Оцінка показників надійності за допомогою мнпз, описаних у 5.5.3.4-5.5.3.9.
- •5.5.3.12.3 Модель Джелінського-Моранді
- •5.5.3.12.4 Модель Гела-Окумото
- •5.5.3.12.5 Базова s-подібна модель
- •5.5.3.12.6 Модель Шика-Уолвертона
- •5.5.3.12.7 Перша геометрична модель Моранді
- •5.5.3.12.8 Модель Муси-Окумото
- •5.5.4 Вибір моделі надійності програмного забезпечення
- •5.5.4.3 Критерій Колмогорова-Смирнова
- •5.5.4.4 Критерій 2
- •5.5.4.5 Критерій мінімального сумарного квадратичного відхилення:
- •5.5.5 Прогнозування показників надійності програмного забезпечення
- •5.6 Аналіз видів, наслідків і критичності відмов програмного забезпечення (sfmeca)
- •5.6.1 Загальні положення щодо аналізу видів, наслідків і критичності відмов
- •5.6.2 Основні принципи виконання sfmeca
- •5.6.2.1 Базування sfmeca
- •5.6.2.2 Визначення функціональної структури програмного забезпечення
- •5.6.2.3 Одержання вихідної інформації
- •5.6.2.4 Подання структури програмного забезпечення
- •5.6.2.5 Ідентифікація видів відмов
- •5.6.2.6 Аналіз відмов із загальної причини
- •5.6.2.7 Аналіз критичності
- •5.6.2.8 Зв'язок між sfmeca та іншими методами
- •5.6.3 Процедура виконання sfmeca
- •5.6.3.1 Процедура виконання sfmeca
- •5.6.3.2 Визначення вимог до програмного забезпечення
- •5.6.3.3 Розроблення діаграм, схем та інших математичних моделей і описів
- •5.6.3.4 Вибір рівнів програмного забезпечення і документації
- •5.6.3.5 Ідентифікація видів, причин і впливу відмов
- •5.6.3.6 Ідентифікація методів виявлення відмов та їх ізолювання
- •5.6.3.7 Опис значення відмов та альтернативних запобіжних заходів
- •5.6.3.8 Оцінка критичності та імовірності відмов
- •5.6.3.9 Розроблення рекомендацій і звіту за результатами sfmeca
- •5.7 Аналіз дерева відмов програмного забезпечення (sfta)
- •5.7.1 Загальні положення щодо аналізу дерева відмов програмного забезпечення
- •5.7.2 Процедура виконання sfta
- •5.7.2.1 Процедура виконання sfta
- •5.7.2.2 Визначення області аналізу
- •5.7.2.3 Ознайомлення з проектом, функціями і роботою програмного забезпечення
- •5.7.2.4 Визначення кінцевої події
- •5.7.2.5 Побудова дерева відмов
- •5.7.2.6 Логічний і чисельний аналіз дерева відмов
- •5.7.2.7 Розроблення звіту про результати аналізу
- •5.7.3 Умовні позначки для дерева відмов
- •5.8 Керівництво з адаптації нормативного документа
- •Додаток а
- •Бібліографія
5.3.3.2 Тестування маршрутів
5.3.3.2.1 Тестування структури маршрутів програмних модулів виконують шляхом перевірки коректності виділених маршрутів виконання програм і виявлення логічних помилок формування маршрутів. На практиці за відсутності впорядкованого аналізу потоків управління деякі маршрути у програмі (до 50%) виявляються пропущеними під час тестування. Тому перше завдання, яке вирішують під час тестування структури програмних модулів, – це отримання інформації про повну сукупність реальних маршрутів виконання. Наочне подання реалізованих маршрутів дозволяє впорядковано контролювати повноту їхнього тестування та до деякої міри охороняє від випадкового пропуску окремих маршрутів. У результаті тестування набуває запланованого систематичного характеру. Для забезпечення коректності програми всі маршрути можливого виконання програмного модуля повинні бути перевірені під час її створення та тим самим визначають складність повного тестування.
5.3.3.2.2 Під час планування тестування маршрутів виникають, насамперед, два завдання:
– формування та відбір критеріїв для виділення маршрутів під час тестування;
– вибір стратегій упорядкування виділених маршрутів під час підготовки тестів.
5.3.3.2.3 Критерії виділення маршрутів для тестування відповідають критеріям визначення структурної складності програмних модулів. Використовують переважно такі критерії:
– покриття графа програми мінімальною кількістю маршрутів, які охоплюють кожну дугу графа хоча б один раз (критерій 1);
– виділення лінійно-незалежних маршрутів, які відрізняються хоча б однією дугою (критерій 2);
– виділення маршрутів для усіх можливих комбінацій дуг, які входять до маршрутів (критерій 3).
5.3.3.2.4 Через протиріччя у начальних умовах у реальних програмах частина маршрутів, які виділяються формально на графі програми, не реалізується на послідовних ділянках маршруту. Це може призводити до скорочення числа маршрутів за будь-яким критерієм. До значного зростання числа маршрутів зазвичай призводять цикли у програмах. Наведені критерії є досить зручними для практичних оцінок складності і повноти тестування структури програм. Тестування доцільно планувати за одним із критеріїв.
5.3.3.2.5 Стратегії упорядкування маршрутів для тестування програми повинні враховувати складність маршруту та тестів для їхньої перевірки (кількість операторів, умовних переходів і циклів у маршруті, частоту його виконання під час функціонування ПЗ, складність одержання відповідних еталонних даних та інші фактори). У першу чергу доцільно робити перевірку основної групи маршрутів з екстремальними значеннями обраного показника у межах ресурсів, виділених для тестування. За умови практичних обмежень ресурсів деяка частина маршрутів може виявитися неперевіреною, що характеризує досягнуту повноту тестування програми за обраним критерієм.
5.3.3.2.6 Упорядкування маршрутів під час планування тестування базується на використанні переважно трьох характеристик програмних модулів:
– числа рядків тексту у виділених маршрутах або розрахунковій тривалості їхньої реалізації (стратегія 1);
– числа альтернатив (предикатів) або умовних переходів, які визначають утворення кожного маршруту (стратегія 2);
– імовірності виконання маршрутів під час функціонування програми (стратегія 3).
5.3.3.2.7 За умови використання стратегії 1 первинному тестуванню підлягають маршрути, найбільш довгі за числом рядків тексту та за часом виконання. Їм відповідають зазвичай маршрути з найбільшим обсягом обчислень і перетворень змінних. Ця стратегія є доцільною під час планування тестування програм, які мають обчислювальний характер оброблення даних з невеликим числом логічних умов і маршрутів виконання програм. Обрані первинні маршрути не обов'язково є найбільш складними за логікою функціонування.
5.3.3.2.8 За умови використання стратегії 2 пріоритет віддається маршрутам, найбільш складним за числом аналізованих умов розгалуження. Ця стратегія є найкращою під час тестування логічних програм з невеликим обсягом обчислень. Для обох стратегій на завершальні етапи тестування залишаються маршрути, прості за обсягом обчислень або за логікою, для яких необхідні відносно прості тести. Це відповідає традиційній стратегії, яка реалізує спочатку підготовку тестів з якомога більшим охопленням елементів структури програми, що налагоджується. В результаті вивчення структури програми виявляють найбільш критичні за тривалістю або найчастіші маршрути виконання програми. Такий підхід дозволяє сконцентрувати зусилля на перевірці найбільш активно функціонуючих компонентів і визначити слабко перевірені частини програми, які виконуються відносно рідко.
5.3.3.2.9 За умови впорядкування маршрутів згідно зі стратегією 3 основні труднощі полягають в оцінці ймовірностей умовних переходів, а також в оцінці числа виконання циклів. Проте, така стратегія дозволяє найбільш повно планувати тестування та оцінювати повноту тестування програм.
5.3.3.2.10 Планування тестування структури програмних модулів у значній мірі може бути автоматизованим. Завдання автоматизованих інструментальних засобів полягає у виділенні маршрутів програм за одним або декількома критеріями з наступним упорядкуванням за заданою стратегією. Якщо фіксувати маршрути, для яких вже проведено тестування, то можна автоматично одержувати інформацію про маршрути, які підлягають першочерговій перевірці. Ці дані можуть використовуватися для автоматичного розрахунку показників повноти тестування.
5.3.3.2.11 На рисунку 5.6 представлено приклад структурного графа програмного модуля, який має 14 вершин, 20 дуг і 3 цикли. Такий модуль порівняно невисокої складності містить близько 50 операторів, написаних мовою високого рівня та може розглядатися як досить типовий. Для повної перевірки модуля за критерієм 1 достатньо чотирьох маршрутів (див. рисунок 5.7). За цим критерієм гарантується перевірка усіх передач управління між операторами програми та кожного оператора не менше одного разу. Найдовший за числом вершин маршрут не охоплює тільки 3 вершин з 14 і тільки 6 дуг з 20.
Рисунок 5.6—Приклад графа структури програмного модуля
5.3.3.2.12 Після перевірки ще двох маршрутів поза контролем залишається одна вершина та дві дуги. Однак по цьому критерію не враховується комбінаторика сполучення умов на різних ділянках маршрутів, наприклад, при сполученнях напрямків розгалужень у вершинах 3 і 12. Складність тестування характеризує сумарне число умов, які необхідно задати у тестах для повної перевірки усіх маршрутів, виділених за критерієм 1. Умови у вершинах кожного маршруту можуть використовуватися для автоматизованого формування предикатів у відповідних тестах.
Рисунок 5.7—Маршрути, які виділено у графі структури програмного модуля за критерієм 1
5.3.3.2.13 Критерій 2 вибору маршрутів забезпечує у вихідному графі програми однократну перевірку кожного лінійно незалежного ациклічного маршруту та кожного лінійно незалежного циклу, які в сукупності утворюють базові маршрути. Кожний лінійно незалежний маршрут або цикл відрізняється від інших хоча б однією вершиною або дугою (див. рисунок 5.8). Множина структур, які перевіряють за цим критерієм, утворюється з трьох лінійно незалежних циклів і п'яти лінійно незалежних ациклічних структур.
Рисунок 5.8—Маршрути, які виділено у графі структури програмного модуля за критерієм 2
5.3.3.2.14 Найбільш глибокий критерій 3 перевірки та визначення складності тестування структури програми включає вимоги однократної перевірки не тільки лінійно незалежних, але й усіх лінійно залежних циклів і ациклічних маршрутів. Він полягає в аналізі хоча б один раз кожного з реальних ациклічних маршрутів вихідного графа програми та кожного циклу, досяжного з усіх цих маршрутів. Для прикладу графа програми, представленого на рис. 5.6, за даним критерієм необхідно виконати 6 ациклічних маршрутів і 5 маршрутів, з яких досяжні елементарні цикли. Для реалізації виділених маршрутів у 11 тестах необхідно в сукупності задати 66 умов. При цьому особливістю чотирьох останніх маршрутів із циклами, а також відповідних їм ациклічних маршрутів, є повний перебір сполучень розгалужень у вершинах 3 і 12. У реальних програмах деякі маршрути можуть виявитися нереалізованими через несумісність умов, які послідовно аналізуються у різних вершинах. З іншого боку, для кожного реалізованого маршруту може бути необхідна перевірка за декількома проходженнями циклів і декількох значень кожної оброблюваної змінної.
