Списки и Сценарии — различия между версиями
Gary (обсуждение | вклад) (→Текст) |
Sonya (обсуждение | вклад) (→Термины) |
||
| (не показаны 23 промежуточные версии 5 участников) | |||
| Строка 3: | Строка 3: | ||
==Материалы== | ==Материалы== | ||
| − | Предшественник этого ''Лектио'' -- [[ | + | Предшественник этого ''Лектио'' -- [[Инструменты Тестов]]. |
===Иллюстрации=== | ===Иллюстрации=== | ||
| − | <gallery mode="packed"> | + | <gallery mode="packed"> File:Списки_и_Сценарии.png |
</gallery> | </gallery> | ||
| − | |||
| − | |||
| + | <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> | ||
| − | + | ===Варианты=== | |
| − | + | :спецификация. / сценарий. / ситуативный тест. / натуральное тестирование. | |
| − | |||
| − | + | :Следующее лектио -- '''[[Тестировка Изделий]]''' | |
| − | + | ===Термины=== | |
| − | + | :[[Функциональное тестирование]], [[Нефункциональное тестирование]], [[Требования]], [[Регрессионное тестирование]], [[Прогрессивное тестирование]] | |
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | + | ==Экзамен== | |
| − | === | + | ===Определения=== |
| − | : | + | : |
| − | === | + | ===Вопросы экзамена=== |
:Какое из приведенных ниже утверждений является правильным: -- | :Какое из приведенных ниже утверждений является правильным: -- | ||
Все остальные ответы по существу верны. | Все остальные ответы по существу верны. | ||
| Строка 55: | Строка 37: | ||
При тестировании всегда учитываются требования к продукту. | При тестировании всегда учитываются требования к продукту. | ||
Прогрессивное тестирование гарантирует, что вновь разработанный функционал работает в соответствии с требованиями продукта. | Прогрессивное тестирование гарантирует, что вновь разработанный функционал работает в соответствии с требованиями продукта. | ||
| − | |||
| − | |||
[[Category: Лектио]] | [[Category: Лектио]] | ||
Текущая версия на 20:37, 20 сентября 2022
Списки и Сценарии (здесь и далее по тексту -- Лектио) -- это часть урока Суть Проверки Работ. В Брацкой Школе, уроки делятся на так называемые лектио, каждое из которых состоит из микролекции и одного или нескольких заключительных вопросов. Урок, в свою очередь, относится к практическому семинару Выбор Профессии.
Содержание
Материалы
Предшественник этого Лектио -- Инструменты Тестов.
Иллюстрации
Текст (HTML)
Списки и Сценарии
Команды разработчиков цифровых систем используют различные форматы заранее подготовленных планов тестинга. Чаще других встречаются пошаговые инструкции проведения тестов и тестовые спецификации.
В тестировании цифровых систем, пошаговые инструкции проведения тестов традиционно называются "сценариями" (test case). Сценарные тесты обыкновенно пишутся на основе пользовательских историй (user story). Пользовательские истории - это один из форматов требований. Стандартный формат такого требования к системе состоит из трёх секций:
- Имея права (описывается пользователь или системная роль того, кто получит выгоду от функционала),
- Я хочу (описывается желаемый функционал),
- Чтобы (описывается выгода, которую функционал создаст для пользователя).
Стандартный сценарий теста формируется на базе сценария требования. Вот, например, формат "Дано-Когда-Тогда" (Given-When-Then или GWT):
- Дано: (описывается начальное состояние сценария),
- Когда: (описывается последовательность конкретных действий, которое совершает пользователь),
- Тогда: (описывается то, что система должна сделать в ответ на описанную выше последовательность действий).
Сценарий как требования, так и теста, обычно имеет название или другой идентификатор. Утверждения теста описываются простыми предложениями в формате "одно подлежащее, один глагол, одно сказуемое". Каждая секция может иметь несколько утверждений. Каждое утверждение пишется на новой строке. Связка "и" применяется в начале строки для второго и каждого последующего утверждения одной секции.
Так как сценарий создаётся от имени пользователя, сценарные форматы сложно применить к серверным, а не не пользовательским функционалам. Пошаговая инструкция также не опишет тех тестов, ожидаемые результаты которых относятся к качеству, а не измерениям. Тестирование на удобство пользования, например, может оценивать возможность пользователя самостоятельно создать последовательность шагов. Наконец, квалифицированные тестировщики могут не нуждаться в точных деталях сценариев и затраты на их создание необоснованные.
Тестовые спецификации могут использоваться как там, где сценарные тесты неприменимы, так и вместо них. Простые тестовые спецификации выглядят как маркированный список характеристик и функций, опросной лист, дефектная ведомость, или карта контрольных проверок.
Разработчики могут создавать свои форматы. Брацки Техсовет, например, совмещает сценарии и спецификации.
А теперь, выберите, пожалуйста, лучшее завершение следующего предложения. Судя по тексту выше, для плановой проверки Брацких Ферм лучше всех подойдёт:
Варианты
- спецификация. / сценарий. / ситуативный тест. / натуральное тестирование.
- Следующее лектио -- Тестировка Изделий
Термины
- Функциональное тестирование, Нефункциональное тестирование, Требования, Регрессионное тестирование, Прогрессивное тестирование
Экзамен
Определения
Вопросы экзамена
- Какое из приведенных ниже утверждений является правильным: --
Все остальные ответы по существу верны. Регрессионное тестирование - это разновидность функционального тестирования. Пользовательские истории, использованные для последней разработки, могут быть отлично использованы для прогрессивного тестирования. При тестировании всегда учитываются требования к продукту. Прогрессивное тестирование гарантирует, что вновь разработанный функционал работает в соответствии с требованиями продукта.
