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

Давайте вообразим, что перед отделом тестирования, руководством была поставлена задача: провести API тестирование веб-компонента. С этого момента возникает масса вопросов, от «Что именно стоит протестировать?» до «Какие именно компоненты? Функциональную часть? Удобство использования?»

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

Как пример,используем схему виртуального SOAP API государственного проекта с весьма запутанной и сложной логикой.

Детально разберем, как нужно составлять проверки, как правильнее документировать их, а также на что именно необходимо обратить свое внимание.

Хорошие новости

При работе с любым API изначально есть 3 превосходные новости:

• Во время разработки API всегда создается блок технической документации, с помощью которой сторонние разработчики могут использовать созданный продукт в своих целях. Это значит, что начинать подготовку группы тестовых проверок можно уже на стадии создания ТЗ, что позволит глубже изучить специфику будущего функционала, а также обнаружить некоторые неточности еще до того, как продукт можно будет считать завершенным;
• Для всех SOAP-сервисов есть специальные схемы данных (XSD): валидация запроса по определенной схеме существенно упрощает жизнь QA специалисту. Базовая задача после релиза схемы – протестировать соответствие схемы ТЗ. Если логика схемы реализована вопреки положениям ТЗ, группа функциональных тестов будет иметь нулевую отдачу, так как подобную схему придется редактировать и проверять всегда заново;
• Традиционно функционал, создаваемый в API, отчасти повторяет определенную интерфейсную часть разрабатываемого продукта, а значит, можно оперировать визуализацией того, что и как должно отображаться в интерфейсе: дополнительно можно обнаружить ошибки в UI, так как проверка функционала проходит под иным углом зрения.

Подготовительные работы к созданию тест-дизайна API

При разработке базового «скелета» тестов можно использовать схемы или ментальные карты.

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

Симбиоз схем и ментальных карт

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

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

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

В нашем случае, необходимо проверить:

• Граничные значения для суммы полей (к примеру, телефонов у одного работника может быть более одного, а отчества вовсе не быть);
• Существующее ограничение на каждое поле в xsd;
• Граничные значения для данных внутри полей (в данном случае необходимо провести тесты на соответствие ограничений, установленных в ТЗ; а также верную реализацию схемы в back-end части, чтобы отображались ошибки формата, а не системные ошибки);
• Авторизационная верификация (все вообразимые проверки прав доступа). К примеру, функцией полного экспорта и импорта может пользоваться только один сотрудник с определенными правами (администратора). На стороне UI подобные проверки считаются неявными; если права отстуствуют, то у пользователя не отображается специальное меню или кнопка;
• Функциональные баги: если информация о работе изменилась на протяжении определенного временного промежутка, значит, необходимо выполнить проверку того, был ли этот работник в системе (дабы не плодить сущности): если в анкете работника есть нередактируемые поля (к примеру, никнейм), необходимо выполнять проверку того, что система – верно его идентифицирует, а также выдаст ошибку о неизменяемости полей при попытке их редактирования;
• При попытке создания и редактирования информации об учетных записях проводится проверка на корректность заполнения и отображения информации на UI (если таковой, конечно же, есть).

Основополагающие принципы

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

Кроме этого, очень удобно и правильно делить тесты по различным вариациям использования: для начала процесс импорта, потом выполнение экспорта (отдельно – от имени администратора, отдельно – от лица простого сотрудника).

Во время составления документации по итогам создания тест-дизайна, можно воспользоваться следующим порядком проверок:

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

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

Создание проверок

Теперь следует обратить внимание  непосредственно на процесс написания проверок. Стоит придерживаться следующих правил:

1. При создании тестов текст ТЗ нужно постоянно перерабатывать.

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

2. Рядом с тестами необходимо записывать конкретно ожидаемый результат.

• Все должно быть лаконично и понятно расписано, так как простая фраза «Выполнение сценария №1 из базового алгоритма» ничего не скажет человеку, который впервые видит подобные проверки;
• Если ожидается успешный импорт – так и следует записывать. Если при этом стоит проверить логику заполнения полей на UI или экспорт – так и записывайте;
• Если ожидается появление определенного сообщения, не стоит банально писать его порядковый номер, в частности тогда, когда вы до конца не знаете, кто впоследствии будет пользоваться этим списком для проведения тестов. Проведите сравнение для фраз: «Появляется сообщение 060» или «У вас недостаточно прав для проведения этой операции». То есть подобным образом вы не только проверяете непосредственное наличие сообщения, но и верность его реализации.

3. Задумайтесь над тем, кто и когда будет использовать ваш документ для проверок.

• Новички, которые только-только познакомились с функционалом вашего продукта? Тогда стоит составлять проверки как можно детальнее, так как у них могут появиться проблемы еще до того, как они столкнутся с первой проверкой;
• Опытные сотрудники, которые и самостоятельно смогли бы написать подобный материал? Тогда используйте исключительно те термины, с которыми они лично знакомы;
• Если окажется, что проверки вы составляете исключительно для себя, чтобы ничего не упустить в тестах, подумайте над тем, когда именно данный функционал будет окончательно реализован. Наш мозг – очень хитрая и умная штука, которая никогда не сохраняет в себе ненужные данные. Если есть неуверенность в том, что проверки будут выполняться сегодня-завтра, расписывайте все подробно, чтобы через год и более не пришлось по новой знакомится с содержанием ТЗ и думать, что именно вы хотели там отобразить.

4. Добавьте ссылку на ТЗ по этому функционалу к проверкам и не забывайте постоянно проверять, не изменилась ли она.

5. Если же после завершения составления проверок прошло определенное время, и часть функционала была реализована (в частности, это значительно затрагивает процесс тестирования доработок, которые расширяют уже созданный функционал), нужно затратить некоторое время на переработку тестов. Любая, даже самая утонченная и грамотная, документация имеет необратимое свойство устаревать. И это нормальное явление. Но не нужно выполнять правки по ходу тестов – можно потерять драгоценное время, пока найдется причина, по которой система не функционирует именно так, как изначально ожидалось полгода назад: плюс вы рискуете распрощаться с некоторыми важными проверками и пропустить заметные баги.

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

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

8. Делите тест на проверки так, чтобы на выполнение одной проверки у вас уходило не более 5 минут с подготовкой всех тестовых компонентов. Не нужно браться за выполнение проверки, которая подразумевает проверку сразу нескольких компонентов. Пусть тестов будет 10-20, но они будут максимально подготовлены и просты в выполнении;

9. Если стоит задача провести тесты на массовый импорт, задумайтесь над тем, как проще подготовить данные и отметьте это внутри документации с тестами.

Шаблонный вид оформления итогов тест-дизайна API

Перед нами подробный список полей, которые должны быть в тест-дизайне:

• Функция пользователя;
• Проверка;
• Ожидаемый результат;
• Планируемый временной отрезок;
• Комментарии;
• Статус теста;
• Дата проверки;
• Ревизия, тестовый стенд;
• Клиент для проверки.

На практике это выглядит как-то так:

Список полей тест-дизайна

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

Итоги

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