Атрибуты Сценариев — различия между версиями
Gary (обсуждение | вклад) (→Текст) |
Gary (обсуждение | вклад) (→Текст) |
||
Строка 8: | Строка 8: | ||
<gallery mode="packed"> | <gallery mode="packed"> | ||
</gallery> | </gallery> | ||
+ | |||
===Текст=== | ===Текст=== | ||
:<p><strong>Атрибуты Сценариев</strong></p><p>Сценарий теста (test case) описывает тест. Сценарии охватывают условия, ресурсы, шаги тестировщика, ожидаемые результаты и дополнительные атрибуты. Если тест проводится не одним заходом и этапов несколько, то основные атрибуты прописываются для каждого этапа.<ol type="a"><li>Условия описывают тестирующий субъект, тестируемый объект и среду теста. Некоторые тесты содержат предварительные требования, то есть те условия, которые должны предшествовать шагам тестировщика. Эти условия могут не иметь прямого отношения к объекту тестирования, но должны быть выполнены до начала основной части теста.</li><li>Ресурсы описывают необходимую инфраструктуру, инструменты, средства, расходные материалы и участие тех людей, которые не являются тестировщиками. В информационных технологиях, ресурсом также являются права доступа. Например, если проверяется закрытый от публики функционал, тестировщику требуется имя пользователя и пароль.</li><li>Шаги тестировщика описывают последовательность тех действий, которые тестировщик должен совершить для получения ожидаемого результата.</li><li>Ожидаемый результат -- то, что должно случиться после выполнения шагов. Если одним сценарием тестируется один объект, то ожидаемый результат должен быть одним. Сопоставление фактического результата с ожидаемым даёт итог теста.</li></ol></p><p>В зависимости от потребностей, сценарии могут дополнительно включать:<ul><li>Название, другие идентификаторы, тема, краткое содержание теста. На предприятиях, эти метаданные стандартно задействуются для архивирования, хранения и нахождения документа.</li><li>Категория теста. Воздействующий или непроникающий, обследование или испытание, функциональный или нет и, если нет, то какого типа, проверочный или приёмный.</li><li>История теста, его автор или авторы, когда добавлен, когда прогонялся возвратным. Если не достаточно описан субъект -- автоматизированный или ручной, а также, белый, чёрный или серый ящик.</li><li>История тестового сценария. Разработки как теста, так и его сценария -- это проекты и их история важна для их развития.</li></ul></p><p>Тесты не созданы одинаковыми. Сценарии функциональных тестов требуют больших деталей, чем, скажем, сценарии юзабилити-тестов. И, наоборот, излишняя деталировка повредит им. Значительная часть тестов на удобство пользования проводится без сценариев вообще, по заданиям типа:<blockquote><code>На таком-то веб-сайте найдите такой-то контакт и сообщите о каждом месте, где Вы чувствовали себя некомфортно, запутались или начали думать, что Вам делать дальше.</code></blockquote> | :<p><strong>Атрибуты Сценариев</strong></p><p>Сценарий теста (test case) описывает тест. Сценарии охватывают условия, ресурсы, шаги тестировщика, ожидаемые результаты и дополнительные атрибуты. Если тест проводится не одним заходом и этапов несколько, то основные атрибуты прописываются для каждого этапа.<ol type="a"><li>Условия описывают тестирующий субъект, тестируемый объект и среду теста. Некоторые тесты содержат предварительные требования, то есть те условия, которые должны предшествовать шагам тестировщика. Эти условия могут не иметь прямого отношения к объекту тестирования, но должны быть выполнены до начала основной части теста.</li><li>Ресурсы описывают необходимую инфраструктуру, инструменты, средства, расходные материалы и участие тех людей, которые не являются тестировщиками. В информационных технологиях, ресурсом также являются права доступа. Например, если проверяется закрытый от публики функционал, тестировщику требуется имя пользователя и пароль.</li><li>Шаги тестировщика описывают последовательность тех действий, которые тестировщик должен совершить для получения ожидаемого результата.</li><li>Ожидаемый результат -- то, что должно случиться после выполнения шагов. Если одним сценарием тестируется один объект, то ожидаемый результат должен быть одним. Сопоставление фактического результата с ожидаемым даёт итог теста.</li></ol></p><p>В зависимости от потребностей, сценарии могут дополнительно включать:<ul><li>Название, другие идентификаторы, тема, краткое содержание теста. На предприятиях, эти метаданные стандартно задействуются для архивирования, хранения и нахождения документа.</li><li>Категория теста. Воздействующий или непроникающий, обследование или испытание, функциональный или нет и, если нет, то какого типа, проверочный или приёмный.</li><li>История теста, его автор или авторы, когда добавлен, когда прогонялся возвратным. Если не достаточно описан субъект -- автоматизированный или ручной, а также, белый, чёрный или серый ящик.</li><li>История тестового сценария. Разработки как теста, так и его сценария -- это проекты и их история важна для их развития.</li></ul></p><p>Тесты не созданы одинаковыми. Сценарии функциональных тестов требуют больших деталей, чем, скажем, сценарии юзабилити-тестов. И, наоборот, излишняя деталировка повредит им. Значительная часть тестов на удобство пользования проводится без сценариев вообще, по заданиям типа:<blockquote><code>На таком-то веб-сайте найдите такой-то контакт и сообщите о каждом месте, где Вы чувствовали себя некомфортно, запутались или начали думать, что Вам делать дальше.</code></blockquote> | ||
+ | |||
+ | Чего не должно быть в тест-кейсе | ||
+ | |||
+ | 1. Зависимостей от других тест-кейсов; | ||
+ | 2. Нечеткой формулировки шагов или ожидаемого результата; | ||
+ | 3. Отсутствия необходимой для прохождения тест-кейса информации; | ||
+ | 4. Излишней детализации. | ||
+ | |||
+ | Первого следует избегать, потому что: связанный тест-кейс всегда может быть удален из-за ненадобности или он может быть изменен, в этом случае, станет непонятно как исполнить тест-кейс в которому, есть ссылки. | ||
+ | |||
+ | Так же из-за зависимости тест-кейсов, может возникнуть ощущение, что тестируемый продукт уже приведет к нужному состоянию благодаря выполнению связанных тест-кейсов. | ||
===Термины=== | ===Термины=== |
Версия 02:48, 27 января 2021
Атрибуты Сценариев (здесь и далее по тексту -- Лектио) -- это часть урока Суть Сценариев Тестов. В Брацкой Школе, уроки делятся на так называемые лектио, каждое из которых состоит из микролекции и одного или нескольких заключительных вопросов. Урок, в свою очередь, относится к практическому семинару Выбор Профессии.
Содержание
Материалы
Предшественник этого Лектио -- Сценарии Тестов.
Иллюстрации
Текст
Атрибуты Сценариев
Сценарий теста (test case) описывает тест. Сценарии охватывают условия, ресурсы, шаги тестировщика, ожидаемые результаты и дополнительные атрибуты. Если тест проводится не одним заходом и этапов несколько, то основные атрибуты прописываются для каждого этапа.
- Условия описывают тестирующий субъект, тестируемый объект и среду теста. Некоторые тесты содержат предварительные требования, то есть те условия, которые должны предшествовать шагам тестировщика. Эти условия могут не иметь прямого отношения к объекту тестирования, но должны быть выполнены до начала основной части теста.
- Ресурсы описывают необходимую инфраструктуру, инструменты, средства, расходные материалы и участие тех людей, которые не являются тестировщиками. В информационных технологиях, ресурсом также являются права доступа. Например, если проверяется закрытый от публики функционал, тестировщику требуется имя пользователя и пароль.
- Шаги тестировщика описывают последовательность тех действий, которые тестировщик должен совершить для получения ожидаемого результата.
- Ожидаемый результат -- то, что должно случиться после выполнения шагов. Если одним сценарием тестируется один объект, то ожидаемый результат должен быть одним. Сопоставление фактического результата с ожидаемым даёт итог теста.
В зависимости от потребностей, сценарии могут дополнительно включать:
- Название, другие идентификаторы, тема, краткое содержание теста. На предприятиях, эти метаданные стандартно задействуются для архивирования, хранения и нахождения документа.
- Категория теста. Воздействующий или непроникающий, обследование или испытание, функциональный или нет и, если нет, то какого типа, проверочный или приёмный.
- История теста, его автор или авторы, когда добавлен, когда прогонялся возвратным. Если не достаточно описан субъект -- автоматизированный или ручной, а также, белый, чёрный или серый ящик.
- История тестового сценария. Разработки как теста, так и его сценария -- это проекты и их история важна для их развития.
Тесты не созданы одинаковыми. Сценарии функциональных тестов требуют больших деталей, чем, скажем, сценарии юзабилити-тестов. И, наоборот, излишняя деталировка повредит им. Значительная часть тестов на удобство пользования проводится без сценариев вообще, по заданиям типа:
На таком-то веб-сайте найдите такой-то контакт и сообщите о каждом месте, где Вы чувствовали себя некомфортно, запутались или начали думать, что Вам делать дальше.
Чего не должно быть в тест-кейсе
1. Зависимостей от других тест-кейсов; 2. Нечеткой формулировки шагов или ожидаемого результата; 3. Отсутствия необходимой для прохождения тест-кейса информации; 4. Излишней детализации.
Первого следует избегать, потому что: связанный тест-кейс всегда может быть удален из-за ненадобности или он может быть изменен, в этом случае, станет непонятно как исполнить тест-кейс в которому, есть ссылки.
Так же из-за зависимости тест-кейсов, может возникнуть ощущение, что тестируемый продукт уже приведет к нужному состоянию благодаря выполнению связанных тест-кейсов.
Термины
- Требования, Тестовый Пример, Юзабилити-тестирование, Регрессионное Тестирование, Прогрессивное Тестирование
Вопрос(ы)
- Судя по прочитанному тексту выше: Регрессионное тестирование вполне возможно для Юзабилити-Тестирования. -- Ложь\Правда
- Следующее лектио -- Проверка и Приёмка