smoke testing что это

Смок-тестирование релиз-кандидата автотестами за 15 минут

Меня зовут Лилия, я QA Lead в одном из проектов финансовой группы БКС (сервис по подбору выгодных для клиента предложений из ряда кредитных продуктов), и сегодня я расскажу, как мы автоматизировали смок-тестирование, с какими проблемами столкнулись и какой стек технологий используем.

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

Что такое смок-тестирование

Смок-тестирование, как его еще называют «дымовое тестирование» – быстрая проверка наиболее критичной функциональности.

Стек технологий для написания автотестов

Автотесты мы пишем на вот таком стеке: Java + Selenium + Cucumber + отчеты в Allure2.

BDD Автотесты для смок-тестирования

2. Шаги steps. В нем находятся классы, в которых описаны действия с элементами на странице и проверки этих элементов.

3. Работа с локаторами на страницах (паттерн PageObject)

Настройка CI

Пока мы писали автотесты, у финансовой группы БКС появился Selenoid, и мы смогли настроить запуск тестов в pipline GitLab

Организация написания автотестов для разных стендов

У нас есть несколько стендов, на которых и происходит разработка, отладка, приемка, а еще есть очень много feature-стендов, где мы тестируем новые функции, разрабатываемые распределенными командами.

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

Источник

Дымовое и санитарное тестирование: понятия и характерные отличия

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

Дымовое тестирование (англ. smoke testing)

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

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

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

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

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

Ключевые преимущества дымовых тестов

Санитарное тестирование (англ. sanity testing)

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

Подобный тип тестирования нередко выполняется до старта полного цикла проведения регрессионных проверок, но только после окончания дымового тестирования.

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

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

Если исправленные баги и редакции кода работают неверно, тогда тестировщик не имеет права принимать сборку на тест. Отметим, что любые дефекты, найденные на такой ранней стадии, смогут сэкономить массу времени на процессе проверки недоработанной сборки.

Ключевые особенности санитарного тестирования

Преимущества санитарного тестирования

Недостатки

Сравнение дымового и санитарного тестирования

Наглядные примеры использования данных тестов

Детально рассмотрим реальные примеры проведения подобных видов проверок на основе настоящих тестовых случаев.

Пример дымового тестирования

Допустим, в проверяемом ПО есть 5 модулей, а именно:

То есть, внутри данных модулей QA проводит тестирование, проверяя основную функциональность этих модулей, а точнее:

Пример санитарного тестирования

Снова представим, что есть 5 модулей:

При тестировании был найден дефект на странице авторизации. К примеру, поле для ввода пароля воспринимает комбинацию исключительно из 6 символов, что категорически не соответствует ТЗ, где указанно, что пароль может быть от 4 символов.

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

Но важно понимать, что при таком подходе тестируется только экстремальная функциональность модулей, нет никакого углубления в проверку деталей из-за отсутствия времени. Это и есть процедура санитарного тестирования.

Данные тесты проводятся только тогда, когда сборка ПО успешно прошла дымовые проверки и валидацию для последующих испытаний.

Источник

Тестирование дыма

Что такое тестирование дыма?

SMOKE TESTING — это тип тестирования программного обеспечения, который определяет, является ли развернутая сборка стабильной или нет. Цель Smoke Проверяет это, чтобы подтвердить, может ли команда QA продолжить дальнейшее тестирование. Дымовые тесты — это минимальный набор тестов, запускаемых на каждой сборке.

Дымовое тестирование — это процесс, в котором сборка программного обеспечения развертывается в среде QA и проверяется для обеспечения стабильности приложения. Он также называется «Тестирование проверки сборки» или «Проверка достоверности».

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

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

Испытания на дым пригодны для дальнейшего формального тестирования. Основной целью тестирования дыма является выявление ранних серьезных проблем. Дымовые тесты предназначены для демонстрации стабильности системы и соответствия требованиям.

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

В этом уроке вы узнаете

Когда мы проводим тестирование на курение

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

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

Кто будет делать тестирование дыма

После выпуска сборки в среду QA, инженеры QA / ведущие специалисты по QA проводят тестирование дыма. Всякий раз, когда появляется новая сборка, команда QA определяет основные функциональные возможности приложения для тестирования дыма. Команда QA проверяет наличие showtoppers в тестируемом приложении.

Тестирование, проводимое в среде разработки кода, чтобы убедиться в корректности приложения перед выпуском сборки для QA, это называется тестированием Sanity. Обычно это узкое и глубокое тестирование. Это процесс, который проверяет соответствие разрабатываемого приложения его основным функциональным требованиям.

Проверка работоспособности определяет завершение этапа разработки и принимает решение о том, сдать или нет программный продукт для дальнейшей фазы тестирования.

Почему мы проводим тестирование на курение?

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

Пример 1: Окно регистрации: возможность перехода к следующему окну с действительным именем пользователя и паролем при нажатии кнопки «Отправить».

Пример 2. Пользователь не может выйти из веб-страницы.

Как сделать тестирование дыма?

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

Ручное тестирование дыма

В общем, тестирование дыма проводится вручную. Это подходы варьируется от одной организации к другой. Дымовое тестирование проводится для обеспечения того, чтобы навигация по критическим путям соответствовала ожидаемым и не мешала функционированию. После того, как сборка выпущена в QA, необходимо выполнить тесты с высоким приоритетом функциональности и проверить их на предмет выявления критических дефектов в системе. Если тест пройден, мы продолжаем функциональное тестирование. Если тест не пройден, сборка отклоняется и отправляется обратно в команду разработчиков для исправления. QA снова начинает тестирование дыма с новой версией сборки. Дымовое тестирование выполняется на новой сборке и будет интегрировано со старыми сборками для поддержания правильности системы. Прежде чем проводить тестирование на дым, команда QA должна проверить правильность версий сборки.

Тестирование дыма автоматизацией

Вместо того, чтобы повторять тестирование вручную всякий раз, когда развертывается новая сборка программного обеспечения, для сборки выполняются записанные тесты дымового теста. Он проверяет, все ли основные функции все еще работают должным образом. Если тест не пройден, они могут исправить сборку и немедленно повторно развернуть сборку. Благодаря этому мы можем сэкономить время и обеспечить качественную сборку в среде QA.

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

Цикл испытаний дыма

Ниже блок-схема показывает, как выполняется тестирование дыма. Как только сборка развернута в QA и пройдены тесты дыма, мы приступаем к функциональному тестированию. Если тест дыма не пройден, мы прекращаем тестирование, пока проблема в сборке не будет устранена.

Цикл испытаний дыма

Преимущества тестирования дыма

Вот несколько преимуществ, перечисленных для тестирования дыма.

Что произойдет, если мы не проведем тестирование дыма

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

Образец примера тестов дыма

Резюме:

В программной инженерии тестирование Smoke должно выполняться на каждой сборке в обязательном порядке, поскольку это помогает находить дефекты на ранних стадиях. Тестирование дыма — последний шаг перед тем, как сборка программного обеспечения войдет в системную стадию. Дымовые тесты должны выполняться на каждой сборке, включенной в тестирование. Это относится к новым разработкам и основным и второстепенным версиям системы.

Перед проведением дымового тестирования команда QA должна убедиться в правильности сборки версии тестируемого приложения. Это простой процесс, который требует минимального времени для проверки стабильности приложения.

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

Эта статья предоставлена ​​Павани Ичапурапу

Источник

Покрываем проект smoke-тестами, пока он не сгорел

Привет, Хабр! Как-то раз на нашем внутреннем семинаре мой руководитель – глава отдела тестирования – начал свою речь со слов «тестирование не нужно». В зале все притихли, некоторые даже пытались упасть со стульев. Он продолжил свою мысль: без тестирования вполне возможно создать сложный и дорогостоящий проект. И, скорее всего, он будет работать. Но представьте, насколько увереннее вы будете себя ощущать, зная, что продукт работает как надо.

В Badoo релизы происходят довольно часто. Например, серверная часть наравне с desktop web релизится дважды в день. Так что мы не понаслышке знаем, что сложное и медленное тестирование – камень преткновения разработки. Быстрое же тестирование – это счастье. Итак, сегодня я расскажу о том, как в компании Badoo устроено smoke-тестирование.

Что такое smoke-тестирование

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

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

Давайте рассмотрим простой пример. Предпродакшн нашего приложения находится по адресу bryak.com (любые совпадения с реальными сайтами случайны). Мы подготовили и залили туда новый релиз для тестирования. Что стоит проверить в первую очередь? Я бы начал с проверки того, что приложение всё ещё открывается. Если web-сервер нам отвечает «200», значит, всё хорошо и можно приступать к проверке функционала.

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

Наш первый smoke-тест

В Badoo серверная часть написана по большей части на PHP. Unit-тесты по понятным причинам пишутся на нём же. Итого у нас уже есть PHPUnit. Чтобы не плодить технологии без необходимости, мы решили писать smoke-тесты тоже на PHP. Помимо PHPUnit, нам потребуется клиентская библиотека работы с URL (libcurl) и PHP extension для работы с ней – cURL.

По сути, тесты просто делают нужные нам запросы на сервер и проверяют ответы. Всё завязано на методе getCurlResponse() и нескольких типах ассертов.

Сам метод выглядит примерно так:

Сам метод умеет по заданному URL возвращать ответ сервера. На вход принимает параметры, такие как cookies, headers, user agent и прочие данные, необходимые для формирования запроса. Когда ответ от сервера получен, метод проверяет, что код ответа совпадает с ожидаемым. Если это не так, тест падает с ошибкой, сообщающей об этом. Это сделано для того, чтобы было проще определить причину падения. Если тест упадёт на каком-нибудь ассерте, сообщив нам, что на странице нет какого-то элемента, ошибка будет менее информативной, чем сообщение о том, что код ответа, например, «404» вместо ожидаемого «200».

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

Самый простой тест выглядит примерно так:

Такой тест проходит менее чем за секунду. За это время мы проверили, что стартовая страница отвечает «200», и на ней есть элемент body. С тем же успехом мы можем проверить любое количество элементов на странице, продолжительность теста существенно не изменится.

Плюсы таких тестов:

Авторизация

Представим, что с момента, как мы написали наш первый smoke-тест, прошло три дня. Само собой, за это время мы покрыли все неавторизованные страницы, какие только нашли, тестами. Немного посидели, порадовались, но потом осознали, что всё самое важное в нашем проекте находится за авторизацией. Как бы получить возможность это тоже тестировать?

Чем отличается авторизованная страница от неавторизованной? С точки зрения сервера всё просто: если в запросе есть информация, по которой пользователя можно идентифицировать, нам вернётся авторизованная страница.

Самый просто вариант – авторизационная cookie. Если добавить её к запросу, то сервер нас «узнает». Такую cookie можно захардкодить в тесте, если её время жизни довольно большое, а можно получать автоматически, отправляя запросы на страницу авторизации. Давайте подробнее рассмотрим второй вариант.

На нашем сайте страница авторизации выглядит так:

Нас интересует форма, куда надо ввести логин и пароль пользователя.

Открываем эту страницу в любом браузере и открываем инспектор. Вводим данные пользователя и сабмитим форму.

В инспекторе появился запрос, который нам надо имитировать в тесте. Можно посмотреть, какие данные, помимо очевидных (логин и пароль), отсылаются на сервер. Для каждого проекта по-разному: это может быть remote token, данные каких-либо cookies, полученных ранее, user agent и так далее. Каждый из этих параметров придётся предварительно получить в тесте, прежде чем сформировать запрос на авторизацию.

В инструментах разработчика любого браузера можно скопировать запрос, выбрав пункт copy as cURL. В таком виде команду можно вставить в консоль и рассматривать там. Там же её можно опробовать, поменяв или добавив параметры.

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

Поскольку авторизация – довольно долгий процесс, авторизационную cookie я предлагаю получать только один раз для каждого пользователя и сохранять где-то. У нас, например, такие cookies хранятся в массиве. Ключом является логин пользователя, а значением – информация о них. Если для следующего пользователя ключа ещё нет, авторизуемся. Если есть – делаем интересующий нас запрос сразу.

Пример кода теста, проверяющего авторизованную страницу, выглядит примерно так:

Как мы видим, добавился метод, который получает авторизационную cookie и просто добавляет её в дальнейший запрос. Сам метод реализуется довольно просто:

Метод сначала проверяет, есть ли для данного e-mail (в вашем случаем это может быть логин или что-то ещё) уже полученная ранее авторизационная cookie. Если есть, он её возвращает. Если нет, он делает запрос на авторизационную страницу (например, bryak.com/auth_page_adds) с необходимыми параметрами: e-mail и пароль пользователя. В ответ на этот запрос сервер присылает заголовки, среди которых есть интересующие нас cookies. Выглядит это примерно так:

Из этих заголовков нам при помощи несложного регулярного выражения надо получить название cookie и её значение (в нашем примере это name=value). У нас метод, который парсит ответ, выглядит так:

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

Разбор падающих тестов

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

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

Ещё полезно собирать артефакты. Когда наш тест падает, он сохраняет последний ответ сервера в HTML-файлик и закидывает в хранилище артефактов, где этот файлик можно открыть из браузера, указав название теста.

Например, тест у нас упал на том, что не может найти на странице кусочек HTML:

Мы заходим на наш коллектор и открываем соответствующую страницу:

С этой страницей можно работать так же, как с любой другой HTML-страничкой в браузере. Можно при помощи CSS-локатора попытаться разыскать пропавший элемент и, если его действительно нет, решить, что либо он изменился, либо потерялся. Возможно, мы нашли баг! Если элемент на месте, возможно, мы где-то ошиблись в тесте – надо внимательно посмотреть в эту сторону.

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

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

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

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

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

Итоги

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

За это время мы убеждаемся, что:

Конечно, это не замена Selenium. Нам всё равно придётся проверять корректное поведение клиента и кросс-браузерные кейсы. Мы можем заменить лишь те тесты, которые проверяют поведение сервера. Но, помимо этого, мы можем осуществлять предварительное тестирование, быстрое и простое. Если на этапе smoke-тестирования нашлись ошибки и «дым идёт не оттуда», возможно, запускать долгий набор тяжеловесных Selenium-тестов до фиксов смысла нет? Это уже на ваше усмотрение! 🙂

Спасибо за внимание.

Виталий Котов, QA-инженер по автоматизации.

Источник