16/05/2022

Виды тестирования по целям и задачам

Виды тестирования по целям и задачам

Классификация

  • Функциональное(«Что?» - проверяет весь функционал продукта)

    • Тестирование данных
    • Приемочное тестирование
    • Операционное тестирование
    • Тестирование пользовательского интерфейса (GUI Testing)
  • Нефункциональное(«Как?»)

    • Тестирование производительности
    • Нагрузочное тестирование
    • Стрессовое тестирование
    • Тестирование масштабируемости
    • Объемное тестирование
    • Тестирование надежности
    • Тестирование восстанавливаемости
    • Тестирование отказоустойчивости
    • Тестирование безопасности
    • Тестирование удобства использования
    • Тестирование доступности -
    • Тестирование совместимости
    • Тестирование интернационализации
    • Тестирование локализации
    • Инсталяционное (тестирование установки)
    • Конфигурационное тестирование -
    • Конкурентное тестирование -
    • Тестирование использоваиня ресурсов -
    • Сравнительное тестирование -
  • Связанные с изменениями

    • Дымовое
    • Регрессионное
    • Тестирвание сборки
    • Санитарное тестирование
    • Повторное тестирование

Функциональное тестирование (Functional/Behavioral testing)

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

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

Часто возникает вопрос, в чём разница между функциональным тестированием (functional testing) и тестированием функциональности (functionality testing).

Если вкратце, то:

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

Для функционального тестирования принято использовать две техники:

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

Основные виды функционального тестирования:

  • Юнит тестирование (Unit Testing)
  • Дымовое тестирование (Smoke Testing)
  • Санитарное тестирование (Sanity Testing)
  • Интеграционное тестирование (Integration Tests),
  • Бета тестирование (Beta Testing)
  • Системное тестирование (System testing)
  • End to end testing
  • Тестирование пользовательского интерфейса (GUI Testing)

Регрессионное тестирование (Regression testing)

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

Фредерик Брукс в своей книге «Мифический человеко-месяц» писал: «Фундаментальная проблема при сопровождении программ состоит в том, что исправление одной ошибки с большой вероятностью (20–50 %) влечёт появление новой». Потому регрессионное тестирование является неотъемлемым инструментом обеспечения качества и активно используется практически в любом проекте.

Повторное тестирование (Re-testing, confirmation testing)

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

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

Приёмочное тестирование (Acceptance testing)

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

Можно выделить следующие подвиды приёмочного тестирования (хотя упоминают их крайне редко, ограничиваясь в основном общим термином «приёмочное тестирование»):

  • Производственное приёмочное тестирование (Factory acceptance testing)
    Выполняемое проектной командой исследование полноты и качества реализации приложения с точки зрения его готовности к передаче заказчику. Этот вид тестирования часто рассматривается как синоним альфа-тестирования.

  • Операционное приёмочное тестирование (Operational acceptance testing, production acceptance testing) Операционное тестирование, выполняемое с точки зрения выполнения инсталляции, потребления приложением ресурсов, совместимости с про- граммной и аппаратной платформой и т. д.

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

Операционное тестирование (Operational testing)

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

Тестирование интерфейса (Interface testing)

Тестирование, направленное на проверку интерфейсов приложения или его компонентов.

По определению ISTQB-глоссария этот вид тестирования относится к интеграционному тестированию, и это вполне справедливо для таких его вариаций как тестирование интерфейса прикладного программирования (API testing182) и интерфейса командной строки (CLI testing), хотя последнее может выступать и как разновидность тестирования пользовательского интерфейса, если через командную строку с приложением взаимодействует пользователь, а не другое приложение. Однако многие источники предлагают включить в состав тестирования интерфейса и тестирование непосредственно интерфейса пользователя (GUI testing).

Нефункциональное тестирование (Non-Functional testing)

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

В большинстве случаев это выполняется методом black box testing. Оно проверяет, соответствует ли поведение системы требованиям по всем аспектам, не охваченные функциональным тестированием.

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

Нефункциональные требования могут быть отражены как:

  • Пользовательские / Технические истории (User /Technical Stories): запись нефункциональных требований в виде пользовательской истории такая же, как и запись любых других требований. Единственная разница между пользователем и технической историей заключается в том, что пользовательская история требует обсуждения и имеет видимость (? visibility);
  • В критериях приемки (Acceptance criteria): это точка, которая определяется для принятия продукта заказчиком. Нефункциональное требование должно быть включено в критерии приемки, но иногда невозможно проверить нефункциональные требования с каждой историей, то есть с каждой итерацией. Следовательно, требования следует добавлять или тестировать только с соответствующей итерацией;
  • В артефактах (Artifact): для нефункциональных требований следует подготовить отдельный артефакт, это, в свою очередь, поможет лучше понять, что нужно тестировать и как это можно делать в итерациях;

Инсталляционное тестирование (Installation testing, Installability testing)

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

В общем случае такое тестирование проверяет множество сценариев и аспектов работы инсталлятора в таких ситуациях, как:

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

Тестирование удобства использования (Usability testing)

Тестирование, направленное на исследование того, насколько конечному пользователю понятно, как работать с продуктом (understandability, learnability, operability), а также на то, насколько ему нравится использовать продукт (attractiveness). И это не оговорка — очень часто успех продукта зависит именно от эмоций, которые он вызывает у пользователей.

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

Тестирование удобства использования (usability testing) и тестирование интерфейса пользователя (GUI testing) — не одно и то же! Например, корректно работающий интерфейс может быть неудобным, а удобный может работать некорректно.

Тестирование доступности (Accessibility testing)

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

Тестирование безопасности (Security testing)

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

Проверяется:

  • Аутентификация (Authentication): только достоверный пользователь может войти в систему;
  • Авторизация (Authorized): пользователь должен иметь возможность входить в те модули, для которых он авторизован или к которым пользователю был предоставлен доступ;
  • Пароль: Требование пароля должно быть подтверждено, т.е. пароль должен соответствовать тому, как это требование определяется, то есть длине, специальным символам, числам и т. д.;
  • Тайм-аут: если приложение неактивно, оно должно истечь по таймауту в указанное время;
  • Резервное копирование данных: резервное копирование данных должно быть выполнено в указанное время и данные должны быть скопированы в безопасное место;
  • Внутренние ссылки на веб-приложение не должны быть доступны, если размещены непосредственно в браузере;
  • Вся коммуникация должна быть зашифрована;

Тестирование интернационализации (Internationalization testing, I18n testing, Globalization testing, Localizability testing)

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

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

Тестирование локализации (Localization testing, L10n)

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

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

Тестирование совместимости (Compatibility testing, Interoperability testing)

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

Здесь, например, может проверяться:

  • Совместимость с аппаратной платформой, операционной системой и сетевой инфраструктурой (конфигурационное тестирование, configuration testing).
  • Совместимость с браузерами и их версиями (кросс-браузерное тестирование, cross-browser testing).
  • Совместимость с мобильными устройствами (mobile testing).
  • И так далее.

В некоторых источниках к тестированию совместимости добавляют (хоть и подчёркивая, что это — не его часть) т.н. тестирование соответствия (compliance testing, conformance testing, regulation testing).

Тестирование данных (Data quality testing) и баз данных (Database integrity testing)

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

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

Тестирование использования ресурсов (Resource utilization testing, Efficiency testing, Storage testing)

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

Сравнительное тестирование (Comparison testing)

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

Демонстрационное тестирование (Qualification testing)

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

Избыточное тестирование (Exhaustive testing)

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

Тестирование надёжности (Reliability testing)

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

Тестирование восстанавливаемости (Recoverability testing)

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

Тестирование отказоустойчивости (Failover testing)

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

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

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

Проверяется:

  • Время отклика (The response time) приложения, то есть сколько времени требуется для загрузки приложения, за какое время любой ввод, предоставленный приложению, обеспечивает вывод, время обновления браузера и т. д.;
  • Пропускную способность (Throughput) следует проверять по количеству транзакций, завершенных во время нагрузочного теста;
  • Настройка среды (Environment) должна быть такой же, как и в реальной среде, иначе результаты не будут такими же;
  • Время процесса (Process time) - такие действия, как импорт и экспорт Excel, любые вычисления в приложении должны быть протестированы;
  • Совместимость (Interoperability) должна быть проверена, т.е. программное обеспечение должно иметь возможность взаимодействовать с другим программным обеспечением или системами;
  • Необходимо проверить время ETL, то есть время, затраченное на извлечение, преобразование и загрузку данных из одной базы данных в другую;
  • Необходимо проверить возрастающую нагрузку (Load) на приложение;

В рамках тестирования производительности выделяют следующие подвиды:

  • Нагрузочное тестирование (Load testing, Capacity testing) Исследование способности приложения сохранять заданные показатели качества при нагрузке в допустимых пределах и некотором превышении этих пределов (определение «запаса прочности»).

  • Тестирование масштабируемости (Scalability testing) Исследование способности приложения увеличивать показатели производительности в соответствии с увеличением количества доступных приложению ресурсов.

  • Объёмное тестирование (Volume testing) Исследование производительности приложения при обработке различных (как правило, больших) объёмов данных.

  • Стрессовое тестирование (Stress testing) Исследование поведения приложения при нештатных изменениях нагрузки, значительно превышающих расчётный уровень, или в ситуациях недоступности значительной части необходимых приложению ресурсов. Стрессовое тестирование может выполняться и вне контекста нагрузочного тестирования: тогда оно, как правило, называется «тестированием на разрушение» (destructive testing) и представляет собой крайнюю форму негативного тестирования.

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

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

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