280  /  331

Тестирование проектов

Просмотров: 2132 (Статистика ведётся с 06.02.2017)

Для тестирования сайтов оптимально подходит метод чеклиста - списка операций, которые нужно обязательно выполнить.

Контрольный список (перечень, таблица, карта; англ. checklist) — список факторов, свойств, параметров, аспектов, компонентов, критериев или задач, структурированных особым образом с целью достижения поставленных задач.

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

Чеклисты обычно составляются опытными сотрудниками. По мере накопления интеллектуального багажа компании в базах знаний, развиваются и совершенствуются и чеклисты. Суть проста — сэкономить время и деньги, не позволив сотрудникам непроизвольно (а иногда и произвольно) наступать на грабли 2 и более раз.

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

  • Поиск. Если на сайте используется форма поиска, то её следует протестировать в первую очередь. Обязательно надо проверить, чтобы ссылки в результатах не были битые. (Битые ссылки присутствуют в анонсах, в подробных описаниях, просто в статическом контенте, в настройках инфоблоков.) Если на сайте используется несколько инфоблоков с динамической информацией, то нужно сделать поисковые запросы, чтобы найти по отдельности элементы различных инфоблоков и проверить, корректно ли работают ссылки в результатах поиска.
  • F5. Во всех формах, в которых пользователь может оставлять какие-либо данные (например, комментарии), нужно проверить, не отправляются ли данные снова при нажатии кнопки F5 в браузере.
  • Пользователи и права доступа. Следует протестировать сайт в трёх состояниях: неавторизованным, авторизованным и авторизованным под администратором. Часто бывает, что создавая инфоблок из-под администратора, ему забывают поставить нужные права доступа, и он остается доступным только для администраторов.
  • Карта сайта Не всегда для этой страницы подойдёт стандартный компонент Карта сайта. Если основная информация на сайте – каталог товаров (сделанный, естественно, с помощью модуля инфоблоков), то в карте сайта логично вывести разделы каталога, а не только разделы сайта.
  • Дефолтные шаблоны. Необходимо проверить, не используются ли где-нибудь на сайте дефолтные шаблоны. Может получиться не очень хорошо, если, например, пользователь пытается восстановить пароль, ему на почту уходит письмо со ссылкой на сайт, он нажимает на ссылку и видит не привычный ему дизайн сайта, а пример дефолтного «корпоративного» сайта "1С-Битрикс: Управление сайтом".
  • Стили в визуальном редакторе. Хорошо, когда контент-менеджер, пользуясь визуальным редактором, видит в нём текст, максимально похожий на текст, который отобразится на сайте. То есть для абзацев, заголовков и т.д. свой кегль шрифта, цвет и т.д.
  • Динамическая информация во включаемых областях Если во включаемой области содержится какая-либо динамическая информация, то она может закешироваться, что скорее всего приведет к нежелательному результату. Лучше вообще не использовать динамическую информацию во включаемой области.
  • Резервная копия, обновления. Необходимо обновить Битрикс до актуальной версии, сделать резервную копию сайта и сохранить её на локальный компьютер.
  • Кеш. Следует проверить, включено ли автокеширование. Если оно не включено, то нужно его включить и повторить всё тестирование с самого начала
  • Права доступа. Проверка на корректность прав доступа различных групп пользователей, генерация отчета по правам групп в папках сайта.
  • Ядро системы. Проверка работы ядра и соответствие его оригиналу с генерацией отчета о папках компонентах и модулях не соответствующих оригиналу и генерации отчета о несоответствии версий. Иногда шаловливые ручки позволяют себе править непосредственно компоненты Bitrix Framework и, чтобы не порушить функционал сайта, очень полезно перед тем как обновлять проект узнать что наделано не так и что наделано дополнительно.
  • Неиспользуемые файлы. Часто при разработке или изменениях делают резервные копии и хорошо если делают приставку old а иногда просто весь этот мусор остается, плюс неиспользуемые картинки и т.п.
  • Сторонние подключения. Часто к сайту подключают различные партнерские программы: баннеры, скрипты и т.п., вещи без которых невозможна монетизация. Но при этом может пострадать безопасность. Необходимо проверять подобный функционал на предмет безопасности и наличия уязвимостей (доступ на редактирование, доступ к ядру, возможность внедрения кода, сохранения через подключаемый модуль файлов)
Из опыта веб-разработчиков.

Роман Петров: Один из простых способов протестировать на ошибки разработки ваш сайт на "1С-Битрикс: Управление сайтом" - это перед запуском проекта, включить тест производительности на нужное время и на том же сервере запустить 3-4 одновременных команды wget на зеркалирование сайта. Первое обращение создаст кэш страницы, а остальные - обратятся уже к закэшированным файлам. Это позволит очень легко выявить все проблемные странички (мелкие ошибки "по забывчивости", ошибки верстки (пропущенные файлы и др.)) и исправить ошибки.

Если у вас еще не достаточно опыта для составления собственного чеклиста, то воспользуйтесь штатным инструментом Монитор качества.

Видео по теме:

Тестирование и нагрузочные испытания - как, чем и зачем (500 мБ, 17 минут 43 секунды)



7
Курсы разработаны в компании «1С-Битрикс»

Если вы нашли неточность в тексте, непонятное объяснение, пожалуйста, сообщите нам об этом в комментариях.
Развернуть комментарии