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

Определение

Тестирование делится на функциональное и нефункциональное. О функциональном тестировании — отдельный мини-гайд.

Что такое нефункциональное тестирование? Быстрый ответ: проверка нефункциональных требований (например, производительность, юзабилити, надежность, совместимость).

Важность нефункционального тестирования

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

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

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

  • Как приложение ведет себя в обычных и необычных условиях?
  • Как приложение ведет себя, если пытаются залогиниться множество пользователей одновременно?
  • Как приложение переносит очень большую («стрессовую») нагрузку?
  • Насколько приложением безопасно пользоваться?
  • Как приложение восстанавливается после сбоев? 
  • Как приложение ведет себя в разных окружениях и в разных операционных системах?
  • Легко ли портировать приложение на другую систему?
  • Есть ли у приложения документация пользователя, она удобная?

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

Цели

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

Преимущества

  • Решает проблемы, не относящиеся к основной функциональности, но тоже очень важные
  • Гарантирует, что приложение/сайт будет удобным, приятным и надежным
  • Безопасность пользователей

Как получить нефункциональные требования

Нефункциональные требования получают из таких документов:

  • User Story / Technical story. Их получают таким же образом, как и другие требования. Разница между user и technical в том, что составление user story требует обсуждения с пользователями и является как бы более прозрачным и контролируемым процессом.
  • Критерии приемки. Показатели, определяющие, приемлем ли продукт для конечного пользователя. Нефункциональные критерии должны включаться в состав, однако собрать их обычно сложнее, поэтому с ними работают на определенных этапах.
  • Артефакты: тест-планы, кейсы, чеклисты и спецификации.

Разница между функциональными и нефункциональными требованиями

ФункциональныеНефункциональные
Основываются на нуждах и требованиях пользователей (customer-based)Основываются на скиллах разработчиков и техническом уровне команды
Описывают, какая функциональность должна быть оценена, какие функции должны быть протестированыОписывают, как должно выглядеть приложение, насколько удобным/надежным должно быть
Тестирование функционала делается перед тем как приложение (сайт) входит в эксплуатациюВключают требования к maintenance-тестированию и тестированию документации, релевантные после ввода в эксплуатацию
«Требования по функционалу»«Требования по качеству»
План имплементации функциональных требований описывается в документе по дизайну системыПлан имплементации нефункциональных требований описывается в документе по архитектуре системы
Четкие показатели технической пригодности системыИногда субъективные показатели типа безопасности, юзабельности и подобные

К какому «ящику» относится?

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

Чек-лист нефункционального тестирования

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

Чек-лист тестирования производительности 

  • Время отклика (response time) приложения/сайта; сколько времени уходит на загрузку приложения/страницы, также, сколько времени уходит на реакцию приложения на ввод, обновление браузера и т.п.
  • Пропускная способность (throutput), количество проведенных транзакций во время нагрузочного тестирования
  • Окружение. Оно должно быть как можно ближе к реальному, или результаты не будут достоверны
  • Время обработки. Импорт-экспорт документов в приложении, скорость вычислений
  • Совместимость. Как приложение работает в связке с другими системами
  • ETL-операции. Время, потраченное на Извлечение-Преобразование-Загрузку (ETL) данных из одной базы в другую
  • Увеличение нагрузки — как приложение ведет себя в таких условиях

Чек-лист тестирования безопасности

  • Аутентификация. Только аутентифицированным пользователям должен предоставляться доступ
  • Авторизация. Пользователь должен иметь возможность логиниться только в те модули, к которым ему разрешен доступ
  • Пароль. Должна быть проверена «сила» пароля, то есть его длина, специальные символы, цифры и т.п.
  • Таймаут, при неактивности приложения какое-то время оно должно быть безопасно закрыто
  • Резервное копирование в защищенное хранилище в определенные промежутки
  • Внутренние ссылки в веб-приложении не должны быть доступны извне
  • И конечно вся коммуникация должна быть зашифрована

Чек-лист тестирования документации

  • Документация пользователя и документация системы
  • Документация для обучения

Документ подхода к тестированию (Approach Document)

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

Объем тестирования (Test Scope)

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

Метрики

Числовые показатели например таких характеристик:

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

Инструменты

  • Инструменты генерирования нагрузки
  • Мониторинга производительности
  • Анализа производительности
  • Профилирования приложения
  • Инструменты base-lining, то есть контроля «базовой линии»

Ключевые даты и целевые показатели

Approach-документ должен также включать следующее:

  • Дата и время каждого теста производительности
  • Типы тестов и проверяемые функции
  • Дата завершения этого этапа

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

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

Общая оценка производительности/продуктивности системы.

  • Система в целом имеет ожидаемое время отклика
  • Самые важные элементы приложения имеют нужное время отклика
  • Может проводиться как часть интеграционного и/или системного тестирования

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

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

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

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

Оценка производительности системы при «стрессовых» условиях

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

Подробнее — отдельный гайд.

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

Поведение системы при подаче в нее очень большого объема данных. 

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

Юзабилити-тестирование

Оценка, удобна ли система людям, легко ли в ней работать

  • Является ли вывод системы корректным и понятным
  • Ошибки диагностируются правильно?
  • Как выглядит GUI и как он реагирует на действия пользователя
  • Отвечает ли стандартам (гайдам) в этой сфере
  • Удобно ли работать в приложении

Подробнее — гайд

Тестирование пользовательского интерфейса

То есть графического интерфейса пользователя (GUI).

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

Подробный гайд по GUI-тестированию.

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

Оценка совместимости приложения с другими аппаратными/программными продуктами

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

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

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

  • Отключения электричества у клиента во время стандартных CRUD-операций
  • Невалидные указатели в базах данных и/или ключи
  • Умышленно поврежденные указатели, поля и ключи в базе
  • Физически поврежденное подключение, грубое отключение роутера или сервера

Тестирование установки и удаления

Проверяют, что софт корректно устанавливается и удаляется. 

  • Все компоненты системы устанавливаются корректно на оборудовании (девайсе)
  • Обновление («накат» новой версии) происходит без ошибок
  • При недостаточности места на диске не будет некорректного поведения.

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

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

  • Нужные документы корректны и доступны 
  • Руководства пользователя, инструкции по установке и настройке, readme-файлы, комментарии к релизам, и онлайн-help

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

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

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

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

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

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

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

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

Тестирование выносливости

Проверка поведения системы при повышении нагрузки, которое продолжается длительное время. Проверяется, не возникают ли, например, утечки памяти при такой ситуации. В англоязычной литературе для такого тестирования существуют взаимозаменяемые термины Endurance-, Soak- и Capacity-testing. 

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

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

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

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

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

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

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

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

Тестирование базовой линии

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

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

Тестирование эффективности

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

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

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

Тестирование удобства сопровождения

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

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

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

***

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

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

Какой была ваша первая зарплата в QA и как вы искали первую работу?

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

Подписаться
Уведомить о
guest

0 комментариев
Межтекстовые Отзывы
Посмотреть все комментарии

Мы в Telegram

Наш официальный канал
Полезные материалы и тесты
Готовимся к собеседованию
Project- и Product-менеджмент

🔥 Популярное

💬 Telegram-обсуждения

Наши подписчики обсуждают, как искали первую работу в QA. Некоторые ищут ее прямо сейчас.
Наши подписчики рассказывают о том, как не бояться задавать тупые вопросы и чувствовать себя уверенно в новой команде.
Обсуждаем, куда лучше податься - в менеджмент или по технической ветке?
Говорим о конфликтных ситуациях в команде и о том, как их избежать
$1100*
медианная зарплата в QA в июне 2023

*по результатам опроса QA-инженеров в нашем телеграм-канале

Собеседование

19%*
IT-специалистов переехало или приняло решение о переезде из России по состоянию на конец марта 2022

*по результатам опроса в нашем телеграм-канале

live

Обсуждают сейчас