Что такое качество? Качество — предсказуемость, стабильность работы, соответствие ожиданиям.
Применительно к программному обеспечению качество — минимум ошибок при успешном решении задач.
Современный софт — не музейный экспонат, он постоянно меняется вместе с условиями работы компании.
Налицо проблема: с одной стороны — обеспечить гибкость и скорость развития, с другой — стабильность и минимум ошибок.
Решение — автоматизированное тестирование и непрерывная интеграция (continuous integration).
Удивительно, но в мире заказной веб-разработки, создания сайтов и запуска интернет-магазинов почти никто не применяет эти технологии.
Мы в отделе сопровождения сайтов в крупных проектах (Альфа-Банк, mybox, Издательство “Учитель”) освоили работу на основе автотестов и непрерывной интеграции.
Расскажем зачем это нужно, как работает и сколько стоит.
Наличия ошибок в программном продукте избежать нельзя, ошибки есть и в больших и в маленьких программах, и на сайтах и в операционных системах. Даже в продуктах google есть ошибки.
Хозяйке на заметку:
Чтобы быть уверенным в корректности работы программы, нужно проверять её на отсутствие ошибок. В ответственных проектах enterprise-сегмента вопрос качества становится важнейшим. Сайт, портал, сервис, которому нельзя доверять — плохой продукт. В разработке программного обеспечения этот процесс называется тестированием. При больших объемах работы тестирование нужно автоматизировать.
В простых случаях тестирование выполняет человек. Он проверяет работу различных сценариев использования в разных браузерах, для учётных записях с разными правами (оптовик, партнёр, гость, админ и т.д.). Чем больше проект, тем больше проверок.
В сложных и дорогих веб-проектах часто, в дополнение к “человеческим” проверкам, используют автоматизированное тестирование. Автоматизированное тестирование выполняется быстрее ручного и исключает невнимательность человека.
Существует разные подходы и инструменты для организации автоматизированного тестирования. Наиболее популярны тестирование отдельных частей проекта (модулей) и тестирование конкретных сценариев использования (например, добавление товара в корзину и оформление заказа).
Тестирование по частям принято называть модульным или Unit-тестированием. Тестирование сценариев, которые позволяют пользователям решать определённые задачи (например, оформлять заказы), называется функциональным тестированием.
Мы расскажем о том, как внедрить оба вида тестирования в крупном проекте.
Хозяйке на заметку:
Для использования модульного тестирования весь проект должен разрабатываться как набор модулей и связей между ними. Автомобиль - система, состоящая из отдельных частей (ДВС, ГУР, климат-контроль и т.д). Это отдельные модули, работу которых можно проверить. Мясной фарш - не модульная система, хотя и состоит из отдельных частей.
Если проект похож на мясной фарш, его невозможно автоматически тестировать, и наоборот — если код должен быть покрыт автоматическими тестами, приходится думать об архитектуре проекта (просто шаблоны и компоненты не считаются, это не архитектура).
Для модульного тестирования веб-проектов на 1С-Битрикс мы используем PHPUnit. Если проект запрограммирован аккуратно (с соблюдением принципов объектно-ориентированного программирования), PHPUnit позволяет быстро покрывать код тестами.
Важно:
Модульные тесты дают понять разработчикам, какое изменение явилось причиной ошибки и вовремя её исправить (до переноса изменений с тестового сервера на основной).
Проблемы:
любое изменение в проекте заставляет менять тесты. Если тесты не поддерживать в актуальном состоянии, вскоре им нельзя будут доверять. На поддержку тестов уходит время.
Из опыта:
Для покрытия кода на 60% уходит 1/10 времени затраченного на разработку (5 дней пишем код, пол дня пишем тесты). Код считается “покрытым”, если в ходе тестирования он выполнялся хотя бы 1 раз, а лучше 2.
Функциональное тестирование не накладывает никаких ограничений на архитектуру проекта. Принцип тестирования прост: мы отправляем в браузер сценарий команд, который нужно выполнить и проверяем результат.
Сценарий оформления заказа:
Прохождение таких тестов после завершения доработки сайта гарантирует работу основных сценариев работы проекта. Если после обновления сайта заказ перестал оформляться вы об этом узнаете немедленно, а не через 1-2 дня простоя интернет-магазина.
Важно:
Тест практически не зависит от версии браузера. Написав такой тест один раз мы можем проверять его работу в любых браузерах в любых операционных системах.
Проблемы:
Любое изменение верстки требует внесения изменений в тесты.
Из нашего опыта:
На создание теста для формы обратной связи уходит 2-4 часа.
Jenkins пришёл в веб из мира разработки десктопного программного обеспечения. Процесс превращения программы из исходных кодов в нечто исполняемое и вразумительное называется сборкой.
Обычно сборка состоит из нескольких шагов: проверка отсутствия синтаксических ошибок, тестирование модулей, компиляция программы и т.д. Каждая операция называется шагом сборки. Необходимость делить процедуру на шаги обусловлена экономией времени. Например, если мы нашли синтаксическую ошибку, не стоит продолжать сборку проекта.
На этом этапе на отдельном сервере Jenkins создаёт копию файлов проекта. Это нужно чтобы исключить возможность влияния внешних факторов (пользователи, программисты, боты google и Яндекс).
На этом этапе Jenkins проверяет код проекта на наличие синтаксических ошибок, а также ищет копипаст в коде.
На этом этапе Jenkins выполняет все модульные тесты и проверяет работоспособность всех частей проекта. Во время выполнения Jenkins проверяет, какой код исполнялся в ходе теста, а какой нет. На основе этого создаётся отчёт о покрытии кода тестами. Чем выше процент покрытия, тем лучше.
На этом этапе Jenkins проверяет выполнение тестовых сценариев в основных браузерах. Результаты этих тестов дают уверенность в том, что последние изменения не сломали бизнес-логику проекта.
На этом этапе Jenkins подбивает накопившуюся информацию о результатах тестирования и рассылает их по почте.
Что нужно:
Сколько стоит:
Веб-разработка по модели “continuous integration” с использованием автоматического тестирования требует заметных организационных и технических затрат.
В небольших, коротких и простых проектах это не окупается.
Если в разработке участвует больше 2 человек, постоянно меняющих код, или объем трудозатрат превышает 200 часов в месяц, внедрение этой технологии обязательно.
На практике только при автоматизированном тестировании удается добиться стабильности процесса и предсказуемости результата.
А это — качество.