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

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

Распространенные проблемы с тестовыми примерами

В работе по тестированию самое основное — это написание тестовых примеров. Обычно вы сталкиваетесь со следующими проблемами. Тест-кейсы напрямую копируют определенные фрагменты требований

Описание тестового примера избыточно

Иерархия сбивает с толку

Тестовые случаи не поддерживаются и не обновляются своевременно.

Дублирование тестовых примеров и т. д.

Эффективных тест-кейсов не так много.

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

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

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

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

Ключевой момент в тестовом примере

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

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

Этапы тестирования: подробно опишите конкретные шаги для выполнения каждого тестового примера.

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

Часто используемые методы разработки тестовых случаев

Разделение классов эквивалентности: разделите входные данные на несколько классов эквивалентности и выберите из них небольшое количество репрезентативных значений в качестве тестовых данных.

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

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

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

Обзор, оптимизация, документирование

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

Как разработать хорошие тест-кейсы

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

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

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

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

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

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

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

На следующем рисунке показаны связи между бизнес-требованиями и функциональными требованиями к программному обеспечению, функциональными требованиями к программному обеспечению и требованиями к тестированию, а также требованиями к тестированию и тестовыми сценариями. В практике компаний, не работающих в Интернете, инструменты управления отслеживанием требований (такие как JIRA, TestLink, и т. д.) обычно используются для управления и измерения охвата тестовых примеров бизнес-требований и функциональных требований к программному обеспечению.

картина

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

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

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

Другой опыт разработки вариантов использования

В дополнение к методам, представленным выше, я поделюсь с вами тремя эксклюзивными «читами», надеясь помочь вам разработать «хороший» набор тестовых примеров.

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

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

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

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

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

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

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