Тестовый сценарий, тестовый пакет. ЛЗ - Тестовый сценарий, тестовый пакет. Тестовый сценарий, тестовый пакет
 Скачать 118.12 Kb.
|
|
Лекционное занятие Тема: Тестовый сценарий, тестовый пакет. Цель: Ознакомиться с практическим применением техник тест дизайна при разработке тест кейсов. Анализом требований. Определением набора тестовых данных. Разработкой шаблона теста. Написанием тест кейсов на основании первоначальных требований, тестовых данных и шагов теста. Оборудование: персональный компьютер, мультимедиа-проектор, MS Visio, Visual Studio, MS Office, методические рекомендации к проведению лекционных занятий, Гагарина, Л. Г. Технология разработки программного обеспечения: учеб. пособие / Л. Г. Гагарина, Е. В. Кокорева, Б. Д. Виснадул; Под ред. Л. Г. Гагариной. - М.: ФОРУМ: ИНФРА-М, 2017.-400 с., инструкционная карта для проведения лекционного занятия. Тестирование ПО (Software Testing) — проверка соответствия между реальным и ожидаемым поведением программы, проводится на наборе тестов, который выбирается некоторым образом. Чем занимаются в тестировании: планированием работ (Test Management) проектированием тестов (Test Design) — этап, на котором создаются тестовые сценарии (тест кейсы), в соответствии с определёнными ранее критериями. Т.е., определяется, КАК будет тестироваться продукт. выполнением тестирования (Test Execution) анализом результатов (Test Analysis) Основные цели тестирования техническая: предоставление актуальной информации о состоянии продукта на данный момент. коммерческая: повышение лояльности к компании и продукту, т.к. любой обнаруженный дефект негативно влияет на доверие пользователей. Следует уметь различать, что: Error — это ошибка пользователя, то есть он пытается использовать программу иным способом (например, вводит буквы в поля, где требуется вводить цифры). В качественной программе предусмотрены такие ситуации и выдаются сообщение об ошибке (error message). Bug (defect) — это ошибка программиста (или дизайнера или ещё кого, кто принимает участие в разработке), то есть когда в программе, что-то идёт не так, как планировалось. Например, внутри программа построена так, что изначально не соответствует тому, что от неё ожидается. Failure — это сбой в работе компонента, всей программы или системы (может быть как аппаратным, так и вызванным дефектом). Тестовый пакет Тестовый пакет является фундаментальной единицей разработки тестов. Это набор тестов, которые оценивают согласованный набор возможностей устройства, то есть те, которые имеют тесную функциональную связь. Набор тестов – это контейнер с набором тестов, который помогает тестировщикам выполнять и сообщать о состоянии выполнения теста. Может принимать любое из трех состояний: «Активно», «Выполняется» и «Завершено». Тестовый набор может быть добавлен в несколько наборов тестов и планов тестирования. После создания плана тестирования создаются наборы тестов, которые, в свою очередь, могут иметь любое количество тестов. Как правило, модульные тесты и тестовые конфигурации разрабатываются самими разработчиками, основная задача тестера в этом случае - организовать все тесты в упорядоченную структуру пакетов и указать, какие пакеты должны исполняться в каких условиях. Вся иерархия тестов хранится в так называемом файле метаданных, имеющем расширение vsmdi. Этот файл находится в системе контроля версий и может быть включен в решение как отдельный элемент. Процесс тестирования Как отмечалось ранее, в тестировании выделяются три основных уровня, или три фазы: Модульное тестирование. Интеграционное тестирование. Системное тестирование. Задача планирования активности тестирования состоит в оптимальном распределении ресурсов между всеми типами тестирования. В дальнейшем изложении мы сконцентрируемся на системной фазе тестирования, как на наиболее важной и критичной активности для разработки качественного программного продукта. Фазы процесса тестирования В процессе тестирования выделяют следующие фазы: Определение целей (требований к тестированию), включающее следующую конкретизацию: какие части системы будут тестироваться, какие аспекты их работы будут выбраны для проверки, каково желаемое качество и т.п. Планирование: создание графика (расписания) разработки тестов для каждой тестируемой подсистемы; оценка необходимых человеческих, программных и аппаратных ресурсов; разработка расписания тестовых циклов. Важно отметить, что расписание тестирования обязательно должно быть согласовано с расписанием разработки создаваемой системы, поскольку наличие исполняемой версии разрабатываемой системы ( Implementation Under Testing (IUT) или Application Under Testing (AUT) – часто употребляемые обозначения для тестируемой системы) является одним из необходимых условий тестирования, что создает взаимозависимость в работе команд тестировщиков и разработчиков. Разработка тестов, то есть тестового кода для тестируемой системы, если необходимо - кода системы автоматизации тестирования и тестовых процедур (выполняемых вручную). Выполнение тестов: реализация тестовых циклов. Анализ результатов. После анализа результатов возможно повторение процесса тестирования, начиная с пунктов 3, 2 или даже 1. Тестовый цикл Тестовый цикл – это цикл исполнения тестов, включающий фазы 4 и 5 тестового процесса. Тестовый цикл заключается в прогоне разработанных тестов на некотором однозначно определяемом срезе системы (состоянии кода разрабатываемой системы). Обычно такой срез системы называют build. Тестовый цикл включает следующую последовательность действий: Проверка готовности системы и тестов к проведению тестового цикла включающая: Проверку того, что все тесты, запланированные для исполнения на данном цикле, разработаны и помещены в систему версионного контроля. Проверку того, что все подсистемы, запланированные для тестирования на данном цикле, разработаны и помещены в систему версионного контроля. Проверку того, что разработана и задокументирована процедура определения и создания среза системы, или build. Проверки некоторых дополнительных критериев. Подготовка тестовой машины в соответствии с требованиями, определенными на этапе планирования (например, полная очистка и переустановка системного программного обеспечения). Конфигурация тестовой машины, так же, как и срез системы, должны быть однозначно воспроизводимыми. Воспроизведение среза системы. Прогон тестов в соответствии с задокументированными процедурами. Сохранение тестовых протоколов (test log). Test log может содержать вывод системы в STDOUT, список результатов сравнения полученных при исполнении данных с эталонными или любые другие выходные данные тестов, с помощью которых можно проверить правильность работы системы. Анализ протоколов тестирования и принятие решения о том прошел или не прошел каждый из тестов ( Pass/Fail ). Анализ и документирование результатов цикла. Последний перед выпуском продукта тестовый цикл не должен включать изменений кода build или кода продукта тестируемой системы. Этот цикл называется " финальным ". Таким образом обеспечивается ситуация, когда финальный цикл полностью повторяем, а выпускаемый продукт полностью совпадает с продуктом, который прошел тестирование. Финальный цикл необходим для гарантии достоверности результатов тестирования. Что такое тестовый сценарий Тестовый сценарий определяется как любой функции , которые могут быть проверены. Это также называется условием проверки или возможностью проверки . Как тестер, вы должны поставить себя на место конечного пользователя и выяснить реальные сценарии и варианты использования тестируемого приложения. Что такое тестирование сценария Тестирование сценариев — это вариант тестирования программного обеспечения, в котором для тестирования используются сценарии. Сценарии помогают в более простом способе тестирования более сложных систем Зачем создавать тестовые сценарии Тестовые сценарии создаются по следующим причинам: Создание тестовых сценариев обеспечивает полное покрытие тестами Сценарии тестирования могут быть одобрены различными заинтересованными сторонами, такими как бизнес-аналитик, разработчики, клиенты, для обеспечения тщательного тестирования тестируемого приложения. Это гарантирует, что программное обеспечение работает для наиболее распространенных случаев использования. Они служат быстрым инструментом для определения трудозатрат на тестирование и, соответственно, создают предложение для клиента или организуют рабочую силу. Они помогают определить наиболее важные сквозные транзакции или реальное использование программных приложений. Для изучения сквозного функционирования программы, тестовый сценарий имеет решающее значение. Когда не создать тестовый сценарий Тестовые сценарии не могут быть созданы, когда Тестируемое приложение является сложным, нестабильным, и в проекте есть время. Проекты, которые следуют Agile методологии, такие как Scrum, Kanban, могут не создавать тестовые сценарии. Сценарий тестирования не может быть создан для исправления новой ошибки или регрессионного тестирования . В таких случаях сценарии тестирования должны быть уже задокументированы в предыдущих циклах тестирования. Это особенно верно для проектов технического обслуживания. Как написать тестовые сценарии Как тестер, вы можете выполнить следующие пять шагов для создания тестовых сценариев: Шаг 1 : Прочтите документы с требованиями, такие как BRS, SRS, FRS, тестируемой системы (SUT). Вы также можете сослаться на примеры использования, книги, руководства и т. Д. Приложения, подлежащего тестированию. Шаг 2 : Для каждого требования определите возможные действия и цели пользователей. Определить технические аспекты требования. Определите возможные сценарии злоупотребления системой и оцените пользователей с менталитетом хакера. Шаг 3: После прочтения Документа с требованиями и проведения надлежащего анализа перечислите различные сценарии тестирования, которые проверяют каждую функцию программного обеспечения. Шаг 4: После того, как вы перечислили все возможные сценарии тестирования, создается матрица отслеживания, чтобы убедиться, что каждому требованию соответствует соответствующий сценарий тестирования. Шаг 5: Созданные сценарии проверяются вашим руководителем. Позже они также рассматриваются другими заинтересованными сторонами в проекте. Советы по созданию тестовых сценариев Каждый тестовый сценарий должен быть привязан как минимум к одному требованию или пользовательской истории в соответствии с методологией проекта. Перед созданием тестового сценария, который проверяет несколько требований одновременно, убедитесь, что у вас есть тестовый сценарий, который проверяет это требование изолированно. Избегайте создания слишком сложных тестовых сценариев, охватывающих несколько требований. Количество сценариев может быть большим, и запускать их все дорого. Исходя из приоритетов клиента, запускайте только выбранные тестовые сценарии Пример 1. Сценарий тестирования для приложения электронной коммерции Для приложения электронной коммерции несколько тестовых сценариев Тестовый сценарий 1: проверка функциональности входа  Чтобы помочь вам понять разницу между сценарием тестирования и тестовыми сценариями, для этого сценария тестирования будут использоваться конкретные тестовые сценарии. Проверьте поведение системы при вводе действительного адреса электронной почты и пароля. Проверьте поведение системы при вводе неверного идентификатора электронной почты и действительного пароля. Проверьте поведение системы при вводе действительного адреса электронной почты и неверного пароля. Проверьте поведение системы при вводе неверного идентификатора электронной почты и неверного пароля. Проверьте поведение системы, если адрес электронной почты и пароль оставлены пустыми и введен вход. Проверить Забыли пароль работает как положено Проверьте поведение системы при вводе действительного / недействительного номера телефона и пароля. Проверять поведение системы, когда установлен флажок «Держать меня в подписи» Как видно, тестовые случаи являются более конкретными. Тестовый сценарий 2. Проверка функциональности поиска  Тестовый сценарий 3: проверьте страницу описания продукта  Сценарий тестирования 4: Проверьте функциональность платежей  Тестовый сценарий 5: проверка истории заказов  Помимо этих 5 сценариев, здесь приведен список всех других сценариев. Проверьте поведение домашней страницы для постоянных клиентов Проверьте категорию / страницы продукта Проверьте службу поддержки / контактные страницы Проверьте страницы ежедневных предложений Пример 2: Тестовые сценарии для банковского сайта Тестовый сценарий 1 : Проверьте функциональность входа и аутентификации Тестовый сценарий 2 : Проверить перевод денег можно Тестовый сценарий 3. Проверьте выписку со счета. Тестовый сценарий 4 : Проверка фиксированного депозита / периодического депозита может быть создана И так далее… Литература: Гагарина, Л. Г. Технология разработки программного обеспечения: учеб. пособие / Л. Г. Гагарина, Е. В. Кокорева, Б. Д. Виснадул; Под ред. Л. Г. Гагариной. - М.: ФОРУМ: ИНФРА-М, 2017.-400 с. |