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

Всем привет! Меня зовут Сергей, и в Яндексе я работаю в команде автоматизации тестирования сервисов монетизации. Перед каждой командой, которая занимается задачами автоматизации тестирования, встает вопрос: «Какой [фреймворк|инструмент] выбрать для написания своих тестов?» В этом посте я хочу помочь вам на него ответить. Если быть конкретнее, речь пойдет об инструментах тестирования на языке Python, но многие из идей и выводов можно распространить на другие языки программирования, поскольку подходы часто не зависят от конкретной технологии.



В Python существует множество инструментов для написания тестов и выбор между ними неочевиден. Я опишу интересные варианты использования PyTest и расскажу о его [плюсах|минусах|неявных возможностях]. В статье вы найдёте развёрнутый пример использования Allure, который служит для создания простых и понятных отчётов автотестов. Также в примерах будет применяться фреймворк для написания матчеров — Hamcrest для Python. Надеюсь, что в итоге, те, кто сейчас в поиске инструментов для тестирования, смогут на основе изложенных примеров быстро внедрить функциональное тестирование в своем окружении. Те же, кто уже использует какой-то инструмент, смогут узнать новые подходы, варианты использования и концепции.

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

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

В связи с удалённой рабочей командой и в целом в силу привычки мы рассматривали только веб-варианты. Отбросив по первичному анализу совсем неподходящие нам решения, на выбор остались три кандидата:

TestLink


TestRail


Sitechco


Получаем в результате: Triple Threat Match. Кто кого — увидим в честном бою.

Для начала, мы в команде определили критерии отбора:

• Стоимость лицензии: желательно бесплатно, или хотя бы, недорого;
• Поддерживаемые окружения: в команде используются Google Chrome, Mozilla Firefox, Safari — отказываться или менять браузеры никто не готов;
• Функционал управления тестами: здесь нам важнее всего было удобное создание тестовых наборов, ведение статистики прохождения и наглядной отчётности;
• Наличие элементов тест-менеджмента: очень хочется от инструмента возможностей планирования своих задач, контроля за планами и сроками;
• Юзабилити: если кому-то в команде что-то не понравится, то тратить своё время и “вникать” вряд ли будем. Всё должно быть понятно сразу.

По этим критериям и разберём каждого из кандидатов.

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

Привет!

Сегодня я расскажу о пока еще публично не анонсированном, но уже доступном для использования сервисе в Microsoft Azure Websites под названием Testing In Production (TiP). С его помощью вы сможете начать тестировать свои облачные веб-приложения более тонко и точно, показывая новый функционал лишь малой части ваших пользователей, оставляя в «безопасности» большинство посетителей. Одним из способов использования TiP является A/B тестирование, которое может быть использовано в различных сценариях. И прежде чем мы перейдем к сути, стоит прежде рассказать, а что же это такое и для чего оно нужно.

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



Что такое тестирование? Упрощенно, это процесс проверки того, что программа соответствует всем поставленным требованиям. Еще более упрощенно ‒ тестирование есть поиск ошибок. При этом обычно программа рассматривается как “черный ящик”, и проверка производится многократным запуском с разными исходными данными и в разных условиях.
Мы убеждены, что полноценное тестирование программного продукта в компании может выполнять только обособленное подразделение ‒ собственно, отдел тестирования. Перекладывание функций тестировщиков на разработчиков, бизнес-аналитиков или даже менеджеров ‒ путь неэффективный. В этой статье мы расскажем, как можно построить отдел тестирования.

Уважаемый пользователь системы WebVisor!

Извещаем вас, что с 10 июня сервис WebVisor.ru прекращает свою работу в связи с переходом технологии WebVisor в компанию Яндекс. Вся функциональность, которая была доступна в сервисе WebVisor.ru, будет доступна в сервисе Яндекс.Метрика.

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

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

Мысли о таком закрытии сервиса и вопросы разработчикам этой технологии в Яндекс:

Есть очень простой способ улучшить отдачу от рекламы. Перед запуском нужно провести её тестирование. Как это сделать без затрат и головной боли? Сейчас расскажу.