Erhalten Sie Zugang zu diesem und mehr als 300000 Büchern ab EUR 5,99 monatlich.
- Herausgeber: Питер
- Kategorie: Wissenschaft und neue Technologien
- Sprache: Russisch
Веб-интерфейсы — лицо приложения, и они должны быть совершенными. Внедрение программы автоматизированного тестирования — лучший способ убедиться, что ваши API готовы к работе. «Тестирование веб-API» — это уникальное практическое руководство, включающее в себя описание всех этапов: от начального проектирования набора тестов до методов документирования, реализации и предоставления высококачественных API. Вы познакомитесь с обширным набором методов тестирования — от исследовательского до тестирования продакшен-кода, а также узнаете, как сэкономить время за счет автоматизации с использованием стандартных инструментов. Книга поможет избежать многих трудностей при тестировании API.
Sie lesen das E-Book in den Legimi-Apps auf:
Seitenzahl: 310
Veröffentlichungsjahr: 2024
Das E-Book (TTS) können Sie hören im Abo „Legimi Premium” in Legimi-Apps auf:
Ähnliche
Переводчик Г. Гаврилов Антон Геннадьевич
Марк Винтерингем
Тестирование веб-API. — СПб.: Питер, 2024.
ISBN 978-5-4461-2092-5
© ООО Издательство "Питер", 2024
Оглавление
Для Стеф: Я обещаю, что закончу ремонт на кухне.
Вступительное слово
«Тестирование веб-API» содержит значительно больше информации, чем можно ожидать от книги с таким названием. Тестирование API представлено как часть единой стратегии тестирования, учитывающей риски. Марк знакомит вас с полезными визуальными моделями, задает вопросы, чтобы заставить думать, и ведет до последних страниц в качестве участника, а не пассажира.
Прежде чем углубиться в детали, в книге предлагается глава о том, зачем мы вообще тестируем, а также как идентифицировать различные типы рисков. Марк делает еще шаг вперед в исследовании этой важной темы — сопоставляет риски с качественными характеристиками и связывает их со стратегией тестирования.
Автор указывает предварительные условия для получения максимальной отдачи от книги. Практикующие читатели, знакомые с написанием кода, HTTP, инструментами разработки и тестирования, изучат новые инструменты и методы, чтобы понять все аспекты поведения их API. Тем не менее книга полезна и людям, которые не имеют всех этих навыков, поскольку чтение даст им общее понимание проблем и вдохновит на выполнение учебных упражнений.
Многие примеры в книге, а также упражнения основаны на реальном проекте с использованием работающего приложения. Вы будете изучать продукт, его область работы, историю и ошибки — все как в реальной жизни. Пользовательский интерфейс продукта поможет ознакомиться с его функциями.
Нам нравится, что эта книга помогает людям применять целостный подход к тестированию API. Проведите беседы о качестве, чтобы договориться о его желаемом уровне, и разработайте стратегию для его достижения, сотрудничая с заинтересованными сторонами. Автор пишет об этом в главе 4:
Хорошая стратегия тестирования характеризуется целостностью. Она должна фокусироваться на разных аспектах — везде, где велики риски снижения качества продукта.
Также нас привлекает то, что Марк одинаково ценит исследовательское тестирование и автоматизацию как элементы стратегии тестирования API. Он очень прагматичен в обоих случаях, перечисляя плюсы и минусы и иллюстрируя их конкретными примерами. При этом он признает, что каждая команда имеет свой собственный контекст. Еще одно качество книги, которое нам нравится, заключается в том, что читателю постоянно напоминают о необходимости использовать физические или виртуальные средства визуализации всего, что обсуждается.
Книга проведет вас от модели стратегии к ее планированию и реализации в соответствии с вашим контекстом. Последние пять глав посвящены расширенной автоматизации тестирования API. В них вы глубоко изучите тестирование контрактов, производительности, безопасности, а также тестирование в рабочей среде. Вы можете самостоятельно выбрать очередность изучения этих тем.
Одна из наших любимых моделей, широко используемая в книге, основана на идее Джеймса Линдсея (James Lyndsay). Это диаграмма Венна, демонстрирующая различие наших представлений о продукте и его реализации. Она помогает нам задавать такие вопросы, как «Кто будет использовать этот ответ API?» или «Что, если я нажму эту кнопку тысячу раз?». Это один из многих способов, помогающих нам мыслить нестандартно.
Использование API продолжает расти по мере того, как все больше приложений переходят на микросервисы и облачные решения. Методы и модели, описанные в этой книге, позволяют создавать высококачественные и надежные API. Эти же модели и методы могут быть адаптированы для многих других видов тестирования. Прочтите эту книгу, и вы разовьете свои навыки тестирования.
— Джанет Грегори (Janet Gregory), консультант, автор, спикер в Dragonfire Inc.; соучредитель сообщества The Agile Testing Fellowship
— Лиза Криспин (Lisa Crispin), консультант по тестированию, автор и соучредитель сообщества The Agile Testing Fellowship
Предисловие
Я всегда чувствовал, что когда впервые начал тестировать API, то уже опоздал. Программное обеспечение как услуга (software as a service) получило широкое распространение, и микросервисы набирали популярность. Я видел, как разработчики в моей команде успешно тестировали API в контексте автоматизации, но только когда мне посчастливилось поработать с одним из них, мой путь к тестированию API начался по-настоящему. Спасибо, Упеш!
Однако по мере того как я развивал свои навыки и начал делиться знаниями с помощью видеокурсов и очного обучения, стало очевидно, что многие еще не начали свой путь или уже начали, но хотят узнать больше. Это стало мотивацией для написания книги: я хотел дать читателям широкое представление о множестве способов, которыми мы можем тестировать веб-API, и рассказать, как они работают.
Когда я впервые стал обучать других тестированию API, то сосредоточился на помощи в понимании и использовании возможностей HTTP, чтобы работать быстрее и качественнее. Но по мере подготовки материала книги я осознал, что нужно охватить значительно более широкий круг вопросов. Вот почему в этой книге мы рассмотрим методы тестирования, которыми можем воспользоваться на всех стадиях разработки веб-API, от постановки задач и написания первой строки кода до создания сложной автоматизации, которая дает ценную обратную связь.
Я надеюсь, что, изучив материал книги, вы получите в свое распоряжение инструменты, которые помогут стать лучше в тестировании API, независимо от вашего опыта и роли в команде.
Благодарности
Прежде всего я хотел бы поблагодарить тех, кто активно помогал мне в создании этой книги: моих редакторов — Кристину Тейлор (Christina Taylor), которая была терпелива, когда я взял перерыв, чтобы снова стать отцом, и Сару Миллер (Sarah Miller), которая помогла мне закончить эту книгу, а также всему производственному персоналу издательства Manning. Я также хотел бы поблагодарить Эбби Бэнгсер (Abby Bangser) и Билла Мэтьюза (Bill Matthews), которые нашли время поговорить о тестировании в производстве и тестировании безопасности соответственно. Также спасибо моему коллеге по автоматизации в тестировании Ричарду Брэдшоу (Richard Bradshaw), с которым мы много дискутировали о тестируемости и стратегии, что помогло обогатить главу с описанием стратегий тестирования. И мы еще долго будем обсуждать отношение к автоматизации тестирования. Наконец, спасибо всем, от кого я получил обратную связь: Alberto Almagro, Allen Gooch, Amit Sharad Basnak, Andres Sacco, Andy Kirsch, Andy Wiesendanger, Anne-Laure Gaillard, Anupam Patil, Barnaby Norman, Christopher Kardell, Daniel Cortés, Daniel Hunt, Ernesto Bossi, Ethien Daniel Salinas Domínguez, Hawley Waldman, Henrik Jepsen, Hugo Figueiredo, James Liu, Jaswanth Manigundan, Jeffrey M. Smith, Jonathan Lane, Jonathan Terry, Jorge Ezequiel Bo, Ken Schwartz, Kevin Orr, Mariyah Haris, Mark Collin, Marleny Nunez Alba, Mikael Dautrey, Dr. Michael Piscatello, Brian Cole, Narayanan Jayaratchagan, NaveenKumar Namachivayam, George Onofrei, Peter Sellars, Prashanth Palakollu, Rajinder Yadav, Raúl Nicolás, Rohinton Kazak, Roman Zhuzha, Ronald Borman, Samer Falik, Santosh Shanbhag, Shashank Polasa Venkata, Suman Bala, Thomas Forys, Tiziano Bezzi, Vicker Leung, Vladimir Pasman, Werner Nindl, William Ryan, Yvon Vieville, and Zoheb Ainapore. Это было трудное, но важное чтение.
(Альберто Альмагро, Аллен Гуч, Амит Шарад Баснак, Андрес Сакко, Энди Кирщ, Энди Вьесенданжер, Энн-Лаура Гаиллард, Анупам Патил, Барнаби Норман, Кристофер Карделл, Дэниел Кортéс, Дэниел Хант, Эрнесто Босси, Этьен Дэниел Салинас Домингез, Холи Волдман, Хенрик Йепсен, Хуго Фигуйредо, Джеймс Лью, Джасвант Манигундан, Джеффри М. Смит, Джонатан Лейн, Джонатан Терри, Йорге Езекуэл Бо, Кен Щварц, Кевин Орр, Мария Харис, Марк Коллин, Марлени Нунез Альба, Микаел Дотри, Майкл Пискателло, Брайан Коль, Нараянан Джаярачаган, НавинКумар Намачиваям, Джордж Онофрей, Питер Селларс, Прашантх Палаколлу, Райиндер Ядав, Рауль Николáс, Рохинтон Казак, Роман Жужа, Рональд Борман, Самер Фалик, Сантош Шанбхаг, Шашанк Поласа Венката, Суман Бала, Томас Форис, Тициано Бецци, Викер Леунг, Владимир Пасман, Вернер Ниндл, Вильям Рян, Ивон Вьевилль и Зохеб Айнапор)
Я также в долгу перед Лизой Криспин (Lisa Crispin) и Джанет Грегори (Janet Gregory) за их добрые слова и время, потраченное на написание предисловия к этой книге. Спасибо Джеймсу Линдсею (James Lyndsay), Робу Мини (Rob Meaney) и Эшу Винтеру (Ash Winter), чья работа помогла мне лучше понять ключевые аспекты тестирования и позволила поделиться этими знаниями в книге.
Есть люди, которые, сами того не понимая, помогли мне с этой книгой. Например, Упеш Амин (Upesh Amin) много лет назад любезно нашел время, чтобы однажды после обеда научить меня работать с HTTP, а Алан Ричардсон (Alan Richardson) навел на мысль о работе над книгой во время курса Marketing 101!
Эта книга является кульминацией моего опыта работы в сообществе тестировщиков, поэтому спасибо всем в Ministry of Testing1 и многочисленным друзьям, которых я приобрел за эти годы на различных мероприятиях, устраиваемых сообществом тестировщиков. Благодарю всех, кто саркастически спрашивал: «О, ты пишешь книгу?» — я ценю бесплатную рекламу и мотивацию.
Но больше всего я хочу поблагодарить Стеф (Steph), которая всегда поддерживала меня во всех сумасшедших проектах, которыми я занимался, и терпеливо и вежливо поздравляла меня каждый вечер, когда я взволнованно говорил ей, что написал «еще три страницы!». И это продолжалось в течение целого года.
1 Ministry of Testing — Министерство тестирования, также называемое MoT, представляет собой глобальное сообщество по тестированию программного обеспечения. — Примеч. пер.
О книге
Замысел этой книги преследует две цели. Первая цель — познакомить читателей с широким спектром различных техник в области тестирования, которые применимы к веб-API. По мере изучения материала вы узнаете, как выполнять различные виды тестирования, как оценить типы рисков и получаемую информацию. Вторая цель — помочь вам создать и внедрить стратегию тестирования, которая успешно сочетает в себе различные техники и эффективна в вашем конкретном случае.
Для кого эта книга
При написании книги я попытался организовать материал так, чтобы помочь вам построить стратегию тестирования шаг за шагом. Однако в духе принципа применения разных стратегий для различных условий предлагается несколько способов, которыми вы можете воспользоваться, чтобы добиться успеха в тестировании.
Независимо от вашей мотивации, я настоятельно рекомендую прочитать часть 1 полностью. Глава 2 поможет освоиться в песочнице, которая используется в практических примерах. Она понадобится, если вы захотите опробовать различные методы, описанные в книге. Глава 3 обязательна к прочтению, потому что в ней подробно рассматриваются качество и риски, а также то, как они влияют на продукт. Я твердо убежден, что для успешного тестирования необходимо четко понимать, какую проблему вы пытаетесь решить. Если вы не знаете, в чем проблема, как вы можете быть уверены, что выбрали правильный подход, и как сможете оценить результат?
Остальной материал книги вы можете выбирать для чтения, исходя из своих предпочтений. Я надеюсь, что для некоторых книга станет руководством для поэтапного построения стратегии тестирования, а для других — удобным или справочным пособием, информирующим о конкретных методах, ресурсах и навыках.
Новичкам в построении стратегии тестирования API
Книга построена таким образом, чтобы провести вас по всему пути с нуля до создания, реализации и выполнения успешной стратегии тестирования. Поэтому если вы новичок в тестировании API, последовательно изучайте главы, чтобы улучшать свои знания и навыки.
Улучшение существующей стратегии тестирования API
Не все читатели начинают с нуля. Вы можете быть членом команды, стремящейся улучшить существующую стратегию тестирования. В таком случае я рекомендую разобраться в построении предлагаемой стратегии и сравнить ее с вашей, чтобы определить возможные пробелы и недостатки последней. Этот анализ поможет определить действия по улучшению тестирования в вашей команде.
Реализация определенных методов тестирования
Некоторые читатели хотят узнать больше о конкретных техниках, и им не обязательно думать о более широкой картине (например, вам может быть поручено провести определенные тесты). Если ваша мотивация такова, я рекомендую сосредоточиться на интересующих вас темах, примерах и заданиях по тестированию. Другим проще понять, какое место занимает определенная техника в стратегии, попробовав ее, а затем уже расширять свое видение.
Структура книги
Двенадцать глав книги разделены на три части.
Часть 1. Разработка стратегии тестирования
В главе 1 мы спросим себя, зачем нужно тестирование и почему понимание его ценности помогает создать стратегию тестирования. Глава 2 знакомит с проектом песочницы, который мы будем использовать в практических примерах на протяжении всей книги, чтобы показать ряд методов, которые помогут быстро понять, что и для кого мы тестируем. Глава 3 объясняет, как определить цели, которых мы стремимся достичь с помощью стратегии тестирования, и что помогает нам расставить приоритеты при выборе типа тестирования.
Часть 2. Введение тестов в нашу стратегию
В части 2, главах с 4-й по 7-ю, мы начинаем изучать техники тестирования веб-API. Я расположил главы в этой части книги так, чтобы они следовали жизненному циклу разработки программного обеспечения, начиная с идеи и заканчивая реализацией и сопровождением.
Эта часть книги завершается главой о том, как рабочий контекст влияет на нашу стратегию и как мы можем реализовать ее таким образом, чтобы поддержать работу команды. Затем мы используем эти знания, чтобы собрать воедино мероприятия по тестированию, сформировав основу нашей стратегии тестирования.
Часть 3. Расширение стратегии тестирования
В заключительной части книги, главах с 8-й по 12-ю, мы узнаем больше о разных техниках тестирования, а также расширим некоторые методы, о которых уже узнали. Важно отметить, что техники, которые мы рассмотрим в этом разделе, не обязательно являются более сложными или требуют большего мастерства. Однако они, возможно, потребуют больших затрат времени и более зрелой культуры тестирования, чтобы интегрировать их в стратегию.
Предварительные требования
Предполагается, что вы подходите к изучению этой книги, обладая рядом навыков и знаний.
HTTP
Чтобы протестировать веб-API, нам потребуется использовать HTTP. Мы подробно изучим применение этого протокола в различных техниках тестирования, однако эта книга не содержит введения в HTTP. Поэтому предполагается, что вы знакомы с основами HTTP, такими как:
• унифицированные идентификаторы/локаторы ресурсов;
• HTTP-методы;
• HTTP-заголовки;
• коды состояния;
• запросы и ответы.
Java
Для разделов, затрагивающих программирование, я решил использовать язык Java из-за его широкого распространения в мире разработки API. Это означает, что нам придется иметь дело с дополнительными шаблонами, поставляемыми с Java, но примеры, которые мы рассмотрим, будут понятны максимально широкой аудитории. Помимо этого, примеры содержат множество шаблонов проектирования для кода автоматизации, а подходы универсальны для разных языков. Поэтому я призываю вас прочитать примеры с кодом или даже попробовать их выполнить на практике. Однако для выполнения этих упражнений вы должны иметь практические знания в следующих областях:
• библиотеки;
• пакеты;
• классы;
• методы тестирования;
• утверждения.
Прочие инструменты
В этой книге рассматривается ряд инструментов, которые используются для поддержки различных мероприятий по тестированию:
• DevTools — расширение для большинства браузеров, помогающее отлаживать веб-страницы (https://developer.chrome.com/docs/devtools)
• Postman — инструментальная платформа, помогающая создавать и тестировать веб-API (https://www.postman.com)
• Wireshark — инструмент для перехвата HTTP-трафика, позволяющий перехватывать HTTP-трафик между API (https://www.wireshark.org)
• Swagger — инструмент проектирования, позволяющий создавать «живую» документацию, с которой вы можете взаимодействовать, чтобы узнать больше о веб-API (https://swagger.io)
• WireMock — инструмент для имитации веб-API, чтобы повысить управляемость тестирования (https://wiremock.org)
• Pact — инструмент тестирования контрактов, который проверяет интеграцию между веб-API (https://pact.io)
• Apache JMeter — инструмент для тестирования производительности и функциональности веб-API (https://jmeter.apache.org)
Если будет возможность, ознакомьтесь с этими инструментами, прежде чем начать путешествие по страницам книги.
О коде в книге
Эта книга содержит множество примеров исходного кода как в пронумерованных листингах, так и в обычном тексте. В обоих случаях исходный код отформатирован шрифтомфиксированнойширины, чтобы отделить его от обычного текста.
Комментарии в исходном коде часто удалялись из листингов, если код объяснялся в тексте. Аннотации кода выделяют важные концепции.
Вы можете получить фрагменты кода в liveBook-версии этой книги по адресу https://livebook.manning.com/book/testing-web-apis. Полный код примеров из книги доступен для загрузки с веб-сайта издательства Manning по адресу https://www.manning.com/books/testing-web-apis.
Кроме того, код есть в двух вспомогательных репозиториях, которые будут неоднократно упоминаться в тексте.
Restful-booker-platform
Restful-booker-platform — это наша платформа API-песочницы, на которой мы будем практиковаться в тестировании. Кодовую базу платформы можно найти по адресу https://github.com/mwinteringham/restful-booker-platform, а сведения об установке приведены в приложении к книге.
Источники, используемые в книге
Многие главы содержат заметки, примеры кода и сценарии тестирования производительности, которые можно просмотреть в соответствующих проектах в следующем репозитории: https://github.com/mwinteringham/api-strategy-book-resources. Все разделы кода можно запускать локально.
Форум LiveBook
Приобретая книгу «Тестирование веб-API», вы получаете бесплатный доступ к веб-форуму издательства Manning (на английском языке), на котором можно оставлять комментарии о книге, задавать технические вопросы и получать помощь от автора и других пользователей. Чтобы получить доступ к форуму, откройте страницу https://livebook.manning.com/book/testing-web-apis/discussion. Информацию о форумах Manning и правилах поведения на них см. на https://livebook.manning.com/discussion.
В рамках своих обязательств перед читателями издательство Manning предоставляет ресурс для содержательного общения читателей и авторов. Эти обязательства не подразумевают конкретную степень участия автора, которое остается добровольным (и неоплачиваемым). Задавайте автору хорошие вопросы, чтобы он не терял интереса к происходящему! Форум и архивы обсуждений доступны на веб-сайте издательства, пока книга продолжает издаваться.
Об авторе
Марк Винтерингем — тестировщик, системный программист и COO (главный операционный директор) Ministry of Testing с более чем десятилетним опытом экспертизы в области тестирования. Участвовал в технологических проектах в разных областях, которые были отмечены наградами BBC, Barclays, правительства Великобритании и Thomson Reuters. Сторонник современных методов тестирования, основанных на оценке рисков. Обучает команды методам автоматизации тестирования, разработки через тестирование и исследовательского тестирования. Соучредитель Ministry of Testing, сообщества, занимающегося вопросами образования в области тестирования.
Иллюстрация на обложке
Изображение на обложке — «Boucbar de Siberie» (сибирский пастух), оно взято из коллекции Жака Грассе де Сен-Совера, опубликованной в 1788 году. Каждая иллюстрация была тщательно нарисована и раскрашена вручную.
В то время было легко определить по одежде, где живут люди и какова их профессия или положение в обществе. Издательство Manning отдает дань изобретательности и инициативам в области компьютерных технологий, создавая обложки, которые напоминают о культурном разнообразии многовековой давности и возвращают к жизни рисунки из старых изданий.
От издательства
Ваши замечания, предложения, вопросы отправляйте по адресу [email protected] (издательство «Питер», компьютерная редакция).
Мы будем рады узнать ваше мнение!
На веб-сайте издательства www.piter.com вы найдете подробную информацию о наших книгах.
Часть 1. Значение тестирования веб-API
В чем смысл тестирования? Вопрос может показаться саркастическим, но понимание целей и пользы поможет нам определить подходы к тестированию. Если мы решим, что тестирование — это просто нажатие кнопок и поломка разных вещей, то получим соответствующий результат. В действительности тестирование — это совокупность навыков, знаний и действий, которые помогают команде повысить качество своей работы. Вот почему, прежде чем мы перейдем к рассмотрению конкретных примеров, нам нужно понять важность правильного тестирования и то, как применять его для определенных задач в нужное время.
В части 1 мы рассмотрим, что и как тестировать, чтобы приносить реальную пользу как коллегам, так и клиентам. В главе 1 обсудим проблемы, связанные с качеством веб-API, и способы решать эти проблемы с помощью тестирования. В главе 2 наметим маршрут нашего путешествия по миру тестирования API. Наконец, в главе 3 будут подробно обсуждаться две ключевые концепции, которыми мы руководствуемся при тестировании: качество и риски.
1. Для чего и как мы тестируем веб-API
В этой главе
• Проблемы создания сложных API-платформ
• Значение и цель тестирования
• Как выглядит стратегия тестирования API и чем она может быть полезна.
Как мы можем гарантировать качество и ценность для конечных пользователей того, что создаем? Проблема, с которой мы сталкиваемся при выпуске высококачественного продукта, заключается в огромном количестве сложных действий и операций при его создании. Если мы хотим добиться высокого качества, необходимо преодолеть все сложности, а также разобраться, как работают наши системы и что пользователям требуется от них. Вот почему нам нужна стратегия тестирования, которая поможет лучше понять, что мы на самом деле создаем. Итак, прежде чем мы начнем наше путешествие по миру тестирования API, давайте сначала подумаем, почему программное обеспечение такое сложное и в чем польза тестирования.
1.1. Что происходит в ваших веб-API
В 2013 году правительство Великобритании разработало стратегию по переводу налоговой и таможенной службы (HMRC) на цифровой стандарт обслуживания. Цель стратегии состояла в том, чтобы перевести работу этих служб в онлайн-режим, улучшить качество услуг и сократить расходы.
К 2017 году налоговая платформа HMRC насчитывала более 100 цифровых услуг, созданных 60 группами в пяти различных центрах. Каждая из этих цифровых услуг поддерживается платформой взаимосвязанных веб-API, число которых постоянно растет. Количество API, созданных для поддержки этих сервисов, просто поражает. Когда я присоединился к проекту в 2015 году, услуг, команд и центров было примерно вдвое меньше, чем сейчас, но уже тогда платформа объединяла более 100 веб-API. С тех пор это число, несомненно, увеличилось. Возникает вопрос: как проект такого масштаба и сложности может предоставлять конечным пользователям высококачественные услуги?
Я привел этот пример, потому что он помогает выделить два уровня сложности при создании веб-API:
• Собственная сложность конкретного веб-API.
• Сложность, обусловленная взаимодействием нескольких веб-API, работающих на одной платформе.
Разобравшись с обеими, мы начнем понимать, зачем нужно тестирование и чем оно может нам помочь.
1.1.1. Собственная сложность веб-API
Может показаться немного банальным начать с вопроса: что такое веб-API? Но если мы потратим время на разбор структуры веб-API, то сможем узнать не только о том, что такое веб-API, но и в чем заключается его сложность. Рассмотрим, к примеру, представленную на рис. 1.1 визуализацию веб-API сервиса бронирования, который мы будем тестировать позже в этой книге.
На рисунке мы видим, что веб-API получает от клиентов данные о резервировании в форме HTTP-запросов, которые обрабатываются в API на разных уровнях. После завершения выполнения и сохранения резервирования веб-API отвечает через HTTP. Более детальное рассмотрение позволит понять, сколько всего происходит в рамках одного веб-API.
Рис. 1.1. Модель веб-API, изображающая его компоненты и то, как он работает
Прежде всего, на уровне представления HTTP-запрос на бронирование переводится в контент, который может быть прочитан другими уровнями. Сервисный уровень применяет к информации о бронировании бизнес-логику, например проверяет, действительно ли это бронирование и не конфликтует ли оно с другими бронированиями. Наконец, если обработанное бронирование необходимо сохранить, оно подготавливается на уровне хранения, а затем сохраняется в базе данных. Если все выполнено успешно, каждый уровень должен сообщить об этом, чтобы создать ответ, который веб-API отправит создателю запроса.
Каждый из рассмотренных слоев может быть построен по-разному, в зависимости от наших требований и вкусов. Например, можно разрабатывать веб-API с использованием архитектур REST, GraphQL или SOAP, каждая из которых имеет свои собственные шаблоны и правила.
Работа с REST
В этой книге мы будем работать преимущественно с веб-API, созданными с использованием архитектуры REST. Существует множество различных архитектурных стилей, но сегодня наиболее широко используется REST. Однако стоит отметить, что хотя GraphQL и SOAP имеют свои отличия, подходы к тестированию, которые мы рассмотрим, в равной степени применимы к этим типам архитектуры. На протяжении всей книги мы будем кратко отмечать, каким образом изучаемое может быть применено к любому архитектурному стилю.
Сервисный уровень содержит бизнес-логику, которая, в зависимости от контекста, может иметь множество настраиваемых правил. Аналогичный принцип применяется к уровням хранения. Каждый из этих уровней опирается на зависимости, которые имеют свои собственные циклы разработки. Нам необходимо знать огромное количество информации, чтобы обеспечить высокое качество работы API.
Понимание того, что происходит в наших веб-API и как они помогают другим, требует времени и опыта. Да, можно достичь некоторого понимания, тестируя части по отдельности (к чему я всегда призываю команды; ознакомьтесь с выступлением Дж. Б. Райнсбергера (J. B. Rainsberger) «Integrated Tests Are a Scam», чтобы узнать больше: https://youtu.be/VDfX44fZoMc). Но это дает нам информацию только о части головоломки, а не обо всей задаче целиком.
1.1.2. Сложность взаимодействия многих веб-API
В случае с платформой HMRC с ее более чем 100 веб-API требуется понимание не только работы каждого из них, но и их взаимодействия друг с другом. Такие подходы, как микросервисная архитектура, помогают уменьшить сложность отдельных веб-API, делая их меньше и более конкретными. С другой стороны, при этом количество веб-API на платформе еще больше увеличивается. Как в этих условиях обеспечить актуальность наших знаний о платформе? И как следить за взаимодействиями каждого API с другими и контролировать, чтобы их соединения работали в пределах ожидаемого?
Чтобы создать высококачественный продукт, мы должны делать осознанный выбор. Это означает, что наши знания о работе веб-API, а также об их взаимодействиях как друг с другом, так и с конечными пользователями жизненно важны. Иначе мы рискуем столкнуться с проблемами из-за неверной интерпретации того, как работают наши системы. Именно с этой точки зрения тестирование важно для упорядочивания и сохранения понимания работы продуктов.
1.2. Как тестирование помогает нам
Если мы как команда собираемся добиться успеха в тестировании, нам необходимо общее понимание его цели и значения. К сожалению, существует множество неправильных представлений о том, что такое тестирование. Чтобы помочь нам всем прийти к единому мнению, позвольте представить модель тестирования (рис. 1.2).
Рис. 1.2. Модель, которая помогает описать значение и цель тестирования
Эта модель, основанная на образе, созданном Джеймсом Линдсеем в его статье «Why Exploration has a Place in any Strategy» (http://mng.bz/o2vd), состоит из двух кругов. Левый круг соответствует нашим представлениям о продукте (воображению), а правый круг — реализации, то есть тому, что мы имеем в реальности. Цель тестирования — узнать как можно больше об этих кругах путем проведения тестов. Чем больше мы тестируем, тем больше продвигаемся в решении следующих задач:
• обнаруживаем потенциальные проблемы, которые могут повлиять на качество;
• разбираемся в том, что создаем, и приобретаем уверенность, что это именно тот продукт или услуга, которые мы хотим создать.
Чтобы лучше разобраться в этом, давайте рассмотрим пример, где команда предоставляет гипотетическую функцию поиска, качество которой мы должны обеспечить.
1.2.1. Представление
Круг представления отражает то, что мы хотим от нашего продукта, включая явные и неявные ожидания. В этом круге наше тестирование сосредоточено на том, чтобы узнать как можно больше об этих ожиданиях. Мы узнаем не только то, что было явно заявлено в письменной или устной форме, но также углубляемся в детали и устраняем двусмысленности в терминах и идеях.
В качестве примера допустим, что представитель бизнеса или пользователей (владелец продукта) сформулировал для своей команды требование: «Результаты поиска должны быть упорядочены по релевантности». Представленная явно информация говорит о том, что требуются результаты поиска, упорядоченные по релевантности. Однако мы можем раскрыть много неявной информации, проверяя идеи и концепции, лежащие в основе того, о чем нас просят. Чтобы разобраться в проблеме, можно задать следующие вопросы:
• Что подразумевается под релевантными результатами?
• Для кого результаты должны быть релевантны?
• Какая информация предоставляется?
• Как ее упорядочить по релевантности?
• Какие данные мы должны использовать?
Ответы на них дают более полное представление о том, чего от нас хотят, устраняют недопонимания в нашей команде и выявляют потенциальные риски, которые могут повлиять на результаты. Зная больше о том, что нас просят создать, мы с большей вероятностью построим то, что нужно, с первого раза.
1.2.2. Реализация
Проверяя представления, мы получаем более четкое понимание того, что нас просят построить. Но это не означает, что в итоге мы получим продукт, который соответствует ожиданиям. Именно поэтому мы также тестируем реализацию, чтобы узнать следующее:
• Соответствует ли продукт ожиданиям?
• В чем продукт может не оправдать ожиданий?
Обе цели одинаково важны. Мы хотим быть уверены, что создали правильный продукт, но побочные эффекты, такие как странности поведения и уязвимости, будут существовать всегда. На примере задачи о представлении результатов поиска мы могли бы не только проверить, что функция выдает их в требуемом порядке, но и спросить:
• Что, если я введу разные условия поиска?
• Что, если релевантные результаты различны для разных поисковых инструментов?
• Что делать, если во время поиска часть сервиса не работает?
• Что, если я запрошу результаты 1000 раз менее чем за 5 секунд?
• Что произойдет, если результатов не будет?
Выходя за рамки ожиданий, мы лучше понимаем происходящее в нашем продукте и его недостатки. Это гарантирует, что в итоге мы будем верно оценивать поведение нашего приложения и не выпустим некачественный продукт. Кроме того, если мы обнаружим неожиданное поведение, то сможем попытаться устранить ошибки или скорректируем наши ожидания.
1.2.3. Значение тестирования
Модель тестирования представлений и реализации демонстрирует, что тестирование выходит за рамки простого подтверждения ожиданий и бросает вызов нашим предположениям. Чем больше мы узнаем в процессе тестирования о том, что мы хотим построить и что мы создали, тем больше эти два круга совпадают друг с другом. А чем больше они совпадают, тем точнее становится наша оценка качества.
Удивительно, но вы уже тестируете!
Поскольку цель тестирования — понять функции продуктов и разобраться, как они должны работать, стоит отметить, что вы, вероятно, уже проводите тестирование в той или иной форме. Можно утверждать, что в любой деятельности, будь то отладка кода, загрузка API или отправка клиенту вопросов о том, как должен работать ваш API, вы чему-то учитесь. Следовательно, вы тестируете.
Именно поэтому иногда считается, что тестирование — это легкая задача. Но существует различие между ситуативным, неформальным и целенаправленным тестированиями. Мы знаем, насколько сложными могут быть продукты, и только при стратегическом подходе к тестированию это различие становится очевидным.
Команды, которые хорошо информированы о собственной работе, имеют лучшее представление о качестве своего продукта. Они также лучше осведомлены о том, какие шаги предпринять для улучшения качества (что позволяет сосредоточить внимание на конкретных рисках), как внести изменения в продукт, чтобы он лучше соответствовал ожиданиям пользователей, и какие проблемы исправить, а какие оставить без внимания. В этом и заключается цель хорошего тестирования: оно помогает командам занять позицию, в которой они могут принимать обоснованные решения и уверенно идти по пути разработки высококачественного продукта.
1.2.4. Стратегический подход к тестированию API
Я считаю, что представленная выше модель — отличный способ описать цель и значение тестирования. Однако она может показаться несколько абстрактной. Как применить ее к тестированию API? Как будет выглядеть стратегия тестирования API при таком подходе? Одна из целей этой книги — помочь вам лучше понять эту модель. Давайте рассмотрим пример стратегии тестирования API, разработанной для проекта HMRC, участником которого я был.
Проект представлял собой сервис, позволявший пользователям искать и читать нормативные документы, а также создавать отчеты. Архитектура системы упрощенно представлена на рис. 1.3.
Рис. 1.3. Неформальная визуализация системной архитектуры платформы веб-API
Эта упрощенная модель дает представление о приложениях, для которых нам приходится разрабатывать стратегии тестирования API. Мы обсудим эту модель в главе 2, а здесь отметим, что приложение состоит из серии веб-API, которые предоставляют услуги пользовательскому интерфейсу и друг другу. Например, Search API может быть запрошен пользовательским интерфейсом и другим API, таким как Report API. Итак, у нас есть пример приложения, но как применить к этому контексту модель тестирования, о которой мы узнали? Опять же, лучше всего это объяснить на визуальной модели, показанной на рис. 1.4.
Рис. 1.4. Экземпляр модели описывает определенные действия по тестированию в рамках общей стратегии тестирования API
Как видим, части кругов представления и реализации заполнены операциями тестирования, которые помогут узнать, как работают наши веб-API. Для представления применимы следующие виды тестирования:
• Тестирование дизайна API позволяет нам подвергать сомнению идеи и улучшать общее понимание проблем, которые мы пытаемся решить.
• Тестирование контрактов помогает убедиться, что веб-API взаимодействуют друг с другом и корректно обновляются при внесении изменений.
Для реализации применимы такие виды тестирования:
• Исследовательское тестирование позволяет понять, как ведут себя веб-API, и обнаружить потенциальные проблемы.
• Тестирование производительности помогает лучше понять поведение веб-API под нагрузкой.
И наконец, у нас есть возможность автоматизированных проверок API, которые охватывают области пересечения наших представлений и реализации. Эти проверки могут подтвердить, что наши знания о работе API по-прежнему верны, и привлечь внимание к любому потенциальному ухудшению качества.
В этой книге мы узнаем больше об этих и других видах тестирования. Приведенная модель демонстрирует, что различные техники тестирования сосредоточены на разных областях нашей работы и предоставляют разную информацию. Успешная стратегия тестирования API должна быть целостной по своему подходу, сочетая множество различных техник, которые работают вместе, дополняя друг друга. Чтобы создать такую стратегию, требуется следующее:
1. Проанализируйте контекст и его риски: кто наши пользователи? Чего они хотят? Как работает наш продукт? Как мы работаем? Как они понимают качество?
2. Оцените доступные типы тестирования: знаем ли мы, как эффективно использовать автоматизацию? Знаем ли мы, что можем тестировать идеи и дизайны API до начала написания кода? Как мы можем получить пользу от тестирования в продакшене?
3. Используйте знание контекста, чтобы выбрать правильные действия по тестированию: какие риски наиболее важны для нас и как их снизить с помощью тестирования?
В этой книге мы рассмотрим все три пункта, чтобы дать необходимые навыки и знания для определения и реализации стратегии тестирования, которая будет помогать вам, вашей команде и вашей организации. По мере чтения книги мы будем возвращаться к общей модели тестирования, чтобы понять, какие техники тестирования работают лучше всего и где, а затем интегрировать их в эффективную стратегию тестирования. Прежде чем углубиться в многочисленные аспекты тестирования API, давайте познакомимся с несколькими подходами, которые помогут быстро изучить платформы веб-API.
Итоги
• Веб-API содержат несколько уровней. Каждый из них выполняет собственные сложные задачи, которые становятся еще более сложными при их комбинировании.
• Сложность возрастает еще больше, когда несколько веб-API работают вместе в рамках сервисов для конечного пользователя на платформе.
• Понимание этой сложности является ключом к созданию высококачественного продукта.
• Чтобы достичь такого понимания, требуется целенаправленная стратегия тестирования.
• Тестирование можно рассматривать как сосредоточение внимания на двух областях: представлений и реализации.
• Мы проверяем представления, чтобы узнать больше о том, что хотим построить. Мы проверяем реализацию, чтобы узнать больше о том, что уже создали.
• Чем больше мы знаем о представлении и реализации, тем больше они пересекаются и тем лучше мы информированы о качестве нашего продукта.
• Модель тестирования показывает, как тестирование работает в областях представлений и реализации.
• Успешная стратегия тестирования состоит из множества действий, которые работают вместе для поддержки команды.
2. Начинаем наш путь тестирования
В этой главе
• Знакомство с продуктом
• Настройка продукта
• Разбираемся, что мы тестируем, собираем сведения о продукте
• Создаем визуальную модель, чтобы делиться информацией
Представим, что это наш первый рабочий день в проекте. Мы присоединились к команде и должны внедрить стратегию тестирования, чтобы помочь коллегам и улучшить качество продукта. С чего мы начнем или как будем продвигать уже имеющуюся стратегию тестирования? Какие инструменты и методы мы должны использовать?
В следующих главах мы узнаем о различных способах тестирования веб-API и о том, как разработать стратегию тестирования API, а для облегчения обучения попрактикуемся на примере продукта. Как и в тот воображаемый первый день, будем решать задачу разработки стратегии тестирования API для приложения и контекста, с которым мы не знакомы. В этой главе мы узнаем о продукте, который будем тестировать на протяжении всей книги, а также о том, как начать путь к созданию успешной стратегии тестирования API.
Подготовка
Прежде чем приступить к этой главе, я настоятельно рекомендую загрузить и установить платформу API песочницы — restful-booker, которую мы будем использовать в этой главе и далее. Подробности о том, как установить приложение, вы найдете в приложении в конце книги.
2.1. Знакомство с продуктом
Приступая к тестированию, целесообразно сперва изучить историю продукта. Не пожалейте времени на то, чтобы узнать о пути, который прошли команда и продукт, понять, как работает продукт, чего команда надеется достичь и какие проблемы пользователей пытается решить. Все это поможет сформировать видение стратегии тестирования.
Уже работаете над продуктом?
Хотя в этой главе описана ситуация, в которой мы начинаем новый проект без стратегии тестирования, многие из нас, скорее всего, будут работать над существующими проектами. Однако инструменты и приемы, которые мы изучим в этой главе, пригодятся независимо от контекста. Эта глава поможет научиться разбираться, как работает платформа API, и делиться этим пониманием с другими.
Для начала давайте познакомимся с платформой restful-booker и узнаем, что она может, почему была создана и что мы собираемся сделать, чтобы помочь улучшить ее качество.
2.1.1. Знакомство с нашей API-песочницей
Давайте представим, что платформа restful-booker — это реальный продукт, за который мы несем ответственность. В нашей ролевой игре платформа restful-booker была создана для владельцев отелей типа bed-and-breakfast (B&B) для управления своими веб-сайтами и бронированием. Ее функции:
• создание бренда для продвижения B&B;
• добавление номеров для бронирования с подробной информацией для гостей;
• создание бронирований гостями;
• просмотр отчетов по бронированиям для оценки доступности;
• отправка гостями сообщений хозяевам B&B.
Платформа изначально создавалась как хобби-проект для одного владельца B&B, но с тех пор выросла и теперь используется несколькими владельцами B&B для бронирования. Проект постепенно растет как по числу отелей, так и по клиентской базе, но в последнее время стали возникать проблемы. Некоторые владельцы B&B недовольны ошибками, простоями и неправильно реализованными функциями. Наша цель — предоставить стратегию тестирования, которая поможет команде улучшить качество платформы restful-booker и гарантирует, что как владельцы B&B, так и гости будут довольны продуктом.
2.2. Знакомство с платформой restful-booker
Прочитав короткую историю платформы restful-booker, мы узнали следующее:
• У нас есть два разных типа пользователей: гости и менеджеры B&B, что следует учитывать при разработке наших API.
• Приложение имеет несколько различных функций, и это подразумевает, что несколько сервисов, вероятно, обрабатываются несколькими API.
• Ядро продукта написано на Java, что определяет, какие языки и инструменты мы могли бы использовать для автоматизации некоторых наших тестов.
Но самое главное, мы узнали, что от нас требуется разработать и внедрить стратегию тестирования API, которая поможет нашей команде улучшить качество продукта.
Мы могли бы сразу попробовать использовать знакомые методы и инструменты или просто начать отправлять запросы в различные веб-API на нашей платформе, чтобы посмотреть, что произойдет. Это может принести некоторую пользу, но не приблизит создание эффективной стратегии тестирования API. Хорошая стратегия требует понимания целей. Без знания того, как работает наша система, как она реализована, кем и для кого она создается, мы не определим стратегию.
