НОУ ІНТУЇТ | лекція | Основи тестування і налагодження Веб-додатків

1. 19.1. Тестування Веб-додатків
2. 19.1.2. Підходи до функціонального тестування Веб-додатків
3. 19.1.3. Тестування для користувача інтерфейсу
4. 19.1.3.1. ручне тестування
5. 19.1.3.2. Сценарії на формальних мовах

Анотація: У даній лекції розглядаються основи тестування Веб-приложени, а також налагодження HTML-коду, стилів CSS і JavaScript.

Презентацію до даної лекції Ви можете завантажити тут .

19.1. Тестування Веб-додатків

19.1.1. Вступ

Обчислювальні та комунікаційні системи використовуються все частіше і з кожним днем ​​все глибше входять в наше повсякденне життя. Компанії та окремі користувачі все більше залежать у своїй роботі від web-додатків. Веб-додатки з'єднують різні відділи всередині компаній, різні компанії і простих користувачів. Веб-додатки дуже динамічні, а їх функціональні можливості безперервно ростуть. Безперервно зростає потоковий трафік засобів інформації і запитів, що формуються переносними і вбудованими пристроями. Внаслідок цього зростає складність систем такого роду. Очевидно, що для розуміння, аналізу, розробки та управління такими системами потрібні кількісні методи і моделі, які допомагають оцінити різні сценарії функціонування, дослідити структуру і стан великих систем. Спостерігаються тенденції до постійного зростання попиту на Веб-служби. Таким чином, проблеми, пов'язані з недостатньою продуктивністю будуть виникати і в майбутньому, і, врешті-решт, вони стануть такими, що превалюють при плануванні і введенні в експлуатацію нових Веб-служб і збільшенні користувачів Інтернету. Веб-додатки стають все більш поширеними і все більш складними, граючи, таким чином, основну роль в більшості онлайнових проектів. Як і у всіх системах, заснованих на взаємодії між клієнтом і сервером, уразливості Веб-додатків зазвичай виникають через некоректну обробки запитів клієнта і / або недостатньої перевірки вхідної інформації з боку розробника.

У першій частині даної лекції ми розглянемо питання специфічні для тестування і налагодження Веб-додатків.

Будуть розглянуті принципи наступних підходів до тестування Веб-додатків [ 1 , 2 ]:

• функціональне тестування;
• тестування користувальницького інтерфейсу;
• перевірки зручності;
• навантажувальний і стресове тестування;
• перевірка посилань і HTML-коду;
• тестування безпеки.

Також буде наведено огляд засобів автоматизації тестування Веб-додатків.

З загальними питаннями тестування і верифікації інформаційних систем пропонується ознайомитися в курсі Інтернет Університету Інформаційних Технологій "Верифікація програмного забезпечення" [ 3 ].

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

19.1.2. Підходи до функціонального тестування Веб-додатків

Функціональне тестування (functional testing) - процес верифікації відповідності функціонування продукту його початковим специфікаціям [ 4 ]. Характерним прикладом може бути перевірка того, що програма підрахунку виплат по банківській позичці видає коректні викладки на будь-які введені суму позики і термін її повернення. Зазвичай подібні перевірки проводяться вручну, іноді до цього підключаються кінцеві користувачі в якості бета-тестерів. Однак програмні системи стають все складніше, а комбінації різних вхідних параметрів і підтримуваних операційних систем нерідко обчислюються десятками і сотнями.

Перерахуємо деякі з методів функціонального тестування веб-додатків [ 5 , 6 ]:

1. Record & Play - заснований на можливості засобів автоматизації тестування автоматично генерувати код.
2. Functional Decomposition - в основі лежить розбиття всіх компонент фреймворка за функціональною ознакою на бізнес-функції (реалізують / перевіряють бізнес-функціональність програми), user-defined функції (допоміжні функції, які ще мають прив'язку до тестованого з додатком або до конкретного проекту), утиліти ( функції загального призначення, не прив'язані до певної програми, технології, проекту).
3. Data-driven - заснований на тому, що до деякого тесту або групі тестів прив'язується джерело даних, і цей тест або набір тестів циклічно виконується для кожного запису з цього джерела даних. Цілком може застосовуватися в комбінації з іншими підходами.
4. Keyword-driven - являє собою фактично движок для обробки посилаються йому команд, а самі інструкції виносяться у зовнішній джерело даних.
5. Object-driven - заснований на тому, що основні ходові частини фреймворка реалізовані у вигляді об'єктів, що дозволяє збирати тести по цеглинці.
6. Model-based - заснований на тому, що тестоване додаток (або його частини) описується у вигляді деякої поведінкової моделі.

Найпоширенішим є підхід, званий Capture & Playback (інші назви - Record & Playback, Capture & Replay) [ 6 ]. Суть цього підходу полягає в тому, що сценарії тестування створюються на основі роботи користувача з тестованим додатком. Інструмент перехоплює і записує дії користувача, результат кожного дії також запам'ятовується і служить еталоном для наступних перевірок. При цьому в більшості інструментів, що реалізують цей підхід, впливу (наприклад, натискання кнопки миші) зв'язуються ні з координатами поточного становища миші, а з об'єктами HTML-інтерфейсу (кнопки, поля введення і т.д.), на які відбувається вплив, і їх атрибутами. При тестуванні інструмент автоматично відтворює раніше записані дії та порівнює їх результати з еталонними, точність порівняння може налаштовуватися. Можна також додавати додаткові перевірки - задавати умови на властивості об'єктів (колір, розташування, розмір і т.д.) або на функціональність програми (вміст повідомлення і т.д.).

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

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

19.1.3. Тестування для користувача інтерфейсу

Частина програмної системи, що забезпечує роботу інтерфейсу з користувачем - один з найбільш нетривіальних об'єктів для верифікації [ 7 ]. Нетривіальність полягає в двоякому сприйняття терміна "призначений для користувача інтерфейс".

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

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

Функціональне тестування користувальницького інтерфейсу складається з п'яти фаз [ 7 ]:

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

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

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

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

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

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

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

19.1.3.1. ручне тестування

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

В табл. 19.1 наведено приклад сценарію для ручного тестування користувальницького інтерфейсу [ 7 ].

Таблиця 19.1. Приклад сценарію для ручного тестування користувальницького інтерфейсу № п / п Дія Реакція системи Результат 1 Клацніть на значку "Система" і виберіть пункт меню "Адміністрування системи". З'явиться вікно введення логіна і пароля Вірно 2 Введіть в вікно, що з'явилося введення ім'я користувача "admin" і пароль "admin". Потім натисніть кнопку "OK". З'явиться вікно "Адміністрування системи". У верхньому правому куті повинно бути виведено ім'я увійшов користувача admin. Невірно Вікно має назву "Управління системою"

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

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

19.1.3.2. Сценарії на формальних мовах

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

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

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

І при передачі інформації в тестований інтерфейс і при отриманні інформації для аналізу можуть використовуватися два способи доступу до елементів інтерфейсу [ 7 ]:

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

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

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