За історії інформатики на тему

Санкт Петербурзький державний університет інформаційних технологій механіки і оптики

реферат

За історії інформатики на тему

"Історія розвитку методології тестування при розробці програмного забезпечення"

Санкт-Петербург

200 9 г

Зміст

Вступ. 3

Поняття тестування. 4

Еволюція тестування. 6

Види тестування, що використовуються в даний час. 8

Автоматизоване тестування. 12

Перспективи розвитку тестування. 16

Висновок. 18

Список літератури .. 19

Вступ

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

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

поняття тестування

Тестувати можна все:

· Роботу програми

· Якість її коду і зрозумілість коментарів

· швидкодію

· Стійкість під великим навантаженням

· Витрата ресурсів (пам'яті, диска, втрати цих ресурсів)

· Взаємодія з іншими програмами

· Стабільність роботи

· Можливість роботи на інших платформах

· Зручність інтерфейсу

· Документацію до програми (смислові і граматичні помилки, зрозумілість і повноту)

· Роботу через мережу, роботу апаратного забезпечення і т.п.

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

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

• локалізацію помилок

• знаходження причин помилок

• коригування програми.

Тестування поділяють на статичну і динамічну:

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

· Динамічне тестування здійснює виявлення помилок на виконується програмою.

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

Тестування вирішує кілька основних завдань:

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

· Підтверджує, що програма здатна виконуватися у всіх заявлених режимах і на всіх підтримуваних ОС або Web-браузерах коректно;

· Чи гарантує, що зберігаються і обробляються дані надійно захищені від стороннього доступу і "злому";

· Визначає, яка максимальне навантаження на сервер, локальну мережу, БД може бути коректно оброблена додатком;

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

еволюція тестування

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

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

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

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

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

Види тестування, що використовуються в даний час

рівні тестування

· Модульне тестування.

· Інтеграційний тестування.

· Системне тестування.

модульне тестування

· Модульне тестування - це тестування програми на рівні окремо взятих модулів, функцій або класів.

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

· Модульне тестування проводиться за принципом "білого ящика"

· Модульне тестування зазвичай має на увазі створення навколо кожного модуля певного середовища

виявлені помилки

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

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

інтеграційне тестування

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

Системне тестування

• Основне завдання системного тестування - виявлення дефектів, пов'язаних з роботою системи в цілому:

· Неправильне використання ресурсів системи

· Непередбачені комбінації даних користувача рівня

· Несумісність з оточенням

· Непередбачені сценарії використання

· Відсутня або неправильна функціональність

· Незручність в застосуванні тощо.

• Системне тестування проводиться над проектом в цілому за допомогою методу «чорного ящика».

Тестування «білого ящика» і «чорного ящика»

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

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

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

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

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

Розрізняють такі види тестування:

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

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

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

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

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

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

Автоматизоване тестування

Автоматизоване тестування, це не тільки і не просто виконання тестів. Автоматизація може бути представлена ​​в більшості процесів тестування, починаючи від планування і закінчуючи тим самим запуском тестів.

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

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

Контроль помилок. Сюди відносяться багтрекінговие системи всіляких варіацій.

Створення тестів. Мається на увазі попередня автогенерація: на основі коду - для unit-тестів, на основі функціональних вимог - для ручних тестів, генерація за принципом record'n'play і т.п.

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

Виконання тестів. Запуск тестових скриптів і аналіз отриманих результатів.

Цілі автоматизованого тестування:

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

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

Конфігураційне тестування - виконання одних і тих же тестів в різних умовах. Тобто коли один або кілька компонентів архітектури системи потрібно перевірити в різному оточенні, зазвичай заявленому в початкових вимогах. Наприклад: підтримка СУБД від різних виробників, робота в різних клієнтських браузерах, використання в декількох ОС і т.п. Тобто якийсь аналог регресійного тестування, але в рамках однієї версії системи. Крім засобів контролю за виконанням робіт, в даному випадку, не зайвою буває можливість автоматичного порівняння отриманих результатів виконання сценаріїв в різних конфігураціях.

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

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

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

По-перше, це unit-тестування. Чи не модульне в загальному розумінні, а техніка написання тестів розробниками на основі і для вихідного коду. Найбільш активно зараз про неї говориться в agile-методологіях. Хоча і в класичних процесах розробки може приносити багато користі, якщо правильно почати використовувати.

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

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

Автоматизоване тестування завжди має позитивний бік:

• Більше покриття коду;
• Тест не буде пропущений;
• Тести містить одні й ті ж кроки;

так і мінуси:

• Помилки в основному знаходяться при створенні скрипта;
• Скрипти не дозволяють відхилень;
• Скрипти також можуть містити помилки.

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

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

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

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

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

1. Автоматизація може застосовуватися в більшості процесів і на всіх рівнях тестування.
2. Ручне та автоматизоване тестування - це взаємодоповнюючі технології.
3. Автоматизоване тестування має на увазі участь людини.
4. Автоматизоване тестування вимагає додаткових інвестицій, але дозволяє підвищити якість продукту.
5. Автоматизоване тестування - це розробка (програмування).
6. Автоматизоване тестування гарантує детерміновану перевірку функціональності.
7. Супровід автоматизованих тестів вимагає великих додаткових витрат при активному зміні тестованої системи.

Перспективи розвитку тестування

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

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

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

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

висновок

Статистика:

• Обсяг світового ринку тестування програмного забезпечення - 13 мільярдів доларів (за статистикою International Data Corporation - IDC)
• Обсяг ринку зовнішнього (outsource) тестування - близько 6.1 мільярда доларів (за статистикою Dataquest)
• Обсяг ринку інструментів для автоматизованого тестування - близько 1.2 мільярдів доларів, і зростає щорічно на 14.9% (за статистикою IDC)
• Розробка програмного продукту становить до 40% середньостатистичного бюджету програмного продукту, його тестування складає близько 40% бюджету розробки (за статистикою LogiGear)
• Обсяг ринку офшорного тестування і підтримки програмного забезпечення перевищує 3.4 мільярди доларів (за статистикою IDC)

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

Список літератури

1. С. Канер, Д. Фолк, Е. Нгуєн. Тестування програмного забезпечення. - К .: Диасофт, 2000. - 544 с.

2. Г. Майерс. Мистецтво тестування програм. - М .: «Фінанси і статистика», 1982. - 176 с.

3. Р. Калбертсон, К. Браун, Г. Кобб. Швидке тестіпрованіе. - М .: Видавничий дім «Вільямс», 2002. - 384 с.

4. Hung Q. Nguyen, Bob Johnson, Michael Hackett. Testing Applications on the Web. 2001. - 402 с.

5. http://software-testing.ru/ Портал фахівців з тестування та забезпечення якості ПЗ.

6. http://www.softwaretestinghelp.com

7. http://www.idc.com Російський сайт компанії International Data Corporation