10

Побудова моделі класу

Размещено на http://www.allbest.ru/

МІНІСТЕРСТВО ОСВІТИ І НАУКИ УКРАЇНИ

ХАРКІВСЬКИЙ НАЦІОНАЛЬНИЙ УНІВЕРСИТЕТ ІМЕНІ В.Н. КАРАЗІНА

ФАКУЛЬТЕТ КОМП'ЮТЕРНИХ НАУК

КУРСОВА РОБОТА

з дисципліни «Математичні методи та технології тестування та верифікації програмного забезпечення»

Тема «Тестування систем реального часу»

Виконав студент 2 курсу групи КС-21

Мороз Євген Русланович

Керівник: ст. викладач Мелкозьорова О. М.

Харків 2019



Реферат

тестування час програмний забезпечення

Відомості про обсяг курсової роботи: 29с., 5 рис., 9 джерел.

В курсовій роботі буде розглянуто основні риси засобів активного тестування та моніторингу для систем реального часу, а також помилки, характерні для СРЧ, і способи їх виявлення.

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

В роботі будуть описані засоби моніторингу мають схожі методи збору, обробки та подання тестувальних даних. Завдяки їм стає можливим локалізувати помилки СРЧ, пов'язані з плануванням і синхронізацією.



Зміст

Перелік позначень та скорочень

Вступ

1. Теоретичні відомості

1.1 Основні визначення

1.2 Особливості тестування систем реального часу

1.3 Помилки в системах реального часу

1.4 Дизайн тестового набору

2. Засоби тестування

2.1 SDL

2.2 MSC

2.3 TTCN

2.4 TTCN-3

2.5 Дії тестування

2.6 Інтерфейс користувача

3. Засоби моніторінгу

3.1 Архітектура засобів моніторінгу

Висновок

Список джерел інформації



Перелік позначень та скорочень

КР - курсова робота;

ОС - операційна система;

ПЗ - програмне забезпечення;

СРЧ - система реального часу;

ОСРЧ - операційна система реального часу ;

РСРЧ - розподілена система реального часу ;

БД - бази данних;



Вступ

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

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



1. Теоретичні відомості

1.1 Основні визначення

Предметом цього огляду є тестування систем реального часу.

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

Існуючі СРЧ є багатозадачними. Багатозадачність реалізується через многопроцессность і багатопоточність.

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

Многопроцессность в СРЧ має суттєві недоліки, оскільки вимагає підтримки часу виконання для доступу до пам'яті, і, отже, при перемиканні контекстів системі потрібно скористатися додатковими функціями.

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

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

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



Рисунок 1.1 Структура системи реального часу

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

1.2 Особливості тестування систем реального часу

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

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

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

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

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

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

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

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

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

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



1.3 Помилки в системах реального часу

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

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

Помилки в ОСРЧ: помилки планування, синхронізації і зв'язку. Для тестування, в цьому випадку, треба використовувати один із способів моніторингу. Детально засоби моніторингу описані в розділі 3.

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

1.4 Дизайн тестового набору

Дизайн тестового набору для тестування в реальному часі може бути запропонований в чотири етапи:

1) тестування завдань

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

2) поведінковий тестування

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

3) межзадачного тестування

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

4) тестування системи

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

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



2. Засоби тестування

2.1 SDL

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

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

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

Рисунок 1.2 Система SDL



2.2 MSC

Діаграма послідовності повідомлень є діаграмою взаємодії з сімейства SDL, стандартизованої Міжнародним союзом електрозв'язку. Метою рекомендації MSC (Діаграма послідовності повідомлень) є надання мови трасування для специфікації і опису поведінки зв'язку компонентів системи і їх середовища за допомогою обміну повідомленнями. Оскільки в MSC комунікаційну поведінку представлено дуже інтуїтивно і прозоро, особливо в графічному поданні, мова MSC легко вивчати, використовувати та інтерпретувати. У зв'язку з іншими мовами він може використовуватися для підтримки методологій для специфікації системи, проектування, моделювання, тестування і документації. Діаграма (рис 1.3) показує три об'єкти. При запуску телефон відключений. Користувач робить спроби з'єднатися. Запит на з'єднання відправляється на комутатор і запускається таймер. Альтернатива має справу з двома можливими відповідями: 1 - таймер відключається, тому що комутатор не відповів, і/або телефон повертається в відключений стан. 2 - комутатор дозволяє з'єднання, і виклик встановлюється.



Рисунок 1.3 MSC (діаграма послідовності повідомлень)

2.3 TTCN

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

TTCN широко використовується, наприклад; ETSI, ITU для тестування телекомунікаційних протоколів. У TTCN також були написані тести відповідності стандартів ETSI, як ISDN, DECT, GSM, EDGE, 3G, DSRC. Нещодавно він також використовувався для тестування різних стандартів протоколу, наприклад, Bluetooth, IP.Виконання цих тестових випадків проти продуктів (наприклад, телефонів, мобільних телефонів, послуг, що надають послуги або елементів мережі) використовуються для перевірки того, що впровадження протоколу в цих продуктах відповідає вимогам, визначеним стандартами телекомунікацій. TTCN часто поєднується з ASN.1.

TTCN це єдина міжнародна стандартна мова тестування. TTCN3 надає більш широку придатність у порівнянні з попередніми версіями TTCN, які в першу чергу орієнтовані тільки на протоколи OSI.

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

2.4 TTCN-3

TTCN-3 є єдиною доступною в даний час міжнародною стандартизованою мовою тестування. До TTCN3 його попередні версії мали обмежену функціональність і обмежували сферу застосування протоколу OSI. Але TTCN3 є вдосконаленою версією і має більш широке застосування.

Характеристики TTCN3:

1) можливість задавати динамічне паралельне тестування

2) операції для комунікації на основі повідомлень і процедур

3) можливість задавати шаблони даних і підписів за допомогою потужних механізмів відповідності

4) параметризація типу і значення

5) призначення та обробка тестових вироків

6) механізми параметризації набору тестів та вибору тестів

Причиною використання TTCN3 для тестування в реальному часі є його таймери. Ці таймери визначаються в наборі функцій тестування. У TTCN3 немає ніяких глобальних таймерів. Ці таймери можна запускати, зупиняти і перевіряти за допомогою простих функцій, таких як timer.start, timer.stop і timer.read.

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

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



Рисунок 1.4 MSC (діаграма послідовності повідомлень) представлення базового сценарію TTCN-3 (тестування та відладки)

2.5 Дії тестування

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

· попередні дії тестування;

· переривання виконання завдання;

· отримання інформації;

· продовження / зміна виконання завдання.

1) Попередні дії тустуування

· завантаження модуля на цільової стороні;

· запуск потрібного завдання;

· якщо завдання було запущено засобами системи, то приєднання до неї (в цьому випадку виконання завдання зупиняється і стає можливим виробляти налагоджувальні дії);

· перемикання між завданнями.

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

2) Переривання виконання завдання

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

Досягнуто точка переривання.

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

Апаратна точка переривання не вимагає модифікації пам'яті, так як її адресу зберігається в спеціальному реєстрі (debug register, DR), який проглядається процесором при виконанні чергової інструкції. Якщо відбуваються дії, закладені в контрольний регістр (наприклад, виконання по заданому адресою або читання / запис в область, що адресується значенням DR), то процесор генерує відповідне переривання, обробивши яке, відладчик отримує необхідну інформацію.

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

Крім роботи з точками переривання, що встановлюються на конкретну адресу, відладчик працює з так званими перериваннями доступу (access breakpoints), використовуваними для визначення моменту доступу до деякої області пам'яті, і переривань настання подій (event detection), які спрацьовують, коли відбувається відповідна подія.

Використовується режим покрокової налагодження.

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

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

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

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

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

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

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

3) Отримання інформації

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

· Перегляд вмісту стека.

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

· Перегляд таблиці символів.

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

· Перегляд вихідних файлів.

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

· Перегляд даних.

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

Крім того, у користувача може виникнути необхідність здійснити в процесі сеансу налагодження виклик деякої функції. Для підтримки цього існують різні способи, наприклад, можна передати відповідний запит агенту налагодження, і той запустить потрібну опцію або в контексті отлаживаемой в даний момент завдання, або в деякому спеціальному контексті. У GDB (GNU debugger, Free Software Foundation) реалізований інший механізм, суть якого полягає в тому, що всі попередні дії (установка точки виконання, і.т.д.) виробляються на інструментальній стороні, а агенту передається запит на виконання з поточного адреси.

1) Продовження / зміна виконання

Особливістю активної налагодження є можливість зміни виконання завдання.

· Зміна даних.

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

· Продовження виконання завдання з будь-якої адреси.

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

· Продовження виконання завдання до деякої адреси.

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

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

· Повернення з функції.

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

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

2) Відновлення збережених регістрів.

3) Установка значення, що повертається в потрібну область пам'яті / регістр.

4) Установка покажчика стека на попередній кадр.

5) Установка точки виконання програми на адресу повернення заданої функції.

6) Знищення поточного кадру стека.

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

2.6 Інтерфейс користувача

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

Інтерфейс отладчика складається з:

· графічного інтерфейсу;

· режиму комадно рядки;

· команд представлення даних.

1) Графічний інтерфейс

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

2) Режим командного рядка

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

3) Команди представлення даних

Наведемо деякі способи представлення і зберігання даних, реалізація яких в значній мірі спрощує роботу користувача:

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

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

Підтримка різних форматів представлення даних - Вже згадувані засоби налагодження (VxGDB, X-Ray) надають можливість виведення даного значення в будь-якому числовому або символьному форматі. Крім того, в них є підтримка складних елементів мови, таких як масиви або структури.

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

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

GDB в даному випадку надає такі можливості:

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

· Команда commands прив'язує до точки переривання, номер якої заданий як аргумент, набір дій, які потрібно реалізувати отладчику при досягненні цієї точки переривання.



3. Засоби моніторингу

3.1 Архітектура засобів моніторінгу

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

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

Рис. 3.1 Архітектура відладчика, що здійснює моніторинг

Налагодження дії при моніторингу можна розділити на наступні категорії:

· збір даних;

· аналіз даних;

· профілювання системи;

· «посмертний» аналіз.

1) Збір даних

Існує кілька способів збору даних на цільовій машині і передачі їх менеджеру:

· Передавати дані на інструментальну сторону в міру їх надходження.

· Передавати дані в разі заповнення буфера.

· Зберігати дані на диску.

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

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

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

· перервати збір даних;

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

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

Один із способів протоколювання подій полягає в тому, що на функції, виконання яких призводить до деякого події, ставиться спеціального виду точка переривання (eventpoint). Такий підхід дозволяє користувачеві визначати власні події (як це зроблено в WindView - Wind River Systems, цільова система VxWorks).

Тепер розглянемо технологію збору даних на прикладі StethoScope (Wind River Systems, цільова система VxWorks). При зборі даних про функції використовується механізм вставки виконуваного коду перед і після виклику отлаживаемой функції. Його суть в тому, що користувач може налаштувати установки, виклики з яких випереджати і завершувати виконання необхідної процедури. Цей механізм використовується і в службових цілях, наприклад при трасуванні завдання. Реалізувати його можна так: на першу інструкцію отлаживаемой функції ставиться крапка переривання, що обробляється особливим чином, а саме:

a. ставиться крапка переривання на точку повернення з отлаживаемой функції;

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

c. запускається виконання налагоджують функції.

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

При зборі інформації про динамічному виділенні пам'яті можна використовувати такий підхід (RTILib - Real-Time Innovations, цільова система VxWorks). Замінити функції виділення і звільнення пам'яті (malloc, calloc, realloc, free) на відповідні функції, які виконують, крім роботи з пам'яттю, деякі налагоджувальні дії, а саме: маркування кордонів виділеного блоку і подальший контроль за її збереженням (так можна фіксувати вихід за межі ), установку прапора доступу до блоку (для заборони / дозволу звернення до цього блоку), збір статистики по використанню пам'яті, протоколювання інформації по виділеним блокам.

2) Аналіз даних

Нас цікавить така класифікація видів аналізу:

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

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

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

a. протоколювання перемикання контекстів

b. протоколювання станів завдань

c. протоколювання статусів системних об'єктів.

3) Профілізація системи

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

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

Збір даних запускається або спеціальної високопріоритетних завданням, або за допомогою ISR (Interrupt Service Routine). Існує два рівня профілювання: профілювання завдання способом «процедура за процедурою» (procedure-by-procedure) і профілювання системи способом «завдання за завданням» (task-by-task). Основні параметри профілювання: частота вибірки (sample rate) - частота, з якою проводиться збір даних; частота аналізу (analysis rate) - частота, з якою проводиться аналіз наявних в буфері вибірок. Анализирующая процедура являє собою фонову задачу, яка підраховує середнє зі значень для задач і функцій з усіх вибірок буфера і значень, отриманих в ході попереднього аналізу.

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

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

4) «Посмертний» (post-mortem) аналіз

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



Висновок

Було розглянуто основні риси засобів активного тестування та моніторингу для розподілених систем реального часу, а також помилки, характерні для СРЧ, і способи їх виявлення.

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

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



Список джерел інформації

1. C.D. Locke, 'Fundamentals of Real-Time', Lockhead Martin, 1998

2. 'Realtime CORBA', White Paper -- Issue 1.0, 1996/Dec

2 'It's all a question of time…', Real-time magazine, 1997/4th Quarter

3 R.O'Farrel, 'Choosing a cross-debugging methodology', Embedded systems programming, 1997/Aug

4 K.Clohessy, 'Using object-oriented programming tools to build real-time embedded systems', Real-time engineering, 1996/Fall

5 IntelliJ_IDEA: веб-сайт. URL: https://jetbrains.ru/products/idea/

6 Интеграционное тестирование: веб-сайт. URL: https://ru.wikipedia.org/wiki/Интеграционное_тестирование

7 Тестирование программного обеспечения: веб-сайт. URL: https://ru.wikipedia.org/wiki/Тестирование_программного_обеспечения

Размещено на Allbest.ru

...