Wiki · Веб-разработка

Тестирование сайта

5 мин чтенияОбновлено 09.10.2026Автор: Дмитрий КолесниковСоавторы: Евгений Баев

Тестирование сайта – это проверка того, что сайт работает так, как задумано: формы доходят до менеджеров, страницы открываются на телефонах и в разных браузерах, сервер держит нагрузку, а личные данные видят только те, кому положено.

Сайт может выглядеть идеально на мониторе дизайнера и при этом терять заявки. Кнопка «Отправить» на телефоне уезжает за край экрана. Письмо с заявкой уходит на ящик, который давно никто не открывает. Корзина обнуляется при переходе к оплате. Владелец замечает это через месяц, когда реклама тратится, а звонков нет.

Тестирование ищет такие поломки раньше клиентов. Проверок много, и для каждого сайта набор свой.

Какие виды тестирования нужны сайту

Вид	Что проверяют	Когда нужен
Функциональное	Формы, корзину, оплату, фильтры, поиск, личный кабинет	Всегда
Кроссбраузерное и адаптивное	Вёрстку в разных браузерах, на телефонах и планшетах	Всегда
Нагрузочное	Сколько посетителей сайт выдержит без замедления и ошибок	Перед рекламой, распродажей, сезоном
Юзабилити	Понятно ли человеку, куда нажать и как оставить заявку	Новый сайт, редизайн, низкая конверсия
Безопасность	Права доступа, уязвимости форм, обновления CMS	Личные кабинеты, оплата, персональные данные
Техническое SEO	Коды ответов, редиректы, robots.txt, sitemap, дубли	Запуск, переезд, смена структуры

Удобство проверяют на живых людях, об этом статья Юзабилити-тестирование. Настройки для поисковиков разбираем в статье Технический аудит сайта.

Как проходит тестирование сайта

Порядок работы почти не зависит от размера проекта.

Пять шагов тестирования сайта: требования, чек-лист, проверки на устройствах, описание ошибок в трекере, повторная проверка — Как проходит тестирование сайта

Собирают требования. Что сайт должен уметь, видно из технического задания и сценариев: «выбрать врача и записаться», «найти товар и оплатить картой».
Пишут чек-лист или тест-кейсы. Каждая строка: действие и ожидаемый результат.
Проходят проверки в нужных браузерах и на устройствах. Мобильную версию смотрят на реальных телефонах, эмулятора в браузере мало.
Заводят ошибки в трекер: шаги, что ожидали, что получили, скриншот, браузер и устройство.
После исправлений проверяют починенное место и соседние функции, потому что правка в одном модуле часто ломает другой. Это регрессионное тестирование.

Хорошее описание ошибки экономит часы. Фраза «форма не работает» разработчику ничего не говорит. А «Safari на iPhone, страница контактов, поле телефона не принимает +7, кнопка неактивна» он сможет повторить у себя и сразу исправить.

Сравнение плохого и хорошего описания ошибки при тестировании сайта: браузер, устройство, шаги, ожидаемый и фактический результат — Как описать ошибку, чтобы её исправили

Сколько стоит тестирование, кто его делает и когда повторять

Как называется проверка сайта перед запуском?

Чаще всего говорят «приёмочное тестирование» или просто QA, от английского quality assurance. Внутри у отдельных проверок свои названия: функциональное для форм и корзины, кроссбраузерное для вёрстки, нагрузочное для сервера, регрессионное для повторной проверки после правок.

От чего зависит цена тестирования сайта?

От объёма работы: сколько страниц и сценариев, в каких браузерах и на каких устройствах смотреть, нужен ли нагрузочный тест. Чек-лист для лендинга и нагрузка на каталог интернет-магазина различаются в разы, поэтому стоимость называют после того, как изучат сайт и составят список сценариев.

Чем тестирование сайта отличается от технического аудита?

Тестирование смотрит на сайт глазами клиента: уходит ли заявка, проходит ли оплата, выдержит ли сервер наплыв людей. Технический аудит смотрит глазами поисковика: индексация, дубли, коды ответов, скорость. Часть проверок общая, например редиректы и robots.txt, но цели у работ разные.

Когда тестировать сайт, который уже работает?

После обновления CMS и модулей, после редизайна или переезда и перед крупной рекламной кампанией. В промежутках достаточно регулярно проходить главные сценарии: заявку, заказ, оплату.

Зачем после каждой правки перепроверять то, что уже работало?

Изменение в одном месте сайта нередко задевает другое: обновили модуль каталога, и перестала работать корзина. Повторную проверку старых функций называют регрессионным тестированием, её делают после любых изменений, даже мелких.

Где тестировать сайт, чтобы не задеть реальных клиентов?

На копии сайта на тестовом домене. Закройте её от индексации, иначе тестовые страницы окажутся в поиске, и проследите, чтобы письма и рассылки с копии не уходили настоящим покупателям. После переноса на основной домен главные сценарии проходят ещё раз уже на рабочем сайте.

Чем нагрузочный тест отличается от проверки скорости?

PageSpeed Insights показывает, как быстро страница открывается у одного посетителя, а нагрузочный тест отвечает, что будет, когда её одновременно откроют сотни людей. Сайт, который быстро работает без посетителей, может лечь в первый час распродажи. Поэтому нагрузку проверяют заранее: перед запуском рекламы, акцией или сезоном.

Кто должен тестировать сайт, кроме разработчика?

Человек со стороны: тестировщик или сам заказчик на приёмке по пунктам ТЗ. Разработчик знает, куда нажимать, и смотрит на сайт с мощного компьютера со свежим браузером, поэтому многое пропускает. На портале поставщика персонала механизмы перед запуском проверял сам клиент, а команда тем временем доводила детали.

Что проверить на сайте после обновления CMS?

Не ограничивайтесь главной: откройте каталог, карточку товара и поиск, отправьте каждую форму, оформите тестовый заказ с оплатой. Если есть обмен с 1С, убедитесь, что цены и остатки выгружаются. И посмотрите, не сбросились ли robots.txt, sitemap и мета-теги к настройкам по умолчанию.

Какие браузеры и телефоны брать для проверки?

Начните со статистики: в Яндекс Метрике видно, с каких браузеров и устройств приходят ваши посетители, их и проверяйте первыми. Мобильную версию смотрите на настоящих телефонах, хотя бы на одном iPhone с Safari и одном Android.

Как проверяли права ролей на портале поставщика персонала

Чем сложнее сайт, тем больше в тестировании проверок прав. В проекте веб-портала для компании, которая поставляет персонал торговым сетям в Красноярске, мы сделали четыре ролевые модели: администратор, менеджер, суперменеджер с расширенными правами и магазины. Каждая точка видит только свои заявки. В процессе добавили роль сотрудника с личным кабинетом и мобильной версией.

От дизайна до тестирования прошло 2–3 месяца. На момент подготовки кейса портал проходил тестирование: клиент проверял механизмы, мы доводили детали перед запуском. Главный тест для такого портала простой и кропотливый: зайти под каждой ролью и пройти все сценарии. Магазин не должен открыть чужую заявку даже по прямой ссылке, а менеджер не должен менять то, что разрешено только суперменеджеру. Как устроены права, рассказываем в статье Ролевая модель доступа.

Проверка по прямой ссылке находит больше дыр, чем клики по меню. Если интерфейс прячет кнопку, а сервер не проверяет права, данные уйдут через адресную строку.

Что проверить перед запуском самому

Даже без тестировщика владелец сайта может за час пройти базовый список:

Отправьте каждую форму и убедитесь, что заявка пришла туда, где её увидит менеджер: на почту, в CRM, в мессенджер.
Откройте сайт на своём телефоне: номер в шапке нажимается, меню открывается, кнопки не уезжают за край.
Оформите тестовый заказ до конца, включая оплату и письмо покупателю.
Введите несуществующий адрес: сайт должен показать страницу 404, а не пустой экран.
Проверьте главную и пару внутренних страниц в PageSpeed Insights.
Убедитесь, что сайт открывается по HTTPS и браузер не ругается на сертификат.

Чек-лист самостоятельной проверки сайта перед запуском: формы, мобильная версия, тестовый заказ, страница 404, скорость, HTTPS — Что проверить перед запуском самому

Когда окупаются автотесты

Ручное тестирование делает человек по чек-листу. Оно подходит для нового сайта, для вёрстки и для всего, где нужен взгляд: удобно ли, понятно ли. Автотесты пишут программисты, и дальше они сами прогоняют сценарии после каждого обновления. Их есть смысл писать, когда сайт живёт годами, часто обновляется и ошибка в корзине стоит дорого. Для сайта-визитки автотесты обычно не окупаются.

Из-за чего поломки всплывают уже после запуска

Проверять сайт только на компьютере разработчика. У него быстрый интернет, большой монитор и свежий браузер.
Тестировать на рабочем сайте с реальными заказами и рассылками. Для проверок нужна тестовая копия.
Не перепроверять сайт после обновления CMS или модулей. Обновление может сломать формы и оплату, которые раньше работали.
Запускать рекламу без нагрузочного теста. Если сайт падает под наплывом посетителей, бюджет уходит впустую.

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