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

Статическое и динамическое тестирование (Static Testing, Dynamic Testing).

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

Статическое тестирование (Static Testing, Non-execution technique или verification).

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

Почему требуется статическое тестирование:

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

• Увеличение размера ПО: по мере увеличения размера программного продукта становится трудно справиться с ним, поскольку эффективность покрытия кода снижается.

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

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

Система не запущена:

• Тестирование документации.

• Ревью кода.

• Статически может тестироваться как черным, так и белым ящиком.

Динамическое тестирование (Dynamic Testing, Execution technique или validation).

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

Система запущена:

• Регистрация / авторизация.
• Загрузка файла.
• Создание карточки объекта.
• Любое другое воздействие на систему.
• Работа с любой функциональностью.

Вид ручного и авто тестирования.

По степени автоматизации.

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

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

Основные шаги ручного тестирования:

Планирование.

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

Идентификация тест-кейсов.

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

Выполнение тестов.

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

Документирование.

Запись результатов тестирования, включая обнаруженные ошибки и недочеты, а также подробные описания сценариев.

Отчетность.

Подготовка отчетов для команды разработчиков о найденных ошибках и других наблюдениях.

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

• Гибкость.

Ручное тестирование позволяет тестировщикам адаптироваться к изменениям в интерфейсе или функциональности.

Интуитивность.

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

Оценка пользовательского опыта.

Ручное тестирование позволяет проверить, как приложение ведет себя для конечного пользователя.

Примеры ручного тестирования:

Проверка функциональности формы входа.

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

Тестирование различных браузеров.

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

Тестирование сложных сценариев.

Например, заказ товара с определенными характеристиками и способом доставки.

Проверка локализации.

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

Тестирование взаимодействия.

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

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

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

Принципы автоматизированного тестирования:

Автоматизация.

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

Повторяемость.

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

Скорость.

Автоматизированные тесты выполняются значительно быстрее, чем ручные, что позволяет сократить время проверки приложения.

Усовершенствование документации.

Автоматизированные тесты служат дополнительной документацией, которая описывает ожидаемое поведение приложения.

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

Тестирование интерфейсов.

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

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

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

Тестирование API.

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

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

Автоматизированные тесты могут создавать нагрузку и измерять производительность приложения при различных условиях.

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

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

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

Процесс функционального тестирования включает следующие аспекты:

Идентификация функциональных требований.

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

Создание тестовых случаев.

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

Подготовка тестовых данных.

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

Выполнение тестов.

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

Сравнение результатов.

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

Документирование ошибок.

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

Тестирование граничных условий.

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

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

Пример функционального тестирования:

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

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

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

Модульное тестирование.

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

Принципы модульного тестирования:

• Изоляция.

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

• Автоматизация.

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

• Покрытие кода.

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

Преимущества модульного тестирования:

• Быстрота.

Модульные тесты могут быть выполнены очень быстро, так как они тестируют только ограниченные части кода.

• Изолированность.

Ошибка в одном модуле не влияет на работу других. Это облегчает поиск и устранение проблем.

• Раннее выявление ошибок.

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

• Облегчение рефакторинга.

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

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

Интеграционное тестирование проверяет взаимодействие между компонентами внутри системы, так и со сторонними системами (другими сайтами).

Например, список больниц определяется выбранным диагнозом на предыдущей вкладке (интеграция между компонентами системы). Расположение больницы на карте (интеграция с Яндекс-картой). Курсы валют на главной странице Яндекса (интеграция с биржей). Интеграцию между компонентами можно представить как несколько пазлов, образующих какую-то картинку.

Основные цели интеграционного тестирования:

Проверка взаимодействия.

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

Обнаружение дефектов интеграции.

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

Проверка системной функциональности.

Убеждение, что весь функционал системы работает так, как ожидается после объединения компонентов.

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

Тестирование API.

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

Тестирование базы данных.

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

Тестирование взаимодействия микросервисов.

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

Тестирование сторонних интеграций.

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

Системное тестирование.

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

Основные аспекты системного тестирования:

Имитация реальной среды.

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

Проверка функциональности системы.

Системное тестирование проверяет весь функциональный спектр системы в контексте реальных бизнес-сценариев.

Выявление проблем интеграции.

Этот вид тестирования также направлен на выявление ошибок интеграции между разными компонентами или модулями.

Проверка производительности.

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

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

• Тестирование полной функциональности продукта.

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

Тестирование пользовательских сценариев.

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

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

Можно проводить тестирование, чтобы измерить, как система реагирует на нагрузку, например, как она обрабатывает множество одновременных запросов.

Тестирование совместимости.

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

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

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

Сценарий: Заказ товара и оплата.

Шаги:

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

Проверки:

• Указанный товар добавлен в корзину.

• Заказ создан в базе данных.

• Расчет стоимости заказа верный.

• Способы оплаты отображаются корректно.

• После завершения заказа, статус заказа обновляется.

• Система успешно интегрируется с платежной системой.

• После оплаты, статус заказа обновляется на «оплачено».

Приемочное тестирование.

Приемочное тестирование формальный процесс тестирования, который проверяет соответствие системы требованиям и проводится с целью:

• Определения удовлетворяет ли система приемочным критериям.
• Вынесения решения заказчиком или другим уполномоченным лицом принимается приложение или нет.

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

Приемочное тестирование пользователем (User Acceptance Testing — UAT).

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

Приемочное тестирование по контракту (Contract Acceptance Testing).

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

Принципы приемочного тестирования:

• Тестирование в реальных условиях.

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

Оценка готовности.

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

Соответствие требованиям.

Система оценивается на предмет того, соответствует ли она бизнес-требованиям и ожиданиям пользователей.

Примеры приемочного тестирования:

• Приемочное тестирование интернет-магазина.

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

Приемочное тестирование банковской системы.

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

Приемочное тестирование мобильного приложения.

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

• Пример приемочного тестирования (UAT) для онлайн-бронирования отеля:

• Сценарий: Бронирование отеля через веб-сайт

Шаги:

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

Проверки:

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

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

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

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

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

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

• Определение целей и требований.

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

Выбор типов производительностных тестов.

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

Создание сценариев тестирования.

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

Выбор инструментов.

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

Настройка тестового окружения.

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

Выполнение тестов.

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

Анализ результатов.

Анализ данных, собранных во время тестирования, для определения, соответствует ли производительность продукта установленным требованиям.

Оптимизация и корректировка.

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

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

• Нагрузочное тестирование (Load Testing).

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

Стресс-тестирование (Stress Testing).

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

Тестирование на стабильность (Stability Testing).

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

Тестирование производительности базы данных.

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

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

Оценка производительности API, которые используются для взаимодействия между компонентами продукта или с другими системами.

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

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

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

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

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

Тестирование емкости.

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

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

Емкость системы измеряется в RPS (requests per second). Используемый подход: ступенчато повышаем нагрузку до момента, когда время ответа начнет расти экспоненциально. Экспоненциальный рост времени ответа, как правило, связан с полной утилизацией одного из ресурсов, из-за которого запросы вместо моментальной обработки выстраиваются друг за другом и ждут своей очереди на обработку.

Нагрузочное тестирование.

Автоматизированное тестирование, имитирующее работу определенного количества пользователей на каком-либо ресурсе.

Измеряется нагрузка запросах в секунду (RPS) или пропускная способность — это общее количество запросов к серверу приложению, которое создает нагрузочный тест в секунду.
Формула: RPS = (количество запросов) / (общее время в секундах).

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

Вот как проходит нагрузочное тестирование:

Определение сценариев нагрузки.

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

Создание тестовых сценариев.

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

Запуск теста.

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

Мониторинг и анализ.

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

Идентификация узких мест.

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

Оптимизация и коррекция.

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

Примеры нагрузочного тестирования:

Тестирование нагрузки на интернет-магазин.

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

Тестирование социальных сетей.

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

Тестирование банковской системы.

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

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

Стрессовое тестирование.

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

Различие нагрузочного и стрессового тестирования.

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

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

Тестирование на максимальную нагрузку (Maximum Load Testing):

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

Пример:

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

Тестирование на перегрузку (Overload Testing):

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

Пример:

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

Тестирование на утечку ресурсов (Resource Exhaustion Testing):

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

Пример:

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

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

Тестирование масштабируемости.

Тестирование масштабируемости проводится для определения способности приложения масштабироваться с точки зрения пользовательской нагрузки, количества транзакций, объема данных и т.д. Цель теста масштабируемости отличается от стрессового или нагрузочного тестирования. Например, компания ожидает шестикратного увеличения нагрузки на серверы в течение следующих двух месяцев. Им может потребоваться увеличить производительность сервера и сократить время обработки запроса, чтобы лучше обслуживать посетителей. Если приложение масштабируемое, то можно сократить это время, обновив оборудование сервера, например, можно увеличить частоту ЦП и добавить больше ОЗУ.

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

Цель тестирования масштабируемости — выявить узкие места, пределы производительности и возможные проблемы, которые могут возникнуть при росте нагрузки на систему.

Примеры тестирования масштабируемости:

Горизонтальное масштабирование.

Этот тип масштабирования подразумевает добавление новых экземпляров (узлов) системы для распределения нагрузки.
Пример — добавление новых серверов к кластеру баз данных.

Вертикальное масштабирование.

В этом случае масштабирование достигается путем увеличения мощности или ресурсов на существующих серверах. Пример — увеличение оперативной памяти или процессорных мощностей.

Тестирование с реалистичной нагрузкой.

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

Тестирование масштабируемости баз данных.

Увеличение объема данных в базе данных и проверка, как это влияет на производительность запросов и общее время ответа.

Тестирование виртуальных сред.

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

Процесс тестирования масштабируемости включает в себя:

Планирование.

Определение сценариев масштабируемости, параметров тестирования и критериев успеха.

Подготовка окружения.

Настройка тестовой среды и инфраструктуры для масштабирования.

Запуск тестов.

Имитация увеличения нагрузки на систему в соответствии с определенными сценариями.

Сбор данных.

Мониторинг и сбор данных о производительности системы, времени ответа и других метриках.

Анализ результатов.

Оценка производительности, обнаружение узких мест, определение возможных проблем.

Оптимизация и коррекция.

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

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

Объемное тестирование.

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

Объемное тестирование (также flood testing) предназначено для прогнозирования того, может ли система / приложение обрабатывать большой объем данных в плане проверки объема данных, обрабатываемых базой данных. Это тестирование сосредоточено на наполнении БД продукта в реальных сценариях использования, отслеживании производительности приложения при различных объемах БД. Обычно продолжительность проверки объема составляет 1 час или время, необходимое для обработки n записей. Оно может варьироваться в зависимости от SLA / требований.

SLA (Соглашение об уровне предоставления услуги) — термин методологии ITIL, обозначающий формальный договор между заказчиком услуги и её поставщиком, содержащий описание услуги, права и обязанности сторон и, самое главное, согласованный уровень качества предоставления данной услуги.

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

Тестирование нагрузки (Load Testing):

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

Пример:

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

Тестирование производительности (Performance Testing):

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

Пример:

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

Тестирование стабильности (Stability Testing):

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

Пример:

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

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

Тестирование выносливости / стабильности.

Включает в себя тестирование системы со значительной нагрузкой в течение длительного периода времени, чтобы выяснить, как система ведет себя при длительном использовании. То есть для обеспечения того, чтобы производительность и / или время отклика после некоторого длительного периода устойчивой активности были не хуже, чем в начале теста. В основном используется для проверки утечек памяти, времени отклика, правильности подключения и закрытия подключения к модулям (например, БД) и т.п. Обычно продолжительность испытания на выносливость составляет 6-8 часов; может отличаться в зависимости от SLA / требований.

Тестирование устойчивости.

Проверяет отказоустойчивость приложения или способность противостоять стрессовым или сложным факторам, а также включает в себя тестирование на соответствие (compliance), выносливость (endurance), нагрузочное тестирование и тестирование восстановления (recovery testing). Эту форму тестирования иногда также называют chaos engineering.

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

Тестирование надежности.

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

Примеры методов и практик тестирования надежности:

Тестирование стабильности.

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

Тестирование на граничных условиях.

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

Тестирование отказоустойчивости.

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

Тестирование нагрузки.

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

Тестирование долговечности.

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

Тестирование восстановления после сбоев.

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

Тестирование совместимости.

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

Примеры практик, которые могут улучшить тестирование надежности:

Создание сценариев сбоев.

Разработка сценариев, которые симулируют различные сбои, чтобы оценить, как система реагирует и восстанавливается.

Тестирование резервирования.

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

Использование автоматизации.

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

Тестирование в реальных условиях.

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

Мониторинг продукта в производственной среде.

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

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

Тестирование на отказ и восстановление.

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

Эталонное и базовое тестирование.

• Стандарт, согласно которому может производиться измерение или сравнение.
• Тест, который может использоваться для сравнения компонентов или систем друг с другом или на соответствие стандарту, указанному в пункте (1).

Эталонное тестирование (Benchmark Testing) — это набор стандартов, метрик или контрольных точек (reference point), по которым оценивается (assessed or evaluated) качество работы продукта или услуги, через нагрузочное тестирование модуля или всей комплексной программной системы для определения ее производительности. Оно определяет повторяемый набор экспериментальных результатов, которые помогают определить функциональные возможности как для текущих, так и для будущих выпусков программного обеспечения.

Тестирование базовой версии (Baseline Testing) — это подход к тестированию, в котором за точку отсчета берется базовая линия
— это показатель конкретного ориентира, который служит основой для нового тестирования. В Baseline Testing тесты прогоняют, сохраняют все результаты и сравнивают с базовым уровнем. Этот базовый уровень относится к последним принятым результатам испытаний. Если в исходном коде есть новые изменения, то для повторного выполнения тестов необходимо сформировать текущий базовый уровень. Если последние результаты будут приняты, то текущая базовая линия станет базовой.

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

Нефункциональное тестирование описывает тесты, необходимые для определения характеристик программного обеспечения, которые могут быть измерены различными величинами. В целом, это тестирование того, «Как» система работает.

Тестирование безопасности.

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

• Конфиденциальность — сокрытие определенных ресурсов или информации.
• Целостность — ресурс может быть изменен только в соответствии с полномочиями пользователя.
• Доступность — ресурсы должны быть доступны только авторизованному пользователю, внутреннему объекту или устройству.

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

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

Анализ проникновения зависит от двух механизмов, а именно от оценки уязвимости и тестирования на проникновение (VAPT — Vulnerability Assessment and Penetration testing).

Основная масса угроз информационной безопасности приходится на следующие виды:

• DDoS (Distributed Denial of Service) — атака, направленная на перегрузку сети или конкретного сервера большим количеством запросов. DDoS-атаки приводят к временной недоступности инфраструктуры.
• Вирусы, черви и трояны — вредоносные программы, которые проникают в компьютер или сеть и наносят различный вред. С их помощью киберпреступники крадут, портят и уничтожают данные.
• Фишинг — мошенническая практика, когда киберпреступники выдают себя за надежные источники для получения личной информации. Одна из разновидностей фишинга — использование подменных доменных имен, которые похожи на настоящие.
• Перехват паролей — процесс получения доступа к чужому аккаунту путем кражи учетных данных.
• Ботнет — сеть зараженных компьютеров, используемых для выполнения вредоносных действий без ведома их владельцев.
• Эксплойты — уязвимости в ПО и аппаратной части, которые киберпреступники могут использовать для взлома. К эксплойтам относятся, в частности, программные и аппаратные бэкдоры.
• Скрытые загрузки — загрузка вредоносного кода на компьютер без ведома пользователя.
• SQL-инъекции — метод атаки, при котором злоумышленники внедряют SQL-код в запросы к базе данных для получения доступа к данным, содержащимся в этой БД.
• Социальная инженерия — манипуляции людьми с целью получения личной информации или выполнения определенных действий. Например, злоумышленник может различными способами втираться в доверие к жертве, ведя с ней переписку в социальных сетях или мессенджерах.
• Атаки Man in the middle, или «человек посередине», — киберпреступник перехватывает и контролирует коммуникацию между двумя сторонами.
• Advanced Persistent Threat (APT) — продолжительная и хорошо подготовленная целенаправленная кибератака. В отличие от DDoS, APT — комплексная киберугроза, сочетающая различные способы атак на корпоративную инфраструктуру. Поэтому противостоять таким угрозам тяжелее всего. Поэтому следует тщательно организовать защиту корпоративной сети и отдельных устройств, а также позаботиться о том, чтобы персонал владел основами ИБ.

Классификация уязвимостей:

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

FUZZ testing (fuzzing) — это тип тестирования безопасности, который обнаруживает ошибки кодирования и лазейки в программном обеспечении, операционных системах или сетях. Фаззинг включает в себя ввод огромного количества случайных данных, называемых fuzz, в тестируемое программное обеспечение, чтобы заставить его дать сбой или прорвать его защиту. Фаззинг часто выявляет уязвимости, которые могут быть использованы с помощью SQL-инъекции, переполнения буфера, отказа в обслуживании (DOS) и XSS. Fuzz-тестирование выполняется с помощью фаззера — программы, которая автоматически вводит полуслучайные данные в программу и обнаруживает ошибки. Fuzz-тестирование обычно выполняется автоматически.

Приложения для проверки безопасности. OWASP ZAP.

Сканер веб-приложений, основанный на методике DAST (Dynamic Application Security Testing). В русском варианте этот метод принято называть методом тестирования «черного ящика». Методика позволяет обнаруживать проблемы безопасности в работающем приложении или веб-сайте при помощи их сканирования на известные уязвимости. К таким уязвимостям можно отнести SQL-инъекции, межсайтовый скриптинг (XSS), Clickjacking и т.д.

OWASP ZAP разработан и поддерживается одноименным проектом под названием OWASP (Open Web Application Security Project) — некоммерческой организацией, которая специализируется на создании статей, материалов, документации, инструментов и технологий, позволяющих разрабатывать приложения безопаснее, а также обеспечивать должный уровень информационной безопасности уже созданных приложений и сайтов.

В качестве преимуществ OWASP ZAP можно выделить:

• Кроссплатформенность — поддержка всех основных ОС (Windows, Linux, MacOS);
• Бесплатный проект с открытым исходным кодом;
• Поддержка плагинов для расширения функциональности;
• Возможность работы как через графический интерфейс (GUI), так и через интерфейс командной строки;
• Обширный набор функций — от активного / пассивного сканирования и до сканирования API и AJAX;
• Простота использования. Идеально подходит и для начинающих специалистов в ИБ и для профессионалов.

Установка.

OWASP ZAP является кроссплатформенным ПО и может быть установлен на Windows, Linux и MacOS. Также запуск возможен в контейнере Docker. Для установки и запуска программы на Windows и Linux требуется заранее предустановленная Java версии 11 и выше. Установщик для MacOS уже включает в себя Java. Для запуска в контейнере Docker также заранее не нужна предустановленная Java.

Для Docker отдельно представлены образы со следующими тегами:

• Stable — стандартная (обычная) версия.
• Bare — минимальный версия. Содержит только самые необходимые функции. Идеально подходит для запуска в командной строке.
• Weekly — версия, обновления для которой выходят каждую неделю.
• Live — бета-версия. Содержит самый последний релиз.

В дистрибутивах Kali Linux до версии 2023.1 OWASP ZAP уже предустановлен в системе (при условии, что на этапе установке

ОС в разделе Software selection был выбран пункт default recommended tools или large default selection plus additional tools, в противном случае установить OWASP ZAP необходимо вручную).

В качестве примера будет использоваться последняя актуальная версия 2.12.0 в ОС Kali Linux.

Принцип работы.

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

Обзор основных функций графического интерфейса OWASP ZAP.

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

• Режимы сканирования.

В OWASP ZAP существуют 4 режима сканирования: Standard Mode — обычное сканирование;

Safe Mode — безопасное сканирование, позволяющее выполнять только те действия, которые не смогут навредить системе. В этом режиме не используются атаки на целевой сайт;

Protected Mode — защищенное сканирование, позволяющее имитировать потенциально опасные уязвимости;

ATTACK Mode — режим атаки, позволяющий, помимо сканирования, также выполнять атаки на потенциальный сайт / приложение.

• Сайты.

Здесь отображаются сайты, которые сканируются в данный момент или уже были просканированы. Также в данном разделе отображается полная структура сайта.

• Раздел со сканированием.

Основной раздел, в котором запускается сканирование сайта.

• Результаты.

Раздел с результатами располагается внизу и подразделяется на вкладки History, Search, Alerts, Output.

History — отображает список всех запросов в том порядке, в котором они были отправлены;

Search — позволяет производить поиск при помощи регулярных выражений в URL-адресах, запросах, ответах, заголовках;

Alerts — отображает найденные уязвимости в сканированном веб-сайте. Уязвимости разбиты на категории. Каждой найденной уязвимости присваивается степень критичности. Описание данного раздела будет рассмотрено далее;

Output — отображает различные информационные сообщения. Например, трассировку стека, ошибки и другую отладочную информацию.

Burp Suite.

Burp Suite — это мультитул для проведения аудита безопасности веб-приложений. Содержит инструменты для составления карты веб-приложения, поиска файлов и папок, модификации запросов, фаззинга, подбора паролей и многое другое. Также существует магазин дополнений BApp store, содержащий дополнительные расширения, увеличивающие функционал приложения. Стоит отметить и появление в последнем релизе мобильного помощника для исследования безопасности мобильных приложений — MobileAssistant для платформы iOS.

Burp Suite — это интегрированная платформа, предназначенная для проведения аудита веб-приложения, как в ручном, так и в автоматических режимах. Содержит интуитивно понятный интерфейс со специально спроектированными табами, позволяющими улучшить и ускорить процесс атаки. Сам инструмент представляет из себя проксирующий механизм, перехватывающий и обрабатывающий все поступающие от браузера запросы. Имеется возможность установки сертификата burp для анализа https соединений.

Основной функционал основан на следующих модулях:

Proxy — перехватывающий прокси-сервер, работающий по протоколу HTTP(S) в режиме man-in-the-middle. Находясь между браузером и веб-приложением он позволяет перехватывать, изучать и изменять трафик идущий в обоих направлениях.

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

Scanner — автоматический сканер уязвимостей ( OWASP TOP 10 и т.д.) Доступен в Professional версии, в бесплатной версии только описание возможностей.

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

Repeater — утилита для модифицирования и повторной отправки отдельных HTTP-запросов и анализа ответов приложения.

Sequencer — утилита для анализа генерации случайных данных приложения, выявления алгоритма генерации, предиктивности данных.

Decoder — утилита для ручного или автоматического преобразования данных веб-приложения.

Comparer — утилита для выявления различий в данных.

Extender — расширения в BurpSuite. Можно добавлять как готовые из BApp store, так и собственной разработки.

Intruder.

Одна из основных утилит для тестирования это Burp Intruder. Принцип его работы заключается в следующем: он обрабатывает каждый HTTP-запрос (называемый «базовым запросом»), изменяя параметры различными способами, выдавая каждую измененную версию запроса и анализируя ответы приложения для идентификации интересных функций или поведения
веб-приложения.

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

Burp Intruder поддерживает следующие виды атак:

Sniper — используется отдельный набор данных — одно поле (участок, отмеченный маркерами) — один пейлоад. Данный тип атак полезен при индивидуальном тестировании полей на наличие общих уязвимостей (таких как XSS).

Battering ram — при таком виде атак используется принцип — все поля — один пейлоад. Это может пригодиться когда для осуществления атаки необходимо помещать одни и те же данные сразу во множество позиций.

Pitchfork — этот вид атак использует несколько пейлодов для нескольких полей. Например, при первом запросе первая строка из первого проверочного набора будет помещена на первое место обозначенное маркерами. А первая строка из второго набора поместится на вторую позицию. При формировании второго запроса на первое место будет помещена вторая строка из первого набора, а на второе — вторая строка из второго набора.
Такой вид атак может пригодиться в ситуациях, когда приложению нужно отсылать всё время разные, но каким-то образом взаимосвязанные данные. Например, если необходимо отправлять имя пользователя в одном поле и его ID в другом.

Сluster bomb — этот вид атак использует перебор основного набора пейлоадов и добавление вторичных. Это удобно использовать например для подбора паролей: при первом запросе Intruder поместит на первую позицию первую строку из первого набора пейлоадов, на вторую первую строку из второго. При втором запросе на первом месте останется первая строка первого набора, а на вторую будет помещена вторая строка второго набора. Потом третья, и так далее.

MobileAssistant.

Burp Suite Mobile Assistant — это инструмент для облегчения тестирования приложений iOS с Burp Suite.

Он может изменять общесистемные параметры прокси-сервера устройств iOS, чтобы трафик HTTP(S) мог быть легко перенаправлен в Burp для анализа. Также он способен использовать SSL pinning — внедрение своего сертификата.
Использовать мобильного помощника можно на джейлбрекнутых iOS устройствах, начиная от 8 версии iOS и до 10 (хотя на ней и не гарантируется стабильная работа). Для установки нужна Cydia и полноценный Burp на хост системе.

Nessus.

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

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

Программа имеет клиент-серверную архитектуру, что сильно расширяет возможности сканирования. Согласно проведенному порталом securitylab.ru опросу, nessus используют 17 % респондентов.

Прежде всего используется для сканирования портов и определяет сервисы, использующие их. Также проводится проверка сервисов по базе уязвимостей. Для тестирования уязвимостей используются специальные плагины, написанные на языке NASL (Nessus Attack Scripting Language).

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

При отключенной опции «safe checks» некоторые тесты на уязвимости, используемые Nessus, могут привести к нарушениям в работе сканируемых систем.

Примеры методов и практик тестирования безопасности:

Тестирование авторизации и аутентификации.

Проверка того, что механизмы авторизации и аутентификации корректно работают. Например, путем попытки входа с неверными учетными данными и проверкой, что доступ запрещен.

Тестирование уязвимостей веб-приложений (OWASP Top 10).

Применение методов, описанных в перечне OWASP Top 10 — это десять наиболее распространенных уязвимостей в
веб-приложениях, таких как инъекции SQL, межсайтовый скриптинг (XSS), кросс-сайтовая подделка запроса (CSRF) и другие.

Тестирование на утечку данных.

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

Тестирование уязвимостей сетевого стека.

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

Тестирование на уязвимости встроенных систем.

Обнаружение уязвимостей во встроенных системах, таких как маршрутизаторы, IP-камеры, умные устройства и другие.

Тестирование на отказ в обслуживании (DoS).

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

Тестирование настройки безопасности.

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

Тестирование брутфорса и перебора: Попытка взлома паролей и учетных записей путем перебора возможных комбинаций.

Примеры практик, которые могут улучшить тестирование безопасности:

Использование специализированных инструментов.

Существует множество инструментов, таких как Burp Suite, OWASP Zap, Nessus и другие, которые помогают автоматизировать процесс обнаружения уязвимостей.

Проведение пентеста (пенетрационное тестирование).

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

Участие экспертов в области безопасности.

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

Анализ кода.

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

Обучение сотрудников.

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

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

Тестирование пользовательского интерфейса (UI — User Interface).

Соответствие интерфейса приложения (сайта), которые сделал разработчик макетам, созданным дизайнером интерфейсов.

Тестирование удобства пользования (UX — User Experience).

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

User friendly.

Обозначение интерфейса, дружественного пользователю, в теории юзабилити. Этим словосочетанием обычно обозначают среду (в том числе и сайта), продуманную с учетом удобства пользователя.

GUI (Graphical User Interface) или ГИП (графический интерфейс пользователя).

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

Примеры методов и практик тестирования удобства использования:

Тестирование пользовательских сценариев.

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

Тестирование навигации.

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

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

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

Тестирование отзывчивости и адаптивности.

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

Тестирование загрузки и производительности.

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

Тестирование визуального дизайна.

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

Тестирование простоты использования.

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

Тестирование обратной связи и подсказок.

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

Тестирование доступности.

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

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

Проведение пользовательских тестов.

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

Анализ метрик использования.

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

Экспертное оценивание.

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

Сопоставление с конкурентами.

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

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

Тестирование доступности.

Это подмножество юзабилити-тестирования. Его цель — убедиться в том, что продукт удобен в использовании людям с различными видами ограничений, инвалидности или особенностями восприятия. Это могут быть проблемы со зрением, слухом или ограничения в подвижности рук. Что наиболее важно, существуют определенные законы и инструкции по тестированию доступности, которые также должны соблюдаться, например, Рекомендации по доступности веб-контента (Web content accessibility guidelines). Продукт должен правильно работать с соответствующим ПО.

Примеры такого программного обеспечения:

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

Еще один из примеров — люди с цветовой слепотой (дальтонизмом). Эта особенность довольно широко распространена. Различными видами цветовой слепоты страдают около 8 % мужчин и 0,4 % женщин — не так уж мало!

Инсталляционное тестирование (Installation Testing).

Тестирование инсталляции (установки) направлено на проверку успешной установки, настройки, обновления и удаления ПО, как десктопного, так и мобильного.

Примерами инсталляционного тестирования могут быть:

Установка и обновление программ.

Предположим, разработан текстовый редактор. При выпуске новой версии необходимо убедиться, что процесс установки и обновления выполняется успешно. Выполнить установку новой версии на различных операционных системах (например, Windows, macOS, Linux) и проверить, что приложение успешно запускается после установки.

Корректность настроек.

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

Совместимость.

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

Разрешение зависимостей.

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

Откат установки.

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

Тестирование параметров командной строки.

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

Проверка на наличие вредоносного ПО.

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

Общий подход к инсталляционному тестированию включает следующие шаги:

Подготовка окружения.

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

Установка программы.

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

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

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

Проверка на конфликты.

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

Откат установки.

Проверка возможности успешного удаления программы и восстановления системы в исходное состояние.

Создание отчета.

Документирование всех шагов, результатов и обнаруженных проблем.

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

Инсталляционное тестирование интерфейса (GUI-тестирование).

GUI-тестирование (Graphical User Interface Testing) — это вид тестирования программного обеспечения, который направлен на проверку графического пользовательского интерфейса (GUI) продукта. Основной целью GUI-тестирования является убедиться, что интерфейс продукта работает корректно, интуитивно понятен пользователям и обеспечивает эффективное взаимодействие с программой.

Процесс GUI-тестирования включает в себя следующие аспекты:

Проверка внешнего вида.

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

Проверка компонентов интерфейса.

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

Навигация и переходы.

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

Ввод и вывод данных.

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

Работа с данными.

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

Тестирование кнопок и действий.

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

Адаптивность и респонсивность.

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

Тестирование диалоговых окон.

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

Локализация.

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

Пример GUI-тестирования:

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

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

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

Тестирование на соответствие (Conformance / Compliance testing).

Conformance — неофициальные, внутренние стандарты организации, добровольное обязательство делать что-либо признанным образом, либо стремление к Compliance, но которое не закончено / не подтверждено формально.

Конфигурационное тестирование (Configuration testing).

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

Configuration = performance + compatibility:

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

Compatibility аспект: проверить объект тестирования на совместимость с объявленным в спецификации оборудованием, операционными системами и программными продуктами третьих фирм.

Конфигурационное тестирование включает в себя следующие аспекты:

Операционные системы.

Проверка работы продукта на разных версиях операционных систем, таких как Windows, macOS, Linux, Android и iOS.

Браузеры.

Тестирование совместимости продукта с разными веб-браузерами, такими как Chrome, Firefox, Edge, Safari и другими.

Устройства.

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

Разрешения экрана.

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

Локализация.

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

Сетевые условия.

Проверка поведения продукта при различных скоростях интернет-соединения, а также при недоступности сети.

Версии сторонних компонентов.

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

Конфигурация аппаратных ресурсов.

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

Тестирование локализации, глобализации и интернационализации.

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

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

Globalization = Internationalization + Localization.

Интернационализация ПО (Internationalization (I18N)) — это особый процесс, при котором веб-софт создается таким образом, чтобы оно было равноудаленным от какой-либо культуры и (или) специфики определенного географического региона. Например, одна из задач по интернационализации ПО — корректное редактирование логики всех подключенных параметров форматирования (формат даты, времени, цифровое и валютное форматирование). Также, тестировщики во время проверки на соответствие ПО требованиям I18N тестируют работу продукта на одинаковую работу в разных регионах и культурах мира.

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

В основном, фокус тестирования интернационализации направлен на:

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

Локализация ПО (Localization (L10N)) — деятельность по модификации ПО в соответствии с определенными региональными настройками (языком, географической территорией, культурными особенностями). В данный вид проверки входит необходимость выполнения работ по переводу всего контента программного обеспечения для конечного пользователя. Во время перевода должны учитываться иконки, информационная графика, справочные материалы, техническая документация и иные культурные особенности регионов (например, онлайн-сервис по заказу бургеров не будет показывать

корову на главной странице в Индии или свинью в мусульманских странах).

На что обратить внимание:

• Длина переведенных слов.
• Параметры шрифта пользовательского интерфейса.
• Ввод текста в разных локализациях.
• RTL-языки (справа-налево) или вертикальные.
• Перевод сокращений или аббревиатур.
• Мета-теги (проблемы с SEO или отображением имени вкладки (title, description, keywords)).
• Соответствие мер исчисления, валюты, postal code и т.п.

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

Проверка переводов.

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

Форматирование дат и времени.

Проверка того, что даты и времена отображаются в соответствии с национальными стандартами каждого региона. Например, в США используется формат «месяц / день / год», а в Европе —
«день / месяц / год».

Локализованные числа и валюты.

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

Поддержка алфавитов.

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

Поддержка правописания.

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

Управление переполнением текста.

Обеспечить, чтобы текстовые блоки и элементы интерфейса были адаптированы к длинным или коротким строкам в разных языках.

Тестирование местных обычаев и традиций.

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

Проверка поддержки разных кодировок.

Убедиться, что продукт поддерживает разные кодировки символов, такие как UTF-8, UTF-16 и другие, чтобы правильно отображать разные языки.

Примеры практик, которые могут улучшить тестирование локализации:

Использование профессиональных переводчиков.

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

Локализованные тестовые данные.

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

Тестирование на реальных устройствах.

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

Контроль длины строк.

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

Локализованные тестовые среды.

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

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

Связанные с изменениями.

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

Дымовое (Smoke) тестирование.

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

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

(Например, если в требованиях написано, что на аватар можно загрузить картинку не более 10 Мб, то нужно загрузить картинку не более 10 Мб и выполнить проверку следующего модуля).

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

Вот как происходит дымовое тестирование:

Выбор базового функционала.

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

Сбор исходных данных.

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

Запуск тестов.

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

Анализ результатов.

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

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

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

Дымовое тестирование в данном случае может включать:

• Попытку входа в систему.
• Проверку основных страниц приложения.
• Отправку запросов на базовые действия (например, отправка формы).
• Убедиться, что ключевая функциональность, такая как добавление товара в корзину, работает.

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

Расширенное тестирование.

Особенности расширенного тестирования:

Активное исследование.

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

Динамичный подход.

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

Гибкость и адаптивность.

Методика позволяет быстро реагировать на изменения и неожиданные ситуации в процессе тестирования.

Поиск новых сценариев.

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

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

Неожиданные сценарии.

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

Проверка граничных условий.

Исследование, как приложение ведет себя, когда данные вводятся в пределах или за пределами допустимых границ.

Работа с разными браузерами и устройствами.

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

Симуляция реальных сценариев использования.

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

Эксплорация функциональности.

Исследование различных функций и опций приложения для выявления неочевидных ошибок или недостатков.

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

Санитарное тестирование.

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

Например, по требованиям на аватар можно загрузить изображение не более 10 Мб. Сначала загружается картинка png не более 10 Мб, после jpg. Ожидаемый результат: картинки данных форматов загрузились. Далее воспроизводятся иные сценарии: загружаются отличительные от картинки файлы: docx, gif, mp3. И размера более 10 Мб. Ожидаемый результат: картинки данных форматов не загрузились и размер картинок превышает 10 Мб.

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

Регрессионное тестирование.

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

Хорошей практикой является выбор таких тестов для регрессионного тестирования:

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

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

• Создание тестовых кейсов.

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

Автоматизация тестов.

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

Выбор набора тестов.

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

Интеграция с непрерывной интеграцией (CI).

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

Обработка ошибок.

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

Тестирование на разных платформах.

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

Примеры практик, которые могут улучшить регрессионное тестирование:

• Создание набора тестовых данных.

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

Тестирование краевых случаев.

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

Регулярное проведение тестирования.

Выполняйте регрессионное тестирование после каждого значимого изменения в коде или перед выпуском новой версии продукта.

Интеграция с системами отслеживания ошибок.

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

Обратная связь от пользователей.

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

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

Как начать регрессионное тестирование: 5 шагов.

В организациях используются разные процедуры регрессионного тестирования. Тем не менее есть несколько основных шагов.

Распознайте изменения исходного кода.

Найти измененные компоненты или модули и их влияние на текущие функции. Затем определить модификацию и оптимизацию в исходном коде.

Установить приоритет этих изменений и требований к продукту.

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

Установить критерии входа и точку входа.

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

Выбрать точку выхода.

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

Составить план своих тестов.

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

Методы регрессионного тестирования.

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

Полная регрессия.

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

Выбор регрессионного теста.

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

Приоритизация тест-кейсов.

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

В чем разница между повторным тестированием и регрессионным тестированием?

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

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

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

Регрессионное тестирование

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

Типы регрессионного тестирования.

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

Перед их выполнением важно понять различия между функциональным тестированием, регрессионным тестированием и дымовым тестированием (smoke testing). Существуют разные типы регрессионного тестирования.

Модульное регрессионное тестирование.

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

Частичная регрессия.

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

Полная регрессия.

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

Чтобы подтвердить, что сборка (новые строки кода) некоторое время не обновляется, реализуется форма «финального» регрессионного тестирования. После этого конечным потребителям будет доступна эта окончательная версия.

Регрессионное тестирование и управление конфигурацией.

Управление конфигурацией играет важную роль в регрессионном тестировании в agile-средах. В контексте «гибкой разработки» код постоянно изменяется.

Чтобы убедиться в справедливости регрессионного теста, примите во внимание следующее:

• На этапе регрессионного тестирования не допускаются никакие модификации кода.
• Регрессионный тест не должен оказывать влияния из-за изменений разработчиков.
• Запрещаются модификации базы данных.
• Для регрессионного тестирования необходимо выбрать изолированную базу данных.

Регрессионное тестирование в agile-среде.

Как известно, основу методологии agile составляют поэтапные и итерационные процессы. Спринты (sprints) — это короткие итерации, используемые для разработки программного обеспечения или других продуктов.

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

Подготовка к регрессионному тестированию должна начинаться в начале цикла разработки продукта (product development cycle) и продолжаться до этапа развертывания (deployment phase).

В методологии agile регрессионное тестирование может выполняться одним из двух способов:

• Регрессия уровня спринта (sprint level regression). Этот тип регрессии выполняется для новых функций или улучшений, внесенных в последний спринт. Тест-кейсы выбираются в соответствии с новой добавленной функцией.
• Сквозная регрессия (end-to-end regression). Все тест-кейсы выполняются повторно для тестирования всех функций продукта. Короткие спринты — требование метода agile. Следовательно, выполнение регрессионного тестирования должно быть регулярным. Если делать это вручную,

QA-специалистам придется нелегко. Автоматизация позволяет выявить распространенные проблемы, а также сократить время выполнения.

7 советов как выбрать регрессионное тестирование.

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

Вот рекомендации, как приоритизировать тест-кейсы:

Выбирать тест-кейсы, которые часто содержат ошибки.

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

Выбирать тест-кейсы с особо важной функциональностью.

Выбирайте тест-кейсы, охватывающие ключевые функции приложения. Например, ключевые функции мобильного банковского приложения — это «Перевод средств» и «Оплата счетов». В первую очередь можно сконцентрироваться на тестировании этих функций.

Выбирайте тест-кейсы, в которых происходят частые изменения кода.

В раздел мобильного банкинга «Просмотр заявок» было добавлено нескольких запросов услуги. Это «увеличение лимита кредитной карты», «запрос чековой книжки», «запрос на привязку аккаунта» и «запрос на прекращение платежа по чеку». Чтобы обеспечить эту возможность, код менялся несколько раз. Необходимо расставить приоритеты и выбрать тест-кейсы, охватывающие эту возможность.

Охватите тестирование сквозных потоков.

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

Тестируйте текстовые поля.

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

Выбирайте риск-ориентированный подход к тестированию.

Риск-ориентированный подход к гибкому регрессионному тестированию включает в себя ранжирование тестировщиками тест-кейсов в соответствии с их приоритетом. Это сокращает время и усилия, необходимые для регрессионного тестирования.

Набор регрессионных тестов делится на три группы:

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

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

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

Стремитесь к сотрудничеству.

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

Вывод:

О дымовое тестирование (Smoke testing) проводится при релизе продукта на прод, после регресса и перед тем как новый релиз увидят пользователи;

О санитарное тестирование (Sanity testing) проводится, если в смоуке / регрессе обнаружены какие-то баги (то есть это может быть в любой момент проведено). Сразу скажу: ни разу не слышала, чтобы в русскоязычной среде использовали этот термин;

О приемочное тестирование (Acceptance testing) проводится:

• Тестировщиком при получении новой фичи от разрабов.
• Заказчиком на показе.

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

Тестирование методом «чёрного ящика».

Методика тестирования без глубоких знаний о внутренней работе ПО называется «чёрным ящиком». Специалист не берёт во внимание архитектуру системы и не имеет доступа к исходному коду. Как правило, при выполнении теста с «чёрным ящиком» специалист работает с пользовательским интерфейсом системы, вводя данные и анализируя результат. При этом тестировщик не знает, как и где обрабатываются эти данные.

Основные принципы метода тестирования черного ящика:

Отсутствие знания о внутренней структуре.

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

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

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

Важность тестовых данных.

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

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

Тестирование методом «белого ящика».

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

Основные аспекты метода тестирования белого ящика:

Полное знание о структуре программы.

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

Тестирование всех возможных путей выполнения.

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

Тестирование путей ошибок.

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

Примеры методов тестирования белого ящика:

Тестирование условий.

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

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

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

Покрытие кода.

Один из показателей эффективности тестирования белого ящика — покрытие кода. Существуют метрики, такие как покрытие строк кода (line coverage), покрытие ветвей (branch coverage) и покрытие путей (path coverage), которые позволяют оценить, насколько много кода было выполнено тестами.

Тестирование исключений.

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

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

Тестирование методом «серого ящика».

Метод представляет собой что-то среднее между двумя предыдущими. При тестировании «серого ящика» специалист должен иметь представление о внутреннем устройстве ПО — но не слишком глубокое. Он ставит себя на место конечного пользователя, но проверяет функционал программы опираясь на понимание её внутреннего устройства.

Основные аспекты метода тестирования серого ящика:

Частичное знание о коде.

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

Тестирование внутренних путей.

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

Выбор тестовых данных.

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

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

Тестирование пути выполнения.

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

Тестирование граничных значений.

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

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

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

Тестирование исключений.

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

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