Відмінності між версіями «Списки та Сценарії»

Матеріал з Брацка Правка
Перейти до: навігація, пошук
(→‎Текст)
(→‎Материалы)
 
(Не показані 28 проміжних версій 7 користувачів)
Рядок 1: Рядок 1:
−
[[Списки и Сценарии]] (здесь и далее по тексту -- ''Лектио'') -- это часть урока [[Суть Проверки Работ]]. В [[Брацка Школа|Брацкой Школе]], уроки делятся на так называемые [[лектио]], каждое из которых состоит из микролекции и одного или нескольких заключительных вопросов. Урок, в свою очередь, относится к практическому семинару '''[[Выбор Профессии]]'''.
+
[[Списки та Сценарії]] (тут і далі по тексту -- ''Лектіо'') -- це частина уроку [[Суть Проверки Работ|Суть Перевірки Робіт]]. У [[Брацка Школа|Брацькій Школі]], уроки діляться на так звані [[лектио|лектіо]], кожне з яких складається з мікролекції та одного або декількох заключних питань. Урок, своєю чергою, належить до курсу '''[[Выбор Профессии|Вибір Професії]]'''.
  
  
 
==Материалы==
 
==Материалы==
−
Предшественник этого ''Лектио'' -- [[План или Планирование]].
+
Предшественник этого ''Лектио'' -- [[Заранее или по Ходу]].
  
 
===Иллюстрации===
 
===Иллюстрации===
−
<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>
  
−
В некоторых случаях сложно вписать критерии приемки в структуру 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>
  
−
    Вы работаете с пользовательскими историями, которые описывают функциональные возможности системного уровня, требующие других методов обеспечения качества.
+
===Варіанти===
−
    Целевая аудитория для критериев приемлемости не нуждается в точных деталях тестовых сценариев.
+
: Специфікація. / сценарій. / ситуативний тест. / натуральне тестування.
−
    Сценарии GWT не подходят для описания дизайна и ограничений пользовательского опыта функции. Разработчики могут упустить ряд важных деталей.
 
  
−
Вы можете решить эти случаи с помощью ориентированного на правила формата AC.
+
:Следующее лектио -- '''[[Тестировка Изделий]]'''
  
−
Форма, ориентированная на правила, предполагает наличие набора правил, описывающих поведение системы. Исходя из этих правил, можно рисовать конкретные сценарии.
+
===Термины===
−
 
+
:[[Функциональное тестирование]], [[Нефункциональное тестирование]], [[Требования]], [[Регрессионное тестирование]], [[Прогрессивное тестирование]]
−
Обычно критерии, составленные с помощью этой формы, выглядят как простой маркированный список. Давайте посмотрим на пример.
 
−
 
 
−
пример
 
−
 
 
−
История пользователя: как пользователь я хочу использовать поле поиска, чтобы ввести город, название или улицу, чтобы найти подходящие варианты отелей.
 
−
 
 
−
Основные критерии приемки интерфейса поиска
 
−
 
 
−
    Поле поиска находится на верхней панели
 
−
    Поиск начинается, когда пользователь нажимает «Поиск».
 
−
    Поле содержит заполнитель с текстом серого цвета: «Куда вы собираетесь?»
 
−
    Заполнитель исчезает, когда пользователь начинает печатать
 
−
    Поиск выполняется, если пользователь вводит город, название отеля, улицу или все вместе
 
−
    Поиск ведется на английском, французском, немецком и украинском языках.
 
−
    Пользователь не может набрать более 200 символов.
 
−
    Поиск не поддерживает специальные символы (символы). Если пользователь ввел специальный символ, покажите предупреждающее сообщение: «Поисковый ввод не может содержать специальные символы».
 
−
 
 
−
Другие форматы
 
  
−
Большинство пользовательских историй можно охватить двумя форматами, упомянутыми выше. Однако вы можете придумать свои собственные критерии приемлемости, поскольку они служат своим целям, написаны четко, простым языком и не могут быть неправильно истолкованы. Некоторые команды даже используют простой текст.
+
==Экзамен==
  
−
===Термины===
+
===Определения===
−
:[[Функциональное Тестирование]], [[Нефункциональное Тестирование]], [[Требования]], [[Регрессионное Тестирование]], [[Прогрессионное Тесирование]]
+
:
  
−
===Вопрос(ы)===
+
===Вопросы экзамена===
 
:Какое из приведенных ниже утверждений является правильным: --
 
:Какое из приведенных ниже утверждений является правильным: --
 
Все остальные ответы по существу верны.
 
Все остальные ответы по существу верны.
Рядок 55: Рядок 37:
 
При тестировании всегда учитываются требования к продукту.
 
При тестировании всегда учитываются требования к продукту.
 
Прогрессивное тестирование гарантирует, что вновь разработанный функционал работает в соответствии с требованиями продукта.
 
Прогрессивное тестирование гарантирует, что вновь разработанный функционал работает в соответствии с требованиями продукта.
−
 
−
:Следующее лектио -- '''[[Тестировка Изделий]]'''
 
  
 
[[Category: Лектио]]
 
[[Category: Лектио]]

Поточна версія на 13:24, 26 листопада 2022

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


Материалы

Предшественник этого Лектио -- Заранее или по Ходу.

Иллюстрации

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


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

Текст (HTML)

Списки та Сценарії

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

У тестуванні цифрових систем покрокові інструкції проведення тестів традиційно називаються "сценаріями" (test case). Сценарні тести зазвичай пишуться на основі історій користувача (user story). Історії користувача - це один з форматів вимог. Стандартний формат такої вимоги до системи складається з трьох секцій:

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

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

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

Сценарій як вимоги, так і тесту зазвичай має назву або інший ідентифікатор. Твердження тесту описуються простими реченнями у форматі "один підмет, одне дієслово, один присудок". Кожна секція може мати кілька тверджень. Кожне твердження пишеться на новому рядку. Зв'язка "і" застосовується на початку рядка для другого та кожного наступного затвердження однієї секції.

Оскільки сценарій створюється від імені користувача, сценарні формати складно застосувати до серверних, а не користувальницьких функціоналів. Покрокова інструкція також не опише ті тести, очікувані результати яких відносяться до якості, а не вимірювань. Тестування на зручність користування, наприклад, може оцінювати можливість користувача самостійно створити послідовність кроків. Нарешті, кваліфіковані тестувальники можуть не потребувати точних деталей сценаріїв та витрати на їх створення необґрунтовані.

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

Розробники можуть створювати свої формати. Брацька Техрада, наприклад, поєднує сценарії та специфікації.

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

Варіанти

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

Термины

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

Экзамен

Определения

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

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

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

Отримано з https://pravka.idosvid.com/w2/index.php?title=Списки_та_Сценарії&oldid=32015