- •Галузева система управління якістю методи оцінки показників якості програмного забезпечення програмно-технічних комплексів критичного призначення Отраслевая система управления качеством
- •1 Сфера застосування
- •2 Нормативні посилання
- •3 Терміни та визначення понять
- •3.2 Безпека програмного забезпечення
- •3.8 Життєвий цикл системи
- •3.9 Інструментальний засіб (case-інструмент)
- •3.10 Категорія критичності програмного забезпечення
- •3.15 Оцінювання якості програмного забезпечення
- •3.16 Показники (характеристики) якості програмного забезпечення
- •3.19 Програмно-технічний комплекс
- •4 Познаки та скорочення
- •3.13 Надійність програмного забезпечення
- •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.2.4 Тестування синтаксису
5.3.2.4.1 Тестування синтаксису передбачає перевірку зовнішніх входів ПЗ таких, як команди оператора, дані від датчиків, інтерфейси між системами. Для виконання цього виду тестування вхідний синтаксис повинен бути описаний у вимогах до ПЗ та у проекті ПЗ. Описи вхідного синтаксису повинні включати множину користувальницьких і операторських команд, комунікаційні протоколи, логічні рішення, які відносяться до потоку транзакцій. Крім того, як джерела інформації, можуть бути використані експлуатаційна документація на ПЗ, а також вбудовані довідкові системи.
5.3.2.4.2 Для побудови тестів повинні використовуватися синтаксичний граф. Найбільш простий приклад синтаксичного графа представлено на рисунку 5.4. Програмні шляхи, які тестуються, формують у послідовностях, зазначених стрілками. Прямокутники на синтаксичному графі позначають програмні підставлені конструкції, а еліпси позначають програмні літерали.
Рисунок 5.4—Приклад синтаксичного графа
5.3.2.4.3 Синтаксичне тестування складається з побудови валідних і невалідних синтаксичних конструкцій і їхнього використання, як вхідних даних для тестування. Досить прості синтаксичні конструкції викликають велику кількість тестових прикладів, тому для синтаксичного тестування повинні використовуватися автоматизовані інструментальні засоби.
5.3.2.4.4 Під час синтаксичного тестування виявляються такі програмні помилки: невиконання валідних синтаксичних конструкцій, виконання невалідних синтаксичних конструкцій, а також відсутність механізмів оброблення валідних і невалідних синтаксичних конструкцій.
5.3.2.5 Тестування логічних умов
5.3.2.5.1 Цей вид тестування повинен застосовуватися у випадках, коли відповідні команди, які формуються ПЗ, залежать від набору значень логічних умов (правил). Відповідності між наборами логічних умов і станом вихідних умов змінних задають у вимогах до ПЗ. Для побудови тестів зазначені відповідності надають у вигляді так званих таблиць рішень (див. таблицю 5.3).
Таблиця 5.3—Приклад таблиці рішень
|
Набори логічних змінних (правила) |
|||||||
|
1 |
2 |
3 |
4 |
5 |
6 |
7 |
8 |
Умова 1 |
1 |
1 |
1 |
1 |
0 |
0 |
0 |
0 |
Умова 2 |
1 |
1 |
0 |
1 |
1 |
0 |
1 |
0 |
Умова 3 |
1 |
0 |
1 |
0 |
1 |
1 |
0 |
0 |
Дія 1 |
|
|
|
|
|
|
|
|
Дія 2 |
|
|
|
|
|
|
|
|
Дія 3 |
|
|
|
|
|
|
|
|
Дія 4 |
|
|
|
|
|
|
|
|
5.3.2.5.2 Перед початком тестування логічних умов повинна бути проведена верифікація таблиці рішень. Потім повинно бути перевірено відповідність роботи ПЗ щодо таблиці рішень для кожного з наборів логічних змінних.
5.3.2.5.3 Використання таблиці рішень для генерації тестів є доцільним у наступних умовах:
– вимоги до ПЗ у тому або іншому виді містять таблиці рішень;
– порядок оброблення логічних умов не впливає на інтерпретацію логічних правил і результуючі дії;
– логічні правила не залежать один від одного;
– за умови множинних результуючих дій, у випадку виконання однієї з логічних умов, послідовність дій не має значення.
