Тестирование веб-ориентированных приложений. Часть-3: ссылки.

Тестирование ссылок
Когда разговор заходит о проверке ссылок, часто можно слышать слова в стиле "Да, пару раз проверим в процессе, потом ещё разок перед сдачей – и всё". Так вот – не всё.

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

0) "Написал – проверь!" Да, именно под номером ноль идёт этот простой тезис. Добавил новую страничку? Новую картинку? Вписал ссылку на CSS или JS? Проверь! Открой эту новую страницу, убедись, что грузится картинка, что подхватились CSS и JS, что ссылка на некий внешний источник ведёт именно туда, куда должна.

В моей практике случались случаи, когда верстальщики или программисты пропускали "какую-то совсем незаметную ссылочку", а потом… Или долго искали, почему что-то не работает, или приходили к выводу, что "это в принципе не может работать" (для начинающих – нередкий случай) и реализовывали какой-то функционал или какие-то особенности интерфейса заново новым способом.

1) "Firebug разработчику – друг, помощник и товарищ". Достаточно бывает просто "лазить" по разрабатываемому приложению, включив Firebug и поглядывая на его отчёт о запрошенных URL’ах и результатах выполнения этих запросов. Появление там сообщений об ошибках должно насторожить.

Рекомендация начинающим: ОБЯЗАТЕЛЬНО используйте Firebug. Ко мне нередко приходят студенты с прекрасным вопросом: "Я вот скачал крутую библиотеку на JavaScript, все демо-примеры работают, а у меня – ничего не работает". В 9 случаях из 10 – проблема в том, что неверно указаны ссылки на скрипты.

2) "Самодиагностика – великая сила!" Да, не стоит писать каждый раз "линк-чекер". Его вообще не надо писать, т.к. есть готовые. Но! Ваше приложение вполне способно хотя бы сообщать администратору о том, что что-то где-то идёт не так. Современные движки, направленные на хитрую эмуляцию ссылок с использованием mod_rewrite, вынуждены сами отслеживать ситуации, когда, например, новость с номером 6451421875 не существует.

Лирическое отступление. Итак, допустим, ваш Интернет-магазин www.mycoolinetshop.com построен как раз с использованием mod_rewrite и ссылки внутри выглядят так: /notebooks/hp/new/ Логично предположить, что страницы /notebooks/hp/nuve/ не существует. Но какой-то пользователь набрал такой URL. Что он должен увидеть? Как минимум – аккуратную, информативную страницу "на мотив 404" с вариантами, по каким ссылкам пройти, чтобы увидеть искомое (что-то в стиле "Возможно, вы искали…"). Ещё лучше – он должен увидеть контекстно-зависимое сообщение в стиле "Извините, в разделе Ноутбуки – HewlettPackard подраздела nuve нет." + всё те же варианты ссылок, по которым может находиться искомое. И, наконец, чего явно НЕ должно быть: пользователь не должен оказаться на "пустой белой странице". Равно как не должен он оказаться и на странице вида "Вокруг какая-то вспомогательная информация, а в центре – пусто". Также плохо, когда в ответ на запрос пользователь получает стандартное сообщение браузера о том, что страница не найдена.

Возвращаемся к нашим ссылкам. Итак, движок видит, что запрошено несуществующее. Это – повод сформировать письмо администратору. Возможно, что-то где-то вышло из строя, или была допущена ошибка контент-менеджером, или (ещё веселее!) мы обнаружили начальную стадию взлома, когда кто-то "прощупывает" сайт.

3) "Создавайте пометки в генерируемом контенте!" Итак, движок отследил ситуацию "404" ("403" и т.п. – сейчас это не принципиально). Он сообщил об этом администратору, а пользователю показал красивую страницу с подробными инструкциями. Чудесно. Но эта страница с инструкциями может идти либо вместе с "кодом ответа 404", либо с комментарием в первых же строках кода в стиле <!— 404 —> . Зачем? А затем, что, возможно, мы пророчим нашему сайту долгую-предлогую жизнь и всё же планируем встроить в админку свой небольшенький "линк-чекер". На основе этих данных он сможет представить нам полный список страниц, где "что-то не так".

4) "Ссылки исчезают в полночь". К сожалению, практика показывает, что битые ссылки склонны размножаться со временем. Удалили какой-то раздел, статью, что-то переименовали и т.п. А ссылка где-то осталась. Тогда возвращаемся к пункту 3 + приходим к выводу, что проверку ссылок следует повторять раз за разом. Например, банально "по крону" раз в полгода, месяц, неделю – в зависимости от масштаба проекта.

5) "Нормальные герои всегда идут в обход". Для некоторых проверок не нужен даже "линк-чекер". Допустим, у нас есть новостной сайт, где в силу некоей специфики за новостью закреплена одна картинка (ещё пример – форум и аватары пользователей). Имя картинки хранится в таблице базы данных. Можно просто пробегаться по базе данных и проверять, все ли файлы картинок на месте.

6) "Зайцы за оградой разбегаются особенно быстро". Хорошо проверять "свои ссылки" (т.е. ссылки на свои же страницы и файлы). Но часто приходится указывать ссылки на внешние источники. Система управления контентом должна анализировать добавляемый контент на предмет наличия в нём ссылок и проверять, не получено ли в ответ на запрос по ним сообщение "404" или ему подобное. Это – первый шаг. В идеале можно извлечь запрошенный контент и сохранить где-то в отдельной таблице его хэш. При периодических проверках ссылок – снова извлекать контент, вычислять хэш и сравнивать с сохранённым. Отличие – повод для отправки сообщения администратору.

7) "Внутренний враг". Сложнее всего автоматизировать самодиагностику битых ссылок в шаблонах, JavaScript и т.п. Но спасает эту ситуацию то, что такие ссылки не склонны "умирать без причин", а потому тщательная проверка "линк-чекером" сайта перед его сдачей в эксплуатацию поможет сильно сэкономить нервы и время.

8) "Не самосошлись! (11-я заповедь)" Есть хорошее разумное правило – "на странице не должно быть ссылок на саму себя". Обнаружение в процессе тестирования таких ссылок позволяет избежать ситуаций, когда пользователь после клика окажется на той же самой странице. Это, конечно, больше вопрос юзабилити, но всё же.

И, как обычно, в заключение – полу-чек-лист-полу-план. Простенький, но даже такой – лучше, чем никакого.

1. Проверить работоспособность всех ссылок в добавленной или исправленной части сайта.
2. Загрузить страницу со включённым Firebug. Убедиться, что Firebug не показал сообщений об ошибках.
3. Запускать механизм самодиагностики после выхода каждого билда.
4. Проверить наличие "меток" в страницах с сообщениями об ошибках, генерируемых движком.
5. Проверять все внешние ссылки. Хотя бы – один раз вручную сразу после добавления.
6. Убедиться в отсутствии на страницах ссылок "на самих себя".
7. Каждый релиз-кандидат полностью проверять "линк-чекером".