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

Історія 

Перші спроби «автоматизації» з'явилися в епоху операційних систем DOS і CP/M. Тоді вона полягала у видачі додатком команд через командний рядок і аналізі результатів. Трохи пізніше додалися віддалені виклики через API для роботи з мережі. Вперше про автоматизоване тестування згадується в книзі Фредеріка Брукса «Міфічний людино-місяць», де йдеться про перспективи використання модульного тестування. Але по-справжньому автоматизація тестування стала розвиватися тільки в 1980-х роках.

Види автоматизованого тестування 

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

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

GUI-автоматизація 

GUI-автоматизація розвивалася протягом 4 поколінь інструментів і технік:

  Утиліти запису і відтворення (capture/playback tools) — записують дії тестувальника під час ручного тестування. Вони дозволяють виконувати тести без прямої участі людини протягом тривалого часу, значно збільшуючи продуктивність і усуваючи «безглузде» повторення одноманітних дій під час ручного тестування. У той же час, будь-яка мала зміна ПЗ, що тестується вимагає перезапису ручних тестів. Тому це перше покоління інструментів не ефективне і не масштабоване.

 Сценарії (Scripting) — форма програмування на мовах, спеціально розроблених для автоматизації тестування ПЗ — пом'якшує багато проблем capture/playback tools. Але розробкою займаються програмісти високого рівня, які працюють окремо від тестувальників, що безпосередньо запускають тести. До того ж скрипти найбільше підходять для тестування GUI і не можуть бути впровадженими, пакетними або взагалі будь-яким чином об'єднані в систему. Нарешті, зміни в ПЗ, яке тестується вимагають складних змін у відповідних скриптах, і підтримка все більше зростаючої бібліотеки тестуючих скриптів стає зрештою непереборним завданням.

 Data-driven testing — методологія, яка використовується в автоматизації тестування. Особливістю є те, що тестові скрипти виконуються і верифікуються на основі даних, які зберігаються в центральному сховищі даних або БД. Роль БД можуть виконувати ODBC-ресурси, csv або xls файли і т. д. Data-driven testing — це об'єднання декількох взаємодіючих тестових скриптів та їх джерел даних в фреймворк, який використовується в методології. У цьому фреймворку змінні використовуються як для вхідних значень, так і для вихідних перевірочних значень: у тестовому скрипті зазвичай закодовані навігація по додатком, читання джерел даних, ведення логів тестування. Таким чином, логіка, яка буде виконана в скрипті, також залежить від даних.

 Keyword-based автоматизація передбачає поділ процесу створення кейсів на 2 етапи: етап планування та етап реалізації.

Модульне тестування 
Модульне тестування () — це метод тестування програмного забезпечення, який полягає в окремому тестуванні кожного модуля коду програми. Модулем називають найменшу частину програми, яку може бути протестованою. У процедурному програмуванні модулем вважають окрему функцію або процедуру. В об'єктно-орієнтованому програмуванні — інтерфейс, клас. Модульні тести, або unit-тести, розробляються в процесі розробки програмістами та, іноді, тестувальниками білої скриньки (white-box testers).

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

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

Додатки 

Для автоматизації тестування існує велика кількість додатків. Деякі з них:

 HP LoadRunner, HP QuickTest Professional, HP Quality Center
 Segue SilkPerformer
 IBM Rational FunctionalTester, IBM Rational PerformanceTester, IBM Rational TestStudio
 SmartBear Software TestComplete

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

 установка продукту
 створення тестових даних
 GUI-взаємодія
 визначення проблеми

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

Інструментарій 

 JUnit — тестування додатків для Java
 NUnit — порт JUnit під .NET
 xUnit — тестування додатків для .NET
 TestNG — тестування додатків для Java
 Selenium — тестування додатків HTML; підтримує браузери Internet Explorer, Mozilla Firefox, Opera, Google Chrome, очікується підтримка Safari.
 WatiN — тестування вебдодатків; підтримує браузери Internet Explorer, Mozilla Firefox
 TOSCA Testsuite — тестування додатків HTML, .NET, Java, SAP
 UniTESK — тестування додатків на Java, Сі.

Див. також 

 Ручне тестування

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

Тестування програмного забезпечення
Автоматизоване тестування програмного забезпечення — частина процесу тестування на етапі контролю якості в процесі розробки програмного забезпечення . Воно використовує програмні засоби для виконання тестів і перевірки результатів виконання , що допомагає скоротити час тестування і спростити його процес . Історія Перші спроби « автоматизації » з'явилися в епоху операційних систем DOS і CP / M . Тоді вона полягала у видачі додатком команд через командний рядок і аналізі результатів . Трохи пізніше додалися віддалені виклики через API для роботи з мережі . Вперше про автоматизоване тестування згадується в книзі Фредеріка Брукса « Міфічний людино - місяць » , де йдеться про перспективи використання модульного тестування . Але по-справжньому автоматизація тестування стала розвиватися тільки вх роках . Види автоматизованого тестування Існує два основних підходи до автоматизації тестування : тестування на рівні коду і GUI - тестування . До першого типу належить , зокрема , модульне тестування . До другого — імітація дій користувача за допомогою спеціальних тестових фреймворків . Найпоширенішою формою автоматизації є тестування додатків через графічний інтерфейс користувача . Популярність такого виду тестування пояснюється двома факторами : по-перше , додаток тестується тим же способом , яким його буде використовувати людина , по-друге , можна тестувати додаток , не маючи при цьому доступу до вихідного коду . GUI - автоматизація GUI - автоматизація розвивалася протягомпоколінь інструментів і технік : Утиліти запису і відтворення ( capture/playback tools ) — записують дії тестувальника під час ручного тестування . Вони дозволяють виконувати тести без прямої участі людини протягом тривалого часу , значно збільшуючи продуктивність і усуваючи « безглузде » повторення одноманітних дій під час ручного тестування . У той же час , будь-яка мала зміна ПЗ , що тестується вимагає перезапису ручних тестів . Тому це перше покоління інструментів не ефективне і не масштабоване . Сценарії ( Scripting ) — форма програмування на мовах , спеціально розроблених для автоматизації тестування ПЗ — пом'якшує багато проблем capture/playback tools . Але розробкою займаються програмісти високого рівня , які працюють окремо від тестувальників , що безпосередньо запускають тести . До того ж скрипти найбільше підходять для тестування GUI і не можуть бути впровадженими , пакетними або взагалі будь-яким чином об'єднані в систему . Нарешті , зміни в ПЗ , яке тестується вимагають складних змін у відповідних скриптах , і підтримка все більше зростаючої бібліотеки тестуючих скриптів стає зрештою непереборним завданням . Data-driven testing — методологія , яка використовується в автоматизації тестування . Особливістю є те , що тестові скрипти виконуються і верифікуються на основі даних , які зберігаються в центральному сховищі даних або БД . Роль БД можуть виконувати ODBC - ресурси , csv або xls файли і т . д . Data-driven testing — це об'єднання декількох взаємодіючих тестових скриптів та їх джерел даних в фреймворк , який використовується в методології . У цьому фреймворку змінні використовуються як для вхідних значень , так і для вихідних перевірочних значень : у тестовому скрипті зазвичай закодовані навігація по додатком , читання джерел даних , ведення логів тестування . Таким чином , логіка , яка буде виконана в скрипті , також залежить від даних . Keyword-based автоматизація передбачає поділ процесу створення кейсів наетапи : етап планування та етап реалізації . Модульне тестування Модульне тестування ( ) — це метод тестування програмного забезпечення , який полягає в окремому тестуванні кожного модуля коду програми . Модулем називають найменшу частину програми , яку може бути протестованою . У процедурному програмуванні модулем вважають окрему функцію або процедуру . В об'єктно - орієнтованому програмуванні — інтерфейс , клас . Модульні тести , або unit - тести , розробляються в процесі розробки програмістами та , іноді , тестувальниками білої скриньки ( white-box testers ) . Професія Інженер - автоматизатор забезпечення якості ( ) — фахівець із забезпечення якості продукту , який використовує програмні засоби для створення тестів і перевірки результатів виконання . Основне завдання такого інженера — створювати автоматичні скрипти , які будуть перевіряти роботу програми на підставі тест - кейсів , написаних QA - автоматизатором . Це допомагає скоротити час тестування і спростити його процес . Висновок Однією з головних проблем автоматизованого тестування є його трудомісткість : попри те , що воно дозволяє усунути частину рутинних операцій і прискорити виконання тестів , великі ресурси можуть витрачатися на оновлення самих тестів . Це відноситься до обох видів автоматизації . При рефакторінгу часто буває необхідно оновити і модульні тести , і зміна коду тестів може зайняти стільки ж часу , скільки і зміна основного коду . З іншого боку , при зміні інтерфейсу програми необхідно заново переписати всі тести , які пов'язані з оновленими вікнами , що при великій кількості тестів може відняти значні ресурси . Додатки Для автоматизації тестування існує велика кількість додатків . Деякі з них : HP LoadRunner , HP QuickTest Professional , HP Quality Center Segue SilkPerformer IBM Rational FunctionalTester , IBM Rational PerformanceTester , IBM Rational TestStudio SmartBear Software TestComplete Використання цих інструментів допомагає тестувальникам автоматизувати наступні задачі : установка продукту створення тестових даних GUI - взаємодія визначення проблеми Однак автоматичні тести не можуть повністю замінити ручне тестування . Автоматизація всіх випробувань — дуже дорогий процес , і тому автоматичне тестування є лише доповненням ручного тестування . Найкращий варіант використання автоматичних тестів — регресійне тестування . Інструментарій JUnit — тестування додатків для Java NUnit — порт JUnit під \ . NET xUnit — тестування додатків для \ . NET TestNG — тестування додатків для Java Selenium — тестування додатків HTML ; підтримує браузери Internet Explorer , Mozilla Firefox , Opera , Google Chrome , очікується підтримка Safari . WatiN — тестування вебдодатків ; підтримує браузери Internet Explorer , Mozilla Firefox TOSCA Testsuite — тестування додатків HTML , \ . NET , Java , SAP UniTESK — тестування додатків на Java , Сі . Див . також Ручне тестування Посилання Коли тестування повинно бути автоматизованим ? Практичний досвід автоматизованого тестування Тестування програмного забезпечення