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