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

Матеріал з Брацка Правка
Перейти до: навігація, пошук
(Термины)
(Материалы)
 
(Не показано 4 проміжні версії 2 користувачів)
Рядок 1: Рядок 1:
[[Списки и Сценарии]] (здесь и далее по тексту -- ''Лектио'') -- это часть урока [[Суть Проверки Работ]]. В [[Брацка Школа|Брацкой Школе]], уроки делятся на так называемые [[лектио]], каждое из которых состоит из микролекции и одного или нескольких заключительных вопросов. Урок, в свою очередь, относится к практическому семинару '''[[Выбор Профессии]]'''.
+
[[Списки та Сценарії]] (тут і далі по тексту -- ''Лектіо'') -- це частина уроку [[Суть Проверки Работ|Суть Перевірки Робіт]]. У [[Брацка Школа|Брацькій Школі]], уроки діляться на так звані [[лектио|лектіо]], кожне з яких складається з мікролекції та одного або декількох заключних питань. Урок, своєю чергою, належить до курсу '''[[Выбор Профессии|Вибір Професії]]'''.
  
  
 
==Материалы==
 
==Материалы==
Предшественник этого ''Лектио'' -- [[Инструменты Тестов]].
+
Предшественник этого ''Лектио'' -- [[Заранее или по Ходу]].
  
 
===Иллюстрации===
 
===Иллюстрации===
Рядок 15: Рядок 15:
  
 
===Текст (HTML)===
 
===Текст (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>
+
:<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>
  
===Варианты===
+
===Варіанти===
:спецификация. / сценарий. / ситуативный тест. / натуральное тестирование.
+
: Специфікація. / сценарій. / ситуативний тест. / натуральне тестування.
  
 
:Следующее лектио -- '''[[Тестировка Изделий]]'''
 
:Следующее лектио -- '''[[Тестировка Изделий]]'''

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

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


Материалы

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

Иллюстрации


Текст (HTML)

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

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

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

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

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

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

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

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

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

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

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

Варіанти

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

Термины

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

Экзамен

Определения

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

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

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