Конспект лекцій для студентів напряму підготовки 050102 «Комп’ютерна інженерія» денної та заочної форм навчання



Сторінка1/4
Дата конвертації09.04.2017
Розмір0.59 Mb.
  1   2   3   4


Міністерство освіти і науки України



ТЕСТУВАННЯ КОМП'ЮТЕРНИХ ЗАСОБІВ
Конспект лекцій

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

6.050102 «Комп’ютерна інженерія»
денної та заочної форм навчання

Луцьк 2015

УДК 004.415.53(07)

ББК 32.811.4 Я 7

Т36


До друку ________________ Голова Навчально-методичної ради (підпис) Луцького НТУ.
Електронна копія друкованого видання передана для внесення в депозитарій Луцького НТУ ________________ директор бібліотеки.

(підпис)
Затверджено науково-методичною радою Луцького НТУ,

протокол № ___ від «___»________20__ року.
Рекомендовано до видання Навчально-методичною радою факультету комп’ютерних наук та інформаційних технологій Луцького НТУ,

протокол № ___ від «___»________20__ року.


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

протокол № ___ від «___»________20__ року.


Укладач: __________ О.І.Міскевич, асистент Луцького НТУ

К.Я.Бортник, к.т.н., доцент Луцького НТУ

(підпис)
Рецензент: __________ К.В..Мельник, кандидат технічних наук,

(підпис) доцент Луцького НТУ
Відповідальний _______ П.А. Пех, кандидат технічних наук,

за випуск: (підпис) доцент Луцького НТУ





Т– 36

Тестування комп’ютерних засобів [Текст]: конспект лекцій для студентів напряму 6.050102 «Комп’ютерна інженерія» усіх форм навчання / уклад. О.І.Міскевич, К.Я.Бортник – Луцьк: Луцький НТУ, 2015. – 44 с.


Видання містить конспект лекцій. Призначений для студентів напряму 6.050102 «Комп’ютерна інженерія» усіх форм навчання.

© О.І.Міскевич, К.Я. Бортник, 2015



ЗМІСТ


ТЕМА: МОДУЛЬНЕ ТЕСТУВАННЯ 17

ЛЕКЦІЯ № 1

ТЕМА: ОСНОВИ ТЕСТУВАННЯ
Слово testing може бути перекладене не лише як тестування, але і як випробування.

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

Наступні «історичні» періоди, що відображають прогрес у розумінні цілей тестування:

1) період до 1956 року - орієнтація на відлагодження;

2) період з 1957 по 1978 рр. - орієнтація на встановлення відповідності програмних систем початковим вимогам;

3) період з 1979 по 1982 рр. – орієнтація на виявлення дефектів, що залишилися після реалізації;

4) період з 1983 по 1987 рр. – орієнтація на аналіз, перевірку і тестування з метою оцінки якості програмних систем на всіх стадіях розробки;

5) період з 1988 по 1995 рр. – інтеграція дій по перевірці і тестуванню в життєвий цикл програмних систем з метою попередження появи дефектів на всіх стадіях розробки.

Тестування віднесено до основних процесів, але представлено не одним, а групою процесів. Крім того, ряд задач тестування розв'язуються в рамках інших процесів розробки, зокрема, задачі планування тестування розподілені по процесах: «Проектування архітектури системи», «Аналіз вимог до ПЗ», «Проектування ПЗ». Автономне і інтеграційне тестування ПЗ виконуються в рамках процесів «Побудова ПЗ» і «Інтеграція ПЗ», оскільки нерозривно з ними зв'язані.

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

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

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

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

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

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

Цілі і об'єкти спільно визначають критерій вибору тестів, як щодо його повноти - «який об'єм тестування достатній для досягнення встановленої мети?», так і його складу - «які тести повинні бути вибрані для досягнення встановленої мети?». Перше питання стосується вибору критерію покриття, а друге – критерію вибору типів тестів.

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

Ключові питання тестування:


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

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

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

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

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

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

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

Рівні тестування відповідно до об'єктів:

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

Традиційно виділяють три рівні тестування ПС: автономне або модульне (unit testing), інтеграційне (integrating testing) і системне (system testing). В стандарті ISO чотири рівні тестування:


  • модульне

  • інтеграційне

  • тестування ПЗ

  • системне

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

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

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

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

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

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

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

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



Види тестування програмної системи:

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

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

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

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

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

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

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

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

Види тестування:

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

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

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

Тестування безпеки (Security testing) полягає в перевірці можливості несанкціонованого доступу до програмних систем. Виконується шляхом моделювання можливих атак зовнішніх користувачів (у тому числі інших програмних систем) з метою «зламати» систему захисту.

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

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

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

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

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

Тестування продуктивності (Performance testing). Виконується для перевірки досягнення встановлених вимог до продуктивності або для оптимізації продуктивності. Іноді підрозділяється на наступні види:

- тестування (load testing) навантаження - перевірка працездатності ПС при очікуваних нормальних навантаженнях;

- тестування на стійкість (stress testing) - перевірка працездатності в нестандартних умовах (при надмірних і відсутніх завантаженнях);

- тестування об'єму (volume testing) - перевірка внутрішньопрограмних або системних обмежень, зв'язаних, наприклад, з великими масивами даних, граничними об'ємами БД і іншими характеристиками об'єму.

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

Порівняльне тестування (Back-to-back testing). Вид тестування, при якому один і той же набір тестів виконується на двох реалізованих версіях, а результати порівнюються. Особливо актуальний в ітераційних моделях розробки.

Тестування відновлення (Recovery testing). Проводиться для перевірки процедур відновлення системи після відмов.

Керована тестами розробка (Test-driven development). Підхід до розробки, згідно якому тести модулів створюються до початку їх кодування. Тести виконують роль прототипу модуля і замінника специфікації вимог. Підхід застосовується в екстремальному програмуванні (ХР).



ЛЕКЦІЯ № 2
ТЕМА: МЕТОДИ ТЕСТУВАННЯ. СТРАТЕГІЇ ТЕСТУВАННЯ
Якщо визначати тестування в його розширеному змісті як будь-яку перевірку програми, то методи тестування можна розділити на дві великі категорії:

Методи статичного тестування: без виконання програми (перевірка текстів, трасування текстів, інспекції). Інструменти тестування - аналізатори коду.

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

Методи динамічного тестування

Методи тестування розрізняються підходами до проектування тестів.

Традиційно методи динамічного тестування розділяють на дві категорії - «чорний ящик» (без доступу до початкового коду – “black box”) і «білий ящик» (з доступом до початкового коду – “white box”).

Докладніша класифікація методів тестування, базована на підходах до проектування тестів, зображена на рис. 2.1.



Рис. 2.1. Класифікація методів тестування



Методи тестування, базовані на досвіді і інтуїції.

Спеціалізоване тестування (Ad hoc). Це найбільш поширений (хоча і не систематичний) підхід, при якому тести розроблюються виходячи з інтуіції тестера і його досвіду в тестуванні подібних систем. Ефективність підходу повністю визначається майстерністю виконавця. Підхід не вимагає докладної специфікації функцій ПЗ, але і не забезпечує оцінювання повноти тестового покриття. Розвитком підходу можна вважати «дослідницьке тестування» (exploratory testing), основні принципи якого – поєднання вивчення програмного продукту з проектуванням тестів і їх виконанням. Таке тестування звичайно здійснюється незалежними тестерами стосовно завершених програмних продуктів.



Методи, базовані на специфікації

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

До основних методів функціонального тестування відносять:

таблиці рішень;

функціональні діаграми;

еквівалентне розбиття;

аналіз граничних значень;

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

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

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

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

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

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

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

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

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

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

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

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

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

Всі згадані методи функціонального тестування відносяться до «систематичних» методів на відміну від випадкових (стохастичних) і статистичних методів.

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



Методи, засновані на аналізі коду (або структурні).

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

Це основні методи, які використовуються на модульному рівні.

Методи цілеспрямованого пошуку помилок.

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

До основних методів цієї категорії відносяться:

припущення про помилки (error guessing);

підсів помилок (error seeding);

мутаційне тестування (mutation testing).

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

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

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

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



Методи, базовані на аналізі очікуваного використання.

До цієї категорії можна віднести два основних методи:

статистичне тестування;

тестування за операційним профілем.

При статистичному тестуванні вхідні дані для проектування тестів вибираються з вхідного простору відповідно до частоти їх появи в майбутніх сценаріях використання програми. При виконанні тестів фіксуються моменти відмов і обчислюються інтервали між відмовами MTBF (Mean Time Between Failure), звичайно в одиницях процесорного часу (CPU) або часу виконання. Отримана інформація використовується для оцінки надійності і прогнозування моменту завершення тестування. Метод застосовується на рівні системного тестування. Для визначення частоти використання функцій програми, а також моментів відмов, в код вставляються команди-лічильники.

Тестування за операційним профілем застосовується в рамках методології інженерії надійності (SRE, від Software Reliability Engineering) і називається методом SRET (від Software Reliability Engineered Testing). Методологія SRE охоплює повний цикл розробки програмних систем з підвищеними вимогами до надійності, а тестування SRET (є по суті статистичним) базується на впорядкуванні входів не лише за частотою, але і з урахуванням критичності функцій, режимів і наслідків відмов систем при експлуатації.

До категорії методів, базованих на аналізі очікуваного використання, можна віднести також метод тестування за сценаріями можливого використання, суть якого полягає в ідентифікації можливих сценаріїв роботи користувача і розробці по них сценаріїв тестування (test-сases). Цей метод застосовується в усіх сучасних інструментах автоматизації функціонального тестування програм, що мають графічний інтерфейс користувача. Він також використовується в методології RUP (Rational Unify Process), згідно якої сценарії тестування формуються на етапі аналізу і проектування за наборами «прецедентів» (use-сases), а також MSF.

Узагальненням даного методу можна вважати тестування на базі моделей (model-based testing, model-driven testing), вживане в рамках відповідного підходу до розробки (model-driven development).

Такі відомі підходи до тестування як тестування, базоване на ризику (risk-driven testing, risk-based testing), представляють не методи розробки тестів, а стратегії спрямованого тестування для мінімізації наборів тестів. Ці стратегії подібні тестуванню за операційним профілем, але проводяться методами систематичного тестування і враховують не тільки частоту використання, але і величину ризику відмови ПС.

Методи, що враховують специфіку програмної системи.

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

Виділено такі специфічні об’єкти тестування:

об'єктно-орієнтованих програм;

компонентів;

графічних інтерфейсів;

Web-застосувань;

систем реального часу;

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

Стратегії тестування, базовані на коді

Для цих стратегій відносять методи структурного тестування

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

Категорії методів:

- тестування потоку управління;

- тестування потоку даних;

- тестування циклів.

З кожним методом зв’язується критерій покриття, який визначає ступінь повноти тестування за цим методом.

В методах структурного тестування ці критерії називаються структурними критеріями покриття.
ЛЕКЦІЯ № 3

  1   2   3   4


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

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