Как тестировать бэкэнд

Как начать тестировать backend и не сойти с ума

Дисклеймер: B первую очередь материал будет интересен тем, кто уже значительное время занимается тестированием пользовательского интерфейса и не знает, как подойти к тестированию backend части приложения. Я не претендую на истину: всё, что сказано ниже, является моим субъективным мнением и пережитым опытом.

Введение

Рынок IT специалистов начал стремительно развиваться в последние пару лет. Требования ко всем специальностям, которые задействованы в разработке программного обеспечения, растут со скоростью развития применяемых технологий. Требования выросли и к специалистам по тестированию. Например, если ещё в 2019 году для того, чтобы устроится тестировщиком в международную IT компанию достаточно было иметь год опыта тестирования чего-нибудь, прочитать «Тестирование dot com» Савина, уметь писать тест-кейсы, знать такие слова как «GIT», «SQL» и «Redmine», то в 2021 году ситуация стала радикально меняться. Осознание того факта, что пятилетний опыт ручного тестирования frontend части различных приложений недостаточен для конкурирования на рынке, привёл меня к выгоранию и побудил к решительным действиям. Я осознал, чтобы не остаться на обочине всей IT индустрии необходимо соответствовать современным критериям хорошего специалиста по тестированию. А именно, попытаться понять, как тестировать серверную часть приложений.

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

Отличие backend тестирования от frontend тестирования

Для начала расскажу, что такое backend тестирование (далее в тексте буду использовать сокращение БТ) и чем оно отличается от frontend тестирования (ФТ).

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

ФТ — это процесс проверки пользовательского интерфейса и функциональности web и desktop приложений. Он включает в себя проверку правильности отображения веб-страниц, а также взаимодействия элементов пользовательского интерфейса, таких как кнопки, поля ввода, выпадающие списки, меню и т.д. Для ФТ используются инструменты, которые позволяют обнаружить ошибки в пользовательских интерфейсах, проверять поведение пользовательских элементов и форм, а также различные сценарии взаимодействия пользователя.

Для БТ используются инструменты, позволяющие создавать тесты для API, которые предназначены для обработки запросов и в некоторых случаях их автоматизации. Позже приведу примеры таких инструментов. В общем, важнейшим отличием между этими двумя видами тестирования является то, что ФТ осуществляется на уровне пользовательского интерфейса, а БТ на уровне сервера. Важно понимать, что если мы тестируем backend, то это не значит, что мы не используем его фронтовую часть для проверок.

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

Однако при переходе на backend есть ряд ключевых вещей, которые следует учитывать:

Понимание технологий. На мой взгляд БТ требует углубленного технического понимания проекта, поэтому важно знать основы разработки клиент-серверных приложений, понимать основы программирования, так как умение читать и понимать код является существенным преимуществом. Пригодятся навыки работы в IDE (рус. интегрированная среда разработки) и СУБД (системы управления базами данных), так как затрагивает, в том числе и проверку на корректность и целостность данных, а также проверку производительности базы данных при большой нагрузке.

Какие инструменты могут понадобиться в работе с новым проектом:

• Graylog – Платформа с открытым исходным кодом для чтения логов

• Lens – Полноценная IDE для Kuberneties, в БТ чаще всего используется для чтения логов микросервисов. Про Kuberneties, кластеризацию, контейнеризацию и в целом про Linux также есть смысл отдельно почитать, информации достаточно, и лишним точно не будет.

• Notepad++ — Текстовый редактор с широкими возможностями, удобно читать логи, запросы и ответы. Есть плагины для xml и json, а также для декодирования Base64.

• JMS Active MQ – Брокер сообщений ориентированный на передачу сообщений на языке программирования Java.

• Offset explorer и Kafka UI – Графические интерфейсы для Apache Kafka распределенного хранилища событий и платформы потоковой обработки.

• Redis – Резидентная СУБД. На разных проектах может использоваться по-разному, например как база данных или для реализации кэшей и брокеров сообщений.

• PostgreSQL, MySQL – Системы управления базами данных, в разных компаниях могут использоваться разные, главное знать SQL.

• DBeaver, SQL Developer, PgAdmin, Squirrel SQL – Клиенты для администрирования баз данных, бывают всякие, без SQL никуда.

• Elasticsearch – По сути документо-ориентированная база данных, используется в продуктах, для которых требуется реализация какого-нибудь поиска.

• Charles Proxy, Fiddler, Wireshark – Снифферы трафика, позволяют просматривать HTTP запросы и подменять ответы. В основном используются для ФТ, но уметь пользоваться крайне полезно.

• GIT (GIT LAB, GIT bash, GIT Extensions, Tortoise GIT) – Всё, что связано с распределенными системами управления версиями и их вспомогательными инструментами, тоже важно знать. Это упростит вхождение в сложные проекты.

• Отдельно выделю, надеюсь, всем известные инструменты разработчика: DevTools и чат-боты kuberneties в телеграм. Если ничего об этом не слышали, то срочно читайте.

Тестирование способов взаимодействия одной компьютерной программы с другими или тестирование API (Application Programming Interface), является существенной частью БТ. Тестировщик должен знать, какими инструментами тестирования API они могут пользоваться, какие сценарии нужно проверять и какие типы ошибок можно ожидать при работе с ним.

API играет ключевую роль в процессе обеспечения функциональности приложения и включает проверку правильности запросов и ответов, а также проверку соответствия контрактам сервисов. В тестировании backend используются различные протоколы, такие как HTTP, HTTPS, SOAP и другие. Понимание этих протоколов и стандартов поможет лучше понимать, как устроен backend, и какие тесты нужно создавать.

• Postman – Наверное, самый популярный инструмент c широким функционалом для тестирования REST API. Позволяет не только собирать коллекции запросов, но и автоматизировать тест-кейсы, а также перехватывать http трафик благодаря расширению на Google Chrome — Postman interceptor.

• SoapUi – Одно из старейших приложения для тестирования веб-сервисов c SOAP (Протокол обмена структурированными сообщениям в распределённой вычислительной среде), также начинен серьезным функционалом по тестированию REST API и нагрузочному тестированию.

• Swagger — это набор инструментов для разработчиков API и бывшая спецификация, на которой основана спецификация OpenAPI. Если Swagger присутствует на проекте, то это сильно упрощает работу по тестированию.

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

• jMeter – Инструмент для проведения нагрузочного тестирования от Apache.

• Yandex Tank – Чуть менее популярный инструмент от Яндекса.

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

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

Концептуальные подходы к пониманию проблем:

• Ищите информацию. Учитесь работать с базами знаний вашей команды, это может быть Confluence или Wiki, что-то полезное можно найти в Jira, если конечно этими инструментами пользуются на проекте, но наверняка что-то похожее будет.
• Пользуйтесь поиском в корпоративных мессенджерах, часто бывает, что кто-то уже задавал похожий вопрос в рабочих чатах — опробуйте поискать по ключевым словам. Также не забывайте про поисковики, какую-то общую информацию можно найти и там.

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

• Задавайте вопросы. Тут пригодятся все ваши soft skills. Если поиск в интернете и по своим записям ни к чему не привели, то самое время обратиться к всевышним. Обратитесь к старшим коллегам-тестировщикам: наверняка они уже с этим когда-то разбирались и обязательно вам помогут (помните, что когда-то они были на вашем месте). Не забывайте задавать вопросы напрямую разработчикам фичи, которую вы будете проверять. Это закрывает большую часть проблем. Если ничего из вышеперечисленного не помогает, то пишите вашему прямому руководителю, чем быстрее, тем лучше для всех.

Как повысить свои когнитивные способности:

• Выспаться. Постоянный недосып напрямую влияет на работу мозга, старайтесь спать не меньше 8 часов.

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

• Следить за питанием. Здоровый рацион сам по себе крайне важен в жизни, но в нашем случае будет достаточно не переедать во время работы и употреблять достаточное количество жидкости.

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

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

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

• Stack trace (рус. «стектрейс», трассировка стека) – Понятие объемное и не простое, но тестировщику достаточно знать что это кусок логов который нужно прислать разработчику если возникло исключение.

• Exception (рус. «экзепшн», исключение, исключительный случай) – Возникает, когда произошло что-то что не было учтено программой, какое-то не спрогнозированное поведение.

• HAR (рус. «хар лог», «хар файл») – Архив или лог сетевых запросов браузера. Иногда тоже может потребоваться такой лог, в котором собраны все отправленные запросы.

• Breakpoint (рус. «брейкопинт», точка остановки) – Преднамеренное прерывание хода выполнения программы. Понятие может потребоваться в процессе работы со снифферами трафика или с интегрированной средой разработки.

• Mocks (рус. «моки», «заглушки») – Сюда входят любые инструменты которые заменяют реальный объект в условиях теста. Обычно применяются во всех видах тестирования, но конкретно при работе с бэкэндом без них никуда.

• Core (рус. «кор», ядро) – Достаточно широкое понятие и может употребляться в разном контексте, например, для определения какой частью приложения занимается группа разработки и тестирования, если самой основной, то говорят «кор команда». Также если речь идет непосредственно о коде: «зашито в коре».

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

• Legacy (рус. «легаси код», наследие) – Буквально термин означает старый код, который был написан очень давно по старой монолитной архитектуре. Его достаточно сложно читать и поддерживать.

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

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

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

• Блог компании Usetech
• Программирование
• SQL
• Git
• Тестирование веб-сервисов

Как проводить backend тестирование

Большая часть процесса тестирования ПО сосредоточена на тестировании графического интерфейса пользователя (GUI). На этом этапе тестировщик проверяет, пригодно ли ПО для использования конечным пользователем.

Но существуют и другие элементы, которые скрыты от пользователя и не доступны для непосредственного взаимодействия — backend. Это не делает эти элементы менее важными, и они тоже должны подвергаться тщательному тестированию. Мы можем объединить как backend всё, что пользователь не видит напрямую.

Вот некоторые из элементов backend:

Тестирование баз данных

Чаще всего, когда говорят о backend тестировании, подразумевается тестирование баз данных (БД).

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

Базы данных обычно проверяются на:

• Требования ACID
• CRUD-операции
• Схему
• Миграцию данных
• Безопасность
• Производительность

Давайте рассмотрим несколько инструментов для тестирования баз данных:

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

• TOAD: создан для работы с реляционными базами данных. Он доступен как в бесплатной, так и в платной версии.
• pHpMyAdmin: отличный инструмент с открытым исходным кодом, который позволяет взаимодействовать с БД через пользовательский интерфейс. Если вы ищете инструмент подключения к базам данных MySQL и MariaDB, то этот инструмент точно вам подойдёт.
• HeidiSQL: очень похож на pHpMyAdmin. Он подключается к базам данных MySQL, Microsoft SQL и PostgreSQL.

2. Инструменты для тестирования производительности и нагрузки БД:

• HammerDB: инструмент с открытым исходным кодом, который поддерживает многие базы данных.
• SLOB: генератор рабочей нагрузки, предназначенный для тестирования системы ввода-вывода. С его помощью можно получить представление о процессоре, памяти и времени обработки массовых транзакций в БД.
• Swingbench: это эффективный инструмент, который работает на СУБД Oracle.

Тестирование API

Строго говоря, API не является частью backend. Но так как мы условно относим к backend всё, что не видно конечному пользователю, давайте рассмотрим и его.

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

Все базы данных и приложения установлены на серверах, которые поддерживают их работоспособность.

На этой стадии проводится несколько тестов:

1. Установка: после завершения установки вы можете перейти в соответствующие папки и убедиться, что файлы/элементы установлены так, как ожидалось.

2. Логи (Logs): на серверах ведутся журналы регистрации состояния каждой транзакции. Это даёт нам представление о том, насколько корректным был процесс транзакции.

Как правило, большинство серверов представляют собой системы на базе UNIX. И для удобной работы с ними вам понадобится программа для подключения к вашему серверу.

С этим вам может помочь PuTTy — популярная программа для удалённого администрирования с открытым исходным кодом.

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

3. Производительность и безопасность сервера:

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

Существует множество инструментов для проверки этих параметров, например, Apache JMeter, WebLOAD, LoadRunner и т. д.

Заключение

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

Похожие записи:

1. Все виды тестирования с описанием
2. Мутационное тестирование
3. Что такое нефункциональное тестирование?
4. Модульное тестирование

Что должен знать тестировщик бэкенда

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

В компании, где я работаю, есть список тем с вопросами, которые мы задаём кандидатам. Я решил дополнить его, сделать более универсальным, разбить каждую тему по уровням (что нужно знать обязательно и что будет плюсом) и добавить ссылки на статьи и книги, которые можно почитать по этим темам.

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

Необходимые знания

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

Также хочу обратиться и к работодателям: не стоит спрашивать про управление памятью в Linux кандидата на позицию Mobile QA Engineer, это вряд ли пригодится ему в работе.
Я не упоминаю языки программирования, потому что это сильно зависит от используемого стека. Но часто про них вообще ничего не спрашивают на собеседованиях тестировщиков (в противном случае указывают о необходимом уровне знания языка в описании вакансии).

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

Теория тестирования

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

Что ожидается от любого кандидата

Знание основных терминов, техник тест-дизайна, умение написать качественный баг-репорт.

Что говорит о том, что кандидат хорошо знает тему

Формально это сертификаты ISTQB.

Что почитать по теме

Есть хорошая статья на Хабре со всей необходимой информацией. Если же хочется более детально разобраться в теории тестирования, то можно почитать материалы ISTQB.

Shell

В зависимости от ОС нужно знать либо bash (sh, zsh и т.п., но нюансы вряд ли будут играть существенную роль), либо CMD и PowerShell.

Что ожидается от любого кандидата

Знание базовых команд.

Что говорит о том, что кандидат хорошо знает тему

Кандидат знает много команд, различные опции для них, их преимущества и недостатки, различные способы использования, а также инструменты для дебага проблем, например, strace, tcpdump, gdb и прочие.

Что почитать по теме

Про основные команды в Linux можно почитать в одной из моих предыдущих статей, а также есть очень крутой репозиторий c кучей примеров на GitHub. Из книг я бы посоветовал «Операционная система UNIX» Робачевского, Немнюгина и Стесик — она не только про команды, а про систему в целом.
Про команды CMD можно почитать здесь, а у PowerShell есть хорошая документация.

HTTP (или протоколы, указанные в описании вакансии)

Очень часто в качестве основного протокола для клиент-серверной архитектуры выбирают HTTP, поэтому часто спрашивают именно про этот протокол. Однако может понадобиться знать IMAP, POP3, SMTP (если будете тестировать почту), Protobuf или MessagePack или другие протоколы.

Что ожидается от любого кандидата

Здесь всё зависит от распространённости протокола. Вряд ли вам будут давать бинарный дамп трафика и просить десериализовать его на бумажке из Protobuf, но если речь идёт об HTTP, то нужно знать его на хорошем уровне: структуру запроса и ответа, основные заголовки, методы, коды ответов, HTTPS.

Что говорит о том, что кандидат хорошо знает тему

Кандидат может ответить на вопросы про кеширование, сжатие данных, cookies и использование различных заголовков в HTTP. Для других протоколов всё более субъективно.

Что почитать по теме

Про HTTP вся необходимая информация есть в «Википедии». Про другие протоколы советую читать их документации и спецификации. Также не стоит забывать про HTTPS. Ну и само собой, нужно всегда под рукой иметь ссылки на RFC 2616 и RFC 7540 (но есть и другие спецификации).

Сетевые протоколы более низкого уровня

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

Что ожидается от любого кандидата

Кандидат должен знать, что существуют протоколы TCP, UDP и IP и понимать их суть.

Что говорит о том, что кандидат хорошо знает тему

Понимание механизма работы протокола TCP (three-way handshake, некоторые поля из заголовка, флаги, скользящее окно), кандидат может назвать недостатки и преимущества TCP и UDP, области их применения, общие знания IP. Будет круто, если кандидат расскажет в двух словах и про другие протоколы (например, ARP, ICMP, ICMPv6).

Что почитать по теме

Базовые знания можно получить из статей в «Википедии»: сетевая модель OSI, TCP, UDP, IP, IPv6, ICMP, ARP, ICMPv6. Если хочется погрузиться в эту тему, то можно почитать «Компьютерные сети» Таненбаума.

Базы данных

Что ожидается от любого кандидата

Основные SQL-запросы (всеми любимый JOIN).

Что говорит о том, что кандидат хорошо знает тему

Общие знания о разных СУБД, репликации, шардировании, о внутреннем устройстве СУБД, общие знания о нереляционных БД.

Что почитать по теме

В общих чертах про базы данных можно почитать в документации конкретной СУБД. Если хочется разобраться с базами данных детально, то рекомендую соответствующие главы «Высоконагруженных приложений» Клеппмана.

ООП

Что ожидается от любого кандидата

Знание основных принципов ООП.

Что говорит о том, что кандидат хорошо знает тему

Будет круто, если кандидат знает некоторые паттерны.

Что почитать по теме

Про принципы можно почитать, например, здесь, про паттерны — здесь. Также есть классная книга «Приёмы объектно-ориентированного программирования. Паттерны проектирования» «банды четырёх».

Операционные системы

Что ожидается от любого кандидата

Для большинства вакансий тестировщиков знание нюансов работы операционных систем нерелевантно.

Что говорит о том, что кандидат хорошо знает тему

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

Что почитать по теме

Вкратце можно прочитать в уже упомянутой книге «Операционная система UNIX» Робачевского, Немнюгина и Стесик. Если тема заинтересует, то можно углубиться в неё с помощью, например, «Современных операционных систем» Таненбаума. В общих чертах ознакомиться с темой можно с помощью «Википедии»: есть статьи про ядро Linux, виртуальную память, context switch и прочие.

Архитектура ЭВМ

Что ожидается от любого кандидата

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

Что говорит о том, что кандидат хорошо знает тему

Будет здорово, если кандидат знает в общих чертах про работу процессора, регистры, кеши, работу памяти и диска и прочее.

Что почитать по теме

Поверхностно ознакомиться с «железом» можно с помощью «Википедии»: ЦПУ, режим работы процессора, микроархитектура (в этой статье много ссылок на другие статьи по теме), кеш, АЛУ, конвейер, branch predictor, суперскалярность и т.д. Более целостно и глубоко эту тему можно изучить, например, с помощью книги «Архитектура компьютера» Таненбаума.

Алгоритмы и структуры данных

Вопросы по алгоритмам и структурам данных, скорее всего, не зададут (особенно если позиция не уровня Intern или Junior), но какие-то общие вещи знать всё равно надо. Лично меня только один раз на собеседовании спрашивали про двоичную кучу, сам я тоже не любитель спрашивать про это кандидатов. Поэтому никаких критериев вводить не буду и прикреплю лишь статью с хорошими картинками, можно распечатать их и положить на видном месте. Если захочется погрузиться в алгоритмы и структуры данных с головой, то смело начинайте читать «Алгоритмы. Руководство по разработке» Скиены или «Алгоритмы. Построение и анализ» Кормена.

Прочее

1. Много где используется Docker.
2. Архитектура распределённых систем («Высоконагруженные приложения»).
3. REST и SOAP.
4. JSON и XML.
5. Protocol Buffers, MessagePack и BSON.
6. TLS.
7. Git (или другие VCS).
8. Nginx и Apache.
9. Библиотеки.
10. TeamCity и Jenkins (или другие CI-системы).

Несколько примеров тестовых заданий

Что будет, если ввести в адресную строку браузера google.com и нажать Enter?

Классическая задача, с помощью которой можно проверить, насколько глубоко кандидат разбирается в веб-технологиях в целом. Есть подробный разбор этой задачи на Хабре, но я не рекомендую вчитываться в нюансы типа «небольшое количество тока отправляется по электросхеме клавиатуры».

Тестирование формы с кнопкой

Да, эту задачу часто задают и на собеседовании тестировщиков бэкенда. Задача классическая, поэтому будет круто, если кандидат немного пофантазирует и представит, что может быть за этой формочкой с кнопкой. Например, можно предположить, что из формы данные уходят на бэкенд, состоящий из нескольких серверов и базы данных, что бэкенд пишет логи и имеет конфиг — это сразу добавит много тест-кейсов более глубокого уровня, чем «введём слишком длинное значение в поле ввода». Например, можно с помощью tcpdump смотреть, точно ли трафик идёт на все сервера бэкенда; можно попробовать отправить SQL-инъекцию или битый JSON (естественно, если вдруг JSON вообще есть в контексте задачи); можно проверить, что будет, если логи займут всё свободное место на диске; можно проверить работу системы при зафайрволенном бэкенде, корректность добавления данных в базу и т.д. Таким образом кандидат покажет свой широкий кругозор, что, несомненно, пойдёт ему на пользу.

Тестирование сервиса

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

Тестирование эндпоинта REST API

И опять всё то же, только с HTTP (скорее всего). Здесь можно продемонстрировать знание протокола HTTP: например, проверить работу сервиса при наличии различных заголовков в запросе.

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

• тестирование
• тестирование по
• развитие персонала
• qa
• qa образование
• базовые понятия

• Тестирование IT-систем
• Тестирование веб-сервисов

Тестирование

Компонентное (модульное) тестирование проверяет функциональность и ищет дефекты в частях приложения, которые доступны и могут быть протестированы по-отдельности (модули программ, объекты, классы, функции и т.д.).

AAA(arrange-act-assert)

Шаблон для форматирования Unit тестов. Обозначающий разделения теста на 3 части

1. Arrange — все необходимые подготовки и входные данные
2. Act — собственно вызов того метода который вы тестируете
3. Assert — проверки, что метод делает то что надо

Интеграционное тестирование (Integration Testing)

Проверяется взаимодействие между компонентами системы после проведения компонентного тестирования.

Системное тестирование (System Testing)

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

Операционное тестирование (Release Testing).

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

Приемочное тестирование (Acceptance Testing)

Формальный процесс тестирования, который проверяет соответствие системы требованиям и проводится с целью: • определения удовлетворяет ли система приемочным критериям; • вынесения решения заказчиком или другим уполномоченным лицом принимается приложение или нет.

Виды / типы тестирования

Функциональные виды тестирования

• Функциональное тестирование (Functional testing)
• Тестирование пользовательского интерфейса (GUI Testing)
• Тестирование безопасности (Security and Access Control Testing)
• Тестирование взаимодействия (Interoperability Testing)

Нефункциональные виды тестирования

• Все виды тестирования производительности:
• нагрузочное тестирование (Performance and Load Testing)
• стрессовое тестирование (Stress Testing)
• тестирование стабильности или надежности (Stability / Reliability Testing)
• объемное тестирование (Volume Testing)
• Тестирование установки (Installation testing)
• Тестирование удобства пользования (Usability Testing)
• Тестирование на отказ и восстановление (Failover and Recovery Testing)
• Конфигурационное тестирование (Configuration Testing)

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

• Дымовое тестирование (Smoke Testing)
• Регрессионное тестирование (Regression Testing)
• Повторное тестирование (Re-testing)
• Тестирование сборки (Build Verification Test)
• Санитарное тестирование или проверка согласованности/исправности (Sanity Testing)

Фреймворки/инструменты для тестирования

PHP Unit

PHP Unit — самый популярный фреймворк для модульного тестирования в PHP.

PHPUnit is based on the idea that developers should be able to find mistakes in their newly committed code quickly and assert that no code regression has occurred in other parts of the code base. Much like other unit testing frameworks, PHPUnit uses assertions to verify that the behavior of the specific component — or «unit» — being tested behaves as expected.

Data Provider

Метод, являющийся data provider-ом, должен возвращать массив массивов или объект, реализующий интерфейс Iterator . Метод, являющийся тестом, будет вызван несколько раз — с каждым массивом и в качестве аргументов будет передано содержимое массива.

Некоторые ключевые моменты при использовании data provider-а:

• Метод data provider-а должен быть публичным ( public ).
• Метод data provider-а должен возвращать массив собранных данных.
• Метод теста должен использовать аннотацию @dataProvider чтобы указать какой метод использовать в качестве data provider-а.

Mock vs Stub

The createMock method is used to create three mostly known test doubles. It’s how you configure the object makes it a dummy, a stub, or a mock.

You can also create test stubs with the mock builder ( getMockBuilder returns the mock builder). It’s just another way of doing the same thing that lets you to tweak some additional mock options with a fluent interface (see the documentation for more).

Dummy is passed around, but never actually called, or if it’s called it responds with a default answer (mostly null ). It mainly exists to satisfy a list of arguments.

$dummy = $this->createMock(SomeClass::class); // SUT - System Under Test $sut->action($dummy); 

Stubs are used with query like methods — methods that return things, but it’s not important if they’re actually called.

$stub = $this->createMock(SomeClass::class); $stub->method('getSomething') ->willReturn('foo'); $sut->action($stub); 

Mocks are used with command like methods — it’s important that they’re called, and we don’t care much about their return value (command methods don’t usually return any value).

$mock = $this->createMock(SomeClass::class); $mock->expects($this->once()) ->method('doSomething') ->with('bar'); $sut->action($mock); 

Expectations will be verified automatically after your test method finished executing. In the example above, the test will fail if the method doSomething wasn’t called on SomeClass , or it was called with arguments different to the ones you configured.

Codeception

Сodeception это, надстройка над PHPUnit(или любым другим тест фреймворком). Она позволяет выполнять сценарные тесты на движке PHPUnit. При этом все ваши существующие тесты для PHPUnit Codeception сможет подхватить без каких-либо проблем. К ним вы сможете легко добавить функциональные и приемочные тесты. Очень многие задачи, требующие костылей (например, интеграция с Selenium, с БД) в Codeception уже решены.

Behat

Behat — это инструмент BDD.

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

В чем преимущество BDD?

• тесты читаемые для не программистов.
• их легко изменять. Они часто пишутся почти на чистом английском.
• их теперь может писать product owner или другие заинтересованные лица.
• результаты выполнения тестов более «человечные».
• тесты не зависят от целевого языка программирования. Миграция на другой язык сильно упрощается.

И именно для этих целей Behat и используется. Позволяет писать тесты человекопонятным английским языком в формате Given-When-Then, преобразуя эти инструкции в вызов автотестов.

Selenium

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

TDD

Разработка через тестирование (test-driven development, TDD) — техника разработки программного обеспечения, которая основывается на повторении очень коротких циклов разработки: сначала пишется тест, покрывающий желаемое изменение, затем пишется код, который позволит пройти тест, и под конец проводится рефакторинг нового кода к соответствующим стандартам.

• Тестирование. Фундаментальная теория — самый лучший
• PHPUnit Getting Started
• Unit Testing Tutorial Part I: Introduction to PHPUnit
• ProTesting
• PHPUnit для начинающих
• https://codeception.com/05-06-2013/specification-testing-coparison.html