К. М. Лавріщева програмна інженерія підручник Київ, 2008
 Скачать 5.23 Mb.
|
|
6.3.3. Підхід до верифікації композиції компонентів Метод верифікації композиції компонентів базується на специфікації функцій і часових (temporal) властивостей готових перевірених компонентів (типу reuse) і виконується за допомогою абстракцій моделі перевірки Model Сhecking [20]. Загальна компонентна модель (ЗКМ) – це сукупності перевірених специфікацій компонентів, часових властивостей і умов функціонування для асинхронної передачі повідомлень (АПП). Модель перевірки забезпечує верифікацію програм на надійність шляхом розв’язання наступних задач: – специфікація компонентів мовою xUML [26] діалекту UML з описом часових властивостей; – опис функцій reuse компоненти, специфікації інтерфейсу і часових властивостей; – перевірка властивостей складних компонентів композиційним апаратом. Компоненти моделі можуть бути примітивними і складними. Властивості примітиву перевіряються за допомогою моделі перевірки, а властивість складного компонента – на абстракції компонентів, зібраних з примітивів і перевірених їхніх властивостей в інтегрованому середовищі. Даний підхід може використовуватися у розподілених програмних системах, що функціонують на платформах типу CORBA, DCOM і EJB. Модель компонента в ЗКМ моделі має вигляд: C = (E, I, V, P), де E – початковий опис компонента; I – інтерфейс цього компонента; V – множина змінних, визначених в множині E і пов'язаних з властивостями з множини Р; Р – часові властивості середовища компонента. Властивість компонента С включається в Р тоді, коли вона перевірена у середовищі і представлена парою (p, А(p)) на множині E, де p – властивість компонента С в Е, А(p) – множина часових формул з властивостей, визначених на множинах I і V. Композиція компонентів – це сукупність простіших компонентів: (E 0 , I 0 , V 0 , P 0 ), ..., (En–i, In–i, Vn–i, Pn–i), визначених на моделі компонента С . Модель обчислень АПП – це обчислювальна модель системи, задана на скінченній множині взаємодіючих процесів, представлених кортежами: Р = (Х, Q ), де X – множина змінних, кожна з яких має тип; – розширена модель стану; Q – черга повідомлень у порядку надходження; – множина початкових значень для кожної змінної з X, E і порожнє для Q. Модель стану ПС (Ф, М, T), де Ф – множина станів; М – множина типів повідомлень; T – набір переходів, визначених на множині Ф і М. Асинхронна передача повідомлень АПП викликає чергування переходів станів і дій процесів. Для двох процесів Р1 і Р2 передача повідомлення від Р1 до Р2 містить у собі: тип повідомлення m з множини М для P2 і відповідні параметри. Коли оператор дії виконується, повідомлення m з параметрами ставиться у чергу до процесу Р2. 6.3.4. Загальні перспективи верифікації програм Методи формальної верифікації використовувалися для перевірки правильності моделей ПрО, функцій в мові API, безпеки і цілісності БД – у проекті SDV фірми Microsoft і у міжнародному проекті з формальної верифікації ПС. Ідея створення цього проекту належить Т.Хоару і обговорювалася на симпозіумі з верифікованого ПС у лютому 2005г. у Каліфорнії. Потім у жовтні того ж року на конференції IFIP в Цюріху був прийнятий міжнародний проект строком на 15 років з розроблення цілісного автоматизованого набору інструментів для перевірки коректності ПС [14, 15]. У проекті сформульовані такі основні задачі: – розроблення єдиної теорії створення і аналізу програм; – побудова всеосяжного інтегрованого набору інструментів верифікації для всіх процесів, включаючи розроблення специфікацій і їх перевірку, генерацію тестових прикладів, уточнення, аналіз і верифікацію програм; – створення репозитарію формальних специфікацій і верифікованих програмних об'єктів різних видів і типів. Репозітарій – це сховище правильних програм, специфікацій і інструментів. Функції репозитарію: – накопичення верифікованих специфікацій, методів доведення, програмних об'єктів і реалізацій кодів для різних програмних застосувань; Розділ 6 165 – накопичення всіляких методів верифікації, їх оформлення у вигляді, придатному для пошуку і відбору реалізованої теоретичної концепції для подальшого застосування; – розроблення стандартних форм для завдання і обміну формальними специфікаціями різних об'єктів, інструментів і готових систем; – розроблення механізмів взаємодії для перенесення готових верифікованих продуктів з репозитарію в нові розподілені і мережні середовища для їхнього використання в нових ПС. Даний проект передбачається розвивати протягом 50 років. Відомо, що більш ранні проекти ставили подібні цілі: поліпшення якості ПС, формалізації сервісних моделей, зниження складності за рахунок використання КПВ, створення налагоджувального інструментарію для візуальної діагностики помилок і їх усунення тощо. Проте корінної зміни в програмуванні поки не відбулося. Залучення техніки формальної специфікації програм ще не означає, що в програмі будуть відсутні помилки, оскільки помилки в програмних проектах, в інтерпретації специфікацій МП, у документації поки не можна розпізнати. Реалізація міжнародного проекту з верифікації ПС допоможе вирішити багато з цих питань. 6.4. Тестування програмних систем Тестування – це метод виявлення помилок у ПС шляхом виконання вихідного коду на тестових даних, збирання робочих характеристик у динаміці виконання в конкретному операційному середовищі, виявлення різних помилок, дефектів, відмовлень і збоїв, викликаних нерегулярними, аномальними ситуаціями або аварійним припиненням роботи системи. Його можна розглядати, як процес семантичного налагодження (перевірки) програми, що полягає у виконанні послідовності різних наборів контрольних тестів, для яких заздалегідь відомий результат. Тобто тестування припускає виконання програми й одержання конкретних результатів виконання тестів [24–26]. Тести підбираються так, щоб вони охоплювали як найбільше типів ситуацій алгоритму програми. Менш тверда вимога – виконання хоча б один раз кожної гілки програми. Історично першим видом тестування було налагодження. Налагодження – це перевірка опису програмного об'єкта на МП з метою виявлення в ньому помилок і подальшого їхнього усунення. Помилки виявляються компіляторами при їхньому синтаксичному контролі. Після цього проводиться верифікація з перевірки правильності функцій коду і валідація з перевірки відповідності продукту заданим вимогам. Мета тестування – перевірка виконання реалізованих функцій відповідно до їхньої специфікації. На основі зовнішніх специфікацій функцій і проектної інформації на процесах ЖЦ створюються функціональні тести, за допомогою яких проводиться тестування з урахуванням вимог, сформульованих на процесі аналізу предметної області. Методи функціонального тестування підрозділяються на статичні і динамічні. 6.4.1. Статичні методи тестування Статичні методи використовуються при проведенні інспекцій і розгляді специфікацій компонентів без їхнього виконання. Техніка статичного аналізу полягає в методичному перегляді (або огляді) і аналізі структури програм, а також у доведенні їхньої правильності вручну за столом. Статичний аналіз направлений на аналіз документів, розроблених на всіх процесах ЖЦ і полягає в інспекції вхідного коду і наскрізного контролю програми. Інспекція ПС – це статична перевірка відповідності програми заданим специфікаціями, проводиться шляхом аналізу різних представлень результатів проектування (документації, вимог, специфікацій, схем або коду програм) на процесах ЖЦ. Перегляди й інспекції результатів проектування і відповідності їх вимогам замовника забезпечують більш високу якість створюваних ПС. При інспекції програм розглядаються документи робочого проектування на процесах ЖЦ разом з незалежними експертами й учасниками розробки ПС. На початковому процесі проектування інспекція припускає перевірку повноти, цілісності, однозначності, несуперечності і сумісності документів з вимогами до програмної системи. На процесі реалізації системи під інспекцією розуміють аналіз текстів програм на дотримання вимог стандартів і прийнятих керівних документів технології програмування. Ефективність такої перевірки полягає в тому, що залучені експерти намагаються подивитися на проблему «з боку» і піддають її всебічному критичному аналізу. Ці прийоми дозволяють на більш ранніх процесах проектування знайти помилки або недоробки шляхом багаторазового перегляду вхідного опису програми. Символьне тестування застосовується для перевірки окремих ділянок програми на вхідних символьних значеннях. Крім того, розробляється безліч нових засобів автоматизації символьного виконання програм. Наприклад, автоматизований засіб статичного контролю для мовно-орієнтованої розробки, інструменти автоматизації доведення коректності й автоматизований апарат мереж Петрі. 6.4.2. Динамічні методи тестування Динамічні методи тестування використовуються в процесі виконання програм. Вони базуються на графовій структурі, що пов'язує причини помилок з очікуваними реакціями на них. У процесі тестування накопичується інформація про помилки, що використовується при оцінці показників надійності і якості ПС. Динамічне тестування орієнтоване на перевірку коректності ПС на множині тестів, що проганяються по ПС, з урахуванням зібраних даних на процесах ЖЦ, проведення виміру окремих показників (число відмов, збоїв) тестування для оцінки характеристик якості, зазначених у вимогах, шляхом виконання системи на ЕОМ. Тестування ґрунтується на систематичних, статистичних, (імовірнісних) і імітаційних методах. Охарактеризуємо їх Систематичні методи тестування поділяються на методи, у яких програма розглядається як «чорна скринька» (використовується інформація про розв'язувану задачу), і методи, у яких програма розглядається як «біла скринька» з використанням структури програми. Цей вид називають тестуванням з керуванням за даними або керуванням на вході-виході. Ціль – з'ясування обставин, при яких поводження програми не відповідає її специфікації. При цьому кількість виявлених помилок у програмі є критерієм якості тестування. Розділ 6 167 Ціль динамічного тестування програм за принципом «чорної скриньки» – виявлення одним тестом максимального числа помилок з використанням невеликої підмножини можливих вхідних даних. Методи «чорної скриньки» забезпечують: – еквівалентне розбиття; – аналіз граничних значень; – застосування функціональних діаграм, що в поєднанні з реверсивним аналізом дають досить повну інформацію про функціонування тестованої програми. Еквівалентна розбивка складається з розділу вхідної області даних програми на скінченне число класів еквівалентності так, щоб кожен тест, що є представником деякого класу, був еквівалентний будь-якому іншому тесту цього класу. Класи еквівалентності виділяються шляхом перебору вхідних умов і розбивки їх на дві групи або більше. При цьому розрізняють два типи класів еквівалентності: правильні, що задають вхідні дані для програми, і неправильні, засновані на завданні помилкових вхідних значень. Розроблення тестів методом еквівалентного розбиття здійснюється в два етапи: виділення класів еквівалентності і побудова тестів. При побудові тестів, заснованих на виборі вхідних даних, проводиться символьне виконання програми. Отже, методи тестування за принципом «чорної скриньки» використовуються для тестування функцій, реалізованих у програмі, шляхом перевірки невідповідності між реальною поведінкою функцій і очікуваною поведінкою з урахуванням специфікацій вимог. Під час підготовки до цього тестування будуються таблиці умов, причинно-наслідкового графа й області розбиття. Крім того, готуються тестові набори, що враховують параметри й умови середовища, які впливають на поведінку функцій. Для кожної умови визначається множина значень і обмежень предикатів, за якими тестується програма. Метод «білої скриньки» дозволяє досліджувати внутрішню структуру програми, при чому виявлення всіх помилок у програмі є критерієм вичерпного тестування маршрутів потоків (графа) передач керування, серед яких розглядають: а) критерій покриття операторів – набір тестів у сукупності повинен забезпечити проходження кожного оператора не менше ніж один раз; б) критерій тестування областей (відомий як покриття рішень або переходів) – набір тестів у сукупності повинен забезпечити проходження кожної гілки і виходу, принаймні, один раз. Критерій «б» відповідає простому структурному тесту і найбільш розповсюджений на практиці. Для задоволення цього критерію необхідно побудувати систему шляхів, що містить у собі усі області програми. Перебування такого оптимального покриття в деяких випадках здійснюється просто, а в інших є більш складною задачею. Тестування за принципом «білої скриньки» орієнтовано на перевірку проходження всіх віток програм за допомогою застосування шляхового й імітаційного тестування. Шляхове тестування застосовується на рівні модулів і графової моделі програми з вибором тестових ситуацій, підготовки даних і містить у собі тестування наступних елементів: – операторів, що повинні бути виконані хоча б один раз, без обліку помилок, що можуть залишитися в програмі через велику кількість логічних шляхів і необхідності проходження підмножин цих шляхів; – шляхів по заданому графу потоків керування для виявлення різних маршрутів передачі керування за допомогою шляхових предикатів, для обчислення якого створюється набір тестових даних, що гарантують проходження всіх шляхів. Проте усі шляхи протестувати неможливо, тому залишаються не виявлені помилки, що можуть виявитися в процесі експлуатації; – блоків, що розділяють програми на окремі дрібні блоки, які виконуються хоча б один раз або багаторазово при проходженні через шляхи програми, що вміщують сукупність операторів реалізації однієї функції, або на вхідній множині даних, що буде використовуватися при виконанні зазначеного шляху. «Біла скринька» базується на структурі програми, у випадку ж «чорної скриньки» про структуру програми нічого невідомо. Для виконання тестування за допомогою цих «скриньок» відомими вважаються виконувані функції, входи (вхідні дані) і виходи (вихідні дані), а також логіка обробки програми і опису документації. 6.4.3. Функціональне тестування Мета функціонального тестування – виявлення невідповідностей між реальною поведінкою реалізованих функцій і очікуваною поведінкою відповідно до специфікації і вимог. Функціональні тести повинні охоплювати всі реалізовані функції з урахуванням найбільш ймовірних типів помилок. Тестові сценарії, що поєднують окремі тести, орієнтовані на перевірку якості розв'язку функціональних задач. Функціональні тести створюються за зовнішніми специфікаціями функцій, проектної інформації і за текстом на МП, що стосуються його функціональних характеристик і застосовуються на процесі комплексного тестування й іспитів для визначення повноти реалізації функціональних задач і їхньої відповідності вхідним вимогам. До задач функціонального тестування належать: – ідентифікація множини функціональних вимог; – ідентифікація зовнішніх функцій і побудова послідовностей функцій відповідно до їхнього використання в ПС; – ідентифікація множини вхідних даних кожної функції і визначення областей їхньої зміни; – побудова тестових наборів і сценаріїв тестування функцій; – виявлення і подання усіх функціональних вимог за допомогою тестових наборів і проведення тестування помилок у програмі і при взаємодії із середовищем. Тести, створювані за проектною інформацією, пов'язані зі структурами даних, алгоритмами, інтерфейсами між окремими компонентами і застосовуються для тестування компонентів і їхніх інтерфейсів. Основна мета – забезпечення повноти і погодженості реалізованих функцій і інтерфейсів між ними. В основу комбінованого методу «чорної скриньки» і «білої скриньки» покладено розбивку вхідної області функції на підобласті виявлення помилок. Підобласть містить у собі однорідні елементи, які обробляються коректно або Розділ 6 169 некоректно. Для тестування підобласті застосовується виконання програми на одному з елементів цієї області. Передумови функціонального тестування: – коректне оформлення вимог і обмежень до якості ПС; – коректний опис моделі функціонування ПС у середовищі експлуатації замовника; – адекватність моделі ПС заданому класу. 6.5. Інфраструктура перевірки правильності програмних систем Під інфраструктурою перевірки правильності (доведення, верифікації і тестування) програмних систем розуміють інтегрований набір загальнодоступних технічних, технологічних і методологічних ресурсів, що знаходяться у розпорядженні команди розробників, верифікаторів і тестувальників, які виконують роботи з розроблення правильної системи за договорами із організаціями-замовниками. Команда виконує дії з підготовки і проведення таких задач: – виділення об'єктів перевірки на процесах ЖЦ та на завершальному процесі тестування; – аналіз і класифікація помилок для розглянутого класу програм, що перевіряються; – підготовка даних для верифікації правильності виконання функцій; – підготовка даних і тестів для їхнього виконання і пошуку різного роду помилок і відмовлень у компонентах і в системі в цілому; – розроблення завдань підгрупами команди з проведення і керування процесом досягнення правильної програми; – підготовка до перевірки виконання вимог до ПС і до системи; – аналіз результатів верифікації і тестування системи, отриманих підгрупами. Об'єкти процесу – компоненти, групи компонентів, підсистеми і система. Для кожного з них формується стратегія проведення верифікації і тестування. Якщо об'єкт готовий і належить до «білої скриньки» або до «чорної скриньки», склад компонентів якого невідомий, то верифікація функцій проводиться зі спеціально підготовленими даними перевірки функцій і вхідних тестових даних для тестування й отримання вихідних даних. Головна мета верифікації перевірити правильність виконання функцій. Стратегічна мета тестування – переконатися, що кожен розглянутий вхідний набір даних відповідає очікуваним вихідних даним. Проектувальник тестів повинен заглянути усередину «чорної скриньки» і досліджити деталі процесів обробки даних, питання забезпечення захисту і відновлення даних, а також інтерфейси з іншими програмами і системами. Це сприяє підготовці тестових даних для проведення тестування. Для деяких типів об'єктів група інженерії тестування не може згенерувати представницьку безліч тестових наборів, що демонстрували б функціональну правильність роботи компонентів при всіх можливих наборах тестів. Тому кращим є метод «білої скриньки», при якому можна використовувати логічну структуру об'єкта для організації перевірки програми в різних її областях. Наприклад, можна виконати верифікацію функцій і підготувати тестові набори, що |