Дизайн тест-кейсов представляет собой процесс создания документов, описывающих, как именно будет проводиться тестирование. Эти документы служат основой для проверки функциональности, производительности и безопасности программного обеспечения. Правильный подход к проектированию тест-кейсов позволяет обеспечить максимальное тестовое покрытие и выявить потенциальные проблемы на ранних этапах разработки, что в конечном итоге снижает затраты на исправление ошибок и ускоряет время выхода продукта на рынок
Содержание:
- Что такое тест-кейсы?
- Различные типы тестов
- Различные методы создания тест-кейсов
- Как планировать и проектировать тест-кейсы?
- Лучшие практики для проектирования тест-кейсов
- Почему тест-кейсы важны для создания качественного ПО?
Что такое тест-кейсы?
Тест-кейс — это документ, который готовят специалисты по контролю качества (QA). Он определяет стратегию тестирования и покрытие тестами, а также содержит такие детали, как предварительные условия, шаги тестирования, постусловия и ожидаемые результаты. В документе также описываются различные переменные, которые используются командой для сравнения ожидаемых и фактических результатов, чтобы определить, соответствует ли продукт требованиям. Основная цель — обеспечить максимальное покрытие тестирования, чтобы выявить возможные дефекты и ошибки в программном обеспечении и устранить их.
Друзья, поддержите нас вступлением в наш телеграм канал QaRocks. Там много туториалов, задач по автоматизации и книг по QA.
Различные типы тестов
Прежде чем понять, как разрабатывать тест-кейс, важно знать разные типы тестов, которые проводятся для оценки работы программного обеспечения. Тесты делятся на формальные и неформальные.
Во-первых, в формальных тестах предварительные условия и данные для тестирования четко определены. Эти тесты проверяют, совпадает ли результат с ожидаемым. В свою очередь, неформальные тесты не имеют таких условий или заранее известных данных. Нет известных входных данных, а значит, и результат остается неизвестным. Инженеры по качеству (QA) узнают результат по мере тестирования.
Ниже приведены несколько распространённых типов тестов, которые проводят специалисты QA при тестировании программного обеспечения.
Интеграционные тесты
Интеграционные тесты проверяют, могут ли различные системы эффективно взаимодействовать друг с другом и правильно ли они работают в составе приложения.
Тесты на проверку пользовательского интерфейса (UI)
Тесты UI помогают определить, функционирует ли интерфейс так, как ожидается. Эти тесты сосредоточены на визуальных элементах веб- и мобильных приложений. Цель — выяснить, доступен ли интерфейс пользователю. Например, команда QA может проверить, правильно ли отображаются изображения или меню на разных устройствах, таких как ноутбуки и мобильные телефоны. Также такие тесты выявляют косметические несоответствия, грамматические или орфографические ошибки.
Юзабилити тесты (тестирование удобства использования)
Тестирование юзабилити может быть как формальным, так и неформальным, в зависимости от метода, который используется. Его цель — понять, как конечный пользователь взаимодействует с программным обеспечением. Оно помогает определить, может ли пользователь легко пользоваться системой и выполнять нужные действия. Это тестирование выявляет проблемы, мешающие пользователю использовать программу.
Тесты на производительность
Тесты производительности помогают инженерам QA оценить, как система работает в разных условиях, таких как стресс, нагрузка, всплески активности и масштабируемость. Каждое такое тестирование показывает, как система поведет себя в реальных условиях. Например, тест измеряет максимальное количество пользователей, которых система может поддерживать до сбоя.
Тесты на безопасность
Тесты безопасности выявляют уязвимости системы и проверяют, может ли она защитить данные и другие активы от угроз и рисков. Различные тесты, такие как тестирование на проникновение и уязвимости, помогают инженерам QA найти и устранить проблемы до того, как система выйдет в эксплуатацию.
Тесты на проверку работы базы данных
Тестирование работы базы данных проверяет, хранит ли база данных данные в соответствии с законами о защите данных, такими как GDPR (общий регламент по защите персональных данных), и отраслевыми стандартами. Оно также помогает проверить важные аспекты, такие как несанкционированный доступ к базе данных.
Тесты на проверку функциональности ПО
Тесты на проверку функциональности оценивают, выполняет ли система заданные действия, как ожидалось. Например, инженеры QA могут проверить, позволяет ли функция входа пользователю успешно войти в систему.
Различные методы создания тест-кейсов
Техники проектирования тест-кейсов помогают инженерам QA создавать более эффективные тесты, уменьшать количество выполняемых тестов и повышать покрытие тестирования.
Техники, основанные на спецификациях (Black Box Techniques)
Эти методы проектируются на основе внешних характеристик программного обеспечения, таких как технические требования или проект системы. Ниже приведены основные категории этих техник:
- Анализ граничных значений (Boundary value analysis, BVA)
Этот метод помогает выявить ошибки на границах допустимых значений ввода. Он основывается на принципе, что если система корректно работает с определенными граничными значениями, она будет работать с любыми значениями между ними.
- Эквивалентное разбиение (Equivalence partitioning, EP)
В этой технике входные данные разделяются на несколько классов, и тест-кейсы создаются для каждого класса, чтобы обеспечить равное тестирование всех классов данных.
- Тестирование по таблице решений (Decision table testing)
Этот метод, также известный как таблица причин и следствий, предполагает создание таблицы всех возможных входных данных и соответствующих им выходных параметров. Это помогает удостовериться, что различные функции системы корректно реагируют на комбинации входных данных и событий.
- Диаграммы перехода состояний (State transition diagrams)
По сути, этот метод тестирования позволяет инженерам по качеству (QA) проверять поведение тестируемого приложения (AUT). Инженер использует различные условия ввода в определенной последовательности, чтобы определить, изменяет ли это состояние тестируемого приложения. Этот тест-кейс особенно полезен для систем с определённым рабочим процессом. Например, этот подход предложит пользователю повторно ввести PIN-код, если он ввёл его неправильно с 1-й или 2-й попытки. На 3-й попытке система может либо предоставить доступ, либо заблокировать учетную запись, в зависимости от того, правильно или неправильно введен PIN-код.
- Тестирование по сценариям использования (Use case testing)
В этом виде тестирования инженер выполняет различные бизнес-сценарии и пользовательские функции, чтобы создать тест-кейс, охватывающий всю систему.
Техники, основанные на структуре кода (White Box Techniques)
Эти виды тест-кейсов сосредоточены на внутренней структуре программного обеспечения. Разработчики тестируют каждый модуль и детали кода приложения при создании тест-кейсов. Ниже приведены категории структурных техник:
- Тестирование покрытия операторов
В этой технике выполняются все исполняемые операторы исходного кода. Это помогает вычислить количество выполненных операторов из общего числа операторов в исходном коде.
- Тестирование покрытия решений
В этой технике выполняется как минимум одна из ветвей в каждой точке принятия решения, чтобы определить, приводит ли это к неожиданному поведению приложения.
- Тестирование условий
Тестирование условий проверяет все условия в исходном коде, чтобы убедиться в отсутствии ошибок.
- Тестирование нескольких условий
В тестировании нескольких условий проверяются различные комбинации условий одновременно для обеспечения 100% покрытия тестирования.
- Тестирование всех путей
Тестирование всех путей помогает выявить все возможные исполняемые пути и ошибки в конкретном коде с использованием исходного кода.
Техники, основанные на опыте
По сути, эта техника в основном опирается на опыт команды QA. Результат тестирования зависит от навыков, интуиции и опыта тестировщиков. Ниже приведены категории техник, основанных на опыте:
- Предугадывание ошибок
В предугадывании ошибок инженеры прогнозируют возможные ошибки, полагаясь на свой опыт, навыки, интуицию и доступные данные.
- Исследовательское тестирование
Исследовательское тестирование проводится без предварительной документации, в основном из-за нехватки времени. Процесс создания тест-кейсов и их выполнение происходят одновременно.
Как планировать и проектировать тест-кейсы?
1. Подготовка тестовой среды
Для запуска тестов инженеры QA должны подготовить тестовую среду. Это включает установку необходимого программного обеспечения, такого как генераторы тестовых данных, отладчики, эмуляторы, симуляторы, заглушки и драйверы. Также требуется аппаратное обеспечение для проведения тестов. QA-инженеры регулярно документируют спецификации оборудования и версии программного обеспечения, чтобы иметь записи для повторного использования в будущем.
2. Определение объема тест-кейсов
Проектирование тест-кейсов начинается с определения объема тестирования. Заказчики предоставляют требования, на основе которых будет проводиться тестирование. Эти требования могут включать в себя спецификации дизайна, кейсы использования, юзабилити и другие аспекты программного обеспечения. Эти требования служат основой для создания тест-кейсов.
3. Проектирование тест-кейсов
После определения объема и подготовки тестовой среды инженеры QA выбирают стратегию для проектирования тестов. Они начинают создавать тест-кейсы для каждого требования к программному обеспечению, чтобы удостовериться, что оно соответствует всем спецификациям.
Тест-кейсы должны охватывать как положительные, так и отрицательные сценарии. Это помогает проверить, что программное обеспечение функционирует корректно как при нормальных, так и при нестандартных условиях. Документ с тест-кейсами должен быть максимально детализированным и может включать следующие элементы:
- ID тест-кейса: Уникальный идентификатор для каждого тест-кейса.
- Описание теста: Описание тестируемых и проверяемых функций.
- Условия тестирования: Описание целей теста и условий, при которых он проводится.
- Предпосылки и условия: Описание условий, которые должны быть выполнены до запуска теста.
- Шаги тестирования: Последовательность действий, выполняемых инженером для выполнения теста.
- Тестовые данные: Переменные и значения, используемые для тестирования.
- Ожидаемые результаты: Описание предполагаемых результатов теста.
- Фактические результаты и постусловия: Описание фактического вывода и последствий после выполнения теста.
- Статус: Если ожидаемые и фактические результаты совпадают, тест помечается как “Пройден”. В противном случае он получает статус “Не пройден”.
Лучшие практики для проектирования тест-кейсов
Ниже приведены несколько лучших практик, которые могут использовать QA-инженеры при создании тест-кейсов:
- Четкость и простота
Тест-кейсы должны точно описывать шаги, которые должен выполнить инженер QA, и ожидаемые результаты. Держите шаги простыми и ограничивайте их до 10-15. Используйте простой язык, чтобы каждый, кто имеет доступ к документации, мог понять тест-кейсы. Убедитесь, что каждый тест-кейс отображает только один ожидаемый результат. Присвойте уникальный ID тест-кейса, если аналогичные шаги повторяются в других тестах, чтобы его легко можно было идентифицировать. - Использование различных техник тестирования
Применяйте методы, такие как анализ граничных значений (BVA) и эквивалентное разбиение (EP), чтобы охватить как можно больше функциональности и добиться максимального тестового покрытия. Несмотря на то, что достижение 100% покрытия может быть сложной задачей, цель должна заключаться в том, чтобы протестировать как можно больше функциональных возможностей для выявления ошибок и дефектов. - Обновление тест-кейсов
Постоянно обновляйте тест-кейсы в соответствии с новыми требованиями. Это поможет другим QA-инженерам легко понять и выполнить их в будущем, а также при необходимости внести изменения в документ. - Придерживайтесь рамок тестирования
Ссылайтесь на документ со спецификациями требований к программному обеспечению, чтобы чётко понимать, какие функции и возможности нужно тестировать. Следуйте только фактическим требованиям, избегая предположений или интуитивных догадок. - Автоматизация
Используйте инструменты автоматизации с поддержкой искусственного интеллекта для написания и управления тест-кейсами. Это поможет QA-инженерам эффективно отслеживать и поддерживать тест-кейсы.
Почему тест-кейсы важны для создания качественного ПО?
Без хорошо продуманных тест-кейсов инженеры QA не смогут эффективно протестировать программное обеспечение. Это может привести к недостаточному тестовому покрытию, что увеличивает риск выпуска программного обеспечения с дефектами и багами. Необходимо уделять достаточно времени на проектирование тест-кейсов, чтобы гарантировать, что продукт безопасен и готов к выпуску на рынок.
Перевод статьи «Test Case Design: A Guide for QA Engineers With Examples».