Метою даного курсу є виклад комплексного погляду на процес верифікації програмного забезпечення. Предметом обговорення є різні підходи та методи, що застосовуються в галузі верифікації та, зокрема, тестування програмного забезпечення. Передбачається, що програмне забезпечення, що розробляється, є частиною більш загальної системи. Подібна система включає апаратні, інформаційні та організаційні (людина-користувач, людина-оператор тощо) компоненти, які розробляються, можливо, різними колективами. Тому необхідні документи розробки, що визначають вимоги до різних компонентів системи та правила їхньої взаємодії. Крім того, передбачається, що відмови системи можуть призводити до наслідків тієї чи іншої тяжкості, тому при розробці програмного забезпечення необхідні та виправдані зусилля, витрачені на виявлення прихованих дефектів. Насамперед, це стосується засобів та процедур верифікації програмного забезпечення. До складу курсу входить ряд практичних занять, що ілюструють на прикладі простої системи прийоми та методи верифікації програмного забезпечення серед Microsoft Visual Studio 2005 Team Edition for Software Testers. Ця публікація входить до складу "Бібліотеки навчальних курсів", формування якої ведеться у рамках програми академічної співпраці MSDN Academic Alliance (MSDN AA).

Наведений нижче текст отримано шляхом автоматичного вилучення з оригінального PDF-документа та призначено для попереднього перегляду.
Зображення (картинки, формули, графіки) відсутні.

Мал. 7 Тестування, верифікація та валідація Верифікація програмного забезпечення – загальне поняття, ніж тестування. Метою верифікації є досягнення гарантії того, що об'єкт, що верифікується (вимоги або програмний код) відповідає вимогам, реалізований без непередбачених функцій і задовольняє проектним специфікаціям і стандартам. Процес верифікації включає інспекції, тестування коду, аналіз результатів тестування, формування та аналіз звітів про проблеми. Таким чином, прийнято вважати, що процес тестування є складовою процесу верифікації, таке ж припущення зроблено і в даному навчальному курсі. Валідація програмної системи – процес, метою якого є доказ того, що в результаті розробки системи ми досягли тих цілей, яких планували досягти завдяки використанню. Інакше кажучи, валідація – це перевірка відповідності системи очікуванням замовника. Питання, пов'язані з валідацією виходять за рамки даного навчального курсу і є окремою цікавою темою для вивчення. Якщо подивитися на ці три процеси з погляду питання, на яке вони дають відповідь, то тестування відповідає на запитання «Як це зроблено?» або «Чи відповідає поведінка розробленої програми вимогам?», верифікація – «Що зроблено?» або «Чи відповідає розроблена система вимогам?», а валідація – «Чи зроблено те, що потрібно?» або «Чи відповідає розроблена система очікуванням замовника?». 1.7. Документація, створювана різних етапах життєвого циклу Синхронізація всіх етапів розробки відбувається з допомогою документів, створених кожному з етапів. Документація у своїй створюється і прямому відрізку життєвого циклу – розробки програмної системи, і зворотному – під час її верифікації. Спробуємо з прикладу V-образного життєвого циклу простежити, які типи документів створюються кожному з відрізків, і які взаємозв'язку з-поміж них існують (Рис. 8). Результатом етапу розробки вимог до системи є сформульовані вимоги до системи – документ, що описує загальні принципи роботи системи, її взаємодію з «довкіллям» - користувачами системи, а також програмними та апаратними засобами, що забезпечують її роботу. Зазвичай паралельно із вимогами до системи створюється план верифікації та визначається стратегія верифікації. Ці документи визначають загальний підхід до того, як виконуватиметься тестування, які методики будуть застосовуватися, які аспекти майбутньої системи повинні бути ретельно перевірені. Ще одне завдання, яке вирішується за допомогою визначення стратегії верифікації – визначення місця різних верифікаційних процесів та їх зв'язків із процесами розробки. 20 Верифікаційний процес, що працює із системними вимогами – це процес валідації вимог, зіставлення їх реальним очікуванням замовника. Забігаючи вперед, скажемо, що процес валідації відрізняється від приймально-здавальних випробувань, що виконуються при передачі готової системи замовнику, хоча може вважатися частиною таких випробувань. Валідація є засобом довести як коректність реалізації системи з погляду замовника, а й коректність принципів, покладених основою її розробки. Мал. 8 Процеси та документи при розробці програмних систем Вимоги до системи є основою процесу розробки функціональних вимог та архітектури проекту. У ході цього процесу розробляються загальні вимоги до програмного забезпечення системи, до функцій, які вона повинна виконувати. Функціональні вимоги часто включають визначення моделей поведінки системи в штатних і позаштатних ситуаціях, правила обробки даних і визначення інтерфейсу з користувачем. Текст вимоги, як правило, включає слова «повинна, повинен» і має структуру виду «У разі, якщо значення температури на датчику ABC досягає 30 і вище градусів Цельсія, система повинна припиняти видачу звукового сигналу». Функціональні вимоги є основою розробки архітектури системи – описи її структури термінах підсистем і структурних одиниць мови, у якому проводиться реалізація – областей, класів, модулів, функцій тощо. На базі функціональних вимог пишуться тест-вимоги – документи, що містять визначення ключових точок, які мають бути перевірені для того, щоб переконатись у коректності реалізації функціональних вимог. Часто тест-вимоги починаються словами «Перевірити, що» і містять посилання на відповідні функціональні вимоги. Прикладом тест-вимог для наведеної вище функціональної вимоги можуть бути «Перевірити, що у разі падіння температури на датчику ABC нижче 30 градусів Цельсія система видає попереджувальний звуковий сигнал» і «Перевірити, що у разі коли значення температури на датчику ABC вище 30 градусів Цельсія , система не видає звукового сигналу». 21 Одна з проблем, що виникають при написанні тест-вимог – принципова нетестованість деяких вимог, наприклад, вимогу «Інтерфейс користувача повинен бути інтуїтивно зрозумілим» неможливо перевірити без чіткого визначення того, що є інтуїтивно зрозумілим інтерфейсом. Такі неконкретні функціональні вимоги зазвичай згодом змінюють. Архітектурні особливості системи також можуть бути джерелом до створення тест-вимог, враховують особливості програмної реалізації системи. Прикладом такої вимоги є, наприклад, "Перевірити, що значення температури на датчику ABC не виходить за 255". На основі функціональних вимог та архітектури пишеться програмний код системи, для його перевірки на основі тест-вимог готується тест-план – опис послідовності тестових прикладів, що виконують перевірку відповідності реалізації системи вимогам. Кожен тестовий приклад містить конкретний опис значень, що подаються на вхід системи, значень, які очікуються на виході та опис сценарію виконання тесту. Залежно від об'єкта тестування тест-план може готуватися або у вигляді програми будь-якою мовою програмування, або у вигляді вхідного файлу даних для інструментарію, що виконує тестовану систему і передає їй значення, зазначені в тест-плані, або у вигляді інструкцій для користувача системи, що описує необхідні дії, які необхідно виконати для перевірки різних функцій системи. В результаті виконання всіх тестових прикладів збирається статистика про успішність проходження тестування – відсоток тестових прикладів, для яких реальні вихідні значення збіглися з очікуваними так званих пройдених тестів. Не пройдені тести є вихідними даними для аналізу причин помилок та подальшого їх виправлення. На етапі інтеграції здійснюється складання окремих модулів системи в єдине ціле та виконання тестових прикладів, що перевіряють всю функціональність системи. На останньому етапі здійснюється постачання готової системи замовнику. Перед впровадженням фахівці замовника спільно з розробниками проводять приймально-здачувальні випробування – виконують перевірку критичних для користувача функцій згідно із заздалегідь затвердженою програмою випробувань. При успішному проходженні випробувань система передається замовнику, інакше відправляється на доопрацювання. 1.8. Типи процесів тестування та верифікації та їх місце у різних моделях життєвого циклу 1.8.1. Модульне тестування Модульному тестуванню піддаються невеликі модулі (процедури, класи тощо). При тестуванні відносного невеликого модуля розміром 100-1000 рядків є можливість перевірити, якщо не всі, то принаймні багато логічних гілок у реалізації, різні шляхи в графі залежності даних, граничні значення параметрів. Відповідно до цього будуються критерії тестового покриття (покриті всі оператори, всі логічні гілки, усі граничні точки тощо). . Модульне тестування зазвичай виконується кожного незалежного програмного модуля і є, мабуть, найбільш поширеним видом тестування, особливо для систем малих і середніх розмірів. 1.8.2. Інтеграційне тестування Перевірка коректності всіх модулів, на жаль, не гарантує коректності функціонування системи модулів. У літературі іноді розглядається 22 «класична» модель неправильної організації тестування системи модулів, яка часто називається методом «великого стрибка». Суть методу у тому, щоб спочатку відтестувати кожен модуль окремо, потім об'єднати в систему і протестувати систему цілком. Для великих систем це неможливо. За такого підходу буде витрачено дуже багато часу на локалізацію помилок, а якість тестування залишиться невисокою. Альтернатива "великому стрибку" - інтеграційне тестування, коли система будується поетапно, групи модулів додаються поступово. 1.8.3. Системне тестування Повністю реалізований програмний продукт піддається системному тестуванню. На даному етапі тестувальника цікавить не коректність реалізації окремих процедур та методів, а вся програма загалом, як її бачить кінцевий користувач. Основою для тестів служать загальні вимоги до програми, включаючи як коректність реалізації функцій, а й продуктивність, час відгуку, стійкість до збоїв, атак, помилок користувача тощо. Для системного та компонентного тестування використовуються специфічні види критеріїв тестового покриття (наприклад, чи покриті всі типові сценарії роботи, всі сценарії з позаштатними ситуаціями, попарні композиції сценаріїв та ін.). 1.8.4. Навантажувальне тестування Навантажувальне тестування дозволяє не тільки отримувати прогнозовані дані про продуктивність системи під навантаженням, яка орієнтована на прийняття архітектурних рішень, але й надає робочу інформацію службам технічної підтримки, а також менеджерам проектів та менеджерам конфігурації, які відповідають за створення найбільш продуктивних конфігурацій обладнання та ПЗ . Навантажувальне тестування дозволяє команді розробки, приймати обгрунтовані рішення, створені задля вироблення оптимальних архітектурних композицій. Замовник зі свого боку отримує можливість проводити приймально-здавальні випробування в умовах наближених до реальних. 1.8.5. Формальні інспекції Формальна інспекція є одним із способів верифікації документів та програмного коду, створюваних у процесі розробки програмного забезпечення. У ході формальної інспекції групою фахівців здійснюється незалежна перевірка відповідності документів, що інспектуються, вихідним документам. Незалежність перевірки забезпечується тим, що вона здійснюється інспекторами, які не брали участь у розробці документа, що інспектується. 1.9. Верифікація програмного забезпечення, що сертифікується Дамо кілька визначень, що визначають загальну структуру процесу сертифікації програмного забезпечення: Сертифікація ПЗ – процес встановлення та офіційного визнання того, що розробка ПЗ проводилася відповідно до певних вимог. У процесі сертифікації відбувається взаємодія Заявника, Сертифікуючого органу та Наглядового органу Заявник - організація, яка подає заявку до відповідного Сертифікуючого органу на отримання сертифікату (відповідності, якості, придатності тощо) виробу. Сертифікуючий орган – організація, яка розглядає заявку Заявника про проведення Сертифікації ПЗ та або самостійно, або шляхом формування спеціальної комісії, яка проводить набір процедур спрямованих на проведення процесу Сертифікації ПЗ Заявника. 23 Наглядовий орган – комісія фахівців, які спостерігають за процесами розробки Заявником інформаційної системи, що сертифікується, і дають висновок про відповідність цього процесу певним вимогам, що передається на розгляд до Сертифікуючого органу. Сертифікація може бути спрямована на отримання сертифіката відповідності або сертифіката якості. У першому випадку результатом сертифікації є визнання відповідності процесів розробки певним критеріям, а функціональність системи певним вимогам. Прикладом таких вимог можуть бути керівні документи Федеральної служби з технічного та експортного контролю у сфері безпеки програмних систем. У другому випадку результатом є визнання відповідності процесів розробки певним критеріям, що гарантують відповідний рівень якості продукції та її придатності для експлуатації в певних умовах. Прикладом таких стандартів може бути серія міжнародних стандартів якості ISO 9000:2000 (ГОСТ Р ISO 9000-2001) або авіаційні стандарти DO-178B, AS9100, AS9006. Тестування програмного забезпечення, що сертифікується, має дві взаємодоповнюючі цілі: Перша мета - продемонструвати, що програмне забезпечення задовольняє вимогам на нього. Друга мета – продемонструвати з високим рівнем довірливості, що помилки, які можуть призвести до неприйнятних відмовних ситуацій, як вони визначені процесом, оцінки відмовобезпеки системи, виявлені у процесі тестування. Наприклад, згідно з вимогами стандарту DO-178B, для того, щоб задовольнити цілі тестування програмного забезпечення, необхідно наступне: Тести, в першу чергу, повинні ґрунтуватися на вимогах до програмного забезпечення; Тести повинні розроблятися для перевірки правильності функціонування та створення умов виявлення потенційних помилок. Аналіз повноти тестів, що ґрунтуються на вимогах на програмне забезпечення, повинен визначити, які вимоги не протестовані. Аналіз повноти тестів, заснованих на структурі програмного коду, має визначити, які структури не виконувались під час тестування. Також у цьому стандарті йдеться про тестування, що ґрунтується на вимогах. Встановлено, що ця стратегія є найбільш ефективною при виявленні помилок. Керівні вказівки для вибору тестових прикладів, що ґрунтуються на вимогах, включають наступне: Для досягнення цілей тестування програмного забезпечення повинні бути проведені дві категорії тестів: тести для нормальних ситуацій та тести для ненормальних (не відображених у вимогах, робастних) ситуацій. Повинні бути розроблені спеціальні тестові приклади для вимог до програмного забезпечення та джерел помилок, властивих процесу розробки програмного забезпечення. Метою тестів для нормальних ситуацій є демонстрація здатності програмного забезпечення давати відгук на нормальні входи та умови відповідно до вимог. 24 Метою тестів для ненормальних ситуацій є демонстрація здатності програмного забезпечення адекватно реагувати на ненормальні входи та умови, інакше кажучи, це не повинно викликати відмову системи. Категорії відмовних ситуацій для системи встановлюються шляхом визначення небезпеки відмовної ситуації для літака та тих, хто перебуває в ньому. Будь-яка помилка в програмному забезпеченні може викликати відмову, яка зробить свій внесок у відмовну ситуацію. Таким чином, рівень цілісності програмного забезпечення, необхідний для безпечної експлуатації, пов'язаний із відмовними ситуаціями для системи. Існує 5 рівнів відмовних ситуацій від несуттєвої до критично небезпечної. Відповідно до цих рівнів запроваджується поняття рівня критичності програмного забезпечення. Від рівня критичності залежить склад документації, що надається в орган, що сертифікує, а значить і глибина процесів розробки та верифікації системи. Наприклад, кількість типів документів та обсяг робіт з розробки системи, необхідних для сертифікації за найнижчим рівнем критичності DO-178B, можуть відрізнятися на один-два порядки від кількості та обсягів, необхідних для сертифікації за найвищим рівнем. Конкретні вимоги визначає стандарт, яким планується вести сертифікацію. 25 ТЕМА 2. Тестування програмного коду (лекції 2-5) 2.1. Завдання та цілі тестування програмного коду Тестування програмного коду – процес виконання програмного коду, спрямований на виявлення дефектів, що в ньому існують. Під дефектом тут розуміється ділянку програмного коду, виконання якого за певних умов призводить до несподіваної поведінки системи (тобто поведінки, яка не відповідає вимогам). Несподівана поведінка системи може призводити до збоїв у її роботі та відмови, у цьому випадку говорять про суттєві дефекти програмного коду. Деякі дефекти викликають незначні проблеми, що не порушують процес функціонування системи, але дещо ускладнюють роботу з нею. У цьому випадку говорять про середні або малозначні дефекти. Завдання тестування за такого підходу – визначення умов, у яких виявляються дефекти системи та протоколювання цих умов. Завдання тестування зазвичай не входить виявлення конкретних дефектних ділянок програмного коду і ніколи не входить виправлення дефектів – це завдання налагодження, яке виконується за результатами тестування системи. Мета застосування процедури тестування програмного коду – мінімізація кількості дефектів, особливо суттєвих, у кінцевому продукті. Тестування саме не може гарантувати повної відсутності дефектів у програмному коді системи. Однак, у поєднанні з процесами верифікації та валідації, спрямованими на усунення суперечливості та неповноти проектної документації (зокрема – вимог на систему), грамотно організоване тестування дає гарантію того, що система задовольняє вимогам та поводиться відповідно до них у всіх передбачених ситуаціях. При розробці систем підвищеної надійності, наприклад, авіаційних, гарантії надійності досягаються за допомогою чіткої організації процесу тестування, визначення зв'язку з іншими процесами життєвого циклу, введення кількісних характеристик, що дозволяють оцінювати успішність тестування. При цьому, що вищі вимоги до надійності системи (її рівень критичності), то жорсткіші вимоги пред'являються. Таким чином, насамперед ми розглядаємо не конкретні результати тестування конкретної системи, а загальну організацію процесу тестування, використовуючи підхід «добре організований процес дає якісний результат». Такий підхід є загальним для багатьох міжнародних та галузевих стандартів якості, про які докладніше буде розказано наприкінці цього курсу. Якість системи, що розробляється при такому підході є наслідком організованого процесу розробки та тестування, а не самостійним некерованим результатом. Оскільки сучасні програмні системи мають дуже значні розміри, під час тестування їхнього програмного коду використовується метод функціональної декомпозиції. Система розбивається на окремі модулі (класи, простори імен тощо), що мають певну вимогу функціональність та інтерфейси. Після цього окремо тестується кожен модуль – виконується модульне тестування. Потім виконується складання окремих модулів у більші конфігурації - виконується інтеграційне тестування, і, нарешті, тестується система в цілому - виконується системне тестування. З точки зору програмного коду, модульне, інтеграційне та системне тестування мають багато спільного, тому в цій темі основну увагу буде приділено модульному тестуванню, особливості інтеграційного та системного тестування будуть розглянуті пізніше. 26 Під час модульного тестування кожен модуль тестується як на відповідність вимогам, так і на відсутність проблемних ділянок програмного коду, які можуть спричинити відмови та збої в роботі системи. Як правило, модулі не працюють поза системою – вони приймають дані від інших модулів, переробляють їх та передають далі. Для того, щоб з одного боку ізолювати модуль від системи та виключити вплив потенційних помилок системи, а з іншого боку – забезпечити модуль усіма необхідними даними, використовується тестове оточення. Завдання тестового оточення – створити середовище виконання для модуля, емулювати всі зовнішні інтерфейси, яких звертається модуль. Про особливості організації тестового оточення йтиметься у цій темі. Типова процедура тестування полягає у підготовці та виконанні тестових прикладів (також званих просто тестами). Кожен тестовий приклад перевіряє одну «ситуацію» у поведінці модуля та складається зі списку значень, що передаються на вхід модуля, опису запуску та виконання переробки даних – тестового сценарію, та списку значень, які очікуються на виході модуля у разі його коректної поведінки. Тестові сценарії складаються таким чином, щоб унеможливити звернення до внутрішніх даних модуля, вся взаємодія повинна відбуватися тільки через його зовнішні інтерфейси. Виконання тестового прикладу підтримується тестовим оточенням, яке включає програмну реалізацію тестового сценарію. Виконання починається з передачі модулю вхідних даних та запуску сценарію. Реальні вихідні дані, отримані від модуля в результаті виконання сценарію, зберігаються і порівнюються з очікуваними. У разі збігу тест вважається пройденим, інакше – не пройденим. Кожен не пройдений тест вказує або на дефект в модулі, або в тестовому оточенні, або в описі тесту. Сукупність описів тестових прикладів складає тест-план – основний документ, визначальний процедуру тестування програмного модуля. Тест-план задає не лише самі тестові приклади, а й порядок їхнього слідування, який також може бути важливим. Структура та особливості тест-планів будуть розглянуті у цій темі, проблеми, пов'язані з порядком слідування тестових прикладів – у темі «Повторюваність тестування». При тестуванні часто буває необхідно враховувати як вимоги до системи, а й структуру програмного коду тестованого модуля. І тут тести складаються в такий спосіб, щоб детектувати типові помилки програмістів, викликані неправильної інтерпретацією вимог. Застосовуються перевірки граничних умов, перевірки класів еквівалентності. Відсутність системі можливостей, не заданих вимогами, гарантують різні оцінки покриття програмного коду тестами, тобто. оцінки того, який відсоток тих чи інших мовних конструкцій виконано внаслідок виконання всіх тестових прикладів. Про все це йтиметься на завершення цієї теми. 2.2. Методи тестування 2.2.1. Чорна скринька Основна ідея в тестуванні системи як чорної скриньки полягає в тому, що всі матеріали, які доступні тестувальнику – вимоги на систему, що описують її поведінку і сама система, працювати з якою він може лише подаючи на її входи деякі зовнішні впливи та спостерігаючи на виходи на деякий результат. Всі внутрішні особливості реалізації системи приховані від тестувальника, таким чином, система і є «чорною скринькою», правильність поведінки якого по відношенню до вимог і належить перевірити. 27 З точки зору програмного коду чорна скринька може являти собою набір класів (або модулів) з відомими зовнішніми інтерфейсами, але недоступними вихідними текстами. Основне завдання тестувальника для даного методу тестування полягає у послідовній перевірці відповідності поведінки системи вимогам. Крім того, тестувальник повинен перевірити роботу системи у критичних ситуаціях – що відбувається у разі подання невірних вхідних значень. В ідеальній ситуації всі варіанти критичних ситуацій мають бути описані у вимогах на систему і тестувальнику залишається лише вигадувати конкретні перевірки цих вимог. Однак насправді в результаті тестування зазвичай виявляється два типи проблем системи: 1. Невідповідність поведінки системи вимогам 2. Неадекватна поведінка системи в ситуаціях, не передбачених вимогами. Звіти про обидва типи проблем документуються та передаються розробникам. У цьому проблеми першого типу зазвичай викликають зміна програмного коду, набагато рідше – зміна вимог. Зміна вимог у разі може знадобитися через їх суперечливості (кілька різних вимог описують різні моделі поведінки системи у однієї й тієї самої ситуації) чи некоректності (вимоги відповідають дійсності). Проблеми другого типу однозначно вимагають зміни вимог через їхню неповноту – у вимогах явно пропущена ситуація, що призводить до неадекватної поведінки системи. При цьому під неадекватною поведінкою може розумітися як повний крах системи, так і будь-яка поведінка, не описана в вимогах. Тестування чорного ящика називають тестуванням за вимогами, т.к. це єдине джерело інформації для побудови тест-плану. 2.2.2. Скляна (біла) скринька При тестуванні системи, як скляної скриньки, тестувальник має доступ не лише до вимог на систему, її входів та виходів, але й до її внутрішньої структури – бачить її програмний код. Доступність програмного коду розширює можливості тестувальника тим, що він може бачити відповідність вимог дільницям програмного коду та бачити тим самим – чи на весь програмний код існують вимоги. Програмний код, для якого відсутні вимоги, називають кодом, непокритим вимогами. Такий код є потенційним джерелом неадекватної поведінки системи. Крім того, прозорість системи дозволяє поглибити аналіз її ділянок, що викликають проблеми – часто одна проблема нейтралізує іншу, і вони ніколи не виникають одночасно. 2.2.3. Тестування моделей Тестування моделей знаходиться дещо осторонь класичних методів верифікації програмного забезпечення. Насамперед це з тим, що об'єкт тестування – не сама система, та її модель, спроектована формальними засобами. Якщо залишити осторонь питання перевірки коректності і застосування самої моделі (вважається, що її коректність і відповідність вихідній системі може бути доведена формальними засобами), то тестувальник отримує у своє розпорядження досить потужний інструмент аналізу загальної цілісності системи. Працюючи з моделлю, можна створити такі ситуації, які неможливо створити в тестовій лабораторії для реальної системи. Працюючи з моделлю програмного коду системи, можна аналізувати його властивості і такі параметри системи, як оптимальність алгоритмів або її стійкість. 28 Проте тестування моделей не набуло широкого поширення через труднощі, що виникають при розробці формального опису поведінки системи. Один із небагатьох винятків – системи зв'язку, алгоритмічний і математичний апарат яких досить добре опрацьований. 2.2.4. Аналіз програмного коду (інспекції) У багатьох ситуаціях тестування поведінки системи загалом неможливе – окремі ділянки програмного коду можуть будь-коли виконуватися, у своїй вони будуть покриті вимогами. Прикладом таких ділянок коду можуть бути обробники виняткових ситуацій. Якщо, наприклад, два модулі передають один одному числові значення, і функції перевірки коректності значень працюють в обох модулях, функція перевірки модуля-приймача ніколи не буде активізована, т.к. всі помилкові значення будуть відсічені ще передавачі. У цьому випадку виконується ручний аналіз програмного коду на коректність, який також називають переглядами або інспекціями коду. Якщо в результаті інспекції виявляються проблемні ділянки, то інформація про це передається розробникам для виправлення на рівні результатів звичайних тестів. 2.3. Основний обсяг тестування практично будь-якої складної системи зазвичай виконується в автоматичному режимі. Крім того, система, що тестується, зазвичай розбивається на окремі модулі, кожен з яких тестується спочатку окремо від інших, потім в комплексі. Це означає, що для виконання тестування необхідно створити деяке середовище, яке забезпечить запуск і виконання модуля, передасть йому вхідні дані, збере реальні вихідні дані, отримані в результаті роботи системи на заданих вхідних даних. Після цього середовище має порівняти реальні вихідні дані з очікуваними та на підставі даного порівняння зробити висновок про відповідність поведінки модуля заданому (Рис. 9). Тестовий драйвер Вихідні дані, що очікуються Тестований Обробка Вхідні дані модуль результатів Реальні вихідні дані Заглушки Мал. 9 Узагальнена схема середовища тестування Тестове оточення також може використовуватися для відчуження окремих модулів системи від усієї системи. Поділ модулів системи на ранніх етапах тестування дозволяє більш точно локалізувати проблеми, що виникають у програмному коді. Для підтримки роботи модуля у відриві від системи тестове оточення має моделювати поведінку всіх модулів, до функцій або даних яких звертається модуль, що тестується. 29

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

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

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

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

1. Загальні відомості про верифікацію та атестацію ПЗ.

1.1. Введення у верифікацію та атестацію

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

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

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

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

На рис. 1.1 показано місце інспектування та тестування у процесі розробки ПЗ. Стрілки вказують ті етапи процесу розробки, у яких можна застосовувати дані методи.

Мал. 1.1. Статична та динамічна верифікація та атестація

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

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

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

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

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

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

2. Верифікація та атестація ПЗ

2.1. Планування верифікації та атестації

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

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

Мал. 2.1. Планування випробувань у процесі розробки та тестування,

Requirements specification – специфікація вимог

System specification – системна специфікація

System design – проектування системи

Detailed Design – детальне проектування

Acceptance test plan – планування приймальних випробувань

System integration test plan – планування тестування системного складання

Sub-system integration test plan – планування тестування збирання підсистеми

Module and unit code and tess – кодування та тестування модулів та компонентів

Sub-system integration test – тестування збирання підсистем

System integration test – тестування системного складання

Acceptance test – приймальні випробування

Service – програмний продукт.

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

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

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

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

2.2. Інспектування програмних систем

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

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

Доведено, що інспектування є ефективним методом виявлення помилок, причому воно значно дешевше за екстенсивне тестування. Інспектуванням можна виявити понад 60% всіх помилок, а за більш формальному підході (використовуючи математичні методи) – понад 90%. Процес інспектування також може оцінити інші якісні характеристики систем: відповідність стандартам, переносимість та зручність супроводу.

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

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

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

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

2.3. Інспектування програм

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

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

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

Мал. 2.2. Процес інспектування

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

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

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

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

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

2.4. Автоматичний статичний аналіз програм

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

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

Статичний аналіз складається з кількох етапів.

1. Аналіз потоку керування.Ідентифікація та виділення циклів, їх точок входу та виходу, виявлення коду, що не використовується.

2. Аналіз використання даних.Перевірка змінних у програмі. На цьому етапі також можна виявити умовні оператори з надмірними умовами.

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

4. Аналіз потоків даних.Визначаються залежності між вхідними та вихідними змінними. Хоча цей аналіз не виявляє конкретних помилок, він дає повний перелік значень, які у програмі. Отже, легко виявляється помилкове виведення даних.

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

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

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

2.5 Метод "чиста кімната".

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

У розробці програмного забезпечення методом «чиста кімната» виділяють п'ять ключових моментів:

1. Формальна специфікація. Розробляється формальна специфікація. Для запису специфікації використовується модель станів, де відображені відгуки системи.

2. Покрокова розробка. Розробка ПО розбивається кілька етапів, які перевіряються методом «чиста кімната» незалежно друг від друга.

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

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

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

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

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

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

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

3. Тестування програмного забезпечення

3.1. Планування тестування

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

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

Тестування складання має ґрунтуватися на наявній специфікації системи.

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

3.2. Тестування дефектів

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

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

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

Методів тестування дефектів є кілька.

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

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

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

3.3. Тестування складання

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

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

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

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

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

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

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

Між компонентами програми можуть бути різні типи інтерфейсів та, відповідно, різні типи помилок інтерфейсу.

Мал. 3.1. Тестування інтерфейсів

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

Зазвичай статичні методи тестування рентабельніші, ніж спеціальне ТІ. У мовах із суворим контролем типів помилки інтерфейсу допомагає виявляти компілятор, а мовах із слабким контролем помилки може виявляти статичний аналізатор. Крім того, при інспектуванні програм можна зосередитись саме на перевірці інтерфейсів компонентів.

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

3.4. Інструментальні засоби тестування

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

Мал. 3.2. Інструментальні засоби тестування

На цьому малюнку:

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

4. Атестація критичних систем

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

4.1. Атестація безвідмовності

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

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

Висока вартість генерації тестових даних (якщо немає можливості автоматичної генерації тестових даних, створення великої кількості тестових даних вимагає великих витрат часу і, відповідно, коштів)

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

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

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

4.2. Гарантії безпеки

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

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

4.3. Верифікація та атестація

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

При створенні КС важливий всебічний аналіз системи, що розробляється. Є п'ять типів аналізу системи, обов'язкових для КС:

1. Аналіз правильності функціонування системи

2. Аналіз можливості зміни та зрозумілості системної архітектури

3. Аналіз відповідності алгоритму обробки та структури даних визначеній у специфікації поведінці системи

4. Аналіз узгодженості програмного коду, алгоритмів та структур даних.

5. Аналіз адекватності тестових сценаріїв системним вимогам.

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

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

Висновок

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

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

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

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

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

Література

1. Соммервілл І. Інженерія програмного забезпечення, 6-е видання.: Пер. з англ. - М.: Видавництво. Будинок. "Вільямс", 2002. - 624 с.: Іл.

2. А.Г. Гейн, В.Г. Житомирський. Основи інформатики та обчислювальної техніки: проб. Навч. Для 10-11 кл. середовищ. шк. - 3-тє вид. - М.: Просвітництво, 1993. - 254 с.: Іл.

3. Ю. Г. Карпов. Теорія автоматів. - Спб.: Пітер, 2002 - 224 с.: Іл.

4. Електронний Архів для інженерів програмного забезпечення. http://www.cs.queensu.ca/Software-Engineering/

5. Software Engineering Questions and Answers. http://www.cs.queensu.ca/Software-Engineering/questions.html

6. Ресурси сервера Інституту Інженерії Програмного Забезпечення Карнегі Меллона (Carnegie Mellon Software Engineering Institute). http://www.sei.cmu.edu/

7. SybaseDevel.Ru - російський портал для розробників. http://www.sybasedevel.ru

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

У статті я розглянув два підходи до моделювання об'єкта як цілого і як конструкції. У цій статті нам цей поділ знадобиться.

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

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

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

2. Неповний запис знань про Об'єкт – щось пропущено, зроблено помилки. Наприклад, знали про вітри, але забули згадати. Це може призвести до недостатнього опису вимог до об'єкта.

3. Неправильне зведення знань. Нас вчили пріоритету маси над рештою параметрів, а виявилося, що треба було нарощувати швидкість.

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

5. Неповний запис отриманих висновків щодо конструкції системи. Усі врахували, всі розрахували, але забули написати.

6. Створена система відповідає опису.

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

Що таке верифікація? Російською, верифікація - це перевірка на відповідність правилам. Правила оформлюються як документа. Тобто має бути документ із вимогами до документації. Якщо документація відповідає вимогам цього документа, вона пройшла верифікацію.

Що таке валідація? Російською валідація – це перевірка правильності висновків. Тобто, має бути зведення знань, в якому описано, як отримати опис конструкції на основі даних про об'єкт. Перевірка правильності застосування цих висновків є валідація. Валідація - це у тому числі перевірка опису на несуперечність, повноту та зрозумілість.

Часто валідацію вимог плутають із валідацією продукту, побудованого на основі цих вимог. Так не варто робити.

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

Можна сказати, що вимога відсутності помилок у програмному забезпеченні абсолютно природна і не потребує обґрунтування. Але як переконатись у тому, що помилок, справді, немає? Питання не таке просте, як може здатися на перший погляд.

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

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

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

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

Метод встановлення правильності програм за допомогою строгих засобів відомий як верифікація програм.

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

В основі методу верифікації лежить припущення, що існує програмна документація, відповідність якої потрібно довести. Документація повинна містити:

специфікацію введення-виведення (опис даних, які не залежать від процесу обробки);

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

специфікації та властивості структурних підкомпонентів програми;

специфікацію структур даних, що залежать від процесу обробки.

До такого методу доказу правильності програм належить метод індуктивних тверджень, незалежно сформульований К. Флойдом та П. Науром.

Суть цього методу полягає в наступному:

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

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

3) формулюється теорема (умови верифікації):

з виведеного твердження випливає вихідне твердження;

4) доводиться теорема; доказ свідчить про правильність програми (програмного фрагмента).

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

Умови верифікації можна побудувати і у зворотному напрямку, тобто, вважаючи істинним вихідне твердження, отримати вхідне твердження та доводити теорему:

із вхідного твердження випливає виведене твердження.

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

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

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

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

1) Побудувати структуру програми.

2) Виписати вхідне та вихідне твердження.

3) Сформулювати всім циклів індуктивні затвердження.

4) Скласти перелік виділених шляхів.

5) Побудувати умови верифікації.

6) Довести умову верифікації.

7) Довести, що виконання програми закінчиться.

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

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

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

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

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

Перелічені методи мають одну загальну властивість: вони розглядають програму як існуючий об'єкт і потім доводять її правильність.

Метод, який сформулювали К. Хоар та Е. Дейкстра, заснований на формальному виведенні програм з математичної постановки завдання.

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

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

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

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

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

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

Відмінність між верифікацією та валідацією проілюстрована на малюнку 1.

Наведені визначення отримані деяким розширенням визначень стандарту IEEE 1012 на процеси верифікації та валідації. У стандартному словнику термінів програмної інженерії IEEE 610.12 1990 визначення верифікації за змістом приблизно те ж, а визначення валідації дещо інше - там говориться, що валідація повинна перевіряти відповідність отриманого в результаті розробки ПО вихідним вимогам до нього. У цьому випадку валідація була б окремим випадком верифікації, що ніде в літературі з програмної інженерії не зазначається, тому, а також тому, що воно виправлене в IEEE 1012 2004 року, це визначення слід вважати неточним. Часте використання фрази B. Boeh'а:

Верифікація відповідає питанням " Чи робимо ми продукт правильно? " , а валідація- питанням " Чи робимо ми правильний продукт?"

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

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

бібліографічний список

• В.В. Кулямін "Методи верифікації програмного забезпечення". Інститут системного програмування РАН 109004, м. Москва, вул. Б. Комуністична, буд. 25.
  http://www.ict.edu.ru/ft/005645/62322e1-st09.pdf
• IEEE 1012-2004 Standard for Software Verification and Validation. IEEE, 2005.
• IEEE 610.12-1990 Standard Glossary of Software Engineering Terminology, Corrected Edition. IEEE, February 1991.
• B. W. Boehm. Software Engineering; R&D Trends and Defense Needs. У R. Wegner, ed. Research. Directions in Software Technology. Cambridge, MA: MIT Press, 1979.
• ISO/IEC 12207 Systems and software engineering - Software life cycle processes. Geneva, Switzerland: ISO, 2008.