Конфигурационное тестирование: Про Тестинг - Тестирование

Содержание

Про Тестинг — Тестирование — Виды Тестирования ПО

Раздел: Тестирование > Виды Тестирования > Конфигурационное тестирование

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

В зависимости от типа проекта конфигурационное тестирование может иметь разные цели:

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

Проект по миграции системы с одной платформы на другую
Цель Тестирования: Проверить объект тестирования на совместимость с объявленным в спецификации оборудованием, операционными системами и программными продуктами третьих фирм.

Уровни проведения тестирования

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

Серверный

Клиентский

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

Аппаратные средства (тип и количество процессоров, объем памяти, характеристики сети / сетевых адаптеров и т.д.)

Программные средства (ОС, драйвера и библиотеки, стороннее ПО, влияющее на работу приложения и т.д.)

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

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

Тип, версия и битность операционной системы (подобный вид тестирования называется кросс-платформенное тестирование)

Тип и версия Web барузера, в случае если тестируется Web приложение (подобный вид тестирования называется кросс-браузерное тестирование)

Тип и модель видео адаптера (при тестировании игр это очень важно)

Работа приложения при различных разрешениях экрана

Версии драйверов, библиотек и т.д. (для JAVA приложений версия JAVA машины очень важна, тоже можно сказать и для .NET приложений касательно версии .NET библиотеки)

и т.д.

Порядок проведения тестирования

Перед началом проведения конфигурационного тестирования рекомендуется:

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

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

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

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

Обобщим что мы имеем

конфигурационным называется тестирование совместимости выпускаемого продукта (программное обеспечение) с различным аппаратным и программным средствами

основные цели — определение оптимальной конфигурации и проверка совместимости приложения с требуемым окружением (оборудованием, ОС и т.д.)

автоматизация конфигурационного тестирования позволяет избежать лишних расходов

Наверх

Конфигурационное тестирование — Студопедия

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

В зависимости от типа проекта конфигурационное тестирование может иметь разные цели:

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

2. Проект по миграции системы с одной платформы на другую. Цель Тестирования: Проверить объект тестирования на совместимость с объявленным в спецификации оборудованием, операционными системами и программными продуктами третьих фирм.

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

1. Аппаратные средства (тип и количество процессоров, объем памяти, характеристики сети / сетевых адаптеров и т.д.)

2. Программные средства (ОС, драйвера и библиотеки, стороннее ПО, влияющее на работу приложения и т.д.)

1 Тип, версия и битность операционной системы (подобный вид тестирования называется кросс–платформенное тестирование)

2 Тип и версия Web браузера, в случае если тестируется Web приложение (подобный вид тестирования называется кросс–браузерное тестирование)

3 Тип и модель видео адаптера (при тестировании игр это очень важно)

4 Работа приложения при различных разрешениях экрана

5 Версии драйверов, библиотек и т.д. (для JAVA приложений версия JAVA машины очень важна, тоже можно сказать и для .NET приложений касательно версии .NET библиотеки) и т.д.

Порядок проведения конфигурационного тестирования.Перед началом проведения конфигурационного тестирования рекомендуется:

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

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

— шаг за шагом, в соответствии с расставленными приоритетами, проверяют каждую конфигурацию.

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

Тестирование программного обеспечения | Тестирование конфигурации

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

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

Различные конфигурации:

Конфигурация операционной системы:
```
Win XP, Win 7 32/64 bit, Win 8 32/64 bit, Win 10 etc. 
```

Конфигурация базы данных:

Oracle, DB2, MySql, MSSQL Server, Sybase etc.

Конфигурация браузера:

IE 8, IE 9, FF 16.0, Chrome, Microsoft Edge etc.

Цели тестирования конфигурации:
Целью тестирования конфигурации является:

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

Процесс тестирования конфигурации:

Типы тестирования конфигурации:
Тестирование конфигурации бывает двух типов:

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

Тестирование конфигурации также можно разделить на следующие 2 типа:

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

Рекомендуемые посты:

Тестирование программного обеспечения | Тестирование конфигурации

0.00 (0%) 0 votes

Конфигурационное тестирование или Configuration Testing Каче…

Привет, сегодня поговорим про конфигурационное тестирование или configuration testing, обещаю рассказать все что знаю. Для того чтобы лучше понимать что такое
конфигурационное тестирование или configuration testing , настоятельно рекомендую прочитать все из категории Качество и тестирование программного обеспечения. Quality Assurance.

В зависимости от типа проекта конфигурационное тестирование может иметь разные цели:

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

Проект по миграции системы с одной платформы на другую
Цель Тестирования: Проверить объект тестирования на совместимость с объявленным в спецификации оборудованием, операционными системами и программными продуктами третьих фирм.

Уровни проведения тестирования

Серверный

Клиентский

Аппаратные средства (тип и количество процессоров, объем памяти, характеристики сети / сетевых адаптеров и т.д.)

Программные средства (ОС, драйвера и библиотеки, стороннее ПО, влияющее на работу приложения и т.д.)

Тип, версия и битность операционной системы (подобный вид тестирования называется кросс-платформенное тестирование)

Тип и версия Web барузера, в случае если тестируется Web приложение (подобный вид тестирования называется кросс-браузерное тестирование)

Тип и модель видео адаптера (при тестировании игр это очень важно)

Работа приложения при различных разрешениях экрана

Версии драйверов, библиотек и т.д. (для JAVA приложений версия JAVA машины очень важна, тоже можно сказать и для .NET приложений касательно версии .NET библиотеки)

и т.д.

Порядок проведения тестирования

Перед началом проведения конфигурационного тестирования рекомендуется:

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

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

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

Обобщим что мы имеем

конфигурационным называется тестирование совместимости выпускаемого продукта (программное обеспечение) с различным аппаратным и программным средствами

основные цели — определение оптимальной конфигурации и проверка совместимости приложения с требуемым окружением (оборудованием, ОС и т.д.)

автоматизация конфигурационного тестирования позволяет избежать лишних расходов

Напиши свое отношение к конфигурационное тестирование или configuration testing. Это меня вдохновит писать для тебя всё больше и больше интересного. Спасибо Надеюсь, что теперь ты понял что такое конфигурационное тестирование или configuration testing
и для чего все это нужно, а если не понял, или есть замечания,
то нестесняся пиши или спрашивай в комментариях, с удовольствием отвечу. Для того чтобы глубже понять настоятелно рекомендую изучить комплексно всю информацию в категории
Качество и тестирование программного обеспечения. Quality Assurance.

Функциональное тестирование программного обеспечения — Лаборатория программирования

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

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

⦁ тестирование black box (черный ящик) – проведение функционального тестирования без доступа к коду системы,
⦁ тестирование white box (белый ящик) – функциональное тестирование с доступом к коду системы.
Тестирование black box проводится без знания внутренних механизмов работы системы и опирается на внешние проявления ее работы. При этом тестировании проверяется поведение ПО при различных входных данных и внутреннем состоянии систем. В случае тестирования white box создаются тест-кейсы, основанные преимущественно на коде системы ПО. Также существует расширенный тип black-box тестирования, включающего в себя изучение кода, – так называемый grey box (серый ящик).

Ключевые преимущества

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

Основные этапы функционального тестирования

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

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

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

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

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

Тестирование безопасности — Оценка уязвимости ПО к различным атакам и попыткам несанкционированного доступа к данным.

Системное тестирование — Проверка соответствия ПО требованиям, заявленным в спецификации

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

Тестирование установки — Тестирование процесса инсталляции/деинсталляции программного обеспечения

Конфигурационное тестирование — Проверка работы ПО на различных программных и аппаратных окружениях.

Интеграционное тестирование — Тестирование взаимодействий между компонентами системы и между несколькими системами.

Smoke-тестирование — Короткий цикл тестов для выявления правильной работы основных функций приложения.

Тестирование документации — Проверка документов на соответствие принятым стандартам, а также соответствие определенным характеристикам

Обеспечение тестового покрытия — Оценка плотности покрытия системы тестами

Тестирование удобства использования — Определение степени удобства использования, понятности и привлекательности разрабатываемого продукта

Регрессионное тестирование

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

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

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

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

Ключевые преимущества

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

Основные этапы

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

Интеграционное тестирование

Многие современные ИТ-системы взаимодействуют с другими системами и модулями, поэтому крайне

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

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

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

Ключевые преимущества

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

⦁ Предотвращение появления критичных ошибок в опытно-промышленной эксплуатации;
⦁ Снижение влияния человеческого фактора;
⦁ Экономия затрат на исправление дефектов.

Основные задачи

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

Способы проведения интеграционного тестирования подбираются в зависимости от интеграционных решений.

Этапы

⦁ Разработка тест-плана – руководства к действию для тестировщиков;
⦁ Формирование тестовых данных и создание тест-кейсов;
⦁ Реализация сценариев для запуска тест-кейсов;
⦁ Выполнение тест-кейсов и исправление ошибок;
⦁ Повторение цикла тестирования до успешной интеграции.

Тестирование безопасности

Тестирование безопасности проводится с целью оценки устойчивости системы к противоправным

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

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

Ключевые преимущества

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

Основные задачи

⦁ Анализ архитектуры и построение модели угроз и рисков
⦁ Определение критериев защищенности
⦁ Поиск уязвимостей в исходном коде
⦁ Fuzz тестирование
⦁ Тестирование на проникновение
⦁ Тестирование, основанное на рисках
⦁ Проведение нагрузочного тестирования

Этапы

⦁ Подготовка: сбор информации, уточнение деталей;
⦁ Планирование: анализ уязвимостей системы и возможных угроз, составление матрицы рисков;
⦁ Проектирование: определение параметров защищенности системы, анализ кода, элементарные тесты;
⦁ Разработка: ввод неожиданных, неправильных, нетипичных данных (fuzz-тестирование), оценка нефункциональных составляющих ПО, модель тестирования на рисках;
⦁ Внедрение: ⦁ нагрузочное тестирование, тесты на проникновение.

Smoke-тестирование

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

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

Ключевые преимущества

⦁ Выявление критичных ошибок в первые несколько часов (минут) после установки
⦁ Снижение рисков вывода некачественного продукта;
⦁ Минимизация рисков при интеграции систем;
⦁ Сокращение затрат на исправление дефектов;
⦁ Ускорение проверки за счет автоматизации.

Основные задачи

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

Системное тестирование

Системное тестирование предназначено для тестирования

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

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

Ключевые преимущества

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

Основные задачи

⦁ Определение подхода к составлению тестовых сценариев
⦁ Создание плана и методики испытаний
⦁ Подготовка тестовых данных
⦁ Проведение тестирования
⦁ Выявление некорректного использования ресурсов

Этапы

⦁ Тестовый план
⦁ Разработка тестов
⦁ Подготовка тестовых данных
⦁ Тестовые прогоны – автоматизированные и обычные
⦁ Составление отчета
⦁ Регрессионое тестирование после исправления ошибок

Тестирование документации

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

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

Ключевые преимущества

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

Тестирование документации включает тестирование нескольких уровней документации:

⦁ Бизнес-требования
⦁ Функциональные требования
⦁ Техническое задание
⦁ Руководства пользователей

Тестирование мобильных приложений

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

Ключевые преимущества

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

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

Обеспечение тестового покрытия

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

Ключевые преимущества

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

Основные задачи

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

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

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

Ключевые преимущества

Тестирование установки позволяет избежать таких проблем при установке ПО в промышленную среду, как:
⦁ Невозможность установить ПО
⦁ Потеря данных после установки новой версии
⦁ Невозможность откатиться до предыдущей версии

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

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

Тестирование удобства использования

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

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

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

Основные задачи

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

В рамках данной задачи оценивается:

⦁ Сколько шагов нужно сделать для выполнения задачи?
⦁ Сколько времени требуется на выполнение задачи?
⦁ Сколько ошибок делает пользователь-новичок при выполнении задачи?
⦁ Какое впечатление осталось у пользователя от работы с программой?
⦁ Эмоции пользователя во время выполнения задачи.

Конфигурационное тестирование

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

Ключевые преимущества

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

Основные этапы конфигурационного тестирования

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

Виды тестирования | BUGZA

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

Функциональные.
Нефункциональные.
Связанные с изменениями.

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

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

Функциональные тесты базируются на функциях и особенностях, а также на взаимодействии с другими системами и могут быть представлены на всех уровнях тестирования: компонентном или модульном (Component/Unit testing), интеграционном (Integration testing), системном (System testing), приемочном (Acceptance testing). Функциональные виды тестирования рассматривают внешнее поведение системы. Далее перечислены одни из самых распространенных видов функциональных тестов.

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

1.Функциональные тесты основываются на функциях, выполняемых системой, и могут проводиться на всех уровнях тестирования (компонентном, интеграционном, системном, приемочном). Как правило, эти функции описываются в требованиях, функциональных спецификациях или в виде случаев использования системы (use cases).

Тестирование функциональности может проводиться в двух аспектах:

Требования.
Бизнес-процессы.

Тестирование в аспекте «требования» использует спецификацию функциональных требований к системе, как основу для дизайна тестовых случаев (Test Cases). В этом случае необходимо сделать список того, что будет тестироваться, а что нет, приоритезировать требования на основе рисков (если это не сделано в документе с требованиями), а на основе этого приоритезировать тестовые сценарии (test cases). Это позволит сфокусироваться и не упустить при тестировании наиболее важный функционал.

Тестирование в аспекте «бизнес-процессы» использует знание бизнес-процессов, которые описывают сценарии ежедневного использования системы. В этом аспекте тестовые сценарии (test scripts), как правило, основываются на случаях использования системы (use cases).

Преимущества функционального тестирования:

имитирует фактическое использование системы.

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

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

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

2. Тестирование безопасности (Security and Access Control Testing)

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

Принципы безопасности программного обеспечения

Общая стратегия безопасности основывается на трех основных принципах:

Конфиденциальность.
Целостность.
Доступность.

Конфиденциальность

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

Целостность

Существует два основных критерия при определении понятия целостности:

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

Доступность

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

3. Тестирование взаимодействия или Interoperability Testing

Тестирование взаимодействия (Interoperability Testing) – это функциональное тестирование, проверяющее способность приложения взаимодействовать с одним и более компонентами или системами и включающее в себя тестирование совместимости (compatibility testing) и интеграционное тестирование (integration testing).

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

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

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

1.Все виды тестирования производительности

Тестирование производительности ( Performance testing ).

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

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

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

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

Объемное тестирование ( Volume Testing )

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

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

Тестирование стабильности или надежности( Stability / Reliability Testing)

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

В англоязычной терминологии вы можете так же найти еще один вид тестирования — Load Testing — тестирование реакции системы на изменение нагрузки (в пределе допустимого). Нам показалось, что Load и Performance преследуют все же одну и ту же цель: проверка производительности (времени отклика) на разных нагрузках. Собственно поэтому мы и не стали разделять их. В то же время кто то может разделить. Главное все таки понимать цели того или иного вида тестирования и постараться их достигнуть.

2. Тестирование Установки (Installation Testing)

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

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

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

В распределенных системах, где приложение разворачивается на уже работающем окружении, простого набора инструкций может быть мало. Для этого часто пишется план установки (Deployment Plan), включающий не только шаги по инсталляции приложения, но и шаги отката (roll-back) к предыдущей версии (в случае неудачи). Сам по себе план установки также должен пройти процедуру тестирования для избежания проблем при выдаче в реальную эксплуатацию. Особенно это актуально, если установка выполняется на системы, где каждая минута простоя — это потеря репутации и большого количества средств, например: банки, финансовые компании или даже баннерные сети. Поэтому тестирование установки можно назвать одной из важнейших задач по обеспечению качества программного обеспечения.

3. Тестирование удобства пользования (Usability Testing)

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

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

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

Производительность, эффективность ( efficiency) — сколько времени и шагов понадобится пользователю для завершения основных задач приложения, например, размещение новости, регистрации, покупка и т.д. (меньше — лучше).
Правильность ( accuracy) — сколько ошибок сделал пользователь во время работы с приложением (меньше — лучше).
Активизация в памяти ( recall ) – как много пользователь помнит о работе приложения после приостановки работы с ним на длительный период времени (повторное выполнение операций после перерыва должно проходить быстрее, чем у нового пользователя).
Эмоциональная реакция ( emotional response ) – как пользователь себя чувствует после завершения задачи — растерян, испытал стресс? Порекомендует ли пользователь систему своим друзьям? (положительная реакция — лучше).

Уровни проведения

Проверка удобства использования может проводиться как по отношению к готовому продукту, посредством тестирования черного ящика (black box testing), так и к интерфейсам приложения (API), используемым при разработке — тестирование белого ящика (white box testing). В этом случае проверяется удобство использования внутренних объектов, классов, методов и переменных, а также рассматривается удобство изменения, расширения системы и интеграции ее с другими модулями или системами. Использование удобных интерфейсов (API) может улучшить качество, увеличить скорость написания и поддержки разрабатываемого кода и, как следствие, улучшить качество продукта в целом.

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

Советы по улучшению удобства пользования:

Для дизайна удобных приложений полезно следовать принципам «пока-йока» или fail-safe. У нас это более известно как «защита от дурака». Простой пример: если поле требует цифровое значение,то логично ограничить пользователю диапазон ввода только цифрами – будет меньше случайных ошибок.
Для повышения юзабилити существующих приложений можно использовать цикл Демминга (Plan-Do-Check-Act), собирая отзывы о работе и дизайне приложения у существующих пользователей, и, в соответствии с их замечаниями, планируя и проводя улучшения.

Заблуждения о тестировании удобства пользования:

Тестирование пользовательского интерфейса = Тестирование удобства пользования

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

Тестирование удобства пользования можно провести без участия эксперта

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

4. Тестирование на отказ и восстановление (Failover and Recovery Testing)

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

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

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

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

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

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

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

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

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

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

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

5. Конфигурационное тестирование (Configuration Testing)

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

В зависимости от типа проекта конфигурационное тестирование может иметь разные цели:

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

Примечание: В ISTQB Syllabus вообще не говорится о таком виде тестирования, как конфигурационное. Согласно глоссарию, данный вид тестирования рассматривается там как тестирование портируемости(portability testing: The process of testing to determine the portability of a software product.).

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

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

1. Дымовое тестирование (Smoke Testing)

Понятие дымовое тестирование пошло из инженерной среды:

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

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

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

Аналогами дымового тестирования являются Build Verification Testing и Acceptance Testing, выполняемые на функциональном уровне командой тестирования, по результатам которых делается вывод о том, принимается или нет установленная версия программного обеспечения в тестирование, эксплуатацию или на поставку заказчику.

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

2. Регрессионное тестирование (Regression Testing)

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

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

Сам по себе термин «регрессионное тестирование», в зависимости от контекста использования, может иметь разный смысл. Сэм Канер, к примеру, описал 3 основных типа регрессионного тестирования:

Регрессия багов (Bug regression) — попытка доказать, что исправленная ошибка на самом деле не исправлена.
Регрессия старых багов (Old bugs regression) — попытка доказать, что недавнее изменение кода или данных сломало исправление старых ошибок, т.е. старые баги стали снова воспроизводиться.
Регрессия побочного эффекта (Side effect regression) — попытка доказать, что недавнее изменение кода или данных сломало другие части разрабатываемого приложения.

3. Тестирование сборки (Build Verification Test)

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

4. Санитарное тестирование или проверка согласованности/исправности (Sanity Testing)

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

Отличие санитарного тестирования от дымового (Sanity vs Smoke testing)

В некоторых источниках ошибочно полагают, что санитарное и дымовое тестирование — это одно и тоже. Мы же полагаем, что эти виды тестирования имеют «векторы движения»- направления в разные стороны. В отличии от дымового (Smoke testing), санитарное тестирование (Sanity testing) направлено вглубь проверяемой функции, в то время как дымовое — направлено вширь, для покрытия тестами как можно большего функционала в кратчайшие сроки.

Обзор инструментария для нагрузочного и перформанс-тестирования

Как говорят иные отважные люди: «От dev до prod — всего один шаг». Люди опытные добавляют, что шаг этот называется «тестирование», причём самое разнообразное, и нам просто нет смысла им не верить.

Нагрузка имеет значение: водитель этого грузовика умудрился обрушить мост весом своего ТС, счёт за восстановление составил примерно $21.3M. К счастью, тестирование ПО обходится дешевле!

Конечно, говоря о тестировании, нужно понять, с чем и за что мы боремся. Мы сознательно ограничили себя и решили сегодня поговорить исключительно про нагрузочное тестирование и тестирование производительности: темы, полярно удалённые друг от друга, крайне интересны в самом практическом выражении. Рассмотрим инструменты для того и другого, не привязываясь к какому-то конкретному стеку технологий, так что не удивляйтесь соседству Яндекс.Танк и BenchmarkDotNet!

Нагрузочное тестирование

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

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

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

С учётом обстоятельств и нашего знания об объекте тестирования выбираем инструмент(ы):

JMeter

Да, старый добрый JMeter. Он вот уже без малого двадцать лет (!) является частым выбором для многих вариантов и типов нагрузочного тестирования: удобный GUI, независимость от платформы (спасибо Java!), поддержка многопоточности, расширяемость, отличные возможности по созданию отчётов, поддержка многих протоколов для запросов. Благодаря модульной архитектуре JMeter можно расширить в нужную пользователю сторону, реализуя даже весьма экзотические сценарии тестирования — причем, если ни один из написанных сообществом за прошедшее время плагинов нас не устроит, можно взять API и написать собственный. При необходимости с JMeter можно выстроить, хоть и ограниченное, но распределённое тестирование, когда нагрузка будет создаваться сразу несколькими машинами.

Одной из удобных функций JMeter является работа в режиме прокси: указываем в настройках браузера в качестве прокси «127.0.0.1:8080» и посещаем браузером нужные нам страницы нужного сайта, тем временем JMeter сохраняет все наши действия и все сопутствующие запросы в виде скрипта, который позже можно будет отредактировать, как нужно — это делает процесс создания HTTP-тестов заметно проще.

Кстати, последняя версия (3.2), вышедшая в апреле этого года, научилась отдавать результаты тестирования в InfluxDB при помощи асинхронных HTTP-запросов. Правда, начиная как раз с версии 3.2, JMeter стал требовать только Java 8, но это, наверное, не самая высокая цена за прогресс.

Хранение тестовых сценариев у JMeter реализовано в XML-файлах, что, как оказалось, создаёт массу проблем: их совсем неудобно писать руками (читай — для создания текста необходим GUI), как неудобна и работа с такими файлами в системах управления версиями (особенно в момент, когда нужно сделать diff). Конкурирующие на поле нагрузочного тестирования продукты, такие, как Яндекс.Танк или Taurus, научились самостоятельно и на лету формировать файлы с тестами и передавать их в JMeter на исполнение, таким образом пользуясь мощью и опытом JMeter, но давая возможность пользователям создавать тесты в виде более читаемых и легче хранимых в CVS тестовых скриптов.

LoadRunner

Ещё один давно существующий на рынке и в определенных кругах очень известный продукт, большему распространению которого помешала принятая компанией-производителем политика лицензирования (кстати, сегодня, после слияния подразделения ПО компании Hewlett Packard Enterprise с Micro Focus International, привычное название HPE LoadRunner сменилось на Micro Focus LoadRunner). Интерес представляет логика создания теста, где несколько (наверное, правильно сказать — «много») виртуальных пользователей параллельно что-то делают с тестируемым приложением. Это даёт возможность не только оценить способность приложения обработать поток одновременных запросов, но и понять, как влияет работа одних пользователей, активно что-то делающих с сервисом, на работу других. При этом речь идёт о широком выборе протоколов взаимодействия с тестируемым приложением.

HP в своё время создала очень хороший набор инструментов автоматизации функционального и нагрузочного тестирования, которые, при необходимости, интегрируются в процесс разработки ПО, и LoadRunner умеет интегрироваться с ними (в частности, с HP Quality Center, HP QuickTest Professional).

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

Gatling

Весьма мощный и серьёзный инструмент (не зря названный в честь скорострельного пулемета) — в первую очередь, по причине производительности и широты поддержки протоколов «из коробки». Например, там, где нагрузочное тестирование с JMeter будет медленным и мучительным (увы, плагин поддержки работы с веб-сокетами не особо быстр, что идейно конфликтует со скоростью работы самих веб-сокетов), Galting почти наверняка создаст нужную нагрузку без особых сложностей.

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

Есть у Gatling и минусы, за которые его критикуют. Во-первых, документация могла бы быть и получше, во-вторых, для работы с ним неплохо знать Scala: и сам Gatling, как инструмент тестирования, и тестовые сценарии пишутся именно на этом языке. В-третьих, разработчики «иногда» в прошлом кардинально меняли API, в результате можно было обнаружить, что тесты, написанные полугодом ранее, «не идут» на новой версии, либо требуют доработки/миграции. У Gatling также отсутствует возможность делать распределённое тестирование, что ограничивает возможные области применения.

Яндекс.Танк

Если коротко, Yandex Tank — это враппер над несколькими утилитами нагрузочного тестирования (включая JMeter), предоставляющий унифицированный интерфейс для их конфигурации, запуска и построения отчётов вне зависимости от того, какая утилита используется «под капотом».

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

Танк используется и в самом Яндексе, и в других компаниях уже около 10 лет. Им обстреливают совершенно разные сервисы, с разными требованиями к сложности тестовых сценариев и к уровню нагрузки. Почти всегда для тестирования даже высоконагруженных сервисов хватает всего одного генератора нагрузки. Танк поддерживает разные генераторы нагрузки, как написанные специально для него (Phantom, BFG, Pandora), так и широко сторонние (JMeter). Модульная архитектура позволяет написать свой плагин под нужный генератор нагрузки и вообще прикрутить практически что угодно.

Для чего использовать разные генераторы нагрузки? Phantom — это быстрая «пушка» на C++. Один такой генератор может выдать до сотни тысяч запросов в секунду. Но для достижения такой скорости приходится генерировать запросы заранее и нельзя (не получается) использовать получаемые от тестируемого сервиса данные для генерации очередного запроса. В случаях, когда нужно исполнять сложный сценарий или сервис использует нестандартный протокол, следует использовать JMeter, BFG, Pandora.

В BFG, в отличие от Jmeter, нет GUI, тестовые сценарии пишутся на Python. Это позволяет использовать любые библиотеки (а их огромное количество). Часто бывает, что для сервиса написаны биндинги для Python, тогда их удобно использовать при написании нагрузочных сценариев. Pandora — это экспериментальная пушка на GoLang, достаточно быстрая и расширяемая, подходит для тестов по протоколу HTTP/2 и будет использоваться там, где нужны быстрые сценарии.

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

Taurus

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

Вообще, Taurus хорошо подойдёт в ситуации, когда мощность, скажем, Gatling важна для создания теста, но разбираться с Gatling (а также с написанием скриптов тестирования на Scala) нет желания или возможности: достаточно описать тест в куда более простом формате файла Taurus, настроить его на использование Gatling как инструмента создания нагрузки, и все Scala-файлы будут сгенерированы автоматически. Так сказать, «автоматизация автоматизации» в действии!

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

Тестирование производительности

Тестировать производительность сервиса или приложения можно и нужно не только после завершения процесса разработки, но и во время неё, буквально так же, как мы делаем регулярные юнит- или регрессионные тесты. Правильно организованные, регулярные тесты производительности позволяют ответить на очень «тонкий» вопрос: не привели ли последние изменения в коде приложения к ухудшению производительности получившегося ПО?

Казалось бы, померить производительность — это так просто! Два раза взять timestamp (желательно с высокой точностью), посчитать разность, сложили-поделили, и всё — можно оптимизировать. Как бы не так! Хотя на словах этот вопрос звучит просто, на деле такого рода замеры довольно затруднительно производить, а сравнивать результаты разных замеров вообще не всегда разумно. Одна из причин: для сопоставления результатов тесты должны проходить над одними и теми же исходными данными, что, среди прочего, подразумевает воссоздание тестовой среды при каждом прогоне проверки, другая причина — сравнение субъективного восприятия времени работы тестового сценария может оказаться неточным.

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

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

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

JMH

JMH (Java Microbenchmark Harness) — это оснастка Java для сборки, запуска и анализа нано/микро/милли/макро-бенчмарков, написанных на Java и других языках с целевой платформой JVM. Сравнительно молодой фреймворк, в котором разработчики постарались учесть все нюансы JVM. Один из удобнейших инструментов, из тех, которые приятно иметь под рукой. JMH поддерживает следующие типы замеров: Throughput (замер чистой производительности), AverageTime (замер среднего времени выполнения), SampleTime (перцентиль времени исполнения), SingleShotTime (время вызова одного метода — актуально для замера «холодного» запуска тестируемого кода).

Поскольку речь идёт о Java, фреймворк учитывает в т.ч. и работу механизма кэширования JVM, и перед запуском бенчмарка несколько раз выполняет тестируемый код для «прогрева» кэша байт-кода Java-машины.

BenchmarkDotNet

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

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

Google Lighthouse

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

В веб-фронтенде в отношении замеров производительности сейчас всё идёт в сторону использования Performance API и измерении именно тех параметров, которые имеют значение для конкретного проекта. Хорошим подспорьем окажется веб-сервис webpagetest.org с Performance API метками и замерами — он позволит увидеть картину не со своего компьютера, а с одной из многих точек тестирования, существующих в мире, и оценить влияние времени приёма-передачи данных через каналы интернет на работу фронтенда.

Этот продукт больше подходил бы для проверки страниц сайта на соответствие рекомендациям Google (и вообще best practices) как для веб-сайтов, так и для Progressive Web Apps, если бы не одна из его функций: среди проверок есть и тест на поведение сайта при плохом качестве веб-соединения, а также при полном отсутствии связи. Это не очень соотносится с перформанс-тестированием как таковым, однако, если задуматься, в некоторых случаях веб-приложение воспринимается «медленным» не потому, что медленно готовит данные, а потому, что условия его работы на машине пользователя, в его браузере, с учётом его соединения с интернетом — увы, не идеальны. Google Lighthouse как раз и позволяет оценить это влияние.

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

Поэтому с радостью приглашаем вас посетить конференцию Гейзенбаг 2017 Moscow, которая состоится 8-9 декабря 2017 года, где будут, в частности, представлены доклады:

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

Что такое тестирование конфигурации? Примеры тестовых случаев

Home
Testing
- - Back
  - Agile Testing
  - BugZilla
  - Cucumber
  - Тестирование базы данных
  - ETL Testing

Пн	Вт	Ср	Чт	Пт	Сб	Вс
	1	2	3	4	5	6
7	8	9	10	11	12	13
14	15	16	17	18	19	20
21	22	23	24	25	26	27
28	29	30	31

Конфигурационное тестирование: Про Тестинг — Тестирование — Виды Тестирования ПО

Про Тестинг — Тестирование — Виды Тестирования ПО

Уровни проведения тестирования

Порядок проведения тестирования

Обобщим что мы имеем

Конфигурационное тестирование — Студопедия

Тестирование программного обеспечения | Тестирование конфигурации

Конфигурационное тестирование или Configuration Testing Каче…

Уровни проведения тестирования

Порядок проведения тестирования

Обобщим что мы имеем

Функциональное тестирование программного обеспечения — Лаборатория программирования

Ключевые преимущества

Основные этапы функционального тестирования

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

Регрессионное тестирование

Ключевые преимущества

Основные этапы

Интеграционное тестирование

Ключевые преимущества

Основные задачи

Этапы

Тестирование безопасности

Ключевые преимущества

Основные задачи

Этапы

Smoke-тестирование

Ключевые преимущества

Основные задачи

Системное тестирование

Ключевые преимущества

Основные задачи

Этапы

Тестирование документации

Ключевые преимущества

Тестирование документации включает тестирование нескольких уровней документации:

Тестирование мобильных приложений

Ключевые преимущества

Обеспечение тестового покрытия

Ключевые преимущества

Основные задачи

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

Ключевые преимущества

Тестирование удобства использования

Основные задачи

Конфигурационное тестирование

Ключевые преимущества

Основные этапы конфигурационного тестирования

Виды тестирования | BUGZA

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

Конфиденциальность

Целостность

Доступность

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

Тестирование производительности ( Performance testing ).

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

Объемное тестирование ( Volume Testing )

Уровни проведения

Советы по улучшению удобства пользования:

Заблуждения о тестировании удобства пользования:

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

Отличие санитарного тестирования от дымового (Sanity vs Smoke testing)

Обзор инструментария для нагрузочного и перформанс-тестирования

Нагрузочное тестирование

JMeter

LoadRunner

Gatling

Яндекс.Танк

Taurus

Тестирование производительности

JMH

BenchmarkDotNet

Google Lighthouse

Что такое тестирование конфигурации? Примеры тестовых случаев

с примерами

Что такое тестирование конфигурации?

Почему это тестирование?

Подготовка к тесту конфигурации

# 1) Подготовка матрицы покрытия

# 2) Приоритизация конфигураций