Тестирование веб-сервисов *

Перевод статьи Vitalij Mik Clean Code Architecture and Test Driven Development in PHP

Понятие «архитектура чистого кода» (Clean Code Architecture) ввел Роберт Мартин в блоге 8light. Смысл понятия в том, чтобы создавать архитектуру, которая не зависела бы от внешнего воздействия. Ваша бизнес-логика не должна быть объединена с фреймворком, базой данных или самим вебом. Подобная независимость даёт ряд преимуществ. К примеру, при разработке вы сможете откладывать какие-то технические решения, например выбор фреймворка, движка/поставщика БД. Также вы сможете легко переключаться между разными реализациями и сравнивать их. Но самое важное преимущество такого подхода — ваши тесты будут выполняться быстрее.

Просто подумайте об этом. Вы действительно хотите пройти роутинг, подгрузить абстрактный уровень базы данных или какое-нибудь ORM-колдовство? Или просто выполнить какой-то код, чтобы проверить (assert) те или иные результаты?

2015 год выдался богатым на нововведения, связанные с улучшениями веб-платформы. Аксель Рошмайер рассматривает 6 технологий, которые ему кажутся наиболее интересными:

1. Electron;
2. React Native;
3. Прогрессивные веб-приложения;
4. Visual Studio Code;
5. Rollup;
6. WebAssembly.

Программы поиска уязвимостей всегда привлекают немало внимания со стороны хакеров и специалистов по безопасности. Ведь это легальный способ неплохо зарабатывать одними только поисками багов (при условии, что есть хороший опыт и голова на плечах). На днях нам представилась возможность взять интервью у багхантера Ивана reactors08 Григорова. Он лидер нашей программы Bug Bounty и занимает 11-е место в общем рейтинге платформы HackerOne.

Как начать искать баги? Может ли это быть единственным источником дохода? В каких Bug Bounty участвовать? Сколько зарабатывают багхантеры? И почему поиском уязвимостей особенно выгодно заниматься в кризис? Ответы на эти и другие вопросы читайте в нашем интервью.

Предисловие

Описанные ниже советы и рекомендации были сформированы на основании опыта создания тестирования и автоматизации с нуля в двух компаниях и старте подобных работ в третьей. Соответственно, на лавры всезнающего специалиста нет никаких претензий, это скорее попытка поделиться опытом, сформированная в виде пошагового руководства по актуальной последнее время теме — автоматизации тестирования в компании.

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

А вот о том, как вообще подойти к тестированию, с чего начать, как продумать тест план и начать формировать тест кейсы, как отбирать тесты для дальнейшей автоматизации, оценивать время работ и нужна ли вам вообще автоматизация и будет рассказано ниже.

P.S.: И последнее — данный текст бы никогда не сформировался, если бы не полезные лекции Алексея Баранцева и Натальи Руколь, а также пропасть информации, написанная добрыми людьми за последние годы по данной теме.

Вот теперь всё, вы предупреждены — можно начинать рассказ.

Новый год начался для нас с возвращения на Хабр. Итак, daddy’s home. Мы решили вернуть наш блог к жизни, чтобы делиться новостями компании, технологическими секретами, жизненным опытом и общаться c вами, тем более и рассказать нам есть о чем.

Новую страницу нашего блога мы начнем, пожалуй, с небольшого эксперимента. Мы решили развернуть наш офисный пакет ONLYOFFICE на мини-серверах. В качестве непривычной тестовой среды для нашего ПО мы использовали три разных (по стоимости и, соответственно, мощности процессора) машины Intel NUC.

Что из этого всего вышло — читайте далее.

Не так давно мне довелось выступать на конференции FFConf с докладом «Вам следует использовать <впишите нужную библиотеку/фреймворк>, это самое лучшее!». И основные мысли я решил изложить в публикации, в надежде, что это спровоцирует в профессиональной среде более широкую дискуссию о «стоимости» современных фреймворков на мобильных устройствах.

Для желающих обратиться к оригиналу моего выступления вот видео:



и слайды презентации: speakerdeck.com/paullewis/framework-here-its-the-bestestest.

Именно таким вопросом задалась команда Почты Mail.Ru перед написанием очередного сервиса. Основная цель такого выбора — высокая эффективность процесса разработки в рамках выбранного языка/технологии. Что влияет на этот показатель?

• Производительность;
• Наличие средств отладки и профилирования;
• Большое сообщество, позволяющее быстро найти ответы на вопросы;
• Наличие стабильных библиотек и модулей, необходимых для разработки веб-приложений;
• Количество разработчиков на рынке;
• Возможность разработки в современных IDE;
• Порог вхождения в язык.

Кроме этого, разработчики приветствовали немногословность и выразительность языка. Лаконичность, безусловно, так же влияет на эффективность разработки, как отсутствие килограммовых гирь на вероятность успеха марафонца.

«У любой задачи существует по крайней мере одно очевидное и невероятно простое для понимания неправильное решение»

Как кто-то из вас уже знает, широко известный ресурс Рутрекер провел акцию «Учения по гражданской обороне». Суть её заключалась в «тренировочном» закрытии доступа на форум для всех пользователей из России на сутки. На следующий день популярные интернет-издания пестрели заголовками «Учебная блокировка Рутрекера не отразилась на его посещаемости». Для меня как регулярного пользователя этого сайта тема с его блокировкой особенно болезненна.

Увидев обнадеживающие заголовки, я порадовался за маленькую победу любимого ресурса. Однако после прочтения статей у меня возникло несколько вопросов. Поэтому я и решил разобраться: действительно ли Рутрекер успешно справился с задачей и научил всех своих пользователей легко и непринуждённо обходить блокировки?

Мы заканчиваем публикацию перевода по тестированию и анализу производительности от команды Patterns&Practices о том, с чем нужно есть ключевые показатели производительности. За перевод спасибо Игорю Щегловитову из Лаборатории Касперского. Остальные наши статьи по теме тестирования можно найти по тегу mstesting

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

Системные метрики...

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



Представьте, что после пары дней жизни в оффлайне как обычно выводите компьютер из гибернации, первым делом отправляетесь на вкладку открытого браузера с содержимым ящика электронной почты от Mail.ru (я понимаю, что тем, кто ей не пользуется по идейным или иным веским соображениям, это представить тяжелее всего, но всё же попробуйте), и вместо обычных нескольких десятков писем во «Входящих», которые уже приготовились быстренько разгрести-просмотреть, видите только прочитанные позавчерашние. Первым делом конечно мысль, что ещё не прочихалось сетевое соединение, обновляем страницу, хм, то же самое, по другим вкладкам видно, что выход в Интернет есть.

Ну, значит виноват кэш. Переоткрываем почту в новой вкладке, перелогиниваемся в ящике, наконец входим через приватный режим и приходим к неутешительному выводу, что проблема серьёзнее. Начинаем обмозговывать первую пришедшую на ум версию о превышении лимита на объём ящика. Параллельно узнаём от администрации одного блога, что он получает от нашего ящика обратно отправленные туда в рамках подписки-рассылки письма. Отправляем себе с другого почтового сервиса весточку и любуемся на превращение её в бумеранг, вернувшийся от mailer-daemon@corp.mail.ru с вердиктом «Mailbox full: адресат@mail.ru».

Поиск жилья, информации о товарах, вакансий, знакомств, сравнение товаров фирмы с конкурентами, исследование отзывов в сети.



В интернет опубликовано много полезной информации и умение извлекать данные поможет в жизни и работе. Научимся получать информацию с помощью webdriver API. В публикации приведу два примера, код которых доступен на github. В конце статьи скринкаст про то, как программа управляет браузером.

Мы продолжаем публикацию перевода по тестированию и анализу производительности от команды Patterns&Practices о том, с чем нужно есть ключевые показатели производительности. За перевод спасибо Игорю Щегловитову из Лаборатории Касперского. Остальные наши статьи по теме тестирования можно найти по тегу mstesting

В первой статье цикла по анализу ключевых показателей производительности мы наладили контекст, теперь переходим к конкретным вещам. В этой части — про анализ метрик пользовательских, бизнесовых и внутри приложения.

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

Итак,

Как собирать пользовательские метрики?..

… Или, другими словами, как посчитать время на тестирование так, чтобы все поверили? Ведь на самом деле у нас обычно — две цели. Первая — посчитать время так, чтобы не ошибиться и правильно распределить ресурсы — скорее всего, поначалу сделать это хорошо все равно не получится. Вторая цель более реальна: посчитать время на тестирование так, чтобы доказать кому-то, что вам нужны еще люди в команде, объяснить, почему вы не успеваете и т. д. Как ни странно, после того, как раз 50 сделаете второе, то и первое будет получаться!

Давайте теперь посмотрим, как считать время на тестирование, на конкретных примерах.

Некоторое время назад мы в HeadHunter обнаружили “сумеречную зону” при передаче новой версии сайта из тестирования в эксплуатацию. Недостаточное внимание к разнице между тестовой и боевой инфраструктурой периодически приводило к падению сайта.



Старые тестовые стенды заметно отличались по внутреннему устройству от рабочего кластера. Отличались init-скрипты для запуска сервисов, отличались файлы конфигурации по расположению и содержанию. Взаимодействие сервисов между собой происходило без учета особенностей боевого окружения.

Я покажу логику нашего решения, которая позволила достичь качественно новых результатов тестирования.

Эта статья продолжает мой доклад на SQA Days-18.

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

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

Недавно наша команда получила код от нового клиента, и нам было поручено после небольшого рефакторинга быстро переходить к реализации нового функционала. Мы понимали, что могли бы улучшить код, перенеся клиентские стили на Sass, и это упростило бы нам поддержку в будущем.

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

Раньше я рассматривал такие изменения как большие риски. В конце концов, C в CSS это каскадирование, где порядок абсолютно важен. Реструктуризация нескольких стилей означает изменение порядка, что, естественно, приводит к большому риску что-то сломать.

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

На этот раз было решено построить визуально регрессионный набор тестов.

Уже больше года у Acronis новый логотип, о том, как он создавался можно прочитать тут. В рамках ребрендинга обновился и сайт www.acronis.com. Для построения сайта мы выбрали CMS Drupal. Сайт получился классный снаружи и непростой внутри: 28 локалей (!), отзывчивый веб-дизайн, карусели, визарды, всплывающие окна… в итоге пришлось задействовать множество различных модулей друпала, некоторые из них кастомизировать и писать собственные. При работе такой динамичной, сложной системы неизбежны ошибки. Их предотвращением и выявлением занимается команда контроля и обеспечения качества вебсайта. В этой статье мы хотим поделиться своим успешным рецептом автоматизации тестирования нашего сайта.

В этой статье хотелось бы поделиться одним из способов простого и удобного интеграционного тестирования http-сервиса, написанного на Go. Интеграционные тесты бывает непросто создавать так, чтобы обходиться без сложных скриптов, но на помощь нам придет Docker, пакет из стандартной библиотеки httptest и билд-теги. Для примера мы будем использовать MySQL базу данных с миграциями, управляемыми пакетом goose. Финальной целью является получить простое и удобное кроссплатформенное интеграционное тестирование простым запуском команды go test, будь это рабочий ноутбук или Continuous Integration сервер.

Одной из возможностей повышения качества выпускаемого продукта является соответствие окружений на боевых серверах и в среде тестирования. Мы постарались минимизировать количество ошибок, связанных с различием конфигураций, путем перехода от нашего старого тестового окружения, где настройки сервисов сильно отличались от боевых, к новому окружению, где конфигурация практически соответствует боевой. Сделали мы это с помощью docker и ansible, получили много профита, но и не избежали различных проблем. Об этом переходе и интересных подробностях я постараюсь рассказать в данной статье.

Самый лучший способ оценить, хорошо ли мы протестировали продукт – проанализировать пропущенные дефекты. Те, с которыми столкнулись наши пользователи, внедренцы, бизнес. По ним можно многое оценить: что мы проверили недостаточно тщательно, каким областям продукта стоит уделить больше внимания, какой вообще процент пропусков и какова динамика его изменений. С этой метрикой (пожалуй, самой распространённой в тестировании) всё хорошо, но… Когда мы выпустили продукт, и узнали о пропущенных ошибках, может быть уже слишком поздно: на “хабре” появилась про нас гневная статья, конкуренты стремительно распространяют критику, клиенты потеряли к нам доверие, руководство недовольно.

Чтобы такого не происходило, мы обычно заранее, до релиза, стараемся оценивать качество тестирования: насколько хорошо и тщательно мы проверяем продукт? Каким областям не хватает внимания, где основные риски, какой прогресс? И чтобы ответить на все эти вопросы, мы оцениваем тестовое покрытие.

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

Кому это будет интересно?

• Если вы начали писать тесты недавно.
• Если вы пишете тесты и считаете, что в них много копипасты, или можно значительно улучшить их.
• Если вы пишете тесты изредка или не пишете совсем, так как вам не нравится или считаете, что это долго.
• Если вы мастер в написании тестов. Возможно, вы узнаете некоторые тонкости или найдете несколько полезных мелочей.