Основные концепции тестирования

Все темы QA

Что такое тестирование?

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

Зачем тестировать ПО?

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

Какие существуют этапы тестирования?

Этапы тестирования ПО обычно включают:

1. Планирование тестирования: определение целей, стратегии и методов тестирования.

2. Дизайн тестов: разработка тестовых случаев и сценариев на основе требований.

3. Исполнение тестов: запуск тестовых случаев и сбор результатов.

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

5. Отчетность: документирование результатов тестирования и выявленных ошибок.

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

Какие типы тестирования можете назвать?

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

1. Модульное тестирование ( Unit testing ): Проверка отдельных модулей или компонентов программы на корректность их работы.

2. Интеграционное тестирование ( Integration testing ): Проверка взаимодействия между различными модулями или компонентами программы.

3. Системное тестирование ( System testing ): Проверка всей системы как единого целого для подтверждения соответствия требованиям.

4. Приемочное тестирование ( Acceptance testing ): Проверка программы на соответствие требованиям заказчика перед ее принятием.

5. Регрессионное тестирование ( Regression testing ): Повторное выполнение тестов для обнаружения новых ошибок после внесения изменений в программное обеспечение.

6. Нагрузочное тестирование ( Load testing ): Оценка производительности программы при определенной нагрузке.

7. Стресс-тестирование ( Stress testing ): Оценка стабильности программы при высоких нагрузках или необычных условиях.

8. Смоук-тестирование ( Smoke testing ): Первичное быстрое тестирование для проверки базовой функциональности после внесения изменений.

Какие уровни тестирования знаете?

Уровни тестирования программного обеспечения включают:

1. Модульное тестирование: Проверка отдельных модулей или функций программы.

2. Интеграционное тестирование: Проверка взаимодействия между модулями или компонентами.

3. Системное тестирование: Проверка работы всей системы как единого целого.

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

Какие техники тест-дизайна знаете?

Некоторые техники тест-дизайна включают:

1. Эквивалентное разбиение: Разделение данных на классы эквивалентности для тестирования.

2. Граничное значение: Тестирование значений вблизи границ допустимых диапазонов.

3. Парное тестирование ( Pairwise Testing ): Создание комбинаций параметров для проверки взаимодействия между ними.

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

5. Тестирование пути ( Path Testing ): Тестирование различных путей выполнения программы.

6. Тестирование интерфейсов: Проверка взаимодействия между компонентами программного обеспечения.

Что такое техника анализа классов эквивалентности?

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

Что такое техника анализа предельных значений? В чем ценность этой техники?

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

Что такое Regression и Confirmation тестирование, какая между ними разница?

Regression testing и Confirmation testing являются видами тестирования программного обеспечения, которые выполняются в различных контекстах и имеют разные цели:

1. Regression testing (регрессионное тестирование):

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

   • Процесс: Запуск тестов, которые проверяют работу существующих функций и аспектов системы после внесенных изменений.

2. Confirmation testing (конфирмационное тестирование):

   • Цель: подтвердить, что конкретный ранее обнаруженный дефект исправлен.

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

Разница:

• Основное различие между ними заключается в целях и областях применения:

  • Регрессионное тестирование фокусируется на общей проверке старого и нового кода после внесенных изменений.

  • Конфирмационное тестирование сосредотачивается на проверке конкретного исправления или функции после его внесения.

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

Как построить таблицу решений для тестов?

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

Как тестировать переходы между состояниями?

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

Как обеспечить независимость тестов?

Каждый тест должен создавать собственные данные и не зависеть от порядка запуска. Общие пользователи, файлы, очереди и порты получают уникальный namespace; внешние зависимости заменяют контролируемыми моками или одноразовыми контейнерами там, где это соответствует уровню проверки. Cleanup выполняют независимо от исхода теста, но лучше начинать из известного чистого состояния, а не надеяться только на уборку. Набор запускают в случайном порядке и параллельно: изменение результата указывает на утечку состояния. Глобальные часы, кэш и singleton тоже считаются общим состоянием и требуют контроля.

Когда BDD становится неэффективным?

BDD теряет смысл, если сценарии пишет один автоматизатор после реализации, а продукт, разработка и QA не обсуждают примеры вместе. Технические шаги вроде кликов и селекторов превращают feature-файлы в дорогую копию тестового кода. Дублирующиеся сценарии, длинные background и попытка описать каждую деталь повышают стоимость поддержки без нового знания. BDD полезен для спорных бизнес-правил и общего языка. Для простого CRUD, алгоритма или низкоуровневой проверки лучше могут подойти unit-тест, таблица решений или обычная спецификация. Эффективность оценивают по устранённым недопониманиям, а не числу сценариев Gherkin.

Когда pairwise-тестирование неприменимо?

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

Как применять прогнозирование ошибок?

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