Что такое api

Зачем нам нужны тесты?

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


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

Если функция работает не так, как мы ожидаем, то можно внести исправления в код и запустить её ещё раз. Так можно повторять до тех пор, пока функция не станет работать так, как нам нужно.

Однако, такие «ручные перезапуски» – не лучшее решение.

При тестировании кода ручными перезапусками легко упустить что-нибудь важное. Например, мы работаем над функцией

Написали часть кода и решили протестировать. Выясняется, что работает правильно, в то время как – нет. Мы вносим в код исправления, и теперь работает правильно. Вроде бы, всё хорошо, не так ли? Однако, мы забыли заново протестировать. Возможно, после внесения правок стала работать неправильно

Например, мы работаем над функцией . Написали часть кода и решили протестировать. Выясняется, что работает правильно, в то время как – нет. Мы вносим в код исправления, и теперь работает правильно. Вроде бы, всё хорошо, не так ли? Однако, мы забыли заново протестировать . Возможно, после внесения правок стала работать неправильно.

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

Автоматическое тестирование означает, что тесты пишутся отдельно, в дополнение к коду. Они по-разному запускают наши функции и сравнивают результат с ожидаемым.

Best Practices of API Testing:

  • Test cases should be grouped by test category
  • On top of each test, you should include the declarations of the APIs being called.
  • Parameters selection should be explicitly mentioned in the test case itself
  • Prioritize API function calls so that it will be easy for testers to test
  • Each test case should be as self-contained and independent from dependencies as possible
  • Avoid «test chaining» in your development
  • Special care must be taken while handling one-time call functions like — Delete, CloseWindow, etc…
  • Call sequencing should be performed and well planned
  • To ensure complete test coverage, create test cases for all possible input combinations of the API.

Архитектура функциональных тестов

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

Как видно, функциональный тест состоит из нескольких «программных» модулей (обозначены прямоугольниками со сглаженными углами), и нескольких «модулей данных» (на практике, модули данных также могут быть программными, то есть содержать код — например, объявление констант), которые обозначены в виде листа бумаги с загнутым уголком:

Тест-кейс содержит последовательность действий над тестируемой системой и тестовые данные для каждого действия (может состоять из нескольких файлов — например, тестовые данные можно выделить в отдельный файл, а «драйвер данных» этого файла (который и будет вызвать методы менеджера функционального тестирования) — в другой).

Менеджер функционального тестирования вызывается из тест-кейса для выполнения действий над тестируемой системой и выполнения проверок. Он управляет сохранением состояний системы, вызовом функций «интерфейсного драйвера» и соответствующих им оракулов.

Менеджер функционального тестирования удобнее всего выделить в отдельный модуль.

Библиотека оракулов. Содержит проверки функциональности. Использует константы, описывающие поведение системы (могут «физически» в том же файле, что и сами оракулы). Использует объекты состояния системы для получения переменных состояния каждого компонента системы. Объекты состояния системы для оракулов предоставляет «менеджер функционального тестирования».

Библиотека классов состояния системы. Содержит классы, хранящие переменные состояния (выходные данные) для каждого компонента (экрана, окна, страницы).

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

Константы, описывающие поведение системы — взаимосвязи между переменными состояния (а также взаимосвязи между частями системы) могут быть выделены в отдельный файл «данных», а могут быть составной частью библиотеки оракулов

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

Отчёт о выполнении теста содержит сообщения всех программных модулей — менеджера функционального тестирования (о выполненных действиях над системой), библиотеки оракулов (о проваленных проверках, а также о результатах проверок, требующих дополнительного «ручного» анализа), интерфейсного драйвера (о проблемах взаимодействия с пользовательским интерфейсом системы).

Рис.1. Архитектура типичного автоматизированного функционального теста

Классификация инструментов

Драйвер

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

Для каждого интерфейса, кроме, собственно, API, необходим свой драйвер. Например, когда вы даёте драйверу для GUI команду “Нажать на кнопку Menu”, он воспринимает её через API и отсылает в тестируемое приложение, где эта команда превращается в клик по графической кнопке Menu. Для взаимодействия с API приложения драйверы не нужны или почти не нужны — взаимодействие программное. А вот при работе с остальными интерфейсами без них не обойтись. Наиболее сложными обычно являются драйверы для GUI, так как этот интерфейс сильно отличается от обычного для программы общения кодом. При этом в автоматизированном тестировании мобильных приложений GUI наиболее актуален, так как в интеграционном тестировании использовать чаще всего приходится именно его. Наиболее популярные драйвера для GUI в мобильном тестировании — и для Android, — для iOS.

Надстройка

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

У надстройки могут быть следующие функции:

  1. Модификация поведения (без изменения API). Например:
    • дополнительное протоколирование,
    • валидация данных,
    • ожидание выполнения действия в течение определённого времени.
  2. Повышение удобства и/ или уровня абстракции API через:
    • использование синтаксического сахара — удобных названий функций, более коротких обращений к ним, унифицированного стиля написания тестов;
    • неявное управление драйвером, когда, например, он инициализируется автоматически, без необходимости прописывать каждое такое действие вручную;
    • упрощение сложных команд вроде выбора события из календаря или работы с прокручивающимися списками;
    • реализацию альтернативных стилей программирования, таких как процедурный стиль или fluent.
  3. Унификация API драйверов. Здесь надстройка предоставляет единый интерфейс для работы сразу с несколькими драйверами. Это позволяет, например, использовать один и тот же код для тестов на iOS и Android, как в популярной надстройке .

Фреймворк

С другой стороны тестов находится фреймворк запуска. В рамках данной статьи я буду коротко называть его “фреймворк”. Фреймворк — это программа для формирования, запуска и сбора результатов запуска набора тестов.

В задачи фреймворка входят:

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

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

Поэтому важно не путать понятия “драйвер” и “фреймворк”. Конечно, в некоторых фреймворках есть собственные драйверы для работы с приложениями, но это вовсе не обязательное условие

Самые заметные фреймворки в мобильном тестировании — и .

Комбайны

Наконец, ещё одна группа утилит, использующихся для автоматизации тестирования мобильных приложений, — это комбайны, объединяющие в себе и фреймворки, и драйверы (причём не только мобильные), и даже возможности разработки. , , — все они поддерживают автоматизацию тестирования iOS-, Android-, веб-приложений, а два последних — ещё и десктоп-приложений.

Итак, инструменты мы классифицировали. Осталось определить самые популярные в каждой категории и сравнить их.

Описание


тренер: Ольга Назина

На курсе мы будем писать автотесты для API-методов в программе Postman. Мы пройдем полный цикл — от первого автотеста до настройки CI (Continuous Integration). От Math.random до циклов и условий. От простого include до регулярных выражений. Это курс вам подойдет, если:

  1. Вы не умеете автоматизировать — Postman дает отличный и простой старт.
  2. Вы тестируете API черным ящиком — например, это «чужое» API, а вы работаете в интеграторе

После прохождения курса вы сможете настроить систему автотестов для ваших API-методов, даже если ранее на проекте никакой автоматизации не было вообще!

Главная фишка курса — МНОГО практики! На курсе 57 (!) обязательных домашних заданий. Обучение идет 14 недель (3,5 месяца) — 13 занятий и неделя в конце на «хвосты».

На курсе не рассказывается о том, как тестировать rest-методы. Если вы никогда раньше не тестировали API, вам лучше сначала пройти курс «Тестирование REST API». Здесь же мы будем заниматься именно автоматизацией, написанием кода.

Входной порог! Я предполагаю, что вы:

  1. Знаете английский на уровне «чтение со словарем / гуглтранслейтом». Мы будем тестировать в том числе JIRA API по стандартной документации, которая на английском. Вы должны прочитать описание метода и понять его.
  2. Знаете любой язык программирования на уровне школьной программы или «читал книгу о нем 3 года назад» — не падаете в обморок от слов «переменные», «массивы», знаете какие бывают типы данных и операторы сравнения. Тренер расскажет про эти понятия в привязке к примерам, но вам будет проще, если что-то почитаете заранее. Посмотрите этот кусок лекции, если он непонятный, то на курс рановато.
  3. Умеете тестировать: знаете про классы эквивалентности и граничные значения. Подробнее см в блоке «Вопросы и ответы»

Расширение спецификации

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

Как было сказано, функция предназначена для работы с целыми положительными значениями .

Для обозначения математических ошибок функции JavaScript обычно возвращают . Давайте делать также для некорректных значений .

Сначала давайте опишем это поведение в спецификации.

Результаты с новыми тестами:

Новые тесты падают, потому что наша реализация не поддерживает их. Так работает BDD. Сначала мы добавляем тесты, которые падают, а уже потом пишем под них реализацию.

Другие функции сравнения

Обратите внимание на. Это проверка того, что переданное значение равно

Библиотека Chai содержит множество других подобных функций, например:

  • – проверяет равенство .
  • – проверяет строгое равенство .
  • , – проверяет неравенство и строгое неравенство соответственно.
  • – проверяет, что
  • – проверяет, что
  • …с полным списком можно ознакомиться в документации

Итак, нам нужно добавить пару строчек в функцию :

Теперь работает, все тесты проходят:

Открыть готовый пример в песочнице.

Приложения

Для автоматизации тестирования существует большое количество приложений. Наиболее популярные из них по итогам 2007 года:

  • HP LoadRunner, HP QuickTest Professional, HP Quality Center
  • Segue SilkPerformer
  • IBM Rational FunctionalTester, IBM Rational PerformanceTester, IBM Rational TestStudio
  • TestComplete (англ.)русск.

Использование этих инструментов помогает тестировщикам автоматизировать следующие задачи:

  • установка продукта
  • создание тестовых данных
  • GUI взаимодействие
  • определение проблемы

Однако автоматические тесты не могут полностью заменить ручное тестирование. Автоматизация всех испытаний — очень дорогой процесс, и потому автоматическое тестирование является лишь дополнением ручного тестирования. Наилучший вариант использования автоматических тестов — регрессионное тестирование.

Инструменты

IBS AppLine использует лучшие решения от признанных лидеров области разработки средств автоматизированного тестирования: HP Unified Functional Testing, IBM Rational Functional Tester, Rational Integration Tester, SmartBear TestComplete, Selenium, MS CodedUI. Если возможности доступных инструментов не позволяют решить весь спектр задач клиента, сотрудники IBS AppLine самостоятельно разрабатывают необходимые утилиты.

В автоматизированном тестировании ПО не существует универсального рецепта, ведь у каждого заказчика разные первоначальные условия. Наша профессиональная команда найдет эффективные и рациональные инструменты тестирования для каждой конкретной системы. Аутсорсинг тестирования ПО дает заказчику уверенность в том, что его ПО действительно высокого качества.

Формат автоматизированного тестирования имеет особое значение в таких важных областях как

  • биллинговый софт,
  • системы ПО, используемые для массового обслуживания клиентов,
  • CRM-решения,
  • ERP-системы.

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

Интересные факты

Что еще интересного мы нашли в собранной статистике?

Что тестируют?

Тип приложения Популярность, %
Веб-приложения 19,9
Мобильные приложения 10,3
Веб-сервисы 5,9
Игры 1,5
Настольные приложения 0,7

Сергей Рогачев, SkillsWiki:

Ольга Киселева, тренер начинающих тестировщиков, имеет 9 лет опыта ручного и 3 года автоматизированного тестирования:

Рина Ужевко, EPAM Systems:

Таисия Рыбак, Hewlett-Packard:

На каких базах данных?

База данных Популярность, %
Oracle 11,0
MySQL 3,7
Postgresql 2,2
Microsoft SQL Server 1,5
MongoDB 1,1
SQLite 0,4
Couchbase Server 0,4

Сергей Рогачев, SkillsWiki:

Рина Ужевко, EPAM Systems:


Ольга Киселева, тренер начинающих тестировщиков, имеет 9 лет опыта ручного и 3 года автоматизированного тестирования:

Как тестируют?

Вид тестирования Популярность, %
Автоматизированное тестирование 40,1
Ручное тестирование 32,7
Нагрузочное тестирование 14,3
Приемо-сдаточные испытания 3,3
Функциональное тестирование 2,2
Регрессионное тестирование 1,5
Интеграционное тестирование 1,1
Smoke-тестирование 0,4

Сергей Рогачев, SkillsWiki:

Ольга Киселева, тренер начинающих тестировщиков, имеет 9 лет опыта ручного и 3 года автоматизированного тестирования:

Рина Ужевко, EPAM Systems:

На чем автоматизируют тестирование?

Средство автоматизации тестирования

Популярность, %
Selenium 10,7
SoapUI 1,8
Codeception 0,7
HP QuickTest Professional 0,7
PyTest 0,7
Robotium 0,7
Selenium WebDriver 0,7
JBehave 0,4

Сергей Рогачев, SkillsWiki:

Таисия Рыбак, Hewlett-Packard:

Ольга Киселева, тренер начинающих тестировщиков, имеет 9 лет опыта ручного и 3 года автоматизированного тестирования:

Рина Ужевко, EPAM Systems:

Какими языками программирования владеют?

Язык программирования Популярность, %
Java 14,3
JavaScript 10,7
Python 8,5
PHP 7
C++ 4,8
C# 4
Perl 2,2
Ruby 1,1
Scala 1,1
VBScript 1,1
Objective-C 0,7
Swift 0,7
Xcode 0,7

Сергей Рогачев, SkillsWiki:

Таисия Рыбак, Hewlett-Packard:

Рина Ужевко, EPAM Systems:

Ольга Киселева, тренер начинающих тестировщиков, имеет 9 лет опыта ручного и 3 года автоматизированного тестирования:

В каких средствах командной разработки работают?

Средство командной разработки Популярность, %
JIRA 13,2
Redmine 4,0
TFS 4,0
HP Quality Center 1,8
HP ALM 1,1
Bugzilla 0,7
TrackStudio 0,7
Trello 0,4

Сергей Рогачев, SkillsWiki:

Таисия Рыбак, Hewlett-Packard:

Ольга Киселева, тренер начинающих тестировщиков, имеет 9 лет опыта ручного и 3 года автоматизированного тестирования:

Рина Ужевко, EPAM Systems:

Какое образование имеют?

Сергей Рогачев, SkillsWiki:

Рина Ужевко, EPAM Systems:

Ольга Киселева, тренер начинающих тестировщиков, имеет 9 лет опыта ручного и 3 года автоматизированного тестирования:

Проверки кодов статуса

Цель этих проверок – просто убедиться в функционировании конечной точки.

К примеру, ваша спецификация гласит, что у вас будут такие коды:

200 – успешно

400 – неверные данные

404 – недоступный ресурс, и т. д.


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

Цель:

Это проверки-ловушки, они убедятся, что ничего не сломалось, когда в продукт вносятся изменения, и сразу же просигнализируют, что что-то ведет себя не как всегда. Они должны быть простыми, быстрыми и однозначными. Двусмысленность тут недопустимо.

Несколько советов:

  • Они дают очень ограниченную информацию, обращайтесь с ними, как с переключателями вкл/выкл.
  • Ситуации с ошибкой 400 могут сильно варьировать, поэтому убедитесь, что вы покрыли наиболее значимые из них. Некоторые из них имеет смысл тестировать в контексте сценариев.

Что нужно знать тестировщику-автоматизатору

Автоматизированное тестирование требует более глубоких технических знаний, чем ручное. В первую очередь, необходимо уметь программировать. Для автоматизации подойдут как скриптовые языки (Python, Bash), так и языки общего назначения (Java, С#). Сейчас наиболее популярны Java и Python.

Скриптовые языки легче изучать, благодаря достаточно простому синтаксису.  Однако, чтобы стать senior-специалистом (Senior Test Automation Engineer) понадобится понимание принципов объектно-ориентированного программирования (ООП) – тестировщики часто используют тот же язык программирования, на котором разрабатывается тестируемое приложение. К тому же, зная один из ООП языков, например, Java, можно быстро разобраться в синтаксисе другого. В изучении языка программирования делайте упор не на алгоритмы, а на фреймворки и библиотеки, которые помогут при разработке автотестов.

Автоматизированное тестирование лучше осваивать постепенно, начиная с простых инструментов, которые практически не требуют знания программирования. Например, для старта подойдут программы-рекордеры, которые отслеживают и записывают действия пользователя, а затем позволяют воспроизвести их автоматически. Один из таких бесплатных инструментов – Katalon Recorder. Он устанавливается как расширение к браузеру Firefox или Chrome. Katalon Recorder автоматически переводит взаимодействие пользователя с сайтом в сценарии тестов, которые затем можно отредактировать вручную. Katalon Recorder также переводит записанные тесты на язык программирования. Однако сгенерированный код может содержать ошибки, поэтому по мере изучения программирования старайтесь дорабатывать эти скрипты. Со временем писать тесты самостоятельно станет проще, чем использовать рекордер. На этом этапе можно начать изучение других инструментов для автоматизации тестирования.

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

Один из самых популярных фреймворков для тестирования веб-приложений – Selenium Webdriver. Он упоминается практически в каждой вакансии. С помощью Selenium Webdriver можно автоматизировать любые действия пользователя, выполняемые через браузер. Он поддерживается операционными системами Windows, Mac, Linux и многими браузерами, например, Chrome и Firefox.

Для тестирования мобильных приложений часто применяется Appium. Это кроссплатформенный инструмент, который подходит для тестирования и нативных, и гибридных приложений. Он поддерживает различные языки программирования: Java, JavaScript, Python, Ruby, C#. С помощью Appium можно запускать параллельное тестирование на нескольких девайсах, при этом один скрипт можно использовать и для Android, и для iOS. Также для тестирования Android-приложений и мобильных версий веб-приложений можно выбрать Selendroid. 

Где можно пройти обучение

И язык программирования, и фреймворки вы можете изучить самостоятельно. Например, на платформе Udemy есть недорогие онлайн-курсы. Обучение будет более результативным, если вы сможете практиковаться на своем рабочем проекте. Если нет возможности тренироваться на работе, то можете закончить курсы по автоматизированному тестированию в каком-либо образовательном центре, где на обучение, в среднем, отводится 2-4 месяца.

В Минске практически все курсы предлагают изучение автоматизированного тестирования на языке Java, а также знакомство с фреймворком Selenium Webdriver. Некоторые центры принимают учеников, которые уже знают Java, хотя бы на базовом уровне. Например, такие курсы есть  в QA Академии, в образовательном центре ПВТ, а также в Stormnet. Без опыта в программировании на Java можно записаться на курс в «Компьютерную Академию Шаг» (кроме Минска, учебные центры расположены во всех областных центрах и Бобруйске). Если вас заинтересует обучение автоматизации на Python, то такой курс для новичков в программировании есть в образовательном центре ПВТ (филиалы есть в Гродно и Гомеле).

Итого

В BDD сначала пишут спецификацию, а потом реализацию. В конце у нас есть и то, и другое.

Спецификацию можно использовать тремя способами:

  1. Как Тесты – они гарантируют, что функция работает правильно.
  2. Как Документацию – заголовки блоков и описывают поведение функции.
  3. Как Примеры – тесты, по сути, являются готовыми примерами использования функции.

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

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

Не имея тестов, людям приходится выбирать один из двух путей:

Внести изменения, и неважно, что будет. Потом у наших пользователей станут проявляться ошибки, ведь мы наверняка что-то забудем проверить вручную. Или же, если наказание за ошибки в коде серьёзное, то люди просто побоятся вносить изменения в такие функции

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

Автоматическое тестирование кода позволяет избежать этих проблем!

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

Кроме того, код, хорошо покрытый тестами, как правило, имеет лучшую архитектуру.

Это естественно, ведь такой код легче менять и улучшать. Но не только по этой причине.

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

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

Далее по книге мы встретим много задач с тестами, так что вы увидите много практических примеров.

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


С этим читают