Практические кейсы и примеры создания сценарных тестов с использованием фреймворка тестирование 3.0

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

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

1. Проверьте корректность кода состояния HTTP. Например, создание ресурса должно возвращать 201 CREATED, а запрещенные запросы должны возвращать 403 FORBIDDEN и т. Д.

2. Проверьте полезную нагрузку ответа. Проверьте правильность тела JSON, имен, типов и значений полей ответа, в том числе в ответах на ошибочные запросы.

3. Проверьте заголовки ответа. Заголовки HTTP-сервера влияют как на безопасность, так и на производительность.

4. Проверьте правильность состояния приложения. Это необязательно и применяется в основном к ручному тестированию или когда пользовательский интерфейс или другой интерфейс можно легко проверить. 

5. Проверьте базовую работоспособность. Если операция была завершена успешно, но заняла неоправданно много времени, тест не пройден.

Тест-кейсы поощряют менеджмент на основании кейсов

Инструменты управления кейсами приглашают менеджеров руководить командой на основании (количества) тест-кейсов. Бывшая коллега рассказывала, что участвовала в проекте, где нужно было прогонять определенное количество кейсов в день. В итоге были придуманы условные кейсы. Если в ходе тестирования в голову приходила тест-идея, она вносилась в «условный» кейс. Если по количеству тестов в день был недобор, можно было прогнать несколько таких условных кейсов. Управление через тест-кейсы настолько же плохо, как плохо управление программистами через строчки кода или количество коммитов. Задача разработчика не в создании строчек кода – хоть они и будут способом достижения цели. То же самое касается тестировщика – их работа не в запуске тест-кейсов, а в предоставлении информации о продукте.

Это приводит нас ко второму вопросу: почему тестированием нужно упралять отдельно от прочей деятельности? Если ваши тестировщики – единая команда с разработчиками, управляйте качеством и своевременностью работы команды. Если что-то из этого не совпадает с вашими ожиданиями, возможно, нужно лучше тестировать, а возможно, что и нет. В любом случае концентрация на тестировании в надежде повысить качество через тестирование может что-то улучшить разве что случайно.

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

Что же делать?

1. Разработчики не умеют тестировать. →
   Можно консультировать их на первых этапах, чтобы помочь разобраться.
2. Нет кодовой базы, инфраструктуры и подходов. →
   Всё решается только временем. На размеченные функции писать тексты проще.
3. Понятные отчёты. →
   В отчёты надо включать все шаги, а название каждого теста должно сразу отражать, что именно им проверяется.
4. Приходится тратить много времени на ряд задач. →
   Спасает здравый смысл: не всё стоит покрывать здесь и сейчас.
5. Сложно отдавать задачи, когда нет подходов и инструментов. →
   Тоже решается постепенно, главное — время для анализа и внедрения того или иного инструмента. И это должно быть отдельной задачей.
6. Проблема масштабных задач. →
   Их можно сразу отдавать без тестов либо частично покрытыми тестами. Но это в любом случае не отменяет погружения в контекст.

Категории тестовых сценариев

Наши тест-кейсы делятся на следующие общие группы тестовых сценариев:

Основные позитивные тесты (прохождение успешного сценария по умолчанию)

Расширенное позитивное тестирование с дополнительными параметрами

Негативное тестирование с валидными входными данными

Негативное тестирование с недопустимыми входными данными

Деструктивное тестирование

Тесты безопасности, авторизации и доступности (которые выходят за рамки этой статьи)

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

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

Деструктивное тестирование — это более глубокая форма негативного тестирования, когда мы намеренно пытаемся сломать API, чтобы проверить его надежность (например, отправляя заведомо большое тело запроса в попытке переполнить систему).

Структура тестового примера

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

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

Это полезно при выполнении теста.

• Низкий
• Средняя
• Высоко

Тест разработан Имя тестера

Дата проведения теста разработана Дата, когда был разработан тест

Тест выполнен Кто выполнил тест (тестер)

Дата проведения теста Дата, когда необходимо выполнить тест

Имя или название теста Заголовок должен содержать краткое, раскрывающее описание контрольного примера, например «Reset Pass». Название важно, потому что это часто первое или единственное, что вы видите при сканировании списка тестовых случаев. Четкие заголовки являются ключом, помогающим тестировщикам быстро находить правильные тестовые примеры.

Описание / Краткое содержание теста Подробное описание теста. В этом разделе вы также можете настроить категории, чтобы организовать тестовые случаи в логические группы.

Предварительное условие Любое требование, которое необходимо выполнить перед выполнением этого теста

Тестовые шаги

Раздел «Шаги тестирования» дает тестировщику нумерованный список шагов, которые необходимо выполнить в системе, что упрощает понимание тестового примера.

Рекомендуется иметь 3-8 этапов теста на один тест. Слишком много шагов мешают разработчикам и тестировщикам воспроизвести шаги, когда отчет об ошибке подан против контрольного примера.

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

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

Постусловие Каково будет состояние системы после выполнения контрольного примера?

Статус (Fail / Pass) Пометить это поле как неуспешное, если фактический результат не совпадает с ожидаемым

Примечания / Комментарии / Вопросы: Если есть какие-то особые условия, которые оставлены в поле выше

Требования Список требований для конкретного цикла испытаний.

Оснастка / Ссылки Файлы и документы, прикрепленные к тестовому примеру, такие как снимки экрана и другие вспомогательные материалы.

Автоматизация? (Да нет) Заполните «ДА», когда контрольные примеры автоматизированы

Как хранить и обновлять тест-кейсы?

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

Надеемся, что вы знаете, чем тест-трекер отличается баг-трекера. Если нет, поясним.

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

Тест-трекер имеет более широкую функциональность. Его основные функции следующие:

проставление и хранение результатов прогонов теста (т.к

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

Часто тест-трекинговая система совмещена с баг-трекинговой.

Например, в TFS есть все: система хранения тестов, отслеживания дефектов и множество других инструментов для тестирования и управления проектом. JIRA используется как баг-трекинговая система, а для тест-трекинга можно использовать специальный плагин Zephyr.

Итак. Отдаем предпочтение тест-трекинговым системам (TTC). Никаких Excel-файлов. Excel-файл с тест-кейсами – это пережиток прошлого. К сожалению, некоторые команды этим пережитком до сих пор пользуются.

Вполне вероятно, у вас на проекте инженеры будут тоже использовать Excel-файлы. Если так, то все оформленные таким образом тест-кейсы для автоматизации все равно должны быть внесены в тест-трекер.

Сейчас поясним почему.

Представьте себе, вы написали тест-кейс, автоматизатор его заавтоматизировал. А потом вы внесли обновления в тест-кейс. Как автоматизатор узнает, какие тест-кейсы нужно обновить? Проще всего это сделать, изменив статус тест-кейса в тест-трекинговой системе. Это позволяет отследить все обновленные тесты.

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

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

Преимущества использования тест-трекера для хранения и обновления тест-кейсов:

• Меньше времени на коммуникацию;
• Меньше времени на обновления.

Кажется, все важные вопросы обсудили. В следующей статье перейдем непосредственно к правилам написания хороших тест-кейсов.

Тест-кейсы необходимо писать по требованиям

1234Следующая ⇒

Требования

Требования необходимо тестировать

Речь здесь идет о тестировании требований всех уровней и видов: бизнес-требования, пользовательские требования, системные требования, функциональные требования, нефункциональные требования, требований производительности, требования удобства использования и т.д.

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

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

Последствиями либо отсутствия тестирования требований вообще, либо откладывания тестирования требований до лучших времен или тезиса «все их недостатки выявятся в процессе разработки и тестирования» являются:

• выявление серьезных ошибок проектирования непосредственно перед выпуском релиза, что приводит к необходимости серьезных доработок, как требований, так и кода (я уже не говорю о доработке тест-кейсов, тестовых данных и повторном тестировании). Естественно, все это приводит к срыву сроков, авральной работе (по ночам и/или выходным) и прочим негативным вещам, которых можно было бы избежать своевременным тестированием требований;
• перекладывание всей ответственности и вины за случившееся на создателей требований, что по меньшей мере, не оздоровляет отношения между участниками разработки. Наверное, многие сталкивались с позицией программистов, аналогичной этим: «Не было написано, поэтому и не сделал», «Как написано, так и сделал», «Писать надо лучше» и т.п.

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

Культура тест-кейсов и фабричная школа

Одержимость кейсами – не просто привычка, это целая культура.

Аарон как-то проводил небольшой эксперимент в рамках курса по тестированию, который он посещал. Он спрашивал коллег, пишут ли они кейсы перед началом тестирования. Он ожидал, что ответы будут варьировать от «да, конечно» до «нет» с приличной дозой «что имеется в виду под тест-кейсами?». Результаты шокировали его. Большая часть респондентов посмотрела на него так, как будто он спросил, одеваются ли они перед тем, как пойти на работу, и задерживают ли дыхание при нырянии. Создание кейсов как основное занятие тестировщика, видимо, даже не обсуждается в их организациях.

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

Тест в культуре тест-кейсов – это конкретное существительное, артефакт, на который можно указать и сообщить, что это тест. Как только тест материализовался подобным образом, логично обращаться с ним как с продуктом – например, мешком риса. Зачастую мы сталкиваемся с подсчетом тестов и оценкой прогресса тестирования, основанной на этих подсчетах. Баги аналогично материализуются: тринадцать багов – это на один баг хуже, чем двенадцать, не правда ли? В этой культуре баги и кейсы взаимосвязаны – кейсы находят баги. Если баг каким-то образом найден без помощи тест-кейса (ситуация, на которую в культуре тест-кейсов смотрят с подозрением), то можно ожидать просьбы создать кейс, который будет нацелен на ловлю подобного бага.

В культуре тест-кейсов тестировщик играет роль посредника, через которого работают тест-кейсы. Следовательно, создание кейсов – это работа для опытных, а с их прогоном справится даже новичок (или, что еще лучше, робот).

Очень заманчиво думать именно так: это позволяет управлять тестированием через простую как грабли систему, которая превращает тестировщиков во взаимозаменяемые ресурсы и создает как бы фабрику тестирования. В этой связи мы часто называем этот образ мыслей «Фабричной школой».

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

Распространенное отношение к людям в фабричной школе – недоверие. Людям нельзя доверять, они не способны действовать единственно верным способом. Люди в лучшем случае транзитная технология – мы пользуемся ими, пока не построены подходящие роботы. Но даже на самых продуктивных фабриках можно заметить, что менеджеры как-то не думают о том, что заменить можно будет и их самих

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

С единственной разницей – мы считаем, что оно необходимо на уровне выполнения теста.

Выбор тестовой документации

На проектах по тестированию могут использоваться следующие виды документации: Acceptance Sheet, Test Survey или тест-кейсы.

Нас интересуют проекты с тест-кейсами, поскольку это самый подробный вид документации. Acceptance Sheet и Test Survey не годятся для автоматизации. Имея на руках Test Survey, автоматизатор, какой бы он опытный ни был, не сможет продумать шаги для автотеста, рискует пропустить важные проверки. А значит, тест не выполнит главной задачи – не сможет отловить дефекты.

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

Ну и еще один самый распространенный вопрос.

Примеры оформления (несколько ожидаемых результатов)

Рассматриваем все тот же абстрактный сайт www.test.ru. Допустим, что поле «ФИО» по ТЗ решили ограничить 40 символами (тут будет ссылка почему так не надо делать).Когда говорят о нескольких ожидаемых результатах, это может означать:

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

Несколько вариантов вводимых данных

Тест-кейс № 2. Создание жильца, проверка поля «ФИО».

Шаги:

1. Зайти на сайт www.dev_test.ru (логин — test, пароль — test).
2. Войти под учеткой администратора (логин — admin, , пароль — 1)
3. Перейти на вкладку «Жильцы»
4. Нажать на кнопку «Создать карточку жильца».
5. Заполнить поле ФИО (см «Ожидаемый результат»)
6. Нажать на кнопку «Сохранить».

Ожидаемый результат

Для этого варианта тест-кейса запись в виде таблички: данные – результат — наше всё!

Результаты для нескольких шагов из кейса

Другой вариант записи тест-кейса с несколькими ожидаемыми результатами — когда результаты пишутся на разные пункты шагов выполнения проверки, то есть на разные этапы сценария.

Тест-кейс № 3. Создание жильца с худым полным ФИО.

Шаги:

1. Зайти на сайт www.dev_test.ru (логин — test, пароль — test).
2. Войти под учеткой администратора (логин — admin, пароль — 1)
3. Перейти на вкладку «Жильцы»
4. Нажать на кнопку «Создать карточку жильца».
5. Ввести корректные ФИО, например, «Иванов Иван Иванович».
6. Нажать на кнопку «Сохранить».

Ожидаемый результат

1. Открывается окно ввода логина / пароля с соответствующими полями для ввода, кнопкой «Войти» и сообщением «Для входа в систему введите, пожалуйста, свои данные».2. Вход в систему успешно осуществлен. В правом верхнем углу отображается надпись «Здравствуйте, admin». Открыта главная страница сайта.4. Открылась страница «Создание нового жильца» с полями «Фамилия», «Имя» и «Отчество» и кнопкой «Сохранить».6. Окно с информацией о жильце закрывается и отображается общий список, в котором присутствует новая карточка. Эту карточку можно открыть и на ней отображаются введенные данные, то есть в поле ФИО указано «Иванов Иван Иванович».

Несколько проверок после одного сценария

Тест-кейс № 4. Создание жильца с самым полным ФИО.

Шаги:

1. Зайти на сайт www.dev_test.ru (логин — test, пароль — test).
2. Войти под учеткой администратора (логин — admin, , пароль — 1)
3. Перейти на вкладку «Жильцы»
4. Нажать на кнопку «Создать карточку жильца».
5. Ввести корректные ФИО, например, «Иванов Иван Иванович».
6. Нажать на кнопку «Сохранить».

Ожидаемый результат1. Окно с информацией о жильце закрывается и отображается общий список, в котором присутствует новая карточка.2. Эту карточку можно открыть.3. В открытой карточке отображаются введенные данные, то есть в поле ФИО указано «Иванов Иван Иванович».

Области применения

Так как тест-кейсы очень сложно поддерживать, то чаще используют чек-листы (тут будет ссылка на статью по чек-листам) или комбинацию «чек-листы & тест-кейсы».В последнем случае большинство проверок пишут в виде чек-листов, а особо сложные (пойди туда, не знаю куда, принеси то, не знаю что, кувыркнись три раза и громко крикни «ДЕДЛАЙН!», только тогда формочка и откроется) уже в виде тест-кейсов, чтобы каждый раз не вспоминать, как этот хитрый сценарий работает.

Тест-кейсы нужны:

1. Жизненно важные системы, ошибка в которых может привести к гибели (самолетостроение, медицина, ПО для атомных станций). Здесь надо тестировать очень аккуратно и тщательно. 
2. При тестировании сложных систем или сложных частей системы, чтобы не запутаться в чек-листе.

Тест-кейсы не нужны:

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

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

Фабричная теория на практике

Что случится, если мы попытаемся управлять сложной когнитивной деятельностью – тестированием – материализуя эту деятельность до поверхностно репрезентативных тест-кейсов?

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

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

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

Правила их составления

2. Писать нужно в едином стиле

1. Регистрация
2. Пополни баланс
3. Скачать файл-образец

1. Регистрация
2. Пополнение баланса
3. Скачивание файла-образца

1. Зарегистрироваться
2. Пополнить баланс
3. Скачать файл-образец

3. Можно ссылаться на другие тест-кейсы

Зарегистрироваться с именем «Д`Артаньян» (см. тест-кейс «Регистрация»).
↓
Зарегистрируйся с таким-то именем. Если не знаешь как — welcome to тест-кейс регистрации.

4. Но не доходя до маразма ツ

Предварительные шаги

1. Зарегистрироваться (см. тест-кейс «Регистрация»).
2. Пополнить баланс (см. тест-кейс «Пополнение баланса»).
3. Скачать файл-образец (см. тест-кейс «Скачивание файла-образца»)

Предварительные шаги

1. Зарегистрироваться (см. тест-кейс «Регистрация»).
2. Пополнить баланс (см. тест-кейс «Пополнение баланса»).
3. Скачать файл «Клиенты» (см. тест-кейс «Скачивание файла»)

1. Скачать файл формата CSV (см. тест-кейс «Скачивание файла»)

• Проверяет, что файл реально скачивается (а то будет big fail).
• Проверяет, что внутри файла лежат правильные данные.

Подготовить файл формата doc с данными из файла-примера (см аттач «Пример.doc»)
Подготовить файл с разными форматами дат рождения (см аттач «Даты рождения.xls»)
Подготовить файл картинкой внутри вместо текста (см аттач «Картинка. xls»)

5. Выкидывать текст ради текста нужно

1. Зарегистрироваться (см. тест-кейс «Регистрация»).

1. Зарегистрироваться (см. тест-кейс «Регистрация»).
2. Зарегистрироваться с именем Ольга и email xxx@gmail.com (см. тест-кейс «Регистрация»).

6. Предварительных шагов может и не быть — это нормально

Предварительные шаги

1. Нажать на кнопку «Войти»

Шаги
Ввести логин такой-то, пароль сякой-то
↓Шаги

1. Нажать на кнопку «Войти»
2. Ввести логин такой-то, пароль сякой-то

Похожие записи:

Профессия разработчик мобильных приложений Отдых для всей семьи вдали от городской суеты Материальная ответственность работника Рейтинг самых крупных инвестиционных компаний россии на 2019 год Почему я не буду оформлять платную подписку на google фото Класс оквэд 01 — растениеводство и животноводство, охота и предоставление соответствующих услуг в этих областях