Моніторинг транзакцій на сайті
Моніторинг транзакцій HostTracker автоматизує сценарії на сайті, як-от відправлення форм чи проходження кількома сторінками. Він перевіряє коректність веб-операцій відповідно до визначених правил на кожному з наступних кроків.
Це синтетичний моніторинг у строгому сенсі: реальний браузер, керований чекпоінтами HostTracker за розкладом, відтворює шлях ваших клієнтів - вхід, пошук, додавання в кошик, оформлення замовлення - і фіксує збій перевірки саме на тому кроці, який перестав працювати.
Виявляйте зламане оформлення замовлення до того, як воно коштуватиме вам продажів
Наскрізне тестування процесу
Сервіс перевірки транзакцій HostTracker гарантує, що всі етапи онлайн-транзакції працюють коректно. Він тестує кожен крок процесу - від додавання товарів у кошик до завершення покупки. Це допомагає знаходити й виправляти проблеми, які могли б завадити клієнтам купити, що покращує клієнтський досвід і зменшує втрачені продажі.
Форми, кліки та переходи
Функція перевірки транзакцій HostTracker всеосяжна й охоплює різні аспекти транзакції в е-комерції. Вона включає відправлення форм, натискання кнопок і переходи між сторінками, щоб відтворити поведінку реальних користувачів. Це перевіряє весь процес покупки, аби переконатися, що він працює справно. Крім того, сервіс надає детальні логи та звіти, які допомагають адміністраторам швидко знаходити й виправляти будь-які проблеми, не заважаючи шляху покупця.
Менше втрачених продажів
Перевірки транзакцій роблять сайти е-комерції надійнішими та ефективнішими. Вони допомагають підтримувати безперебійну роботу транзакцій, усуваючи проблеми до того, як вони виникнуть. Це означає, що клієнти більш задоволені й більше довіряють сайту. Це також допомагає утримувати клієнтів задоволеними, уникаючи втрачених продажів. Це робить сервіс корисним інструментом для онлайн-магазинів.
Що таке синтетичний моніторинг транзакцій - і чим він не є
Синтетичний моніторинг означає, що трафік генерується навмисно: замість того щоб чекати, поки відвідувач наштовхнеться на проблему, і сподіватися, що він про неї повідомить, сервіс моніторингу сам проходить ваш сайт за розкладом ззовні вашої мережі. Моніторинг транзакцій - це його багатокрокова форма. Проста синтетична перевірка запитує одну URL-адресу й дивиться на відповідь. Перевірка транзакції відкриває реальний браузер, проходить упорядкований сценарій - відкрити сторінку, увійти, знайти товар, додати в кошик, оформити замовлення - і перевіряє результат на кожній зупинці.
Ця різниця важлива, адже більшість того, що клієнти насправді роблять на сайті, - це послідовність дій, а не перегляд однієї сторінки. Кожна окрема сторінка в оформленні замовлення може повертати HTTP 200, тоді як саме оформлення замовлення зламане: кнопку прибрали під час релізу, форма надсилає дані на ендпоінт, що тепер повертає 404, помилка JavaScript зупиняє майстер налаштування на третьому кроці. Жоден з цих збоїв ніяк не проявляється в коді статусу, тож жоден з них не проявляється у звичайному моніторингу аптайму.
Це не те саме, що моніторинг фінансових транзакцій. У банківській сфері та комплаєнсі "моніторинг транзакцій" означає перевірку платежів на шахрайство й відмивання коштів. Ця сторінка про значення терміна у веб-експлуатації: автоматичне відтворення користувацького сценарію на вашому власному сайті, щоб довести, що він досі працює. HostTracker - це сервіс моніторингу сайтів: він стежить за вашим сценарієм оформлення замовлення, а не за вашою платіжною книгою.
Що перевірка транзакції виявляє там, де HTTP-перевірка безсила
Швидка HTTP-перевірка - правильний інструмент для питання "чи працює сайт". Це один запит, тож і вердикт один: код стану, час відповіді та будь-яке ключове слово чи правило перевірки, яке ви задали для отриманого тіла відповіді. Це велике покриття за дуже малу ціну - і воно закінчується точно там, де закінчується перша відповідь. Усе, що нижче в цій таблиці, стається вже після цього моменту.
| Що насправді зламалося | Швидка HTTP-перевірка | Перевірка транзакції |
|---|---|---|
| Сервер недоступний, збій DNS, відмова TLS-рукостискання | Виявлено | Виявлено |
| Головна сторінка повертає 500 після розгортання | Виявлено | Виявлено |
| Сторінка завантажується, але кнопку "Додати в кошик" прибрали в релізі | Пропущено - HTML і далі повертає 200 | Виявлено - крок кліку не може знайти свій селектор |
| Форма входу надсилає дані на ендпоінт, що тепер повертає 404 | Пропущено - сторінка самої форми в порядку | Виявлено - крок після надсилання так і не досягає сторінки акаунту |
| Виняток JavaScript зупиняє майстер оформлення замовлення на другому кроці | Пропущено - JavaScript ніколи не виконується | Виявлено - браузер виконує скрипт, і перевірка може провалитися на помилках у консолі |
| Сторінка оплати відображає банер помилки замість підтвердження | Пропущено - відображена помилка все одно код 200 | Виявлено - перевірка вмісту на тексті підтвердження провалюється |
| Сесійна кука перестає встановлюватися, тож третій крок повертає на сторінку входу | Пропущено - немає сесії, яку можна втратити | Виявлено - весь сценарій виконується в одній браузерній сесії |
| Сторонній скрипт - чат-віджет, тег-менеджер, платіжний SDK - блокує рендеринг | Пропущено - сторонні ресурси ніколи не завантажуються | Виявлено - браузер завантажує їх так само, як і відвідувач |
| Сценарій працює, але кожен крок тепер триває вісім секунд | Частково - вимірюється лише перша відповідь | Виявлено - кожен крок хронометрується, і крок може перевищити тайм-аут |
Жодна з перевірок не замінює іншу. Чесна рекомендація - запускати обидві: одну HTTP-перевірку щохвилини на тому самому сайті для швидкого виявлення збоїв і перевірку транзакції на одному чи двох сценаріях, які справді приносять дохід. Якщо хочете почати з половини про доступність, почніть з розподіленого моніторингу доступності з 300+ точок і додайте сценарій зверху.
Як насправді виконується перевірка транзакції
Кожен запуск відкриває реальний, headless-браузер Chromium на одному з чекпоінтів HostTracker і виділяє йому одну браузерну сесію на весь сценарій. Саме ця деталь робить перевірку значущою: куки, токени та стан входу, встановлені на другому кроці, залишаються й на п’ятому - точно так само, як у людини, що клікає вашим сайтом. JavaScript виконується, переходи відбуваються - включно з тими, що запускають ваші власні скрипти, - а сторонні ресурси завантажуються так само, як у браузері відвідувача.
Сценарій послідовний і з негайним припиненням при першому збої. Кроки виконуються в тому порядку, в якому ви їх написали, і перший крок, що провалюється, завершує запуск і стає зафіксованою причиною. Ви ніколи не отримаєте стіну помилок, спричинених однією зламаною кнопкою, - ви отримаєте саме цю зламану кнопку.
Два опційні перемикачі змінюють суворість запуску. Провал на помилці консолі перетворює будь-яку помилку в консолі браузера на провалену перевірку - потужна опція для добре поведеного застосунку, доповнена списком дозволених підрядків (до десяти), щоб відомий шумний сторонній скрипт не кричав "вовк". Пропускати завантаження медіафайлів увімкнено за замовчуванням; вимикайте цю опцію, коли предмет тестування - саме медіа.
Дії, з яких будується сценарій
Транзакція - це список кроків, і кожен крок - одна дія над сторінкою. Тут немає макрорекордера, який міг би застаріти, - ви будуєте сценарій явно, і саме тому він продовжує працювати, навіть коли ваша маркетингова команда змінює текст на кнопці.
| Дія | Що робить крок |
|---|---|
| navigate | Відкрити URL-адресу. Перший перехід - на власну адресу монітора - додається за вас як нульовий крок. |
| click | Клікнути на елемент, знайдений за CSS-селектором, або за координатою в області перегляду. Ліва, права чи середня кнопка миші, з опційною затримкою утримання. |
| type | Ввести текст у поле, опційно із затримкою між натисканнями клавіш, щоб власні обробники вводу сторінки встигали реагувати. |
| select | Перевірити кількість збігів для селектора: жодного, рівно один, щонайменше один, або будь-яку кількість. Діє на всі збіги, перший, або випадковий. |
| checkContent | Перевірити відображений текст. До десяти ключових слів, будь-яке з них або всі, з урахуванням регістру чи без, наявні або навмисно відсутні, опційно тільки у видимому тексті. |
| hover | Навести курсор на елемент - так ви дістаєтесь меню чи підказки, які з’являються лише при наведенні. |
| waitForNavigation | Дочекатися переходу сторінки, опційно провалюючи крок, якщо перехід не стається вчасно. |
| sleep | Пауза від 1 мілісекунди до 10 секунд, з опційним випадковим розкидом, щоб сценарій не бив по тій самій миті щоразу. |
| screenshot | Зробити знімок сторінки посеред сценарію, щоб збій двома кроками пізніше все одно показав, як сторінка виглядала на шляху туди. |
| back | Повернутися на один запис назад в історії браузера. |
Будь-який крок може супроводжуватись скриншотом і очікуванням переходу після себе, власним перевизначенням тайм-ауту та коротким ім’ям до 19 символів. Називайте свої кроки - це ім’я з’являється в результаті й у сповіщенні, тож "3 - надіслати вхід" - це різниця між сторінкою, що "лежить", і сторінкою, у якої POST-запит входу перестав перенаправляти. У веб-редакторі скриншоти й очікування переходу пропонуються як поведінка після кроку; повний набір дій, включно з наведенням, доступний через API.
Налаштування першого монітора транзакцій
- Додайте монітор і оберіть Перевірку транзакції як його тип. 30-денний пробний період покриває це - 100 моніторів, усі типи перевірок, без банківської картки.
- Введіть URL-адресу, з якої починається сценарій. Цей початковий перехід автоматично стає нульовим кроком, тож десять кроків, які ви можете написати самі, - це десять кроків реальної роботи, а не дев’ять плюс завантаження сторінки.
- Додавайте кроки по порядку. Для всього, на що ви клікаєте чи в що вводите текст, використовуйте стабільний CSS-селектор -
idабо власний атрибутdata-, а не згенеровану назву класу, яка змінюється з наступним білдом. - Перевіряйте на кожному кроці. Крок
checkContentпісля кожного значущого переходу - це те, що перетворює послідовність кліків на справжній тест: після входу перевірте текст сторінки акаунту, після оформлення замовлення - текст підтвердження. - Оберіть інтервал - від 10 хвилин до 24 годин - і локації, з яких він виконуватиметься. Мережа HostTracker охоплює 300+ локацій у 158 містах, тож ви можете запускати сценарій із регіонів, де справді перебувають ваші клієнти.
- Оберіть контакти, які отримають сповіщення, і скільки часу вони чекатимуть спершу. Різні люди можуть перебувати на різних сходинках драбини сповіщень, тож черговий інженер дізнається одразу, а керівник - лише якщо проблема досі не усунена через годину.
- Збережіть і відкрийте перший результат. Прочитайте хронометраж кожного кроку одного разу, коли все справне, - саме цей базовий рівень робить перший реальний збій очевидним.
Якщо хочете спершу перевірити початкову URL-адресу перед побудовою сценарію, запустіть безкоштовну миттєву HTTP-перевірку на ній - без входу в акаунт - або виміряйте, як сторінка завантажується в реальному браузері, за допомогою безкоштовного тесту швидкості сторінки.
Що відбувається в момент, коли крок провалюється
Запуск зупиняється на кроці, що провалився, і фіксує побачене. Результат називає крок, класифікує збій - тайм-аут, елемент, який селектор не зміг знайти, перевірка вмісту, що не збіглася, HTTP-помилка, помилка з’єднання, помилка в консолі браузера або неправильно налаштований крок - і зберігає тривалість кожного кроку, URL-адресу, IP та HTTP-статус, на якому завершився кожен перехід, повідомлення консолі браузера й скриншот сторінки в момент збою.
Потім це двічі перевіряють, перш ніж когось розбудити. Одне спостереження про збій не вважається збоєм: перевірка повторюється з інших незалежних локацій, і зміна стану підтверджується лише тоді, коли кворум погоджується. За замовчуванням це мажоритарний вердикт серед максимум семи агентів, мінімум трьох, - тож одна нестабільна локація чи одна тимчасова мережева заминка між дата-центром і вашим хостом не може самотужки згенерувати сповіщення.
Щойно перехід підтверджено, сповіщення надходять із затримкою, яку обрав кожен контакт: одразу, або лише через 3, 5, 15, 30 чи 60 хвилин, або через 3, 6, 12 чи 24 години безперервного збою. Сповіщення надсилаються дев’ятьма каналами, які підтримує HostTracker, - електронна пошта, SMS, голосовий дзвінок, webhook, Slack, веб-пуш і месенджери Telegram, Discord та Viber, - а сповіщення про відновлення надходить, щойно сценарій знову починає завершуватися успішно.
Які сценарії автоматизувати першими
Почніть з одного сценарію, збій якого коштує вам грошей, доведіть його до зеленого статусу, і лише тоді додавайте решту. Один відстежуваний сценарій, якому ви довіряєте, кращий за п’ять налаштованих абияк.
Від кошика до оформлення замовлення
Відкрийте сторінку товару, клікніть "додати в кошик", перевірте, що позначка кошика показує один товар, відкрийте оформлення замовлення, перевірте суму та відображення платіжної форми. Зупиніться за крок до оформлення замовлення - і отримаєте повне покриття без тестових замовлень у вашій базі даних.
Вхід і перехід до панелі керування
Введіть облікові дані виділеного тестового акаунту, надішліть форму, дочекайтеся переходу, а потім перевірте текст, що з’являється лише за реальної сесії. Це найцінніший сценарій для більшості застосунків - зламаний вхід означає повний простій, що повертає 200 на кожній сторінці.
Відправлення контактної форми
Заповніть поля, надішліть форму, перевірте текст подяки. Тихе зламання форми - класичний невидимий збій: нічого не видає помилку, ніщо не сповіщає, а звернення просто перестають надходити, поки хтось не помітить це через кілька тижнів.
Пошук повертає результати
Введіть запит, який завжди має щось знаходити, надішліть форму, а потім перевірте, що відомий результат присутній, а текст порожнього стану відсутній. Саме друга перевірка виявляє індекс пошуку, який тихо перестав перебудовуватися.
Реєстрація до останнього кліку
Пройдіть форму реєстрації до фінального екрана підтвердження й перевірте його, спрямувавши форму на тестову ціль, щоб моніторинг ніколи не створював реальні акаунти. Реєстрація ламається тихо й дорого - ніхто не поскаржиться на реєстрацію, яку не зміг завершити.
Скидання пароля
Запросіть скидання й перевірте, що з’являється екран підтвердження. Це залежить від вашого поштового конвеєра, черги та сервісу токенів, тож це на диво хороший індикатор для бекенд-проблем, які головна сторінка ніколи не показує.
Обмеження, про які варто знати перед побудовою
Перевірка транзакції - найпотужніший монітор, який пропонує HostTracker, і водночас той, у якого найбільше реальних обмежень. Знання їх наперед економить пів дня роботи.
- Десять кроків і 40 секунд. Сценарій виконує щонайбільше десять написаних кроків у межах 40-секундного бюджету. Довший сценарій краще розбити на два монітори - "чи можуть вони увійти" і "чи можуть вони оформити замовлення" - що заодно покаже, яка саме половина зламалася.
- Десять хвилин - найшвидший інтервал. Браузерні перевірки дорогі й у виконанні, і в отриманні. Поєднуйте сценарій з одно хвилинною HTTP- чи ping-перевіркою того самого сайту, якщо потрібне виявлення збоїв на рівні хвилин.
- Використовуйте тестовий акаунт і тестовий товар. Перевірка надсилає реальні форми на ваш реальний сайт. Виділений акаунт, тестовий SKU і sandbox вашого платіжного провайдера тримають трафік моніторингу подалі від ваших бізнес-даних.
- CAPTCHA, MFA і захист від ботів зупинять сценарій. Вони роблять свою роботу. Або додайте чекпоінти HostTracker у список дозволених для тестового акаунту, або відстежуйте шлях, який не захищений ними.
- Селектори - найкрихкіша частина. Сценарій, побудований на згенерованих назвах класів, ламається на наступному редизайні. Дайте елементам, які ви перевіряєте, стабільні ідентифікатори - і монітор переживе вашу фронтенд-команду.
- Без HTTP-облікових даних, заголовків чи власного user-agent. Перевірки транзакцій не несуть базових облікових даних авторизації, власних заголовків запиту чи власного user-agent - вкладайте автентифікацію в сам сценарій, як кроки. Якщо потрібен контроль на рівні заголовків, для цього призначена перевірка API.
- Це реальний трафік. Сценарій, що виконується з багатьох локацій кожні десять хвилин, з’являється у вашій аналітиці й впливає на ваші ліміти запитів. Фільтруйте його на своєму боці й свідомо обирайте розмір списку локацій.
Синтетичний моніторинг проти моніторингу реальних користувачів
Ці два підходи відповідають на різні питання, і команда, яка розуміє цю різницю, перестає очікувати, що один підхід виконає роботу іншого. HostTracker - це сервіс синтетичного моніторингу сайтів: він сам генерує трафік, зі своїх чекпоінтів, за розкладом, який контролюєте ви.
| Синтетичний моніторинг транзакцій | Моніторинг реальних користувачів | |
|---|---|---|
| Хто генерує трафік | Сервіс моніторингу, за фіксованим розкладом | Ваші реальні відвідувачі, коли б вони не з’явилися |
| Працює до появи трафіку | Так - staging-сайт без користувачів усе одно перевіряється | Ні - немає відвідувачів, немає даних |
| Помічає збій о третій ночі | Так - розклад не спить | Не помітить, поки хтось не з’явиться |
| Називає точний крок, що провалився | Так - сценарій детермінований | Рідко - ви бачите симптом, а не послідовність |
| Відображає реальний досвід клієнтів | Ні - це контрольована вибірка | Так - у цьому весь сенс |
| Потребує коду на вашому сайті | Ні - виконується повністю ззовні | Скрипт чи SDK на кожній сторінці |
| Покриває сценарій, який клієнти рідко завершують | Так - ви обираєте, що перевіряти | Ні - рідкісні шляхи лишаються невиміряними |
Якщо наступним вам потрібна саме половина про час завантаження, а не про сценарій, HostTracker також вимірює завантаження реальних сторінок у браузері - див. моніторинг доступу браузера й часу завантаження, - а для машинного еквівалента транзакції перевірка API перевіряє контракт відповіді, а не відображену сторінку. На боці сервера монітор запитів до бази даних часто пояснює, чому сценарій сповільнився в першу чергу.
Часті запитання
Моніторинг транзакцій для сайту - це перевірка, яка автоматизує реальний багатокроковий користувацький сценарій - наприклад, заповнення форми, вхід в акаунт, додавання товару в кошик або завершення покупки - і підтверджує, що кожен крок виконується коректно, а вся послідовність дає очікуваний результат. На відміну від простої перевірки, яка лише підтверджує завантаження однієї сторінки, моніторинг транзакцій проходить той самий шлях, яким пішов би реальний відвідувач, - надсилаючи дані й переходячи сторінками послідовно, - а потім звіряє результат із визначеними вами правилами. Це важливо, адже сайт може виглядати цілком справним за будь-якими простими показниками доступності - головна сторінка завантажується, окремі сторінки повертають код 200, - тоді як критичний багатокроковий процес на кшталт оформлення замовлення непомітно ламається на півдорозі. Моніторинг транзакцій HostTracker створений спеціально для того, щоб виявляти саме такий тип збоїв.
Моніторинг транзакцій HostTracker дає змогу автоматизувати й перевіряти широкий спектр взаємодій на сайті, зокрема відправлення форм, натискання кнопок і переходи між сторінками, які разом моделюють те, як реальний користувач рухається вашим сайтом. Це охоплює типові сценарії: проходження реєстрації чи входу, відправлення контактної форми або форми для збору лідів, а також багатокрокові процеси покупки, як-от додавання товарів у кошик і проходження оформлення замовлення. Оскільки перевірка покроково імітує поведінку реального користувача, а не просто завантажує одну сторінку, вона може підтвердити, що кожен етап процесу справді працює й дає очікуваний результат, а не лише те, що задіяні сторінки випадково завантажуються. Це робить її корисною для будь-якого сайту, де зламаний інтерактивний сценарій - а не лише зламана сторінка - коштував би вам лідів, реєстрацій або продажів.
Базовий моніторинг аптайму перевіряє, чи відповідає одна сторінка або точка доступу і чи повертає вона нормальний код стану, що свідчить про доступність сервера, але нічого не каже про те, чи справді працює багатокроковий процес, побудований на його основі. Моніторинг транзакцій йде далі: він автоматизує цілу послідовність кроків - відправлення форми, переходи сторінками, завершення процесу покупки - і перевіряє, що кожен крок виконується успішно, а весь наскрізний процес дає правильний результат. Сайт може проходити кожну перевірку аптайму, тоді як його оформлення замовлення повністю зламане на етапі оплати, адже кожна окрема сторінка й далі нормально завантажується сама по собі; виявити це може лише перевірка, яка справді проходить транзакцію крок за кроком. Для будь-якого сайту, де конверсії залежать від багатокрокового сценарію, моніторинг транзакцій покриває категорію збоїв, яку базові перевірки аптайму просто не здатні побачити.
Так, це один з основних сценаріїв використання моніторингу транзакцій. Перевірки транзакцій HostTracker проходять визначену послідовність кроків - наприклад, додавання товару в кошик, перехід до оформлення замовлення, заповнення обов’язкових полів і досягнення сторінки підтвердження - і перевіряють, що кожен крок виконується як очікується. Це означає, що збій, який виник будь-де в цьому сценарії - чи то зламана кнопка "додати в кошик", помилка валідації форми, чи сторінка оформлення замовлення, що перестала завантажуватися після нещодавнього розгортання, - буде виявлено й зафіксовано в детальних логах із указанням конкретного кроку, на якому стався збій. Швидке виявлення такої проблеми має значення, адже зламаний крок оформлення замовлення напряму коштує продажів і може довго залишатися непоміченим для простих перевірок аптайму, оскільки задіяні окремі сторінки й далі можуть повертати нормальні коди стану.
Коли якийсь крок перевірки транзакції не проходить - форма не відправляється, очікувана сторінка не завантажується або не виконується умова валідації - HostTracker фіксує момент збою і надсилає сповіщення через налаштовані вами канали, тож ви дізнаєтесь не лише про те, що щось зламалося, а й де саме в сценарії це сталося. Разом зі сповіщенням надаються детальні логи та звіти, які дають адміністраторам конкретний крок і результат, потрібні для швидкого розслідування, замість того щоб вручну відтворювати весь сценарій самостійно. Саме ця деталізація на рівні кроку робить моніторинг транзакцій практично корисним для швидкого виправлення проблем: знати, що "оформлення замовлення зламане", значно менш придатно до дій, ніж знати, що збій стається саме на кроці підтвердження оплати після конкретної нещодавньої зміни, - це суттєво звужує коло ймовірних причин.
Ні, хоча багатокрокові сценарії покупки - поширений приклад, моніторинг транзакцій корисний для будь-якого сайту, де має коректно працювати послідовність дій користувача, а не лише завантаження однієї сторінки. Це охоплює сценарії входу та реєстрації для SaaS-застосунків, форми для збору лідів і контактні форми для сервісних компаній, багатосторінкові процеси подання заявок, а також будь-яку навігацію сайтом, де зламане посилання чи невдале відправлення форми на півдорозі завадило б відвідувачу завершити те, заради чого він прийшов. Будь-який інтерактивний процес, у якому втрата користувача на півдорозі має реальну ціну - упущена реєстрація, покинута форма ліда, незавершена заявка, - виграє від того, що саме цей сценарій автоматизовано й регулярно перевіряється, замість того щоб просто вважати, що він і далі працює лише тому, що задіяні сторінки завантажуються без помилок.
Перевірка транзакції виконується з обраним вами інтервалом - від 10 хвилин до 24 годин: 10, 15, 30 і 45 хвилин, потім 1, 2, 4, 6, 12 і 24 години. Мінімальний інтервал вищий за одну хвилину, яку HostTracker пропонує для простих HTTP-перевірок, і це зроблено свідомо: перевірка транзакції запускає реальний браузер, завантажує сторінку разом з її JavaScript і покроково проходить ваш сценарій, а це секунди реальної роботи, а не один запит. Типовий підхід - поєднувати обидва типи: одна хвилина для HTTP- чи ping-перевірки відповідає на питання "чи доступний сайт зараз", а перевірка транзакції кожні 10-15 хвилин відповідає на складніше питання - чи досі завершується оформлення замовлення, вхід чи реєстрація за ним. Таке поєднання виявляє серйозний збій протягом хвилини, а зламаний сценарій - протягом одного циклу перевірки, без запуску браузерної сесії проти вашого застосунку щохвилини.
Ні, і не варто цього робити. Перевірка транзакції відправляє реальні форми на ваш реальний сайт, тож правильне налаштування - це виділений тестовий акаунт, тестовий товар чи SKU, а якщо сценарій доходить до оплати - тестовий режим або sandbox вашого платіжного провайдера, точно як для будь-якого автоматизованого наскрізного тесту. Багато команд зупиняють відстежуваний сценарій за один крок до незворотної дії: доходять до сторінки оплати, перевіряють, що вона відобразилася з правильною сумою, і завершують на цьому. Це все одно підтверджує, що кожен крок до моменту оплати працює, без створення замовлення кожні десять хвилин. Те саме правило стосується сценаріїв реєстрації та збору лідів - спрямуйте сценарій на тестову ціль форми або відфільтровуйте надсилання монітора на своєму боці, щоб трафік моніторингу ніколи не забруднював ваші реальні дані.
Продовжуйте вивчати моніторинг HostTracker
Перевіряйте API-ендпоінти на відповідність контракту
Застосуйте політику валідації до кінцевих точок вашого веб-сервісу та виявляйте неправильний код стану, пошкоджену відповідь JSON/XML або повільну відповідь раніше, ніж це помітять ваші інтеграції.
Відстежуйте реальну швидкість завантаження сторінок із 300+ локацій
Автоматизуйте реальне відвідування вашої сторінки браузером і вимірюйте час завантаження відповідно до заданої вами політики, щоб уповільнення виявлялися раніше, ніж відвідувачі почнуть залишати сайт.
Перегляньте всі можливості моніторингу HostTracker
Порівняйте всі 8 типів моніторингу поруч і комбінуйте перевірки, що підходять саме вашому сайту.
Виявляйте зламане оформлення замовлення до того, як воно коштуватиме вам продажів
Розпочніть безкоштовний тестовий період і стежте за критичними користувацькими сценаріями - входом, пошуком, оформленням замовлення - цілодобово.