Добро пожаловать в серию статей «Лидерство в тестировании» от гуру тестирования программного обеспечения и консультанта Пола Джеррарда. Эта серия предназначена для того, чтобы помочь тестировщикам с многолетним опытом работы, особенно в Agile командах, преуспеть в своей роли руководителя тестирования и менеджера.
В предыдущей статье мы обсудили, как управлять тестированием производительности. Теперь мы обсудим программное обеспечение для ИТ‑инфраструктуры, инфраструктуру тестирования и тестовые среды.
Инфраструктура — это термин, который мы используем для описания всего оборудования, облачных сервисов, сетей, вспомогательного программного обеспечения и тестируемого приложения, необходимого для разработки, тестирования, развертывания и эксплуатации наших систем.
Однако имеет смысл не ограничивать наше определение технологией. Центры обработки данных, офисные помещения, рабочие столы, настольные компьютеры, ноутбуки, планшетные компьютеры и мобильные телефоны с установленными на них собственными программными пакетами — все это является частью экосистемы, необходимой для разработки, тестирования и развертывания систем.
Если вы используете инструменты разработчика, DevOps-инструменты и процедуры, инструменты тестирования, а также необходимые бизнес-процессы и знания в предметной области, то это еще не все.
Самые простые вещи — коды доступа или смарт-карты, используемые для доступа в здания, — могут стать критически важными, если их нет на месте.
Инфраструктура во всем ее разнообразии предназначена для поддержки разработки, тестирования, развертывания и эксплуатации ваших систем. Она либо критически важна для тестирования, либо нуждается в тестировании.
В этой статье мы рассмотрим то, что большинство людей считают тестовыми средами(инвайроментами), и кратко рассмотрим то, что часто называют тестированием инфраструктуры, а именно:
Начнем.
Тестовые среды
Все тесты основаны на неявном, критическом и упрощающем предположении: наши тесты будут выполняться в известной среде.
Что такое среда?
Все системы должны быть протестированы в контексте. Чтобы тестирование было эффективным, система должна быть установлена, настроена, развернута или сконструирована в реалистичной среде, имитирующей реальный мир, в котором она будет использоваться.
Мы могли бы использовать тестовые сценарии, которые, например, расширяют возможности систем с точки зрения функциональности, производительности или безопасности, но это свойства тестов, а не среды.
Реалистичная среда будет воспроизводить все бизнес, технические и организационные условия. Большая часть этих данных включает в себя данные, используемые для управления бизнес-процессами, настройки системы и предоставления справочных данных.
Но абсолютно реалистичные среды обычно непрактичны или слишком дороги (даже тестировщикам систем с высокой степенью критичности, таких как самолеты, ядерные реакторы или сканеры мозга, в какой-то момент приходится идти на компромисс). Почти все испытания проводятся в средах, имитирующих реальный продукт с некоторым приемлемым уровнем компромиссов.
Автомобили проходят испытания на грунтовых дорогах, в аэродинамических трубах, вибростендах и частных испытательных трассах, прежде чем их можно будет протестировать на открытом воздухе. Компьютерные системы тестируются в лабораториях программистами и специалистами по тестированию программного обеспечения, прежде чем конечные пользователи смогут опробовать их в условиях, подобных продакшену.
Тестируйте в реалистичных средах
В моделируемых средах возможны ошибки, как и в наших требованиях и тестовых моделях, но мы должны с этим мириться.
Следует проводить значимые тесты в рамках имеющейся среды, а результаты этих тестов — это то, как мы сами их интерпретировали.
Надежность результатов тестирования зависит от среды, в которой выполняются тесты. Если тест выполняется в среде, которая настроена неправильно:
Неудачный тест может означать, что система неисправна, хотя на самом деле все правильно.
Успешное прохождение теста может означать, что система работает правильно, хотя на самом деле она неисправна.
Разумеется, обе ситуации крайне нежелательны.
Своевременная настройка и поставка сред
Даже с появлением облачной инфраструктуры настройка и обслуживание тестовых сред могут быть сложными и дорогостоящими.
Когда группы поддержки работают над новой продакшен средой, тестировщикам могут требоваться тестовые среды (и, возможно, несколько таких сред). На более поздних этапах тестирования у групп поддержки часто возникают конкурирующие требования.
Среды разработки или любые последующие действия по тестированию могут быть запущены с опозданием или не выполняться вовсе, или они могут быть сконфигурированы или контролироваться не так, как требуется. Это неизбежно приведет к задержке тестирования и/или подорвет уверенность в любом результате тестирования.
Важнейшей задачей является своевременное определение необходимости и требований к среде, которая будет использоваться для тестирования, включая механизм управления изменениями в этой среде.
Инфраструктура как код — это недавняя эволюция в том, как можно создавать среды с помощью инструментов, следующих процедурам и использующих декларативный код для определения настроек среды.
Хотя базовые платформы операционных систем (серверы) можно легко создать в облаке или в виде виртуальных машин в вашей собственной среде, полностью определенные серверы специального назначения со всем необходимым программным обеспечением, данными, конфигурациями и интерфейсами требуют больших усилий.
Однако после настройки они становятся высокоэффективным средством создания среды. Инфраструктурный код может управляться с помощью исходного кода, как и любой другой прикладной код, и управляться путем внесения изменений.
Основной принцип непрерывной поставки ПО заключается в том, что как можно скорее какое-либо ПО, даже если оно не является чем-то полезным, должно быть внедрено, чтобы доказать работоспособность процессов.
Конечно, для этого нужны жизнеспособные среды для сборок, средства непрерывной интеграции, системное тестирование и настроенный процесс деплоймента. Цель состоит в том, чтобы развертывать тестовые и продакшен среды без ограничений. Как только будут созданы определения среды и процессы деплоймента, создание сред станет автоматизированной и рутинной задачей.
В любом случае, определения этих сред являются одним из первых результатов проекта.
Среды разработки
Тестирование разработчика сосредоточено на создании программных компонентов, которые предоставляют функции приложению на уровне пользователя или представления.
Тесты, как правило, основаны на знании внутренней структуры кода, и для их выполнения могут не использоваться "реалистичные" данные или требовать их использования. Тесты низкоуровневых компонентов или служб обычно выполняются через API с использованием специально разработанных или проприетарных драйверов или инструментов.
Спектр инструментов разработки, платформ и так называемых интегрированных сред разработки (IDE) огромен. В этой статье мы можем коснуться лишь некоторых основных требований и особенностей сред, связанных с тестированием.
Для поддержки разработки и тестирования в объеме, доступном для разработчиков, среда должна поддерживать следующие действия. Это всего лишь выборка — в вашей ситуации могут быть дополнительные действия или их вариации:
Песочница (Sandbox) для экспериментов с новым программным обеспечением. Песочницы часто используются для тестирования новых библиотек, разработки одноразового кода-прототипа или отработки методов программирования. Все распространенные языки программирования содержат сотни или тысячи программных библиотек. Изолированные среды используются для установки и тестирования программного обеспечения, которое еще не является частью основного потока разработки, для его оценки и практического использования. Эти среды могут рассматриваться как одноразовые.
Локальная среда разработки. Здесь разработчики поддерживают локальную копию подмножества или всего исходного кода своего приложения из общего хранилища кода и могут создавать системные сборки для локального тестирования. Эта среда позволяет разработчикам вносить изменения в код в своей локальной копии и тестировать свои изменения. Некоторые тесты проводятся нерегулярно и, возможно, никогда не повторяются. Другие тесты автоматизированы. Автоматизированные тесты обычно сохраняются навсегда, особенно если они основаны на TDD подходе.
Общая (непрерывная) среда интеграции. Когда разработчики уверены, что их код готов, они отправляют свои изменения в общий, управляемый репозиторий кода. CI среда выполняет автоматическую сборку и автоматические тесты с использованием репозитория. На этом этапе новый или измененный код интегрируется и тестируется. CI система запускает автоматизированные тесты по запросу, ежечасно или ежедневно, и вся команда получает уведомления и может видеть статус тестов последней интегрированной сборки. Сбои выявляются оперативно и устраняются в срочном порядке.
Среда разработки или CI поддерживает тестирование разработчиком, но другие серверы приложений, веб-службы, серверы обмена сообщениями или базы данных, которые дополняют систему, могут быть недоступны.
Если взаимодействие этих систем не существует, потому что они не были созданы, или потому что они принадлежат компании-партнеру, и существует только действующая система и нет тестовой версии, то разработчикам приходится ограничивать или имитировать эти интерфейсы (создавать моки), чтобы, по крайней мере, иметь возможность протестировать свой собственный код.
Имитационные (Mock) инструменты могут быть сложными, но имитируемые интерфейсы обычно не могут поддерживать тесты, требующие интеграции данных в нескольких системах.
Если разработчикам доступен интерфейс к серверу тестовых баз данных, их тестовые данные могут быть минимальными, не интегрированными или непротиворечивыми и не соответствовать производственным данным.
Состояние общих для всей команды баз данных для разработки обычно является неудовлетворительным. При отсутствии надлежащего режима управления этим общим ресурсом разработчики могут повторно использовать, портить или удалять данные друг друга.
Тестовые среды системного уровня
Тестирование на системном уровне сосредоточено на совместной интеграции компонентов и подсистем.
Эти среды предоставляют платформу для поддержки задач крупномасштабной интеграции, проверки функциональности и функционирования системы в контексте пользовательских или бизнес-процессов.
Среды также могут быть посвящены нефункциональным аспектам системы, таким как производительность, безопасность или управление сервисами.
Одна из наиболее распространенных ошибок при тестировании заключается в том, что у тестировщика системы в своей среде возникает какой-либо сбой, но, как бы он ни старался, разработчик или тестировщик не могут воспроизвести сбой в среде разработки.
«Это работает на моей машине!»
«Да, конечно, это так».
Это почти наверняка вызвано несогласованностью в двух средах. Разница в поведении может быть вызвана конфигурацией, некоторыми различиями в версиях программного обеспечения или различиями в данных базы данных.
Первое, что нужно проверить, — это различия в данных, вызывающие проблемы. Обычно их легко выявить и часто их можно быстро устранить.
При обнаружении несоответствия в версии программного обеспечения или конфигурации тестировщики и разработчики могут потратить много времени на поиск причины различий в поведении.
Возникновение подобных проблем часто означает сбой в обмене данными между разработчиком и тестируемым устройством. Это также может указывать на потерю контроля над конфигурацией при настройке среды разработчика или тестирования или в процессе развертывания.
Инфраструктура в виде кода и автоматизированная подготовка среды позволят оставить проблемы с согласованностью среды в прошлом.
Типы специализированных тестовых сред
Для поддержки системного, приемочного и нефункционального тестирования среды должны поддерживать следующие действия (в вашей организации их может быть больше):
(Функциональная) Системная среда тестирования. В этой среде система проверяется на соответствие требованиям, задокументированным для системы в целом. Требования могут представлять собой большие текстовые документы с табличными тест кейсов, определенными для тестирования системы. В Agile проектах эта среда может быть необходима для того, чтобы тестировщики могли исследовать интегрированную систему, не ограничиваясь конкретными функциями.
«End-to-end” среда тестирования. В тех случаях, когда CI среда позволяет интегрировать компоненты с подсистемами, для бизнес-процессов могут потребоваться другие системы взаимодействия (не находящиеся под контролем разработчиков). Для проведения крупномасштабной интеграции, бизнес-процессов или общего приемочного тестирования требуются полномасштабные среды. Как правило, данные являются копией данных в реальном времени или, по крайней мере, в соответствующем масштабе. Там, где требуется доказать эффективность крупномасштабной интеграции, потоки данных и контроль осуществляются за счет более длительных сессий пользователей и независимой сверки данных в интегрированных системах. Управление данными в тестовых средах имеет решающее значение. Если вы уже используете Jira, подумайте о расширении своих возможностей по управлению данными с помощью расширенных инструментов управления тестированием, разработанных для Jira.
Среда измерения производительности. Эти среды должны обеспечивать надежную платформу для оценки производительности системы (или выбранных подсистем). При избыточности или клонировании серверов возможны компромиссы в архитектуре. Однако объемы данных должны соответствовать продакшен масштабу, даже если данные являются синтетическими. Безусловно, среда должна быть такого масштаба, чтобы поддерживать объемы производственных транзакций, позволяющие эффективно прогнозировать производительность систем в процессе производства.
Среды доступности, отказоустойчивости и управляемости (ARM). В некоторых отношениях эти среды аналогичны средам измерения производительности, но в зависимости от цели тестирования могут быть неизбежны изменения. Целью тестирования доступности является проверка того, что система может работать в течение длительного времени без сбоев. Тестирование на устойчивость (часто называемое тестированием на отработку отказа) проверяет, что отказ системных компонентов не приводит к недопустимым сбоям в работе предоставляемого сервиса. Тестирование управляемости или операций призвано продемонстрировать эффективность процедур системного администрирования, управления, а также резервного копирования и восстановления.
Данные в средах
В некоторых очень крупных проектах может быть до 20 или даже 30 крупномасштабных сред, предназначенных для различных аспектов тестирования, обучения, переноса данных и пробного запуска. В небольших проектах их будет меньше, возможно, только одна общая среда или режим непрерывной доставки, и все тестирование может осуществляться автоматически в средах, которые создаются для одноразового использования, а затем удаляются.
Данные нужны во всех средах, но масштаб и степень реалистичности этих данных могут различаться. Ниже приведены некоторые общие закономерности в получении тестовых данных и управлении ими. Эти закономерности касаются владения (локального или общего) средствами создания (ручными, автоматизированными или скопированными из рабочей среды) и масштабирования:
Локальные, созданные вручную, маломасштабные данные — подходят для специального тестирования разработчиками или тестировщиками.
Локальные, автоматизированные, синтетические данные. Подходят для автоматизированных тестов разработчиков или сред, в которых может быть охвачена функциональность определенных модулей или функций.
Общие данные, созданные вручную. Используется в средах интеграции и системного тестирования, где данные тестирования часто обновляются параллельно с тестами, выполняемыми вручную. При необходимости создается резервная копия и восстанавливаются.
Общие данные, созданные автоматически. Используется в средах интеграции и системного тестирования, где тестовые данные формируются параллельно с автоматизированными тестами или тестами, выполняемыми вручную. При необходимости генерируются и/или восстанавливаются из резервных копий.
Общие крупномасштабные синтетические/случайные данные. Для тестирования производительности и ARM-тестирования требуются согласованные данные в большом объеме. Обычно эти данные не обязательно должны быть значимыми – рандомизированные данные работают нормально и генерируются по мере необходимости или генерируются изначально и восстанавливаются из резервных копий.
Общие крупномасштабные значимые данные. Для комплексного, приемочного или пользовательского тестирования обычно требуются значимые данные в широком масштабе. Иногда используются копии или выдержки из реальных данных. Будьте осторожны, вы не нарушите правила обработки данных, если не будете их искажать / обезличивать.
Повторное тестирование и регрессионное тестирование. Вам потребуется известный контролируемый набор данных в известном состоянии, поэтому его обычно восстанавливают из резервных копий. Это относится к любой из описанных выше сред, поскольку для надежного воспроизведения сбоев эти тесты необходимо повторно запускать с данными в известном состоянии.
Тестирование инфраструктуры
В начале этой статьи мы рассмотрели, что включает в себя инфраструктура, и с тех пор мы в первую очередь сосредоточились на технических компонентах, а именно на программных системах, и предположили, что аппаратное обеспечение — реальное или виртуальное — доступно.
Когда мы изначально создаем системы, мы исходим из того, что инфраструктура существует и что она функционирует правильно, является производительной, безопасной и устойчивой и т. д.
Мы можем протестировать все эти аспекты после интеграции нашего приложения и, несомненно, выявить недостатки в инфраструктуре на относительно поздней стадии наших проектов. Но обнаружение проблем с инфраструктурой на столь поздних этапах проекта обычно приводит к серьезным сбоям.
Изменения, направленные на устранение сбоев в инфраструктуре, могут потребовать существенной модернизации и внесения изменений в наше приложение.
Результаты тестирования нашего приложения или всей системы необходимо будет повторить.
Если компоненты сторонних производителей, такие как базы данных, веб-сайты, сетевые сервисы или службы обмена сообщениями, выходят из строя, мы зависим от поставщиков (или сообщества разработчиков с открытым исходным кодом), которые их поддерживают.
Чтобы быть уверенными в надежности компонентов инфраструктуры, мы можем полагаться на свой (или чужой) опыт их использования в прошлом. Или же нам необходимо оценить их надежность с помощью тестирования, прежде чем мы приступим к их использованию при проектировании и создании нашей системы.
В зависимости от исследуемой инфраструктуры используемая среда может варьироваться — от отдельного сервера до практически полной инфраструктурной платформы.
Хотя некоторые тесты будут проводиться вручную, в основном мы будем использовать инструменты, драйверы или роботов для моделирования транзакционной нагрузки, которую будет генерировать наше приложение. Нам нужно было бы смоделировать или отключить эти интерфейсы:
Интерфейсы, которые в настоящее время недоступны
Интерфейсы для компонентов, которым мы доверяем и которые легко имитировать
Интерфейсы, не входящие в область действия, которые не влияют на тестируемую инфраструктуру.
Излишне говорить, что инфраструктура обычно не работает через пользовательский или графический интерфейс.
Интеграция приложения в инфраструктуру в основном будет осуществляться в форме обмена сообщениями или удаленных вызовов служб. Часто для моделирования трафика требуются вызовы API к веб-серверам или серверам приложений, серверам обмена сообщениями или базам данных, а также к сервисам, предоставляемым через облако или удаленные местоположения.
Цели в области производительности и ARM могут быть известны, и в этом случае могут быть выполнены тесты для обеспечения достижения этих целей.
Однако инфраструктура часто используется совместно с другими приложениями, кроме нашего собственного, поэтому знание ее конечной емкости помогает оценить, сколько ресурсов останется после развертывания нашего приложения.
В данном случае тестирование инфраструктуры направлено на снижение риска для наших собственных и, возможно, других приложений, которые будут основаны на ней в будущем.