Введение в тестовые случаи

Тестовый кейс (TestCase) — это набор тестовых входных данных, условий выполнения и ожидаемых результатов, скомпилированный под требования проекта.,Чтобы проверить, соответствует ли программа потребностям клиентов.,Его можно описать как: проектирование данных и поэтапное проектирование каждой контрольной точки и каждой функциональной точки, обнаруженной в ходе анализа спроса.,Проектирование данных、ступенчатый дизайн、ожидаемый результат.

Цель тестовых примеров (Зачем использовать тестовые примеры?)

1. Тестовые примеры — это основа тестирования программного обеспечения;

2. Ориентиры для оценки результатов испытаний;

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

4. В процессе написания тестовых примеров вы можете ознакомиться с требованиями и получить базовое и глубокое понимание архитектуры системы или бизнес-процессов;

5. Хорошие тест-кейсы не только удобны для просмотра вам и другим, но и помогают тщательно подумать при проектировании. Поэтому написание тест-кейсов так же важно, как и дизайн. Это исполнительный (руководящий) документ.

Основное содержание тестового примера

Как правило, тестовые примеры должны содержать следующее содержимое:

1. Написание вариантов использования: название продукта – этап тестирования – элемент тестирования – первая буква функционального модуля XXX плюс номер;

2. Тестовый проект: соответствует функциональному модулю (доработанная функция);

3. Название теста: непосредственно уточняйте тестовую точку, вводите содержимое + результат, название того же функционального модуля не может повторяться (из тестовой точки);

4. Уровень важности: низкий, средний, высокий;

5. Предустановленные условия: должны быть выполнены некоторые предварительные условия, иначе вариант использования не может быть выполнен;

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

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

8. Ожидаемые результаты. Сравните ожидаемые результаты с фактическими результатами, чтобы определить, соответствует ли тестируемый объект требованиям. Если ожидаемый результат уникален, «или или» не может появиться.

Написание тестовых случаев

Обычно,Небольшие компании и небольшие проекты используют Excel для управления тестовыми примерами.,Для крупных компаний,Умение использовать инструменты управления тестированием,напримерjira、Дзен Тао,Или разработать инструмент самостоятельно. Но в целом,тестовый пример,Он должен содержать следующее содержимое:

Шаблон тестового примера
	Номер варианта использования | Функциональный модуль | название теста | Уровень приоритета | Предустановленные условия | данные испытаний | Этапы работы | ожидаемый результат | Дизайнер | Результаты испытаний | Исполнитель | Примечание

Принципы написания тест-кейсов

1. Точность: дизайн тестовых примеров должен соответствовать требованиям тестирования, а содержание теста должно быть точно описано.
2. Простота: дизайн тестовых случаев должен включать необходимые шаги и элементы для завершения теста, и нет необходимости добавлять избыточные и ненужные шаги и элементы.
3. Возможность повторного использования, разработка тестовых примеров, требования. Тестирование является управляемым, поэтому любой, кто его тестирует, в любое время может получить одинаковые результаты.
4. Применимость: тестовый пример исполняется для текущей тестовой среды и тестировщиков.
5. Выполнение этого тестового примера не повлияет на выполнение других тестовых примеров. Тестовый пример должен описывать, как восстановить прикладную систему в исходное состояние, не влияя на выполнение последующих тестов.

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

Что такое обзор варианта использования?

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

Зачем нужны обзоры вариантов использования?

1. Чтобы тестировщики не выполняли недопустимую работу на этапе выполнения;

2. Во избежание противоречивого понимания потребностей трех сторон.

3. Чтобы достичь согласия по стандартам качества каждого тестера и стандартам требований проекта.

Рецензенты вариантов использования и время

1. обозреватель вариантов использования

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

1. Время рассмотрения варианта использования

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

Формат обзора вариантов использования

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

Действия, которые необходимо предпринять после проверки

1. После завершения проверки тестовые примеры будут рассортированы как можно скорее, а измененное содержимое будет переорганизовано и завершено. Измененные функциональные точки будут отмечены желтым цветом.
2. Что касается контента, который не был определен на собрании, мы продолжим следить за ним после собрания, пока результаты не будут подтверждены. Если есть какие-либо недостающие функциональные точки, после добавления они будут отмечены зеленым цветом.
3. Совещание по рассмотрению вариантов использования итог,Например: Какие функциональные точки были исправлены?,Отмечено желтым; какие новые функциональные точки были добавлены?,Зеленым отмечены функции каких модулей изменены.,Отмечено фиолетовым цветом；Который Функциональный модуль перенес его на следующий выпуск,Отмечено красным.

Подвести итог

Разработка и проверка тестовых примеров — важные шаги для обеспечения эффективности и результативности тестирования. Благодаря четким шагам написания и обзору содержания можно обеспечить полноту, точность и выполнимость тестовых примеров, тем самым повышая эффективность и охват тестирования. Надеюсь, эта статья поможет каждому!