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

Kazan Startup Weekend, прошедший в ИТ-парке, доказал, что кризис инвестициям не помеха, как говорится, война войной, а стартапы привлекли более $1 млн – это больше, чем на прошлогоднем Kazan Startup Week.

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

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

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

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

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

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

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

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

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

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



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

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

В данной статье речь пойдет об использовании фреймворка testNG, а конкретно — о реализованных в нем и довольно редко используемых интерфейсах: IRetryAnalyzer, ITestListener, IReporter. Но обо всем по порядку.

Вечной проблемой каждого тестировщика при запуске автотестов является “падение” отдельных сценариев от запуска к запуску рандомно. И речь идет не о падении наших тестов по объективным причинам (т.е. действительно имеет место ошибка в работе тестируемого функционала, или же сам тест написан не корректно), а как раз о тех случаях, когда после перезапуска ранее проваленные тесты чудом проходят. Причин такого рандомного падения может быть масса: отвалился интернет, перегрузка CPU / отсутствие свободной RAM на устройстве, таймаут и др. Вопрос — как исключить или хотя бы уменьшить количество таких не объективно проваленных тестов?

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

1) текущее приложение автотестов было решено разместить на сервере (CI);
2) реализация мультипоточности в проекте превратилась из желания в mustHave (в виду необходимости сокращения времени регрессионного тестирования сервиса).

Второму пункту лично я был очень рад, так как считаю, что любой процесс, который может длиться меньшее количество времени — обязательно должен поступать именно таким образом (будь то прохождение автотеста или очередь на кассе в супермаркете: чем быстрее мы можем завершить эти процессы, тем больше времени у нас остается для занятий чем-то действительно интересным). Так вот, разместив наши тесты на сервере (тут нам помогли админы и их знание jenkins) и запустив их в потоках (тут уже помогла наша усидчивость и эксперименты с testng.xml), мы получили сокращение времени прохождения тестов из 100 минут до 18, но одновременно мы получили прирост в проваленных тестах >2 раза. Поэтому к первым двум пунктам добавился следующий (собственно, сам челлендж, которому и посвящена эта статья):

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



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

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

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

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

Итак,

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

История создания

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

… Или, другими словами, как посчитать время на тестирование так, чтобы все поверили? Ведь на самом деле у нас обычно — две цели. Первая — посчитать время так, чтобы не ошибиться и правильно распределить ресурсы — скорее всего, поначалу сделать это хорошо все равно не получится. Вторая цель более реальна: посчитать время на тестирование так, чтобы доказать кому-то, что вам нужны еще люди в команде, объяснить, почему вы не успеваете и т. д. Как ни странно, после того, как раз 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, получили много профита, но и не избежали различных проблем. Об этом переходе и интересных подробностях я постараюсь рассказать в данной статье.

Привет, Хабровчане! Сегодня поговорим об оптимизации скорости загрузки сайта. Это первое на что обращает внимание пользователь особенно при входе с мобильных устройств. Какие проблемы ведет за собой низкая скорость сайта:
— снижение конверсии (исследование Walmart);
— уменьшение охвата аудитории;
— увеличение показателя отказов;
— снижение доступности сайта;
— снижение скорости индексации поисковыми роботами.

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

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

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

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

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

Захотелось поделиться с вами моим способом тестирования веб-сервисов.

Принцип такой:

1. Создаем maven проект.
2. Настраиваем его так, чтобы с каждым запуском выполнялось следующее:
2.1. загружалось WSDL описание сервиса по ссылке
2.2. генерировался код клиента на основе WSDL описания
2.3. генерировался код ассертов для классов, участвующих в проверках, в том числе тех, которые были сгенерированы на предыдущем этапе
3. Пишем тесты.
4. Добавляем проект в jenkins, который и запускает само тестирование.

Нам понадобятся следующие инструменты: Java, maven, AssertJ, TestNG.

AssertJ — интересный фреймворк, который, помимо всего прочего, умеет генерировать асерты для конкретных классов. Это позволяет писать тесты так: