Что такое качество? Качество — предсказуемость, стабильность работы, соответствие ожиданиям.


Применительно к программному обеспечению качество — минимум ошибок при успешном решении задач.

Современный софт — не музейный экспонат, он постоянно меняется вместе с условиями работы компании.

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

Решение — автоматизированное тестирование и непрерывная интеграция (continuous integration).

Удивительно, но в мире заказной веб-разработки, создания сайтов и запуска интернет-магазинов почти никто не применяет эти технологии.

Мы в отделе сопровождения сайтов в крупных проектах (Альфа-Банк, mybox, Издательство “Учитель”) освоили работу на основе автотестов и непрерывной интеграции.

Расскажем зачем это нужно, как работает и сколько стоит.

Идея автоматического тестирования сайтов

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

Хозяйке на заметку:
Чтобы быть уверенным в корректности работы программы, нужно проверять её на отсутствие ошибок. В ответственных проектах enterprise-сегмента вопрос качества становится важнейшим. Сайт, портал, сервис, которому нельзя доверять — плохой продукт. В разработке программного обеспечения этот процесс называется тестированием.  При больших объемах работы тестирование нужно автоматизировать.

В простых случаях тестирование выполняет человек. Он проверяет работу различных сценариев использования в разных браузерах, для учётных записях с разными правами (оптовик, партнёр, гость, админ и т.д.). Чем больше проект, тем больше проверок.

В сложных и дорогих веб-проектах часто, в дополнение к “человеческим” проверкам, используют автоматизированное тестирование. Автоматизированное тестирование выполняется быстрее ручного и исключает невнимательность человека.

Существует разные подходы и инструменты для организации автоматизированного тестирования. Наиболее популярны тестирование отдельных частей проекта (модулей) и тестирование конкретных сценариев использования (например, добавление товара в корзину и оформление заказа).

Тестирование по частям принято называть модульным или Unit-тестированием. Тестирование сценариев, которые позволяют пользователям решать определённые задачи (например, оформлять заказы), называется функциональным тестированием.

Мы расскажем о том, как внедрить оба вида тестирования в крупном проекте.

Модульное тестирование

Хозяйке на заметку: 

Для использования модульного тестирования весь проект должен разрабатываться как набор модулей и связей между ними. Автомобиль - система, состоящая из отдельных частей (ДВС, ГУР, климат-контроль и т.д). Это отдельные модули, работу которых можно проверить. Мясной фарш - не модульная система, хотя и состоит из отдельных частей.

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

Для модульного тестирования веб-проектов на 1С-Битрикс мы используем PHPUnit. Если проект запрограммирован аккуратно (с соблюдением принципов объектно-ориентированного программирования), PHPUnit позволяет быстро покрывать код тестами.

Модульное тестирование

Важно:
Модульные тесты дают понять разработчикам, какое изменение явилось причиной ошибки и вовремя её исправить (до переноса изменений с тестового сервера на основной).

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

Из опыта:
Для покрытия кода на 60% уходит 1/10 времени затраченного на разработку (5 дней пишем код, пол дня пишем тесты). Код считается “покрытым”, если в ходе тестирования он выполнялся хотя бы 1 раз, а лучше 2.

Функциональное тестирование

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

Сценарий оформления заказа:

  1. Открыть главную страницу
  2. Найти первый товар в списке и кликнуть на его название (или фото)
  3. Запомнить название товара
  4. Найти на странице кнопку с текстом “Купить” и нажать на неё
  5. Открыть страницу “Корзина”
  6. Проверить есть ли в корзине элемент с нужным названием (мы его запомнили на шаге 3)
  7. Найти кнопку “Оформить заказ” и нажать на неё
  8. Заполнить поля формы оформления заказа тестовыми данными (в поле “имя” ввести имя и т.д.)
  9. Найти кнопку “Отправить заказ” и нажать на неё
  10. Запомнить номер, присвоенный заказу
  11. Открыть список заказов и найти заказ с нужным номером
  12. Если заказ найден - тест пройден успешно

Прохождение таких тестов после завершения доработки сайта гарантирует работу основных сценариев работы проекта. Если после обновления сайта заказ перестал оформляться вы об этом узнаете немедленно, а не через 1-2 дня простоя интернет-магазина.

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

Проблемы:
Любое изменение верстки требует внесения изменений в тесты.

Из нашего опыта:  
На создание теста для формы обратной связи уходит 2-4 часа.

Автоматизация запуска тестирования

Современные инструменты разработки позволяют запускать тесты нажатием одной кнопки. Эта задача решается с помощью специального программного обеспечения. Мы используем Jenkins.
Эта система работает на отдельном сервере. Программист даёт сигнал что он закончил решать задачу и пора запускать тестирование. Jenkins получает изменения программиста, добавляет их на сайт и запускает тесты. По окончанию тестирования, Jenkins отправит всем заинтересованным письма с подробным отчётом о провалившихся тестах  и результатах свой работы.

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

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

Шаги сборки

atp1c_17.png

Создание независимой копии проекта

На этом этапе на отдельном сервере Jenkins создаёт копию файлов проекта. Это нужно чтобы исключить возможность влияния внешних факторов (пользователи, программисты, боты google и Яндекс).

Синтаксический анализ

На этом этапе Jenkins проверяет код проекта на наличие синтаксических ошибок, а также ищет копипаст в коде.

Модульное тестирование

На этом этапе Jenkins выполняет все модульные тесты и проверяет работоспособность  всех частей проекта. Во время выполнения Jenkins проверяет, какой код исполнялся в ходе теста, а какой нет. На основе этого создаётся отчёт о покрытии кода тестами. Чем выше процент покрытия, тем лучше.

Функциональное тестирование

На этом этапе Jenkins проверяет выполнение тестовых сценариев в основных браузерах. Результаты этих тестов дают уверенность в том, что последние изменения не сломали бизнес-логику проекта.

Построение отчётов и e-mail уведомления

На этом этапе Jenkins подбивает накопившуюся информацию о результатах тестирования и рассылает их по почте.

Важно:


  • Если модульного тестирования нет, ошибки накапливаются и переплетаются. Проект становится хрупким.
  • Тесты развиваются вместе с проектом, если меняется проект, обязательно нужно менять тесты, иначе они будут врать.
  • Нельзя покрыть проект тестами, если его разработчики не делили свой код на модули. Такие тесты будут показывать температуру на марсе, а поддерживать их актуальность будет невозможно.
  • Актуальность такого функционального теста зависит только от вёрстки в вашем проекте. Поменяли вёрстку — поменяйте тест.
  • Функциональные тесты работают в разы медленнее модульных, т.к. для запуска каждого теста нужно открыть браузер и дождаться пока загрузится страница.
  • Если вы хотите использовать модульное тестирование в своём старом проекте, покрывайте тестами только новые задачи.

Заключение, или “Сколько это стоит?” и “Что для этого нужно?”

Что нужно:

  1. Организовать сервер, на котором будет работать Jenkins.
  2. Купить сервер, на котором будут размещены виртуальные машины с разными операционными системами (+лицензии для операционных систем) и разными версиями браузеров
  3. Настроить VPN между серверами
  4. Установить и настроить Jenkins
  5. Написать тесты

Сколько стоит:

  1. Настройка серверов, установка операционных систем, установка и настройка Jenkins и прочих программных пакетов для среднего проекта — 40 часов работы.
  2. Разработка тестов — очень индивидуальная процедура, ее трудоемкость сильно зависит от конкретики.
    Например, автотест для проверки процедуры авторизации — 3 часа работы, тест оформления заказа с выбором первой системы оплаты и первой службы доставки 8 часов

Для каких веб-проектов нужно автоматическое тестирование и непрерывная интеграция

Веб-разработка по модели “continuous integration” с использованием автоматического тестирования требует заметных организационных и технических затрат.

В небольших, коротких и простых проектах это не окупается.

Если в разработке участвует больше 2 человек, постоянно меняющих код, или объем трудозатрат превышает 200 часов в месяц, внедрение этой технологии обязательно.

На практике только при автоматизированном тестировании удается добиться стабильности процесса и предсказуемости результата.

А это — качество.

Оцените статью
08.12.2015
Понравилась статья?
Поделитесь ссылкой с друзьями и коллегами!

Статьи по теме

10 обязательных задач поддержки сайта на БитриксСтатья посвящена организации поддержки сайтов на Битрикс. Здесь не только про решение технических проблем и устранение багов. Здесь про развитие живых проектов...
Как увеличить продажи оптово-розничных компаний с помощью автоматизации?Расскажем об увеличении продаж металлопроката за счет улучшения пользовательского опыта. Доработали интернет-магазин, чтобы клиенты видели свои заказы независим...
ТОП проблем сайтов на Битриксе из аудитов ИНТЕРВОЛГИ В статье расскажем о наиболее частых ошибках разработки проектов на 1С-Битрикс. Мы выявили их в ходе 10+ последних аудитов производительности и качества код...
Запускаем бесконтактную доставку в интернет-магазине на БитриксСегодня, как никогда, магазины стремятся перенести продажи в онлайн. Это не просто тренд – это необходимость. Но если у вас уже есть интернет-магазин, это не зн...
Foodtech-разработка: интерфейсы для касс MYBOXСтатья о том, как разобраться с задачей переработки дизайна кассового ПО MYBOX: выезд «в поля», вдумчивый аудит и много-много раз перерисованный дизайн ...
Решение типовых ошибок при организации продаж через интернет-магазин в разные регионы Как сделать свой сайт удобным для пользователей, оперативным в обновлении актуальных остатков, цен, скидок для товаров в их регионе? Счастливые облад...
Мы работаем по одному из двух форматов:
  • аренда команды (от 2 человек, не менее 3 месяцев);
  • итерации с фиксированной ценой (1-3 месяца длительностью).
ИНТЕРВОЛГА предоставляет:
  • регулярные онлайн-планерки с заказчиком;
  • квалифицированных специалистов;
  • организованную команду (находятся в одном помещении, что упрощает решение рабочих вопросов);
  • полную прозрачность и регулярность отчетов о результатах.
Ключевые услуги:
  • нагруженный интернет-магазин;
  • личный кабинет;
  • оптовые продажи — B2B-платформа;
  • маркетплейс;
  • технический аудит сайта;
  • Битрикс24 — корпоративные HR-порталы;
  • Битрикс24 — построение CRM-системы;
  • Битрикс24 — личные кабинеты сотрудников;
  • Битрикс24 — аудит портала;
  • 1С — интеграция с другими системами;
  • 1С — доработка системы;
  • маркетинг — комплексное интернет-продвижение;
  • маркетинг — продвижение для B2B.
Хотите получать лучшие статьи от INTERVOLGA раз в месяц?
Подпишитесь на рассылку — спамить не будем