Тестовый сценарий это: Тестовый сценарий — CoderLessons.com

Содержание

Артефакты, необходимые для тестирования / Хабр

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

Итак попробую ответить на вопрос: какие артефакты необходимы для обеспечения процесса тестирования (имеется ввиду разрабатываемые самим тестировщиком).

Я выделяю несколько артефактов:

1. План тестирования (Test plan)
2. Тестовый сценарий (Test-case)
3. Наборы тестовых сценариев (Test script or Test suite)
* Набор тестовых сценариев для Smoke-test
* План приёмосдаточных испытаний (ПСИ)
4. Описание дефектов
5. Отчет о тестировании

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

План тестирования

Есть как минимум два общепринятых понимания этого документа:

1. Документ описывающий кто, что, когда и как будет тестироваться

2. Документ описывающий все необходимые для проверки приложения тесты.

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

* Взять книгу Роберт Калбертсон, Крис Браун, Гэри Кобб. Быстрое тестирование
* Взять RUP
* Погуглить
* Дождаться когда я изложу пример в одной из следующих статей

Тестовый сценарий(тест)

Тестовый сценарий — это описание начальных условий, входных данных, действий пользователя и ожидаемого результата.
Хорошая практика — написание тестовых сценариев на основании вариантов использования (Use cases).

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

Варианты названий:

* Атомарный тест
* Тестовый вариант

* Вариант тестирования
* Тестовый случай

Наборы тестовых сценариев

Это тестовые сценарии сгруппированные по некоему признаку (например тестируемой функциональности). Они могут быть как зависящими от последовательности выполнения (результат выполнения предыдущего является предварительным условием для следующего (Test script)), так и независимыми (Test suite).
Наиболее часто выделяемыми наборами являются: Набор тестовых сценариев для Smoke-test и План приёмо-сдаточных испытаний.

Набор тестовых сценариев для Smoke-test

Если честно, то я не знаю адекватного перевода на русский данного термина. Иногда используется перевод “Дымчатое тестирование”, но он вызывает у меня стойкое отвращение.

Набор тестовых сценариев для Smoke-test — это документ, включающий в себя набор определенных тестовых сценариев, покрывающих основную функциональность объекта или системы. Цель проведения Smoke-test — убедиться в том, что ключевые функции программы работают, не вникая в подробности.

Хорошая практика — прием билда в тестирование на основании прохождения Smoke-test. Также зачастую в качестве такого теста используют ежедневную сборку с обязательным прохождением unit тестов.

Комментарий: Ежедневная сборка без unit тестов не может считаться как Smoke test. Это называется: “Ух ты компилицо”

План приёмо-сдаточных испытаний (ПСИ)

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

В общем случае подмножества тестов выглядят так как на рисунке.

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

Кросспост с личного блога

Тестирование

Тестирование в легковесных процессах

Определение основных направлений и видов тестирования осуществляется на этапе анализа пользовательских историй (для Kanban) или планирования историй в спринт (для Scrum). Существенные требования к качеству историй фиксируются в критериях приемки.

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

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

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

Тестирование с предварительным проектированием

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

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

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

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

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

Тестовый сценарий против тестового сценария

Что такое контрольный пример?

TEST СЛУЧАЙ представляет собой набор действий , выполняемых для проверки конкретной функции или функциональности вашего приложения. Тестовый набор содержит шаги теста, данные теста, предварительное условие, постусловие, разработанное для конкретного тестового сценария для проверки любого требования. Тестовый пример включает в себя конкретные переменные или условия, с помощью которых инженер-тестировщик может сравнивать ожидаемые и фактические результаты, чтобы определить, работает ли программный продукт в соответствии с требованиями заказчика.

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

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

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

Пример тестового сценария

Для приложения электронной коммерции несколько тестовых сценариев

Тестовый сценарий 1: проверка функциональности поиска

Тестовый сценарий 2: проверка функциональности платежей

Тестовый сценарий 3: проверка функциональности входа

Пример тестовых случаев

Тестовые сценарии для сценария тестирования: «Проверка функциональности входа» будет

  1. Проверьте поведение системы при вводе действительного адреса электронной почты и пароля.
  2. Проверьте поведение системы при вводе неверного идентификатора электронной почты и действительного пароля.
  3. Проверьте поведение системы при вводе действительного адреса электронной почты и неверного пароля.
  4. Проверьте поведение системы при вводе неверного идентификатора электронной почты и неверного пароля.
  5. Проверьте поведение системы, если адрес электронной почты и пароль оставлены пустыми и введен вход.
  6. Проверить Забыли пароль работает как положено
  7. Проверьте поведение системы при вводе действительного / недействительного номера телефона и пароля.
  8. Проверять поведение системы, когда установлен флажок «Держать меня в подписи»

Почему мы пишем тестовые случаи?

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

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

Почему мы пишем тестовый сценарий?

Вот важные причины для создания сценария тестирования:

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

Тестовый случай и тестовый сценарий

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

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

Лучшие практики создания тестовых случаев

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

Лучшие практики создания сценария тестирования

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

КЛЮЧЕВАЯ РАЗНИЦА

  • Тестовый набор — это набор действий, выполняемых для проверки определенных функций или функциональности, тогда как сценарий тестирования — это любая функциональность, которую можно протестировать.
  • Тестовый набор в основном получен из тестовых сценариев, в то время как тестовые сценарии получены из тестовых артефактов, таких как BRS и SRS.
  • Test Case помогает в исчерпывающем тестировании приложения, тогда как Test Scenario помогает в гибком способе тестирования сквозной функциональности.
  • Тестовые случаи направлены на то, что тестировать и как тестировать, в то время как тестовый сценарий больше ориентирован на то, что тестировать.
  • Тестовые случаи — действия низкого уровня, тогда как тестовые сценарии — действия высокого уровня.
  • Test Case требует больше ресурсов и времени для выполнения теста, в то время как Сценарий тестирования требует меньше ресурсов и времени для выполнения теста.
  • Тестовый набор включает в себя этапы тестирования, данные, ожидаемые результаты для тестирования, тогда как сценарий тестирования включает в себя сквозную функциональность, подлежащую тестированию.

 

Зачем нужны тестовые сценарии? — Дмитрий Мугтасимов (профессиональный блог) — LiveJournal

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

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

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

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

  • Разделение труда специалистов разной квалификации — в этом случае тестовые сценарии являются интерфейсом между разработчиком тестовых сценариев и тестировщиком, который выполняет эти тестовые сценарии.
  • Регрессионное тестирование — в этом случае тестовые сценарии позволяют обеспечить повторяемость итераций регрессионного тестирования, что дает возможность для более точного планирования и стабильность результатов тестирования.
  • Повторное выполнение тестовых сценариев — в этом случае становится возможным выполнить тестовые сценарии, которые обнаружили дефект, повторно в той последовательности действий, которая первоначально планировалось. К сожалению, повторные итерации без написанных тестовых сценариев из-за человеческого фактора могут быть выполнены не полностью или не точно: становиться неинтересно, снижается внимательность.
  • Отчетность по результатам работы (по прогрессу и по качеству) — в этом случае становится возможной количественная оценка степени выполнения работы с точностью до тестового сценария, после завершения работы становится возможным оценить причины пропущенных дефектов, т.к. результаты выполненных тестировщиком в программном обеспечении действий (фактические результаты) могут быть задокументированы для каждого шага тестового сценария.
  • Отслеживание тестового покрытия по требованиям к программному обеспечению — в этом случае наличие ранее написанных тестовых сценариев позволяет убедиться, что определенные требования будут проверены и при необходимости дополнить набор тестовых сценариев. Строго говоря, для отслеживания тестового покрытия последовательность действий, приводимая в сценарии, необязательна. Для этих целей достаточно описания проверки, которая должна быть выполнена.
  • Разделение труда специалистов одинаковой квалификации — в этом случае тестовые сценарии являются средством измерения объема работы специалистов и планирования работ, т.е. каждому тестировщику может быть назначен свой комплект тестовых сценариев, которые он должен провести за определенный срок. Следует отметить, что подобное разделение труда можно осуществить и без тестовых сценариев, например, по требованиям к программному обеспечению.
Перечисленные случае не всегда актуальны. Например, если на определенном этапе развития программного обеспечения требуется обнаружить только наиболее критичные дефекты, т.к. остальные дефекты будут обнаружены и исправлены в ходе сопровождения, то разработка тестовых сценариев может оказаться неэффективной.

(c) 2010 Дмитрий Мугтасимов

Тест «Сценарии» для управленческих стилей | Онлайн примеры

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

Онлайн-пример «Сценарий» теста:

Какие управленческие стили определяет «Сценарий» тест

Тест управленческих стилей оценивает главные навыки руководителей и их управленческий потенциал. Главные преимущества тестирования – объективность и достоверность при оценке трех базовых компонентов управленческого анализа:

Управленческие стили в тест Сценарии
Базовый навык Описание Возможные варианты управленческого стиля
Расстановка приоритетов Умение планировать время, распределять усилия, учитывая все аспекты сложившейся ситуации и использовать адаптивный подход к решению проблем. — Панорамный подход;
— Делегирование полномочий.
Управление людскими ресурсами Навыки работы с людьми и способность поддерживать необходимый уровень мотивации у подчиненных. Способность построения команды, рабочей группы и забота о подчиненных. — Командная работа;
— Стиль одиночки.
Сохранение авторитета Понимание принципов управления и создания репутации. Готовность работать в интересах компании. — Стремление к признанию собственных заслуг;
— Соблюдение корпоративных интересов.

Формат Сценарий тестов и Кейс тестов

Тесты сценарии и кейс тесты (case test) разрабатываются международными консалтинговыми или кадровыми агентствами под нужды работодателя. Однако в отличие от сложных и объемных упражнений по анализу кейсов тестирование более стандартизировано. Вопросы, варианты ответов и профиль оцениваемых навыков могут отличаться, но структура испытания, как правило, остается неизменной.

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

Как правило, встречаются три типа вопросов:

  1. Выбор одного правильного варианта;
  2. Оценка каждого варианта по шкале от 1 до 5;
  3. Расстановка ответов по эффективности.

Время на прохождение задания ограничено. В среднем упражнение занимает 40 минут и включает 15-20 сценариев-вопросов.

Преимущества ситуационных заданий

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

Важно:

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

Для кого предназначен тест

Ситуационные сценарии и личностные испытания используются в практике HR для подбора персонала на руководящие должности. Они часто встречаются на многоэтапных отборах на престижные стажировки или конкурсы для управленцев, например, на конкурс «Лидеры России». Благодаря тестированию выявляются слабые места человека. Результаты теста используются в качестве основания для прохождения курсов или семинаров по повышению квалификации.

Сложности

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

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

Как готовиться к «Сценарий» тестам

Первым делом, перед тем как идти на собеседование, узнают тип теста и его разработчика. Спросить об этом можно у менеджера по кадрам, пригласившего вас на собеседование. Для каждого разработчика (SHL, Talent-q) существуют свои тонкости. Если удалось узнать разработчика испытания, подготовка выстраивается по соответствующим руководствам. Подготовка также зависит от вакансии и будущих должностных обязанностей.

Подготовиться помогут тренировочные тест сценарии, примеры правильного выполнения заданий и руководства по ситуационным тестам. Соискателю разъясняется, к какому результату приводит избранное решение, как HR выполняет итоговую оценку и интерпретирует полученные результаты, какие навыки оцениваются на упражнении. Научившись правильно трактовать варианты ответов, соискатель сможет:

  • Легко находить в них различия;
  • Понимать, о наличии или отсутствии каких навыков идет речь;
  • Знать, как они характеризуют претендента.

Результаты

Тестирование, как и ассессмент – сертифицированная процедура, после которой претенденту предоставляется результат в виде:

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

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

Советы по подготовке к «Сценарий» тестам

  1. Искать информацию.
    По регламенту ассессмента информация об испытаниях держится в секрете вплоть до момента проведения процедуры. Несмотря на это HR охотно отвечают на вопросы перед собеседованием, помогая понять, что ждет кандидата. Ошибку совершают те, кто боится задавать вопросы. Альтернативными источниками информации послужат официальный сайт компании или аккаунты в соцсетях.
  2. Понять стратегию.
    Цель испытания – найти человека, обладающего управленческим стилем, согласующимся с утвержденными в компании методами работы, ее целями или стратегией. Поэтому кандидату важно знать, какого отношения от него ждет работодатель. В одних компаниях желательным будет жесткий стиль управления, в других – способность мягко решать конфликты. Получить предварительную консультацию мжно у сотрудников компании. Связаться с ними можно при помощи соцсетей.
  3. Быть честным.
    В заданиях иногда встречаются вопросы, призванные проверить честность соискателя, поэтому обманывать работодателя нецелесообразно. Адаптируя ответы с учетом контекста и ситуации, не следует пытаться впечатлить работодателя, выбирая «удобные» или «красивые» варианты. Более того, большинство вопросов на ассессменте пересекаются между собой. Если работодатель получит противоречивые результаты, он откажет претенденту из-за недостатка искренности.
  4. Тренироваться.
    Подготовка к ассессменту состоит в решении тренировочных заданий. Такой тест «сценарии» можно решать онлайн. Преимущества этого метода в наличии статистики по заданиям и возможности отслеживать динамику роста. Причем просто отвечать на вопросы недостаточно – кандидаты должны посмотреть на процесс глазами экзаменаторов. Для этого, пользуясь руководствами, составляется личный профиль, проводится работа над ошибками и прорабатываются «слабые» стороны характера.

Оцените статью

средняя оценка 3,33 (3 голосов)

Загрузка…

Методология разработки тестовых случаев на основе сценариев использования

Автор: Екатерина Курач

Написать тест кейсы для «полного» тестирования продукта — просто невозможно. Мы можем разработать миллионы тестов, но будет ли время у нас их выполнить? Вероятнее всего — нет. Поэтому приходится тщательно выбирать тест кейсы, которые мы будем проводить.

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

Но, как известно, полностью протестировать программу невозможно по следующим причинам:

  1. Количество всех возможных комбинаций входных данных слишком велико, чтоб его можно было проверить полностью.
  2. Количество всех возможных последовательностей выполнения кода программы также слишком велико, чтобы его можно было протестировать полностью.
  3. Пользовательский интерфейс программы (включающий все возможные комбинации действий пользователя и его перемещений по программе) обычно слишком сложен для полного тестирования.

Т.е. написать тест кейсы для «полного» тестирования продукта — просто невозможно. Мы можем разработать миллионы тестов, но будет ли время у нас их выполнить? Вероятнее всего — нет. Поэтому приходится тщательно выбирать тест кейсы, которые мы будем проводить.

Характеристики хорошего теста:

  • Существует обоснованная вероятность выявления тестом ошибки
  • Набор тестов не должен быть избыточным
  • Тест должен быть наилучшим в своей категории
  • Он не должен быть слишком простым или слишком сложным

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

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

Методология разработки тестовых случаев на основе сценариев использования

Случай использования состоит из некоторого множества сценариев: нормальный случай, расширения и исключительные ситуации. Для разработки тест кейсов на основе одного случая использования разрабатываются несколько сценариев, соответственно: Сценарий использования представляет собой оптимистический сценарий, который выбирается чаще других. В раздел Альтернативные пути могут быть включены несколько сценариев, которые отличаются от сценария использования в различных аспектах, однако остаются полноценными путями исполнения. В раздел Исключительные пути попадают те сценарии, которые приводят к возникновению ошибок. Каждый сценарий предусматривает действия, предпринимаемые действующим субъектом, и требует от системы отклика, который соответствует основной части тестового случая. Тестовый случай состоит из некоторого набора предусловий, стимулирующего воздействия (входные данные) и ожидаемого отклика.

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

 

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

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

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

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

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

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

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

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

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

В таблице 1 показаны классы эквивалентности этих трех переменных.

Имя переменнойТип объектаКлассы эквивалентности
Имя Строка
  1. Имя, которое выходит за пределы максимальной длины строки
  2. Имя, которое в точности соответствует максимальной длине строки
  3. Полное имя с оставшимся пустым пространством
  4. Пустое имя
Служащий Штатная единица
  1. Специально созданная штатная единица
  2. Ранее существовавшая единица
Авторизация Код безопасности
  1. Санкционирован только локальный доступ
  2. Санкционирован доступ в масштабах всей системы

Спецификация входных значений для системы управления кадрами

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

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

ИмяШтатная единицаАвторизация
Полное имя с остающимся пустым пространством Ранее существовавшая штатная единица Санкционирован только локальный доступ
Полное имя с остающимся пустым пространством Новая штатная единица Санкционирован только локальный доступ

Перестановки входных данных системы управления персоналом

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

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

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

Второй подход заключается в разработке тестовых случаев большого цикла (grand tour test cases), в котором каждый тестовый случай генерирует данные, которые служат входом для следующего тестового случая. По условиям такого подхода каждый тест переносит тестовые данные через весь жизненный цикл. Полученное при этом состояние базы данных используется в качестве входного для следующего теста. Этот метод особенно эффективен при тестировании жизненного цикла после того, как тестирование нижнего уровня позволило выявить большую часть дефектов, вызывающих отказы. Если выстроить тестовые случаи в соответствующую последовательность, то после успешного выполнения тестового случая 1 устанавливается такое состояние программы, которое ожидается как входное для тестового случая 2. Очевидная проблема в условиях очерченного подхода заключается в том, что неудачное выполнение тестового случая 1 оставляет программу в состоянии, которого мы не ожидали, в результате чего мы не можем выполнять прогон тестового случая 2 или даже вернуть программу в рабочее состояние.

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

  • Тестирование на соответствие функциональным требованиям
  • Проверка качественных системных атрибутов. Добротная организация разработок программного обеспечения предусматривает методы подтверждения всех системных «требований», включая и претензии на придание программному продукту особых качеств. Существуют два вида претензий, с которыми может столкнуться программа при разработке продукта. Первый вид претензий представляет интерес только для организаций, занимающейся разработкой программных продуктов. Например, утверждение, что «программный код допускает многократное использование». Второй тип претензий представляет интерес для пользователей системы. Например, утверждение о том, что система является более полной, нежели другие системы подобного класса, предлагаемые на текущий момент на рынке программных продуктов. Вполне понятно, что не все эти претензии могут подвергаться проверке через тестирование. Однако на это следует обратить внимание.
  • Тестирование механизма развертывания системы
  • Тестирование после развертывания системы. Естественное расширение тестирования механизма развертывания системы заключается в добавлении в тестируемый программный продукт функциональных средств самопроверки. Считается, что система «изнашивается» во времени по причине изменений, имеющих место в ее взаимодействии с окружением, примерно так же, как со временем изнашивается механическая система из-за трений между ее компонентами. По мере того, как устанавливаются все более новые версии стандартных драйверов и библиотек, несоответствия возрастают вместе с ростом вероятности возникновения отказов. Каждая новая версия dll-библиотеки привносит возможность появления новых областей нестыковки стандартных интерфейсов или появления состояния гонок между этой библиотекой и приложением. Функциональные средства самотестирования должны обеспечивать выполнение тестов, которые исследуют работу интерфейсов между этими программными продуктами.
  • Тестирование взаимодействий окружения
  • Тестирование системы безопасности

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

Литература:

  1. Сэм Канер, Джек Фолк, Енг Кек Нгуен. Тестирование программного обеспечения. — Киев: Издательство «Диа Софт», 2001.—544 с.
  2. Макгрейгор Джон, Сайкс Девид. Тестирование объектно-ориентированного программного обеспечения. Практическое пособие. — Киев: ООО «ТИД «ДС»», 2002.—432 с.

Что такое исследовательское тестирование? / Хабр

И чем оно отличается от тестирования по сценариям (сценарного тестирования)


Этот пост является переводом статьи Джеймса Баха What is Exploratory Testing? Это первый перевод из серии статей Баха про исследовательское тестирование и все, что с ним связано с сайта http://www.satisfice.com. Если вы нашли неточность в переводе или ошибку в терминологии прошу сообщить о ней в комментариях к статье.
 

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

Параллельное проектирование и выполнение тестов


Простейшее определение исследовательского тестирования — это разработка и выполнения тестов в одно и то же время. Что является противоположностью сценарного подхода (с его предопределенными процедурами тестирования, неважно ручными или автоматизированными). Исследовательские тесты, в отличие от сценарных тестов, не определены заранее и не выполняются в точном соответствии с планом. Звучит это просто, но на практике все весьма туманно. Это происходит из-за того, что «определенный» не означает что мы жестко фиксируем все и вся. Даже в том случае, если тщательно определены все тестовые сценарии, то работа с большим количеством интересных деталей (например, как быстро печатать на клавиатуре, или какие виды поведения программы признать ошибочными) остаются на усмотрение тестировщика. Кроме того, даже в свободной форме поисковой сессии тест будет включать в себя ограничения состоящие в том, какую часть продукта тестировать или какую стратегию использовать. Хороший исследовательский тестирировщик будет записывать идеи тестов и использовать их в последующих циклах испытаний. Такие заметки иногда очень похожи на сценарии тестирования, даже если они таковыми не являются. Исследовательское тестирование иногда путают с «ad hoc» тестированием. Ad hoc тестирование обычно относится к процессу импровизации, поиска ошибки экспромтом. По определению, любой может заниматься ad hoc тестированием. Термин «исследовательское тестирование» (придумал Cem Kaner, в книге Testing Computer Software) обозначает вдумчивый подход к ad hoc тестированию. За последние десять лет, Джеймс Уиттакер, Сем Канер и я работали для выявления навыков и техник позволяющих эффективно использовать исследовательское тестирование. Например, полностью определены и сформулированы процессы исследовательского тестирования, см. General Functionality and Stability Test Procedure for Microsoft’s Windows 2000 Compatibility Certification program.

Баланс между исследовательским и сценарным тестированием


Если каждый следующий тест, который мы выполняем, выбирается по результатам предыдущего теста, это означает, что мы используем исследовательское тестирование.Мы начинаем заниматься поисками и исследованиями, когда мы не можем сказать, какие тесты должны быть выполнены, или когда мы еще не имели возможности эти тесты создать, то есть мысль об их написании даже не приходила нам в голову. Если мы идем по сценариям, и на свет выплывает новая информация, которая предлагает нам лучшую стратегию тестирования, мы можем перейти к поисковому режиму (как и в случае обнаружения новой ошибки, которая требует подробного рассмотрения). С другой стороны, мы больше следуем сценарному подходу, когда 1) неопределенность в том, как мы хотим проверить, мала 2) новые тесты относительно неважны, 3) необходимость обеспечения эффективности и надежности в выполнении этих тестов стоит усилий по работе с подобными тестами, 4)мы готовы платить за написание и поддержание тестов.

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

Зачем проводить исследовательское тестирование?


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

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

Как написать тестовые случаи: образец шаблона с примерами

  • Home
  • Testing

      • Back
      • Agile Testing
      • BugZilla
      • Cucumber
      • Database Testing
      • ETL Testing
      • ETL
      • Назад
      • JUnit
      • LoadRunner
      • Ручное тестирование
      • Мобильное тестирование
      • Mantis
      • Почтальон
      • QTP
      • Назад
      • Центр качества SAP
      • SoapUI
      • Управление тестированием
      • TestLink
  • SAP

      • Назад
      • 900 03 ABAP
      • APO
      • Начинающий
      • Basis
      • BODS
      • BI
      • BPC
      • CO
      • Назад
      • CRM
      • Crystal Reports
      • Crystal Reports
      • FICO3
      • Заработная плата
      • Назад
      • PI / PO
      • PP
      • SD
      • SAPUI5
      • Безопасность
      • Менеджер решений
      • Successfactors
      • SAP Back Tutorials
      • 9007
          • Apache
          • AngularJS
          • ASP.Net
          • C
          • C #
          • C ++
          • CodeIgniter
          • СУБД
          • JavaScript
          • Назад
          • Java
          • JSP
          • Kotlin
          • Linux
          • Linux
          • Kotlin
          • Linux
          • js
          • Perl
          • Назад
          • PHP
          • PL / SQL
          • PostgreSQL
          • Python
          • ReactJS
          • Ruby & Rails
          • Scala
          • SQL
          • 000
          • SQL
          • 000 0003 SQL 000 0003 SQL 000
          • UML
          • VB.Net
          • VBScript
          • Веб-службы
          • WPF
      • Обязательно учите!

          • Назад
          • Бухгалтерский учет
          • Алгоритмы
          • Android
          • Блокчейн
          • Business Analyst
          • Создание веб-сайта
          • CCNA
          • Облачные вычисления
          • 00030003 COBOL 9000 Compiler
              9000 Встроенные системы
            • 00030002 9000 Compiler 9000
            • Ethical Hacking
            • Учебники по Excel
            • Программирование на Go
            • IoT
            • ITIL
            • Jenkins
            • MIS
            • Сеть
            • Операционная система
            • Назад
            • Управление проектами Обзоры
            • Salesforce
            • SEO
            • Разработка программного обеспечения
            • VB A
        • Big Data

            • Назад
            • AWS
            • BigData
            • Cassandra
            • Cognos
            • Хранилище данных
            • 0003
            • HBOps
            • 0003
            • HBOps
            • 0003
            • MicroStrategy
            • MongoDB
        .Тестовый пример

        против тестового сценария: в чем разница?

        • Home
        • Тестирование

            • Back
            • Agile Testing
            • BugZilla
            • Cucumber
            • Тестирование базы данных
            • Тестирование ETL
            • 0003
            • Jmeter
            • Jmeter Load Backing
            • Ручное тестирование
            • Мобильное тестирование
            • Mantis
            • Почтальон
            • QTP
            • Назад
            • Центр качества (ALM)
            • RPA
            • SAP Testing
            • Selenium
          • SAP

              • Назад
              • ABAP
              • APO
              • Начало er
              • Basis
              • BODS
              • BI
              • BPC
              • CO
              • Назад
              • CRM
              • Crystal Reports
              • FICO
              • Pay4
              • HR
              • Назад
              • PI / PO
              • PP
              • SD
              • SAPUI5
              • Безопасность
              • Менеджер решений
              • Successfactors
              • SAP Tutorials
          • Назад

            Web

              • Angular

                Web

                  • ASP.Net
                  • C
                  • C #
                  • C ++
                  • CodeIgniter
                  • СУБД
                  • JavaScript
                  • Назад
                  • Java
                  • JSP
                  • Kotlin
                  • Linux
                  • Linux
                  • Kotlin
                  • Linux
                  • js
                  • Perl
                  • Назад
                  • PHP
                  • PL / SQL
                  • PostgreSQL
                  • Python
                  • ReactJS
                  • Ruby & Rails
                  • Scala
                  • SQL
                  • 000
                  • SQL
                  • 000 0003 SQL 000 0003 SQL 000
                  • UML
                  • VB.Net
                  • VBScript
                  • Веб-службы
                  • WPF
              • Обязательно учите!

                  • Назад
                  • Бухгалтерский учет
                  • Алгоритмы
                  • Android
                  • Блокчейн
                  • Business Analyst
                  • Создание веб-сайта
                  • CCNA
                  • Облачные вычисления
                  • 00030003 COBOL 9000 Compiler
                      9000 Встроенные системы
                    • 00030002 9000 Compiler 9000
                    • Ethical Hacking
                    • Учебники по Excel
                    • Программирование на Go
                    • IoT
                    • ITIL
                    • Jenkins
                    • MIS
                    • Сеть
                    • Операционная система
                    • Назад
                    • Управление проектами Обзоры
                    • Salesforce
                    • SEO
                    • Разработка программного обеспечения
                    • VB A
                • Big Data

                    • Назад
                    • AWS
                    • BigData
                    • Cassandra
                    • Cognos
                    • Хранилище данных
                    • 0003
                    • HBOps
                    • 0003
                    • HBOps
                    • 0003
                    • MicroStrategy
                    • MongoDB
                .

                Как написать тестовые примеры для страницы входа (примеры сценариев)

                Примеры тестовых примеров для страницы входа (включает ВСЕ важные функциональные и нефункциональные тестовые примеры для страницы входа)

                Всякий раз, когда вас попросят написать тестовые примеры для «Форма с некоторыми элементами управления», вам необходимо следовать списку правил для написания тестовых примеров, как указано ниже:

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

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

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

                Здесь может быть имя пользователя, пароль, кнопка «Войти», кнопка «Отмена» и ссылка «Забыли пароль». Может быть еще один элемент управления — флажок «Запомнить меня», чтобы запомнить данные для входа на конкретный компьютер.

                Тестовые примеры — страница входа в систему

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

                Случаи функционального тестирования:
                Нефункциональные тесты безопасности:

                Мы можем взять Пример страницы входа в Gmail.Вот его изображение.

                Тестовые примеры для страницы входа в Gmail

                Тестовые сценарии для страницы регистрации

                # 1) Проверьте сообщения для каждого обязательного поля.

                # 2) Убедитесь, что пользователь не может продолжить, не заполнив все обязательные поля.

                # 3) Проверьте возраст пользователя при выборе DOB.

                # 4) Проверьте, не разрешены ли числа и специальные символы в имени и фамилии.

                # 5) Убедитесь, что пользователь может успешно зарегистрироваться со всеми обязательными данными.

                # 6) Проверьте, может ли пользователь войти в систему с действительными данными.

                # 7) Убедитесь, что поля «Пароль» и «Подтверждение пароля» принимают только одинаковые строки.

                # 8) Убедитесь, что в поле «Пароль» запрашиваются слабые пароли.

                # 9) Проверить, не будет ли назначен дублирующийся адрес электронной почты.

                # 10) Убедитесь, что для каждого поля формы есть подсказки для простоты использования.

                Сценарии тестирования для страницы входа в мобильное приложение

                [источник изображения]

                # 1) Проверьте, может ли пользователь войти в систему с действительным именем пользователя и паролем.

                # 2) Проверьте, не может ли пользователь войти в систему с неверным именем пользователя или паролем. Проверьте перестановки и комбинации этого.

                # 3) Установите флажок «Запомнить меня». Если этот флажок установлен, пользователь не должен выходить из системы даже после выхода из приложения.

                # 4) Убедитесь, что этот флажок не установлен по умолчанию.

                # 5) Если пользователь зарегистрировался в Facebook или социальной сети, убедитесь, что пользователь может войти в систему с этими учетными данными или нет.

                # 6) Проверьте функцию «Забыли пароль».

                # 7) Убедитесь, что страница входа соответствует экрану мобильного телефона. Пользователю не нужно прокручивать экран.

                Заключение

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

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

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

                Надеюсь, у вас есть полное представление о том, как писать тестовые примеры для страницы входа.

                .Образец шаблона тестового набора

                с примерами тестового набора [Скачать]

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

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

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

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

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

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


                Рекомендуемые инструменты

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

                # 1) TestRail

                => Загрузить TestRail Test Case Management Tool


                # 2) TestMonitor

                TestMonitor — онлайн-управление тестированием верхнего уровня. Революционно легко.

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

                => Посетите веб-сайт TestMonitor


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

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

                Стандартные поля образца шаблона тестового случая

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

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

                ID тестового набора: Уникальный ID требуется для каждого тестового примера. Следуйте некоторому соглашению, чтобы указать типы теста. Например, «TC_UI_1», указывающий «тестовый пример пользовательского интерфейса №1».

                Приоритет теста (Низкий / Средний / Высокий) : Это очень полезно при выполнении теста.Приоритет тестирования для бизнес-правил и функциональных тестовых примеров может быть средним или более высоким, тогда как второстепенные случаи пользовательского интерфейса могут иметь низкий приоритет. Рецензент всегда должен устанавливать приоритет теста.

                Имя модуля : укажите имя основного модуля или подмодуля.

                Тест разработан Имя тестировщика.

                Дата разработки теста : Дата написания.

                Тест выполнен пользователем Имя тестировщика, выполнившего этот тест.Заполняется только после выполнения теста.

                Дата выполнения теста : Дата выполнения теста.

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

                Краткое описание / описание теста : Кратко опишите цель теста.

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

                Зависимости : упомяните любые зависимости от других тестовых примеров или требований к тестированию.

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

                Pro Tip : Чтобы эффективно управлять тестовым примером с меньшим количеством полей, используйте это поле для описания условий тестирования, тестовых данных и ролей пользователей для запуска теста.

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

                Ожидаемый результат : Каким должен быть результат системы после выполнения теста? Подробно опишите ожидаемый результат, включая сообщение / ошибку, которые должны отображаться на экране.

                Постусловие : Каким должно быть состояние системы после выполнения этого тестового примера?

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

                Статус (пройден / не пройден) : Если фактический результат не соответствует ожидаемому, то отметьте этот тест как не удалось . В противном случае обновите его, так как прошло .

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

                При необходимости добавьте следующие поля:

                Идентификатор дефекта / Ссылка : Если статус теста — сбой , включите ссылку на журнал дефектов или укажите номер дефекта.

                Тип теста / ключевые слова : Это поле можно использовать для классификации тестов на основе типов тестов. Например, функциональность, удобство использования, бизнес-правила и т. Д.

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

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

                Автоматизация? (Да / Нет) : Автоматизирован ли этот тестовый пример или нет. Когда тестовые примеры автоматизированы, полезно отслеживать статус автоматизации.

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

                Загрузить шаблон тестового случая с примером (формат # 1)

                — Шаблон файла DOC для тестового случая и
                — Шаблон файла тестового примера Excel

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

                Примеры тестовых случаев:

                Учебное пособие № 1: 180+ примеров тестовых случаев для веб-приложений и настольных приложений

                Еще один формат тестовых примеров (№ 2)

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

                Примеры тестов

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

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

                Ниже приведены тестовые примеры для того же:

                => Загрузите указанный выше формат тестового примера с данными примера

                Пример тестового примера для ручного тестирования

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

                [Примечание. Щелкните любое изображение, чтобы увеличить его]

                Заключение

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

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

                Мы будем рады узнать ваши мысли, комментарии / предложения по этой статье.

                PREV Tutorial | СЛЕДУЮЩИЙ Учебник

                .

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *