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

29 сентября «Универсариум» запустил курс «Основы тестирования ПО». Надо отдать должное Алексею Петрову – автору курса, директору по качеству Почта@Mail.ru. Он в течение 17 лекций планомерно приводит слушателя к мысли о том, что тестирование – это не просто (а, если честно, то вообще не) сверка реализованного кода со спецификацией. Это процесс, сопровождающий продукт от самой идеи его создания почти до полного исчезновения и прекращения использования. Скажем больше – это целая философия, конечной целью которой является создание Продукта Вашей Мечты.



Сегодня мы раскроем основные пункты тестирования, без которых невозможно создание качественного продукта:

Для большинства людей общий аудит сайта – задача достаточно сложная и трудоемкая, однако с такими инструментами, как Screaming Frog SEO Spider (СЕО Паук) задача может стать значительно более простой как для профессионалов, так и для новичков. Удобный интерфейс Screaming Frog обеспечивает легкую и быструю работу, однако многообразие вариантов конфигурации и функциональности может затруднить знакомство с программой, первые шаги в общении с ней.

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

Одним из преимуществ веб-сервисов является относительная простота тестирования. Действительно, в простейшем случае все, что нам нужно для проверки работы веб-сервиса – это отправить правильно сформированный HTTP-запрос любым удобным способом и проверить, что вернулось в ответ. С помощью SoapUI – инструмента для всевозможных видов тестирования веб-сервисов (более подробно о возможностях можно почитать на официальном сайте) – этот процесс можно сделать еще удобнее, автоматизировав его: мы можем создать набор тестов, указав в нем, какие запросы следует отправлять, и задав набор правил, которым должны удовлетворять ответы от сервиса. Но, тем не менее, эти тесты мы по прежнему должны будем запускать руками, а душа жаждет полной автоматизации. Действительно, почему бы не запускать эти тесты автоматически при сборке приложения (на CI-сервере или прямо на машине разработчика)?

Java native library (JNL) представляет собой JAR-архив, содержащий в себе JNI-код и объекты, которые операционная система может загрузить в качестве разделяемых библиотек. Это позволяет вызывать из Java-приложения функции, реализованные платформо-зависимыми методами. Способы создания JNL — это тема отдельной большой статьи, поэтому считаем, что у вас уже есть JNL и вы хотите ею воспользоваться в своем приложении. Об особенностях использования JNL в приложениях, работающих под управлением сервера приложений, и будет эта статья.

Рутинные задачи в разработке ПО автоматизируются посредством приложений Continuous Delivery и DevOps. Разработчики берут на себя все больше и больше ответственности. Мне стало интересно какова будет роль традиционного тестирования и тестировщиков если посмотреть немного вперед.

Среди разработчиков нередка ситуация, когда основной рабочий компьютер это mac или linux, но время от времени нужен доступ к windows: запустить специфичную программу, проверить верстку в internet explorer, поставить триальную версию corel draw для конвертации в .svg.

“Классический” способ решения этой задачи — установить одну из популярных виртуальных машин, скачать 90-дневную триал версию windows и установить ее в виртуальноый машине. Но у этого способа есть один большой минус — о необходимости деражать под рукой такую виртуальную машину разработчик обычно вспоминает в тот момент когда “о, тут нужна винда!”. А ставится windows не то чтобы очень быстро. И 90-дневный триал, что характерно, имеет обыкновение заканчиваться в самый неподходящий момент. Даже с rearm. Недавно Microsoft пошла на встречу разработчикам и сделала интересный сервис, позволяющий очень быстро и бесплатно получить доступ к нужной версии windows.

Друзья, сегодня выпала возможность отвечать на вопросы на долгоиграющую тему «Как стать Тестировщиком, каковы перспективы, и что необходимо, чтобы попасть в эту сферу.»

Как водится в начале любых мнениеизложений или презентаций, дам краткую (очень краткую) информацию о себе:
Работаю в QA два с половиной года. За это время сменил три компании, поработал на разных проектах. Много общался с основателями компаний и организаторами тренингов/конференций/семинаров. Проводил собеседования и следил за развитием рынка.

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



Разделю пост следующие части:
1. Наблюдения

• Почему отрасль Тестирования низкоквалифицирована?
• Личный опыт
• «Принцип Свитчера» и его влияние на QA

2. Возможные решения

Эта статья является продолжением SpiderTest: Автотесты своими руками. Однако, первая часть обзора на это приложение была больше ориентирована на десктопный интерфейс. В этой же хотелось бы поговорить об экзотике: связи тестов с CI-server’ом и GitHub.
Может возникнуть вопрос: «Зачем вообще все это нужно? Мы написали тест, прогнали его в нужных браузерах и нам достаточно» и в целом он довольно обоснованный! Действительно, для обычного тестирования, запуска автотестов из самого приложения SpiderTest в большинстве случаев бывает достаточно. Но что делать, если мы хотим запустить тесты в IE9-11, Opera, FireFox и Google Chrome разных версий? На одной машине это сделать невозможно, а создавать кучу виртуальных машин и запускать по очереди в каждой утомительно (и вообще это костыль).
А если мы хотим провести дымовое тестирование? Или хотим запускать тесты не только в разных браузерах, но и в разных операционных системах (Windows OS, Linux OS)?
Самый оптимальный ответ на поставленные выше вопросы – использовать сервер непрерывной интеграции. В этой статье я рассмотрю настройку SpiderTest и Jenkins. Справедливости ради стоит сказать, что запускать тесты можно и на bamboo, и на teamcity, но Jenkins прост и бесплатен, поэтому рассмотрим его.

Немало копий поломано в вопросе о том, как следует проверять адрес электронной почты (например, habrahabr.ru/post/175329), но позвольте предоставить вам немного статистики с реального проекта.

Довольно часто среди начинающих (и даже не очень) тестировщиков приходится слышать: «вот если бы я умел писать автотесты, я бы…». Как правило этим «если бы» ребята и ограничиваются. На вопрос: «А почему не учишься писать?» чаще всего отвечают: «Программирование это не мое». Действительно, тем для кого программирование темный лес, погрузиться в мир автотестов довольно затруднительно, ведь скрипт сам себя не напишет. В этой статье я хотел бы поговорить о том, как из ручного тестировщика стать крутым автотестером.

Сервис мониторинга работы сайтов Host-tracker обзавелся новой опцией – проверкой на попадание в Единый реестр запрещенных сайтов.

HTML код до и после работы Билайна. Найдите отличия!

Недавно я написал две статьи про оператора связи Билайн:
Билайн автоматически добавляет тулбар с поиском Mail.Ru
Билайн автоматически добавляет тулбар и изменяет дизайн сайтов

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

Теперь оператор связи меняет атрибут src у тега iframe и фреймы перестают работать!

Любой маломальски опытный QA-инженер (или в простонародье тестировщик) сможет сходу назвать пяток различных видов тестов: удобство пользователя, дымовое, нагрузочное, регрессионное, конфигурационное, тестирование взаимодействия и т.д. Какие-то виды тестирования используются редко, например нагрузочное, почаще применяется тестирование удобства пользователя, о таких экзотических видах, как конфигурационное тестирование или тестирование взаимодействия, многие вообще слышали только в книгах Канера и Фолка «Тестирование программного обеспечения» и никогда не использовали в работе. Но есть вид тестирования, про который можно сказать совершенно четко: его делал каждый. Я говорю о регрессионном функциональном тестировании. Этот вид теста, пожалуй, является одним из наиболее важных, нудных и трудоемких.

Всем привет!
Сегодня я хочу поделится нашим опытом автоматизации тестирования веб-приложения с использованием Selenium WebDriver и фреймворка Behave.
Если интересно добро пожаловать под кат.

Пару месяцев назад в протоколе TLS обнаружили уязвимость, которая получила название Logjam. Проведенные исследования показали, что большое число серверов подвержено этой уязвимости, так как, применяя защищенные соединения, используют типичные и наиболее распространенные простые ключи шифрования размером 512 бит. Ранее, такой длины вполне могло хватить для защиты соединения клиента с сервером. На сегодняшний же день, проведены исследования по вычислению наиболее распространенные ключей. Host-tracker предлагает функционал, который позволяет моментально проверить данную уязвимость.

Часть 1

Процесс оптимизации

Установить в организации хорошо прописанный и формальный процесс оптимизации – это очень полезная практика, поскольку она:

1. организует рабочий процесс и задаёт реальные сроки окончания
2. устанавливает стандарты контроля качества и уменьшает количество ошибок
3. добавляет веса всей операции – логику процесса можно объяснить владельцам компании

На общем уровне планирования я бы рекомендовал устраивать совещания по планированию оптимизации 1-2 раза в неделю, на которых необходимо:

1. Просмотреть текущие тесты, чтобы понять, нужно ли их остановить или признать «завершёнными» (см. ниже). Для законченных тестов есть две возможности:
   
   1. есть явный победитель. В этом случае необходимо разработать его вывод в продакшн
   2. нет явного победителя в текущей контрольной группе. В этом случае нужно определить, требуется ли дополнительное изучение вопроса, или же нужно просто прекращать эксперимент.
   
   
2. Рассмотреть источники данных и подумать над новыми идеями для тестов
3. Обсудить и назначить приоритет любым новым идеям.

Как же понять, когда тест завершён?

Критерии завершённости – вещь сложная и даже являются коммерческими секретами. Определю минимальные необходимые условия для объявления теста «завершённым». Общепринятых стандартов не существует, и критерии зависят в основном от представлений вашей команды. Мы для себя выработали следующие критерии:

«Горячая» и часто обсуждаемая сегодня тема оптимизации конверсии привела к безусловной популяризации А/Б-тестирования, как единственного объективного способа узнать правду о работоспособности тех или иных технологий/решений, связанных с увеличением экономической эффективности для онлайн-бизнеса.

За этой популярностью скрывается практически полное отсутствие культуры в организации, проведении и анализе результатов экспериментов. В Retail Rocket мы накопили большую экспертизу в оценке экономической эффективности от систем персонализации в электронной коммерции. За два года был отстроен идеальный процесс проведения A/Б-тестов, которым мы и хотим поделиться в рамках этой статьи.

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

Привет Хабр! Сегодня предлагаем вашему вниманию третью часть цикла статей, посвящённого HP StormRunner Load. Предыдущие части: I и II.



В этой части поговорим про анализ результатов.

Оптимизация веб-сайтов, известная под именем А/Б тестирование набрала популярность в качестве рабочей техники для многих команд, создающих сайты. Но до сих пор по ней слишком мало всеобъемлющих книг, статей или обучающих материалов, направленных на одиночных разработчиков, стремящихся ввести эту технику у себя в организации.

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

Основы: что такое оптимизация веб-сайтов?

Это метод экспериментов, проверяющих, какой дизайн лучше подходит для вашего сайта. Идея проста:

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

Показатели выбираются так, чтобы непосредственно отражать ваши бизнес-цели. Они могут включать количество товаров, купленных на сайте; количество людей, подписавшихся на рассылку; количество людей, просмотревших видео с инструкцией. Иногда показатели называют конверсией – это процент посетителей, совершивших нужное действие по отношению к общему числу посетителей.