Списки и Сценарии — различия между версиями

Материал из Брацка Правки
Перейти к: навигация, поиск
(→‎Текст)
(→‎Термины)
 
(не показано 26 промежуточных версий 5 участников)
Строка 3: Строка 3:
  
 
==Материалы==
 
==Материалы==
−
Предшественник этого ''Лектио'' -- [[План или Планирование]].
+
Предшественник этого ''Лектио'' -- [[Инструменты Тестов]].
  
 
===Иллюстрации===
 
===Иллюстрации===
−
<gallery mode="packed">
+
<gallery mode="packed"> File:Списки_и_Сценарии.png
 
</gallery>
 
</gallery>
  
−
===Текст===
 
−
:<p><strong>Списки и Сценарии</strong></p><p>Команды разработчиков цифровых систем используют различные форматы заранее подготовленных планов тестинга. Чаще других встречаются пошаговые инструкции проведения тестов и тестовые спецификации.</p><p>В тестировании цифровых систем, пошаговые инструкции проведения тестов традиционно называются "сценариями" (test case). Сценарные тесты обыкновенно имитируют действия конечного пользователя и пишутся на основе пользовательских историй (user story). Пользовательские истории -- это один из форматов требований. Стандартный формат состоит из трёх секций:<code><ol><li>Имея права (описывается пользователь или системная роль того, кто получит выгоду от функционала),</li><li>я хочу (описывается желаемый функционал),</li><li>чтобы (описывается выгода функционала.</li></ol></code>
 
  
−
Narrative
 
−
    A short introductory section with the following structure:
 
  
−
        As a: the person or role who will benefit from the feature;
+
<gallery mode="packed"> File:Списки_и_Сценарии_рис2.png
−
        I want: the feature;
+
</gallery>
−
        so that: the benefit or value of the feature.
 
  
−
Acceptance criteria
+
===Текст (HTML)===
−
    A description of each specific scenario of the narrative with the following structure:
+
:<p><strong>Списки и Сценарии</strong></p><p>Команды разработчиков цифровых систем используют различные форматы заранее подготовленных планов тестинга. Чаще других встречаются пошаговые инструкции проведения тестов и тестовые спецификации.</p><p>В тестировании цифровых систем, пошаговые инструкции проведения тестов традиционно называются "сценариями" (test case). Сценарные тесты обыкновенно пишутся на основе пользовательских историй (user story). Пользовательские истории - это один из форматов требований. Стандартный формат такого требования к системе состоит из трёх секций:</p><ol type="a"><li>Имея права (описывается пользователь или системная роль того, кто получит выгоду от функционала),</code></li><li>Я хочу (описывается желаемый функционал),</code></li><li> Чтобы (описывается выгода, которую функционал создаст для пользователя).</code></li></ol><p>Стандартный сценарий теста формируется на базе сценария требования. Вот, например, формат "Дано-Когда-Тогда" (Given-When-Then или GWT):</p><ol type="a"><li>Дано: (описывается начальное состояние сценария),</code></li><li>Когда: (описывается последовательность конкретных действий, которое совершает пользователь),</code></li><li>Тогда: (описывается то, что система должна сделать в ответ на описанную выше последовательность действий).</code></li></ol><p>Сценарий как требования, так и теста, обычно имеет название или другой идентификатор. Утверждения теста описываются простыми предложениями в формате "одно подлежащее, один глагол, одно сказуемое". Каждая секция может иметь несколько утверждений. Каждое утверждение пишется на новой строке. Связка "и" применяется в начале строки для второго и каждого последующего утверждения одной секции.</p><p>Так как сценарий создаётся от имени пользователя, сценарные форматы сложно применить к серверным, а не не пользовательским функционалам. Пошаговая инструкция также не опишет тех тестов, ожидаемые результаты которых относятся к качеству, а не измерениям. Тестирование на удобство пользования, например, может оценивать возможность пользователя самостоятельно создать последовательность шагов. Наконец, квалифицированные тестировщики могут не нуждаться в точных деталях сценариев и затраты на их создание необоснованные.</p><p>Тестовые спецификации могут использоваться как там, где сценарные тесты неприменимы, так и вместо них. Простые тестовые спецификации выглядят как маркированный список характеристик и функций, опросной лист, дефектная ведомость, или карта контрольных проверок.</p><p>Разработчики могут создавать свои форматы. Брацки Техсовет, например, совмещает сценарии и спецификации.</p><p><i>А теперь, выберите, пожалуйста, лучшее завершение следующего предложения.</i> Судя по тексту выше, для плановой проверки Брацких Ферм лучше всех подойдёт:</p>
  
−
        Given: the initial context at the beginning of the scenario, in one or more clauses;
+
===Варианты===
−
        When: the event that triggers the scenario;
+
:спецификация. / сценарий. / ситуативный тест. / натуральное тестирование.
−
        Then: the expected outcome, in one or more clauses.
 
  
−
AC можно записывать в разных форматах. Есть два наиболее распространенных варианта, и третий вариант - разработать собственный формат:
+
:Следующее лектио -- '''[[Тестировка Изделий]]'''
  
−
    ориентированный на сценарий (Учитывая / Когда / Тогда)
+
===Термины===
−
    ориентированный на правила (контрольный список)
+
:[[Функциональное тестирование]], [[Нефункциональное тестирование]], [[Требования]], [[Регрессионное тестирование]], [[Прогрессивное тестирование]]
−
    специальные форматы
 
−
 
 
−
Поскольку первый и второй форматы имеют очень специфическую структуру, мы в основном сосредоточимся на них. Однако вы можете обнаружить, что другие форматы лучше подходят для вашего продукта, поэтому мы вкратце коснемся и их.
 
−
Критерии приемки, ориентированные на сценарий
 
−
 
 
−
Сценарийно-ориентированный формат записи AC известен как тип Given / When / Then (GWT).
 
−
 
 
−
    Учитывая некоторые предварительные условия
 
−
    Когда я делаю какое-то действие
 
−
    Тогда я жду результата
 
−
 
 
−
Этот подход унаследован от разработки, основанной на поведении (BDD), и обеспечивает согласованную структуру, которая помогает тестировщикам определять, когда начинать и когда завершать тестирование той или иной функции. Это также сокращает время, затрачиваемое на написание тестовых примеров, поскольку поведение системы описывается заранее.
 
−
 
 
−
Каждый критерий приемки, написанный в этом формате, содержит следующие утверждения:
 
−
 
 
−
    Сценарий - название поведения, которое будет описано
 
−
    Дано - начальное состояние сценария
 
−
    Когда - конкретное действие, которое совершает пользователь
 
−
    Затем - результат действия в «Когда».
 
−
    И - используется для продолжения любого из трех предыдущих утверждений
 
−
 
 
−
В совокупности эти утверждения охватывают все действия, которые пользователь предпринимает для выполнения
 
−
 
 
−
Поставьте задачу и ощутите результат.
 
−
 
 
−
Давайте посмотрим на несколько примеров.
 
−
 
 
−
Пример 1
 
−
 
 
−
История пользователя: Как пользователь, я хочу иметь возможность восстановить пароль своей учетной записи, чтобы иметь доступ к своей учетной записи в случае, если я забыл пароль.
 
−
 
 
−
Сценарий: Забыли пароль
 
−
 
 
−
Дано: пользователь перешел на страницу входа
 
  
−
Когда: пользователь выбрал опцию забытого пароля
+
==Экзамен==
  
−
И: Ввели действующий адрес электронной почты, чтобы получить ссылку для восстановления пароля.
+
===Определения===
 +
:
  
−
Затем: Система отправила ссылку на введенный адрес электронной почты.
+
===Вопросы экзамена===
−
 
 
−
Дано: пользователь получил ссылку по электронной почте
 
−
 
 
−
Когда: пользователь перешел по ссылке, полученной в электронном письме.
 
−
 
 
−
Затем: Система позволяет пользователю установить новый пароль.
 
−
 
 
−
Пример 2
 
−
 
 
−
История пользователя: Как пользователь, я хочу иметь возможность запрашивать наличные со своего счета в банкомате, чтобы получать деньги со своего счета быстро и в разных местах.
 
−
 
 
−
Критерии приемки 1:
 
−
 
 
−
При условии, что счет кредитоспособен
 
−
 
 
−
И: карта действительна
 
−
 
 
−
И: в диспенсере есть наличные
 
−
 
 
−
Когда: клиент запрашивает наличные
 
−
 
 
−
Затем: убедитесь, что счет списан
 
−
 
 
−
И: обеспечить выдачу наличных
 
−
 
 
−
И: убедитесь, что карта возвращена
 
−
 
 
−
Критерии приемки 2:
 
−
 
 
−
Учитывая: что на счету овердрафт
 
−
 
 
−
И: карта действительна
 
−
 
 
−
Когда: клиент запрашивает наличные
 
−
 
 
−
Затем: убедитесь, что отображается сообщение об отказе
 
−
 
 
−
И: убедитесь, что наличные не выдаются
 
−
Формат критериев приемлемости, ориентированный на правила
 
−
 
 
−
В некоторых случаях сложно вписать критерии приемки в структуру Given / When / Then. Например, GWT вряд ли пригодится в следующих случаях:
 
−
 
 
−
    Вы работаете с пользовательскими историями, которые описывают функциональные возможности системного уровня, требующие других методов обеспечения качества.
 
−
    Целевая аудитория для критериев приемлемости не нуждается в точных деталях тестовых сценариев.
 
−
    Сценарии GWT не подходят для описания дизайна и ограничений пользовательского опыта функции. Разработчики могут упустить ряд важных деталей.
 
−
 
 
−
Вы можете решить эти случаи с помощью ориентированного на правила формата AC.
 
−
 
 
−
Форма, ориентированная на правила, предполагает наличие набора правил, описывающих поведение системы. Исходя из этих правил, можно рисовать конкретные сценарии.
 
−
 
 
−
Обычно критерии, составленные с помощью этой формы, выглядят как простой маркированный список. Давайте посмотрим на пример.
 
−
 
 
−
пример
 
−
 
 
−
История пользователя: как пользователь я хочу использовать поле поиска, чтобы ввести город, название или улицу, чтобы найти подходящие варианты отелей.
 
−
 
 
−
Основные критерии приемки интерфейса поиска
 
−
 
 
−
    Поле поиска находится на верхней панели
 
−
    Поиск начинается, когда пользователь нажимает «Поиск».
 
−
    Поле содержит заполнитель с текстом серого цвета: «Куда вы собираетесь?»
 
−
    Заполнитель исчезает, когда пользователь начинает печатать
 
−
    Поиск выполняется, если пользователь вводит город, название отеля, улицу или все вместе
 
−
    Поиск ведется на английском, французском, немецком и украинском языках.
 
−
    Пользователь не может набрать более 200 символов.
 
−
    Поиск не поддерживает специальные символы (символы). Если пользователь ввел специальный символ, покажите предупреждающее сообщение: «Поисковый ввод не может содержать специальные символы».
 
−
 
 
−
Другие форматы
 
−
 
 
−
Большинство пользовательских историй можно охватить двумя форматами, упомянутыми выше. Однако вы можете придумать свои собственные критерии приемлемости, поскольку они служат своим целям, написаны четко, простым языком и не могут быть неправильно истолкованы. Некоторые команды даже используют простой текст.
 
−
 
 
−
===Термины===
 
−
:[[Функциональное Тестирование]], [[Нефункциональное Тестирование]], [[Требования]], [[Регрессионное Тестирование]], [[Прогрессионное Тесирование]]
 
−
 
 
−
===Вопрос(ы)===
 
 
:Какое из приведенных ниже утверждений является правильным: --
 
:Какое из приведенных ниже утверждений является правильным: --
 
Все остальные ответы по существу верны.
 
Все остальные ответы по существу верны.
Строка 151: Строка 37:
 
При тестировании всегда учитываются требования к продукту.
 
При тестировании всегда учитываются требования к продукту.
 
Прогрессивное тестирование гарантирует, что вновь разработанный функционал работает в соответствии с требованиями продукта.
 
Прогрессивное тестирование гарантирует, что вновь разработанный функционал работает в соответствии с требованиями продукта.
−
 
−
:Следующее лектио -- '''[[Тестировка Изделий]]'''
 
  
 
[[Category: Лектио]]
 
[[Category: Лектио]]

Текущая версия на 20:37, 20 сентября 2022

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


Материалы

Предшественник этого Лектио -- Инструменты Тестов.

Иллюстрации

  • Списки и Сценарии.png


  • Списки и Сценарии рис2.png

Текст (HTML)

Списки и Сценарии

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

В тестировании цифровых систем, пошаговые инструкции проведения тестов традиционно называются "сценариями" (test case). Сценарные тесты обыкновенно пишутся на основе пользовательских историй (user story). Пользовательские истории - это один из форматов требований. Стандартный формат такого требования к системе состоит из трёх секций:

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

Стандартный сценарий теста формируется на базе сценария требования. Вот, например, формат "Дано-Когда-Тогда" (Given-When-Then или GWT):

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

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

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

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

Разработчики могут создавать свои форматы. Брацки Техсовет, например, совмещает сценарии и спецификации.

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

Варианты

спецификация. / сценарий. / ситуативный тест. / натуральное тестирование.
Следующее лектио -- Тестировка Изделий

Термины

Функциональное тестирование, Нефункциональное тестирование, Требования, Регрессионное тестирование, Прогрессивное тестирование

Экзамен

Определения

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

Какое из приведенных ниже утверждений является правильным: --

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

Источник — «https://pravka.bskol.com/w1/index.php?title=Списки_и_Сценарии&oldid=26940»