Списки и Сценарии — различия между версиями
Gary (обсуждение | вклад) (→Текст) |
Gary (обсуждение | вклад) (→Текст) |
||
| Строка 10: | Строка 10: | ||
===Текст=== | ===Текст=== | ||
| − | :<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><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>Тестовые спецификации могут использоваться как там, где сценарные тесты неприменимы, так и вместо них. Простые тестовые спецификации выглядят как маркированный список характеристик или функций, опросной лист, дефектная ведомость, или карта контрольных проверок.</p><p>Разработчики могут создавать свои форматы. Брацки Техсовет, например, совмещает сценарии и спецификации.</p> |
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
===Термины=== | ===Термины=== | ||
Версия 22:21, 30 января 2021
Списки и Сценарии (здесь и далее по тексту -- Лектио) -- это часть урока Суть Проверки Работ. В Брацкой Школе, уроки делятся на так называемые лектио, каждое из которых состоит из микролекции и одного или нескольких заключительных вопросов. Урок, в свою очередь, относится к практическому семинару Выбор Профессии.
Содержание
Материалы
Предшественник этого Лектио -- План или Планирование.
Иллюстрации
Текст
Списки и Сценарии
Команды разработчиков цифровых систем используют различные форматы заранее подготовленных планов тестинга. Чаще других встречаются пошаговые инструкции проведения тестов и тестовые спецификации.
В тестировании цифровых систем, пошаговые инструкции проведения тестов традиционно называются "сценариями" (test case). Сценарные тесты обыкновенно имитируют действия конечного пользователя и пишутся на основе пользовательских историй (user story). Пользовательские истории -- это один из форматов требований. Стандартный формат такого требования к системе состоит из трёх секций:
Имея права (описывается пользователь или системная роль того, кто получит выгоду от функционала),я хочу (описывается желаемый функционал),чтобы (описывается выгода функционала).
Стандартный сценарий теста формируется на базе сценария требования. Вот, например, формат ДКТ (Дано-Когда-Тогда; на языке оригинала, Given-When-Then или GWT):
Дано: (описывается начальное состояние сценария),Когда: (описывается последовательность конкретных действий, которое совершает пользователь),Затем: (описывается то, что система должна сделать в ответ на последовательность действий описанную выше).
Сценарий как требования, так и теста, обычно имеет название или другой идентификатор. Описания теста делаются простыми предложениями в формате "одно подлежащее, один глагол, одно сказуемое". Каждая секция может иметь несколько утверждений. Каждое утверждение пишется на новой строке. Связка "и" применяется в начале строки для второго и каждого последующего утверждения одной секции.
Так как сценарий создаётся от имени пользователя, сценарные форматы сложно применить к серверным, а не не пользовательским фунционалам. Пошаговая инструкция также не опишет тех тестов, ожидаемые результаты которых относятся к качеству, не измерениям. Тестирование на удобство пользования, например, может оценивать возможность пользователя самостоятельно создать последовательность шагов. Наконец, квалифицированные тестировщики могут не нуждаться в точных деталях тестовых сценариев и нет необходимости в трате времени на их создание.
Тестовые спецификации могут использоваться как там, где сценарные тесты неприменимы, так и вместо них. Простые тестовые спецификации выглядят как маркированный список характеристик или функций, опросной лист, дефектная ведомость, или карта контрольных проверок.
Разработчики могут создавать свои форматы. Брацки Техсовет, например, совмещает сценарии и спецификации.
Термины
- Функциональное Тестирование, Нефункциональное Тестирование, Требования, Регрессионное Тестирование, Прогрессионное Тесирование
Вопрос(ы)
- Какое из приведенных ниже утверждений является правильным: --
Все остальные ответы по существу верны. Регрессионное тестирование - это разновидность функционального тестирования. Пользовательские истории, использованные для последней разработки, могут быть отлично использованы для прогрессивного тестирования. При тестировании всегда учитываются требования к продукту. Прогрессивное тестирование гарантирует, что вновь разработанный функционал работает в соответствии с требованиями продукта.
- Следующее лектио -- Тестировка Изделий
