Сценарий тестирования программного обеспечения пример

Что такое тестирование сценария?

Тестирование сценариев — это вариант тестирования программного обеспечения, в котором для тестирования используются сценарии. Сценарии помогают в более простом способе тестирования более сложных систем

Давайте изучим это с помощью видео ниже —

Зачем создавать тестовые сценарии?

Тестовые сценарии создаются по следующим причинам:

• Создание тестовых сценариев обеспечивает полное покрытие тестами
• Сценарии тестирования могут быть одобрены различными заинтересованными сторонами, такими как бизнес-аналитик, разработчики, клиенты, для обеспечения тщательного тестирования тестируемого приложения. Это гарантирует, что программное обеспечение работает для наиболее распространенных случаев использования.
• Они служат быстрым инструментом для определения трудозатрат на тестирование и, соответственно, создают предложение для клиента или организуют рабочую силу.
• Они помогают определить наиболее важные сквозные транзакции или реальное использование программных приложений.
• Для изучения сквозного функционирования программы, тестовый сценарий имеет решающее значение.

Когда не создать тестовый сценарий?

Тестовые сценарии не могут быть созданы, когда

• Тестируемое приложение является сложным, нестабильным, и в проекте есть время.
• Проекты, которые следуют Agile методологии, такие как Scrum, Kanban, могут не создавать тестовые сценарии.
• Сценарий тестирования не может быть создан для исправления новой ошибки или регрессионного тестирования . В таких случаях сценарии тестирования должны быть уже задокументированы в предыдущих циклах тестирования. Это особенно верно для проектов технического обслуживания.

Как написать тестовые сценарии

Как тестер, вы можете выполнить следующие пять шагов для создания тестовых сценариев:

• Шаг 1 : Прочтите документы с требованиями, такие как BRS, SRS, FRS, тестируемой системы (SUT). Вы также можете сослаться на примеры использования, книги, руководства и т. Д. Приложения, подлежащего тестированию.
• Шаг 2 : Для каждого требования определите возможные действия и цели пользователей. Определить технические аспекты требования. Определите возможные сценарии злоупотребления системой и оцените пользователей с менталитетом хакера.
• Шаг 3: После прочтения Документа с требованиями и проведения надлежащего анализа перечислите различные сценарии тестирования, которые проверяют каждую функцию программного обеспечения.
• Шаг 4: После того, как вы перечислили все возможные сценарии тестирования, создается матрица отслеживания, чтобы убедиться, что каждому требованию соответствует соответствующий сценарий тестирования.
• Шаг 5: Созданные сценарии проверяются вашим руководителем. Позже они также рассматриваются другими заинтересованными сторонами в проекте.

Советы по созданию тестовых сценариев

• Каждый тестовый сценарий должен быть привязан как минимум к одному требованию или пользовательской истории в соответствии с методологией проекта.
• Перед созданием тестового сценария, который проверяет несколько требований одновременно, убедитесь, что у вас есть тестовый сценарий, который проверяет это требование изолированно.
• Избегайте создания слишком сложных тестовых сценариев, охватывающих несколько требований.
• Количество сценариев может быть большим, и запускать их все дорого. Исходя из приоритетов клиента, запускайте только выбранные тестовые сценарии

Пример 1. Сценарий тестирования для приложения электронной коммерции

Для приложения электронной коммерции несколько тестовых сценариев

Тестовый сценарий 1: проверка функциональности входа

Чтобы помочь вам понять разницу между сценарием тестирования и тестовыми сценариями, для этого сценария тестирования будут использоваться конкретные тестовые сценарии.

1. Проверьте поведение системы при вводе действительного адреса электронной почты и пароля.
2. Проверьте поведение системы при вводе неверного идентификатора электронной почты и действительного пароля.
3. Проверьте поведение системы при вводе действительного адреса электронной почты и неверного пароля.
4. Проверьте поведение системы при вводе неверного идентификатора электронной почты и неверного пароля.
5. Проверьте поведение системы, если адрес электронной почты и пароль оставлены пустыми и введен вход.
6. Проверить Забыли пароль работает как положено
7. Проверьте поведение системы при вводе действительного / недействительного номера телефона и пароля.
8. Проверять поведение системы, когда установлен флажок «Держать меня в подписи»

Как видно, тестовые случаи являются более конкретными.

Тестовый сценарий 2. Проверка функциональности поиска

Фундаментальная теория тестирования

В тестировании нет четких определений, как в физике, математике, которые при перефразировании становятся абсолютно неверными. Поэтому важно понимать процессы и подходы. В данной статье разберем основные определения теории тестирования.

Перейдем к основным понятиям

Тестирование программного обеспечения (Software Testing) — проверка соответствия реальных и ожидаемых результатов поведения программы, проводимая на конечном наборе тестов, выбранном определённым образом.

Цель тестирования — проверка соответствия ПО предъявляемым требованиям, обеспечение уверенности в качестве ПО, поиск очевидных ошибок в программном обеспечении, которые должны быть выявлены до того, как их обнаружат пользователи программы.

Для чего проводится тестирование ПО?

• Для проверки соответствия требованиям.
• Для обнаружение проблем на более ранних этапах разработки и предотвращение повышения стоимости продукта.
• Обнаружение вариантов использования, которые не были предусмотрены при разработке. А также взгляд на продукт со стороны пользователя.
• Повышение лояльности к компании и продукту, т.к. любой обнаруженный дефект негативно влияет на доверие пользователей.

Принципы тестирования

• Принцип 1 — Тестирование демонстрирует наличие дефектов (Testing shows presence of defects).
  Тестирование только снижает вероятность наличия дефектов, которые находятся в программном обеспечении, но не гарантирует их отсутствия.
• Принцип 2 — Исчерпывающее тестирование невозможно (Exhaustive testing is impossible).
  Полное тестирование с использованием всех входных комбинаций данных, результатов и предусловий физически невыполнимо (исключение — тривиальные случаи).
• Принцип 3 — Раннее тестирование (Early testing).
  Следует начинать тестирование на ранних стадиях жизненного цикла разработки ПО, чтобы найти дефекты как можно раньше.
• Принцип 4 — Скопление дефектов (Defects clustering).
  Большая часть дефектов находится в ограниченном количестве модулей.
• Принцип 5 — Парадокс пестицида (Pesticide paradox).
  Если повторять те же тестовые сценарии снова и снова, в какой-то момент этот набор тестов перестанет выявлять новые дефекты.
• Принцип 6 — Тестирование зависит от контекста (Testing is context depending). Тестирование проводится по-разному в зависимости от контекста. Например, программное обеспечение, в котором критически важна безопасность, тестируется иначе, чем новостной портал.
• Принцип 7 — Заблуждение об отсутствии ошибок (Absence-of-errors fallacy). Отсутствие найденных дефектов при тестировании не всегда означает готовность продукта к релизу. Система должна быть удобна пользователю в использовании и удовлетворять его ожиданиям и потребностям.

Обеспечение качества (QA — Quality Assurance) и контроль качества (QC — Quality Control) — эти термины похожи на взаимозаменяемые, но разница между обеспечением качества и контролем качества все-таки есть, хоть на практике процессы и имеют некоторую схожесть.

QC (Quality Control) — Контроль качества продукта — анализ результатов тестирования и качества новых версий выпускаемого продукта.

К задачам контроля качества относятся:

• проверка готовности ПО к релизу;
• проверка соответствия требований и качества данного проекта.

QA (Quality Assurance) — Обеспечение качества продукта — изучение возможностей по изменению и улучшению процесса разработки, улучшению коммуникаций в команде, где тестирование является только одним из аспектов обеспечения качества.

К задачам обеспечения качества относятся:

• проверка технических характеристик и требований к ПО;
• оценка рисков;
• планирование задач для улучшения качества продукции;
• подготовка документации, тестового окружения и данных;
• тестирование;
• анализ результатов тестирования, а также составление отчетов и других документов.

Верификация и валидация — два понятия тесно связаны с процессами тестирования и обеспечения качества. К сожалению, их часто путают, хотя отличия между ними достаточно существенны.

Верификация (verification) — это процесс оценки системы, чтобы понять, удовлетворяют ли результаты текущего этапа разработки условиям, которые были сформулированы в его начале.

Валидация (validation) — это определение соответствия разрабатываемого ПО ожиданиям и потребностям пользователя, его требованиям к системе.

Пример: когда разрабатывали аэробус А310, то надо было сделать так, чтобы закрылки вставали в положение «торможение», когда шасси коснулись земли. Запрограммировали так, что когда шасси начинают крутиться, то закрылки ставим в положение «торможение». Но вот во время испытаний в Варшаве самолет выкатился за пределы полосы, так как была мокрая поверхность. Он проскользил, только потом был крутящий момент и они, закрылки, открылись. С точки зрения «верификации» — программа сработала, с точки зрения «валидации» — нет. Поэтому код изменили так, чтобы в момент изменения давления в шинах открывались закрылки.

Документацию, которая используется на проектах по разработке ПО, можно условно разделить на две группы:

1. Проектная документация — включает в себя всё, что относится к проекту в целом.
2. Продуктовая документация — часть проектной документации, выделяемая отдельно, которая относится непосредственно к разрабатываемому приложению или системе.

Этапы тестирования:

1. Анализ продукта
2. Работа с требованиями
3. Разработка стратегии тестирования и планирование процедур контроля качества
4. Создание тестовой документации
5. Тестирование прототипа
6. Основное тестирование
7. Стабилизация
8. Эксплуатация

Стадии разработки ПО — этапы, которые проходят команды разработчиков ПО, прежде чем программа станет доступной для широкого круга пользователей.

Программный продукт проходит следующие стадии:

1. анализ требований к проекту;
2. проектирование;
3. реализация;
4. тестирование продукта;
5. внедрение и поддержка.

Требования

Требования — это спецификация (описание) того, что должно быть реализовано.
Требования описывают то, что необходимо реализовать, без детализации технической стороны решения.

Атрибуты требований:

1. Корректность — точное описание разрабатываемого функционала.
2. Проверяемость — формулировка требований таким образом, чтобы можно было выставить однозначный вердикт, выполнено все в соответствии с требованиями или нет.
3. Полнота — в требовании должна содержаться вся необходимая для реализации функциональности информация.
4. Недвусмысленность — требование должно содержать однозначные формулировки.
5. Непротиворечивость — требование не должно содержать внутренних противоречий и противоречий другим требованиям и документам.
6. Приоритетность — у каждого требования должен быть приоритет(количественная оценка степени значимости требования). Этот атрибут позволит грамотно управлять ресурсами на проекте.
7. Атомарность — требование нельзя разбить на отдельные части без потери деталей.
8. Модифицируемость — в каждое требование можно внести изменение.
9. Прослеживаемость — каждое требование должно иметь уникальный идентификатор, по которому на него можно сослаться.

Дефект (bug) — отклонение фактического результата от ожидаемого.

Отчёт о дефекте (bug report) — документ, который содержит отчет о любом недостатке в компоненте или системе, который потенциально может привести компонент или систему к невозможности выполнить требуемую функцию.

Атрибуты отчета о дефекте:

1. Уникальный идентификатор (ID) — присваивается автоматически системой при создании баг-репорта.
2. Тема (краткое описание, Summary) — кратко сформулированный смысл дефекта, отвечающий на вопросы: Что? Где? Когда(при каких условиях)?
3. Подробное описание (Description) — более широкое описание дефекта (указывается опционально).
4. Шаги для воспроизведения (Steps To Reproduce) — описание четкой последовательности действий, которая привела к выявлению дефекта. В шагах воспроизведения должен быть описан каждый шаг, вплоть до конкретных вводимых значений, если они играют роль в воспроизведении дефекта.
5. Фактический результат (Actual result) — описывается поведение системы на момент обнаружения дефекта в ней. чаще всего, содержит краткое описание некорректного поведения(может совпадать с темой отчета о дефекте).
6. Ожидаемый результат (Expected result) — описание того, как именно должна работать система в соответствии с документацией.
7. Вложения (Attachments) — скриншоты, видео или лог-файлы.
8. Серьёзность дефекта (важность, Severity) — характеризует влияние дефекта на работоспособность приложения.
9. Приоритет дефекта (срочность, Priority) — указывает на очерёдность выполнения задачи или устранения дефекта.
10. Статус (Status) — определяет текущее состояние дефекта. Статусы дефектов могут быть разными в разных баг-трекинговых системах.
11. Окружение (Environment) – окружение, на котором воспроизвелся баг.

Жизненный цикл бага

Severity vs Priority

Серьёзность (severity) показывает степень ущерба, который наносится проекту существованием дефекта. Severity выставляется тестировщиком.

Градация Серьезности дефекта (Severity):

• Блокирующий (S1 – Blocker)
  тестирование значительной части функциональности вообще недоступно. Блокирующая ошибка, приводящая приложение в нерабочее состояние, в результате которого дальнейшая работа с тестируемой системой или ее ключевыми функциями становится невозможна.
• Критический (S2 – Critical)
  критическая ошибка, неправильно работающая ключевая бизнес-логика, дыра в системе безопасности, проблема, приведшая к временному падению сервера или приводящая в нерабочее состояние некоторую часть системы, то есть не работает важная часть одной какой-либо функции либо не работает значительная часть, но имеется workaround (обходной путь/другие входные точки), позволяющий продолжить тестирование.
• Значительный (S3 – Major)
  не работает важная часть одной какой-либо функции/бизнес-логики, но при выполнении специфических условий, либо есть workaround, позволяющий продолжить ее тестирование либо не работает не очень значительная часть какой-либо функции. Также относится к дефектам с высокими visibility – обычно не сильно влияющие на функциональность дефекты дизайна, которые, однако, сразу бросаются в глаза.
• Незначительный (S4 – Minor)
  часто ошибки GUI, которые не влияют на функциональность, но портят юзабилити или внешний вид. Также незначительные функциональные дефекты, либо которые воспроизводятся на определенном устройстве.
• Тривиальный (S5 – Trivial)
  почти всегда дефекты на GUI — опечатки в тексте, несоответствие шрифта и оттенка и т.п., либо плохо воспроизводимая ошибка, не касающаяся бизнес-логики, проблема сторонних библиотек или сервисов, проблема, не оказывающая никакого влияния на общее качество продукта.

Срочность (priority) показывает, как быстро дефект должен быть устранён. Priority выставляется менеджером, тимлидом или заказчиком

Градация Приоритета дефекта (Priority):

• P1 Высокий (High)
  Критическая для проекта ошибка. Должна быть исправлена как можно быстрее.
• P2 Средний (Medium)
  Не критичная для проекта ошибка, однако требует обязательного решения.
• P3 Низкий (Low)
  Наличие данной ошибки не является критичным и не требует срочного решения. Может быть исправлена, когда у команды появится время на ее устранение.

Существует шесть базовых типов задач:

• Эпик (epic) — большая задача, на решение которой команде нужно несколько спринтов.
• Требование (requirement ) — задача, содержащая в себе описание реализации той или иной фичи.
• История (story) — часть большой задачи (эпика), которую команда может решить за 1 спринт.
• Задача (task) — техническая задача, которую делает один из членов команды.
• Под-задача (sub-task) — часть истории / задачи, которая описывает минимальный объем работы члена команды.
• Баг (bug) — задача, которая описывает ошибку в системе.

Тестовые среды

• Среда разработки (Development Env) – за данную среду отвечают разработчики, в ней они пишут код, проводят отладку, исправляют ошибки
• Среда тестирования (Test Env) – среда, в которой работают тестировщики (проверяют функционал, проводят smoke и регрессионные тесты, воспроизводят.
• Интеграционная среда (Integration Env) – среда, в которой проводят тестирование взаимодействующих друг с другом модулей, систем, продуктов.
• Предпрод (Preprod Env) – среда, которая максимально приближена к продакшену. Здесь проводится заключительное тестирование функционала.
• Продакшн среда (Production Env) – среда, в которой работают пользователи.

Основные фазы тестирования

• Pre-Alpha: прототип, в котором всё ещё присутствует много ошибок и наверняка неполный функционал. Необходим для ознакомления с будущими возможностями программ.
• Alpha: является ранней версией программного продукта, тестирование которой проводится внутри фирмы-разработчика.
• Beta: практически готовый продукт, который разработан в первую очередь для тестирования конечными пользователями.
• Release Candidate (RC): возможные ошибки в каждой из фичей уже устранены и разработчики выпускают версию на которой проводится регрессионное тестирование.
• Release: финальная версия программы, которая готова к использованию.

Основные виды тестирования ПО

Вид тестирования — это совокупность активностей, направленных на тестирование заданных характеристик системы или её части, основанная на конкретных целях.

1. Классификация по запуску кода на исполнение:
   • Статическое тестирование — процесс тестирования, который проводится для верификации практически любого артефакта разработки: программного кода компонент, требований, системных спецификаций, функциональных спецификаций, документов проектирования и архитектуры программных систем и их компонентов.
   • Динамическое тестирование — тестирование проводится на работающей системе, не может быть осуществлено без запуска программного кода приложения.

2. Классификация по доступу к коду и архитектуре:
   • Тестирование белого ящика — метод тестирования ПО, который предполагает полный доступ к коду проекта.
   • Тестирование серого ящика — метод тестирования ПО, который предполагает частичный доступ к коду проекта (комбинация White Box и Black Box методов).
   • Тестирование чёрного ящика — метод тестирования ПО, который не предполагает доступа (полного или частичного) к системе. Основывается на работе исключительно с внешним интерфейсом тестируемой системы.

3. Классификация по уровню детализации приложения:
   • Модульное тестирование — проводится для тестирования какого-либо одного логически выделенного и изолированного элемента (модуля) системы в коде. Проводится самими разработчиками, так как предполагает полный доступ к коду.
   • Интеграционное тестирование — тестирование, направленное на проверку корректности взаимодействия нескольких модулей, объединенных в единое целое.
   • Системное тестирование — процесс тестирования системы, на котором проводится не только функциональное тестирование, но и оценка характеристик качества системы — ее устойчивости, надежности, безопасности и производительности.
   • Приёмочное тестирование — проверяет соответствие системы потребностям, требованиям и бизнес-процессам пользователя.

4. Классификация по степени автоматизации:
   • Ручное тестирование.
   • Автоматизированное тестирование.

5. Классификация по принципам работы с приложением
   • Позитивное тестирование — тестирование, при котором используются только корректные данные.
   • Негативное тестирование — тестирование приложения, при котором используются некорректные данные и выполняются некорректные операции.

6. Классификация по уровню функционального тестирования:
   • Дымовое тестирование (smoke test) — тестирование, выполняемое на новой сборке, с целью подтверждения того, что программное обеспечение стартует и выполняет основные для бизнеса функции.
   • Тестирование критического пути (critical path) — направлено для проверки функциональности, используемой обычными пользователями во время их повседневной деятельности.
   • Расширенное тестирование (extended) — направлено на исследование всей заявленной в требованиях функциональности.

7. Классификация в зависимости от исполнителей:
   • Альфа-тестирование — является ранней версией программного продукта. Может выполняться внутри организации-разработчика с возможным частичным привлечением конечных пользователей.
   • Бета-тестирование — программное обеспечение, выпускаемое для ограниченного количества пользователей. Главная цель — получить отзывы клиентов о продукте и внести соответствующие изменения.

8. Классификация в зависимости от целей тестирования:
   • Функциональное тестирование (functional testing) — направлено на проверку корректности работы функциональности приложения.
   • Нефункциональное тестирование (non-functional testing) — тестирование атрибутов компонента или системы, не относящихся к функциональности.
     1. Тестирование производительности (performance testing) — определение стабильности и потребления ресурсов в условиях различных сценариев использования и нагрузок.
     2. Нагрузочное тестирование (load testing) — определение или сбор показателей производительности и времени отклика программно-технической системы или устройства в ответ на внешний запрос с целью установления соответствия требованиям, предъявляемым к данной системе (устройству).
     3. Тестирование масштабируемости (scalability testing) — тестирование, которое измеряет производительность сети или системы, когда количество пользовательских запросов увеличивается или уменьшается.
     4. Объёмное тестирование (volume testing) — это тип тестирования программного обеспечения, которое проводится для тестирования программного приложения с определенным объемом данных.
     5. Стрессовое тестирование (stress testing) — тип тестирования направленный для проверки, как система обращается с нарастающей нагрузкой (количеством одновременных пользователей).
     6. Инсталляционное тестирование (installation testing) — тестирование, направленное на проверку успешной установки и настройки, обновления или удаления приложения.
     7. Тестирование интерфейса (GUI/UI testing) — проверка требований к пользовательскому интерфейсу.
     8. Тестирование удобства использования (usability testing) — это метод тестирования, направленный на установление степени удобства использования, понятности и привлекательности для пользователей разрабатываемого продукта в контексте заданных условий.
     9. Тестирование локализации (localization testing) — проверка адаптации программного обеспечения для определенной аудитории в соответствии с ее культурными особенностями.
     10. Тестирование безопасности (security testing) — это стратегия тестирования, используемая для проверки безопасности системы, а также для анализа рисков, связанных с обеспечением целостного подхода к защите приложения, атак хакеров, вирусов, несанкционированного доступа к конфиденциальным данным.
     11. Тестирование надёжности (reliability testing) — один из видов нефункционального тестирования ПО, целью которого является проверка работоспособности приложения при длительном тестировании с ожидаемым уровнем нагрузки.
     12. Регрессионное тестирование (regression testing) — тестирование уже проверенной ранее функциональности после внесения изменений в код приложения, для уверенности в том, что эти изменения не внесли ошибки в областях, которые не подверглись изменениям.
     13. Повторное/подтверждающее тестирование (re-testing/confirmation testing) — тестирование, во время которого исполняются тестовые сценарии, выявившие ошибки во время последнего запуска, для подтверждения успешности исправления этих ошибок.

Тест-дизайн — это этап тестирования ПО, на котором проектируются и создаются тестовые случаи (тест-кейсы).

Техники тест-дизайна

Автор книги «A Practitioner’s Guide to Software Test Design», Lee Copeland, выделяет следующие техники тест-дизайна:

1. Тестирование на основе классов эквивалентности (equivalence partitioning) — это техника, основанная на методе чёрного ящика, при которой мы разделяем функционал (часто диапазон возможных вводимых значений) на группы эквивалентных по своему влиянию на систему значений.
2. Техника анализа граничных значений (boundary value testing) — это техника проверки поведения продукта на крайних (граничных) значениях входных данных.
3. Попарное тестирование (pairwise testing) — это техника формирования наборов тестовых данных из полного набора входных данных в системе, которая позволяет существенно сократить количество тест-кейсов.
4. Тестирование на основе состояний и переходов (State-Transition Testing) — применяется для фиксирования требований и описания дизайна приложения.
5. Таблицы принятия решений (Decision Table Testing) — техника тестирования, основанная на методе чёрного ящика, которая применяется для систем со сложной логикой.
6. Доменный анализ (Domain Analysis Testing) — это техника основана на разбиении диапазона возможных значений переменной на поддиапазоны, с последующим выбором одного или нескольких значений из каждого домена для тестирования.
7. Сценарий использования (Use Case Testing) — Use Case описывает сценарий взаимодействия двух и более участников (как правило — пользователя и системы).

Методы тестирования

Тестирование белого ящика — метод тестирования ПО, который предполагает, что внутренняя структура/устройство/реализация системы известны тестировщику.

Согласно ISTQB, тестирование белого ящика — это:

• тестирование, основанное на анализе внутренней структуры компонента или системы;
• тест-дизайн, основанный на технике белого ящика — процедура написания или выбора тест-кейсов на основе анализа внутреннего устройства системы или компонента.
• Почему «белый ящик»? Тестируемая программа для тестировщика — прозрачный ящик, содержимое которого он прекрасно видит.

Тестирование серого ящика — метод тестирования ПО, который предполагает комбинацию White Box и Black Box подходов. То есть, внутреннее устройство программы нам известно лишь частично.

Тестирование чёрного ящика — также известное как тестирование, основанное на спецификации или тестирование поведения — техника тестирования, основанная на работе исключительно с внешними интерфейсами тестируемой системы.

Согласно ISTQB, тестирование черного ящика — это:

• тестирование, как функциональное, так и нефункциональное, не предполагающее знания внутреннего устройства компонента или системы;
• тест-дизайн, основанный на технике черного ящика — процедура написания или выбора тест-кейсов на основе анализа функциональной или нефункциональной спецификации компонента или системы без знания ее внутреннего устройства.

Тестовая документация

Тест план (Test Plan) — это документ, который описывает весь объем работ по тестированию, начиная с описания объекта, стратегии, расписания, критериев начала и окончания тестирования, до необходимого в процессе работы оборудования, специальных знаний, а также оценки рисков.

Тест план должен отвечать на следующие вопросы:

• Что необходимо протестировать?
• Как будет проводиться тестирование?
• Когда будет проводиться тестирование?
• Критерии начала тестирования.
• Критерии окончания тестирования.

Основные пункты тест плана:

1. Идентификатор тест плана (Test plan identifier);
2. Введение (Introduction);
3. Объект тестирования (Test items);
4. Функции, которые будут протестированы (Features to be tested;)
5. Функции, которые не будут протестированы (Features not to be tested);
6. Тестовые подходы (Approach);
7. Критерии прохождения тестирования (Item pass/fail criteria);
8. Критерии приостановления и возобновления тестирования (Suspension criteria and resumption requirements);
9. Результаты тестирования (Test deliverables);
10. Задачи тестирования (Testing tasks);
11. Ресурсы системы (Environmental needs);
12. Обязанности (Responsibilities);
13. Роли и ответственность (Staffing and training needs);
14. Расписание (Schedule);
15. Оценка рисков (Risks and contingencies);
16. Согласования (Approvals).

Чек-лист (check list) — это документ, который описывает что должно быть протестировано. Чек-лист может быть абсолютно разного уровня детализации.

Чаще всего чек-лист содержит только действия, без ожидаемого результата. Чек-лист менее формализован.

Тестовый сценарий (test case) — это артефакт, описывающий совокупность шагов, конкретных условий и параметров, необходимых для проверки реализации тестируемой функции или её части.

Атрибуты тест кейса:

• Предусловия (PreConditions) — список действий, которые приводят систему к состоянию пригодному для проведения основной проверки. Либо список условий, выполнение которых говорит о том, что система находится в пригодном для проведения основного теста состояния.
• Шаги (Steps) — список действий, переводящих систему из одного состояния в другое, для получения результата, на основании которого можно сделать вывод о удовлетворении реализации, поставленным требованиям.
• Ожидаемый результат (Expected result) — что по факту должны получить.

Резюме

Старайтесь понять определения, а не зазубривать. Если хотите узнать больше про тестирование, то можете почитать Библию QA. А если возникнет вопрос, всегда можете задать его нам в телеграм-канале @qa_chillout.

Введение в тестовый сценарий

Тестовый сценарий — это комбинация двух слов, то есть теста и сценария. Тест представляет собой акт проверки или подтверждения, а сценарий представляет собой путешествие пользователя. Любая тестируемая функциональность называется сценарием тестирования. Сценарий тестирования может быть описан как проверка или подтверждение правильности поездки пользователя. Он будет в форме документов, содержащих все тестовые примеры, подробно написанные для проверки сквозной функциональности приложений. Это одна из высокоуровневых категорий требований, которые можно проверить. Это также известно как возможность тестирования или условия тестирования.

Зачем создавать тестовые сценарии?

Несколько тестовых случаев могут быть охвачены одним тестовым сценарием. Следовательно, связь между сценариями тестирования и контрольными случаями является однозначным. Но каждый сценарий должен быть учтен тестером при его создании. Тестеры создают его для тестирования приложения с точки зрения конечного пользователя. Тестировщики стремятся от всех разработчиков, заинтересованных сторон и клиентов подготовить их, которые являются критическими.

Причина их создания заключается в следующем:

• Полное и правильное покрытие тестов обеспечивается созданием совершенных тестовых сценариев.
• Их создание становится критически важным для изучения сквозных функций программы.
• Наиболее важные и критические сквозные транзакции или использование приложений в реальном времени могут быть точно определены при правильной их помощи.
• Они могут использоваться в качестве инструмента для быстрого определения рабочей силы по тестированию, которая также помогает клиентам или организациям эффективно и результативно создавать предложения и организацию рабочей силы по тестированию.
• Для обеспечения тщательного и правильного тестирования приложений его утверждение проводится на различных уровнях, включая клиентов, бизнес-аналитиков, разработчиков и т. Д.

Точно так же могут быть определенные обстоятельства, при которых его следует избегать.

• Его нельзя создавать в проектах, следующих за гибкими методологиями, такими как Scrum и т. Д.
• Когда тестируемые приложения нестабильны или слишком сложны, или когда проект находится в критическом состоянии, его создания можно избежать.
• Его можно избежать для регрессионного тестирования или для новой ошибки, потому что в проектах технического обслуживания их тяжелая документация может произойти заранее в предыдущих циклах тестирования.

Как тестовые сценарии могут быть написаны?

Следующие шаги могут быть выполнены тестером для создания тестовых сценариев:

• Шаг 1: Документ о требованиях, таких как Спецификация бизнес-требований (BRS), Спецификация функциональных требований (FRS) и Спецификация системных требований (SRS) приложения, подлежащего тестированию, следует внимательно и тщательно прочитать. Руководства, книги, варианты использования и т. Д. Тестируемого приложения могут быть отнесены к тому же.
• Шаг 2: Все возможные цели и действия пользователя должны быть правильно определены для каждого требования. Все технические характеристики каждого требования также должны быть определены.
• Шаг 3: Все возможные причины взлома системы и оценки пользователя должны выполняться с точки зрения хакера. Оценка пользователя может быть выполнена путем нахождения всех возможностей пользовательского управления приложениями.
• Шаг 4: Полный список всех возможных тестовых случаев для проверки всех функциональных возможностей приложения должен быть составлен после полного прочтения документа с требованиями и завершения анализа.
• Шаг 5: После привлечения всех из них для проверки соответствия требования и его сценария тестирования должна быть создана матрица отслеживания.
• Шаг 6: Все созданные тестовые сценарии проверяются и оцениваются супервизором. Это также дополнительно проверяется всеми заинтересованными сторонами.

В соответствии с процедурой проекта каждый сценарий тестирования должен соответствовать как минимум одной пользовательской истории или требованию. Обязательно проверять каждый тестовый сценарий на соответствие его требованию отдельно, перед несколькими требованиями в одном тестовом сценарии. Сложные тестовые сценарии с несколькими требованиями можно избежать для простоты. Цена прямо пропорциональна их количеству. Поэтому желательно всегда запускать только выбранные и требуемые в соответствии с приоритетом клиента.

Примеры

Ниже приведены несколько примеров сценария тестирования.

Тестовый сценарий для интернет-магазина приложений Buykart

Сценарии тестирования, которые можно принять во внимание при проверке приложения для онлайн-покупок Buykart, следующие:

Тестовый сценарий 1: проверка работоспособности входа

Тестовые случаи, которые можно рассмотреть для создания:

• Поведение приложения при вводе действительного идентификатора входа и действительного пароля можно проверить.
• Поведение приложения при вводе действительного логина и неверного пароля может быть проверено.
• Поведение приложения при вводе неверного логина и действительного пароля можно проверить.
• Поведение приложения при вводе неверного логина и неверного пароля можно проверить.
• Поведение приложения при входе путем ввода идентификатора входа без пароля можно проверить.
• Поведение приложения при входе путем ввода пароля без идентификатора входа можно проверить.
• Поведение приложения при входе в систему без ввода логина и пароля можно проверить.
• Поведение приложения при выборе забытого пароля.

Тестовый сценарий 2. Проверка функциональности поиска

Тестовые случаи, которые можно рассмотреть для создания:

• Поведение приложения при поиске действующего товара.
• Поведение приложения при поиске недействительного продукта.

Тестовый сценарий 3: проверка деталей продукта

Тестовые случаи, которые можно рассмотреть для создания:

• Поведение приложения при выборе продукта.
• Поведение приложения продукта в списке пожеланий.
• Поведение приложения при добавлении товара в корзину.
• Поведение приложения при выборе опции «Купить сейчас».
• Поведение приложения при вводе неверного адреса.
• Поведение приложения при вводе действительного адреса.
• Поведение приложения при проверке нескольких вариантов оплаты.

Тестовый сценарий 4: проверка функциональности платежа

Тестовые случаи, которые можно рассмотреть для создания:

• Поведение приложения при выборе каждого варианта оплаты.
• Поведение приложения, когда выбран правильный способ оплаты.
• Поведение приложения при выборе неверного варианта оплаты.
• Поведение приложения при успешной оплате.
• Поведение приложения при отклонении платежа.

Тестовый сценарий 5: проверка функциональности деталей заказа

Тестовые случаи, которые можно рассмотреть для создания:

• Поведение приложения при выборе каждого заказа.
• Поведение приложения при выборе опции «Возврат товара».
• Поведение приложения при выборе опции отслеживания товара.
• Поведение приложения при выборе опции «Обзор продукта».

Вывод

Он служит надлежащим руководством для тестировщиков и помогает им сделать тестирование более эффективным и действенным. Это помогает уменьшить сложность тестирования и избыточность. Каждый тестовый пример написан подробно для лучшего понимания. Это очень экономит время для тестеров.

Рекомендуемые статьи

Это было руководство к тому, что такое тестовый сценарий. Здесь мы обсудим, как создавать тестовые сценарии на разных примерах. Вы также можете взглянуть на следующие статьи, чтобы узнать больше —

1. Стресс нестабильности работы
2. Мотивированный и посвященный
3. Что такое Agile Testing?
4. Как написать контрольный пример?

Сводка тестового примера программного обеспечения

• Основные элементы тестовых случаев
• Метод разработки тестового примера
  • Метод проектирования на основе спроса
  • Класс эквивалентности
  • Граничное значение
  • Диаграмма причин и следствий
  • Ортогональное расположение
  • Дизайн сцены
  • Неправильное предположение
• Действительность тестовых случаев
• Детализация и оценка тестовых случаев

Основные элементы тестовых случаев

• Концепция регрессионного тестирования: Тестовый пример — это набор коллекций, предоставляемых тестируемой системе с целью реализации теста.Этот набор коллекций содержит такие элементы, как тестовая среда, этапы работы, тестовые данные и ожидаемые результаты.(Хорошим тестовым примером является то, что человек, не знакомый с бизнесом, может быстро протестировать в соответствии с вариантом использования)

• Критерии оценки тестовых случаев:

  • Сценарии использования четко выражены и недвусмысленны
  • Сильная работоспособность сценария использования
  • Входные и выходные данные варианта использования ясны, а вариант использования имеет только один ожидаемый результат.
  • Сильная ремонтопригодность
  • Сценарии использования имеют высокий охват требований
  • Сильная способность выявлять программные ошибки

Преимущества тестовых примеров

* Основа исполнителя теста
 * Сделайте работу повторяемой, основа автоматизированного тестирования
 * Оцените охват требований
 * Повторное использование вариантов использования
 * Накопите идеи методов испытаний для последующей справки

• Трудности в использовании
  Разработка тестовых примеров занимает много времени и трудоемко, и зачастую на разработку тестовых примеров уходит больше времени, чем на их выполнение.
• Решите следующие проблемы
  Охват тестированием невозможно измерить; повторное тестирование новых версий сложно реализовать
  Не уверен, все ли функции были протестированы всесторонне; существует множество избыточных тестов, которые влияют на эффективность тестирования.

Методика разработки тестового примера

Дизайн на основе спроса
RBT — это метод тестирования, основанный на требованиях, который сделает тестирование более эффективным, поскольку фокусируется на основной причине проблем с качеством, а именноспрос。

Тестирование на основе требований является одним из самых фундаментальных тестов программного обеспечения, в котором основное внимание уделяется следующим двум ключевым вопросам:

• Убедитесь, что требования верны, полны, однозначны и логически согласованы.
• С точки зрения «черного ящика», спроектируйте достаточный и необходимый набор тестов, чтобы убедиться, что дизайн и код могут полностью соответствовать требованиям.
• случай
  
  Требования к программному обеспечению:
  1.1.1.1.5.3 Поток событий
  1. Если пользователь не получил письмо для активации, он может снова отправить письмо для активации после ввода адреса электронной почты и пароля в интерфейсе входа в систему.
  2. Электронное письмо активации, отправляемое каждый раз, действительно только в течение 24 часов после отправки электронного письма, а активационное письмо необходимо отправить повторно через 24 часа.
  Прецедент
  1-1. Если электронное письмо не получено, после ввода адреса электронной почты и пароля при входе в систему отправьте письмо активации еще раз;
  1-2. Электронное письмо получено. После ввода адреса электронной почты и пароля при входе в систему письмо для активации не будет отправлено.
  2-1. После получения письма активируйте в течение 24 часов.
  2–2. После получения письма ссылка для активации истечет через 24 часа.
  2–3. После получения письма оно было активировано; через 24 часа срок действия ссылки истекает, нажмите «Активировать» еще раз.
  Проверка страницы:
  1. Получите письмо для активации.
  2. Содержание электронного письма верное.
  3. URI активации правильный и может быть активирован.
  4. Запрос на повторную активацию активирован
  5. Срок действия приглашения на активацию истек.

Конкретный метод проектирования

Класс эквивалентности

Идея: концентрация входных данных бесконечна и не может быть покрыта

• Согласно требованиям, вход (в особых случаях будет рассматриваться выход) делится на несколько классов эквивалентности, и из классов эквивалентности выбирается тестовый пример.Если тестовый пример проходит тест, эквивалентный класс, представленный тестом, считается пройденным.Итак, вы можете использоватьМеньше тестовых примеров для достижения максимально возможного многофункционального покрытия, решая проблему неполного охвата。
  • Эффективный класс эквивалентности：Набор разумных и значимых входных данных для спецификации программы, Используйте эффективный класс эквивалентности, чтобы проверить, реализуются ли функции и характеристики, указанные в спецификации.
  • Недопустимый класс эквивалентности: согласно спецификации требования коллекция, не соответствующая требованию.
• Класс эквивалентности учитывает только классификацию входной области, не учитывает комбинацию входной области и требует других методов проектирования и дополнений.
• eg: Имя пользователя состоит из строки длиной 6-15 цифр, поэтому допустимый класс эквивалентности для символов — AZ, az, а недопустимый класс эквивалентности — два: числа: 1, 0, 1, -1; специальные символы: @ , #, ￥, пусто

Граничное значение

Метод анализа граничных значений:Метод тестирования черного ящика для проверки граничного значения ввода и вывода, Метод анализа граничных значенийВ качестве дополнения к методу разделения классов эквивалентности, В данном случае его тестовый примерГраница из класса эквивалентности。
eg:

1. Длина поля ввода составляет 1-11, а граничные значения: 1, 22, 12, 0.
2. Страница запроса содержит 999 строк, и каждые 50 строк составляют одну страницу. Граничное значение: выходная строка 0, 1 строка, 50 строк, 51 строка, 999 строк.
3. В качестве примера возьмем программные требования зарегистрированного почтового ящика.: Имя пользователя должно состоять из 6-15 цифр, а точки на граничном значении: 5, 6, 15, 16 все заполнены?
   • В фактическом дизайне теста класс эквивалентности и граничное значение будут использоваться в комбинации, поэтому окончательный дизайн варианта использования, который можно подтвердить, будет следующим: входное значение из пяти символов 5, 6, 10, 15 и 16.
   • К тому же тест не полный, китайский? Половина ширины? Полная ширина? Специальные символы (расширенные символы)

Диаграмма причин и следствий

Причинно-следственная диаграмма представляет собой упрощенную логическую схему., жестяная банкаВизуально показать взаимосвязь между условиями ввода программы (причинами) и действиями вывода (результатами), Диаграмма причинности имеет видИспользуйте графику для разработки тестовых случаевСистемный подход, особенноПодходит для различных ситуаций, когда тестируемая программа имеет несколько входных условий, а выходные данные программы зависят от входных условий.。

• Шаги метода диаграммы причинности для разработки тестовых случаев:
  • Проанализируйте все возможные входы и возможные выходы.
  • Найдите соответствие между вводом и выводом.
  • Нарисуйте причинно-следственную схему.
  • Преобразуйте диаграмму причин и следствий в таблицу решений.
  • Сопоставьте таблицу решений с каждым тестовым примером.
    Причинно-следственный метод разработки тестовых случаев может помочь тестировщикам прояснить взаимосвязь между вводом и выводом, но для более сложных вводов и выводов это займет много времени.

Ортогональное расположение

Цель ортогонального метода — уменьшить количество вариантов использования и охватить входные парные комбинации как можно меньшим количеством вариантов использования.

• На практике это не распространено, научные эксперименты важнее,На практике мы посмотрим на код или представим возможный код для сокращения случаев использования.。

Дизайн сцены

• Почти все программы сейчас используютТриггеры событий для управления процессом, Формируется обычное явление при срабатывании событияСцены, И формируются разные последовательности триггеров и результаты обработки одного и того же события.Поток событий, Этот метод может более наглядно отобразить ситуацию, когда событие запускается, что полезно разработчику тестов для разработки тестовых примеров и упрощения их понимания и выполнения.

• Типичные области применения:Используйте бизнес-поток, чтобы объединить изолированные функциональные точки, чтобы установить общий бизнес-процесс для тестировщиков, чтобы избежать неправильной тенденции к раскрытию функциональных деталей и игнорированию ключевых моментов бизнес-процесса.。

Неправильное предположение

• Метод неправильного предположения — это метод тестирования, который любят использовать опытные тестировщики.。
• Основываясь на опыте и интуиции, выявляйте ошибки, которые, по вашему мнению, могут возникнуть в программе, и целенаправленно разрабатывайте тестовые примеры., ** Опыт может быть получен в результате дополнительного тестирования определенного бизнеса, он также может исходить из отзывов пользователей послепродажного обслуживания, он также может исходить из отзывов пользователей после продажи или сортировки ошибок из библиотеки управления неисправностями. ** Определите, где продукт был подвержен проблемам в прошлом,Чем больше проблем, тем больше потенциальных ошибок。

Действительность тестовых случаев

• Функция, соответствующая тесту, удалена и больше не может использоваться.
  • Вы можете обмениваться сообщениями с QQ, когда выйдет WeChat, и вы не можете отправлять сообщения после следующей версии.
• При выполнении тестового примера ОШИБКА не обнаружена, на самом деле здесь есть ОШИБКА
  • Тестовый пример не включал сканирование и загрузку апплета Apple 7 WeChat. В результате ошибка, заключающаяся в том, что приложение для мобильного велосипеда добавлялось в WeChat мобильного телефона Apple 7 и блокировку нельзя было разблокировать путем сканирования кода, не была обнаружена.
• Выполните тестовый пример и найдите ОШИБКУ
• При выполнении тестового примера ОШИБКА не обнаружена, фактическая ОШИБКА была изменена

Детализация и оценка тестовых случаев

Гранулярность: относится к уровню детализации написания тестового примера.
Основные соображения могут относиться к следующему:

• Требования к качеству продукции
• Требования к проекту для вариантов использования
• Достаточное время и ресурсы для тестирования
  Но каким бы упрощенным ни был вариант использования, его нельзя опускать.

Оценка тестовых случаев

Обеспечение качества тестовых примеров требует всестороннего использования различных средств и методов,Обзор делится на формальный и неформальный.。

• Экспертная оценка
• Проверка пользователя
• Обзор команды проекта

Случай интервью

Вопросы по ручке:Определенное программное обеспечение мобильного телефона имеет функцию экспорта данных с TF-карты. Пожалуйста, запишите идею тестирования этой функции.