В этой статье мы рассмотрим описание процесса тестирования программного обеспечения сквозь призму работы с 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).

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

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

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

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

  

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

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

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

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

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

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

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

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

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

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

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

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

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