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

В этой статье мы рассмотрим описание процесса тестирования программного обеспечения сквозь призму работы с API. Я попытался собрать полезные факты из книги “Hands on restful API design and the best practices” авторов Harihara Subramanian и Pethuru Raj. В книге подробно описываются этапы проектирования API и есть отдельная глава по тестированию RESTful сервисов в связке с API.

Можно читать в связке с моим предыдущим переводом “Стратегия тестирования REST API: что именно вам нужно тестировать?”. В статье я привожу примеры из личной практики (выделены курсивом), чтобы наглядно проиллюстрировать каждый этап из книги.

Глава в книге разбита несколько частей: 

• Типы API тестирования;

• Проблемы в API тестировании;

• Тестирование безопасности API (эту главу я переведу в следующей статье);

• Описываются различные инструменты и фреймворки для тестирования API и безопасности.

• Отдельным блоком идет описание CQRS — архитектурного шаблона проектирования API, оптимизирующего операции чтениязаписи данных.

Я перевел все части, которые, по-моему мнению, касаются зоны ответственности специалиста по качеству ПО. С чем-то мне приходилось работать, что-то я взял на вооружение и буду применять на будущих проектах.

Что же такое тестирование ПО?

Тестирование программного обеспечения — это процесс подтверждения качества и точности ПО с помощью верификации и валидации соответствия требованиям и бизнес-целям. От начала бизнес-процесса до его окончания.

Какие результаты должны получиться в процессе тестирования:

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

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

• Предвидеть и выявить скрытые проблемы и дефекты;

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

Всегда надо начинать с анализа бизнес-требований и документации. Или участия в различных церемониях и встречах наподобие “Три амиго”. Это если мы говорим о Scrum-командах. От качества проработки требований напрямую зависит качество API и стоимость продукта в целом. Никому не хочется платить за десяток раз переписанную фичу из-за опечаток в ТЗ. Аналитики могут ошибаться в типах данных, именах ресурсов, маппинге, названиях полей, видах ошибок от сервера. Все требования должны фиксироваться командой и уточняться как можно больше раз, пока QA не приведет всё к виду, удовлетворяющему критериям качества. На многих проектах ведется Confluence (или любая другая база знаний) раздел, в котором создается отдельный документ с требованиями. 

Также постарайтесь сформировать “правильную” доску спринта для всей команды. Согласно канону SDLC (Software development lifecycle). 1 роль — один столбец. В нашей компании используется TFS.

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

Как мы уже знаем из предыдущих глав книги, программное обеспечение использующее RESTful API обычно состоит из различных слоев взаимодействия. Например, есть уровни представления,  бизнес-логики и  базы данных. На рисунке ниже видно, что тестирование API происходит на уровне бизнес-логики, а тестирование пользовательского интерфейса на уровне представления (Presentation layer).

Многие компании сейчас начинают оптимизировать свои корпоративные системы, написанные много лет назад. Если компания не приводит в порядок инфраструктуру, не использует передовые технологии доставки ценности до клиента (API, Облака, кубы), то компания теряет рынок.

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

Понимание подходов тестирования API

Соглашение о подходе к тестированию API — важная часть стратегии тестирования. Желательно договорится об этом перед началом разработки API. Ниже перечислены несколько принципов:

• Прозрачное описание области тестирования и хорошее понимание функциональности API;

• Понимание основных методологий тестирования, таких как анализ граничных значений и классов эквивалентности — часть составления тест-кейсов для API;

• Планирование, определение и подготовка входящих параметров, пустых запросов и тестовых примеров для API;

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

Архитекторы и аналитики — ваши друзья. Надо стараться прийти к единому видению разрабатываемого API. Иногда еще используют такие артефакты, как “Стратегия тестирования” или скорее “План тестирования”, например по RUP методологии. Попробуйте сформулировать для себя видение и стратегию развития продукта, который хочет получить бизнес. Сделая это, вы сможете унифицировать требуемые тестовые данные и упорядочить процесс написания кейсов. 

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

• Модульное тестирование (Unit testing) — тесты, которые валидируют результаты отдельных методов.

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

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

Вопросы для валидации могут быть следующие:

• Вопросы специфичные для продукта: “Это именно тот функционал, который был нужен?”

• Вопросы ожидаемого поведения: “Этот метод ведет себя так, как ожидалось?”

• Вопросы, связанные с эффективностью: “Это метод использует ресурсы максимально независимо и эффективно?”

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

Валидация в том виде, в котором она описана в этом разделе книги, является частью пользовательского тестирования. Доступ к методу включается на тестовом контуре после функционального тестирования и бизнес-подразделение проверяет его соответствие бизнес-требованиям. Например, корректность работы калькулятора, который использует API-вызовы через веб-интерфейс

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

• E2E и UI тесты. Тесты, которые запускают и проверяют сценарии конечного использования продукта, включая пользовательский интерфейс, API и БД. Проверяется результаты выполнения метода на каждом этапе транзакции.

E2E проводится силами нескольких команд: Тестировщики фронта, тестировщики бэка, специалисты инфраструктурных технических отделов, ответственные за передаваемые данные. Предварительно лучше составить список тестов, который удовлетворит видению бизнеса. Можно взять и из плана тестирования, но там он часто избыточен. Этот список согласуется со всеми участниками e2e тестирования, чтобы к вам не было потом лишних вопросов.

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

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

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

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

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

  • Утечка ресурсов. Негативные тесты для проверки сбоев в работе основных ресурсов API путем отправки некорректных запросов. Ресурсы здесь — это память, данные, уязвимости, операции тайм-аута и так далее.

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

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

Принципы написания тест-кейсов для API

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

Возможные типы ошибок, которые помогают нам обнаружить тесты API:

• Неправильно обработанные ошибки или некорректные состояния ошибок API (код 401 вместо 502);

• Любые неиспользуемые флаги;

• Отсутствует или дублируется функциональность;

• Проблемы с многопоточностью;

• Неправильная обработка допустимых значений аргументов;

• Проблемы проверки, такие как проверка схемы или проблемы со структурой;

• Проблемы с надежностью и производительностью (такие как тайм-аут и подключение и получение времени отклика) API;

• Уязвимости API и любые проблемы безопасности.

Если мы говорим о документации, то в ТЗ желательно прописать требования, которые удовлетворяют вышеперечисленным пунктам. Состав сообщений об ошибках от бэка, состав схемы (у нас все прописано в спецификациях и схема ответа валидируется отдельным функциональными тестом в Postman), требования к составам полей запроса</span>ответа. Часто кейсы  зависят от полноты требований и типа запроса. Для GET запроса без параметров будет не так уж много вариантов. Для POST, с телом запроса на 200 полей, комбинаций может быть очень много.

Основные аспекты написания тестовых сценариев API

В следующем списке представлены несколько важных нюансов подготовки тестового кейса для тестирования API:

• Проверяются возвращаемые значения на основе различных входных условий и комбинации тестовых данных. 

• Проверяется поведение API, когда нет возвращаемого значения. Проверяйте коды ответа от сервера в негативных и позитивных тестах.

• Проверяются все события и триггеры API, если базовый API создает дочерние события.

• Проверяются не только результаты запроса к API в случае обновления структуры данных, но и влияние изменения данных на целевую систему.

• Проверяются результаты изменения когда API изменяет какие-то ресурсы. 

Из практики:

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

Проблемы тестирования API

Если вы разобрались с необходимыми тестовыми примерами, достаточно ли этого, чтобы начать тестирование API? Нет. Есть еще несколько проблем с которыми вы можете столкнуться. Описание этих проблем приводятся в следующем разделе..

Начальная установка

Под начальной установкой подразумевается наличие тестового контура, его стабильность/доступность, а также время безотказной работы. Ключевым моментом является учет потребностей тестирования API уже на этапе проектирования и проверка API на 100% аптайм.

Часто на проекте не хватает ресурсов, чтобы сделать полноценные контура со всеми системами. Представьте, в идеальном мире у вас должны быть все данные с продуктового контура, реплицируемые на dev и test контуры, тестовые БД, тестовые фронт системы. Плохой практикой считается проводить тестирование (автотесты и нагрузка) на системах, где частично используются выходы на prod. ДА! ДА! Так бывает. Проверка API может зааффектить то, что никто не ожидает и кстати, чаще всего проблема случается в самый неподходящий момент. На нашем проекте QA всегда стараются минимизировать риск, если было подозрение на неизолированность тестового контура.

Проверка актуальной схемы API перед тестированием

Как вы думаете, что является жизненно важным для API? Правильно, спецификации и форматы запросов. Однако частые изменения схем и тест-кейсов неизбежны, особенно на этапе разработки. Управление тестами в альфа- и бета-средах может снизить количество проблем (из-за обновлений схемы) до 90 %.

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

Комбинации параметров тестирования

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

Используйте матрицы трассировки требований и различные техники тест-дизайна, типа Pair-wise, чтобы оптимизировать количество проверок и максимизировать их наличие на единицу тест-кейса. Если в каждом запросе вы должны проходить аутентификацию, то вы можете проверить ее только на одном пользователе, понимая, что для остальных из определенного скоупа ролей она будет работать так же корректно. 

Последовательность вызовов API

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

Для рисования схем нужен аналитик и инструменты типа miro. Хорошо, если на проекте существует общедоступная карта API. И кто-то даже поддерживает ее в актуальном состоянии.

Проверка параметров

Проверка чисел и количества цифр в телефонном номере, ограничения длины, типов данных, модификации диапазонов данных. Обычно такие тесты являются сложными задачами для команды тестирования, особенно с более крупными API, которые имеют огромное количество параметров. Внедрение синтетических приложений и инструментов мониторинга производительности приложений (application performance monitoring — APM) поможет обеспечить обнаружение любых проблем, возникающих из-за проверки параметров. Проверка параметров — один из важнейших аспектов тестирования безопасности.

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

Интеграция с трекинговой системой

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

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

Лучшие практики тестирования API

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

• Сгруппируйте тестовые кейсы API по категориям тестов (модульные тесты, функциональные тесты, тесты безопасности и другие).

  

• Убедитесь, что в тест-кейсах указаны наименования задействованных (вызываемых) методов API в заголовке каждого тест-кейса.

• Убедитесь, что выбор параметров явно указан в самом тестовом примере.

• Выполняемые тест-сьюты независимы, то есть каждый тест-кейс является автономным и независимым объектом.

• Приоритезируйте вызовы API. Это помогает упростить тестирование;

• Очистите тест-кейсы от цепочки тестов (повторное использование объектов тестовых данных, созданных другими тестами).

• Так как тест-кейсы имеют дело с одноразовыми функциями вызова, такими как удаление, закрытие окна, асинхронные вызовы, требуется уделить особое внимание нежелательных вызовам.

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

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

Сводная таблица инструментов для тестирования API

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

Все эти инструменты используются в реальных проектах. Чаще, в публикуемых вакансиях можно встретить Postman и SoapUI — оба нужны для тестирования различных API. Первый для REST API, второй для API, построенных на SOAP архитектуре. Их можно и взаимозаменять, так как Postman позволяет делать SOAP запросы и наоборот. Но возможны и некоторые коллизии.  Однажды я пару часов не мог понять в чем проблема, а оказалось, что SoapUI не отображал полный rest ответ от сервера, ограничиваясь Alert’ом. Кроме всем известных инструментов, перечисленных в таблице, используется еще десяток сервисов или внутренних разработок для анализа и подготовки тестовых данных. “Стандартный” стек, кроме тех, что в описан выше: Nodepad++ с плагинами JsonXML, VS Code(swagger plugin), GIT, SQL Developer, PowershellUnix bash, Kibana(logs) или аналог. 

Особое внимание в главе про тестирование уделяется различным уязвимостям (vulnerabilities) при проектировании API и работам по их отслеживанию и предотвращению. Работа с конфиденциальными данными, человеческий фактор, XSS-атаки (Cross-site scripting), инъекции — в общем, обо всём этом поговорим в следующей статье.

Изучая материалы, связанные с обеспечением качества сложных систем, становится понятно, что это самое “качество” появляется на самом раннем этапе. Лучшие практики описывают процесс доставки ценности до потребителя в максимально эффективном виде. И если QA-специалист поставит себе цель донести эту ценность и это качество через весь процесс разработки до финальной стадии, то на выходе клиенты получат быстрый, надежный и удобный сервис. А компания, в свою очередь,  сэкономленные бюджет на разработку, дополнительную прибыль и лояльность. А что может быть важнее для компании, чем довольный и лояльный клиент.

Any capability that may be tested is defined as a TEST SCENARIO. It’s also known as Test Possibility or Test Condition. As a tester, you should put yourself in the shoes of the end user and determine the Application Under Test’s real-world scenarios and use cases.

In liner statements, a test scenario is a complete list containing test cases that cover end-to-end functionality of a software program. A scenario is defined as a liner statement. The test scenario is a classification of testable requirements at a high level. These criteria are categorized according to a module’s functionality and derived from use cases.

Because there are so many test cases in the scenario, there is a thorough testing process. The tester must evaluate the test cases for each scenario before completing the test scenario. Testers must put themselves in the shoes of the user in the test scenario because they are testing the software application from the user’s perspective. The most important aspect of the process is scenario preparation, which necessitates seeking advice or assistance from customers, stakeholders, or developers.

Important − Because the text scenario process does not include navigation steps or input, the test execution process cannot be done.

These are high-level documents that describe all of the conceivable permutations or various ways or combinations of utilizing the application, with the primary goal of understanding the application’s general flow.

Method of Writing Test Scenario

To build Test Scenarios as a tester, follow these steps —

• Examine the software’s requirement documents, such as SRS (System Requirement Specification), the BRS (Business Requirement Specification), and FRS (Functional Requirement Specification). You could also consult the application’s use cases, books, manuals, and other resources.

• For each requirement, determine all technical aspects and objectives.

• Find every feasible way for the user to interact with the software.

• Determine all possible scenarios in which the system could be exploited, as well as users who could be hackers.

• Make a list of various test cases to check each function of the software after reading the requirement document and completing the scheduled analysis.

• Create a traceability matrix after you’ve identified all of the possible test scenarios to see if each requirement has a matching test scenario or not.

• All possibilities are reviewed by the project supervisor. They are then evaluated by the project’s other stakeholders.

When writing test cases, we had to observe a few rules —

• Always keep a list of the most frequently utilized features and modules.

• We usually begin the scenarios by selecting modules one by one, in order to maintain a good sequence and avoid missing any module levels.

• Scenarios are usually defined at the module level.

• Delete scenario should always be the final resort; else, we will waste a lot of time re-creating data.

• It should be written in plain English.

• Every scenario should be written in a single or two-line format, try not to write in paragraphs.

• Do’s and checks should be included in every scenario.

Reason for creating Test Scenario

One test scenario can cover several test cases. As a result, Test Scenarios and Test Cases have a one-to-many relationship. However, the tester must consider each scenario when developing it. It was created by testers to test the application from the perspective of an end-user. Testers look for crucial information from all developers, stakeholders, and customers.

The following are the reasons for their creation −

• The design of excellent Test Scenarios ensures complete and proper Test Coverage.

• It is necessary to create them in order to investigate a program’s end-to-end functionality.

• They can be used to determine the most significant and critical end-to-end transactions or real-time application usage.

• They can be used as a tool for quickly determining testing workforce, which can then be utilized to assist clients or organizations with proposal creation and testing workforce organization efficiently and effectively.

• Approval of applications is done at multiple levels, including customers, business analysts, developers, and so on, to ensure thorough and proper testing.

When Test Scenario should not be created

There are some conditions in which its production should be prevented —

• It is unlikely to be developed in projects that use Agile Methodologies like Scrum.

• It may be avoided when the applications to be tested are unstable or excessively complicated, or when the project is in a critical-time state.

• Its creation may be prevented for regression testing or a new defect because substantial documentation of them would happen in previous test cycles in maintenance projects.

Features of Test Scenario

• The test scenario is a one-liner that directs testers through the testing process.

• The product’s complexity and repetition are reduced by using a test scenario.

• A test scenario is when you talk and think about tests in great detail yet write them down in liner statements.

• It’s a series of procedures threaded together.

• When the tester does not have enough time to write test cases and the team agrees on a comprehensive liner scenario, the test scenario becomes more significant.

• The test scenario is a useful activity for saving time.

• It is simple to maintain because adding and modifying test scenarios is simple and self-contained.

Test Scenario Examples

We’re using the Gmail application to create test cases for the most often used modules, such as Login, Compose, and inbox

Test Scenarios for the Login module

• Check that the home page is displayed after entering the correct login information (username and password).

• Check for the home page after entering the invalid Username and password.

• Check for an error message if you leave the username and password fields blank.

• Enter a valid Login, click Cancel, and look for the fields to be reset.

• Check that the account has been blocked by entering invalid Login more than three times.

• Check sure the Username is displayed on the home screen after entering a valid Login.

Test Scenario for compose module

• Checks if all users have access to the To, Cc, and Bcc email addresses.

• Check that the entire user has access to the To, Cc, and Bcc fields.

• Prepare a message, send it, and wait for a confirmation message.

• Compose an email, send it, and check the sender’s sent item as well as the inbox.

• Create a message, send it, and check for invalid and legitimate email addresses (valid format) in the sender’s inbox

• Check for conformation messages and check-in draft messages after composing main and then discarding it.

• After you’ve finished writing your email, save it as a draft and look for the confirmation message.

• Compose an email, shut it, and check for confirmation before saving it as a draft.

On the Inbox module, Test scenario.

• Check that all received mail is shown and highlighted in the inbox by clicking on it.

• Check that the sender email id for the most recent received email has been accurately displayed.

• Select the email, reply, and forward it; check the sender’s sent item and the receiver’s inbox.

• Examine any attached attachments to the email to see if they have been downloaded or not.

• Before downloading, be sure the attachment has been properly inspected for malware.

• Select the email, reply, and forward it, then save it as a draft. Check the Draft section for the confirmation message and checks.

• Check that all of the emails that have been marked as read have not been highlighted.

• Verify that all Cc recipients are visible to all users.

• Checks that all Bcc email recipients are hidden from the users.

• Select the message, delete it, and then check the Trash folder.

Any capability that may be tested is defined as a TEST SCENARIO. It’s also known as Test Possibility or Test Condition. As a tester, you should put yourself in the shoes of the end user and determine the Application Under Test’s real-world scenarios and use cases.

In liner statements, a test scenario is a complete list containing test cases that cover end-to-end functionality of a software program. A scenario is defined as a liner statement. The test scenario is a classification of testable requirements at a high level. These criteria are categorized according to a module’s functionality and derived from use cases.

Because there are so many test cases in the scenario, there is a thorough testing process. The tester must evaluate the test cases for each scenario before completing the test scenario. Testers must put themselves in the shoes of the user in the test scenario because they are testing the software application from the user’s perspective. The most important aspect of the process is scenario preparation, which necessitates seeking advice or assistance from customers, stakeholders, or developers.

Important − Because the text scenario process does not include navigation steps or input, the test execution process cannot be done.

These are high-level documents that describe all of the conceivable permutations or various ways or combinations of utilizing the application, with the primary goal of understanding the application’s general flow.

Method of Writing Test Scenario

To build Test Scenarios as a tester, follow these steps —

• Examine the software’s requirement documents, such as SRS (System Requirement Specification), the BRS (Business Requirement Specification), and FRS (Functional Requirement Specification). You could also consult the application’s use cases, books, manuals, and other resources.

• For each requirement, determine all technical aspects and objectives.

• Find every feasible way for the user to interact with the software.

• Determine all possible scenarios in which the system could be exploited, as well as users who could be hackers.

• Make a list of various test cases to check each function of the software after reading the requirement document and completing the scheduled analysis.

• Create a traceability matrix after you’ve identified all of the possible test scenarios to see if each requirement has a matching test scenario or not.

• All possibilities are reviewed by the project supervisor. They are then evaluated by the project’s other stakeholders.

When writing test cases, we had to observe a few rules —

• Always keep a list of the most frequently utilized features and modules.

• We usually begin the scenarios by selecting modules one by one, in order to maintain a good sequence and avoid missing any module levels.

• Scenarios are usually defined at the module level.

• Delete scenario should always be the final resort; else, we will waste a lot of time re-creating data.

• It should be written in plain English.

• Every scenario should be written in a single or two-line format, try not to write in paragraphs.

• Do’s and checks should be included in every scenario.

Reason for creating Test Scenario

One test scenario can cover several test cases. As a result, Test Scenarios and Test Cases have a one-to-many relationship. However, the tester must consider each scenario when developing it. It was created by testers to test the application from the perspective of an end-user. Testers look for crucial information from all developers, stakeholders, and customers.

The following are the reasons for their creation −

• The design of excellent Test Scenarios ensures complete and proper Test Coverage.

• It is necessary to create them in order to investigate a program’s end-to-end functionality.

• They can be used to determine the most significant and critical end-to-end transactions or real-time application usage.

• They can be used as a tool for quickly determining testing workforce, which can then be utilized to assist clients or organizations with proposal creation and testing workforce organization efficiently and effectively.

• Approval of applications is done at multiple levels, including customers, business analysts, developers, and so on, to ensure thorough and proper testing.

When Test Scenario should not be created

There are some conditions in which its production should be prevented —

• It is unlikely to be developed in projects that use Agile Methodologies like Scrum.

• It may be avoided when the applications to be tested are unstable or excessively complicated, or when the project is in a critical-time state.

• Its creation may be prevented for regression testing or a new defect because substantial documentation of them would happen in previous test cycles in maintenance projects.

Features of Test Scenario

• The test scenario is a one-liner that directs testers through the testing process.

• The product’s complexity and repetition are reduced by using a test scenario.

• A test scenario is when you talk and think about tests in great detail yet write them down in liner statements.

• It’s a series of procedures threaded together.

• When the tester does not have enough time to write test cases and the team agrees on a comprehensive liner scenario, the test scenario becomes more significant.

• The test scenario is a useful activity for saving time.

• It is simple to maintain because adding and modifying test scenarios is simple and self-contained.

Test Scenario Examples

We’re using the Gmail application to create test cases for the most often used modules, such as Login, Compose, and inbox

Test Scenarios for the Login module

• Check that the home page is displayed after entering the correct login information (username and password).

• Check for the home page after entering the invalid Username and password.

• Check for an error message if you leave the username and password fields blank.

• Enter a valid Login, click Cancel, and look for the fields to be reset.

• Check that the account has been blocked by entering invalid Login more than three times.

• Check sure the Username is displayed on the home screen after entering a valid Login.

Test Scenario for compose module

• Checks if all users have access to the To, Cc, and Bcc email addresses.

• Check that the entire user has access to the To, Cc, and Bcc fields.

• Prepare a message, send it, and wait for a confirmation message.

• Compose an email, send it, and check the sender’s sent item as well as the inbox.

• Create a message, send it, and check for invalid and legitimate email addresses (valid format) in the sender’s inbox

• Check for conformation messages and check-in draft messages after composing main and then discarding it.

• After you’ve finished writing your email, save it as a draft and look for the confirmation message.

• Compose an email, shut it, and check for confirmation before saving it as a draft.

On the Inbox module, Test scenario.

• Check that all received mail is shown and highlighted in the inbox by clicking on it.

• Check that the sender email id for the most recent received email has been accurately displayed.

• Select the email, reply, and forward it; check the sender’s sent item and the receiver’s inbox.

• Examine any attached attachments to the email to see if they have been downloaded or not.

• Before downloading, be sure the attachment has been properly inspected for malware.

• Select the email, reply, and forward it, then save it as a draft. Check the Draft section for the confirmation message and checks.

• Check that all of the emails that have been marked as read have not been highlighted.

• Verify that all Cc recipients are visible to all users.

• Checks that all Bcc email recipients are hidden from the users.

• Select the message, delete it, and then check the Trash folder.

Санкт-Петербургский
Государственный Университет Информационных
Технологий, Механики и Оптики

Кафедра Информационных
Технологий и Программирования

Лабораторная
работа №2.
Вар 1.

Тема:
Создание тестового сценария (test
case).

Выполнили студенты:

Шевченко Алексей

Тихонов Дмитрий

Группа: 5511

Преподаватель:

Санкт-Петербург

2008 год

Цель:
Научиться создавать простейшие тестовые
сценарии (test case).

Задание:
Написать тестовый сценарий из не
менее 10 шагов, Оплата мобильного телефона
через платежный терминал. Сценарий
должен включать в себя не только основной
вариант использования функционала, но
и ошибочный (например: ввод пустого/неверного
пароля в примере). Обратите внимание,
что все предварительные действия,
необходимые для прохождения шага, должны
быть явно описаны. Например, нельзя
требовать от тестировщика банкомата
ввести ПИН код до того как он вставил
карту.

4. Система прошла тестирование успешно,
за исключением антивандальной защиты
(необходимо сделать корпус прочнее). Мы
освоили написание тестовых сценариев,
а

Соседние файлы в папке все лабы итип

• #
• #
• #
• #
• #

  09.05.201437.89 Кб745511-5-s14&s17.xls

Автор: Екатерина Курач

Написать тест кейсы для «полного» тестирования продукта — просто невозможно. Мы можем разработать миллионы тестов, но будет ли время у нас их выполнить? Вероятнее всего — нет. Поэтому приходится тщательно выбирать тест кейсы, которые мы будем проводить.

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

Но, как известно, полностью протестировать программу невозможно по следующим причинам:

1. Количество всех возможных комбинаций входных данных слишком велико, чтоб его можно было проверить полностью.
2. Количество всех возможных последовательностей выполнения кода программы также слишком велико, чтобы его можно было протестировать полностью.
3. Пользовательский интерфейс программы (включающий все возможные комбинации действий пользователя и его перемещений по программе) обычно слишком сложен для полного тестирования.

Т.е. написать тест кейсы для «полного» тестирования продукта — просто невозможно. Мы можем разработать миллионы тестов, но будет ли время у нас их выполнить? Вероятнее всего — нет. Поэтому приходится тщательно выбирать тест кейсы, которые мы будем проводить.

Характеристики хорошего теста:

• Существует обоснованная вероятность выявления тестом ошибки
• Набор тестов не должен быть избыточным
• Тест должен быть наилучшим в своей категории
• Он не должен быть слишком простым или слишком сложным

В настоящее время наблюдается несколько методологий разработки тест кейсов. Они отличаются и теоретическим подходом, и практической реализацией.

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

Методология разработки тестовых случаев на основе сценариев использования

Случай использования состоит из некоторого множества сценариев: нормальный случай, расширения и исключительные ситуации. Для разработки тест кейсов на основе одного случая использования разрабатываются несколько сценариев, соответственно: Сценарий использования представляет собой оптимистический сценарий, который выбирается чаще других. В раздел Альтернативные пути могут быть включены несколько сценариев, которые отличаются от сценария использования в различных аспектах, однако остаются полноценными путями исполнения. В раздел Исключительные пути попадают те сценарии, которые приводят к возникновению ошибок. Каждый сценарий предусматривает действия, предпринимаемые действующим субъектом, и требует от системы отклика, который соответствует основной части тестового случая. Тестовый случай состоит из некоторого набора предусловий, стимулирующего воздействия (входные данные) и ожидаемого отклика.

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

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

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

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

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

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

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

1. Идентификация всех значений, которые вводятся действующими субъектами, содержащимися в модели случая использования
2. Выделение классов эквивалентности значений каждого типа входных данных
3. Построение таблиц, в которые помещен список комбинаций значений из различных классов эквивалентности
4. Построение тестовых случаев, в которых сочетаются одна перестановка значений с необходимыми внешними ограничениями

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

В таблице 1 показаны классы эквивалентности этих трех переменных.

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

В таблице 2 каждой из этих переменных отводится отдельный столбец. В эти столбцы помещены значения из различных классов эквивалентности рассматриваемых переменных. Каждая строка таблицы представляет собой описание конкретного теста.

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

Перестановки входных данных системы управления персоналом

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

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

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

Второй подход заключается в разработке тестовых случаев большого цикла (grand tour test cases), в котором каждый тестовый случай генерирует данные, которые служат входом для следующего тестового случая. По условиям такого подхода каждый тест переносит тестовые данные через весь жизненный цикл. Полученное при этом состояние базы данных используется в качестве входного для следующего теста. Этот метод особенно эффективен при тестировании жизненного цикла после того, как тестирование нижнего уровня позволило выявить большую часть дефектов, вызывающих отказы. Если выстроить тестовые случаи в соответствующую последовательность, то после успешного выполнения тестового случая 1 устанавливается такое состояние программы, которое ожидается как входное для тестового случая 2. Очевидная проблема в условиях очерченного подхода заключается в том, что неудачное выполнение тестового случая 1 оставляет программу в состоянии, которого мы не ожидали, в результате чего мы не можем выполнять прогон тестового случая 2 или даже вернуть программу в рабочее состояние.

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

• Тестирование на соответствие функциональным требованиям
• Проверка качественных системных атрибутов. Добротная организация разработок программного обеспечения предусматривает методы подтверждения всех системных «требований», включая и претензии на придание программному продукту особых качеств. Существуют два вида претензий, с которыми может столкнуться программа при разработке продукта. Первый вид претензий представляет интерес только для организаций, занимающейся разработкой программных продуктов. Например, утверждение, что «программный код допускает многократное использование». Второй тип претензий представляет интерес для пользователей системы. Например, утверждение о том, что система является более полной, нежели другие системы подобного класса, предлагаемые на текущий момент на рынке программных продуктов. Вполне понятно, что не все эти претензии могут подвергаться проверке через тестирование. Однако на это следует обратить внимание.
• Тестирование механизма развертывания системы
• Тестирование после развертывания системы. Естественное расширение тестирования механизма развертывания системы заключается в добавлении в тестируемый программный продукт функциональных средств самопроверки. Считается, что система «изнашивается» во времени по причине изменений, имеющих место в ее взаимодействии с окружением, примерно так же, как со временем изнашивается механическая система из-за трений между ее компонентами. По мере того, как устанавливаются все более новые версии стандартных драйверов и библиотек, несоответствия возрастают вместе с ростом вероятности возникновения отказов. Каждая новая версия dll-библиотеки привносит возможность появления новых областей нестыковки стандартных интерфейсов или появления состояния гонок между этой библиотекой и приложением. Функциональные средства самотестирования должны обеспечивать выполнение тестов, которые исследуют работу интерфейсов между этими программными продуктами.
• Тестирование взаимодействий окружения
• Тестирование системы безопасности

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

Литература:

1. Сэм Канер, Джек Фолк, Енг Кек Нгуен. Тестирование программного обеспечения. — Киев: Издательство «Диа Софт», 2001.—544 с.
2. Макгрейгор Джон, Сайкс Девид. Тестирование объектно-ориентированного программного обеспечения. Практическое пособие. — Киев: ООО «ТИД «ДС»», 2002.—432 с.

Лабораторная работа №2.

Тема: Создание тестового сценария (test
case).

Цель: Научиться создавать простейшие  тестовые
сценарии (test case).

Задание: Написать тестовый сценарий из не
менее 10 шагов, соответствующий полученному варианту задания. Сценарий должен
включать в себя не только основной вариант использования функционала, но и
ошибочный (например: ввод пустого/неверного пароля в примере). Обратите
внимание, что все предварительные действия, необходимые для прохождения шага,
должны быть явно описаны. Например, нельзя требовать от тестировщика банкомата
ввести ПИН код до того как он вставил карту.

Варианты:

1.  Оплата мобильного телефона через платежный терминал

1. Снятие наличных денег в банкомате

3.  Проезд в автобусе с кондуктором

4.  Использование будильника мобильного телефона

5.  Ксерокопирование

6.  Проход в метро (по смарт-карте и/или с жетоном)

7.  Закрывание двери ключом

8.  Поездка в лифте

9.  Звонок в службу поддержки Интернет-провайдера/мобильного оператора

Содержание отчета:

1.  Титульный лист с названием курса, номером и темой лабораторной работы, вариантом,
номером группы и Ф.И.О. авторов.

2.  Цель и задание, соответствующие полученному варианту.

3.  Результаты работы:

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

4.  Выводы: достигли ли цели работы, что сделали, чему научились и т.д.

Примерные вопросы
для подготовки защите:

1.  См. лабораторную работу №1

2.  Что такое тестовый сценарий? Каково его назначение? Из чего он состоит?

3. 
Что такое план тестирования? Каково его назначение? Из чего он состоит?

4.  Что такое шаг тестового сценария? Какого назначение каждого из его
полей?

5.  Напишите отчет о тестировании по вашему тестовому сценарию.

6.  …

Пример: