Автоматизоване тестування UI: стисло про головне

14 хв. читання

Авторка: Ляшенко Дар'я, Senior AQA Engineer у компанії Svitla Systems.

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

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

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

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

Підходи до тестування UI у вебсервісах

Тут дійсно є з чого вибрати, проте першими на думку спадають два найбільш поширені підходи до тестування UI: «запис-відтворення» (record-and-playback) і тестування на основі моделей (model-based testing). Розгляньмо кожен окремо.

Тестування Record-and-playback

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

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

Тестування на основі моделей

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

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

Тестування на основі моделей заощаджує час та гроші; його легко підлаштувати під різні середовища, машини, браузери тощо. Якщо знадобиться покрити нові функції, зазвичай це не спричинить таких додаткових витрат, як у тестуванні record-and-play. І останнє, але не менш важливе: завдяки методу model-based легко виявляти та виправляти помилки.

Інструменти

Selenium IDE

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

Плюси:

  • Запис UI скриптів для розповсюджених браузерів;
  • Групування тестів;
  • Підтримує різні мови програмування: Java, Python, Ruby та інші;
  • Працює на багатьох платформах (Windows, Linux, IOS);
  • Підтримує паралельний «прогон» тестів;
  • Open source;
  • Розвинене ком'юніті з великою кількістю технічних форумів.

Мінуси:

  • Можуть виникнути деякі проблеми з тестуванням у браузерах, оскільки на ранніх стадіях його розробляли для Firefox;
  • Важко стабільно ідентифікувати динамічні елементи;
  • Дещо складна документація;
  • Призначений тільки для вебу.

Watir Webdriver (+ rspec)

Watir (тестування вебзастосунків за допомогою Ruby) — це бібліотека для Ruby, яка має відкритий код. Її можна використовувати для автоматизованого тестування UI як симулятор дій користувача. Вона перевіряє наявні елементи та їхню доступність (наприклад, клікабельність посилань тощо). На додаток є корисні фічі, як-от збереження скріншотів, headless-тестування, базове вимірювання response-часу.

Rspec також належить до бібліотек Ruby, корисних для «поведінкової» розробки (behavior-driven development (BDD).

Плюси:

  • Кросбраузерність;
  • Різні способи знаходження елементів;
  • Корисні фічі та бібліотеки;
  • Open source;
  • Зрозуміла документація;
  • Багато «вейтерів» для тестування динамічних елементів.

Мінуси:

  • Працює тільки з Ruby;
  • Обмежене мобільне тестування;
  • Різні драйвери під різні браузери.

Приклад:


require 'rspec'
require 'watir-webdriver'

browser = Watir::Browser.new

describe "check the main page" do
  before(:each) do
    @browser.goto("http://main.page/")
  end


  context "check no error" do
    it "should not return an 400 error" do
      @browser.text.should_not include('Bad request')
    end
    it "should not return an 401 error" do
      @browser.text.should_not include('Not authorised'')
    end
   end

  context "page include main elements" do 
    it "check input field" do
      @browser.text_field({name: "input"}).set 'MyName'
      @browser.form({name: "submit name"}).submit
      Sleep 4
      expect(@browser.title).to eq("Your Name Form")
    end
   end
end

Cucumber

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

Cucumber використовує мову Gherkin, яка має п'ять основних ключових слів: Scenario, Given, When, Then, And. Тобто основний сценарій, який ви хочете протестувати, умови для початку, дії користувача, результат, та додаткові дії до будь-якого з трьох операторів.

Плюси:

  • Можна прочитати;
  • Тест-кейси може описати будь-хто з команди, хто володіє англійською;
  • Open source;
  • Можна залучати членів бізнес-команди;
  • Підтримує багато мов та може використовуватись як додатковий інструмент для тестування (Java, Ruby, .Net тощо).

Мінуси:

  • Для повноцінного тестування потрібні додаткові інструменти для автоматизації та перевірки умов (наприклад, rspec & Selenium);
  • Використовує мову Gherkin для детального опису, а не для імплементації автоматизованого тестування.

Приклад:

Feature: Checking main page

  Scenario: Positive case
    Given main page is opened 
    When I enter the name "John" 
    And I click on the "Submit" button
    I should see the text "Your name is John"

Jasmine

Jasmine — фреймворк для JavaScript, має відкритий код. Jasmine вважається BDD-інструментом, але його можна застосувати з TDD і для модульного тестування (unit testing).

Jasmine широко використовують для unit-тестування, але цей інструмент може бути ефективним для автоматизування UI при використанні додаткових бібліотек і драйверів (Selenium, jasmine-jquery).

Плюси:

  • Простий у використанні;
  • Опція Describe групує тести в групи;
  • Великий вибір валідаторів;
  • Зручне налаштування передумов;
  • Працює з Angular;
  • Headless;
  • Просте встановлення;
  • Велике ком'юніті з форумами та навчальними посібниками;
  • Підтримує mock об'єктів.

Мінуси:

  • Файли для тестування повинні мати спеціальний суфікс в кінці;
  • Складно виконувати асинхронні завдання;
  • Тривалий сетап.

Приклад:

const {Builder, By, Key, until} = require('selenium-webdriver');

require('chromedriver');
const driver = new Builder()
    .forBrowser('chrome')
    .build();
var login = async function() {
    let loginEl = By.css('.some-login');
    await driver.wait(until.elementLocated(loginEl), 10 * 1000);
    console.log('Login done')
}
describe('base page, function () {
    beforeEach(async function() {
        await login();
    });
    afterAll(async function() {
       console.log('Test done')
    });

    var urlAddress = '/some-jasmine-uiSpec';
    describeUi("base page", fixtureAddress, function () {
        function currentBaseUrl() {
            return window.location.pathname;
        }
        it("URL is correct", function () {
            expect(currentBaseUrl()).toBe(urlAddress);
        });

    describeUi("base page with hash", fixtureAddress+'#098', function() {
        it("has is in url", function() {
            expect(location.hash).toBe('#098');
        });
    });
});

Postman

Postman — зручний інструмент для тестування API. Він не вважається повноцінним інструментом для тестування UI або автоматизованого тестування, але по-своєму корисний. Вебсервіси — місток між сервером та користувачем. Тож за допомогою Postman можна робити запити на API й з'ясувати, чи помилка на стороні клієнта, чи сервера. Ще можна перевіряти коди відповідей HTTP, безпосередньо зміст, швидкість відповідей та багато іншого.

Приклад: image1

Cypress

Cypress — інструмент JavaScript, який створено спеціально для тестування UI. Він доволі нескладний для новачків та цілком підходить для E2E-тестування. Інструмент має корисні функції для інженерів, зокрема автоматичне очікування доступності елемента, досить легкий дебагінг, снепшоти, функції-заглушки для API та інше.

Плюси:

  • Велика кількість корисних функцій;
  • Зручна робота із запитами;
  • Запускає тести паралельно на різних віртуальних машинах;
  • Легко використовувати;
  • Функція «подорожі в часі» для зневадження.

Мінуси:

  • Тільки для JS;
  • Обмежений кросбраузер (Chrome, Firefox, Edge);
  • Обмежена робота з iframes;
  • Одночасно лише один браузер.

Приклад:

describe('Post Name, () => {
  it('Open a page', () => {
    cy.visit('/main-page')     
    cy.get('input.name') 
      .type('My name is John')  

    cy.contains('Submit Name')      
      .click()                 
    cy.get('#main-content')               
      .should('contain', 'My name is John')
  })
})

Appium

Якщо вам потрібно автоматизувати тестування мобільного застосунку, то, найімовірніше, ви звернетесь до Appium. Цей інструмент дозволяє тестувати програми для iOS або Android, керувати як мобільними вебсторінками (у Chrome та інших браузерах), так і застосунками. Appium делегує команди Chromedriver і може виконувати тести на реальних пристроях й емуляторах.

Плюси:

  • Підтримує всі популярні мови (Java, C#, C, JavaScript, Ruby, Python, PHP);
  • Open source;
  • Багатоплатформний;
  • Велике ком'юніті.

Мінуси:

  • Складна конфігурація;
  • Потрібен досвід програмування;
  • Можуть виникнути проблеми при налаштуванні.

Приклад:


// setup classes which will describe app path and so on
 
def testEmailInput(self):
        email = self.driver.find_element_by_accessibility_id('emailTextField')
        email.send_keys("my@gmail.com")
        email.send_keys(Keys.RETURN)
        sleep(2)
        self.assertEqual(email.get_attribute("value"), "my@gmail.com")

Robot Framework

Robot Framework схожий на Cucumber. В ньому можна описувати умови та тест-кейси мовою високого рівня. Цей інструмент базується на Python, для повноцінного тестування UI він може бути розширений за допомогою додаткових бібліотек, які використовують інші мови програмування.

Плюси:

  • Простий для вивчення та використання;
  • Швидкий у імплементації кейсів;
  • Детальна документація;
  • Легко розширити за допомогою інших бібліотек;
  • Open source.

Мінуси:

  • Погана підтримка циклів;
  • Складно працювати з цілими та логічними значеннями;
  • Може повільно опрацьовувати дані;
  • Може бути не доцільним при роботі зі складними кейсами.

Приклад:

*** Settings ***
Library  SeleniumLibrary
Suite Setup     Open browser    ${URL}   ${BROWSER}
Suite Teardown  Close All Browsers

*** Variables ***
${URL}          http://some-url.com/
${BROWSER}      Chrome

*** Test Cases ***
The user can save his name
    [Tags]       search_flights
    Find Input element xpath://select[@name='inputName']  John
    Click Button    css:input[type='submitName']
    @{name}=  Get WebElements    css:table[class='table']>tbody tr
    Should Not Be Empty    ${name}


// also it includes Python classes which describe WebDriver session

Підводні камені UI-тестування

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

Тестування займає багато часу

  • Популярне рішення — паралельне виконання тестів або використання більше ніж одного віртуального середовища.
  • Ви можете групувати тести на основі передумов та запускати їх по черзі, де це можливо, не відтворюючи середовище з нуля.
  • Спочатку виконайте базовий кейс. Вам не потрібно тестувати складні послідовності, якщо щось не вдалося з самого початку.
  • Запускайте тести вночі.
  • Перевірте кілька основних E2E-послідовностей на початку.
  • Дозвольте повторно запускати набори окремих кроків без перезапуску цілого набору.
  • Перенесення деяких передумов з UI на backend. Наприклад, якщо ви створюєте нових користувачів щоразу і це не є тестом, який перевіряє процес створення користувачів, ви можете створювати їх на бекенді.

Нестабільні/динамічні елементи

  • Не оновлюйте середовище під час тестового запуску.
  • Замість очікування в секундах, оберіть очікування появи елемента, на кшталт element.when_visible.
  • Щоб перевірити наявність елементів, використовуйте повторні спроби в розумній кількості.
  • Робіть скріншоти, щоб дослідити помилкові кроки.

Тести не помічають зміни в UI

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

Висновок

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

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

Помітили помилку? Повідомте автору, для цього достатньо виділити текст з помилкою та натиснути Ctrl+Enter
Codeguida 6.2K
Приєднався: 7 місяців тому
Коментарі (1)
Щоб залишити коментар необхідно авторизуватися.

Вхід / Реєстрація