По этой причине, в большинстве случаев юнит-тесты пишут разработчики — создатели приложения. Обычно такое тестирование делают после функционального, как менее приоритетное (но тоже важное). Оно может значительно улучшить качество приложения, объективно и субъективно, возвысить его над конкурентами, а не только «отполировать внешний вид», как было принято в предыдущие десятилетия. Нефункциональное — это не о том, работает ли софт или нет, это о том, КАК он работает и как он выглядит.
(В некоторых справочниках встречается еще третий тип — эксплуатационное тестирование (maintenance testing), выполняемое при сопровождении уже работающего продукта). Дымовое тестирование осуществляется при выпуске каждой новой сборки. Смок-тестирование проверяет смок тестирование критически важный функционал приложения; а санитарное тестирование проверяет отдельный модуль приложения. Цель такого тестирования – проверить, что после очередной сборки программного продукта нет явных, грубых дефектов, «блокирующих дальнейший путь».
Преимущества дымового тестирования
А на вопрос как проверить правильность отчетов, звучал ответ – «распечатался – значит все хорошо». Провели разведку, присмотрелись – работы непочатый край. Если система корректируется в процессе создания (что неизбежно), если в ее модули/функции вносятся изменения, то обязательно проверяют, не повлияли ли эти правки на функционирование системы. Подробный обзор бесплатных инструментов нагрузочного тестирования — здесь.
Smoke-тестирование предполагает ответы ДА/НЕТ и все тест-кейсы должны быть пройдены с положительным результатом. Smoke test должны быть быстрыми и легковесными, для того, чтобы их можно было запускать часто. В зависимости от специфика проекта, smoke test можно пройти как за несколько минут, так и за несколько часов.
Smoke-тестирование
Для этого специалисты определяют минимальный набор тест-кейсов для критически важного функционала. На этапе написания тест-кейсов выделяют приоритетность и серьёзность кейса. В Smoke-прогон входят кейсы с Priority High и Severity Critical — как правило, это основные пользовательские сценарии, набор кейсов для проверок интеграционных модулей. А дымовое тестирование проверяет общую работоспособность/стабильность (нового) билда, почему и называется еще «Верификацией билда» или «Confidence Testing». Простое смок-тестирование верифицирует основную функциональность (работает или нет в целом) и позволяет передать продукт на доработку или следующие стадии тестирования.
- Чаще всего автоматизируется тестирование производительности.
- Затем они дают фидбек, и конструктивную критику, после чего разработчики, при необходимости, вносят изменения в так называемую бета-версию продукта.
- Если смотреть интегрально, с точки зрения QA и CI-CD-пайплайна, то смок-тестирование — это о том как проверить, что остальные виды тестирования уже валидные, то есть можно идти дальше.
- В итоге команда тестирования перестала зависеть от специалистов заказчика и работоспособности инфраструктуры.
- На систему подается нагрузка в виде запросов/одновременных «пользователей», которая позволяет оценить, какое количество нагрузки система способна обработать до того как начнет ухудшать свою производительность.
Кто знаком с нашим подходом или работал с нами, тот знает – в ЛК уже как 5 лет работает отличная система наставничества и обучения. Каждый новичок имеет индивидуальный план погружения на проект с мануалами и ссылками на необходимые ресурсы. А на период отсутствия машин, обучение происходило с помощью видео, схем и таблиц, созданных более опытными первопроходцами из первого десанта. Но даже посмотреть, как все работает на стендах, у нас не было возможности, так как на проекте наблюдался недостаток машин, и не все они были в рабочем состоянии. А накат новой версии длился несколько дней и в это время все тестировщики учились гадать на кофейной гуще и плясать с бубном.
Пример smoke testing:
Таким образом, smoke-тесты — это простой и действенный способ проверить основной функционал сборки. Тем не менее они не отменяют необходимость проведения более глубоких проверок, затрагивающих функции, не столь важные для самой сборки, но имеющие большое значение для пользователя. Кроме того, тестовые сценарии нуждаются в периодическом обновлении, чтобы исключить риск пропуска новых ошибок. Простыми словами, смок-тестирование — это как бы тестирование «вширь и всего», а санити-тестирование это как бы «вглубь и одного модуля». Смок-тесты должны быстро «покрыть» критический функционал в сжатые сроки, а санити-тесты — для тщательной проверки «подозреваемой» функции.
Программный продукт должен восстанавливаться быстро и «без потерь». На систему подается нагрузка в виде запросов/одновременных «пользователей», которая позволяет оценить, какое количество нагрузки система способна обработать до того как начнет ухудшать свою производительность. Например, Windows-приложение должно быть совместимым со всеми распространенными версиями ОС Windows. Если это веб-приложение, оно должно без проблем открываться во всех распространенных браузерах. Android-приложение нужно протестировать во всех распространенных в данный момент версиях ОС Android.
Зная объем работы, мы предложили заказчику несколько вариантов комплектации команды на выбор. На просьбу предоставить информацию, а также на вопросы «какая должна быть информация и как она должна попасть в отчет», нам отвечали, что такой информации https://deveducation.com/ в природе не существует. Документирование не велось, а если и были какие-то документы, то не всегда была понятна их актуальность и часто в помощь просто призывался «всезнающий гугл». Проверка загрузки основной страницы приложения без ошибок.
Для смоук-тестов мы решили оставить старое количество кейсов, потому что стояло требование укладываться с ними в 1 день. Основной упор делался на то, что кейсы должны быть актуальны, максимально понятны и покрывать основной функционал -1 приоритета (блокеры). В данном примере кода мы используем фреймворк PyTest и библиотеку Selenium WebDriver для написания нескольких тестов, которые выполняются в браузере Google Chrome. Тесты проверяют загрузку страницы Google, наличие на странице поля для поиска и возможность поиска по запросу “pytest”. Эти тесты помогут быстро выявить базовые проблемы в работе приложения и принять меры для их исправления. Проверка работы основных функций приложения (например, добавление товара в корзину для интернет-магазина).