К. М. Лавріщева програмна інженерія підручник Київ, 2008
 Скачать 5.23 Mb.
|
|
6.5.1. Класифікація помилок і методи їхнього пошуку Міжнародний стандарт ANSI/IEEE–729–83 розділяє всі помилки в розробці програм на такі типи. Помилка (error) – стан програми, при якому видаються неправильні результати, причиною яких є недоліки (flaw) в операторах програми або в технологічному процесі її розроблення, що приводить до неправильної інтерпретації вихідної інформації, отже, і до невірного розв’язку. Дефект (fault) у програмі – наслідок помилок розробника на кожному з процесів проектування, що може утримуватися у вхідних або проектних специфікаціях, текстах кодів програм, експлуатаційній документації тощо. У процесі виконання програми можуть бути виявлені дефект або збій. Відмова (failure) – це відхилення програми від функціонування або неможливість програми виконувати функції, визначені вимогами й обмеженнями, що розглядається як подія, яка сприяє переходу програми в непрацездатний стан через помилки, приховані у ній дефекти або збої у середовищі функціонування [6, 11]. Відмова може бути за таких причин: – помилкова специфікація або пропущена вимога, яка означає, що специфікація точно не відбиває того, що припускав користувач; – специфікація може містити у собі вимогу, яку неможливо виконати на даній апаратурі і програмному забезпеченні; – проект програми може містити у собі помилки (наприклад, база даних спроектована без засобів захисту від несанкціонованого доступу користувача, а потрібен захист); – програма може бути неправильною, тобто вона виконує невластивий алгоритм або він реалізований не цілком. Таким чином, відмова, як правило, є результатами однієї помилки або більше у програмі, а також наявності різного роду дефектів. Загальні класи помилок. Усі помилки, що виникають у програмах, розподіляють на такі класи [14, 26]: – логічні і функціональні помилки; – помилки обчислень і часу виконання; – помилки вводу-виводу і маніпулювання даними; – помилки інтерфейсів; – помилки обсягу даних і ін. Логічні помилки – наслідок порушення логіки алгоритму, внутрішньої непогодженості змінних і операторів, а також мовних правил програмування. Функціональні помилки – наслідок неправильно визначених функцій, порушення порядку їхнього застосування або відсутності повноти їхньої реалізації і т.д. Помилки обчислень виникають через неточність вхідних даних і реалізованих формул, похибок методів, неправильного застосування операцій обчислень. Помилки часу виконання зв'язані з відсутністю необхідної швидкості обробки запитів, або часу виконання або відновлення програми. Помилки вводу-виводу і маніпулювання даними є наслідком неякісної підготовки даних для виконання програми, збоїв при занесенні їх у базу даних або при вибірці з неї. Розділ 6 171 Помилки інтерфейсу належать до помилок взаємозв'язку окремих елементів одного з одним, що виявляється при передачі даних між ними, а також при взаємодії із середовищем функціонування. Помилки обсягу належать до даних і є наслідком того, що реалізовані методи доступу і розміри баз даних не задовольняють реальні обсяги інформації системи або інтенсивності їхньої обробки. Наведені основні класи помилок властиві різним типам компонентів ПС і виявляються вони в програмах по-різному. Так, при роботі з БД виникають помилки подання і маніпулювання даними, логічні помилки в завданні прикладних процедур обробки даних та ін. У програмах обчислювального характеру переважають помилки обчислень, а в програмах керування й обробки – логічні і функціональні помилки. У ПС, що складається з багатьох різномовних програм, які реалізують різні функції, можуть міститися помилки різних типів. Помилки інтерфейсів і порушення обсягу характерні для будь-якого типу ПС. Аналіз типів помилок у програмах є необхідною умовою створення планів і методів тестування для забезпечення правильності ПС. На сучасному процесі розвитку засобів підтримки розробки ПС (CASE– технології, інструменти) при проектуванні ПС захищається від найбільш типових помилок і запобігається поява дефектів. Фірма IВМ розробила підхід до класифікації помилок, названий ортогональною класифікацією дефектів [21]. При такому підході розподіл помилок за категоріями робить відповідальний розробник. Класифікація не залежить від продукту, організації розробки, вона може застосуються до всіх процесів розроблення ПС різного призначення. Відповідно до даної класифікації в табл. 6.2 наведено список помилок. Таблиця 6.2. Ортогональна класифікація дефектів IBM Контекст помилки Класифікація дефектів Функція Помилки інтерфейсів кінцевих користувачів ПС, викликані апаратурою або зв'язані з зовнішніми структурами даних Інтерфейс Помилки у взаємодії з іншими компонентами, у викликах, макросах, що керують блоками або в списку параметрів Логіка Помилки в програмній логіці, неохопленій валідацією, а також у використанні значень змінних Присвоювання Помилки в структурі даних або в ініціалізації змінних окремих частин програми Зациклення Помилки, викликані ресурсом часу, реальним часом або розподілом часу Середовище Помилки в репозитарії, у керуванні змінами або в контрольованих версіях проекту Алгоритм Помилки, пов'язані з забезпеченням ефективності, коректності алгоритмів або структур дані системи Документація Помилки в записах документів супроводу або в публікаціях Передбачено ситуації, коли знайдена неініційована змінна або ініційованій змінній привласнене неправильне значення. Ортогональність схеми класифікації полягає в тому, що будь-який її термін належить тільки до однієї категорії. Іншими словами, помилка, що простежується в системі, повинна знаходитися в одному з класів, що дає можливість різним розробникам класифікувати помилки однаковим способом. Фірма Hewlett–Packard використовувала класифікацію Буча, встановивши відсоткове співвідношення помилок, що виявляються в ПС на різних стадіях розробки (рис. 6.4.). Це співвідношення, типове для багатьох фірм, що роблять ПС, має деякі відхилення від інших. Згідно з даними [32] вартість аналізу і формування вимог, внесення до них змін становить приблизно 10%, аналогічно оцінюється вартість специфікації продукту. Вартість кодування оцінюється більше ніж 20%, а вартість тестування продукту дорівнює більш ніж 45% його загальної вартості. Значну частину вартості становить супровід готового продукту і виправлення виявлених у ньому помилок. Дослідження фірм IBM показали, чим пізніше виявляється помилка в програмі, тим дорожче коштує її виправлення, ця залежність близька до експонентної. Так, військово-повітряні сили США оцінили вартість розробки однієї інструкції в 75 доларів, а вартість супроводу дорівнює близько 4000 доларів. Рис. 6.4. Відсоткове співвідношення помилок при розробці ПС Зв'язок помилки з відмовою. Наявність помилки в програмі, як правило, приводить до відмови ПС при його функціонуванні. Для аналізу причинно- наслідкових зв'язків «помилка-відмова» виконуються такі дії: – ідентифікація помилок у технологіях проектування і програмування; – взаємозв'язок помилок процесу проектування і помилок, що допускаються людиною; – класифікація відмов, помилок і можливих помилок, а також дефектів на кожному процесі розробки; – зіставлення помилок людини, що допускаються на визначеному процесі розробки, і дефектів в об'єкті, як наслідків помилок специфікації проекту, моделей програм; Розділ 6 173 – перевірка і захист від помилок на всіх процесах ЖЦ, а також виявлення дефектів на кожному процесі розробки; – зіставлення дефектів і відмовлень у ПС для розробки системи взаємозв'язків і методики локалізації, збирання й аналізу інформації про відмови і дефекти; – розробка підходів до процесів документування й супроводження ПС. Кінцева мета причинно-наслідкових зв'язків «помилка-відмова» полягає у визначенні методів і засобів тестування і виявлення помилок визначених класів, а також критеріїв завершення тестування на множині наборів даних; у визначенні шляхів удосконалювання організації процесу розроблення, тестування і супроводу ПС. Наведемо таку класифікацію типів відмов: – апаратна, при якому загальносистемне ПС не працездатне; – інформаційна, викликана помилками у вхідних даних і передачі даних по каналах зв'язку, а також при збоях пристроїв вводу, як наслідок апаратних відмов; – програмна, при наявності помилок у компонентах системи; – ергономічна, викликана помилками оператора при його взаємодії з комп’ютером (це відмовлення – вторинна відмова, може привести до інформаційної або функціональної відмови). Деякі помилки можуть бути, з одного боку, наслідком недоробок при визначенні вимог, проекту, генерації вихідного коду або документації, з іншого боку, вони виникають в процесі розробки програми або інтерфейсів окремих елементів програми (порушення порядку параметрів і т.п.). 6.5.2. Процес тестування за життєвим циклом Наведені типи помилок розподіляються за процесами ЖЦ і їм відповідають такі джерела їхнього виникнення [23, 24]: – ненавмисне відхилення розробників від робочих стандартів або планів реалізації; – специфікації функціональних і інтерфейсних вимог виконані без дотримання стандартів розробки, що призводить до порушення функціонування програм; – організації процесу розробки – недосконале або недостатнє управління керівником проекту ресурсами (людськими, технічними, програмними і т.д.) і питаннями тестування й інтеграції елементів проекту. Розглянемо процес тестування, виходячи з рекомендацій стандарту ISO/IEC– 12207, і наведемо типи помилок, що виявляються під час кожного процесу ЖЦ. Процес розробки вимог. При визначенні вихідної концепції системи і вихідних вимог до системи виникають помилки аналітиків при специфікації вищого рівня системи і побудові концептуальної моделі предметної області. Характерними помилками цього процесу є: – неадекватність специфікації вимогам кінцевих користувачів; – некоректність специфікації взаємодії ПС із середовищем функціонування або з користувачами; – невідповідність вимог замовника окремим і загальним властивостям ПС; – некоректність опису функціональних характеристик; – незабезпеченість інструментальними засобами всіх аспектів реалізації вимог замовника й ін. Процес проектування. Помилки при проектуванні компонентів можуть бути наслідком недоліків в описі алгоритмів, логіки керування, структур даних, інтерфейсів, логіки моделювання потоків даних, форматів вводу-виводу та ін. В основі цих помилок лежать дефекти специфікацій заданих аналітиками і недоробки проектувальників. До них належать помилки, пов'язані з: – погодженістю інтерфейсу користувача із середовищем; – описом функцій (неадекватність цілей і задач компонентів, що виявляються при перевірці комплексу компонентів); – визначенням процесу обробки інформації і взаємодії між процесами (результат некоректного визначення взаємозв'язків компонентів і процесів); – некоректним завданням даних і їхніх структур при описі окремих компонентів і ПС у цілому; – некоректним описом алгоритмів модулів; – визначенням умов виникнення можливих помилок у програмі; – порушенням прийнятих для проекту стандартів і технологій. Процес кодування.На даному процесі виникають помилки, що є результатом дефектів проектування, помилок програмістів і менеджерів у процесі розроблення і налагодження системи. Причиною помилок є: – безконтрольність значень вхідних параметрів, індексів масивів, параметрів циклів, вихідних результатів та ін.; – неправильна обробка нерегулярних ситуацій при аналізі кодів повернення від викликуваних підпрограм, функцій і ін.; – порушення стандартів кодування (погані коментарі, нераціональне виділення модулів і компонентів та ін.); – використання одного імені для позначення різних об'єктів або різних імен одного об'єкта, погана мнемоніка імен; – непогоджене внесення змін у програму різними розробниками та ін. Процес тестування.На цьому процесі помилки допускаються програмістами і тестувальниками при виконанні технології збирання і тестування, вибору тестових наборів і сценаріїв тестування та ін. Відмови в програмному забезпеченні, викликані такого роду помилками, повинні виявлятися, усуватися і не впливають на статистику помилок компонентів і на програмне забезпечення в цілому. Процес супроводу. На процесі супроводу виявляються помилки, причиною яких є недоробки і дефекти експлуатаційної документації, недостатні показники кодифікованості й легкості читання, а також некомпетентність осіб, відповідальних за супровід і/або удосконалення ПС. Залежно від сутності внесених змін на цьому процесі можуть виникати практично будь-які помилки, аналогічні раніше перерахованим помилкам на попередніх процесах. Джерела помилок. Помилки можуть бути виникнути в процесі розроблення проекту, компонентів, коду і документації. Як правило, вони виявляються при виконанні або супроводі програмного забезпечення в найбільш несподіваних і різних її точках. Причиною появи помилок є – нерозуміння вимог замовника; неточна специфікація вимог у документах проекту та ін. Це приводить до того, що реалізуються деякі функції системи, що будуть працювати не так, як пропонує замовник. У зв'язку з цим проводиться спільне обговорення замовником і розробником деяких деталей вимог для їхнього уточнення. Розділ 6 175 Команда розробників системи може також змінити мову опису системи. Деякі помилки можуть бути не виявлені (наприклад, неправильно задані індекси або значення змінних цих операторів). Визначення тесту. Для перевірки правильності програм спеціально розробляються тести і тестові дані. Під тестом розуміється деяка програма, призначена для перевірки працездатності іншої програми і виявлення в ній помилкових ситуацій. Тестову перевірку можна провести також шляхом введення в програму, які перевіряється, операторів, які будуть сигналізувати про хід її виконання й отримання результатів. Тестові дані слугують для перевірки роботи системи і складаються різними способами: генератором тестових даних, проектною групою на основі документів або наявних файлів, користувачем з специфікаціях вимог та ін. Дуже часто розробляються спеціальні форми вхідних документів, у яких відображається процес виконання програми за допомогою тестових даних [23–25, 31]. Створюються тести, що перевіряють: – повноту функцій; – погодженість інтерфейсів; – коректність виконання функцій і правильність функціонування системи в заданих умовах; – надійність виконання системи; – захист від збоїв апаратури і не виявлених помилок та ін. Тестові дані готуються як для перевірки окремих програмних елементів, так і для груп програм або комплексів на різних стадіях процесу розроблення. Багато типів тестів готуються замовником для перевірки роботи програмної системи. Структура і зміст тестів залежать від виду елемента тестування, яким може бути модуль, компонент, група компонентів, підсистема або система. Деякі тести залежать від мети і необхідності знати: чи працює система відповідно до її проекту, чи задоволені вимоги і чи бере участь замовник у перевірці роботи тестів тощо. Залежно від задач, що ставляться перед тестуванням програм, складаються тести перевірки проміжних результатів проектування елементів на процесах ЖЦ, а також створюються тести іспитів остаточного коду системи. Тестування інтегрованої системи. Тести для перевірки окремих елементів системи і тести інтегрованої системи мають загальні і відмінні риси. Як приклад розглянемо схему інтеграції компонентів. На першому рівні схеми знаходяться, наприклад, компоненти А, B, D, на другому рівні – E, C, G. Вони пов'язані між собою інтерфейсом (рис.6.5). Кожен компонент схеми тестується окремо від інших компонентів тестами, що містять у собі набори даних і сценаріїв, складені відповідно до їхніх типів і функцій, специфікованих у вимогах до системи. Тестування проводиться в контрольному операційному середовищі на заданій безлічі тестових даних і операцій, розроблених з ними. Рис. 6.5. Схема тестування інтегрованих компонентів Тести перевіряють внутрішню структуру, логіку і граничні умови виконання кожного компонента. Спочатку тестуються компоненти А, B, D незалежно один від одного і кожний з окремим тестом. Після їхньої перевірки виконується перевірка інтерфейсів для зв'язку компонентів другого рівня: А E, B C, D G, а потім вже компоненти Е, C, G. Компоненти й інтерфейси інтегруються і утворюють компонент F, він перевіряється на правильність інтеграції і функцій. При тестуванні можуть виникати помилки. Вони, зазвичай, – результат неправильного завдання параметрів в операторах виклику або помилок в алгоритмі обчислення процедур або функцій. Помилки, що виникають у в зв'язках, усуваються, а потім повторно перевіряється зв'язок з компонентом F у вигляді трійки: компонент–інтерфейс–компонент. Наступний крок тестування комплексної системи – перевірка функціонування системи за допомогою тестів перевірки функцій і вимог до них. Після цього перевіряється комплекс на виконавчих і іспитових тестах відповідно до вимог до ПС, апаратури і виконуваних функцій. Іспит системи проводиться в реальному середовищі, у якому система буде функціонувати надалі. Приклад. Оцінювання часу тестування та ризиків відмов модулів. Нехай ми маємо приклад деякої системи інформаційно-аналітичної підтримки прийняття управлінських рішень із модулів [ 31, 33] (табл. 6.3.). Вони функціонують у розподіленому середовищі Oracle RunTime та MS Office (Word, Excel). Таблиця 6.3. Склад програмних комплексів ПС Шифр ПК Призначення ПК1 Підготовка вхідних даних ПК2 Ведення діловодства і контролю виконавської діяльності ПК3 Контроль і введення регламентованої інформації до БД ПК4 Надання довільних та регламентованих довідок ПК5 Формування звітної доповіді ПК6 Діагностична експертиза ПК7 Моніторинг стану діяльності ЗСУ Найбільший внесок у ризик відмов робить ПК3 контролю і введення даних до БД Oracle, який функціонує на 10 робочих місцях. Його головне призначення – контроль даних у формах, підготовлених за допомогою ПК1 та їх експорт до БД. Розділ 6 177 ПК3 виконує запис у більш як 90 таблиць БД, використовує понад 50 нормативно- довідкових таблиць та класифікаторів. На процесі проектування для цього ПК був виконаний аналіз можливих сценаріїв функціонування (рис. 6.4) за декількома способами використання. Таблиця 6.4. Функції модулів, що надають найбільший внесок у відмови ПС |