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

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

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

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

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

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

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

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

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

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

Інженер-автоматизатор забезпечення якості (англ. QA Automation engineer) — фахівець із забезпечення якості продукту, який використовує програмні засоби для створення тестів і перевірки результатів виконання. Основне завдання такого інженера — створювати автоматичні скрипти, які будуть перевіряти роботу програми на підставі тест-кейсів, написаних 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, Сі.

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

• Коли тестування повинно бути автоматизованим? [Архівовано 30 липня 2013 у Wayback Machine.]
• Практичний досвід автоматизованого тестування [Архівовано 24 квітня 2021 у Wayback Machine.]