Атрибуты Сценариев — различия между версиями

Материал из Брацка Правки
Перейти к: навигация, поиск
(Новая страница: «Атрибуты Сценариев (здесь и далее по тексту -- ''Лектио'') -- это часть урока Суть Сценари…»)
 
(→‎Термины)
 
(не показаны 32 промежуточные версии 2 участников)
Строка 1: Строка 1:
−
[[Атрибуты Сценариев]] (здесь и далее по тексту -- ''Лектио'') -- это часть урока [[Суть Сценариев Тестов]]. В [[Брацка Школа|Брацкой Школе]], уроки делятся на так называемые [[лектио]], каждое из которых состоит из микролекции и одного или нескольких заключительных вопросов. Урок, в свою очередь, относится к практическому семинару '''[[Выбор Профессии]]'''.
+
[[Атрибуты Сценариев]] (здесь и далее по тексту -- ''Лектио'') -- это часть урока [[Документы Тестов]]. В [[Брацка Школа|Брацкой Школе]], уроки делятся на так называемые [[лектио]], каждое из которых состоит из микролекции и одного или нескольких заключительных вопросов. Урок, в свою очередь, относится к практическому семинару '''[[Выбор Профессии]]'''.
  
  
Строка 9: Строка 9:
 
</gallery>
 
</gallery>
  
−
===Текст===
+
===Текст (HTML)===
−
:<p><strong>Атрибуты Сценариев</strong></p><p>Сценарий теста (test case; в русском сленге, "тест кейс") -- это документация теста, включающая набор требований для его проведения. В системной инженерии задание на функциональный тест, например, определяет входные данные, внешние факторы, доступные активы, процедуры и ожидаемые выходные данные, которые должна производить тестируемая система. Имея эту спецификацию, тестировщик, который проводит функциональное тестирование работы продукта, может оценить, достигает ли тестируемая система целей, для достижения которых она была разработана.</p>
+
:<p><strong>Атрибуты Сценариев</strong></p><p>Сценарий теста (test case) описывает атрибуты теста. Как документ, сценарий может быть коротким или долгим.</p><p>Короткие сценарии могут состоять из одного предложения. В формате "Дано-Когда-Тогда" это предложение сформулирует тестируемый объект (то есть то, что "дано"), действие тестировщика (то есть "когда") и ожидаемый результат (или "тогда"). Глубоко детализованные документы охватывают условия, ресурсы, шаги тестировщика, ожидаемые результаты и дополнительные атрибуты.</p><p>Если тест проводится не одним заходом и этапов несколько, то основные атрибуты прописываются для каждого этапа.<ol type="a"><li>Условия определяют тестирующий субъект, тестируемый объект и среду теста. Некоторые условия могут не иметь прямого отношения к объекту тестирования и должны быть выполнены до или после основной части теста. Предварительные требования должны быть удовлетворены до шагов тестировщика.</li><li>Ресурсы задают инфраструктуру, инструменты, средства, расходные материалы и участие тех людей, которые не являются тестировщиками. Права доступа -- это также ресурс. Например, если проверяется закрытый от публики функционал, тестировщику требуется имя пользователя и пароль.</li><li>Шаги тестировщика показывают последовательность действий тестировщика.</li><li>Ожидаемый результат -- то, что должно случиться или появиться после выполнения шагов тестировщика. Если одним сценарием тестируется один объект, то ожидаемый результат должен быть одним. Сопоставление фактического результата с ожидаемым даёт итог теста.</li></ol></p><p>В зависимости от потребностей, сценарии могут дополнительно включать:<ul><li>Название, тема, краткое содержание теста и другие идентификаторы стандартно задействуются предприятиями для архивирования, хранения и нахождения документа.</li><li>Категория теста. Воздействующий или непроникающий, обследование или испытание, проверочный или приёмный, функциональный или нет и, если нет, то какого типа. Если не достаточно описан субъект -- автоматизированный или ручной, а также белый, чёрный или серый ящик.</li><li>История теста и его сценария, авторы, когда добавлен и история прогонов могут быть полезны для работы над возвратными тестами.</li></ul></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:28, 21 сентября 2022

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


Материалы

Предшественник этого Лектио -- Сценарии Тестов.

Иллюстрации

Текст (HTML)

Атрибуты Сценариев

Сценарий теста (test case) описывает атрибуты теста. Как документ, сценарий может быть коротким или долгим.

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

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

  1. Условия определяют тестирующий субъект, тестируемый объект и среду теста. Некоторые условия могут не иметь прямого отношения к объекту тестирования и должны быть выполнены до или после основной части теста. Предварительные требования должны быть удовлетворены до шагов тестировщика.
  2. Ресурсы задают инфраструктуру, инструменты, средства, расходные материалы и участие тех людей, которые не являются тестировщиками. Права доступа -- это также ресурс. Например, если проверяется закрытый от публики функционал, тестировщику требуется имя пользователя и пароль.
  3. Шаги тестировщика показывают последовательность действий тестировщика.
  4. Ожидаемый результат -- то, что должно случиться или появиться после выполнения шагов тестировщика. Если одним сценарием тестируется один объект, то ожидаемый результат должен быть одним. Сопоставление фактического результата с ожидаемым даёт итог теста.

В зависимости от потребностей, сценарии могут дополнительно включать:

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

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

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

Варианты

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

Термины

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

Экзамен

Определения

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

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