Привет Друзья! Продолжаем изучение тестовой документации, которая обязательна в составлении и с которой сталкивается в своей работе каждый тестировщик. В данной статье Мы рассмотрим Тестовый набор.
Тестовый набор (Test suite) – набор тест-кейсов, в которых результат описывается предисловием, то есть очередность проводимых тестов.
Он включает в себя следующие атрибуты:
- идентификатор тест-кейса;
- проект;
- модуль;
- описание теста;
- ожидаемый результат (в основном только для последнего шага);
- приоритет;
- дата проведения;
- исполнитель;
- среда тестирования
- статус прохождения тест-кейса;
Пример Тестового набора
Данные атрибуты являются обязательными. Тестовые наборы могут храниться в специализированном ПО, например: TestIT, Redmine, Jira, а так же в облачных хранилищах или google-документах в виде excel и word формате.
Друзья, вот мы и рассмотрели такую важную тему «как составлять тестовый набор», пришло время прощаться, подписываетесь на канал, ставьте лайк и до новых встреч!
Позитивность тестов, негативное тестирование / Урок 14 / Тестировщик с нуля
Источник: dzen.ru
Что такое тестовый набор (тест-свит)
Тестовый набор — контейнер для выполнения тест-кейсов, сгруппированных по функциональности.
В тест-план может входить много тестовых наборов (свитов), которые в свою очередь состоят из тест-кейсов.
Тест-кейсы выполняются вместе (последовательно); они группируются в наборы по функциональности (предназначению), в порядке, изложенном в тест-плане.
Тестовый набор (далее также «тест-свит») может иметь статусы Активный, В процессе, и Завершен.
Итак, тестовый набор (свит) это коллекция тест-кейсов, направленных на проверку функциональности приложения, или какой-то ее части. В наборе также содержится информация о цели каждого тест-кейса, и конфигурация выполнения.
О правильном названии
Примечание: в русскоязычном QA-сообществе сложилась практика написания и произношения «тест-сьют», и это, в общем-то, некорректное название. Однако: чтобы наши материалы могли увидеть и прочитать больше людей, стремящихся в QA, мы должны ориентироваться на поисковые запросы; и дело в том, что «тест-сьют» в Рунете ищут гораздо чаще, чем «тест-свит». Но, реагируя на замечания наших веселых читателей в обсуждении в Телеграм-канале, решили исправить определение. Пусть будет «тест-свит», если угодно («свит как сладкий», а не «сьют как костюм», да).
Еще о правильном названии test suite на русском, например, здесь (спойлер: все не так уж однозначно).
Быстрый пример
Например, тестирование функции покупки в онлайн-магазине будет состоять примерно из таких тест-кейсов:
- Логин
- Выбор товара и добавление в корзину
- Проверка правильности данных
- Покупка
- Выход из системы
Большие подробные тест-свиты формируют при дымовом и системном тестировании.
Тестовая документация тестировщика: тест план, тест кейс и чек-лист | Урок 4 | QA Labs
Характеристики тестового набора
- Создается на основе тест-плана
- Также набор описывает цели тест-кейсов
- В тестовый набор входят параметры тестируемого приложения, настройки окружения, и подобные вспомогательные файлы и настройки
- Тестовые наборы могут быть как функциональной, так и нефункциональной направленности
- Тестовые наборы ускоряют и облегчают процесс тестирования
- Тест-кейсы в свите выполняются последовательно, и выполнение следующего зависит от предыдущего
- Могут автоматизироваться, например в Selenium
Типы
По предназначению можно выделить:
- Абстрактный тест-свит, создаваемый при так называемом тестировании на основе моделей. Состоит из группы абстрактных тест-кейсов, созданных на основе высокоуровневой модели приложения. QA-команда не может применять такие тест-свиты непосредственно (как обычные), поскольку они недостаточно подробно описывают приложение и тестовое окружение, и не могут запускаться/выполняться автоматизированно.
- Выполняемый тест-свит, то есть обычный. Разрабатывается на основе абстрактного и может выполняться (и соответственно автоматизироваться). Работает на «низком уровне», то есть на привычном для junior-тестировщика уровне, и активно взаимодействует с приложением.
Часто применяемые тестовые наборы
Тестирование верификации билда. Тестовый набор базовой проверки основной функциональности. Когда есть готовый билд.
Регрессионные тесты. Набор регрессионного тестирования функциональности.
Дымовые тесты. Набор тест-кейсов базовой проверки функциональности в экспресс-режиме, обычно после модификации кода.
Функциональные. Набор, верифицирующий обычно часть функциональности, ее отдельные аспекты.
Сквозные интеграционные, набор сквозной проверки интеграции подсистем в приложении.
Шаблон тестового набора
Шаблон стандартного тест-набора.
Саммари. Чаще довольно детализированное описание «о чем этот набор».
Дизайн. Описание дизайна.
Результаты формального ревью. Следующая секция посвящена формальному ревью, результатам обсуждения QA-командой, (что поможет привести свои будущие QA-активности в соответствие с общепринятыми правилами).
Пред- и пост-условия. Условия «входа и выхода» данного набора, то есть что должно быть сделано перед его выполнением, и после.
Ожидаемые результаты. Критерии успешности набора. После его выполнения полученные результаты сравниваются с ожидаемыми.
Анализ рисков. Идентификация всех возможных рисков, влияющих на результаты, и как их будут избегать/обходить.
Тест-кейсы. Секция непосредственно тест-кейсов, и их тестовых окружений.
Документы и репорты, а также скриншоты, записи выполнения и другие релевантные данные.
Чем отличаются тест-план, тестовый сценарий, тест-кейс, и тестовый набор
| Описание масштаба, цели, и подхода к тестированию в тестовых наборах | Описание проверки функциональности | Важный (опорный) документ, составляющая часть тестового набора | Набор тест-кейсов, объединенных по функциональности |
| Три типа: главный (мастер-план), план по типу тестов, и план по уровню тестов | Все описывается с точки зрения пользователя, может быть разным | Двух типов: формальный тест-кейс и неформальный | Два типа: абстрактный и выполняемый |
| Создается из use-кейсов, описания продукта, и требований к продукту (SRS) | Создается на основе use-кейсов, для повышения тестового покрытия и проверки пользовательских путей | Создается на основе требований и сценария тестирования | Создается по группам функциональности из нескольких тест-кейсов |
| По стандартному шаблону, описывающему процессы | Описывает операции QA-команды | Описывает проверку набора требований по проверке функциональности | Описывает цели тест-кейсов |
Как объединять тест-кейсы в тестовый набор
Как уже говорилось выше, удобнее всего объединять на основе функциональности. Можно также создавать под-наборы в рамках болшого набора.
Более гибкий подход: древовидная структура тест-свита, без ограничений на количество кейсов-«ветвей».
Чтобы структурировать тест-кейсы как логические компоненты в тест-свите, удобнее рассматривать их с точки зрения программирования, как модули, компоненты или наборы функций.
Чаще всего формируют стандартные «дымовые» и регрессионные тестовые наборы. При необходимости добавляя/удаляя оттуда тест-кейсы.
Важность в энтерпрайзе
Важно соблюдать баланс между скоростью и качеством. Этот баланс зависит от типа приложения, заказчика, и сроков. Наиболее распространенные приложения, использующие тестовые наборы, это корпоративные, и веб-приложения.
Тестирование веб- и enterprise. Веб-сервисы очень динамичные, в них часто меняются масштаб и требования. В зависимости от метрик и пользовательского фидбэка добавляются и удаляются функции. Веб-архитектура поэтому должна быть гибкой, должно регулярно проводиться сквозное тестирование, чтобы обеспечить максимальную гибкость продукта. Сквозное тестирование веб-приложения тестовым набором будет надежнее, если направлено на неизменные элементы модулей, а не на DOM-элементы.
В целом в enterprise (и десктопе) — водопадные модели, большие объемы разработки, крупные изменения бывают редко но регулярно, стабильная и надежная архитектура, соответственно тестовые наборы ориентированы на 100%-ное соблюдение требований.
Быстрые тесты. Быстрое продвижение с тестированием имеет большое влияние на продуктивность разработчиков, поэтому быстрота выполнения и легкость разбора тестов важна в веб- и энтерпрайзе. Важно поддерживать «короткую петлю фидбэка» от тестирования, это упрощает жизнь, позволяет быстро продвигаться с разработкой и экономить компании время.
Сквозные тесты. «Всеобъемлющие» e2e-наборы дают уверенность в коде в целом; результаты будут близки к реальным пользовательским сценариям сразу же как появится билд.
Лучшие практики создания тестовых наборов
Хороший тестовый набор не требует много времени на выполнение. Он сразу показывает, что приложение работает как надо, то есть требования соблюдены. Найден баг, отправлен фидбэк, разработчики находят в чем дело и фиксят. Общие признаки хорошего тестового набора:
Быстрый. Если в наборе много интеграционных тестов и мало модульных, он, очевидно, будет долго выполняться. Быстрый тест-свит даст быстрый фидбэк, разработка пойдет эффективнее.
Полный. Если свит покрывает 100% кодовой базы или чуть меньше, он найдет все дефекты, созданные после изменения функции; полнота дает уверенность.
Надежность. Надежный тест-свит это надежный стабильный фидбэк независимо от изменений вне области тестирования; ненадежный, с моргающими тестами = нет фидбэка по недавним изменениям кода.
Изолированность. В идеальном изолированном наборе тесты выполняются без зависимости от других тестов и не влияя на другие тесты; разумеется, большинство наборов такими быть не могут; несколько улучшить ситуацию помогает очистка тестовых данных после выполнения теста и перед запуском следующего.
Легкость в обслуживании. Хороший тест-свит организован удобно, в него легко удалять и добавлять тест-кейсы и модифицировать их. Чтобы свиты были легки в обслуживании, нужно придерживаться лучших практик и методологий программирования.
Удобочитаемый. Набор легко читать, он подходит для создания документации. Описания должны четко объяснять — что тестируется, и должны быть ориентированы на разработчиков в том числе.
Выбрать ЯП и фреймворки. Современное сложное приложение чаще пишется на нескольких ЯПах, каждый из которых имеет свои плюсы и минусы. Нужно учитывать уровень опыта команд и скиллы разработчиков. Если например разработчики посоветовались и решили, что Python будет основным языком проекта, то у QA-автоматизаторов нет выбора.
Язык тестового фреймворка чаще всего совпадает с языком разработки. Позитив от одного ЯП для всех команд в том, что разработчики могут выступать бесплатными менторами для QA, когда у тех возникнут проблемы.
Что такое тест-сет?
В некоторых QA-инструментах так принято называть небольшой набор (скорее группу) тестов, выделенных для какой-то более-менее узкой задачи, или проверки функции, или регрессы. Например:
- Часть системных функций (чаще всего касающихся критически важных частей GUI), или скажем запросов в БД
- Те же регрессионные тесты
- Санити-тесты
- Группа тестов, которая должна выполняться определенным тестировщиком в день или в неделю (нормативные)
Источник: testengineer.ru
Формирование тестовых наборов, основные подходы.
В соответствии с определением тестирования в начале данного параграфа, удачным следует считать тест, который обнаруживает хотя бы одну ошибку. С этой точки зрения хотелось бы использовать такие наборы тестов, каждый из которых с максимальной вероятностью может обнаружить ошибку.
Формирование набора тестов имеет большое значение, поскольку тестирование является одним из наиболее трудоемких этапов (от 30 до 60 % общей трудоемкости) создания программного продукта. Причем доля стоимости тестирования в общей стоимости разработки имеет тенденцию возрастать при увеличении сложности программного обеспечения и повышении требований к их качеству.
Существуют два принципиально различных подхода к формированию тестовых наборов: структурный и функциональный.
Структурный подход базируется на том, что известка структура тестируемого программного обеспечения, в том числе его алгоритмы («стеклянный ящик»). В этом случае тесты строят так, чтобы проверить правильность реализации заданной логики в коде программы.
Функциональный подход основывается на том, что структура программного обеспечения не известна («черный ящик»). В этом случае тесты строят, опираясь на функциональные спецификации. Этот подход называют также подходом, управляемым данными, так как при его использовании тесты строят па базе различных способов декомпозиции множества данных.
Наборы тестов, полученные в соответствии с методами этих подходов, обычно объединяют, обеспечивая всестороннее тестирование программного обеспечения.
Более подробное рассмотрение перечисленных вопросов начнем с обсуждения методов ручного контроля.
Ручной контроль программного обеспечения, методы ручного контроля.
Ручной контроль программного обеспечения
Ручной контроль, как указано выше, обычно используют на ранних этапах разработки. Все проектные решения, принятые на том или ином этапе, должны анализироваться с точки зрения их правильности и целесообразности как можно раньше, пока их можно легко пересмотреть. Поскольку возможность практической проверки подобных решений на ранних этапах разработки отсутствует, большое значение имеет их обсуждение, которое проводят в разных формах.
Различают статический и динамический подходы к ручному контролю. При статическом подходе анализируют структуру, управляющие и информационные связи программы, ее входные и выходные данные. При динамическом – выполняют ручное тестирование., т. е. вручную моделируют процесс выполнения программы на заданных исходных данных.
Исходными данными для таких проверок являются: техническое задание, спецификации, структурная и функциональная схемы программного продукта, схемы отдельных компонентов и т. д., а для более поздних этапов – алгоритмы и тексты программ, а также тестовые наборы.
Доказано, что ручной контроль способствует существенному увеличению производительности и повышению надежности программ и с его помощью можно находить от 30 до 70 % ошибок логического проектирования и кодирования. Следовательно, один или несколько из методов ручного контроля обязательно должны использоваться в каждом программном проекте.
Основными методами ручного контроля являются:
- инспекции исходного текста,
- сквозные просмотры,
- проверка за столом,
- оценки программ.
Инспекции исходного текста
Инспекции исходного текста представляют собой набор процедур и приемов обнаружения ошибок при изучении текста группой специалистов. В эту группу входят: автор программы, проектировщик, специалист по тестированию и координатор – компетентный программист, но не автор программы. Общая процедура инспекции предполагает следующие операции:
- участникам группы заранее выдается листинг программы и спецификация на нее;
- программист рассказывает о логике работы программы и отвечает на вопросы инспекторов;
- программа анализируется по списку вопросов для выявления исторически сложившихся общих ошибок программирования.
Список вопросов для инспекций исходного текста зависит, как от используемого языка программирования, так и от специфики разрабатываемого программного обеспечения. В качестве примера ниже приведен список вопросов, который можно использовать при анализе правильности программ, написанных на языке Pascal.
Источник: studfile.net