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

Материал из Брацка Правки
Перейти к: навигация, поиск
(Текст)
(Термины)
 
(не показано 28 промежуточных версий 5 участников)
Строка 3: Строка 3:
  
 
==Материалы==
 
==Материалы==
Предшественник этого ''Лектио'' -- [[План или Планирование]].
+
Предшественник этого ''Лектио'' -- [[Инструменты Тестов]].
  
 
===Иллюстрации===
 
===Иллюстрации===
<gallery mode="packed">
+
<gallery mode="packed"> File:Списки_и_Сценарии.png
 
</gallery>
 
</gallery>
  
===Текст===
 
:<p><strong>Списки и Сценарии</strong></p><p>Команды разработчиков цифровых систем используют различные форматы заранее подготовленных планов тестинга. Чаще других встречаются пошаговые инструкции проведения тестов и тестовые спецификации.</p><p>В тестировании, пошаговые инструкции проведения тестов традиционно называются "сценариями" (test case). Стандартпланы тестов написанные в форме сценария
 
AC можно записывать в разных форматах. Есть два наиболее распространенных варианта, и третий вариант - разработать собственный формат:
 
  
    ориентированный на сценарий (Учитывая / Когда / Тогда)
 
    ориентированный на правила (контрольный список)
 
    специальные форматы
 
  
Поскольку первый и второй форматы имеют очень специфическую структуру, мы в основном сосредоточимся на них. Однако вы можете обнаружить, что другие форматы лучше подходят для вашего продукта, поэтому мы вкратце коснемся и их.
+
<gallery mode="packed"> File:Списки_и_Сценарии_рис2.png
Критерии приемки, ориентированные на сценарий
+
</gallery>
  
Сценарийно-ориентированный формат записи AC известен как тип Given / When / Then (GWT).
+
===Текст (HTML)===
 +
:<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>
  
    Учитывая некоторые предварительные условия
+
===Варианты===
    Когда я делаю какое-то действие
+
:спецификация. / сценарий. / ситуативный тест. / натуральное тестирование.
    Тогда я жду результата
 
  
Этот подход унаследован от разработки, основанной на поведении (BDD), и обеспечивает согласованную структуру, которая помогает тестировщикам определять, когда начинать и когда завершать тестирование той или иной функции. Это также сокращает время, затрачиваемое на написание тестовых примеров, поскольку поведение системы описывается заранее.
+
:Следующее лектио -- '''[[Тестировка Изделий]]'''
  
Каждый критерий приемки, написанный в этом формате, содержит следующие утверждения:
+
===Термины===
 
+
:[[Функциональное тестирование]], [[Нефункциональное тестирование]], [[Требования]], [[Регрессионное тестирование]], [[Прогрессивное тестирование]]
    Сценарий - название поведения, которое будет описано
 
    Дано - начальное состояние сценария
 
    Когда - конкретное действие, которое совершает пользователь
 
    Затем - результат действия в «Когда».
 
    И - используется для продолжения любого из трех предыдущих утверждений
 
 
 
В совокупности эти утверждения охватывают все действия, которые пользователь предпринимает для выполнения
 
 
 
Поставьте задачу и ощутите результат.
 
 
 
Давайте посмотрим на несколько примеров.
 
 
 
Пример 1
 
 
 
История пользователя: Как пользователь, я хочу иметь возможность восстановить пароль своей учетной записи, чтобы иметь доступ к своей учетной записи в случае, если я забыл пароль.
 
 
 
Сценарий: Забыли пароль
 
 
 
Дано: пользователь перешел на страницу входа
 
 
 
Когда: пользователь выбрал опцию забытого пароля
 
 
 
И: Ввели действующий адрес электронной почты, чтобы получить ссылку для восстановления пароля.
 
 
 
Затем: Система отправила ссылку на введенный адрес электронной почты.
 
 
 
Дано: пользователь получил ссылку по электронной почте
 
 
 
Когда: пользователь перешел по ссылке, полученной в электронном письме.
 
 
 
Затем: Система позволяет пользователю установить новый пароль.
 
 
 
Пример 2
 
 
 
История пользователя: Как пользователь, я хочу иметь возможность запрашивать наличные со своего счета в банкомате, чтобы получать деньги со своего счета быстро и в разных местах.
 
 
 
Критерии приемки 1:
 
 
 
При условии, что счет кредитоспособен
 
 
 
И: карта действительна
 
 
 
И: в диспенсере есть наличные
 
 
 
Когда: клиент запрашивает наличные
 
 
 
Затем: убедитесь, что счет списан
 
 
 
И: обеспечить выдачу наличных
 
 
 
И: убедитесь, что карта возвращена
 
 
 
Критерии приемки 2:
 
 
 
Учитывая: что на счету овердрафт
 
 
 
И: карта действительна
 
 
 
Когда: клиент запрашивает наличные
 
 
 
Затем: убедитесь, что отображается сообщение об отказе
 
 
 
И: убедитесь, что наличные не выдаются
 
Формат критериев приемлемости, ориентированный на правила
 
  
В некоторых случаях сложно вписать критерии приемки в структуру Given / When / Then. Например, GWT вряд ли пригодится в следующих случаях:
+
==Экзамен==
  
    Вы работаете с пользовательскими историями, которые описывают функциональные возможности системного уровня, требующие других методов обеспечения качества.
+
===Определения===
    Целевая аудитория для критериев приемлемости не нуждается в точных деталях тестовых сценариев.
+
:
    Сценарии GWT не подходят для описания дизайна и ограничений пользовательского опыта функции. Разработчики могут упустить ряд важных деталей.
 
  
Вы можете решить эти случаи с помощью ориентированного на правила формата AC.
+
===Вопросы экзамена===
 
 
Форма, ориентированная на правила, предполагает наличие набора правил, описывающих поведение системы. Исходя из этих правил, можно рисовать конкретные сценарии.
 
 
 
Обычно критерии, составленные с помощью этой формы, выглядят как простой маркированный список. Давайте посмотрим на пример.
 
 
 
пример
 
 
 
История пользователя: как пользователь я хочу использовать поле поиска, чтобы ввести город, название или улицу, чтобы найти подходящие варианты отелей.
 
 
 
Основные критерии приемки интерфейса поиска
 
 
 
    Поле поиска находится на верхней панели
 
    Поиск начинается, когда пользователь нажимает «Поиск».
 
    Поле содержит заполнитель с текстом серого цвета: «Куда вы собираетесь?»
 
    Заполнитель исчезает, когда пользователь начинает печатать
 
    Поиск выполняется, если пользователь вводит город, название отеля, улицу или все вместе
 
    Поиск ведется на английском, французском, немецком и украинском языках.
 
    Пользователь не может набрать более 200 символов.
 
    Поиск не поддерживает специальные символы (символы). Если пользователь ввел специальный символ, покажите предупреждающее сообщение: «Поисковый ввод не может содержать специальные символы».
 
 
 
Другие форматы
 
 
 
Большинство пользовательских историй можно охватить двумя форматами, упомянутыми выше. Однако вы можете придумать свои собственные критерии приемлемости, поскольку они служат своим целям, написаны четко, простым языком и не могут быть неправильно истолкованы. Некоторые команды даже используют простой текст.
 
 
 
===Термины===
 
:[[Функциональное Тестирование]], [[Нефункциональное Тестирование]], [[Требования]], [[Регрессионное Тестирование]], [[Прогрессионное Тесирование]]
 
 
 
===Вопрос(ы)===
 
 
:Какое из приведенных ниже утверждений является правильным: --
 
:Какое из приведенных ниже утверждений является правильным: --
 
Все остальные ответы по существу верны.
 
Все остальные ответы по существу верны.
Строка 136: Строка 37:
 
При тестировании всегда учитываются требования к продукту.
 
При тестировании всегда учитываются требования к продукту.
 
Прогрессивное тестирование гарантирует, что вновь разработанный функционал работает в соответствии с требованиями продукта.
 
Прогрессивное тестирование гарантирует, что вновь разработанный функционал работает в соответствии с требованиями продукта.
 
:Следующее лектио -- '''[[Тестировка Изделий]]'''
 
  
 
[[Category: Лектио]]
 
[[Category: Лектио]]

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

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


Материалы

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

Иллюстрации


Текст (HTML)

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

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

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

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

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

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

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

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

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

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

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

Варианты

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

Термины

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

Экзамен

Определения

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

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

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