Тестирование API — лучшая стратегия для принятия

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

Недавно я занимался автоматизацией тестирования Rest API. У нас есть один API-интерфейс для извлечения ресурсов (этот API-интерфейс в основном используется в пользовательском интерфейсе нашего веб-приложения для различных бизнес-процессов для получения данных), хотя это один и тот же API-интерфейс ресурсов, фактическая конечная точка соответственно различается для разных ситуаций. т. е. передаваемые параметры запроса в URL-адресе API отличается в зависимости от бизнес-процесса.

Например что-то вроде

`./getListOfUsers?criteria=agedLessThanTen ../getListOfUsers?criteria=agedBetweenTenAndTwenty ../getListOfUsers?criteria=agedBetweenTwentyAndThirty и т. д.

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

Этот тест подходит для подтверждения того, что конечные точки работают, а содержание ответа хорошее или нет.

Мои настоящие вопросы касаются стратегии тестирования или бизнес-прикрытий здесь,

  1. Достаточно ли здесь одного попадания в конечную точку API или нет.

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

  3. Если конечные точки API дополняют друг друга, добавляя больше тестов, не будет ли это просто дублированием тестов/дополнительным обслуживанием/и другими проблемами позже, и следует ли нам этого избегать? если он не дает значения?
  4. Какова общая тенденция автоматизации API в отношении покрытия? . Я считаю, что его следует использовать для тестирования потоков бизнес-интеграции и сценариев, если это необходимо, но для таких ситуаций, как эта, действительно ли это необходимо
  5. также следует помнить об этом моменте?, что автоматизация не заменяет ручное тестирование, а только дополняет его. и попытка автоматизировать каждый возможный сценарий не принесет пользы, а только вызовет проблемы с обслуживанием позже?

Спасибо


api testing automated-tests web-api-testing
person Musaffir Lp    schedule 11.10.2018    source источник

Ответы (1)


arrow_upward
0
arrow_downward

Достаточно ли здесь одного попадания в конечную точку API или нет.

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

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

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

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

Я использовал много условных выражений выше, так как только вы можете оценить ситуацию в свете реальной системы.

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

person Rsf    schedule 11.10.2018
comment
Спасибо @Rsf, это имеет для меня большой смысл. Мне пришлось использовать тестовые данные как жестко закодированные значения в файле, потому что это фактические значения, которые будут присутствовать в содержимом ответа при нажатии на конечные точки API. Таким образом, эти данные в файлах точно такие же, как и в базе данных тестового сервера. Генерация данных на лету выглядит неосуществимой, если мне нужно проверить содержимое ответа. - person Musaffir Lp; 15.10.2018