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

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

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

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


Материалы

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

Иллюстрации


Текст (HTML)

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

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

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

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

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

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

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

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

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

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

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

Варианты

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

Термины

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

Экзамен

Определения

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

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

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