Сценарии Тестов — различия между версиями

Материал из Брацка Правки
Перейти к: навигация, поиск
(→‎Текст)
(→‎Термины)
 
(не показано 38 промежуточных версий 5 участников)
Строка 1: Строка 1:
−
[[Сценарии Тестов]] (здесь и далее по тексту -- ''Лектио'') -- это часть урока [[Суть Сценариев Тестов]]. В [[Брацка Школа|Брацкой Школе]], уроки делятся на так называемые [[лектио]], каждое из которых состоит из микролекции и одного или нескольких заключительных вопросов. Урок, в свою очередь, относится к практическому семинару '''[[Выбор Профессии]]'''.
+
[[Сценарии Тестов]] (здесь и далее по тексту -- ''Лектио'') -- это часть урока [[Документы Тестов]]. В [[Брацка Школа|Брацкой Школе]], уроки делятся на так называемые [[лектио]], каждое из которых состоит из микролекции и одного или нескольких заключительных вопросов. Урок, в свою очередь, относится к практическому семинару '''[[Выбор Профессии]]'''.
  
  
 
==Материалы==
 
==Материалы==
−
Предшественник этого ''Лектио'' -- [[Поиски и Сценарии]].
+
Предшественник этого ''Лектио'' -- [[Задания на Поиск]].
  
 
===Иллюстрации===
 
===Иллюстрации===
−
<gallery mode="packed">
+
<gallery mode="packed">File:Сценарии_Тестов.png
 
</gallery>
 
</gallery>
  
−
===Текст===
+
===Текст (HTML)===
−
:<p><strong>Сценарии Тестов</strong></p><p>Сценарий теста (test case; в русском сленге, "тест кейс") -- это документация теста, включающая набор требований для его проведения. В системной инженерии задание на функциональный тест, например, определяет входные данные, внешние факторы, доступные активы, процедуры и ожидаемые выходные данные, которые должна производить тестируемая система. Имея эту спецификацию, тестировщик, который проводит функциональное тестирование работы продукта, может оценить, достигает ли тестируемая система целей, для достижения которых она была разработана.</p>
+
:<p><strong>Сценарии Тестов</strong></p><p>Сценарий теста (test case; в русском сленге, "тест кейс") -- это документ излагающий требования для его проведения. Исследовательское тестирование (exploratory testing) используется для создания сценариев тестов. Ролевое тестирование (scenario testing) задействуется, чтобы установить необходимость нового сценария. Глубоко разработанный сценарий позволяет слабо подготовленному тестировщику успешно провести тест.</p><p>Тестовые сценарии разветвляются на две ветки: формальные и неформальные.</p><ul><li><strong>Формальный</strong> сценарий теста (formal test case) даже наименьшего требования состоит из как минимум двух этапов чётко определённых шагов. Если ожидаемый результат одного этапа позитивен, то другого должен быть негативным. Скажем, при проверке функционала формальный тест должен продемонстрировать, что система делает то, что должна делать и не делает того, что не должна.</li><li><strong>Неформальный</strong> сценарий теста (informal test case) может выбирать для проверки отдельные требования и состоять из одного этапа. Для проектов с невысокими рисками, неформальный сценарий может применяться, пока создаётся формальный.</li></ul><p>Формальность и подробность сценария зависит от важности теста и цены ошибки. Глубоко детализованный сценарий содержит условия, ресурсы, шаги тестировщика, ожидаемые результаты и дополнительные атрибуты теста. Простые сценарии редко содержат все атрибуты.</p><p>Вот пример простого сценария в формате "Дано-Когда-Тогда":<ol type="a"><li>Дано: Веб-страница лектио "Сценарии Тестов" курса под названием "Выбор Профессии",</li><li>Когда: Веб-страница загружена и открыта,<br>и: правильный ответ заключительного вопроса выбран,<br>и: кнопка "Далее" нажата,</li><li>Тогда: Пользователь попадает на следующую веб-страницу.</li></ol></p><p>Ничего не взорвётся и никто не погибнет, если заключительный вопрос лектио не соответствует содержанию лекции. Проверка же безопасности реактора четвёртого энергоблока Чернобыльской атомной электростанции 26 апреля 1986 года привела к его разрушению.</p><p>Огромная цена ошибки обязывает тест быть формальным. Сценарии тестов ядерных реакторов разрабатываются вместе с подробной инструкцией. К проведению проверки тестировщики допускаются только после прохождения специального тренинга. В ходе тренинга все шаги и возможные нештатные ситуации должны детально разбираться.</p><p><i>А теперь, выберите, пожалуйста, лучшее завершение следующего предложения.</i> Судя по тексту выше, примером:</p>
−
<p>Для того чтоб подготовить Тестовый Пример необходимо знать следующую информацию: описание Требования, которое мы должны проверить; объяснение, как проверить систему; версия приложения, файлы данных, операционная система, аппаратное обеспечение, безопасный доступ, физическая или логическая дата, время суток и т.д. </p>
 
−
<p>Не все случаи производительности должны быть очень подробными. Например, один пример теста производительности для этого самого lectio может быть:
 
−
Оцените, отражает ли заключительный вопрос lectio краткую лекцию, которую включает эта lectio.</p>
 
−
<p>Тестовые примеры для Юзабилити-Тестирования редко детализируются; они имеют тенденцию быть более общими, чем для тестирования производительности. Простейший пример теста на удобство использования:
 
−
<p>При использовании протестированной системы сообщайте, если вы чувствуете себя некомфортно, запутались или даже начинаете думать, что делать дальше.
 
−
Регрессионное Тестирование для улучшения пользовательского опыта невозможно; все Юзабилити-Тестирование относится к категории «прогрессивное тестирование».</p>
 
  
−
Тест-кейс — это профессиональная документация тестировщика, последовательность действий направленная на проверку какого-либо функционала, описывающая как придти к фактическому результату.
+
===Варианты===
 +
:негативного ожидаемого результата будет сообщение об ошибке при вводе неверного пароля. / позитивного ожидаемого результата будет сообщение об ошибке при вводе неверного пароля. / формального сценария будет глубоко детализированная спецификация. / неформального сценария будет глубоко детализированная спецификация.
  
−
Набор тест-кейсов называют тест-комплектом. Иногда тест-набор путают с тест-планом. Тест-план описывает какие работы, как и когда должны быть проведены в рамках тестирования продукта, а так же что необходимо для их выполнения.
+
:Следующее лектио -- '''[[Атрибуты Сценариев]]'''
  
−
Зачем нужны тест-кейсы?
+
===Термины===
−
 
+
:[[Требования]], [[Тестовый пример]], [[Юзабилити-тестирование]], [[Регрессионное тестирование]], [[Прогрессивное тестирование]]
−
Тест-кейсы должен помочь нам провести проверку продукта без ознакомления с всей документацией. Написанный один раз, удобный в поддержке тест-кейс сэкономит много времени и сил тестировщикам.
 
−
 
 
−
 
 
−
 
 
−
 
 
−
Не обязательно, но желательно добавить в тест-кейс атрибут история редактирования — это сильно облегчит вам жизнь. Лаконичный журнал изменений, где отраженно: кем, как, и когда был изменен тест-кейс.
 
−
 
 
−
Что еще необходимо знать, перед созданием тест-кейса?
 
−
 
 
−
Во-первых, каждый выполненный тест-кейс, дает нам один из трех результатов:
 
−
 
 
−
1.Положительный результат, если фактический результат равен ожидаемому результату,
 
−
2.Отрицательный результат, если фактический результат не равен ожидаемому результату. В этом случае, найдена ошибка.
 
−
3.Выполнение теста блокировано, если после одного из шагов продолжение теста невозможно. В этом случае так же, найдена ошибка.
 
−
 
 
−
Во-вторых, одним тест-кейсом проверяется одна конкретная вещь, и для этой вещи должен быть только один ожидаемый результат.
 
−
 
 
−
Чего не должно быть в тест-кейсе
 
−
 
 
−
1. Зависимостей от других тест-кейсов;
 
−
2. Нечеткой формулировки шагов или ожидаемого результата;
 
−
3. Отсутствия необходимой для прохождения тест-кейса информации;
 
−
4. Излишней детализации.
 
−
 
 
−
Первого следует избегать, потому что: связанный тест-кейс всегда может быть удален из-за ненадобности или он может быть изменен, в этом случае, станет непонятно как исполнить тест-кейс в которому, есть ссылки.
 
−
 
 
−
Так же из-за зависимости тест-кейсов, может возникнуть ощущение, что тестируемый продукт уже приведет к нужному состоянию благодаря выполнению связанных тест-кейсов.
 
  
−
Со вторым думаю все ясно. Если описание шагов или ожидаемое результата будет не четким, то это блокирует прохождение тест-кейса.
+
==Экзамен==
  
−
В тест-кейса должно быть вся информация, которая необходима для его прохождения. Например, если мы проверяем окно логина на сайте, значит нам понадобится логин и пароль, иначе прохождение этого сценария будет невозможно.
+
===Определения===
 +
:
  
−
Так же не следует слишком детализировать кейс. Например, если мы проверяем возможность создания комментария, то не стоит писать в каком угле экрана должно быть окно логина. Избыточная информация только затрудняет прохождение тест-кейса.
+
===Вопросы экзамена===
−
 
 
−
Сценарное тестирование занимают свою нишу. Я могу себе представить ситуации в тестировании, когда эффективность и воспроизводимость настолько важны, что мы должны написать сценарии для них или их автоматизировать. Например, в случае, когда тестовая платформа регулярно бывает недоступна, как в случае клиент-серверных приложений, в которых есть только несколько настроенных серверов и они должны быть разделены между командами разработки и тестирования. Здравый смысл подсказывает нам, что мы должны заранее тщательно проработать сценарий тестов, чтобы получить максимальную отдачу во время выполнения тестов в выделенное нам время. Исследовательское тестирование особенно полезно в сложных ситуациях тестирования, когда мало что известно о продукте, или как часть подготовки набора сценариев тестов. Основное правило заключается в следующем: исследовательское тестирование используется в тех случаях, когда выполнение следующего теста неочевидно, или когда вы хотите выйти за рамки очевидного. По моему опыту, это происходит в большинстве случаев.
 
−
 
 
−
Если одним сценарием тестируется один объект, то ожидаемый результат должен быть одним.
 
−
 
 
−
===Термины===
 
−
:[[Требования]], [[Тестовый Пример]], [[Юзабилити-тестирование]], [[Регрессионное Тестирование]], [[Прогрессивное Тестирование]]
 
−
 
 
−
===Вопрос(ы)===
 
 
:Судя по прочитанному тексту выше: Регрессионное тестирование вполне возможно для Юзабилити-Тестирования. -- Ложь\Правда
 
:Судя по прочитанному тексту выше: Регрессионное тестирование вполне возможно для Юзабилити-Тестирования. -- Ложь\Правда
−
 
−
:Следующее лектио -- '''[[Атрибуты Сценариев]]'''
 
  
 
[[Category: Лектио]]
 
[[Category: Лектио]]

Текущая версия на 10:26, 21 сентября 2022

Сценарии Тестов (здесь и далее по тексту -- Лектио) -- это часть урока Документы Тестов. В Брацкой Школе, уроки делятся на так называемые лектио, каждое из которых состоит из микролекции и одного или нескольких заключительных вопросов. Урок, в свою очередь, относится к практическому семинару Выбор Профессии.


Материалы

Предшественник этого Лектио -- Задания на Поиск.

Иллюстрации

  • Сценарии Тестов.png

Текст (HTML)

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

Сценарий теста (test case; в русском сленге, "тест кейс") -- это документ излагающий требования для его проведения. Исследовательское тестирование (exploratory testing) используется для создания сценариев тестов. Ролевое тестирование (scenario testing) задействуется, чтобы установить необходимость нового сценария. Глубоко разработанный сценарий позволяет слабо подготовленному тестировщику успешно провести тест.

Тестовые сценарии разветвляются на две ветки: формальные и неформальные.

  • Формальный сценарий теста (formal test case) даже наименьшего требования состоит из как минимум двух этапов чётко определённых шагов. Если ожидаемый результат одного этапа позитивен, то другого должен быть негативным. Скажем, при проверке функционала формальный тест должен продемонстрировать, что система делает то, что должна делать и не делает того, что не должна.
  • Неформальный сценарий теста (informal test case) может выбирать для проверки отдельные требования и состоять из одного этапа. Для проектов с невысокими рисками, неформальный сценарий может применяться, пока создаётся формальный.

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

Вот пример простого сценария в формате "Дано-Когда-Тогда":

  1. Дано: Веб-страница лектио "Сценарии Тестов" курса под названием "Выбор Профессии",
  2. Когда: Веб-страница загружена и открыта,
    и: правильный ответ заключительного вопроса выбран,
    и: кнопка "Далее" нажата,
  3. Тогда: Пользователь попадает на следующую веб-страницу.

Ничего не взорвётся и никто не погибнет, если заключительный вопрос лектио не соответствует содержанию лекции. Проверка же безопасности реактора четвёртого энергоблока Чернобыльской атомной электростанции 26 апреля 1986 года привела к его разрушению.

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

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

Варианты

негативного ожидаемого результата будет сообщение об ошибке при вводе неверного пароля. / позитивного ожидаемого результата будет сообщение об ошибке при вводе неверного пароля. / формального сценария будет глубоко детализированная спецификация. / неформального сценария будет глубоко детализированная спецификация.
Следующее лектио -- Атрибуты Сценариев

Термины

Требования, Тестовый пример, Юзабилити-тестирование, Регрессионное тестирование, Прогрессивное тестирование

Экзамен

Определения

Вопросы экзамена

Судя по прочитанному тексту выше: Регрессионное тестирование вполне возможно для Юзабилити-Тестирования. -- Ложь\Правда
Источник — «https://pravka.bskol.com/w1/index.php?title=Сценарии_Тестов&oldid=26965»