Тестирование — 10 инструментов

 

 

->

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

Инструменты для тестирования

Инструменты, имеющие отношение к тестированию, удобно разделить на три типа:

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

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

Веб-сайт также объединяет и индексирует более 300 блоггеров, а более 52 000 блогов также индексируются и доступны для поиска. Мы предоставили URL-адреса основных категорий инструментов и ярлыки для поиска по этим категориям в блогах.

Существует более 1700 инструментов для совместной работы, тестирования и DevOps.

Далее в этой статье мы рассмотрим основные проблемы, влияющие на управление тестированием и поддерживающие его.

Архитектура инструментов

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

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

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

Вам не обязательно быть культурой DevOps, чтобы использовать инструменты «DevOps».

Управление тестированием

Инструменты управления тестированием необходимы во всех масштабных проектах. Agile-проекты обычно используют инструмент для управления инцидентами и, что касается тестов, в некоторой степени полагаются на использование бизнес-историй и сценариев для отслеживания ключевых примеров, если не всех, тестов. Инструменты управления тестированием различаются по объему от очень простых, например, Microsoft Excel, до комплексных продуктов для управления жизненным циклом приложений (ALM).

В целом область применения инструментов управления тестированием охватывает несколько областей:

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

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

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

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

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

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

Самым популярным инструментом управления тестированием на планете по-прежнему остается Microsoft Excel.

Дизайн теста

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

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

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

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

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

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

Собственный или с открытым исходным кодом?

За последние двадцать лет широкое распространение получило использование бесплатного программного обеспечения с открытым исходным кодом (FOSS), особенно для запуска инфраструктуры. Стоимость лицензий на операционную систему и соответствующее программное обеспечение веб-сервера от Microsoft, а также общее мнение о том, что Linux/Unix более надежна и безопасна, чем Windows, означает, что для многих сред Linux/Unix является предпочтительной операционной системой для серверов.

Две приведенные ниже таблицы (обновляемые ежедневно на w3techs.com) показывают относительную популярность операционных систем и продуктов для веб-серверов. Около 85% сайтов используют самые известные продукты веб-серверов с открытым исходным кодом, Apache и Nginx.

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

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

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

	Собственный	ФОСС
Доступность	Инструменты доступны для каждой области.	Некоторые области, особенно средства разработки и инфраструктуры, поддерживаются лучше, чем другие.
Стоимость покупки	Часто дорогие, особенно продукты для предприятий.	Бесплатная или общедоступная лицензия с нулевой стоимостью. Коммерческие лицензии могут существовать для корпоративных или размещенных версий.
Документация	Обычно очень хорошо.	Варьируется. Иногда отличный, иногда несуществующий и все между ними. Часто пишется программистами для программистов, поэтому менее полезна, чем коммерческая документация.
Техническая поддержка	Очень хорошо, по стоимости.	Варьируется. Некоторые авторы инструментов предоставляют отличную поддержку и даже добавляют функции по запросу. У многих инструментов есть онлайн-форумы, но они могут быть очень техническими. Другие инструменты плохо поддерживаются.
Надежность/качество	Обычно очень хорошо.	Переменная. Продукты со многими пользователями, локалями, большими командами поддержки, как правило, превосходны. Некоторые инструменты, написанные людьми с небольшим количеством участников и пользователей, могут быть ненадежными.
Богатство функций	Наборы функций, как правило, соответствуют опубликованным дорожным картам продуктов и обычно являются исчерпывающими.	Продукты имеют тенденцию развиваться в зависимости от пользовательского спроса и размера команды участников. Участники, как правило, добавляют функции, которые им нужны, а не на основе, например, опросов клиентов.
Частота выпуска/исправления	Крупные релизы, как правило, выходят через месяцы, а иногда и через годы. Регулярные выпуски патчей. Предупреждения и примечания к выпуску, как правило, очень хороши.	Варьируется. Основные выпуски крупных инфраструктурных продуктов — например, проприетарные. Меньшие по размеру и менее популярные продукты, как правило, выпускаются чаще. Небольшое предупреждение или его отсутствие, плохие примечания к выпуску и временная потеря обратной совместимости.

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

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

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

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

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

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

Упражнение по выбору инструмента

Если вы ищете инструмент управления тестированием для поддержки вашего текущего или знакомого, недавнего проекта и приложения. Основываясь на функциональных областях, описанных выше при обсуждении инструментов управления тестированием, составьте список из 15-20 функций, которые:

• Обязательный
• Желаемый

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

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

• Как инструменты складываются с точки зрения функций?
• Какие функции отсутствуют в инструментах FOSS по сравнению с проприетарными инструментами?
• Сколько существует инструментов, которые в целом соответствуют вашим требованиям?
• Как вы думаете, сколько времени вам потребуется потратить на изучение инструментов, чтобы составить краткий список, скажем, из трех?