# Другие виды тестирования **Ad-hoc тестирование (интуитивное тестирование)** Само название говорит о том, что это тестирование проводится неформально, то есть без привязки к тест-кейсам, а также без какого-либо плана или документации для этого вида тестирования. Цель такого тестирования – найти дефекты и сломать приложение, выполнив любой сценарий приложения или используя произвольную функциональность. Ad-hoc тестирование – это неформальный способ поиска дефектов, который может быть выполнен любым участником проекта. Сложно выявить дефекты без тест-кейсов, но иногда в ходе этого тестирования обнаруживаются дефекты, которые не покрываются существующими тест-кейсами. **Бэкенд тестирование** При вводе данных через интерфейс приложения они сохраняются в базе данных, при этом тестирование так и называется тестированием базы данных или бэкенд-тестированием. Существуют различные базы данных, такие как SQL Server, MySQL, Oracle и т.д. Тестирование базы данных включает в себя тестирование структуры таблиц, схем, хранимых процедур, структур данных и так далее. При бэкэнд-тестировании графический интерфейс не задействован, тестировщики напрямую подключены к базе данных с соответствующим доступом, и они могут легко проверить данные, выполнив несколько запросов. Во время тестирования бэкэнда могут быть выявлены такие проблемы, как потеря данных, взаимная блокировка, повреждение данных и т.д., и эти проблемы очень важно устранить до того, как система будет запущена на production. **Тестирование совместимости браузеров** Это подтип тестирования на совместимость (которое описано ниже), и выполняется командой тестирования. Тестирование на совместимость с браузерами проводится для веб-приложений и гарантирует, что ПО может работать в различных браузерах и операционных системах. Этот тип тестирования также проверяет, работает ли веб-приложение на всех версиях всех браузеров или нет. **Тестирование на обратную совместимость** Это вид тестирования, который проверяет, работает ли вновь разработанное или обновленное ПО с более старой своей версией или нет. Тестирование на обратную совместимость проверяет, работает ли новая версия ПО с форматом файлов, созданных более старой версией ПО: также ли оно хорошо работает с таблицами данных, файлами и структурами данных, созданными более старой версией этого ПО. Если какое-либо ПО обновлено, то оно должно хорошо работать поверх своей предыдущей версии. **Тестирование граничных значений** Этот метод тестирования проверяет поведение приложения при определенных входных данных. Тестирование граничных значений проводится для проверки наличия дефектов при вводе граничных значениях. Тестирование граничных значений используется для тестирования различных диапазонов чисел. Для каждого диапазона существует верхняя и нижняя граница, и тестирование проводится на этих граничных значениях. Если для тестирования требуется диапазон чисел от 1 до 500, то тестирование граничных значений выполняется на значениях 0, 1, 2, 499, 500 и 501. **Тестирование ветвей** Это тестирование также известно как тестирование покрытия ветвей или тестирование покрытия решений. Это вид тестирования “белого ящика”, выполняемый на уровне модульных тестов. Оно проводится для того, чтобы убедиться, что каждый возможный путь от точки принятия решения выполняется хотя бы один раз для 100% покрытия теста. **Пример:** ``` Read number A, B If (A>B) then Print(“A is greater”) Else Print(“B is greater”) ``` Здесь есть две ветви, одна для if, а другая для else. Для 100% покрытия нам нужны 2 тестовых случая с разными значениями A и B. ``` Test case 1: A=10, B=5 It will cover the if branch. Test case 2: A=7, B=15 It will cover the else branch. ``` **Сравнительное тестирование** Сравнение сильных и слабых сторон продукта с его предыдущими версиями или другими аналогичными продуктами называется сравнительным тестированием. **Эквивалентное разделение** Это метод тестирования и разновидность тестирования “черного ящика”. Во время этого тестирования выбирается набор групп и несколько значений или чисел для тестирования. Подразумевается, что все значения из этой группы генерируют один и тот же результат. Целью такого тестирования является удаление избыточных тест-кейсов в пределах определенной группы, которые генерируют одинаковые выходные данные, но не приводят к каким-либо дефектам. Предположим, что приложение принимает значения от -10 до +10, тогда, используя разделение по эквивалентности, для тестирования будут выбраны нулевое, одно положительное и одно отрицательное значения. Таким образом, эквивалентное разбиение для этого тестирования – это от -10 до -1, 0 и от 1 до 10. **Тестирование на основе опыта (предугадывание ошибок)** Предугадывание ошибок – это метод тестирования в режиме реального времени. Оно включает в себя сценарии, основанные на опыте тестировщиков. Этот вид тестирования также известен как тестирование на основе опыта, поскольку он использует знания QA о том, как приложение работало в прошлом, как сломать приложение, какие дефекты часто встречаются в приложениях данного типа. **Тестирование графического интерфейса пользователя** Целью данного тестирования является проверка графического интерфейса пользователя (GUI) в соответствии с бизнес-требованиями. Ожидаемый графический интерфейс приложения указан в документе детального проектирования и макетах экранов графического интерфейса. Тестирование GUI включает в себя проверку размеров кнопок и полей ввода, присутствующих на экране, выравнивание всего текста, таблиц и содержимого в таблицах. Также проверяется меню приложения. После выбора различных меню и пунктов меню проверяется, что страница не изменяет размеры, а выравнивание остается неизменным после наведения курсора мыши на меню или подменю. **Инкрементное интеграционное тестирование** Инкрементное интеграционное тестирование – это подход к тестированию “снизу вверх”, то есть непрерывное тестирование приложения при добавлении новой функциональности. Функциональности приложения и модули должны быть достаточно независимыми, чтобы их можно было тестировать отдельно. Это делается разработчиками или тестировщиками. **Тестирование инсталляции/деинсталляции** Тестирование инсталляции проводится для проверки того, что программное приложение установлено правильно и работает в соответствии с ожиданиями. Тестирование инсталляции – это фаза тестирования, предшествующая первому взаимодействию пользователей с реальным приложением. Тестирование инсталляции также называется “тестированием внедрения”. Тестирование деинсталляции проводится для подтверждения того, что все компоненты или элементы ПО корректно удаляются из системы. Такой вид тестирование может проверять полную, частичную или обновленную инсталляцию/деинсталляцию на различных операционных системах в различных аппаратных или программных средах. **Мутационное тестирование** Мутационное тестирование – это вид тестирования “белого ящика”, при котором изменяется исходный код ПО и проверяется, могут ли существующие тест-кейсы выявить эти дефекты в системе. Изменения в исходном коде программы очень минимальны, поэтому они влияют не на все приложение, а только на конкретную область, на которую оказывается воздействие, и соответствующие тест-кейсы должны быть способны выявить эти ошибки в системе. **Негативное тестирование** Идея тестировщика для некоторых проверок заключается в том, чтобы “сломать систему/приложение”, и это достигается с помощью негативного тестирования. Техники негативного тестирования выполняются с использованием некорректных входных данных. Проверяется, валидирует ли система ошибку недопустимого ввода и ведет ли она себя так, как ожидается. **Тестирование восстановления** Это вид тестирования, который проверяет, насколько хорошо приложение или система восстанавливается после сбоев или аварий. Тестирование восстановления определяет, сможет ли система продолжить работу после сбоев. Предположим, что приложение получает данные через сетевой кабель и вдруг этот сетевой кабель был отключен. Через некоторое время содинение с сетевым кабелем восстанавливают; тогда система должна начать получать данные с того места, где она потеряла соединение из-за отключения сетевого кабеля. **Тестирование на основе рисков** При тестировании на основе рисков функциональные возможности или требования тестируются на основе их приоритетности. Тестирование на основе риска включает в себя тестирование высококритичных функциональностей, которые имеют наибольшее влияние на бизнес-показатели и в которых вероятность отказа очень высока. Решения о приоритете основываются на потребностях бизнеса, поэтому сначала выполняется тестирование высокоприоритетных функциональных возможностей, а затем тестирование функциональностей среднего и низкого приоритета. Функциональность с низким приоритетом может быть протестирована или не протестирована в зависимости от имеющегося времени. Тестирование с учетом риска проводится, если не хватает времени для тестирования всех областей ПО, когда оно должно быть внедрено в срок без каких-либо задержек. Этот подход применяется только после обсуждения и одобрения клиента и руководства организации. **Статическое тестирование** Статическое тестирование – это вид тестирования, который проводится без выполнения какого-либо кода. Обзоры, ревью и аудиты – это различные методы проведения статического тестирования. Под статическим тестированием понимаются такие действия, как просмотр документов с требованиями, спецификации требований заказчика, высокоуровневого и низкоуровневого дизайна, синтаксиса кода, стандартов именования и т. д. Статическое тестирование также проводится для тест-кейсов, планов тестирования, тестовых сценариев. Оно проводится для как можно раннего предотвращения дефектов на начальных стадиях. Именно поэтому статическое тестирование является экономически эффективным. Например, QA тестирует сайт страхования домашних животных. Логика расчета его стоимости описана в документации с требованиями. В рамках статического тестирования QA могут просмотреть код разработчика для расчета стоимости страхования и сравнить его с требованиями, чтобы предотвратить потенциальный дефект, связанный с этими расчетами. **Тестирование уязвимостей** Тестирование, которое включает в себя выявление слабых мест в ПО, оборудовании и сети, известно как тестирование на уязвимость. В вредоносных программах хакер может получить контроль над системой, если она уязвима к таким видам атак, вирусам и червям. Необходимо проверить, проходят ли эти системы тестирование на уязвимость перед производством. Оно может выявить критические дефекты и недостатки в системе безопасности. --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://qabook.gitbook.io/start/teoriya-testirovaniya/osnovy-testirovaniya/vidy-testirovaniya/drugie-vidy-testirovaniya.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.