Тестирование — руководство 7 шагов

 

 

->

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

В предыдущей статье я рассказал вам, 10 инструментах тестирования производительности. Исходя из этого, в этой статье мы поговорим об инфраструктуре, тестовой инфраструктуре и тестовых средах.

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

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

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

Самые обыденные вещи — вплоть до кодов доступа или смарт-карт, используемых для доступа в здания, — могут стать критическими, если их нет на месте.

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

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

Тестовые среды

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

Что такое среда?

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

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

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

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

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

Получение реалистичных сред для тестирования

Смоделированные среды так же подвержены ошибкам, как и наши требования и тестовые модели, но нам просто нужно с этим смириться.

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

Надежность результатов тестирования зависит от среды, в которой выполняются тесты. Если тест запускается в неправильно настроенной среде:

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

Обе ситуации крайне нежелательны, конечно.

Своевременная настройка и доставка сред

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

Часто, когда группы поддержки работают над новой производственной средой, тестировщики требуют тестовых сред (а возможно, и нескольких). На поздних стадиях проектов к группам поддержки всегда предъявляются конкурирующие требования.

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

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

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

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

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

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

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

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

Среды разработки

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

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

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

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

• Среда «Песочница» для экспериментов с новым программным обеспечением. Песочницы часто используются для тестирования новых библиотек, разработки одноразового кода прототипа или для отработки методов программирования. Все распространенные языки программирования имеют сотни или тысячи программных библиотек. Песочницы используются для установки и тестирования программного обеспечения, которое еще не является частью основного потока разработки, чтобы оценить его и попрактиковаться в его использовании. Эти среды можно рассматривать как одноразовые среды.
• Локальная среда разработки. Именно здесь разработчики поддерживают локальную копию подмножества или всего исходного кода для своего приложения из общего репозитория кода и могут создавать сборки системы для локального тестирования. Эта среда позволяет разработчикам вносить изменения в код в своей локальной копии и тестировать свои изменения. Некоторые тесты являются специальными и, возможно, никогда не повторяются. Другие тесты автоматизированы. Автоматизированные тесты обычно сохраняются навсегда, особенно если они следуют подходу Test-Driven.
• Общая (непрерывная) среда интеграции. Когда разработчики уверены, что их код готов, они отправляют свои изменения в общий контролируемый репозиторий кода. Используя репозиторий, среда CI выполняет автоматизированные сборки и выполняет автоматизированные тесты. На этом этапе новый или измененный код интегрируется и тестируется. Система CI запускает автоматические тесты по запросу, ежечасно или ежедневно, и вся команда получает уведомления и может видеть статус тестов последней интегрированной сборки. Неисправности выявляются незамедлительно и устраняются в срочном порядке.

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

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

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

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

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

Тестовые среды системного уровня

Тестирование на системном уровне фокусируется на совместной интеграции компонентов и подсистем. 

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

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

Одна из наиболее распространенных ошибок при тестировании заключается в том, что системный тестер в своей среде испытывает какой-то сбой, но, как бы он ни старался, разработчик или тестировщик не может воспроизвести сбой в среде разработки.

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

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

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

Инфраструктура как код и автоматизированная подготовка среды оставят проблемы согласованности среды в прошлом.

Типы выделенных тестовых сред

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

• (Функциональная) Среда тестирования системы. В этой среде система проверяется на соответствие требованиям, документально оформленным для системы в целом. Требования могут быть большими текстовыми документами с табличными наборами тестовых случаев, определенных для системного теста. В гибких проектах эта среда может быть необходима, чтобы позволить тестировщикам исследовать интегрированную систему, не ограничивая себя конкретными функциями.
• Сквозная тестовая среда. Если среда CI позволяет интегрировать компоненты с подсистемами, бизнес-процессы могут потребовать наличия других взаимодействующих систем (не находящихся под контролем разработчиков). Полноценные среды необходимы для проведения крупномасштабной интеграции, а также бизнес-процессов или общего приемочного тестирования. Обычно данные представляют собой копию живых или, по крайней мере, соответствующего масштаба. Там, где необходимо доказать крупномасштабную интеграцию, потоки данных и управление осуществляются с использованием более длительных пользовательских циклов и независимой сверки данных в интегрированных системах.
• Среда производительности. Эти среды должны обеспечивать значимую платформу для оценки производительности системы (или выбранных подсистем). Компромиссы в архитектуре возможны при наличии избыточных или клонированных серверов. Но объемы данных должны соответствовать производственным масштабам, даже если данные синтетические. Конечно, масштаб среды должен поддерживать объемы производственных транзакций, чтобы можно было сделать полезный прогноз производительности систем в производственной среде.
• Среды доступности, отказоустойчивости, управляемости (ARM). В некоторых отношениях эти среды аналогичны средам производительности, но в зависимости от цели тестирования вариации могут быть неизбежны. Цель тестирования доступности — убедиться, что система может работать без сбоев в течение длительного периода времени. Тестирование отказоустойчивости (часто называемое тестированием отказоустойчивости) проверяет, что компоненты системы в случае их отказа не вызывают неприемлемого нарушения работы предоставляемого сервиса. Тестирование управляемости или операций направлено на демонстрацию эффективности системного администрирования, управления, резервного копирования и восстановления.

Данные в средах

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

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

• Локальные, созданные вручную небольшие данные, подходящие для специального тестирования разработчиками или тестировщиками.
• Локальные, автоматизированные, синтетические данные. Подходит для автоматизированных тестов разработчиков или сред, в которых можно охватить функциональность определенных модулей или функций.
• Общие, созданные вручную данные. Используется в средах интеграции и системного тестирования, часто там, где тестовые данные развивались параллельно с ручным запуском тестов. Резервное копирование и восстановление при необходимости.
• Общие, автоматически созданные данные. Используется в средах интеграции и системного тестирования, где тестовые данные развивались параллельно с автоматическими или ручными тестами. Генерируется и/или восстанавливается из резервных копий, когда это необходимо.
• Совместно используемые крупномасштабные синтетические/случайные данные. Для тестирования производительности и ARM требуются согласованные данные в большом объеме. Эти данные обычно не должны быть осмысленными — рандомизированные данные прекрасно работают и генерируются по мере необходимости или генерируются изначально и восстанавливаются из резервных копий.
• Делились крупномасштабными значимыми данными. Для сквозного, приемочного или пользовательского тестирования обычно требуются значимые данные в масштабе. Иногда используются копии или выписки из живых данных. Однако будьте осторожны, вы не нарушите правила использования данных, если не зашифруете/не анонимизируете их.
• Повторное тестирование и регрессионное тестирование. Вам потребуется известный контролируемый набор данных в известном состоянии, поэтому его обычно восстанавливают из резервных копий. Это относится к любой из вышеперечисленных сред, поскольку эти тесты необходимо повторно запускать с данными в известном состоянии, чтобы надежно воспроизвести сбои.

Тестирование инфраструктуры

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

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

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

• Изменения, направленные на устранение сбоев в инфраструктуре, могут потребовать значительных изменений в нашем приложении.
• Результаты тестирования нашего приложения или всей системы необходимо будет повторить.
• Если ^{сторонние} компоненты, такие как база данных, веб-службы, сетевые службы или службы обмена сообщениями, выходят из строя, мы оказываемся во власти поставщиков (или сообщества открытого исходного кода), которые их поддерживают.

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

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

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

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

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

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

Цели производительности и ARM могут быть известны, и в этом случае можно выполнить тесты, чтобы убедиться, что эти цели выполнены.

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

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