Home

Автор: Анна Хворостьянова

Представьте, что перед Вами поставили задачу: протестировать API веб-сервиса. На этом этапе возникает довольно много вопросов, начиная от “Что именно требуется протестировать? Функционал? Нагрузку? Юзабилити?” до “Чем отличается список проверок для тестирования API от чек-листа для проверки UI”? В данной статье я поделюсь своим опытом составления проверок и кейсов для функционального тестирования SOAP API крупного государственного проекта со сложной логикой; мы обсудим, как лучше писать проверки и на что следует обратить особое внимание; в конце я представлю примерный вид документа с результатами тест-дизайна, которым будет удобно пользоваться и который не стыдно показать менеджеру или заказчику.

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

При тестировании API есть три хороших новости:

1. При создании API всегда создается документация, благодаря которой сторонние разработчики смогут использовать Ваш продукт. Это означает, что начать подготовку тестовых проверок можно уже на этапе подготовки ТЗ, что поможет Вам глубже понять логику реализуемого функционала, а также позволит выявить неточности и неоднозначные формулировки еще до того, как задача будет передана разработчикам.
2. Для SOAP-сервисов существуют схемы данных (XSD); валидация запросов по схеме значительно упрощает работу тестировщика. Главная задача после релиза схем - проверить соответствие схемы ТЗ. Если схема реализована не в соответствии с техническим заданием, функциональные тесты могут пройти впустую, т.к. схему будут переделывать и придется проверять все заново.
3. Часто функционал, реализуемый в API, повторяет какую-то интерфейсную часть Вашего продукта, поэтому в данном случае можно увидеть визуализацию того, что должно быть в программном интерфейсе; кроме того, можно найти и баги UI, т.к. тестирование функционала происходит под другим углом зрения.

Подготовка к тест-дизайну

При создании основного “скелета” проверок можно рисовать схемы или mind-карты. Моя схема-напоминалка в общем виде обычно выглядит так:

Смотреть схему в большем размере

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

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

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

●      Ограничения на каждое поле в xsd (подробнее можно прочитать на w3schools.com, аналог статьи на русском - здесь)

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

●      Граничные значения для информации внутри полей (здесь необходимо проверить соответствие ограничений схемы ТЗ; а также правильную реализацию схем на бекенде, чтобы возникали ошибки формата, а не системные ошибки)

●      Авторизационные проверки (сюда включаются все проверки прав доступа). Например, импортом и полным экспортом может пользоваться только сотрудник с правами администратора. На UI эти проверки являются неявными, если прав нет, то у пользователя не появляется данное меню/кнопка.

●      Функциональные ошибки: если данные о сотруднике изменяются по истечение времени, то необходимо проверить, был ли такой сотрудник в системе (чтобы не плодить сущности); если в анкете сотрудника есть неизменяемые поля (например, логин), необходимо проверить, что система: во-первых, правильно идентифицирует пользователя (например, по присвоенному id); во-вторых, выдает ошибку неизменяемых полей при попытке их изменения.

●      При создании и изменении данных учетных записей необходимо проверять корректность заполнения и отображения данных на UI (если таковой присутствует).

Базовые принципы

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

При оформлении документа по результатам тест-дизайна я предлагаю такой порядок проверок:

1. Форматные контроли
2. Базовые проверки успешного импорта
3. Массовый импорт (большое количество сущностей)
4. Бизнес-ошибки и ошибки интеграционного слоя (те, которые просто не могут возникнуть в пользовательском интерфейсе, т.к. форма имеет фиксированное количество полей или пользователь имеет доступ только к определенным операциям). Здесь же стоит разместить авторизационные контроли (проверки на наличие прав доступа)
5. Проверки успешного экспорта
6. Массовый экспорт
7. Проверки сообщений при ошибках экспорта (например, если нет данных; ошибки прав доступа)

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

Написание проверок

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

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

• Во-первых, слепое копирование ТЗ не позволит Вам продумать достаточное количество проверок.
• Во-вторых, Вы рискуете упустить то, что уже упустили аналитики при составлении логики работы функционала.
• В-третьих, при сведении проверок в единую таблицу лучше всего использовать не общие выражения из ТЗ, а названия конкретных операций и тегов (сравните: “Создать пользователя. Заполнить поля “Имя", “Фамилия", “Идентификатор"" или “Выполнить ImportUserAccount, заполнив теги UserSurname, Username, UserId”. Идентификаторов в запросе может быть несколько, а UserId явно будет единственным.)

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

• Поясню: фраза “Выполнение Базового сценария 1 из основного алгоритма” вряд ли что-то скажет человеку, который впервые увидел ваши проверки.
• Если ожидается успешный импорт - так и напишите. Если нужно при этом проверить заполнение полей на UI или выполнить экспорт - напишите это тоже!
• Если Вы ожидаете какое-то сообщение, не пишите просто его номер, особенно, если Вы не знаете, кто потом будет пользоваться этим списком проверок для теста. Сравните: “Возникает сообщение 060” или “Возникает сообщение 060 “У Вас нет прав для проведения данной операции””. Таким образом вы не только проверяете наличие сообщения, но и правильность его реализации.

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

• “Зеленые” новички, которые только начали погружаться в  продукт? Тогда нужно писать как можно подробнее, ведь у них могут возникнуть проблемы еще до того, как они доберутся до первой проверки.
• “Матерые” коллеги, которые и сами вполне могли бы написать такой ТД? В этом случае используйте только те термины, которые точно знают ваши коллеги. Если только Вам удобно использовать англицизмы вроде “реквест”, “респонс”, а тестировщикам милее слова “запрос” и “ответ”, учтите это.
• Если вы знаете, что пишете проверки для себя, чтобы ничего не упустить при тесте, подумайте, когда данный функционал будет реализован. Человеческий мозг - очень хитрый инструмент, который быстро избавляется от ненужной информации. И если вы не уверены, что тестирование будет происходить сегодня-завтра, пишите подробнее, чтобы через полгода не пришлось заново читать ТЗ и вникать, что же вы хотели здесь проверить.

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

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

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

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

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

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

Примерный вид оформления результатов тест-дизайна

Для себя я сформировала следующий список обязательных полей, который должен быть в ТД:

• Полномочие (функция пользователя, в нашем примере - это администратор или сотрудник)
• Проверка
• Ожидаемый результат
• Планируемое время
• Комментарий (сюда записываются дефекты или замечания по фактическому результату)
• Статус проверки (в наших документах он реализован в виде выпадающего списка со статусами “Пройдено”, “Провалено”, “С замечаниями”, “Блокировано”, “Не тестировалось”)
• Дата проверки
• Тестовый стенд, ревизия
• Пользователь для проверки

Выглядит это примерно следующим образом:

 Смотреть табличку в полном размере

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

Заключение

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

Подробнее о тестировании API (в том числе, нефункциональном) можно прочитать на сайте SmartBear, а также в презентации Тоби Клемсона.

Обсудить в форуме