Знаймо

Додати знання

приховати рекламу

Цей текст може містити помилки.

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



План:


Введення

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


1. Введення

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

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

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

З точки зору ISO 9126, Якість (програмних засобів) можна визначити як сукупну характеристику досліджуваного ПЗ з урахуванням таких складових:

  • Надійність
  • Сопровождаемость
  • Практичність
  • Ефективність
  • Мобільність
  • Функціональність

Більш повний список атрибутів і критеріїв можна знайти в стандарті ISO 9126 Міжнародної організації зі стандартизації. Склад і зміст документації, супутньої процесу тестування, визначається стандартом IEEE 829-1998 Standard for Software Test Documentation.


2. Історія розвитку тестування програмного забезпечення

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

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

На початку 1970-х тестування ПО позначалося як "процес, спрямований на демонстрацію коректності продукту" або як "діяльність з підтвердження правильності роботи ПЗ". У зароджувалася програмної інженерії верифікація ПО значилася як "доказ правильності". Хоча концепція була теоретично перспективною, на практиці вона вимагала багато часу і була недостатньо всеохоплюючою. Було вирішено, що доказ правильності - неефективний метод тестування ПЗ. Проте, в деяких випадках демонстрація правильної роботи використовується і в наші дні, наприклад, приймально-здавальні випробування. У другій половині 1970-х тестування уявлялося як виконання програми з наміром знайти помилки, а не довести, що вона працює. Успішний тест - це тест, який виявляє раніше невідомі проблеми. Даний підхід прямо протилежний попередньому. Зазначені два визначення є "парадокс тестування", в основі якого лежать два протилежні твердження: з одного боку, тестування дозволяє переконатися, що продукт працює добре, а з іншого - виявляє помилки в ПЗ, показуючи, що продукт не працює. Друга мета тестування є більш продуктивною з точки зору поліпшення якості, так як не дозволяє ігнорувати недоліки ПО.

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

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

У 2000-х з'явилося ще ширше визначення тестування, коли в нього було додано поняття "оптимізація бізнес-технологій" (en: business technology optimization, BTO). BTO спрямовує розвиток інформаційних технологій відповідно до цілей бізнесу. Основний підхід полягає в оцінці та максимізації значущості всіх етапів життєвого циклу розробки ПО для досягнення необхідного рівня якості, продуктивності, доступності.


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

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

По об'єкту тестування:

За знання системи:

За ступенем автоматизації:

За ступенем ізольованості компонентів:

За часом проведення тестування:

За ознакою позитивності сценаріїв:

  • Позитивне тестування (positive testing)
  • Негативне тестування (negative testing)

За ступенем підготовленості до тестування:

  • Тестування з документації (formal testing)
  • Тестування ad hoc або інтуїтивне тестування (ad hoc testing)

4. Рівні тестування

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

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


5. Статичний і динамічний тестування

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

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

Також до статичного тестування відносять тестування вимог, специфікацій, документації.


6. Регресійне тестування

Основна стаття: Регресійне тестування

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


7. Тестові скрипти

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

8. Тестування "білого ящика" і "чорного ящика"

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

При тестуванні білого ящика ( англ. white-box testing , Також говорять - прозорого ящика), розробник тесту має доступ до вихідного коду програм і може писати код, який пов'язаний з бібліотеками тестованого ПЗ. Це типово для юніт-тестування ( англ. unit testing ), При якому тестуються тільки окремі частини системи. Воно забезпечує те, що компоненти конструкції - працездатні й стійкі, до певної міри. При тестуванні білого ящика використовуються метрики покриття коду.

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

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

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

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


8.1. Покриття коду

Основна стаття: Покриття коду

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

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

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


9. Цитати

  • "Тестування програм може використовуватися для демонстрації наявності помилок, але воно ніколи не покаже їх відсутність." - Дейкстра, 1970 р.

Література

  • Лайза Кріспін, Джанет Грегорі Гнучке тестування: практичне керівництво для тестувальників ПЗ і гнучких команд = Agile Testing: A Practical Guide for Testers and Agile Teams - М .: "Вільямс", 2010. - 464 с. - (Addison-Wesley Signature Series). - 1000 прим . - ISBN 978-5-8459-1625-9.
  • Канер Ким, Фолк Джек, Нгуен Енг Кек Тестування програмного забезпечення. Фундаментальні концепції менеджменту бізнес-додатків - Київ: ДиаСофт, 2001. - 544 с. - ISBN 9667393879.
  • Калбертсон Роберт, Браун Кріс, Кобб Гері Швидке тестування - М .: "Вільямс", 2002. - 374 с. - ISBN 5-8459-0336-X.
  • Синіцин С. В., Налютін Н. Ю. Верифікація програмного забезпечення - М .: БИНОМ, 2008. - 368 с. - ISBN 978-5-94774-825-3.
  • Бейзер Б. Тестирование чёрного ящика. Технологии функционального тестирования программного обеспечения и систем - СПб. : Питер, 2004. - 320 с. - ISBN 5-94723-698-2.

Цей текст може містити помилки.

Схожі роботи | скачати

Схожі роботи:
Розробка програмного забезпечення
Проектування програмного забезпечення
Портування програмного забезпечення
Впровадження програмного забезпечення
Супровід програмного забезпечення
Локалізація програмного забезпечення
Архітектура програмного забезпечення
Метрика програмного забезпечення
Якість програмного забезпечення
© Усі права захищені
написати до нас