Что называется тестированием программы

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

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

Регрессионное тестирование (Regression testing) | Курс тестирование ПО с нуля — Урок 19 | QA Labs

Типы тестирования программного обеспечения: функциональное и нефункциональное тестирование

Функциональное тестирование

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

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

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

Интеграционное тестирование

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

Нефункциональное тестирование

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

Функциональное тестирование. Виды тестирования | Курс тестирование ПО с нуля — Урок 10 | QA Labs

Тестирование производительности

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

Как эти типы тестов отличаются друг от друга

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

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

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

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

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

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

Преимущества этих типов тестов

Тестирование производительности

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

Функциональное тестирование

• Убедитесь, что веб-сайт/приложение не имеет дефектов.
• Обеспечивает ожидаемое поведение всех функциональных возможностей.
• Гарантирует правильность архитектуры при необходимой безопасности.
• Улучшает общее качество и функциональность.
• Минимизирует бизнес-риски, связанные с веб-сайтом/приложением.

Интеграционное тестирование

• Гарантирует, что все модули приложений хорошо интегрированы и работают, как ожидалось вместе.
• Обнаруживает взаимосвязанные проблемы и конфликты, чтобы решить их на ранней стадии, прежде чем они создадут большую проблему.
• Проверяет функциональность, надежность и стабильность между различными модулями.
• Обнаруживает упущенные исключения для улучшения качества кода.
• Поддерживает конвейер CI/CD.

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

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

Недостатки этих типов тестирования

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

Правильное время для выполнения этих типов тестов

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

Совет: руконый подход

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

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

Что такое LoadView?

LoadView — это облачный инструмент тестирования нагрузки, который проверяет производительность веб-сайта в условиях высокого трафика. Он имитирует тысячи виртуальных пользователей из разных географических мест на нескольких браузерах и устройствах для создания наиболее реалистичных сред для тестирования производительности. Он также предлагает функцию создания тестового сценария с помощью EveryStep Web Recorder, которая не требует каких-либо навыков кодирования, чтобы любой человек в вашей команде мог создавать сценарии и выполнять тестирование нагрузки. Вы можете протестировать свой веб-сайт, приложение, веб-страницы и API сторонних разработчиков с помощью LoadView для обнаружения узких мест в производительности и быстрого их устранения. LoadView быстро приутовиться, и его отчеты о производительности легко понять с действиями идеи.

Вывод: Типы тестирования программного обеспечения

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

Сделайте вашу нагрузку и стресс-тестирование правильный путь с LoadView. Зарегистрируйтесь и начать работу сегодня. Мы предоставим вам до 5 бесплатных нагрузочных тестов для начала.

Источник: www.loadview-testing.com

BYTEX BLOG

Андерклокинг — снижение частоты работы оборудования.

Баг (дефект) — недостаток компонента или системы, который может привести к отказу определенной функциональности.

Приоритет багов — важность той или иной ошибки в ПО:

• Trivial — косметическая малозаметная проблема.
• Minor — очевидная, незначительная проблема.
• Major — значительная проблема.
• Critical — проблема, нарушающая работу c ключевыми функциями ПО.
• Blocker — проблема, нарушающая функционирование ПО.

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

Валидация — определение соответствия разрабатываемого ПО ожиданиям и потребностям пользователя, требованиям к системе.

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

Спецификация — детальное описание того, как должно работать ПО.

Система отслеживания ошибок (англ. bug tracking system) — программа учета и/или контроля багов:

• Atlassian JIRA
• Bugzilla
• YouTrack
• Redmine
• etc.

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

Обеспечение качества (Quality Assurance, QA) — совокупность мероприятий, охватывающих все технологические этапы разработки, выпуска и эксплуатации программного обеспечения

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

Ошибка (англ.Error) – действие, которое порождает неправильный результат.

Сбой (англ.Failure) – несоответствие фактического результата работы компонента или системы ожидаемому результату.

Классификация по типу тестирования:
Мобильное тестирование — тестирование мобильных приложений.
Консольное тестирование — тестирование приложений предназначенных для консолей.
Web-тестирование (Браузерное тестирование) — тестирование браузерных приложений.

Классификация по запуску кода на исполнение:
Статическое тестирование (англ.Static testing) — тестирование без запуска кода на исполнение.
Динамическое тестирование (англ. Dynamic testing) — тестирование с запуском кода на исполнение.

Классификация по доступу к коду и архитектуре ПО:
Черный ящик (англ. Black box) — тестировщику не известно как устроена тестируемая система.
Белый ящик (англ. White box) — тестировщику известно все детали реализации тестируемой системы.
Серый ящик (англ. Grey box) — тестировщику известно только некоторые особенности устройства тестируемой системы.

Классификация по степени автоматизации:
Ручное тестирование (англ. Manual testing) — тестирование ПО будучи его пользователем.
Автоматизированное тестирование (англ. Automated testing) — тестирование ПО при помощи специальных программ.

Классификация по принципу работы с приложением:
Позитивное тестирование (англ. Positive testing) — тестирование ПО на то, как оно должно работать.
Негативное тестирование (англ. Negative testing) — тестирование ПО на то, как оно не должно работать.

Классификация по уровню детализации приложения:
Интеграционное тестирование — тестирование взаимодействия и связей нескольких компонентов приложения.
Системное тестирование — это тестирование всего приложения от начала и до конца.
Модульное тестирование — тестирование на уровне отдельного функционального компонента приложения.

Классификация по целям и задачам:
Функциональное тестирование — проверка корректности работы функциональности приложения.
Нефункциональное тестирование — проверка нефункциональных особенностей приложения (удобство использования, совместимость, производительность, безопасность).
Инсталляционное тестирование — проверка протекания стадии инсталляции (установки) приложения.
Регрессионное тестирование — проверка на наличие багов, вызванных изменениями в приложении.
Повторное тестирование — выполнение тест-кейсов, которые ранее обнаружили дефекты, с целью подтверждения устранения дефектов.
Приёмочное тестирование — тестирование, направленное на проверку приложения с точки зрения конечного пользователя/заказчика
Тестирование удобства использования — тестирование, направленное на исследование того, насколько конечному пользователю понятно, как работать с продуктом, а также на то, насколько ему нравится использовать продукт.
Тестирование доступности — тестирование, направленное на исследование пригодности продукта к использованию людьми с ограниченными возможностями
Тестирование интерфейса — тестирование, направленное на проверку интерфейсов приложения или его компонентов.
Тестирование безопасности — тестирование, направленное на проверку способности приложения противостоять злонамеренным попыткам получения доступа к данным или функциям
Тестирование интернационализации — тестирование, направленное на проверку готовности продукта к работе с использованием различных языков и с учётом различных национальных и культурных особенностей.
Тестирование локализации — тестирование, направленное на проверку корректности и качества адаптации продукта к использованию на том или ином языке с учётом национальных и культурных особенностей.
Тестирование совместимости — тестирование, направленное на проверку способности приложения работать в указанном окружении (браузер, мобильное ус-во и т.д.).
Тестирование данных и баз данных — тестирование, направленное на исследование таких характеристик данных, как полнота, непротиворечивость, целостность, структурированность и т.д.
Тестирование использования ресурсов — совокупность видов тестирования, проверяющих эффективность использования приложением доступных ему ресурсов и зависимость результатов работы приложения от количества доступных ему ресурсов.
Сравнительное тестирование — тестирование, направленное на сравнительный анализ преимуществ и недостатков разрабатываемого продукта по отношению к его основным конкурентам.
Демонстрационное тестирование — формальный процесс демонстрации заказчику продукта с целью подтверждения, что продукт соответствует всем заявленным требованиям.
Избыточное тестирование — тестирование приложения со всеми возможными комбинациями всех возможных входных данных во всех возможных условиях выполнения.
Тестирование надёжности — тестирование способности приложения выполнять свои функции в заданных условиях.
Тестирование восстанавливаемости — тестирование способности приложения восстанавливать свои функции и заданный уровень производительности, а также восстанавливать данные в случае возникновения критической ситуации.
Тестирование отказоустойчивости — тестирование, заключающееся в эмуляции или реальном создании критических ситуаций с целью проверки способности приложения задействовать механизмы, предотвращающие нарушение работоспособности, производительности и повреждения данных.
Тестирование производительности — исследование показателей скорости реакции приложения на внешние воздействия при различной по характеру и интенсивности нагрузке.
Нагрузочное тестирование — исследование способности приложения сохранять заданные показатели качества при нагрузке в допустимых пределах и некотором превышении этих пределов/
Тестирование масштабируемости — исследование способности приложения увеличивать показатели производительности в соответствии с увеличением количества доступных приложению ресурсов.
Объёмное тестирование — исследование производительности приложения при обработке различных (как правило, больших) объёмов данных.
Стрессовое тестирование — исследование поведения приложения при нештатных изменениях нагрузки, значительно превышающих расчётный уровень.
Конкурентное тестирование — исследование поведения приложения в ситуации, когда ему приходится обрабатывать большое количество одновременно поступающих запросов, что вызывает конкуренцию между запросами за ресурсы (базу данных, память, канал передачи данных, дисковую подсистему и т.д.)
Фокус-тест (англ. Focus test) — тестирование, проводимое с целью получения первичной реакции игроков. Необходимо для оценки удобства использования и того, как продукт принимается целевой аудиторией или сторонними людьми.

Failure — сбой (причём не обязательно аппаратный) в работе компонента, всей программы или системы.

UX (англ. User eXperience — опыт пользователя) — ощущение, испытываемое пользователем во время использования цифрового продукта.

UI (англ. User Interface — пользовательский интерфейс) — это инструмент, позволяющий осуществлять взаимодействие «пользователь — приложение».

Анализ граничных значений (англ. Boundary Value Analysis — BVA). Анализ граничных значений может быть применен к полям, записям, файлам, или к любого рода сущностям имеющим ограничения.

Дымовое тестирование (англ. Smoke test) — короткий цикл тестов для подтверждения, что после сборки кода (нового или исправленного) приложение стартует и выполняет основные функции.

Исследовательское (ad-hoc) тестирование — это разработка и выполнения тестов в одно и то же время, что является противоположностью сценарного подхода.

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

Матрица соответствия требований (англ. Traceability matrix) — это двумерная таблица, содержащая соответсвие функциональных требований (functional requirements) продукта и подготовленных тестовых сценариев (test cases).

Операционное тестирование (англ. Release Testing). Даже если система удовлетворяет всем требованиям, важно убедиться в том, что она удовлетворяет нуждам пользователя и выполняет свою роль в среде своей эксплуатации, как это было определено в бизнес модели системы.

Предугадывание ошибки (англ. Error Guessing — EG). Это когда тест аналитик использует свои знания системы и способность к интерпретации спецификации на предмет того, чтобы «предугадать» при каких входных условиях система может выдать ошибку.

Причина / Следствие (англ. Cause/Effect — CE). Это, как правило, ввод комбинаций условий (причин), для получения ответа от системы (Следствие).

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

Серьезность (англ. Severity) — это атрибут, характеризующий влияние дефекта на работоспособность приложения.

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

Пре-альфа (англ. Pre-alpha) — начальная стадия разработки. Период времени со старта разработки до выхода стадии Альфа. Также так называются программы, прошедшие стадию разработки, для первичной оценки функциональных возможностей в действии.

Альфа-тестирование (англ. Alpha testing) — имитация реальной работы с системой штатными разработчиками, либо реальная работа с системой потенциальными пользователями/заказчиком на ранней стадии разработки продукта, но в некоторых случаях может применяться для законченного продукта в качестве внутреннего приёмочного тестирования.

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

Релиз-кандидат или RC (англ. Release candidate), Пре-релиз, иногда «гамма-версия» — стадия-кандидат на то, чтобы стать стабильной.

Релиз или RTM (англ. Release to manufacturing — промышленное издание) — издание продукта, готового к тиражированию.

Пост-релиз или Post-RTM (англ. Post-release to manufacturing) — издание продукта, у которого есть несколько отличий от RTM и помечается как самая первая стадия разработки следующего продукта.

Таблица принятия решений (англ. Decision table) — инструмент для упорядочения сложных бизнес требований, которые должны быть реализованы в продукте.

Тест-дизайн (англ. Test design) — это этап процесса тестирования ПО, на котором проектируются и создаются тестовые случаи (тест кейсы).

Тест-план (англ. Test Plan) — это документ, описывающий весь объем работ по тестированию, а также оценки рисков с вариантами их разрешения.

Тестирование взаимодействия (англ. Interoperability Testing) — это функциональное тестирование, проверяющее способность приложения взаимодействовать с одним и более компонентами или системами.

Тестирование сборки (англ. Build Verification Test) — тестирование направленное на определение соответствия, выпущенной версии, критериям качества для начала тестирования.

Тестирование пользовательского интерфейса (англ. UI Testing) — тестирование, выполняемое с целью определения, удобен ли некоторый искусственный объект (такой как веб-страница, пользовательский интерфейс или устройство) для его предполагаемого применения.

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

Чек-лист (англ. Check list) — это документ, описывающий что должно быть протестировано.

Эквивалентное Разделение (англ. Equivalence Partitioning — EP). Как пример, у вас есть диапазон допустимых значений от 1 до 10, вы должны выбрать одно верное значение внутри интервала, скажем, 5, и одно неверное значение вне интервала — 0.

Z-конфликт (англ. Z-fighting) — наложение текстур друг на друга.

Оверклокинг (англ. Overclocking) — процесс увеличения частоты (и напряжения) компонента компьютера сверх штатных режимов с целью увеличения скорости его работы.

Источник: bytextest.ru

Java Unit Testing: методики, понятия, практика

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

1. Модульное тестирование (unit testing) — тесты, задача которых проверить каждый модуль системы по отдельности. Желательно, чтобы это были минимально делимые кусочки системы, например, модули.
2. Системное тестирование (system testing) — тест высокого уровня для проверки работы большего куска приложения или системы в целом.
3. Регрессионное тестирование (regression testing) — тестирование, которое используется для проверки того, не влияют ли новые фичи или исправленные баги на существующий функционал приложения и не появляются ли старые баги.
4. Функциональное тестирование (functional testing) — проверка соответствия части приложения требованиям, заявленным в спецификациях, юзерсторях и т. д. Виды функционального тестирования:
5. тест «белого ящика» (white box) на соответствие части приложения требованиям со знанием внутренней реализации системы;
6. тест «черного ящика» (black box) на соответствие части приложения требованиям без знания внутренней реализации системы.
7. Тестирование производительности (performance testing) — вид тестов, которые пишутся для определения скорости отработки системы или ее части под определённой нагрузкой.
8. Нагрузочное тестирование (load testing) — тесты, предназначенные для проверки устойчивости системы при стандартных нагрузках и для нахождения максимально возможного пика, при котором приложение работает корректно.
9. Стресс-тестирование (stress testing) — вид тестирования, предназначенный для проверки работоспособности приложения при нестандартных нагрузках и для определения максимально возможного пика, при котором система не упадёт.
10. Тестирование безопасности (security testing) — тесты, используемые для проверки безопасности системы (от атак хакеров, вирусов, несанкционированного доступа к конфиденциальным данным и прочих радостей жизни).
11. Тестирование локализации (localization testing) — это тесты локализации для приложения.
12. Юзабилити тестирование (usability testing) — вид тестирования, направленный на проверку удобства использования, понятности, привлекательности и обучаемости для пользователей. Это всё звучит хорошо, но как оно происходит на практике? Все просто: используется пирамида тестирования Майка Кона: Это упрощенный вариант пирамиды: сейчас её делят на более мелкие детали. Но сегодня мы не будем извращаться и рассмотрим самый простой вариант.

1. Unit — модульные тесты, применяемые в различных слоях приложения, тестирующие наименьшую делимую логику приложения: например, класс, но чаще всего — метод. Эти тесты обычно стараются по максимуму изолировать от внешней логики, то есть создать иллюзию того, что остальная часть приложения работает в стандартном режиме. Данных тестов всегда должно быть много (больше, чем остальных видов), так как они тестируют маленькие кусочки и весьма легковесные, не кушающие много ресурсов (под ресурсами я имею виду оперативную память и время).
2. Integration — интеграционное тестирование. Оно проверяет более крупные кусочки системы, то есть это либо объединение нескольких кусочков логики (несколько методов или классов), либо корректность работы с внешним компонентом. Этих тестов как правило меньше, чем Unit, так как они тяжеловеснее. Как пример интеграционных тестов можно рассмотреть соединение с базой данных и проверку правильной отработки методов, работающих с ней.
3. UI — тесты, которые проверяют работу пользовательского интерфейса. Они затрагивают логику на всех уровнях приложения, из-за чего их еще называют сквозными. Их как правило в разы меньше, так они наиболее тяжеловесны и должны проверять самые необходимые (используемые) пути. На рисунке выше мы видим соотношение площадей разных частей треугольника: примерно такая же пропорция сохраняется в количестве этих тестов в реальной работе. Сегодня подробно рассмотрим самые используемые тесты — юнит-тесты, так как уметь ими пользоваться на базовом уровне должны все уважающие себя Java-разработчики.

Ключевые понятия юнит-тестирования

Покрытие тестов (Code Coverage) — одна из главных оценок качества тестирования приложения. Это процент кода, который был покрыт тестами (0-100%). На практике многие гонятся за этим процентом, с чем я не согласен, так как начинается навешивание тестов там, где они не нужны. Например, у нас в сервисе есть стандартные CRUD (create/get/update/delete) операции без дополнительной логики. Эти методы — сугубо посредники, делегирующие работу слою, работающему с репозиторием. В данной ситуации нам нечего тестировать: разве то, что вызывает ли данный метод — метод из дао, но это не серьёзно. Для оценки покрытия тестами обычно используют дополнительные инструменты: JaCoCo, Cobertura, Clover, Emma и т.д. Для более детального изучения данного вопроса держи пару годных статей:

• материал о Code Coverage на JavaRush и на Хабре;
• фундаментальная теория тестирования.

TDD (Test-driven development) — разработка через тестирование. В рамках этого подхода в первую очередь пишется тест, который будет проверять определенный код. Получается тестирование чёрного ящика: мы знаем, что есть на входе и знаем, что должно получиться на выходе. Это позволяет избежать дублирования кода. Разработка через тестирование начинается с проектирования и разработки тестов для каждой небольшой функциональности приложения. В подходе TDD, во-первых, разрабатывается тест, который определяет и проверяет, что будет делать код. Основная цель TDD — сделать код более понятным, простым и без ошибок. Подход состоит из таких составляющих:

1. Пишем наш тест.
2. Запускаем тест, прошел он или нет (видим, что всё красное — не психуем: так и должно быть).
3. Добавляем код, который должен удовлетворить данный тест (запускаем тест).
4. Выполняем рефакторинг кода.

Исходя из того, что модульные тесты являются наименьшими элементами в пирамиде автоматизации тестирования, TDD основан на них. С помощью модульных тестов мы можем проверить бизнес-логику любого класса. BDD (Behavior-driven development) — разработка через поведение. Это подход основан на TDD. Если говорить точнее, он использует написанные понятным языком примеры (как правило на английском), которые иллюстрируют поведение системы для всех, кто участвует в разработке. Не будем углубляться в данный термин, так как он в основном затрагивает тестировщиков и бизнес-аналитиков. Тестовый сценарий (Test Case) — сценарий, описывающий шаги, конкретные условия и параметры, необходимые для проверки реализации тестируемого кода. Фикстуры (Fixture) — состояние среды тестирования, которое необходимо для успешного выполнения испытуемого метода. Это заранее заданный набор объектов и их поведения в используемых условиях.

Этапы тестирования

Тест состоит из трёх этапов:

1. Задание тестируемых данных (фикстур).
2. Использование тестируемого кода (вызов тестируемого метода).
3. Проверка результатов и сверка с ожидаемыми.

Чтобы обеспечить модульность теста, нужно нужно изолироваться от других слоев приложения. Сделать это можно помощью заглушек, моков и шпионов. Мок (Mock) — объекты, которые настраиваются (например, специфично для каждого теста) и позволяют задать ожидания вызовы методов в виде ответов, которые мы планируем получить. Проверки соответствия ожиданиям проводятся через вызовы к Mock-объектам. Заглушки (Stub) — обеспечивают жестко зашитый ответ на вызовы во время тестирования. Также они могут сохранять в себе информацию о вызове (например, параметры или количество этих вызовов). Такие иногда называют своим термином — шпион ( Spy ). Иногда эти термины stubs и mock путают: разница в том, что стаб ничего не проверяет, а лишь имитирует заданное состояние. А мок — это объект, у которого есть ожидания. Например, что данный метод класса должен быть вызван определенное число раз. Иными словами, ваш тест никогда не сломается из-за «стаба», а вот из-за мока может.

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

Практика тестирования

А теперь давайте рассмотрим приведенный выше материал на конкретном примере. Будем тестировать метод для сервиса — update. Рассматривать слой дао не будем, так как он у нас дефолтный. Добавим стартер для тестов:

org.springframework.boot spring-boot-starter-test 2.2.2.RELEASE test
Итак, класс сервиса:

8 — вытягиваем обновляемый обьект из БД 9-14 — создаём объект через билдер, если в приходящем объекте есть поле — задаем его, если нет — оставляем то, что есть в БД И смотрим наш тест:

1 — наш Runner 4 — изолируем сервис от слоя дао, подставляя мок 11 — задаем для класса тестовую сущность (ту, которую мы будем юзать в качестве испытуемого хомячка) 22 — задаём объект сервиса, который мы и будем тестить

Здесь мы видим четкое разделение теста на три части: 3-9 — задание фикстур 11 — выполнение тестируемой части 13-17 — проверка результатов Подробнее: 3-4 — задаём поведение для мока дао 5 — задаём экземпляр, который мы будем апдейтить поверх нашего стандартного 11 — используем метод и берём результирующий экземпляр 13 — проверяем, что он не ноль 14 — сверяем айди результата и заданные аргументы метода 15 — проверяем, обновилось ли имя 16 — смотрим результат по cpu 17 – так как в экземпляре для обновления мы не задавали это поле, оно должно остаться прежним, проверяем это. Запускаем: Тест зелёный, можно выдыхать)) Итак, подведём итоги: тестирование улучшает качество кода и делает процесс разработки более гибким и надёжный. Представьте себе, как много сил мы потратим при изменении дизайна программного обеспечения с сотнями файлов классов. Когда у нас есть модульные тесты, написанные для всех этих классов, мы можем уверенно провести рефакторинг. И самое главное — это помогает нам легко находить ошибки во время разработки. Гайз, на этом у меня сегодня всё: сыпем лайки, пишем комменты)))

Источник: javarush.com