Тестовые системы: Системное тестирование — Википедия – Тестирование программного обеспечения — Википедия

Содержание

Лучшие системы управления тестированием 2019

Оригинальная публикация

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

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

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


Что мы хотим от системы управления тестированием?

Пользователь системы управления тестированием ожидает увидеть следующее:

  • Удобная установка и поддержка.
  • Создание и управление проектами.
  • Создание пользователей и ролей пользователей.
  • Удобная интеграция с автоматическими тестами.
  • Создание тест-плана.
  • Создание тест-кейса.
  • Прогон тест-кейса.
  • Понятная система отчётности.
  • Встроенная система баг-трекинга.
  • Возможность интеграции с другими инструментами.

Зачем она нужна?

Решить задачу создания единой системы для работы со всей документацией проекта можно несколькими способами:

  • Самый дешёвый способ — не заморачиваться и выбрать Google Docs для матрицы трассируемости, а дефекты вести в open-source баг-трекере.
  • Другой способ — использовать одну из популярных TMS'ок, интегрированную с баг-трекером компании.
  • Next-level способ — выбрать Test Management System, исходя из специфики проектов, объемов задач, типов документации и используемых видов тестирования.

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

Популярные системы управления тестированием

  • Test Link
  • Test IT
  • Zephyr
  • qTest
  • PractiTest
  • TestLodge
  • TestRail
  • Qase
  • Tematoo
  • Test Collab
  • HP ALM
  • Testuff
  • XQual

Давайте рассмотрим выбранные инструменты более пристально.

1. TestLink

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

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

Возможности:

  • Управление требованиями
  • Спецификация — определение тест кейсов путём группировки в разные наборы тестов
  • Назначение выполнения тест сьютов на уровне сборки
  • Централизованное управление пользователями и ролями
  • Кастомизация настраиваемых пользователем полей

Ссылка на код (GitHub)
Ссылка на скачивание

2. Test IT

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

Разработчики приложения уделяют большое внимание автоматизированному тестированию, каждый тестовый случай в библиотеке тестов можно интегрировать с автотестами по API. Правильно настроенная интеграция с автотестами позволяет следить за прогонами и их результатами прямо из TMS в режиме реального времени. Вы сможете видеть какие автоматические тесты в процессе выполнения, анализировать их результаты и просматривать исходный код прямо из Test IT.

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

Возможности:

  • Управление тест-планами, тест-кейсами и чек-листами
  • Общие шаги для повторяющихся действий
  • Автоматическое распределение тестов на QA инженеров
  • Интеграция автоматических тестов с помощью API
  • Аналитика как по автоматическим, так и по ручным тестам
  • Ролевая модель и персонализация
  • Геймификация
  • Двусторонняя интеграция с JIRA
  • Импорт из других систем управления тестированием


Бесплатная пробная версия: Открытая демо-версия на сайте
Ссылка на скачивание


3. Zephyr

Zephyr — это плагин для всем известной JIRA, который интегрирует тестирование в проектный цикл, позволяя вам отслеживать качество программного обеспечения и принимать решения в стиле go / no-go. Тест кейсы могут создаваться, выполняться и трекаться так же, как и любые другие задачи в JIRA. Для более оптимальной фиксации процесса тестирования есть интеграция с инструментами управления качеством, автоматизации, непрерывной интеграции и аналитики.

Кроме того, у продукта быстро отвечающая тех поддержка.

Возможности:

  • Ссылка на user stories, задачи, требования, дефекты
  • Конфигурации деплоя: в облаке, на сервере, в дата-центре
  • Расширенная информация на дашбордах аналитики и DevOps
  • Интеграция с JIRA, Confluence, Selenium, Jenkins и Bamboo

Бесплатная пробная версия: 30 дней
Ссылка на скачивание

4. qTest

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

Разработчики нескромно заявляют, что их инструмент управления тестами №1
Согласно анализу рынка, qTest является одним из самых быстрорастущих решений для управления тестированием среди команд Agile Development.

Возможности:

  • Планирование тестов
  • Создание и управление требованиями
  • Интуитивный drag-n-drop интерфейс
  • Комплексная матрица трассируемости
  • Наглядные отчёты с подробными графиками
  • Интеграция со сторонними инструментами баг-трекинга
  • Детальный контроль доступа пользователей
  • Облачный инструмент интеграции с JIRA

Бесплатная пробная версия: 30 дней
Ссылка на скачивание

5. PractiTest

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

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

Возможности:

  • Лёгкое добавление тестов новых фич в регрессионное тестирование
  • Группировка тестов на основе микросервисов, которые они охватывают, даже кросс-сервисные
  • Различное отображение информации для разных групп пользователей
  • Дашборды в реальном времени показывают состояние тестов, прогонов на этапах разработки и при деплое на продакшн
  • Интеграция с JIRA, Redmine, Jenkins, GitLab и Slack

Бесплатная пробная версия: 14 дней
Ссылка на скачивание

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

Возможности:

  • Базовый набор создания, редактирования тест плана и тест сьютов
  • Нативный интерфейс
  • Интеграция с JIRA, Redmine, Trello, Asana, GitHub и YouTrack

Бесплатная пробная версия: 30 дней
Ссылка на скачивание

7. TestRail

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

Возможности:

  • Отслеживание состояния и результатов отдельного теста
  • Сравнение результатов нескольких тестов, конфигураций и этапов
  • Отслеживание рабочей нагрузки команды для корректировки задач и ресурсов
  • Развёрнутые отчёты и метрики
  • Широкие возможности настройки, облачные или локальные варианты установки
  • Интеграция с JIRA, Redmine, YouTrack, GitHub, Jenkins, Selenium и Visual Studio
  • Удобный REST API

Бесплатная пробная версия: 30 дней
Ссылка на скачивание

8. Qase

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

Возможности:

  • Тестовый репозиторий: выстраивание тестов в логические группы
  • Составление шагов для кейсов, установка приоритета и серьёзности
  • Запуск тестовых прогоны с трекингом времени по каждому тест кейсу
  • Хранение документации по проекту
  • Автоматическое заведение дефектов в интегрированные трекеры
  • Интеграция с JIRA, Redmine, YouTrack и Slack
  • Объединение результатов автотестов с REST API

Бесплатно для небольших компаний
Ссылка на скачивание

9. Tematoo

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

Возможности:

  • Формирование тест сьютов по билдам и типам
  • Описание тест кейса по шагам, с возможностью прикрепить скриншот
  • Статус отдельных тестов, наборов и общий статус сборки
  • Аналитические отчёты и общий метрики по тест плану
  • Для платного плана: свой баг-трекер

Бесплатно: для команды из 1-5 человек
Ссылка на скачивание

10. Test Collab

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

Test Collab можно настроить в облаке или в вашей инфраструктуре, тут всё достаточно гибко.

Возможности:

  • Группировка тест кейсов по этапам или билдам
  • Управление требованиями
  • Переиспользование тестов
  • Настройка спринтов
  • Отчёты по результатам тестов
  • Комментирование тест кейсов
  • Интеграция с JIRA, Redmine, Bugzilla, Asana, Trello, YouTrack, GitHub

Бесплатно: 200 тест кейсов, 400 выполненных прогонов
Бесплатная пробная версия: 14 дней
Ссылка на скачивание

11. HP ALM

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

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

Возможности:

  • Общий доступ к библиотекам требований и ресурсов
  • Подробные сведения о коде, тестировании, управлении рисками и их оценке, а также о соответствии требованиям
  • Быстрый доступ к показателям, например к данным о неустранённых дефектах
  • Быстрая настройка лабораторной среды для устранения ошибок конфигурации в средах Agile
  • Создание требований и отслеживание их выполнения на всех этапах жизненного цикла приложения
  • Аналитика на любой вкус и цвет: гибко настраиваемые отчёты
  • Интеграция с 50+ инструментами

Бесплатная пробная версия: 60 дней
Ссылка на скачивание

12. Testuff

Testuff — это мощная веб-платформа управления тестированием, которая позволяет легко проектировать, выполнять и управлять неограниченным количеством тестов. Тул можно настроить под любой формат тестирования: от популярной гибкой методологии и TDD, до White-Box или Black-Box; Top-Down или Bottom-Up.

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

Возможности:

  • Два доступных клиента — Web и Desktop
  • Планирование цикла тестирования с использованием нескольких тестовых окружений
  • Разграничение по ролям пользователей
  • Встроенный захват экрана в виде скриншота или видео
  • Подключение результатов автоматизированных тестов по API
  • Интеграция с JIRA, Trello, Redmine, Bugzilla, YouTrack, Selenium, GitHub, Visual Studio

Бесплатная пробная версия: 30 дней
Ссылка на скачивание

13. XQual

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

Возможности:

  • Расширенная настройка шагов тест кейса
  • Переиспользование тестов
  • Матрица трассируемости
  • Настройка тестовой лаборатории: hardware, software, тестовое окружение
  • Продвинутое логирование действий (даже удалённых тестов)
  • Настраиваемая аналитика
  • Встроенный захват экрана
  • Интеграция с JIRA, Redmine, MySQL, Oracle, Apache, Skype
  • Интеграция с 5 различными интерфейсами для ручного тестирования
  • Интеграция с почти 70 тулами автоматизации: Selenium, QTP / UFT, JMeter, Ranorex, TestComplete, JUnit, NUnit, TestPartner, Sahi, NeoLoad, QF-Test, RobotFramework, Sikuli, SoapUi, Squish, TestNg, TestOptimal и многие другие

Бесплатно: для команды из 4-10 человек, 200 тестов
Ссылка на скачивание

Понравился пост? Не забудьте поделиться им!
И помните, мы стоим между багами и клиентом! 🙂

Обсудить в форуме

Автоматизация тестирования программных систем / Habr

Приветственное слово

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

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

Основные понятия

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

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

В свою очередь, инструмент для автоматизированного тестирования — это программное обеспечение, посредством которого осуществляется создание, отладка, выполнение и анализ результатов прогона тест-скриптов (Test Scripts — это наборы инструкций для автоматической проверки определенной части программного обеспечения).

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

Применение автоматизированного тестирования

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

Следом идёт регрессионное тестирование. Означает оно проверку ПО на корректность функциональности, выпущенной и протестированной в предыдущей версии. Выполняется с регулярной частотой, задаваемой в зависимости от условий: у кого-то с каждым новым билдом, а у кого-то с каждой версией для заказчика.

Конфигурационное тестирование – выполнение одних и тех же тестов в разных условиях. То есть когда один или несколько компонентов архитектуры системы требуется проверить в разном окружении, обычно заявленном в изначальных требованиях. Например: поддержка СУБД от разных производителей, работа в разных клиентских браузерах, использование в нескольких ОС и т.п. То есть некий аналог регрессионного тестирования, но в рамках одной версии системы.

Функциональное тестирование. Ясно, что здесь речь идёт о проверке нового функционала. Иногда бывает, что без автоматизации никак не обойтись. Даже если нужно выполнить тестирование только один раз. Обычно, впоследствии эти тесты и используются для регресса.

Установочное тестирование, выполняется для проверки условий инсталляции (и настройки) продукта с учётом тех или иных требований к системе от заказчика.

«А зачем?»

…спросит кто-то. Вопрос очень даже резонный. Тестировать, как вы понимаете, можно вручную, а можно с использованием средств автоматизации. Чтобы сделать выбор в сторону того или иного подхода, следует разобраться в его плюсах и минусах.
Какие же преимущества даёт тестировщику автоматизация? А вот какие:
  • Исключен «человеческий фактор». Сильное достоинство. Все мы люди и никто из нас не застрахован от ошибок. Выполняемый же тест-скрипт не пропустит тест по неосторожности и ничего не напутает в результатах.
  • Быстрое выполнение – автоматизированному скрипту не нужно сверяться с инструкциями и документациями.
  • Меньшие затраты на поддержку – когда скрипты уже написаны, на их поддержку и анализ результатов требуется, как правило, меньшее время чем на проведение того же объема тестирования вручную.
  • Отчеты – автоматически рассылаемые и сохраняемые отчеты о результатах тестирования.
  • Выполнение без вмешательства – во время выполнения тестов инженер-тестировщик может заниматься другими полезными делами, или тесты могут выполняться в нерабочее время.

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

Вернее даже будет сказать так: как подойти к внедрению процесса автоматизации тестирования в своей деятельности?

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

На финишной прямой

Чтобы принять окончательное решение о целесообразности применения автоматизации, обычно советуют ответить на возникающий естественным образом в данной ситуации вопрос: «превалируют ли в нашем случае преимущества над недостатками?». Если недостатки в конкретном случае неприемлемы, то от автоматизации стоит воздержаться.
Выбор инструмента

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

Логично теперь будет поближе рассмотреть некоторые популярные средства автоматизации тестирования и привести пример написания простого тест-скрипта.

HP QuickTest Professional

Средство автоматизации от кампании Hewlett-Packard. Распространяется на платной основе (8000-10000 USD). Является основным инструментом автоматизации функционального тестирования от данного производителя. Позволяет автоматизировать функциональные и регрессионные тесты через записи действий пользователя при работе с тестируемым приложением, а потом исполнять записанные действия с целью проверки работоспособности ПО.
Записанные действия сохраняются в виде скриптов.
Скрипты могут быть отображенные в инструменте как VBScript (expert view), или же как визуальные последовательные шаги с действиями (keyword view).
Каждый шаг может быть отредактирован и на него можно добавить точки проверки (checkpoint), которые сравнивают ожидаемый результат с полученным.
IBM Rational Functional Tester

Тоже платный, но не настолько («всего-то» 6000 USD).
Rational Functional Tester предоставляет тестировщикам средства автоматизированного тестирования, позволяющие выполнять функциональное тестирование, регрессивное тестирование, тестирование пользовательского интерфейса и тестирование управляемое данными.
Много описательной информации о нём не дам, а лучше приведу практический пример.
Пример использования

Будет использована интеграция IBM Rational Functional Tester со средой разработки Microsoft Visual Studio. Для создания функционального теста необходимо выполнить следующие действия:

1) В среде разработки Microsoft Visual Studio создать новый проект «Functional Test Project»:

2) Выполнить запись пользовательских действий с тестируемым приложением:

3) Создать проверочную точку в процессе выполнения записи. Проверочная точка также будет выполнять проверку значения в выпадающем списке:

4) Сохранить результаты записи:

Далее необходимо сформировать bat-файл, который будет вызывать скрипт тестирования на выполнение и проверять результат:
rational_ft.exe -datastore “<путь к каталогу проекта VS>\DemoTestRFT” -playback uml2cqtestscript
findstr failed “<путь к каталогу проектаVS>\DemoTestRFT_logs\uml2cqtestscript\rational_ft_logframe.html”
if %errorlevel% == 1 goto end
exit -1
:end
exit 0

Bat-файл выполняет следующие действия:
Вызывается IBM Rational Functional Tester со следующими параметрами:
-datastore “<путь к каталогу проекта VS>\DemoTestRFT” – путь к каталогу с проектом.
-playback uml2cqtestscript – выполнить скрипт тестирования.
IBM Rational Functional Tester записывает свои результаты в отчет в формате HTML. Для того, чтоб определить был ли провален хоть один шаг в процессе выполнения скрипта тестирования, необходимо найти слово «failed» в отчете.
В зависимости от результата поиска возвращается результат 0 или -1.

Результат выполнения

Selenium

А это уже бесплатный пакет от компании OpenQA.org.
В основе Selenium лежит среда для тестирования web-приложений, реализованная на JavaScript и выполняющая проверки непосредственно средствами браузера. В рамках проекта Selenium выпускается 3 инструмента, каждый из которых имеет свои особенности и область применения: Selenium Core, Selenium IDE, Selenium RC и Selenium GRID.
Поддерживаемые технологии: DHML, JavaScript, Ajax
Поддерживаемые ОС: Mac OS, Microsoft Windows, Linux, Solaris
Язык тестов: HTML, Java, C#, Perl, PHP, Python, и Ruby
Тестируемые приложения: веб-приложения.

Тестирование систем в TPC-C — быстро и просто / DataLine corporate blog / Habr

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

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

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

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

Для начала вспомним, какие бывают синтетические тесты. Для процессоров подойдет 7-Zip Benchmark, для дисков — CrystalDiskMark. С их помощью мы можем очень быстро посмотреть, насколько быстро работает наш стенд на алгоритмах, заложенных в эти (!) тесты. Штука в том, что в нашей системе, для которой предназначен стенд, точно будут использоваться другие алгоритмы. И с этим приходится как-то жить.

Для более точных результатов тестирования дисков есть SQLIO или FIO. Обязательно прочитайте две исторические статьи amarao о тестировании дисков — раз и два, и свежую статью коллеги. По этим статьям вы научитесь правильно применять этот сложный тест.

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

Так как большинство бизнес-систем, для которых критична производительность, являются реляционными базами данных, то для нас наибольший интерес представляет тест TPC-C. Это комплексный тест, генерирующий многопользовательскую OLTP нагрузку из различных транзакций. Для его прохождения в базе данных генерируется набор данных, характерный для бизнес-систем, связанных с продажами или производством товаров и сервисов. TPC-C можно дополнить тестом TPC-H для эмуляции нагрузки OLAP системы.

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

Для проведения TPC-C теста мы будем использовать Open source проект HammerDB.

Параметры виртуальной машины для тестирования:

  • 4 vCPU 3ГГц,
  • 64 ГБ оперативной памяти,
  • диск на общей СХД с SSD дисками.

Почему такие параметры? Меньшее число процессоров на серверах с СУБД бывает редко, памяти для СУБД много не бывает, ну а на жесткие диски ее класть — себе дороже.

Установленное на машину ПО:

  • Microsoft Windows 2016 x64,
  • Microsoft SQL Server 2017 (не Express edition; или же следим за максимальным объемом базы данных),
  • SQL Server Management Studio,
  • и собственно HammerDB.

Конечно, можно разнести HammerDB и SQL сервер на разные ВМ/сервера для изоляции нагрузки пользователей от нагрузки сервера, что довольно правильно. Но в другой раз.

А теперь начнем тест.

  1. Первым шагом с помощью SQL Server Management Studio создаем базу данных для тестов и размещаем ее на отдельном диске — так у вас будет выше карма.
  2. Далее запускаем HammerDB.
    1. Выбираем MS SQL, TPC-C.
    2. Заполняем параметры подключения к MS SQL:
      • количество складов: можно начать с десяти, но для реальных тестов нужно, например, 2000,
      • количество виртуальных пользователей: удвоенное количество наших процессоров.
    3. Жмем Ок и ждем.

  3. Наша база данных наполняется данными, растет. Для 2000 складов размер базы данных на диске — порядка 250 ГБ.

  4. После того, как база заполнилась (это может занять несколько часов), нам нужно сгенерировать Driver Script — сценарий тестирования.
    1. Задаем условия:
      • ограничение теста во времени — 20 минут,
      • время «разгона» теста — 5 минут. Это ограничение нужно, чтобы не «положить» систему резким стартом.

    2. Жмем Ok и переходим в Load.


    Наш тестовый скрипт готов.
  5. Переходим в Virtual Users и задаем количество пользователей.


    В нашем случае — 200 пользователей, но вообще рекомендуется выставлять в 10 раз меньше пользователей, чем складов.

    Здесь же выбираем Show Output, чтобы результаты теста были видны в момент его работы, и Log Output to Temp для  генерации текстового файла с результатами теста.

    Нажимаем Create, Run!


    У наших Virtual Users изменился статус.

  6. Переходим на Transaction Counter и смотрим, запустился ли наш тест.
    Ура, все очень просто — и тест работает!

    Вот так отображаются результаты теста после запуска.

  7. Ждем 5 минут. Нагрузка приходит к плановой; показатели, в моем случае, улучшились.
  8. Теперь посмотрим на результаты со стороны виртуализации. И вот что мы видим.
    • Процессоры ВМ во время теста были нагружены практически на 100%:
    • Память использовалась довольно активно:
    • В дисковых операциях преобладало чтение, задержки на ожидаемом уровне:

Итак, все довольно просто и теперь у нас есть ВМ с эталонным тестом. Перемещая ее по различным стендам, мы можем оценить их относительную производительность.

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

Кому-то этот текст может показаться очень простым. Но я еще не встречал на русском языке ответа на вопрос: «Как мне измерить производительность нашей системы в TPC-C?» Enjoy! 🙂

НОУ ИНТУИТ | Лекция | Системное тестирование

Аннотация: Лекция является последней из трех рассматривающих уровни процесса верификации. Тема данной лекции - процесс системного тестирования, его задачи и цели. Рассматриваются виды системного тестирования, особенности системного тестирования и испытаний при разработке сертифицируемого программного обеспечения. Цель данной лекции: дать представление о процессе системного тестирования, его технической и организационной составляющих

22.1. Задачи и цели системного тестирования

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

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

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

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

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

22.2. Виды системного тестирования

Принято выделять следующие виды системного тестирования:

  • функциональное тестирование;
  • тестирование производительности;
  • нагрузочное или стрессовое тестирование;
  • тестирование конфигурации;
  • тестирование безопасности;
  • тестирование надежности и восстановления после сбоев;
  • тестирование удобства использования.

В ходе системного тестирования проводятся далеко не все из перечисленных видов тестирования - конкретный их набор зависит от тестируемой системы.

Исходной информацией для проведения перечисленных видов тестирования являются два класса требований: функциональные и нефункциональные. Функциональные требования явно описывают, что система должна делать и какие выполнять преобразования входных значений в выходные. Нефункциональные требования определяют свойства системы, напрямую не связанные с ее функциональностью. Примером таких свойств может служить время отклика на запрос пользователя (например, не более 2 секунд), время бесперебойной работы (например, не менее 10000 часов между двумя сбоями), количество ошибок, которые допускает начинающий пользователь за первую неделю работы (не более 100), и т.п.

Рассмотрим каждый вид тестирования подробнее.

Функциональное тестирование. Данный вид тестирования предназначен для доказательства того, что вся система в целом ведет себя в соответствии с ожиданиями пользователя, формализованными в виде системных требований. В ходе данного вида тестирования проверяются все функции системы с точки зрения ее пользователей (как пользователей-людей, так и "пользователей" - других программных систем). Система при функциональном тестировании рассматривается как черный ящик, поэтому в данном случае полезно использовать классы эквивалентности. Критерием полноты тестирования в данном случае будет полнота покрытия тестами системных функциональных требований (или системных тест-требований) и полнота тестирования классов эквивалентности, а именно:

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

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

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

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

Все требования, относящиеся к производительности системы, должны быть четко определены и обязательно должны включать в себя числовые оценки параметров производительности. Т.е., например, требование "Система должна иметь приемлемое время отклика на запрос пользователя" является непригодным для тестирования. Напротив, требование "Время отклика на запрос пользователя не должно превышать 2 секунды" может быть протестировано.

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

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

Системное тестирование программного обеспечения

Уважаемый пользователь! Реклама помогает поддерживать и развивать наш проект, делая его простым и удобным специально для Вас. Если проект интересный и важный для Вас, то отключите на нем блокировщик рекламы. Спасибо, что читаете сайт!

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

  • на базе требований (requirements based) - для каждого требования пишутся тестовые случаи (test cases), проверяющие выполнение данного требования.
  • на базе случаев использования (use case based) - на основе представления о способах использования продукта создаются случаи использования системы (Use Cases). По конкретному случаю использования можно определить один или более сценариев. На проверку каждого сценария пишутся тест кейсы (test cases), которые должны быть протестированы.

Уважаемый пользователь! Реклама помогает поддерживать и развивать наш проект, делая его простым и удобным специально для Вас. Если проект интересный и важный для Вас, то отключите на нем блокировщик рекламы. Спасибо, что читаете сайт!

Тестирование распределенных систем, — интервью с Андреем Сатариным, Яндекс


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

Я пообщался со спикером конференции Heisenbug 2016 Moscow Андреем Сатариным (twitter.com/asatarin). Андрей участвовал в проектах по тестированию в Mail.ru, в Лаборатории Касперского, в Deutsche Bank, а сейчас тестирует распределенные системы в Яндексе. Статья будет полезна не только людям, которые занимаются тестированием, но и разработчикам. Если вы ни разу не касались вопроса тестирования распределенных систем, добро пожаловать под капот.

Андрей Сатарин:

… они убивают ноды прямо в рабочее время и разработчики наблюдают за...

Способы и особенности тестирования распределенных систем


– Какие методики и стратегии тестирования распределенных систем существуют? Чем они отличаются?

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

Очень популярен подход внедрения сбоя (fault injection). Когда система работает, мы при помощи специальных программ и механизмов добавляем сбои: сбои дисков или целых машин, может быть, сетевые сбои, сбои внутренних компонентов тестируемой системы. Поскольку подавляющее большинство распределенных систем должны обладать устойчивостью к подобного рода сбоям, по крайней мере в каких-то ограниченных масштабах, то система не должна прекращать свою работу или проявлять каких-то аномалий в работе. По сути это тестирование на отказоустойчивость, поскольку это одно из важнейших нефункциональных требований к распределенным системам. Чем больше машин работает, тем выше вероятность индивидуальной проблемы на какой-то из них. Например, если задействована тысяча машин, то, условно говоря, диски будут вылетать раз в неделю. Система обязана переживать такие ситуации никоим образом их не замечая.

Есть более академические подходы, например, формальная верификация (formal verification). В распределенных системах есть внутренние алгоритмы и протоколы, которые позволяют ей работать. Они сами по себе достаточно сложные, но гарантируют некоторые инварианты, которые должны достигаться всегда, независимо от каких-либо сбоев в системе, переупорядочивания пакетов в сети и чего-либо ещё. Суть подхода заключается в том, что на основе только описания алгоритма на специальном языке проверяется его корректность. Это дает уверенность в том, что тот алгоритм, который используется, при условии, что он корректно реализован, будет работать.

В 2015 году вышла академическая статья от Microsoft Research «Proving Practical Distributed Systems Correct», где они описали модель системы распределенного хранилища, после чего с помощью специальных инструментов проверили эту модель на корректность, а затем сгенерировали код, который сразу же заработал.

– Какие особенности необходимо учитывать при тестировании распределенных систем?

– Особенность в том, что важно понимать какие именно инварианты гарантирует тестируемая система. Например, сейчас популярны nosql базы данных, которые могут быть более высокопроизводительными, но они не поддерживают транзакции. То есть их уровень консистентности ниже, чем у классических (MySql, PostgreSQL, Oracle). И, когда происходит тестирование такой распределенной системы, типа nosql базы данных, важно, чтобы было понимание какие именно инварианты она поддерживает. От этого зависят аномалии, которые будут наблюдаться в тестах. В сложных тестах, например, когда есть несколько конкурентных писателей и читателей, можно увидеть много различных состояний. Другими словами, нужно понимать, какие эффекты можно наблюдать в системе, а какие — нет.

Нефункциональные требования играют наиболее существенную роль


– Какие типичные ошибки совершают сами люди при тестировании распределенных систем?

– Самая распространенная ошибка — это проверка не всех гарантий, которые система должна предоставлять, в этом случае система становится недотестирована. Вторая ошибка, которая может дорого стоить, это не тестирование на отказ какой-то части системы. По опыту, если в распределенной системе какая-то подсистема не тестировалась на fault injection, то багов там чуть более, чем очень много.

– Какие метрики и характеристики распределенной системы важно тестировать и почему?

– Из нефункциональных требований это, во-первых, отказоустойчивость (fault tolerance), а во-вторых, это производительность (perfomance). Для распределенных систем нефункциональные требования играют наиболее существенную роль по сравнению с функциональными требованиями. Fault tolerance на первом месте, потому что сначала система должна работать, а если она не работает, то остальное уже не так важно.

– Насколько важна производительность тестов? Нужно ли учитывать возможные задержки сети при разработке тестов для распределенной системы?

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

98% всех дефектов можно воспроизвести всего лишь на 3 нодах


– Нужно ли создавать специальные кластера для тестирования или можно использовать «боевые» кластера, которые находятся в продакшене? Как определить оптимальный размер тестового кластера?

– Чаще всего применяют именно тестовые кластера. Если говорить про тестирование на боевых серверах, то самый широко известный пример — это компания Netflix, которая активно пропагандирует свой подход, называемый «simian army», то есть «армия макак». Он заключается в том, что они в продакшене делают fault injection. Они убивают ноды прямо в рабочее время и разработчики наблюдают за тем, чтобы система никак при этом не деградировала. Но здесь надо понимать, что такая возможность появляется только начиная с какого-то масштаба. Если система работает на 10-20 нодах, то тестирование подобным образом означает, что будет деградация на 5-10%. В продакшене не все готовы на такие жертвы. Кроме того, может быть какой-то service level agreement (SLA) и такое тестирование может быть дорого из-за его нарушения. В любом случае, даже если встречается практика тестирования на продакшене, то существует перед этим огромная тестовая инфраструктура, которая отлавливает большую часть дефектов. Преимущество тестирования в продакшене только в том, что нет необходимости повторять продуктивное окружение.

По поводу размера тестового кластера. Если система распределенная, то он должен быть больше единицы — это ограничение снизу. На тему ограничений сверху есть статья «Simple Testing Can Prevent Most Critical Failures», в которой исследуется вопрос о том, какие ошибки есть в распределенных системах. Согласно статье, исследователи пришли к выводу, что 98% всех дефектов можно воспроизвести всего лишь на 3 нодах. Конкретно в нашей работе мы используем больше, обычно тестовый кластер состоит из 8 нод, но это связано с внутренним устройством нашей системы.

– Как бороться с полными или частичными отказами распределенной системы во время тестирования?

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

– Какие конкретно технологии и инструменты используются для создания тестового окружения? Для автоматизации тестирования?

– Тестовое окружение зависит от технологий, которые используются для разработки, и от технологий, которые знакомы команде. Мы, например, активно используем Python, потому что он хорошо подходит для таких задач и наши тестировщики его знают. Он простой в плане написания тестов, достаточно высокоуровневый, чтобы на нем можно было писать понятно. На мой взгляд, у него немного «беда» с concurrency, но эта проблема решаема. Сама система разрабатывается на C++, но его использовать для высокоуровневых тестов достаточно тяжело, так как быстро и легко разрабатывать на нем не получится, а в тестах бывает важна скорость разработки.

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

– У тебя есть еще что-нибудь, что ты бы хотел добавить по теме?

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



Послушать больше докладов на тему тестирования можно будет 10 декабря в гостинице «Radisson Славянская» на конференции Гейзенбаг. Регистрация еще открыта.

Темы докладов:

Немного о простом. Тест-дизайн. Часть 1 / Habr

Сегодня тестирование ПО, один из ключевых процессов создания продукта. Неважно, какую Вы используете методологию, подход, процесс, тестирование ПО так или иначе всегда существует в Вашем процессе. В последние годы (да даже наверное десятилетие) тестирование ПО сформировалось в отдельную область ИТ, которая постоянно развивается в мировом сообществе.

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

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

Почему?

Потому что тестировщики ничего не делают, им не нужны знания. Тестировать может каждый!

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

Hard skills всегда можно научить, а вот soft skills к сожалению научить очень сложно, потому что это характер человека, его отношение к чему-либо и т.д. Обычно я косо смотрю на руководителей, которые набирают себе специалистов по ручному тестирования по hard skills. Зачем Вы это делаете??? (ответы можете оставить в комментариях) Ну да ладно, продолжим:)

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

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

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

И в этом цикле статей поговорим об этом.

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

Выглядит это так:

  • Зачем нам нужны техники тест-дизайна?
  • Чтобы правильно определить проверки для тестирования.
  • А используете ли Вы их в работе?
  • В явном виде нет, мы сами определяем то, что нужно проверить.

Почему так происходит? Ведь техники тест-дизайна – это основа составления сценариев тестирования. Это тоже самое, что уметь водить машину, но при этом не знать ПДД. Почему же тестировщики не применяют их в работе?

Ответ прост.

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

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

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

  • Анализ требований и рисков тестирования
  • Определение проверок для тестирования
  • Формализация проверок в виде тестовых сценариев
  • Приоритезация проверок
  • Определение подходов к тестированию

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

Итак, начнем.

А начнем мы с самого простого, а именно о 2-х основных техниках тест-дизайна, про которые все слышали, и я уверен, применяли, но скорее всего на интуитивном уровне в своей работе.
Это классы эквивалентности и граничные значения.

Что же такой классы эквивалентности?

Класс эквивалентности (Equivalence class) – это набор входных (или выходных) данных ПО, которые обрабатываются программой по одному алгоритму или приводят к одному результаты.

То есть, это некое множество значений, которое вы можете подставлять в программу и получать один и тот же результат. Результатом можем быть не только конкретные значения, действия программы, но и просто область применения. Поэтому, самые простые классы эквивалентности, на которые делятся проверки, это 2 основных класса: позитивные и негативные сценарии.

Они есть всегда. Каждый тестировщик делит проверки на эти классы, но не каждый тестировщик знает, почему он это делает. Ответ – классы эквивалентности.

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

Рассмотрим пример:

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

  • От 18 до 25 лет – 18%
  • От 25 до 45 лет – 16 %
  • Свыше 45 лет – 20%

Мы определяем 2 основных класса – это позитивные и негативные сценарии.

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

Далее мы делим класс позитивных сценариев 3 класса вводимых значений 18-24, 25-44 и 45 +

В классе негативных сценариев мы формируем значения, исходя из необходимости проверки отказов программы, поэтому мы имеем 0, 1-17, отрицательные значения, ввод символов и т.д.

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

Итого мы имеем.

  • Позитивные проверки: Ввод значений: 19, 30, 48 (значения могут быть любыми из данного диапазона класса)
  • Негативные проверки: 0, 3, -1, А и т.д.

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

Еще одна особенность классов эквивалентности – это их применение. Я выделяю 3 уровня применения техник тест-дизайна для подготовки к тестированию.

  • Первый уровень – проверка элементов системы (например, полей, чекбоксов, кнопок и т.д.)
  • Второй уровень – проверка логики работы системы при комбинации данных в элементах системы
  • Третий уровень – проверка бизнес- процесса системы и логики работы программы.

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

Неотъемлемой часть проверки любого элемента является другая техника – граничные значения.

Граничные значения дополняют эквивалентные классы, тем самым полностью покрывая проверки элемента ПО.

Граничные значения – техника тест-дизайна, которая дополняет классы эквивалентности дополнительными проверками на границе изменения условий.

Вроде все просто!

Вернемся к нашему примеру ранее.

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

  • От 18 до 25 лет – 18%
  • От 25 до 45 лет – 16 %
  • Свыше 45 лет – 20%

Что же здесь будет границей?

Если вы подумали о длине поля на страничке Хабры, или об отпуске в теплых странах, хочу вас расстроить, это не так 🙂

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

Поэтому, помимо граничного значения мы используем для тестирования дополнительно 2 значения, значение перед границей и значение после границы.

В итоге мы имеем:

Границы наших классов: 17, 18, 19, 24, 25, 26, 44, 45, 46 и max.

Также, у нас есть негативный класс, это от 0 до 18. Поэтому тут мы тоже должны использовать для тестирования граничные значения: -1, 0, 1, 17,18

Далее исключаем повторяющиеся значения, и получаем значения для проверки элемента ввода данных.

-1, 0, 1, 17, 18, 19, 24, 25, 26, 44, 45, 46, max.

Значение max обычно уточняется у Заказчика или аналитика. Если не могут предоставить, то следует бросить его и не проверять необходимо подобрать значение, соответствующее здравому смыслу (вряд ли кто-то придет за кредитов в возрасте 100 лет).

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

Если ранее у нас были 3 значения для 3-х классов, 19, 30 и 48, то после определения граничных значений, мы можем исключить из списка значения 30 и 48 и заменить их предграничными значениями, такими как 26 (вместо 30) и 46 (вместо 48).

Граничные значения определяются не только для числовых значений, но и для буквенных (например, границы алфавита и кодировки), даты и времени, смысловых значений. Граница числовых значений зависит от формата ввода, если у вас целые числа, например, 2, то граничные значения будут 1 и 3. Если дробные значения, то границы для числа 2 уже будут 1,9 (1,99) или 2,1 (2,01) и т.д.

Техники тест-дизайна 1-го уровня достаточно просты и понятны. Я думаю, вы скажете, да это легко, но зачем досконально проверять каждый элемент. И будете правы!..

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

Что ж, слишком легко??? Сейчас начнем разбирать более сложные техники, готовьтесь.

Техники тест-дизайна 2-го уровня отвечают за вариативность и комбинаторику данных при проверке ПО.

Основной техникой тест-дизайна parwise testing (попарное тестирование). Суть техники заключается в минимизации вариативности комбинаций проверок, достаточных для обеспечения высокого качества ПО.

Простыми словами, в данной технике применяется правило Парето, 80 % качества можно достичь всего 20% проверок комбинаций данных.

Данная техника была выведена путем более 15-тилетнего исследования IEEE в области анализа причин возникновения дефектов в системе. Результаты исследования показали, что 98% всех дефектов возникают при конфликте ПАР входных данных или ОДНОГО входного параметра.

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

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

Пусть выпадение значения 2 – это дефект, тогда вероятность появления дефекта при кидании кубика равна 1/6=0,167.

Если мы бросаем 2 кубика, то вероятность выпадения 2-х двоек (2 дефекта) становиться ниже и равна 0,167*0,167 = 0,028, для 3-х уже 0,005 и т.д.

Получается, что вероятность возникновения дефекта при комбинации 3-х и более параметров настолько мала, что ее можно отбросить.

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

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


Если мы внимательно посмотрим, то увидим с Вами пять полей заполнения данных:
  • ФИО
  • Дата рождения
  • Мобильный телефон
  • Серия номер паспорта
  • Электронная почта,
  • а также 2 чек-бокса.

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

Очень ВАЖНО, при использовании техники попарного тестирования, мы не говорим о результате тестирования. Нам важно проверить вариативность данных при заполнении заявки.

Итак,

Поле ФИО может принимать значения (классы):

  • ФИО на русском
  • Невалидное значение
  • Пустое значение

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

Идем дальше, дата рождения, также как и мобильный телефон, серия и номер паспорта можем иметь тоже 3 состояния:

  • Валидное значение
  • Невалидное значение
  • Пустое значение

Т.к. электронная почта необязательно, то данное поле имеет 2 значения:
  • Валидное значение
  • Невалидное значение

Чек-боксы обычно имеют всего 2 состояния – Y или N.

Чтобы проверить все комбинации данной формы нам бы понадобилось сделать свыше 1000 тестов, но используя попарное тестирование нам достаточно всего 9 тестов!
Магия, не думаю:)

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

Мы берем ФИО и серия номер паспорта. Наша задача – перебрать все значения данной пары между собой:


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

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

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

Надеюсь было полезно!

Отправить ответ

avatar
  Подписаться  
Уведомление о