Тестування програмних продуктів

I. ВСТУП.

ЗАГАЛЬНІ ПОНЯТТЯ.

Багато організацій, що займаються створенням програмного забезпечення, до 50% коштів, виділених на розробку програм, витрачають на тестування, що складає мільярди доларів по всьому світу в цілому. І все ж, незважаючи на величезні капіталовкладення, знань про суть тестування явно не вистачає і більшість програмних продуктів неприйнятно ненадійно навіть після "грунтовного тестування".

Про стан справ найкраще свідчить той факт, що більшість людей, що працюють в області обробки даних, навіть не може правильно визначити слово "тестування", і це насправді головна причина невдач.

"Тестування - процес, що підтверджує правильність програми і демонструє, що помилок у програмі немає." Основний недолік такого визначення полягає в тому, що воно зовсім неправильно; фактично це майже визначення антоніма слова "тестування". Читач з деяким досвідом програмування вже, ймовірно, розуміє, що неможливо продемонструвати відсутність помилок в програмі. Тому визначення описує нездійсненне завдання, а так як тестування часто все робиться з успіхом, принаймні з певним успіхом, то таке визначення логічно некоректно. Правильне визначення тестування таке: Тестування - процес виконання програми з наміром знайти помилки.

Неможливо гарантувати відсутність помилок в нетривіальною програмі; в кращому випадку можна спробувати показати наявність помилок. Якщо програма правильно веде себе для солідного набору тестів, немає підставі стверджувати, що в ній немає помилок; з усією певністю можна лише стверджувати, що не відомо, коли ця програма не працює. Звичайно, якщо є причини вважати даний набір тестів здатним з великою вірогідністю виявити всі можливі помилки, то можна говорити про деяке рівні впевненості в правильності програми, встановлюється цими тестами.

Психологічні експерименти показують, що більшість людей, поставивши за мету (наприклад, показати, що помилок немає), орієнтується у своїй діяльності на досягнення цієї мети. Тестовік підсвідомо не дозволить собі діяти проти мети, тобто підготувати тест, який виявив би одну з залишилися в програмі помилок. Оскільки ми всі визнаємо, що досконалість у проектуванні та кодуванні будь-якої програми недосяжно і тому кожна програма містить деяку кількість помилок, найбільш плідним застосуванням тестування буде знайти деякі з них. Якщо ми хочемо добитися цього і уникнути психологічного бар'єру, що заважає нам діяти проти поставленої мети, наша мета повинна полягати в тому, щоб знайти як можна більше помилок. Сформулюємо основоположний висновок:

Якщо ваша мета - показати відсутність помилок, ви. їх знайдете не надто багато. Якщо ж ваша мета - показати наявність помилок, ви знайдете значну їх частину.

Надійність неможливо внести в програму в результаті тестування, вона визначається правильністю етапів проектування. Найкраще рішення проблеми надійності - з самого початку не допускати помилок в програмі. Однак імовірність того, що вдасться бездоганно спроектувати велику програму, нескінченно мала. Роль тестування полягає саме в тому, щоб визначити місцезнаходження нечисленних помилок, що залишилися в добре спроектованої програмі. Спроби за допомогою тестування досягти надійності погано спроектованої програми абсолютно безплідні.

Тестування виявляється досить незвичайним процесом (ось чому воно і вважається важким), так як цей процес руйнівний. Адже мета перевіряючого (тестовіка) - змусити програму збитися. Він задоволений, якщо це йому вдається, коли ж програма на його стосується не збивається, він не задоволений.

Ще одна причина, по якій важко говорити про тестування - це той факт, що про нього відомо дуже небагато. Якщо сьогодні ми маємо в своєму розпорядженні 5% тих знанні про проектування і власне програмуванні (кодуванні), які будуть у нас до 2000 р., то про тестуванні нам відомо менше 1%.

ОСНОВНІ ВИЗНАЧЕННЯ.

Хоча в тестуванні можна виділити кілька різних процесів, такі терміни, як тестування, налагодження, доказ, контроль і випробування, часто використовуються як синоніми і, на жаль, для різних людей мають різне значення. Хоча стандартних, загальноприйнятих визначень цих термінів немає, спроба сформулювати їх була зроблена на симпозіумі з тестування програм. Нашу класифікацію різних форм тестування ми почнемо з того, що дамо ці визначення, злегка їх доповнивши і розширивши їх список.

Тестування (testing), як ми вже з'ясували,-процес виконання програми (або частини програми) з наміром (або метою) знайти помилки.

Доказ (proof) - спроба знайти помилки в програмі безвідносно до зовнішнього для програми середовищі. Більшість методів доказу передбачає формулювання тверджень про поведінку програми і потім висновок і доказ математичних теорем про правильність програми. Докази можуть розглядатися як форма тестування, хоча вони і не передбачають прямого виконання програми. Багато дослідників вважають доказ альтернативою тестуванню - погляд багато в чому помилковий; більш детально це обговорюється в гл. 17.

Контроль (verification) - спроба знайти помилки, виконуючи програму в тестовій, або моделюється, середовищі.

Випробування (validation) - спроба знайти помилки, виконуючи програму в заданій реальному середовищі.

Атестація (certification) - авторитетне підтвердження правильності програми, аналогічне атестації електротехнічного обладнання Underwriters Laboratories. Під час тестування з метою атестації виконується порівняння з деякими заздалегідь певним стандартом.

Налагодження (debugging) не є різновидом тестування. Хоча слова "налагодження" і "тестування" часто використовуються як синоніми, під ними маються на увазі різні види діяльності. Тестування - діяльність, спрямована на виявлення помилок; налагодження спрямована на встановлення точної природи відомої помилки, а потім - на виправлення цієї помилки. Ці два види діяльності пов'язані - результати тестування є вихідними даними для налагодження.

Тестування модуля, або автономне тестування (module testing, unit testing) - контроль окремого програмного модуля, звичайно в ізольованому середовищі (тобто ізольовано від усіх інших модулів). Тестування модуля іноді включає також математичне доказ.

Тестування сполученні (integration testing) - контроль сполученні між частинами системи (модулями, компонентами, підсистемами).

Тестування зовнішніх функцій (external function testing) - контроль зовнішнього поведінки системи, певного зовнішніми специфікаціями.

Комплексне тестування (system testing) - контроль та / або випробування системи по відношенню до вихідних цілям. Комплексне тестування є процесом контролю, якщо воно виконується в моделюється середовищі, і процесом випробування, якщо виконується в середовищі реальної, життєвої.

Тестування прийнятності (acceptance testing) - перевірка відповідності програми вимогам користувача.

Тестування налаштування (installation testing) - перевірка відповідності кожного конкретного варіанту установки системи з метою виявити будь-які помилки, що виникли в процесі настройки системи.

Відносини між цими типами тестів і проектною документацією, на якій грунтується тест, показані на рис.3,

Рис. 2. Спектр підходів до проектування тестів,

Рис. 3. Процеси тестування та їх зв'язок з процесами проектування.

II. ОСНОВНА ЧАСТИНА.

ФІЛОСОФІЯ ТЕСТУВАННЯ

Тестування програмного забезпечення охоплює цілий ряд видів діяльності, дуже аналогічний послідовності процесів розробки програмного забезпечення. Сюди входять постановка задачі для тесту, проектування, написання тестів, тестування тестів і, нарешті, виконання тестів та вивчення результатів тестування. Вирішальну роль грає проектування тесту. Можливий цілий спектр підходів до вироблення філософії, або стратегії проектування тестів, зображений на рис.2. Щоб орієнтуватися в стратегіях проектування тестів, варто розглянути два крайніх підходу, що знаходяться на кордонах спектру. Слід відзначити також, що багато хто з тих, хто працює в цій області, часто впадають в одну чи іншу крайність.

Прихильник (або прихильниця) підходу, відповідного лівої межі спектру, проектує свої тести, досліджуючи зовнішні специфікації або специфікації сполучення програми або модулі, які він тестує. Програму він розглядає як чорний ящик. Позиція його така: "Мене не цікавить, як виглядає ця програма і чи виконав я всі команди або всі шляхи. Я буду задоволений, якщо програма буде вести себе так, як зазначено у специфікаціях ". Його ідеал - перевірити всі можливі комбінації і значення на вході.

Прихильник підходу, відповідного іншого кінця спектра, проектує свої тести, вивчаючи логіку програми. Він починає з того, що прагне підготувати достатню кількість тестів для того, щоб кожна команда була виконана принаймні один раз. Якщо він трохи більш досвідчений, то проектує тести так, щоб кожна команда умовного переходу виконувалася в кожному напрямку хоча б раз. Його ідеал - перевірити кожен шлях, кожну гілку алгоритму. При цьому його зовсім (або майже зовсім) не цікавлять специфікації.

Жодна з цих крайнощів не є хорошою стратегією. Читач, однак, вже, мабуть, зауважив, що перша з них, а саме та, відповідно до якої програма розглядається як чорний ящик, краще. На жаль, вона страждає тим недоліком, що абсолютно нездійсненна. Розглянемо спробу тестування тривіальної програми, отримує на вході три числа і обчислює їх середнє арифметичне. Тестування цієї програми для всіх значень вхідних даних неможливо. Навіть для машини з відносно низькою точністю обчислень кількість тестів обчислювалося б мільярдами. Навіть якби ми обчислювальну потужність, достатню для виконання всіх тестів в розумний час, ми витратили б на кілька порядків більше часу для того, щоб ці тести підготувати, а потім перевірити. Такі програми, як системи реального часу, операційні системи і програми управління даними, які зберігають "пам'ять" про попередні вхідних даних, ще гірше. Нам треба було б тестувати програму не тільки для кожного вхідного значення, але і для кожної послідовності, кожної комбінації вхідних даних. Тому вичерпне тестування для всіх вхідних даних будь-якої розумної програми нездійсненне.

Ці міркування приводять до другого фундаментальному принципу тестування: тестування - проблема значною мірою економічна. Оскільки вичерпне тестування неможливе, ми повинні обмежитися чимось меншим. Кожен тест повинен давати максимальну віддачу в порівнянні з нашими витратами. Ця віддача вимірюється ймовірністю тою, що тест виявить не виявлену перш помилку. Витрати вимірюються часом і вартістю підготовки, виконання та перевірки результатів тесту. Вважаючи, що витрати обмежені бюджетом та графіком, можна стверджувати, що мистецтво тестування, по суті, є мистецтвом відбору тестів з максимальною віддачею. Більше того, кожен тест повинен бути представником деякого класу вхідних значень, так щоб його правильне виконання створювало у нас деяку переконаність у тому, що для певного класу вхідних даних програма буде виконуватися правильно. Це звичайно вимагає деякого знання алгоритму і структури програми, і ми, таким чином, зміщується до правого кінця спектра.

ІНТЕГРАЦІЯ МОДУЛІВ.

Другим за важливістю аспектом тестування (після проектування тестів) є послідовність злиття всіх модулів у систему чи програму. Ця сторона питання зазвичай не отримує достатньої уваги і часто розглядається занадто пізно. Вибір цієї послідовності, однак, є одним з найбільш життєво важливих рішенні, прийнятих на етапі тестування, оскільки він визначає форму, в якій записуються тести, типи необхідних інструментів тестування, послідовність програмування модулів, а також ретельність і економічність усього етапу тестування. З цієї причини таке рішення має прийматися на рівні проекту в цілому і на досить ранній його стадії.

Є великий вибір можливих підходів, які можуть бути використані для злиття модулів у більші одиниці. У більшості своїй вони можуть розглядатися як варіанти шести основних підходів, описаних в наступних шести розділах. Відразу ж за ними йде розділ, де запропоновані підходи порівнюються по їх впливу на надійність програмного забезпечення.

Висхідне тестування.

При висхідному підході програма збирається і тестується знизу вгору. Тільки модулі самого нижнього рівня ("термінальні" модулі; модулі, які не викликають інших модулів) тестуються ізольовано, автономно. Після того як тестування цих модулів завершено, виклик їх повинен бути так само надійний, як виклик вбудованої функції мови або оператор присвоювання. Потім тестуються модулі, безпосередньо викликають вже перевірені. Ці модулі більш високого рівня тестуються не автономно, а разом з уже перевіреними модулями більш низького рівня. Процес повторюється до тих пір, поки не буде досягнута вершина. Тут завершуються і тестування модулів, і тестування сполученні програми.

При висхідному тестуванні для кожного модуля необхідний драйвер: потрібно подавати тести відповідно до сполученням модуля, що тестується. Одне з можливих рішенні - написати для кожного модуля невелику провідну програму. Тестові дані представляються як "вбудовані" безпосередньо в цю програму змінні і структури даних, і вона багаторазово викликає модуль, що тестується, з кожним викликом передаючи йому нові тестові дані. Є і краще рішення: скористатися програмою тестування модулів - це інструмент тестування, що дозволяє описувати тести на спеціальній мові що рятує від необхідності писати драйвери.

Низхідне тестування.

Низхідне тестування (зване також низхідній розробкою не є повною протилежністю висхідному, але в першому наближенні може розглядатися як таке, При низхідному підході програма збирається і тестується зверху вниз. Ізольовано тестується тільки головний модуль. Після того як тестування цього модуля завершено, з ним з'єднуються ( наприклад, редактором зв'язків) один за іншим модулі, безпосередньо викликані їм, та тестується отримана комбінація. Процес повторюється до тих пір, поки не будуть зібрані і перевірені всі модулі.

При цьому підході негайно виникає два питання: що робити, коли модуль, що тестується викликає модуль нижчого рівня (якого в даний момент ще не існує), і як подаються тестові дані. Відповідь на перше питання полягає в тому, що для імітації функцій відсутніх модулів програмуються модулі-заглушки ", які моделюють функції відсутніх модулів. Фраза "просто напишіть заглушку" часто зустрічається в описі цього підходу, але вона здатна ввести в оману, оскільки завдання написання заглушки "може виявитися важким. Адже заглушка рідко зводиться просто до оператора RETURN, оскільки викликає модуль зазвичай чекає від неї вихідних параметрів. У таких випадках у заглушку вбудовують фіксовані вихідні дані, які вона завжди і повертає. Це іноді виявляється неприйнятним, так як зухвалий модуль може розраховувати, що результат виклику залежить від вхідних даних. Тому в деяких випадках заглушка повинна бути досить гострою, наближаючись за складністю до модуля, який вона намагається моделювати.

Цікавий і друге питання: в якій формі готуються тестові дані і як вони передаються програмі? Якби головний модуль містив всі потрібні операції введення і виведення, відповідь була б проста:

Тести пишуться у вигляді звичайних для користувачів зовнішніх даних і передаються програмі через виділені їй пристрої введення. Так, однак, трапляється рідко. У добре спроектованої програмі фізичні операції введення-виведення виконуються на нижніх рівнях структури, оскільки фізичний ввід-висновок - абстракція досить низького рівня. Тому для того, щоб вирішити проблему економічно ефективно, модулі додаються не в строго низхідній послідовності (всі модулі одного горизонтального рівня, потім модулі наступного рівня), а таким чином, щоб забезпечити функціонування операцій фізичного введення-виведення як можна швидше. Коли ця мета досягнута, що сходить тестування отримує значну перевагу: всі подальші тести готуються в тій же формі, яка розрахована на користувача.

Залишається ще одне питання: в якій формі пишуться тести до тих пір, поки не буде досягнута ця мета? Відповідь: вони включаються до деяких з заглушок.

Спадний метод має як переваги, так і недоліки в порівнянні з висхідним. Найзначніше гідність - в тому, що цей метод поєднує тестування модуля, тестування сполученні і частково тестування зовнішніх функцій. З цим же пов'язана інша його достоїнство - коли модулі введення-виведення вже підключені, тести можна готувати в зручному вигляді. Спадний підхід вигідний також у тому випадку, коли є сумніви щодо здійсненності програми в цілому або якщо в проекті програми можуть виявитися серйозні дефекти.

Перевагою низхідного підходу дуже часто вважають відсутність необхідності в драйверах; замість драйверів вам просто слід написати "заглушки". Як читач зараз вже, ймовірно, розуміє, це перевага спірна.

Спадний метод тестування має, на жаль, деякі недоліки. Основним з них є той, що модуль рідко тестується досконально відразу після його підключення. Справа в тому, що грунтовне тестування деяких модулів може зажадати вкрай витончених заглушок. Програміст часто вирішує не витрачати масу часу на їх програмування, а замість цього пише прості заглушки і перевіряє лише частину умов у модулі. Він, звичайно, збирається повернутися і закінчити тестування розглянутого модуля пізніше, коли прибере заглушки. Такий план тестування безумовно не краще рішення, оскільки про відкладених умовах часто забувають.

Другий тонкий недолік низхідного підходу полягає в тому, що він може породити віру в можливість почати програмування і тестування верхнього рівня програми до того, як вся програма буде повністю спроектована. Ця ідея на перший погляд здається економічною, але зазвичай справа йде зовсім навпаки. Більшість досвідчених проектувальників визнає, що проектування програми - процес інтерактивний. Рідко перший проект виявляється досконалим. Нормальний стиль проектування структури програми передбачає після закінчення проектування нижніх рівнів повернутися назад і підправити верхній рівень, внісши до нього деякі вдосконалення чи виправляючи помилки, або іноді навіть викинути проект і розпочати все спочатку, тому що розробник раптово побачив кращий підхід. Якщо ж головна частина програми вже запрограмована і відтестовано, то виникає серйозний опір будь-яким поліпшень її структури. У кінцевому підсумку за рахунок таких поліпшень зазвичай можна заощадити більше, ніж ті кілька днів або тижнів, які розраховує виграти проектувальник, приступаючи до програмування занадто рано.

МОДИФІКОВАНИЙ спадний метод

Спадний підхід має ще один істотний недолік, що стосується повноти тестування. Припустимо, що є велика програма і десь ближче до нижнього її рівня перебуває модуль, призначений для обчислення коренів квадратного рівняння. Для заданих вхідних змінних А, В і С він вирішує рівняння .

При проектуванні і програмуванні модуля з такою функцією завжди слід розуміти, що квадратне рівняння може мати як дійсні, так і комплексні корені. Для повної реалізації цієї функції необхідно, щоб результати могли бути дійсними або комплексними числами (або, якщо додаткові витрати на знаходження комплексних коренів не виправдані, модуль повинен принаймні повертати код помилки у випадку, коли вхідні коефіцієнти задають рівняння з комплексними коренями). Припустимо, що конкретний контекст, в якому використовується модуль, виключає комплексні корені (тобто викликають модулі ніколи не задають вхідних параметрів, які призвели б до комплексних коренів). При строго низхідному методі іноді буває неможливо тестувати модуль для випадку комплексних коренів (або тестувати помилкові умови). Можна спробувати виправдовувати це тим, що, оскільки таке рівняння ніколи не буде дано модулю, нікого не повинно турбувати, чи працює він і в цих випадках. Так, це байдуже зараз, але виявиться важливим у майбутньому, коли хтось спробує використовувати модуль в новій програмі або модифіковані стару програму так, що стануть можливими і комплексні корені.

Ця проблема проявляється в різноманітних формах. Застосовуючи спадний тестування в точній відповідності з попереднім розділом, часто неможливо тестувати певні логічні умови, наприклад помилкові ситуації або захисні перевірки. Спадний метод, крім того, робить складною або взагалі неможливою перевірку виняткових ситуацій в деякому модулі, якщо програма працює з ним лише в обмеженому контексті (це означає, що модуль ніколи не отримає достатньо повний набір вхідних значень). Навіть якщо тестування такої ситуації в принципі можливо, часто буває важко визначити, які саме потрібні тести, якщо вони вводяться в точці програми, віддаленої від місця перевірки відповідної умови.

Метод, званий модифікованим низхідним підходом, вирішує ці проблеми: потрібно, щоб кожен модуль пройшов автономне тестування перед підключенням до програми. Хоча це дійсно вирішує всі перераховані проблеми, тут потрібні і драйвери, і заглушки для кожного модуля.

МЕТОД Великого стрибка.

Ймовірно, найпоширеніший підхід до інтеграції модулів - метод "великого стрибка". У відповідності з цим методом кожен модуль тестується автономно. Після закінчення тестування модулів вони інтегруються в систему всі відразу.

Метод великого стрибка в порівнянні з іншими підходами має багато недоліків і мало достоїнств. Заглушки і драйвери необхідні для кожного модуля. Модулі не інтегруються до самого останнього моменту, а це означає, що протягом довгого часу серйозні помилки в сполученнях можуть залишитися невиявленими. Метод великого стрибка значно ускладнює налагодження.

І все ж таки великий стрибок не завжди небажаний. Якщо програма мала і добре спроектована, він може виявитися прийнятним. Однак для великих програм метод великого стрибка зазвичай згубний.

МЕТОД САНДВІЧІ

Тестування методом сандвіча представляє собою компроміс між висхідним і спадним підходами. Тут робиться спроба скористатися перевагами обох методів, уникнувши їх недоліків.

При використанні цього методу одночасно починають висхідний і спадний тестування, збираючи програму як знизу, так і зверху і зустрічаючись в кінці кінців десь в середині. Точка зустрічі залежить від конкретної програми, що тестується і повинна бути заздалегідь визначена при вивченні її структури. Наприклад, якщо розробник може представити свою систему у вигляді рівня прикладних модулів, потім рівня модулів обробки запитів, потім рівня примітивних функцій, то він може вирішувати, чи застосовувати спадний метод на рівні прикладних модулів (програмуючи заглушки замість модулів обробки запитів), а на інших рівнях застосувати висхідний метод.

Застосування методу сандвіча - це розумний підхід до інтеграції великих програм, таких, як операційна система або пакет прикладних програм.

Метод сандвіча зберігає таку гідність низхідного і висхідного підходів, як початок інтеграції системи на самому ранньому етапі. Оскільки вершина програми стає до ладу рано, ми, як у низхідному методі, вже на ранньому етапі отримуємо працює каркас програми. Оскільки нижні рівні програми створюються висхідним методом, знімаються ті проблеми низхідного методу, які були пов'язані з неможливістю тестувати деякі умови в глибині програми.

МОДИФІКОВАНИЙ МЕТОД сандвіч.

При тестуванні методом сандвіча виникає та ж проблема, що і при низхідному підході, хоча тут вона коштує не так гостро. Проблема ця в тому, що неможливо досконально тестувати окремі модулі. Висхідний етап тестування за методом сандвіча вирішує цю проблему для модулів нижніх рівнів, але вона може як і раніше залишатися відкритою для нижньої половини верхньої частини програми. У модифікованому методі сандвіча нижні рівні також тестуються суворо знизу вгору. А модулі верхніх рівнів спочатку тестуються ізольовано, а потім збираються низхідним методом. Таким чином, модифікований метод сандвіча також представляє собою компроміс між висхідним і спадним підходами.

ПОРІВНЯЛЬНА ХАРАКТЕРИСТИКА МЕТОДІВ ТЕСТУВАННЯ.

З точки зору надійності програмного забезпечення ці стратегії можна оцінити за вісьмома критеріями, як показано на рис. 10.7. Перший критерій - час до моменту складання модулів, оскільки це важливо для виявлення помилок в сполученнях і припущеннях модулів про властивості один одного. Другий критерій - час до моменту створення перших працюючих "скелетних" версій програми, оскільки тут можуть проявитися головні дефекти проектування. Третій і четвертий критерії стосуються питання про те, чи необхідні заглушки, драйвери та інші інструменти тестування. П'ятий критерій-міра паралелізму, який можливий на початку або на ранніх стадіях тестування. Це цікаве питання, оскільки необхідність у ресурсах (тобто програмістів) зазвичай досягає піка на етапах проектування та програмування модулів.

Рис. 10.7. Кількісна оцінка підхід до складання.

Тому важливо, щоб можливість паралельного тестування з'явилася ближче до початку, а не кінця циклу тестування.

Шостий критерій пов'язаний з відповіддю на обговорювався раніше питання: чи можливо перевірити будь-який конкретний шлях і будь-яка умова у програмі? Сьомий критерій характеризує складність планування, нагляду і управління в процесі тестування. Це пов'язано з усвідомленням того факту, що тестування, яким важко керувати, часто веде до недогляд і упущень. Час від часу лунають заперечення проти низхідного підходу у зв'язку з тим, що тестування нижніх модулів вимагає багаторазових зайвих прогонів головних модулів. Однак цей критерій відзначений як несуттєвий. Хоча зайві прогони дійсно бувають необхідні, можливо також, що в багатьох випадках, які здаються зайвими, в дійсності відтворюються дещо різні умови. Ці прогони можуть розкрити нові помилки, перетворюючи таким чином недолік в гідність. Оскільки цей ефект недостатньо усвідомлений, ми їм нехтуємо.

Тепер оцінимо наші шість підходів за допомогою перерахованих восьми критеріїв. Як вже говорилося, така оцінка залежить від конкретного проекту. В якості вихідного наближення для виконання ваших власних оцінок наведено варіант дуже грубої оцінки. Перш за все слід зважити відносний вплив кожного з восьми критеріїв на надійність програмного забезпечення. Рання збірка і раннє отримання працюючого каркаса програми, а також можливість тестувати будь-які конкретні умови є найбільш важливими, тому їм дається коефіцієнт 3. Складність підготовки заглушок, а також складність планування і управління послідовністю тестів також важливі, тому вони отримують вага 2. Третій критерій, необхідність драйверів, вага 1 зважаючи на доступність загальних інструментів тестування. Критерій, пов'язаний з паралелізмом роботи, також має вагу 1, тому що, хоча він, може бути, і важливий з інших причин, на надійність сильно не впливає. Восьмий критерій отримує коефіцієнт нуль.

На рис. 10.8 показані результати цієї оцінки. У кожній графі таблиці вага береться зі знаком плюс або мінус або не враховується, в залежності від того, сприятливо, несприятливо або байдуже проявляється відповідний фактор при даному підході. Модифікований метод сандвіча і висхідний метод виявляються найкращими підходами, а метод великого стрибка-найгіршим. Якщо спосіб оцінки виявляється близьким до вашої конкретної ситуації, слід рекомендувати модифікований метод сандвіча для тестування великих систем або програм і висхідний підхід для тестування програм малих і середніх.

Рис. 10.8. Зважена оцінка підходів до складання.

III. ВИПРОБУВАННЯ ПРОГРАМНИХ ​​ПРОДУКТІВ (АНАЛІЗ).

МЕТА І ОСОБЛИВОСТІ ВИПРОБУВАННЯ.

Випробування є найважливішим елементом управління якістю продукції. Відповідно до ГОСТ 16504-81 під випробуванням промислової продукції розуміють експериментальне визначення кількісних та / або якісних характеристик об'єкта випробування як результату впливу на нього; при його функціонуванні; при моделюванні об'єкта та / або дії. Під випробуванням програмної продукції слід розуміти експериментальне визначення кількісних та / або якісних характеристик властивостей продукції при її функціонуванні в реальному середовищі та / або моделюванні середовища функціонування.

Метою випробування є експериментальне визначення фактичних (досягнутих) характеристик властивостей випробовується ПІ. Ці характеристики можуть бути як кількісними, так і якісними. Важливо, щоб на їх основі можна було зробити висновок про придатність даного ПІ до використання за своїм призначенням. Якщо висновок негативний, то зразок ПІ повертається на доопрацювання. Таким чином перекривається доступ недоброякісної продукції до користувача, Безпосередньо у ході випробувань якість ПІ може і не змінитися, тому що локалізація помилок не є метою випробування. Разом з тим деякі дефекти в програмах і документації можуть усуватися по ходу випробування.

Випробування є завершальним етапом розробки. Йому передує етап статичної та динамічної налагодження програм. Основним методом динамічної налагодження є тестування. У вузькому сенсі мета тестування полягає у виявленні помилок, мета ж налагодження-не тільки у виявленні, але верб усунення помилок. Проте обмежитися тільки налагодженням програми, якщо є впевненість в тому, що всі помилки в ній усунені, не можна. Цілі у налагодження та випробування різні. Повністю налагоджена програма може не володіти певними споживчими властивостями і тим самим бути непридатною до використання за своїм призначенням. Не може служити альтернативою випробуванню та перевірка працездатності програми на контрольному прикладі, так як програма, працездатна в умовах контрольного прикладу, може виявитися непрацездатною в інших умовах застосування. Спроби охопити контрольним прикладом всі передбачувані умови функціонування зводяться в кінцевому рахунку до тих же випробуванням.

Відповідно до ГОСТ 19,004-80 під випробуванням програм розуміють встановлення відповідності програми заданим вимогам і програмним документам. Це визначення побудовано на припущенні, що в технічному завданні на розробку програми визначені всі вимоги (характеристики), забезпечення яких гарантує придатність програми до використання за своїм призначенням. Але така вимога рідко дотримується на практиці. У деяких випадках, особливо в автоматизованих системах, ТЗ на ПС або взагалі не пишуть, або в них перераховує лише функції, які покладаються на ПС, без вказівки вимог до інших споживчими властивостями. При відсутності ТЗ на розробку ПС або повного і обгрунтованого переліку вимог до характеристик розроблюваного ПС завдання випробування ПС стає невизначеною і неконструктивною. Що значить встановити відповідність програми заданим вимогам, якщо ці вимоги формально не задані? Яка користь від встановлення такої відповідності, якщо ці вимоги свідомо "усічені" і не відображають основних споживчих властивостей програми? Користувачеві буде не легше, якщо програма функціонує погано, але це в явному вигляді не суперечить вимогам ТЗ.

За наявності в ТЗ необхідних характеристик основних споживчих властивостей ПІ наведені визначення терміна "випробування" за метою випробування практично збігаються. Однак і в цьому випадку перше визначення є більш конструктивним, тому що воно формулює не тільки мета, але й основний метод проведення випробування - перевірка ПІ, функціонуючого в реальній або моделюється, але близької до реальної середовищі,

У зарубіжній літературі, в тому числі в стандартах на програмне забезпечення, поняття "випробування" часто ототожнюють з поняттям "тестування". Наприклад, в Std IEEE 829-1983 "Документація тестів програмного забезпечення" (США) дано таке визначення тестування: "... процес активного аналізу ПЗ на предмет виявлення розбіжності між реальними і необхідними нормами ПЗ (тобто наявності помилок в програмах) та з метою оцінки характеристик елементів ПЗ ". Дане визначення об'єднує два наведені визначення терміна "випробування" з тією лише різницею, що при прийнятій (див. визначення) концепції пошук і локалізація помилок на є явно вираженими цілями випробування. З урахуванням висловлених міркувань термін "тестування", що використовується в зарубіжній літературі, будемо інтерпретувати як випробування методом тестування,

Тривалість випробування залежить від типу, конфігурації (складності) ПС, а також від цілей і ступеня автоматизації розглянутого технологічного процесу. При випробуванні операційних систем вона коливається від одного до шести місяців [20]. Складні програмні комплекси після інтеграції можуть випробовуватися й більш тривалий час.

Основними видами випробування ПП є попередні, приймальні та експлуатаційні випробування, включаючи дослідну експлуатацію. Особливості їх організації та проведення детально розглянуті в книзі [18].

Залежно від місця проведення розрізняють стендові та полігонні випробування. Під випробувальним стендом розуміють сукупність технічних пристроїв і математичних моделей, що забезпечують в автоматичному режимі імітацію середовища функціонування; надходження вхідних даних, які спотворюють впливу; реєстрацію інформації про функціонування ПС, а також управління процесом випробування і об'єктом випробування. Якщо в основу стендових випробувань покладено принцип моделювання, то відповідні випробувальні стенди називають моделюючими.

Випробувальним полігоном називають місце, призначене для випробувань в умовах, близьких до умов експлуатації, і забезпечене необхідними засобами випробування. Полігонних випробуванням піддають системи, що працюють в реальному масштабі часу. У полігонних умовах звичайно поєднують натурні випробування з використанням реальних об'єктів автоматизуються систем і моделювання деяких об'єктів і процесів їх функціонування. Останнім. Час в деяких розробляють організаціях створюють випробувальні полігони, що представляють собою сукупність спеціалізованих за профілем даної організації випробувальних стендів. Такі полігони мають загальну технічну та інформаційну бази, а також програмні засоби організації випробувань.

За ступенем залежності випробувачів від розробників розрізняють залежні і незалежні випробування. При залежних випробуваннях основні операції з випробовуються ПС (підготовка до роботи, підготовка і введення вихідних даних, реєстрація та аналіз результатів) виконують розробники програм. Оцінку результатів випробування проводить комісія при активній участі розробників. Незалежні випробування проводять спеціальні підрозділи, що не несуть відповідальності за розробку програм і безпосередньо не підпорядковані керівникам розробки.

ТЕХНОЛОГІЧНА СХЕМА ВИПРОБУВАННЯ.

Для підвищення ефективності випробування, його прискорення і здешевлення необхідно розробити науково обгрунтовані методи, засоби та методики, що дозволяють подолати недоліки підходу до випробування як до свого роду евристики, недооцінку його ролі в забезпеченні необхідного рівня якості ПП, підміну випробувань процедурами типу перевірки працездатності на контрольному прикладі і т. п. Ця мета може бути досягнута лише шляхом розробки технологічної схеми випробувань, передбачає;

знання призначення випробуваного ПС, умов його функціонування і вимог до нього з боку користувачів;

автоматизацію всіх найбільш трудомістких процесів і перш за все моделювання середовища функціонування, включаючи спотворюють впливу;

ясне уявлення мети і послідовності випробування;

цілеспрямованість і ненадлишковим випробування, що виключають або мінімізують повторення однорідних процедур при одних і тих же умовах функціонування випробуваного ПС;

систематичний контроль за ходом, регулярне ведення протоколу та журналу випробування;

чітке, послідовне визначення і виконання плану випробування;

чітке зіставлення наявних ресурсів з передбачуваним обсягом випробування;

можливість забезпечення, а також об'єктивної кількісної оцінки повноти та достовірності результатів випробування навсех етапах.

Будь-якого виду випробувань повинна передувати ретельна підготовка. У підготовку випробувань ПС входять наступні заходи:

складання та узгодження плану-графіка проведення випробування;

розробка, комплектування, випробування та паспортизація програмно-технічних засобів, що використовуються при випробуваннях;

аналіз придатності випробувальних засобів, використовуваних під час попередніх випробувань, для проведення приймальних випробувань;

аналіз придатності накопичених даних про якість ПС для використання при остаточному визначенні значень показників якості випробуваного ПС;

перевірка та погодження з представником Замовника конструкторської документації на ПС, пропонованому при випробуваннях;

розробка, узгодження та затвердження програм і методікіспитаній;

атестація фахівців на допуск до проведення випробувань;

приймання випробовується досвідченого зразка ПС на носії даних та документації;

проведення заходів, спрямованих на забезпечення достовірності випробувань.

Особливо слід підкреслити необхідність завчасної розробки та випробування всіх програмно-технічних засобів, які будуть використовуватися при проведенні випробувань. При цьому слід мати на увазі, що рівень точності і надійності вимірювальної апаратури, використовуваної при випробуваннях будь-якого об'єкта, повинен бути значно вище відповідних показовий об'єкту. Тому реальні характеристики програмно-технічних випробувальних засобів необхідно встановити заздалегідь, а їх прийнятність погоджувати між розробниками, випробувачами і замовниками ПС. Нехтування цим правилом викликає недовіру до результатів випробування і, як наслідок, подовження строків випробування.

Складність програмно-технічних випробувальних засобів, вимоги до їх досконалості, а отже, і витрати ресурсів на їх розробку прямо пропорційно залежать від відповідних показників випробовуваних ПС. Обсяг випробувальних програмних засобів, виражений в машинних командах, може досягати обсягу випробовуваних з їх допомогою програм. Тому розробка програмно-технічних засобів, призначених для випробування особливо складної ПП, повинна починатися одночасно з розробкою дослідних зразків продукції.

На підставі викладеного можна визначити наступні п'ять етапів випробування.

1. Обстеження проектованого ПС, аналіз проектної документації.

2. Визначення найбільш важливих підсистем, функцій і шляхів проектованого ПС, що підлягають випробуванню.

3. Аналіз показників якості ПС і методів визначення їх значень. Розробка програм і методик випробування.

4. Розробка (освоєння) випробувальних програмно-технічних засобів, бібліотек тестів і баз даних (якщо вони потрібні).

5. Безпосереднє проведення випробувань, аналіз результатів, прийняття рішення.

На рис. 16 зображена технологічна схема у вигляді етапів підготовки і проведення випробування та їх зв'язку з етапами розробки ПС.

Рис. 16. Технологічна схема випробування ПС.

У залежності від специфіки, умов застосування, вимог до якості випробовуваних ПС випробування можуть проводитися або шляхом тестування, або шляхом статистичного моделювання середовища функціонування, або на основі натурних і змішаних експериментів. Часто корисно використання всіх цих методів. Значення деяких показників якості можна отримати експертним шляхом.

ПЛАНУВАННЯ І ОЦІНКА завершення випробувань.

План проведення випробувань повинен бути орієнтований на забезпечення всебічної перевірки ПС та максимальної (заданою) достовірності отриманих результатів при використанні обмежених ресурсів, виділених на випробуваннях. Принципово можливі такі підходи до вирішення цього завдання:

1) аналізують весь діапазон вхідних даних. На основі аналізу заздалегідь готують таке безліч комбінацій даних (тестових наборів даних), яке охоплює найбільш характерні підмножини вхідних даних. Програму розглядають як чорний ящик. Випробування зводяться до послідовного введення тестових наборів даних і аналізу отриманих результатів;

2) аналізують безліч ситуацій, які можуть виникнути при функціонуванні ПС. Вибирають найбільш характерні ситуації. Кожну з них виражають через тестовий набір вхідних даних. Далі сутність випробування та аналізу результатів зводиться до підходу 1);

3) за допомогою графових моделі аналізують мікроструктуру ПС. Вибирають безліч шляхів, яке повністю покриває граф-схему ПС, і таку послідовність тестових наборів вихідних даних, виконання якої буде проходити по виділених шляхах. Організація випробувань аналогічна підходам 1) і2);

4) ПС випробовують у реальному середовищі функціонування;

5) ПС випробовують у статистично модельованої середовищі функціонування, адекватної реальної середовищі.

Жоден з цих підходів не є універсальним. Кожен з них має свої переваги і недоліки, які різною мірою виявляються в залежності від специфіки випробуваного ПС. Наприклад, підхід 1) може виявитися кращим, якщо діапазон вхідних даних Оглянувши, порівняно легко аналізується й систематизується, і неприйнятним - в іншому випадку. Найбільш достовірні результати виходять при випробуваннях в реальному середовищі функціонування. Але такі випробування рідко вдається здійснити. Тому на практиці використовують комбінації всіх видів. Типовим прикладом такої комбінації може служити змішаний метод, коли середовище функціонування ПС моделюється, а достовірність результатів перевіряється шляхом порівняння з результатами, отриманими при функціонуванні ПС в реальному середовищі.

Аналіз показує, що абсолютна перевірка ПС при жодному з розглянутих підходів не здійсненна. Тому при плануванні випробувань необхідно попередньо аналізувати структури випробовуваних програм та вхідних даних. Зокрема, слід встановлювати ті шляхи граф-схеми програми, використання яких при перетворенні даних найбільш ймовірно. Це завдання аналогічна підходам 1) і 2). Для складних програмних комплексів вона не має суворо математичного рішення. Разом з тим на практиці нерідко вдається заздалегідь установити найбільш ймовірні ситуації, які можуть виникнути в автоматизируемой системі, а отже, і набори вхідних даних, що описують ці ситуації.

Методика вирішення задачі планування випробування включає в себе наступні етапи: знаходження всіх шляхів реалізації;

виділення мінімальної підмножини шляхів, які забезпечують перевірку всіх ділянок програми; розробка тестів для перевірки виділених шляхів. Необхідно відзначити, що в результаті рішення отримують не одне підмножина шляхів, а деяку сукупність таких підмножин. Аналізуючи ці сукупності за критеріями мінімального часу реалізації їх на ЕОМ, вибору найбільш ймовірних шляхів, відсутності в цих сукупностях несумісних шляхів (розглянутим методам властивий цей недолік), вибирають найбільш прийнятну сукупність. Для формування вхідних даних тестування для кожного виділеного шляху реалізації становлять спеціальні таблиці. У таблицях представляють тільки умовні оператори, що належать даному шляху, і оператори, в яких обчислюються змінні управління. У результаті аналізу приписів, що задовольняють умовним операторам, виробляють вхідні дані тестування.

Для встановлення потреби в машинному часу на проведення випробувань необхідно знати середнє значення абсолютної реактивності ПС. Ця характеристика повинна бути задана в ТЗ. Якщо ж вона не задана, то можна прийняти де - Мінімальне значення абсолютної реактивності; - Максимальне значення абсолютної реактивності.

Незважаючи на те що перевірка всіх шляхів граф-схеми великої програми нездійсненна, при плануванні випробувань необхідно при заданих ресурсах забезпечити максимальну повноту перевірки, особливо перевірки модулів вирішення найбільш відповідальних завдань. Прагнення уникнути при цьому неефективного простого перебору приводить до задачі вибору мінімальної кількості шляхів, що покривають граф ПС. Під покриттям розуміють включення всіх дуг графа. Мінімальне покриття, з одного боку, забезпечує мінімум тестів і контрольних прорахунків, а, з іншого боку, гарантує проходження кожної дуги графа хоча б по одному разу.

Розглянутий метод планування на етапі автономних статистичних випробувань модулів ПІ дозволяє значно зменшити матеріальні і часові витрати на випробування програм. Орієнтація на той чи інший підхід до випробувань залежить від типу випробуваного ПС.

У загальному випадку при плануванні та організації випробувань слід шукати компромісне рішення, яке враховує два суперечливих вимоги: забезпечення максимальної достовірності узагальненої оцінки якості ПІ і виконання випробування в обмежений час з використанням обмежених ресурсів. Слід виділити три стадії випробування: підготовчу; безпосередні випробування; заключну (підготовка звітних матеріалів). Завдання цих стадій очевидні. Детальніше зупинимося на завданнях підготовчої стадії.

Ця стадія найбільш тривала і найбільш трудомістка. Основними її завданнями є: планування випробувань;

розробка технологічної схеми випробувань і випробувальних засобів; розробка програм і методик випробування; накопичення попередніх статистичних даних, які характеризують ПС.

Цілеспрямованість і чіткість організації робіт з накопичення статистичних даних може істотно підвищити достовірність оцінки якості ПС, виключити дубльовані (повторні) перевірки і зменшити терміни випробувань і витрачаються матеріальні ресурси. Однак у деяких випадках з-за поганої організації роботи результати тестування на етапах налагодження програм і попередніх випробуваннях не реєструються, тому не можуть використовуватися для остаточною. оцінки якості програми.

Між виділеними стадіями випробування ПС є прямі і зворотні зв'язки, аналогічні зв'язків між етапами життєвого циклу ПС. Це означає, що при виконанні робіт заключній стадії може бути виявлена ​​необхідність повернення до стадії безпосередніх випробувань (або навіть до підготовчої стадії) для уточнення окремих характеристик.

Складання плану проведення випробувань повинен передувати аналіз Т3 на розробку ПС, структурних та функціональних схем, режимів функціонування, залежностей між модулями програми, планів-графіків розробки та налагодження компонентів ПС, результатів контролю їх якості на ранніх стадіях розробки. У результаті цього аналізу необхідно розробити та обгрунтувати загальну стратегію випробування, а на її основі-комплекс документів з організації випробувань, який повинен містити відповіді на наступні питання: 1) завдання випробувань на кожній фазі, послідовність розвитку фаз; 2) використовуються спеціальні випробувальні кошти; 3) кількість необхідного машинного часу на кожній фазі випробувань; 4) конфігурація загального технічного та програмного забезпечення; 5) оцінювані властивості, критерії оцінки, способи їх отримання; 6) процедури контролю ходу випробування; 7) процедури реєстрації, збору, обробки та узагальнення результатів випробування; 8) умови (критерії) початку і завершення кожної фази випробувань. По кожному з цих питань необхідно визначити відповідальних виконавців, терміни виконання робіт, вид кінцевого результату.

У стандарті IEEE 829-1983 (США) велику увагу приділено документування процесу випробування ПП. Перелік документів, які розробляються і ведуться відповідно до плану випробування, наведено в розділі "Документування",

Проаналізувавши зміст виділених розділів плану випробування / тестування, можна зробити висновок про доцільність включення відомостей, що містяться в цих розділах, в програми і методики випробування ПС. Таке включення сприятиме підвищенню інформативності цих документів та впорядкування самого процесу випробувань.

На проведення випробувань ПП доводиться витрачати значні трудові та матеріальні ресурси. Терміни проведення випробувань завжди обмежені. Тому перед випробувачами завжди стоїть завдання пошуку шляхів мінімізації витрат матеріальних, трудових і часових ресурсів для досягнення мети випробування. Для реалізації цього завдання необхідно встановити критерії завершеності Випробувань, які можуть служити основою для ухвалення рішення про завершення випробувань.

При оцінці рівня завершеності випробувань ПС і достовірності отриманих результатів часто виникають серйозні труднощі. Відзначимо наступні з них:

1) більшість ПС є унікальними і або не мають аналогів для порівняння характеристик, або мають аналоги, характеристики яких невідомі;

2) відсутність загальноприйнятих показників, а також методів розрахунку необхідних та фактичних значень призводить до того, що в ТЗ на розробку ПС вимоги до характеристик ПС або фактично відсутні (у кількісному вираженні), або не претендують на повноту.

Розглянемо шляхи вирішення проблеми оцінки завершеності випробувань ПС. Але перш за все звернемо увагу на необхідність ретельного документування процесу випробування. Таке документування слід почати з моменту придбання ПС властивості працездатності і вести його безперервно до моменту передачі ПС в промислову експлуатацію.

Досвід створення вітчизняних систем реального часу підтверджує необхідність ведення одного або двох журналів. В одному з них слід реєструвати всі експерименти з ПС, а в іншому-виявлені помилки (проблеми) та хід їх усунення. Періодично складають звіти про випробування за певний період часу. Для ведення журналів необхідно ретельно розробити інструкції, в яких встановити загальні правила заповнення журналів, у тому числі єдині правила присвоєння реєстраційних номерів помилок, індексації типів помилок, класифікації помилок і т. п. У журналах слід передбачити окремі розділи, в яких при необхідності будуть даватися докладні коментарі до помилок і способи їх усунення.

Не всяку помилку можна швидко ідентифікувати, тому в стандарті IEEE 829-1983 рекомендовано документувати у вигляді звітів тест-інцидент все нестандартні події, що відбуваються під час випробування і вимагають додаткового аналізу. Рекомендується наступна структура цього звіту: ідентифікатор звіту тест-інцидент, анотація, опис інциденту, вплив інциденту на подальший хід випробування. Останні два розділи є основними. Опис інциденту має включати наступні елементи: вхідні дані, очікувані та фактичні результати, відхилення від норми, дата і час випробування, крок процедури випробування, середовище функціонування, результати спроб повторення умов експерименту, випробувачі, спостерігачі-реєстратори.

Реєстрація експериментів і помилок (інцидентів), періодична обробка даних і аналіз результатів дозволяють контролювати випробування і керувати цим процесом. Сама процедура реєстрації може бути різною, важливо лише запобігти втраті цінної інформації при мінімальних затратах на збір і обробку даних. Дана умова можна забезпечити тільки шляхом максимальної автоматизації всіх процесів.

Критерій інтенсивності виявлення помилок. Якщо вважати, що під час одного експерименту виявляється не більше однієї помилки і кожна помилка до початку наступного експерименту усувається, то можна припустити, що при сприятливому ході налагодження і випробування крива залежності: N = 1 - п / К, де п - кількість виявлених і усунених помилок; К. -. кількість експериментів, буде асимптотично прагнути до одиниці (крива 1 на рис. 17). Крива 2 свідчить про неблагополучний ході процесу.

Тоді як критерій припинення випробувань можна прийняти, наприклад, така умова: N> 0,95 при виявленні в останніх двісті експериментах не більше трьох несуттєвих помилок.

Ідея вибору такого критерію заснована на тому, що частота виявлення помилок, виражена відношенням п / К, у міру збільшення кількості експериментів повинна зменшуватися і до моменту завершення випробувань прийняти значення, близьке до нуля. Слід мати на увазі, що оцінка рівня завершеності випробувань за цим показником буде достовірною лише в тому випадку, якщо кожен експеримент проводиться в нових умовах і випробувачі прагнуть виявити помилки, а не довести їх відсутність. Якщо ж програму перевіряють при одних і тих же чи близьких умовах, то досить швидко отримують криву виду 1, яка не свідчить ні про повноту, ні про глибину перевірки програм, ні про відсутність в ній помилок.

Критерій заданого значення середнього напрацювання на відмову (критерій Дж. Д. Муса). Зроблено два припущення. 1. Сумарна кількість виявлених і усунених дефектів у про

грамі (під дефектом розуміється будь-яка причина незадоволеності властивостями програми) описується показовою функцією часу функціонування

- Вихідне кількість дефектів у програмі; - Загальна кількість дефектів, що може проявитися за час експлуатації ПС; - Середнє напрацювання на відмову на початку випробувань;

З-коефіцієнт стиснення тестів. Коефіцієнт С 1 тоді, коли абсолютна реактивність програми при прогоні тестів або статистичних дослідженнях відрізняється від абсолютної реактивності при роботі програми в реальних умовах. Якщо, наприклад, за одну годину випробувань моделюється керований процес, що відбувається в реальних умовах протягом десяти годин, то коефіцієнт стиснення З приймається рівним 10.

Швидкість виявлення та усунення дефектів, вимірювана щодо часу функціонування програми, пропорційна інтенсивності відмов. Коефіцієнт пропорційності B = n / m називається коефіцієнтом зменшення дефектів.

Кількість зареєстрованих відмов т залежить від сумарного часу функціонування програми таким чином:

Значення середнього напрацювання на відмову також залежить від сумарного часу функціонування:

Якщо в ході випробування виявлені помилки усуваються, то поточне значення середнього напрацювання на відмову буде збільшуватися. Таким чином, в якості критерію завершеності випробування можна прийняти досягнення необхідного (заданого) значення середнього напрацювання на відмову Tо. Тоді, визначаючи періодично поточне значення середнього напрацювання на відмову за цією формулою, можна при плануванні подальшого ходу випробування розрахувати час, необхідний для подальшого прогону програми за формулою

При плануванні налагодження та випробування ПЗ слід враховувати вплив наступних факторів: 1) швидкості виявлення дефектів; 2) швидкості усунення дефектів; 3) задоволеності машинним часом. Перший фактор залежить від укомплектованості і кваліфікації випробувачів, другий-від укомплектованості і кваліфікації групи програмістів отладчиков, третій - від фондоозброєності (технічної оснащеності) розробляє (відчуває) організації.

На початковій стадії налагодження програми інтенсивність виявлення дефектів висока. Програмісти-відладчики перевантажені роботою, доводиться навіть переривати тестові прогони, робити перерви у випробуваннях. На заключній стадії інтенсивність виявлення дефектів низька, але гостро відчувається необхідність у машинному часу. Випробувачі перевантажені у підготовці все нових і нових тестових вихідних даних, в той час як у програмістів-відладчиків роботи може бути мало.

СТЕНДИ Налагодження і ВИПРОБУВАННЯ ПРОГРАМ.

Ідея імітаційного моделювання покладена в основу створення комплексних імітаційно-моделюючих випробувальних стендів, що використовуються для налагодження та випробування складних систем управління в реальному масштабі часу.

Комплексний імітаційно-моделюючі випробувальний стенд (КІМІС) являє собою сукупність засобів випробуваної системи та їхніх моделей, моделі зовнішнього середовища і програм обробки результатів моделювання, функціонально об'єднаних на основі випробуваного програмного комплексу. Комплексні імітаційно-моделюючі випробувальні стенди використовуються при полігонних випробуваннях складних систем.

Загальна ідея створення КІМІС заснована на тому, що для випробування (дослідження) ПС, реалізованого безпосередньо на керуючої ЕОМ, необхідно моделювати керований процес і імітувати надходження в ЕОМ інформації про цей процес. Випробовуване ПС байдуже до безпосередніх джерел інформації. Важливо лише, щоб вся інформація була розподілена по реальним фізичних каналах ЕОМ і тимчасовим тактовим інтервалам, а також відповідала заданому (очікуваному) діапазону умов зовнішнього середовища. Сполучення моделей з реальними засобами системи необхідно для оцінки результатів моделювання шляхом їх порівняння з реальними даними. Використання в складі КІМІС безпосередньо самого ПС, а не його моделі, дозволяє отримати більш достовірні результати при моделюванні і уникнути великих додаткових трудовитрат на розробку моделі ПС.

Для створення КІМІС, крім основної ЕОМ, на якій реалізується випробовуване ПС, використовують ЕОМ приблизно такої ж продуктивності для реалізації комплексу моделей відповідного призначення. Першу ЕОМ (ВС) зазвичай називають технологічної, другу-інструментальної. Інструментальна ЕОМ та програмне забезпечення утворюють КІМІС. Такі КІМІС є кросової системою (КРОС-КІМІС). Модельований (імітуючі) на інструментальній ЕОМ дані передаються в технологічну ЕОМ, де і обробляються як реальні дані. Програмне забезпечення КІМІС може бути реалізовано і на технологічній ЕОМ (Резидент-КІМІС). Але такий варіант використовується порівняно рідко із-за дефіциту пам'яті і продуктивності в технологічних (керуючих) ЕОМ.

Автоматизований технологічний комплекс (АТК) складається з елементів наступних типів: керований технологічний агрегат (УТА), автоматизована система управління технологічним процесом (АСУ ТП), датчики інформації (ДІ) про стан керованого процесу. На вхід АТК надходить об'єкт обробки (00), на вихід-результат обробки (РО). Якщо припинити доступ інформації в ЕОМ від реальних фізичних об'єктів АТК, а замість неї вводити адекватну ін формацію, імітовану по КІМІС на інструментальній ЕОМ, то процес функціонування ПЗ АСУ ТП буде адекватний реальному. Оператор УТА в принципі може брати участь в обох режимах.

Програмне забезпечення КІМІС в загальному випадку складається з наступних підсистем: моделювання, аналізу результатів випробування, реєстрації подій (документування), планування та управління і бази даних (рис. 20). До складу підсистеми моделювання входять: модель заявок на обробку (МОЗ), модель об'єкта обробки (МГО); моделі датчиків інформації (МДІ); імітатор перешкод (ІП); модель керованого технологічного агрегату (МТА).

Модель заявок імітує потік заявок на обробку (наприклад, потік слябів) виходячи з планових та виробничих міркувань

Відповідно до заданим пріоритетом або випадковим чином вибирається 00, який приймає на обслуговування, із сукупності 00, імітованої МОЗ, і його характеристики. Моделі датчиків інформації є інформаційними моделями конкретних типів датчиків інформації, що використовуються в системі управління АТК. Вони імітують видачу поточних координат характеризують стан технологічного процесу. Модель керованого технологічного агрегату (наприклад, прокатного стану) імітує керований технологічний процес (наприклад, прокатки сталі) з видачею відповідної інформації про цей процес. Імітатор перешкод у відповідності з заданими імовірнісними характеристиками імітує вплив випадкових факторів на елементи модульованої системи і керований процес. При цьому використовується датчик випадкових чисел, який дозволяє реалізувати процедуру "розіграш".

Таким чином, підсистема моделювання, імітуючи технологічний процес в керованому агрегаті, забезпечує відтворення потоку вхідної інформації в ЕОМ, адекватного цього потоку в реальних умовах експлуатації АТК.

Імітованим потік вхідної інформації подається 'на вхід випробуваного ПЗ АСУ та ініціює його функціонування, результатом якого є потік вихідний (управлінської) інформації, що видається на УТА або його модель. Утворюється замкнутий контур управління, адекватний контуру керування в реальному ДТК.

Основними компонентами підсистеми аналізу результатів випробувань є: програма вибірки результатів перетворення вхідних даних, програми формування еталонних значень для аналізу правильності результатів, програма порівняння фактичних результатів з еталонними і оцінки їх прийнятності (правильності).

Підсистема реєстрації подій забезпечує документування ходу випробувань та реєстрацію всіх тих характеристик, які можуть бути корисні як для визначення значень показників якості випробуваного ПС, так і для оцінки ефективності та стану самого процесу випробувань.

Підсистема планування і управління на основі аналізу стану випробувань, отриманих результатів, перевірених шляхів граф-схеми випробуваного ПС і вступників завдань від програмістів-випробувачів здійснює планування експериментів та підготовку відповідних вихідних даних для підсистеми моделювання. На цю ж підсистему покладається координація дій (ініціалізація) всіх елементів КІМІС.

Переваги КІМІС очевидні. Його використання дозволяє здійснювати комплексну стиковку об'єктів випробуваної системи та перевірку принципів управління задовго до створення всіх елементів системи (елемент системи, розробка якого не завершена, замінюється моделлю). Застосування моделювання дозволяє урізноманітнити умови випробування і заощадити матеріальні ресурси. Комплексні випробувальні моделюючі стенди можна використовувати не тільки для випробування програм, але і для відпрацювання взаємодії всіх елементів системи.

Сполучення реальних коштів випробуваної системи з їх моделями дозволяє урізноманітнити умови випробування і провести напівнатурні експерименти. Можна, наприклад, перевірити роботу автоматизується технологічного агрегату, моделюючи поведінку об'єкта обробки або, навпаки, промоделювати роботу технологічного агрегату при роботі з реальним об'єктом обробки. Такі варіації дозволяють, з одного боку, перевіряти адекватність моделей своїм оригіналам і тим самим

переконуватися в достовірності результатів статистичних випробувань, а, з іншого боку, використовувати КІМІС на самих ранніх етапах розробки досвідченого зразка ПС для вибору й апробації найкращих проектних рішень.

IV. СЕРТИФІКАЦІЯ ПРОГРАМНИХ ​​ПРОДУКТІВ.

СТАНДАРТИЗАЦІЯ СИСТЕМ ЯКОСТІ.

На початку 70-х років багато фахівці прийшли до висновку про необхідність широкого розповсюдження індустріальних (інженерних) методів у галузі побудови програм (см, § 1.1). Індустріальні методи базуються на суворій регламентації й автоматизації технологічних процесів. Таким чином, стандартизація і в області побудови програм стала життєвою необхідністю.

У рамках Єдиної Системи Програмної Документації (ЕСПД) розроблено і введено в дію близько тридцяти стандартів, упорядковують розробку програмної документації. Багато видів стандартів для програмної продукції ще не розроблені (загальні технічні вимоги, загальні технічні умови, технічні умови на види ПП, номенклатура показників якості, методи виконання окремих видів робіт у технологічних процесах, порядок проведення цих робіт тощо).

При розробці ПМК системи КК ПП прийняті наступні вихідні положення:

1) розробка ПП здійснюється у відповідності з діючими стандартами, технічними умовами, ТЗ або іншими замінюють його документами, що містять вимоги до якості ПП, встановлені на підставі аналізу вимог конкретного і (або) потенційного користувача до споживчих властивостей даного виду ПП;

2) якість ПП забезпечується переважно в процесі його розробки; по завершенню кожного етапу розробки проекту повинен проводитися документований, систематичний і критичний аналізи результатів розробки;

3) за якість розроблюваної ПП відповідальність несе розробник, що поставляється - постачальник;

4) керівництво організації - розробника несе відповідальність за визначення політики у сфері якості і за рішення, що стосуються розробки, впровадження та ведення системи якості;

5) управління якістю ПП грунтується насамперед на стимулювання зацікавленості розробників і постачальників в забезпеченні високої якості ПП, підвищенні професіоналізму:

6) для забезпечення необхідної якості ПП управління якістю здійснюється на всіх стадіях і етапах життєвого циклу ПП, починаючи з самих ранніх;

7) у розробляє організації повинні бути визначені система якості (керуючі органи та особи, що несуть відповідальність за якість), а також політика в області якості ПП; відповідальність і повноваження за кожний вид діяльності, що впливає на якість ПП; визначення обов'язків і повноважень має забезпечувати досягнення поставлених цілей на заданому рівні ефективності;

8) управління якістю ПП базується на контролі якості в процесі розробки;

9) усі формалiзуються, функції, процедури та операції з управління якістю в кінцевому рахунку повинні бути передані ЕОМ і реалізовані на неї у вигляді інструментальних програм;

10) в ідейному (концептуальному) плані інструментальні програми і методики, що входять до складу ПМК, повинні представляти єдине ціле, яка узгоджується з прийнятою технологією програмування і що є складовою частиною цієї технології;

11) у складі ПМК підсистеми У К ПП можна виділити базову (умовно постійну) і змінну частини. Базова частина-ПМК розробляється як типове проектне рішення з використанням принципів модульної структури і може бути використана в різних організаціях, незалежно від відомчої приналежності і власної специфіки. Змінна частина-ПМК враховує специфіку розробляє організації, структури та завдань підсистеми КК ПП. Вона створюється в конкретній організації шляхом настройки базової частини ПМК та розробки нових, відсутніх частин підсистеми КК ПП;

12) всі компоненти базової частини ПМК повинні мати властивості автономності (незалежності) розробки, налаштування та застосування. Проте найбільший ефект повинен досягатися від комплексного використання всіх компонентів ПМК.

Основними методами стандартизації КК ПП в розробляє організації є: систематизація та класифікація: типізація і уніфікація; регламентування.

Систематизація і класифікація спрямовані на впорядкування елементів управління (ГКК, СКК та ін), встановлення їх прав і обов'язків, а також взаємодії між ними.

Типізація та уніфікація спрямовані на виявлення і формування схожих компонентів програм і програмних комплексів по профілю організації, па створення бібліотек уніфікованих компонентів, засобів генерації програм з цих компонентів, інтерфейсних угоді.

Регламентування спрямовано на впорядкування організаційних та технологічних процедур щодо забезпечення необхідного рівня якості на всіх стадіях життєвого циклу ПП.

У США, наприклад, в середині 80-х років введено в дію такі стандарти: ANSI / IEEE "Специфікація вимог до ПЗ" (Guide to Software Requirements Specifications); "Планування управління конфігурацією ПЗ" (Software Configuration Management Plans); "Документування тестів ПО "(Software Test Documentation);" Планування рівня якості ПО "(Software Quality Assurance Plan?). В якості проектів апробуються та інші стандарти, в тому числі "Довідник гарантії якості", "Класифікація відмов, збоїв і помилок ВО".

При організації управління якістю ПП багато корисні рекомендації можна запозичувати з відповідних стандартів з управління якістю промислової продукції.

У 1987 р. затверджено п'ять міжнародних стандартів ISO, що встановлюють вимоги до систем забезпечення якості продукції на підприємствах: "Стандарти з управління якістю та забезпечення якості. Керівництво для вибору і застосування "(ISO 9000);" Система якості. Моделі забезпечення якості при проектуванні, розробці, виробництві, монтажі й обслуговуванні "(ISO 900S);" Система якості. Моделі забезпечення якості при виробництві і монтажі "(ISO 9002);" Система якості. Моделі забезпечення якості в процесі контролю і випробування готової продукції "(ISO 9003);" Управління якістю та елементи системи якості. Основні напрямки "(ISO 9004).

КЛАСИФІКАЦІЯ ПОКАЗНИКІВ ЯКОСТІ

Під показником якості програмної продукції відповідно до ГОСТ 15467-79 слід розуміти кількісну характеристику одного або декількох властивостей продукції, які складають її якість, розглянуту відповідно до певних умов її створення та експлуатації. Властивість продукції - це об'єктивна особливість, яка може виявитися при створенні або експлуатації продукції. У визначенні поняття "Показник якості" слова "Кількісна характеристика" не слід розуміти в буквальному сенсі. При визначенні значень показників якості успішно можуть застосовуватися і нечислові характеристики, хоча в загальному випадку наявність строго кількісних, числових характеристик краще.

Показники якості програмної продукції в залежності від характеру вирішуваних завдань з оцінки якості продукції можна класифікувати за такими ознаками: характеризуються властивості; спосіб вираження; кількість характеризуються властивостей; місце застосування у процедурі оцінки; стадії визначення значень показників.

За способом вираження розрізняють показники, виражені в натуральних одиницях, і показники, виражені в вартісних одиницях. В якості натуральних одиниць зазвичай використовують одиниці фізичних величин (кілограми, метри, секунди і т. п.), а також бали і безрозмірні одиниці. ПС є інформаційними об'єктами. Якими-небудь власними фізичними властивостями вони не володіють, тому одиниці фізичних величин у традиційному вигляді при визначенні значень показників якості ПС майже не застосовуються, за винятком одиниць часу. Але як складовий елемент системи обробки даних ПС вносить певну частку похибки у точність вихідних результатів. Ця похибка може вимірюватися в одиницях перетворюваних фізичних величин. Разом з тим у програмуванні широко використовують такі натуральні одиниці, як біт, байт, умовна машинна команда, рядок тексту і т. п. Вартісні одиниці застосовують при визначенні значень економічних показників якості програмної продукції.

За кількістю характеризуються властивостей розрізняють одиничні і комплексні показники. Одиничні показники якості характеризують одну із властивостей ПС, комплексний-кілька. Комплексні показники можуть бути груповими, узагальненими або інтегральними.

У залежності від місця застосування у процедурі оцінки рівня якості ПС розрізняють базові і відносні показники. Базовим значенням показника якості продукції називають значення показника, прийняте за основу при порівняльній оцінці якості продукції. Відносне значення показника якості продукції являє собою відношення фактичного значення показника якості продукції, що оцінюється до базового значення цього показника.

За стадії визначення значень показників якості розрізняють прогнозовані, проектні, виробничі і експлуатаційні показники. Прогнозованими показниками оперують на стадіях виконання науково-дослідних робіт та складання ТЗ на розробку ПС, тобто на тих стадіях, коли немає ще жодного детального проекту ПС, ні, тим більше, самого ПС. Значення прогнозованих показників в основному визначають на основі інтуїції і досвіду аналогічних розробок, тому ці показники носять суб'єктивний характер.

Значення проектних показників визначають на основі аналізу проектів ПС (ескізного, технічного, робочого), а також шляхом випробування дослідного зразка ПС. Ці показники мають більш об'єктивний характер. Ступінь їх достовірності залежить від ефективності використовуваних інструментальних засобів аналізу і випробування.

Виробничі показники мало відрізняються від проектних, особливо якщо виготовлення ПС зводиться до простого копіювання. Якщо ж копіювання передують операції складання або генерації ПС, то виробничі показники якості таких ПС можуть істотно відрізнятися від проектних.

Значення експлуатаційних показників визначають за результатами промислової експлуатації ПС. При дотриманні певних правил збору та обробки даних про якість ПС в процесі експлуатації експлуатаційні показники дають найбільш об'єктивну і достовірну оцінку. Тільки за цими показниками можна зробити дійсну оцінку науково-технічного рівня і якості ПС.

ВИБІР НОМЕНКЛАТУРИ ПОКАЗНИКІВ ЯКОСТІ

Вибір номенклатури показників якості програмної продукції полягає у встановленні переліку найменувань характеристик властивостей продукції, які визначають якість даного виду продукції і забезпечують можливість повної і достовірної оцінки її рівня якості. Порядок вибору номенклатури показників якості програмної продукції повинен встановлюватися з урахуванням специфіки цієї продукції. Вибір номенклатури показників якості конкретного ПС залежить від виду (групи) ПС, цілі застосування і стадії визначення показників.

Для кожного виду (групи), а іноді і конкретного ПС встановлюють свою номенклатуру показників якості, що враховує специфіку призначення п умов застосування. Номенклатура показників якості для кожного підкласу, групи і виду ПС оформляється у вигляді таблиць застосованості показників якості. Крім переліку рекомендованих та обов'язкових показників якості для цього підкласу (виду, групи) ПС, в таблицях застосованості слід вказувати і коефіцієнти (параметри) вагомості (значимості) кожного з показників. Визначення коефіцієнтів вагомості показників якості - найбільш істотна і важке завдання вибору номенклатури показників якості. У принципі при вирішенні цього завдання можна використовувати або метод вартісно-регресійних залежностей, або метод граничних номінальних значень. Але їх використання ускладнене через відсутність необхідних вихідних даних. Тому на практиці найбільш поширений експертний метод визначення коефіцієнтів вагомості.

Таблиці застосованості є керівним або довідковим матеріалом для вибору робочої номенклатури показників якості конкретного ПС. Робоча номенклатура ПС встановлюється з урахуванням призначення та умов використання ПС; результатів аналізу вимог користувача (замовника), поставлених завдань управління якістю; складу, структури та специфіки характеризуються властивостей.

Цілі застосування номенклатури показовий якості встановлюють відповідно до завдань управління якістю програмної продукції. Такими цілями, зокрема, можуть бути наступні: складання технічного завдання па розробку ПС; складання технічних умови на ПС; заповнення карти технічного рівня; встановлення контрольованих показників при проектуванні ПС; встановлення контрольованих показників при дослідної експлуатації ПС; атестація ПС за категоріями якості.

Стадії визначення значенні показників якості відповідають стадіям життєвого циклу ПС.

При виділенні властивостей і відповідних показників якості ПС необхідно керуватися такими основними принципами:

виділення груп властивостей має проводитися за чітко визначеними ознаками;

властивості, що входять в одну групу, повинні, як правило, взаємно виключати один одного і бути незалежними. Якщо властивості залежать один від одного, то в методиках визначення значенні показників якості повинні бути дані чіткі вказівки по виключенню багаторазового (неодноразового) впливу одного і того ж властивості на узагальнену оцінку якості ПС;

всяка вихідна номенклатура показників повинна бути відкритою, тобто повинна допускати можливість внесення мені виключення з неї окремих елементів. Це вимога обумовлена, з одного боку, недостатнім досвідом оцінки якості програмної продукції, а з іншого,-великою різноманітністю ПС та умов їх застосування;

для кожного з виділених властивостей повинна існувати можливість вираження їх у шкалах "краще - гірше", "більше - менше";

в групу слід включати властивості, необхідні і достатні для визначення відповідного складного властивості;

формулювання властивостей повинна бути однозначною;

сукупність властивостей, які характеризують якість оцінюваного ПС, повинна бути впорядкована за певним правилом у вигляді багаторівневої ієрархічної структури - дерева властивостей;

дерево властивостей має відображати всі основні особливості використання н функціонування ПС;

вибрані показники якості повинні бути скоррелнрованни з відповідними властивостями ПС. Це означає, що між кожним з виділених властивостей і характеризують його показниками повинно бути встановлено однозначна відповідність. Встановлення такої відповідності дозволяє замість дерева властивостей використовувати дерево показників якості програмної продукції;

показники якості, що характеризують властивості ПС, мають сприяти забезпеченню відповідності якості ПС вимогам з боку їх користувачів та враховувати сучасні досягнення науки і техніки. Для виконання цього принципу часто необхідно проводити спеціальні дослідження, так як в загальному випадку між показниками якості можуть виникати серйозні суперечності, а поліпшення одного показника може призвести до погіршення іншого.

Для перевірки працездатності вибраної системи показників якості необхідно встановлювати ступінь кореляції кожного розглянутого показника з якістю ПС, корисність показника, можливість кількісного уявлення і автоматичної оцінки показника. Зокрема, оцінку корисності кожного з обраних показників для конкретних ПС рекомендується проводити за наступною шкалою:

5-вкрай важливо, щоб цей показник мав високе значення;

4-важливо, щоб цей показник мав високе значення;

3-добре б мати високе значення цього показника;

2 - в деякій мірі корисно мати високе значення цього показника;

1-при низьких значеннях цього показника відчутних втрат немає,

Близько 50% приватних показників можна визначити автоматично за допомогою ЕОМ, 25%-за допомогою компаратора. Таким чином, оцінка близько 75% показників може бути формалізована. Оцінка 20% показників може бути проведена тільки кваліфікованим фахівцем. Більшість показників встановлюють шляхом статичного аналізу програм і лише близько 5% - в процесі динамічних випробувань (Дані відповідають положенню в цій області в 80-ті роки).

Слід мати на увазі, що оцінка якості, а отже, до вибір показників якості складних багатофункціональних програмних комплексів типу операційних систем, систем управління базами даних, пакетів прикладних програм і так далі має свої особливості. Кожна функція таких ПС реалізується програмним шляхом, що задає певний технологічний процес перетворення вхідних даних у вихідні. Відомі мета цього процесу і потреба в ньому, Для того щоб задовольнити цю потребу, ПС повинна мати певні властивості. Причому властивості ПС, що задовольняють потреби в одній функції, можуть істотно відрізнятися від властивостей ПС, необхідних для реалізації іншої функції. Тому ступінь задоволення потреби у виконанні кожної з функцій ПС в загальному випадку характеризується своїми показниками або, принаймні, параметрами вагомості показників. Виникає необхідність вибору показників і визначення їх вагомості для оцінки якості (ефективності) реалізації кожної з основних функцій ПС. Спроба вибору єдиної номенклатури показників якості виявляється, як правило, безрезультатною. У цьому можна легко переконатися на прикладі оцінки якості операційних систем (ОС) ЕОМ. На ОС ЕОМ покладаються такі функції: управління даними, завданнями, введенням-висновком; обслуговування бібліотек користувачів;

трансляція та редагування програм; протоколювання станів і подій; перезапис і сортування інформації та ін Очевидно, що вимоги, наприклад, до транслятора істотно відрізняються від вимог до ПС протоколювання подій як за своїм переліком, так і за вагомістю кожного з показників. У свою чергу відмінність вимог обумовлює необхідність використання різних показників якості, що характеризують споживчі властивості програм, що реалізують ці функції.

ГРУПИ ПОКАЗНИКІВ ЯКОСТІ

Будь-якому класу продукції притаманні певні властивості, характерні для даного класу. У свою чергу кожен підклас, група, вид цієї продукції має приватні властивості, що відрізняють вироби однієї класифікаційної угруповання від іншої. Розглянемо формування номенклатури показників якості, що характеризує загальні властивості класу програмної продукції. Ця номенклатура може бути використана в якості вихідної при виборі робочого номенклатури показників якості будь-якого конкретного ПС.

Номенклатури показників якості завжди мають ієрархічну структуру. Їх формування починається з виділення груп верхнього рівня ієрархії, а потім номенклатури деталізуються аж до отримання одиничних показників.

Виділення груп показників якості є важливим і складним завданням формування номенклатури показників якості. Невдале комплектування груп може призвести до ускладнення взаємозв'язків між групами та окремими показниками, а також зробити номенклатуру показників якості малоконструктивний.

Відомо, що для оцінки якості промислової продукції використовують такі групи показників: призначення; економічного використання сировини, матеріалів, палива, енергії; надійності; ергономічності; естетичності; технологічності; патентно-правові; уніфікації та стандартизації; екологічності; безпеки.

Всі ці показники можна використовувати і при оцінці якості ПП. По в силу особливостей ПП деякі групи показників при оцінці її якості застосовувати недоцільно (неконструктивно). До таких показників відносять показники екологічності, безпеки.

Екологічні показники і показники безпеки нехарактерні для ПП, оскільки програмні вироби безпосередньо не можуть надавати шкідливих впливів на навколишнє середовище, ні на здоров'я людини. У принципі, такі дії можливі в тих випадках, коли ПІ використовують як елементи керуючих об'єктів, наприклад в АСУ. У цьому випадку виробляються ЕОМ за певним алгоритмом управляючі дії можуть викликати і несприятливі екологічні наслідки, і бути небезпечними для людини. Але це вже опосередкований вплив через керівні органи та виконавчі механізми автоматизованих технологічних комплексів (АТК). Вони враховуються як відповідні показники AT К.

Патентно-правові показники програмної продукції не можуть бути використані до тих пір, поки питання патентно-правового захисту цієї продукції не будуть вирішені в законодавчому (юридичному) плані.

Щодо надійності програмної продукції існує багато суперечливих думок. Разом з тим більшість фахівців одностайні в думці про те, що природа надійності програмних і технічних засобів різна. Для програмної продукції малопродуктивними є такі показники надійності, як довговічність, збереженість, ремонтопридатність. Джерелами низької надійності ПС в основному є помилки в програмах, внесені на стадії проектування і невиявлені при налагодженні і випробуваннях. Заслуговує на увагу думка американського фахівця Фокса Д., який вважає, що використання терміну "надійність програмного забезпечення" завдає шкоди, так як сприяє неправильного розуміння природи програмного забезпечення. Разом з тим слід враховувати той факт, що при аналізі деяких властивостей ПП, що виявляються при її функціонуванні, доводиться користуватися категоріями надійності (працездатність, відмова, збій, відновлення та ін.) Тому в номенклатурі показників якості ПП визнано за доцільне виділяти в окрему групу показники, що характеризують властивості ПП, близькі за своїми зовнішніми проявами показниками надійності апаратури. Ця група названа показниками надійності функціонування.

Таким чином, в базовій номенклатурі показників якості ПП на верхньому рівні виділяємо наступні показники: призначення, надійності функціонування, ергономічності, технологічності, уніфікації і стандартизації. Якість ПП в основному формується в процесі створення продукції і значною мірою залежить від ефективності структурних (конструктивних) рішень. Тому на цьому ж рівні в окрему групу виділимо структурні показники.

Показники призначення, надійності функціонування, ергономічності і технологічності характеризують властивості ПП, які проявляються в процесі її використання (експлуатації). За цією ознакою їх можна вважати експлуатаційними. Структурні показники і показники уніфікації і стандартизації характеризують властивості структури (конструкції) ПС, їх можна об'єднати в одну групу конструктивних показників. По відношенню до групи експлуатаційних показників ця група носить допоміжний характер. Досягнення певного рівня значень цих показників не може служити самоціллю, це лише засіб (шлях) забезпечення необхідних значень одного або декількох показників, що відносяться до основної групи - групи експлуатаційних показників.