Запит до URL покаже, що сторінка відповіла. Він не покаже, чи залишився потрібний тариф, чи дійшла форма реєстрації до очікуваного кроку, чи зберігся заголовок у локалізованій версії. Спочатку браузер має показати правильний вміст, а вже потім його можна переглядати.
RenderLog зберігає такий стан як сценарій у наборі перевірок. Запуск можна почати з робочого простору, API, CI, вебхука або розкладу. В одному результаті залишаються файл, дані сторінки, перевірки, візуальне порівняння та рішення щодо перегляду.
Почніть з однієї сторінки й одного рішення
Наприклад, на публічній сторінці тарифів є план Growth за $49 і кнопка 'Start free trial'. Перевірка зберігає сторінку та область перегляду, перевіряє наявність 'Growth' і '$49' та робить знімок сторінки. Якщо після випуску план зникне або кнопка зміститься, результат покаже, що саме потребує уваги. Суми тут лише приклад, а не ціни RenderLog.
Виберіть стан сторінки, який команда вже перевіряє вручну. У редакторі сценарію задайте URL, об'єкт перевірки, область перегляду та лише потрібні кроки. Додайте перевірку видимого тексту, значення, атрибута або стану елемента. Візуальний еталон потрібен тоді, коли рішення залежить від макета.
Збережіть налаштування, які роблять запуски порівнюваними
Одного URL недостатньо, якщо результат змінюють cookie, мова, область перегляду, селектор або кроки сценарію. Набір перевірок зберігає сценарії та спільні налаштування браузера, а кожен сценарій може мати власні вхідні дані, об'єкт перевірки, області, кроки, перевірки й еталон.
Налаштовуйте сценарій ручними запусками. Після випуску запускайте його з CI, API або вебхука, а для змін поза процесом випуску додайте розклад. Усі запуски залишаються в одній історії.
Використовуйте історію запусків, щоб зрозуміти зміну
На знімку вище запуск для example.com зберіг PNG розміром 19,1 КБ за 5,9 секунди. Статус Passed стоїть поруч із 'No assertions' і '0 steps'. Це підтверджує, що браузер зробив знімок. Щоб перевіряти сторінку тарифів, додайте очікувану назву плану й ціну. Без цих перевірок успішний запуск нічого не каже про правильність тарифу.
Коли зображення змінилося, порівняйте погоджений еталон, поточний знімок і підсвічену різницю. Перевірте змінену область та результати перевірок, потім зафіксуйте дію Accept, Reject або Ignore з короткою приміткою. Не робіть новим еталоном сторінку входу, відсутній селектор чи неповний результат. Зберігайте облікові дані в запиті або налаштуваннях збереженого набору перевірок, а не в URL чи знімках. Цей результат допомагає знайти зміну на вибраній сторінці. Він не охоплює весь сайт чи всі дії відвідувачів.
Продовжуйте з того самого процесу
Переглянути посібники RenderLog
Відкрийте практичні посібники про no-code перевірки, візуальний перегляд і API.
Посібник: як відстежувати зміни на сайті
Практичний початок для вибору сторінок, станів і відповідальних за перегляд.
No-code перевірки сайтів
Створюйте перевірки сторінок, форм і станів інтерфейсу з еталонами та повторними запусками.
API знімків сайту
Створюйте разові або автоматизовані знімки та файли документів із запиту.
Посібник: моніторинг сторінок із цінами
Дізнайтеся, як поєднати візуальне порівняння з погодженими станами.
Посібник: перегляд візуальних відмінностей
Використовуйте еталони, історію запусків і сповіщення без зайвого шуму.
Посібник: розклад перевірок
Оберіть періодичність, коли для повторної перевірки вже є відповідальна людина.
Почніть з однієї сторінки, яку команда вже переглядає
Збережіть її стан, додайте перевірку, пов'язану з ризиком, та визначте, хто переглядає зміни. Додавайте інші сторінки після того, як перша перевірка матиме відповідального й зрозумілу реакцію.