Яку проблему вирішує автоматичне тестування користувальницького інтерфейсу?

Зараз ми розслідуємо автоматичне тестування користувальницького інтерфейсу (в даний час ми робимо автоматизовані тестування блоків та інтеграції).

Ми розглянули Selenium і Telerik і зупинилися на останньому як інструменті вибору завдяки своєму набагато більш гнучкому диктофону - і нам не дуже хочеться, щоб тестери писали занадто багато коду.

Однак я намагаюся зрозуміти загальну користь. Які погляди людей і які речі добре працюють, а що ні?

Наша система постійно розвивається, і ми регулярно випускаємо нові версії нашої (веб-платформи).

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

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

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

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

По-друге, якість квитків QA, які повернулися до команди Dev, були кращими. Замість "Сторінка зламалася, коли я натиснув кнопку" Надіслати ", ми отримали точний випадок, який не вдався, щоб ми могли побачити, що було внесено у форму. Команда з контролю якості також зробила крок далі, перевіривши всі випадки, які не вдалися, і перевірила інші сценарії на цій сторінці, щоб краще зрозуміти, що сталося.

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

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

Останнє, що ми з’ясували, - це те, що з деякими налаштуваннями команди QA ми також могли зробити тестування інжекцій SQL на нашому додатку. Ми виявили деякі вразливості, які нам вдалося швидко виправити.

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

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

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

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

ми не дуже хочемо, щоб тестери писали занадто багато коду.

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

і ми не хочемо, щоб тестери писали занадто багато коду

Ми застосували протилежний підхід. Ми хотіли, щоб код тестувальників писав.

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

1. Історії користувачів.

2. Операційна концепція. Як ця історія, ймовірно, буде працювати. Огляд дизайну.

3. Ескіз екрану: дизайн інтерфейсу. Як би це виглядало.

4. Сценарії Селену. Якщо всі сценарії спрацюють, ми готові до випуску.

5. Кодування та тестування, поки сценарій не працює.

Автоматизоване тестування - єдиний спосіб довести, що функціональність існує.

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

"Будь-яка функція програми без автоматизованого тесту просто не існує."

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

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

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

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

Ми розглянули Selenium і Telerik і зупинилися на останніх як інструменті вибору завдяки своєму набагато більш гнучкому диктофону

Я не впевнений, наскільки ви це заглянули. Звичайно, є й інші варіанти. Ви заглянули в Watir , WatiN , Sikuli, щоб назвати декілька?

і ми не хочемо, щоб тестери писали занадто багато коду.

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

Однак я намагаюся зрозуміти загальну користь. Які погляди людей і які речі добре працюють, а що ні?

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

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

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

Ми "думаємо", що це правильно зробити, але в і без того напруженому графіку шукаємо додаткову інформацію.

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

Ви праві, що регрес величезний. Також -

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

• ми повторно використали автоматизовані тестові сценарії для завантаження даних, щоб нам не довелося складати базу даних, щоб робити тестування великих розмірів

• тест на продуктивність

• багатотокові тести

• у веб-системах - обмін між браузерами та обмін між ОС. Що стосується узгодженості веб-переглядача, то важлива річ - потрапляння якомога ширшої бази.

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

Лише один приклад: точне вимірювання тривалості надання веб-сторінки

Використовуючи тести автоматизації, набагато простіше перевірити працездатність веб-браузера. Для вимірювання максимального часу відповіді, який ви, швидше за все, приймете, просто встановіть константу в тестових сценаріях та / або передайте її як функціональний параметр, наприклад, у цьому псевдокоді: $ sel-> wait_for_page_to_load ($ mypage, $ maxtime).

Тестування крос-браузера з низькими значеннями може бути досить освічуючим.

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

Автоматизоване тестування інтерфейсу користувача вирішує можливість:

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

Однак, як зазначають інші:

Telerik ...

інструмент вибору завдяки своєму набагато більш гнучкому диктофону

є червоним прапором для багатьох із нас.

Сценарії, записані таким чином, як правило, не є довгостроковим рішенням, оскільки:

• Ідентифікатор бази даних / об'єктів, як правило, змінюється від випадку до випадку
• Записані вручну сценарії часто покладаються на теги макета сторінки, які часто змінюються
• загальні дії потрібно буде писати знову і знову, замість того, щоб дозволяти повторне використання (див. підхід SitePriz & PageObject)
• іноді вам потрібно використовувати такі інструменти, як xpath, щоб отримати додаткову інформацію на основі інформації поточної сторінки. Простий записаний сценарій цього не зробить.
• розробники та тестери, які пишуть код, не рекомендуватимуть використовувати класи CSS, атрибути даних ID та HTML5, які є практикою, яка призведе до більш надійних тестів, які можна ремонтувати.

Telerik має деякі переваги, які слід враховувати:

• спрямований на мобільних клієнтів
• вбудовані інструменти для управління зростанням
• обробляє Android, iOS та Windows Phone

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

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

Я приходжу до цього з іншого походження. У моїх колишніх роботодавців ми розробили комерційні автоматизовані інструменти тестування (QALoad, QARun, TestPartner, SilkTest, SilkPerfomer).

Ми бачили автоматизоване тестування інтерфейсу користувача як виконання двох ролей:

1. Повне регресійне тестування

2. Автоматизована установка тестових середовищ

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

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

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

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

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

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

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

• Ви визначаєте, чи функціонує компонент відповідно до специфікації?
• Ви хочете перевірити всі різні можливі входи та виходи?
• стрес-тест компонент?
• Або ти намагаєшся перевірити, що "це працює"?

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

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

• Відсутність документації (наприклад: використання автоматизованого тестового бігуна для демонстрації існуючої функціональності)
• Застарілі вимоги через повзучість області (приклад: визначення розриву між вимогами та кодом шляхом захоплення екрана під час тестових запусків)
• Високий оборот розробників і тестерів (наприклад: зворотний застарілий інженерний JavaScript шляхом захоплення екрану під час тестових запусків із відкритим інструментом розробника)
• Визначення порушень стандартних угод про іменування за допомогою регресійних тестів XPath (приклад: пошук усіх вузлів атрибутів DOM для назви верблюдів)
• Розпізнавання отворів у безпеці, які може виявити лише комп'ютер (наприклад: вихід із однієї вкладки, одночасно надсилаючи форму в іншу)

Я хотів би поділитися досвідом нашої команди. Ми використовували власний інструмент тестування інтерфейсу користувача, Screenster, для тестування наших та веб-додатків наших клієнтів. Він зарекомендував себе як корисна альтернатива Selenium для візуальних завдань тестування / CSS. Screenster - це інструмент автоматизації тестів, який виконує порівняння на екранах екрана різних версій веб-сторінок. Спочатку він створює візуальну базову лінію для сторінки, знімаючи скріншот для кожної дії користувача. Під час наступного запуску він робить новий знімок екрана на кожному кроці, порівнює його з базовим і визначає відмінності.

Підводячи підсумки, Screenster має такі переваги: ​​Візуальна основна лінія: знімки екрана знімаються для кожного кроку користувача під час тестового запису Порівняння на екрані: Screenster порівнює зображення, зняті під час відтворення, із зображеннями з базової лінії та виділяє всі відмінності Smart CSS Selectors: тестер може вибрати Елементи CSS на знімках екрана та виконайте дії з ними - наприклад, позначте їх як ігноровані регіони, щоб виключити їх із подальшого порівняння