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



Скачати 99.64 Kb.
Дата конвертації08.06.2018
Розмір99.64 Kb.

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

ТЕРНОПІЛЬСЬКИЙ НАЦІОНАЛЬНИЙ ЕКОНОМІЧНИЙ УНІВЕРСИТЕТ

ФАКУЛЬТЕТ КОМП’ЮТЕРНИХ ІНФОРМАЦІЙНИХ ТЕХНОЛОГІЙ

ІНДИВІДУАЛЬНЕ ЗАВДАННЯ

на тему:

“СИСТЕМИ ТЕСТУВАННЯ РЕАЛЬНОГО ЧАСУ”

Виконав студент

групи ПЗАС-41

Октович Олександр

Перевірив

Кочан Р.О.

Тернопіль 2008

ЦIЛІ, ПРІНЦИПИ І ЕТАПИ ТЕСТУВАННЯ

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

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

Інше визначення тестування ( у м. Майерса ) тестування - це процес виконання програми з метою виявлення в ній помилок. Таке визначення мети стимулює пошук помилок в програмах. Звідси також ясно, що “вдалим" тестом є такою, на якому виконання програми завершилося з помилкою. Навпаки, “невдалим можна назвати тест, що не дозволив виявити помилку в програмі.

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

У Майерса сформульовані також основні принципи організації тестування:

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

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

3) по тих же міркуваннях організація - розробник програмного забезпечення не повинна “одноосібно " його тестувати ( повинні існувати організації, що спеціалізуються на тестуванні програмних засобів );

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

5) необхідно ретельно підбирати тест не тільки для правильних ( передбачених ) вхідних даних, але і для неправильних (непередбачених);

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

7) потрібно зберігати використані тести (для підвищення ефективності повторного тестування програми після її модифікації або установки у замовника);

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

9) потрібно враховувати так званий “принцип скупчення помилок": імовірність наявності не виявлених помилок в деякій частині програми прямо пропорційна числу помилок, вже виявлених в цій частині;

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

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

8

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



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

Але навіть якщо передбачити, що вдалося досягнути повного структурного тестування деякої програми, в ній проте можуть міститися помилки, так як

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

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

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

У тестування багатомодульных програмних комплексів можна виділити чотири етапи:

1) тестування окремих модулів;

2) спільне тестування модулів;

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

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

На перших двох етапах використовуються передусім методи структурного тестування, так як

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

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

При тестуванні як окремих модулів, так і їх комплексів повинні бути вирішені дві задачі:

1) побудова ефективної безлічі тестів;

2) вибір способу комбінування (збирання) модулів при створенні трестируємого варіанту програми.

СТРУКТУРНЕ ТЕСТУВАННЯ

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

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

Більш сильним критерієм є так званий критерій С1: кожна гілка алгоритму (кожний перехід) повинна бути пройдена (виконана) хоч би один раз. Для більшості мов програмування покриття переходів забезпечує і покриття операторів, але, наприклад, для програм на мові ПЛ/1 додатково до покриття всіх гілок потрібно всіх додаткових точок входу в процедуру (що задаються операторами ENTRY) і всіх ON - одиниць.

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

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

або SWITCH ) містили гілки ELSE або DEFAULT, хоч би і пусті. У цьому випадку всі гілки алгоритму, ті, що не виконувалися на даному тесті будуть “видимі" з таблиці частоти виконання операторів перетвореної програми.

Актуальною залишається задача створення інструментальних засобів, що дозволяють:

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

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

3) підтримувати більш могутні критерії повноти структурного тестування.

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

Огляд методів проектування тестів при функціоналному тестуванні почнемо з методу зквівалентного роздріблення.

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

1) зменшувати (більш ніж на одиницю) число інших тестів, які повинні бути разроблені для досягнення зазделегідь поставленої мети “задовільного" тестування;

2) покривати собою значну частину інших можливих тестів.

Іншими словами:

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

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

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

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

виділення по зовнішній специфікації класів еквівалентності;

побудова безлічі тестів.

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

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

кожному класу привласнюється свій номер;

проектуються тести для ПКЕ таким чином, що кожний тест покриває як можна більше ще не покритих ПКЕ, доти, поки все ПКЕ не будуть покриті;

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

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

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

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

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

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

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

1) побудувати тести для кордонів області допустимих значень вхідних даних і тести з недопустимими значеннями, відповідними незначному виходу за межі цієї області (наприклад, для області [-1.0; 1.0] будуємо тести -1.0; 1.0; -1.001; 1.001);

2) побудувати тести для мінімального і максимального значень вхідних умов, що визначають дискретну безліч допустимих значень вхідних даних, і тести для значень, великих або менших цих величин (наприклад, якщо вхідний файл може містити від 1 до 225 записів, то вибираються тести для порожнього файла, що містить 1, 255 і 256 записів);

3) використати правило 1 для кожної вихідної умови (наприклад, програма обчислює щомісячну витрату приватної особи або невеликого підприємства, мінімум якого 0.00 $, а максимум 1165.50 $; тоді необхідне построїти тести, що викликають негативну витрату, витрати, рівну 0.00 $ і 1165.50 $, і витрату, більшу 1165.50 $);

4) використати правило 2 для кожної вихідної умови (наприклад, програма шукає і відображає на екрані дисплея найбільш відповідні, в залежності від вхідної умови, реферати статей, але не більш чотирьох; тоді необхідно побудувати тести, що приводять до відображення 0, 1, 4 рефератів і спроб помилкового відображення 5 рефератів);

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

6) спробувати знайти і перевірити тестами інші граничні умови.

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

Для ілюстрації необхідності аналізу граничних умов приведемо тривіальний приклад. Нехай є програма, що здійснює введення трьох чисел що інтерпретує їх як довжину сторін трикутника і що виводить повідомлення про тип трикутника (“різносторонній", “рівнобедрений" або “рівносторонній "). Допустимо також, що в програмі міститься помилка: при перевірці умови побудови трикутника (сума довжин будь-яких двох сторін повинна бути більше третьою) використовується операція відношення >= замість >. При проектуванні тестів по методу еквівалентного роздроблення будуть побудовані тести для випадків можливості побудови трикутника (наприклад, 3, 4, 5) і неможливості його побудови (наприклад, 1, 2, 4), тобто помилка в програмі не буде виявлена (на вхідні дані 1, 2, 3 буде виведене повідомлення “різносторонній трикутник"). Але подібний тест буде отриманий при використанні методу аналізу граничних умов.

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

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



Функціональна діаграма - це текст на деякій формальній мові, на яку транслюється специфікація, складена на природному або напівформальному мовах.
Каталог: my downloads -> learning
learning -> Технологія швидкого тестування
learning -> Методичні вказівки до виконання курсового проекту з дисципліни „ Програмна інженерія" Спеціальність 050207 „Економічна кібернетика"
learning -> Лекційний курс
learning -> Робоча програма з дисципліни "Системний аналіз та проектування комп’ютерних інформаційних систем"
learning -> 4. Нехай в області d задана функція, що є дійсною частиною аналітичної функції
learning -> Та різницеві рівняння
learning -> Тема Предмет І метод історії економіки та економічної думки
learning -> Методичні вказівки до проведення виробничої практики для студентів напряму підготовки 030502 „Економічна кібернетика / Уклад. О. М. Ляшенко: тнеу, 2011. 114 с
learning -> Основні поняття


Поділіться з Вашими друзьями:


База даних захищена авторським правом ©referatu.in.ua 2017
звернутися до адміністрації

    Головна сторінка