Ку! Меня зовут Евген, и я Автоматизатор тестирования на Python. В этой статье я расскажу как из вопроса ко мне "на сколько % у нас покрыта API автотестами?" Я выдал базу в виде регламента по автоматизации API.
Введение
В один прекрасный июльский день ко мне приходит менеджер и спрашивает:
-
М: - а на сколько наши апи покрыты автотестами?
-
Я: - вот наша документация по тестированию, там все тест-кейсы есть.
-
М: - АЭэ, а можна это всё один документ? В эксельник конечно же. А то неудобно и непонятно.
В один прекрасный сентябрьский день ко мне приходит менеджер и спрашивает:
-
М: - а на сколько тот документ актуален?
-
Я: - на июль.
-
М: - надобно актуализировать.
В один прекрасный ноябрьский день ко мне приходит менеджер и спрашивает:
-
М: - а на сколько % у нас покрыта API автотестами?
-
Я: о_О (что есть 100%?) -
Тут я понял что так продолжаться больше не может. И решил описать в первую очередь для себя, что же можно назвать 100% покрытием? Для начала мы разберем основные подходы к покрытию автотестами API сервиса: что покрывать, как покрывать, какие типы тестов необходимы для определенного типа метода и т.п.. Как оценивать покрытие и определение для утверждений "метод покрыт" и "100% покрытие".
Как прокрывать API автотестами?
Для ответа на этот вопрос, я решил создать схему(структуру) где все разделено на типы, подтипы и взаимосвязи. А именно:
-
Разбить методы на подтипы для определения набора доступных тест-кейсов.
-
Разбить тест-кейсы на типы проверок.
-
Разбить шаги тест-кейса на типы для определения требуемого набора в конкретном случае.
Подтипы методов
Опытным путём были выявлены и сформированы основные подтипы методов которые можно применить к любой структуре запроса-ответа.
-
GET STATIC OBJECT - метод GET на статичный объект, данные которые никогда не должны меняться.
-
GET DINAMIC OBJECT - метод GET на динамический объект который может быть создан, отредактирован, удалён.
-
GET LIST OBJECTS - метод GET на список объектов который возвращает множество объектов, может пополняться и сокращаться, фильтроваться, сортироваться и иметь пагинацию.
-
POST CREATE OBJECT - метод POST для создание объекта. Может иметь зависимости из других сервисов/объектов, например: id черновика - они являются обязательными для создания объекта.
-
POST UPLOAD FILE - метод POST для загрузки файлов. Может иметь ограничения на вес файла и формат (mime types). А так же разновидность типа передачи данных - json, form-data.
-
POST CREATE OBJECT TO OBJECT - метод POST для создание объекта для объекта. Например лайк или комментарий к посту.
-
POST FILTER/SORT/OBJECTS ON LIST - метод POST для возврата списка объектов. Возвращает множество объектов, может пополняться и сокращаться, фильтроваться, сортироваться и иметь пагинацию.
-
PATCH OBJECT - метод PATCH для обновления объекта.
-
PATCH ELEM ON OBJECT - метод PATCH для обновления элемента(ов) объекта.
-
PUT OBJECT - метод PUT для обновления объекта.
-
DELETE OBJECT - метод DELETE для удаления объекта.
Типы тест-кейсов
Выявлены и сформированы основные типы тест-кейсов которые применимы в разных конфигурациях(в зависимости от особенностей реализации) для каждого метода и его подтипа. Описание каждого типа тест-кейса отображена в таблице ниже.
Столбцы в таблице ниже
-
TestCaseType - тип тест-кейса который применим к перечню методов.
-
Sub.Methods - подтип метода, к которому применим тест-кейс.
-
Priority - приоритет тест-кейсов для реализации, не путать с приоритетом эндпоинта к покрытию.
|
TestCaseType |
Sub.Methods |
Priority |
|
TC: RequsetDefault Дефолтный тест-кейс, проверяет работоспособность эндпонита и корректность его данных для дальнейшего тестирования. Является первым и самым приоритетным тестом. Steps: 1. StatusCode |
GET STATIC OBJECT |
1 |
|
TC: RequestCompareBenchmark Показательный тест-кейс, использует выборочный объем доступных данных и проверяет что мы получили ожидаемые нам объекты или значения в рамках тестируемого объекта. Steps: 1. StatusCode |
GET STATIC OBJECT |
1 |
|
TC: Тест-кейс проверки ролевой модели и прав доступа к данным. Покрытие эндпоинтов админки и эндпоинтов доступа к личным данным пользователей. Steps: 1. StatusCode SubTestCases: - Sub.TC: Incorrect credentials -запрос с некорректными данными аутентификации
|
GET STATIC OBJECT |
1 |
|
TC: RequestNewObject Тест-кейс проверки для нового, созданного объекта. Этот тест-кейс зависит от метода создания и реализуется совместно или в зависимости от тест-кейса создания. Steps: 1. StatusCode SubTestCases: - Sub.TC: RequsetDefault - дефолтный тест-кейс для проверки доступности и корректности нового объекта. |
GET DINAMIC OBJECT |
1 |
|
TC: RequestUpdateObject Тест-кейс проверки для обновленного объекта который был создан или существовал. Этот тест-кейс зависит от метода изменения и реализуется совместно или в зависимости от тест-кейса изменения. Применим и для проверки сброса кэша. Steps: 1. StatusCode SubTestCases: - Sub.TC: RequsetDefault - дефолтный тест-кейс для проверки доступности и корректности отредактированного объекта. |
GET DINAMIC OBJECT |
1 |
|
TC: RequsetIncorrectBody Тест-кейс проверки корректного ответа(ошибки) при попытке прокинуть данные в некорректном для API формате. Включает в себя перебор стандартных проверок. Главным показателем является отсутствие чувствительных данных в ответе. Steps: 1. StatusCode |
POST CREATE OBJECT |
1 |
|
TC: RequstEnvList Тест-кейс проверки доступности объекта в разных окружениях где он должен выводится в соответствии с ожиданиями, например: админка, публичка(если опубликовано). Steps: 1. StatusCode |
GET STATIC OBJECT |
2 |
|
TC: RequestsParams Тест-кейс проверки отправки запроса с параметрами фильтрации, сортировки и пагинации. В рамках тест-кейса проверяется корректный вывод и работоспособность параметров. Steps: 1. StatusCode SubTestCases: - Sub.TC: RequestParamsFilters - проверка параметров фильтрации |
GET LIST OBJECTS |
2 |
|
TC: RequsetElements Тест-кейс проверки элемента объекта. Проверяется качество и поведение при изменениях в ключах и значениях тела запроса. Steps: 1. StatusCode SubTestCases: - Sub.TC: RequestOnlyRequiredElem - проверка запроса только с обязательными элементами |
POST CREATE OBJECT |
2 |
|
TC: RequestNotFound Тест-кейс проверки на 404 ошибку. Применяется для корректного поведения ответа на несуществующие или удаленные объекты/адреса. Steps: 1. StatusCode |
GET STATIC OBJECT |
2 |
|
TC: RequestExtraData Тест-кейс с "лишними" данными в запросе. Проверяется корректное поведение при добавлении этих данных в зависимости от реализации. Главным показателем является отсутствие чувствительных данных в ответе. Steps: 1. StatusCode SubTestCases: - Sub.TC: RequestAddBody/AddBodyElem - проверка добавления body в ГЕТ метод или добавление элемента в тело POST/PATCH/PUT запроса. |
GET STATIC OBJECT |
3 |
|
TC: RequsetNotAllowed Тест-кейс проверки корректного ответа(ошибки) при попытке обратится к эндпоинту с неподдерживаемым типом метода. Steps: - StatusCode |
GET STATIC OBJECT |
3 |
Шаги тест-кейсов
Выявлены и сформированы основные проверки в тест-кейсах, именуемые далее как шаг(step) которые применимы в разных конфигурациях(в зависимости от особенностей реализации) для каждого тест-кейса.
-
Step 1: StatusCode - проверка статус кода ответа.
-
Step 2: ResponseCompareBodySwagger - сравнение тела ответа с телом примера в сваггере.
-
Step 3: ResponseValidateBodyScheme - валидация тела ответа, например с помощью pydentic.
-
Step 4: GetElemet - получение необходимых ключей и их значений из тела ответа.
-
Step 5.1: CompareBenchmark - эталонное сравнение. Подразумевает что мы получили именно то что и ожидали, конкретное значение у ключа.
-
Step 5.2: CompareBoundary - допустимое сравнение. Подразумевает что мы получили значение ключа в рамках допустимого.
Step 2 и Step 3
Разница ResponseCompareBodySwagger и ResponseValidateBodyScheme:
CompareBodySwagger - непосредственное сравнение ответа и примера из сваггера.
ValidateBodyScheme - валидация схемы ответа с помощью модели которую описал автотестировщик в коде.
Причина разделения: человеческий фактор - не в 100% случаях разработчик внесет новые данные в сваггер. Ускоряет время локализации проблемы а так же закрывает необходимость ручной проверки схемы на актуальность.
Step 5
CompareBenchmark и CompareBoundary взаимозаменяемые шаги.
Как оценивать покрытие API автотестами?
Покрытие метода с использованием всех вышеупомянутых тест-кейсов представляет собой весьма трудоёмкий процесс. Более того, нельзя утверждать, что данное перечисление является исчерпывающим и абсолютно полным, поскольку оно не учитывает специфические аспекты реализации и пользовательские кейсы, которые также могут возникнуть. Тем не менее, мы можем согласовать минимально необходимый объем и тип этих тест-кейсов для покрытия большей площади за меньшее время, что особенно важно на интенсивном этапе разработки. Параллельно с этим, мы сможем уделять больше внимания методам и эндпоинтам, имеющим более высокий приоритет для покрытия.
И как итог, ниже представлен условный список примеров с обязательным покрытием метода автотестами, что в дальнейшем мы можем назвать "100% покрытие".
-
У метода присутствуют все тест-кейсы первого приоритета.
-
У метода присутствуют 4 тест-кейса: 2 позитивных и 2 негативных.
-
У метода присутствуют все тест-кейсы связанные с бизнес-логикой.
P.S.:
Эта статья исходит из написанной мной "инструкции" для себя же и находится в стадии постоянного обновления. Для опытного глаза она очевидно не "полная" и может содержать неточности, упущения. Одна из целей этой статьи, поделится опытом и мыслями по данному вопросу.
Автор: BaroH
