Автор: Сад Латиао

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

Предисловие

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

В конце статьи автор приготовил для вас сюрприз.

1. Что такое тестовый пример?

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

Говоря простым языком: это означает описание этапов работы нашей тестовой системы словами в определенном формате.

2. Каковы преимущества написания тестовых примеров?

1. Проясните свои мысли и избегайте пропусков

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

2. Отслеживайте ход тестирования

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

3. Историческая справка

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

4. Повторяемость

Когда мы тестируем систему, мы не можем протестировать ее один раз. Это требует многократного тестирования несколькими людьми. Затем нам нужны тестовые примеры для стандартизации и руководства нашим поведением при тестировании.

3. Метод тестового примера

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

1. Разделение классов эквивалентности

Подмножество входной области, в которой входные данные эквивалентны при выявлении ошибок в программе. Если есть поле ввода, требующее ввода чисел от 1 до 10 000, мы не сможем попробовать каждое число. Наш ввод 5 и 6 для проверки и выявления ошибок в поле ввода можно рассматривать как эквивалент. Затем в это время мы можем случайным образом извлечь некоторые данные для проверки. Например: 10, 99, 7777...

Классы эквивалентности: действительные классы эквивалентности и недействительные классы эквивалентности.

Поле ввода требует ввода числа от 1 до 10000.

Допустимые классы эквивалентности: для проверки можно ввести число от 1 до 10 000, например: 2, 5, 99, 8495...

Неверный класс эквивалентности. Для проверки можно ввести любой символ, кроме 1–10 000, например: 20 000, буквы, символы подчеркивания, специальные символы, пробелы, возврат каретки...

2. Граничное значение

Граничные значения являются дополнением к классу эквивалентности. Опыт тестирования подсказывает нам, что большое количество ошибок возникает в граничных значениях ввода и вывода. Давайте возьмем приведенный выше пример. Поле ввода требует ввода числа от 1 до 10000. Нам нужно проверить, выходит ли оно за этот диапазон, например: 0, -1, -2, 1000, 10001... и т. д., чтобы определить, выходит ли оно за наш диапазон.

3. Диаграмма причин и следствий

Конечным продуктом, созданным методом причинно-следственной диаграммы, является таблица решений, которая подходит для проверки различных комбинаций входных условий программы. Например: Причина: A=0, B=0 В результате я могу определить: A=B. Точнее, это причинная идея. Это будет неявно руководить нашим тестированием. Конечно, чтобы ничего не пропустить, можно нарисовать причинно-следственные связи в системе с помощью картинок. Однако если система большая и сложная, это будет трудоемкая задача. хе-хе.

4. Неправильный метод угадывания

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

5. Другие

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

4. Формат и элементы тест-кейсов

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

Конечно, вы также можете добавить некоторые другие параметры, такие как: приоритет, этап тестирования...

Примечание. Приведенный выше формат взят из «Метода тестирования программного обеспечения Microsoft». Он может вам не подойти. Я просто хочу, чтобы все поняли формат тестирования.

Что касается хранения и управления тест-кейсами:

1. Система управления проектами включает в себя управление вариантами использования. Как правило, варианты использования связаны с проектом, имеют фиксированный формат, функции поиска, модификации и другие и очень удобны в использовании. Например: управление проектами ZenTao, контроль качества, отсутствие ошибок и т. д. — все они имеют функции управления вариантами использования.

2. Управление осуществляется через форму документа world\Excel. Преимущество этого способа заключается в том, что вы можете самостоятельно определить формат тестовых примеров.

Пример тестового примера

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

Примечание. Это не полный тестовый пример, и его формат не фиксирован. Вы можете написать тестовые примеры в соответствии со своими потребностями.

Помимо вышесказанного, нам также необходимо знать о тестовых примерах.

5. Когда мы можем разработать тестовые сценарии?

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

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

6. Обзор и обновление тестовых примеров

После завершения разработки тестового примера, завершен ли он? Соответствует ли это системе? Удовлетворить требования клиентов? Анализ вариантов использования имеет важное значение. Что касается методов проверки, в разных компаниях используются разные процессы.

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

7. При каких обстоятельствах писать тест-кейсы нецелесообразно?

1. Время файла

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

2. Спрос сильно и часто меняется.

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

3. Время проекта не позволяет

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

Не пишите тестовые примеры, которые являются неполными или непонятными для других, поскольку это было бы бессмысленно.