Что такое параллельное тестирование в тестировании программного обеспечения?
Томас Гамильтон
⚡ Умное резюме
Параллельное тестирование выявляет дефекты, которые появляются только тогда, когда несколько пользователей одновременно работают с одним и тем же приложением, обнаруживая взаимоблокировки, потерянные обновления и проблемы с блокировками, которые никогда не выявляются при последовательной функциональной проверке.
Что такое параллельное тестирование?
Тестирование параллельного выполнения Это метод тестирования, используемый для обнаружения дефектов в приложении, когда в систему одновременно входят несколько пользователей. Другими словами, он отслеживает эффект, когда несколько пользователей одновременно выполняют одно и то же действие.
Тестирование параллельного выполнения также называют многопользовательское тестированиеТестирование параллельной программы сложнее, чем тестирование последовательной программы, из-за недетерминированности и проблем синхронизации: один и тот же тест может пройти при одном запуске и провалиться при следующем, не изменив ни одной строки кода.
Приведенная ниже диаграмма иллюстрирует эту идею: несколько пользователей одновременно обращаются к одному и тому же ресурсу приложения, и тест наблюдает, что приложение делает в этой ситуации, когда происходит перекрытие.
Зачем нужно параллельное тестирование?
Два вопроса оправдывают затраченные усилия, и оба остаются незаметными при выполнении функциональных заданий для одного пользователя.
- Он позволяет выявить последствия одновременного доступа к одним и тем же записям базы данных, модулям или коду приложения.
- Она выявляет и измеряет уровень взаимоблокировок, блокировок, использования однопоточного кода и ограниченного доступа к общим ресурсам.
Функция может быть полностью корректной для одного пользователя, но при этом терять данные для второго пользователя, который подключается на миллисекунду позже. Именно поэтому этот метод используется в сочетании с другими подходами. тестирование производительности а не в рамках функционального тестирования.
Как проводить тестирование параллельного выполнения
Тестирование параллельного выполнения выполняется в повторяющейся последовательности. Описанные ниже шаги следуют из описания алгоритма.ping к разрешению.
- Шаг 1) Выявите потоки, подверженные параллелизму. Обратите внимание на наличие общего состояния: одновременные входы в систему, резервирование мест или акций, обновления баланса, пакетные задания, записывающие данные в одну и ту же таблицу, а также любые однопоточные компоненты в пути выполнения.
- Шаг 2) Установите целевой показатель параллельного выполнения. Определите, сколько пользователей должны действовать одновременно, исходя из реальных пиковых нагрузок, а не из округленного числа.
- Шаг 3) Разработайте тестовые примеры. Каждый прецедент сопоставляет общий ресурс, конкурирующие действия и ожидаемое конечное состояние — например, две сессии вывода средств с одной учетной записи не обязательно должны быть успешными.
- Шаг 4) Создайте скрипт и выберите инструмент. Требуется генератор нагрузки, создающий настраиваемых виртуальных пользователей; JMeter является распространенным выбором среди решений с открытым исходным кодом, и его настройки групп потоков напрямую соответствуют сценариям параллельного выполнения.
- Шаг 5) Ramp постепенно. Увеличивайте количество одновременно подключенных пользователей поэтапно, а не резко.ping к цели, чтобы был виден уровень, на котором начинается конкуренция.
- Шаг 6) Мониторинг и анализ. Внимательно изучите задержки блокировок, разброс времени ответа, частоту ошибок и блокировку базы данных — дефект параллельного выполнения часто проявляется как аномалия времени, прежде чем отобразится как ошибка.
- Шаг 7) Устраните проблему и запустите повторно. Устраните причину, связанную с синхронизацией, индексированием или блокировкой, затем повторите тот же запуск, чтобы убедиться, что поведение изменилось, а не просто сместилось.
Распространенные дефекты параллельного выполнения
Дефекты параллельного выполнения делятся на небольшое количество распознаваемых классов, и правильное наименование класса обычно сразу указывает на способ их исправления.
| дефект | Что происходит | Типичный симптом |
| Условия гонки | Результат зависит от того, какая сессия завершилась первой. | В одних сериях итоговые результаты были правильными, в других — нет. |
| Deadlock | Две сессии удерживают друг друга, другая нуждается в... | Транзакции зависают вместо возврата ошибки. |
| Потерянное обновление | Вторая операция записи перезаписывает первую, не считывая её. | Сохранённые изменения незаметно исчезают. |
| Повреждение данных | Общая структура записывается лишь частично. | Записи находятся в состоянии, в котором не может быть создана действительная транзакция. |
| Голодание | Одна сессия так и не получает ресурс, которого ожидает. | При попытке доступа к одному из пользовательских путей происходит таймаут, хотя система выглядит работоспособной. |
Поскольку эти сбои носят периодический характер, необходимо фиксировать журналы и временные метки каждого запуска; в противном случае о дефекте невозможно достоверно сообщить. процесс управления дефектами.
Пример тестирования параллельного выполнения
Рассмотрим интернет-магазин, в котором остался последний экземпляр товара. Два покупателя одновременно открывают товар и оба нажимают на кнопку «Открыть». Купить.
- Сценарий: В двух сессиях значение запаса равно 1, обе проходят проверку наличия, и в обеих записывается значение запаса равное 0.
- Ожидаемый результат: Один заказ подтверждается, по другому приходит сообщение об отсутствии товара на складе, и количество товара никогда не становится отрицательным.
- Индикатор дефекта: Оба ордера подтверждаются, или же цена акций падает до -1, что указывает на то, что проверка наличия и уменьшение количества не выполняются как один атомарный шаг.
- Варианты, которые стоит попробовать: Те же две сессии: редактирование одной записи профиля, два подтверждения одного и того же запроса и пакетное задание, обновляющее таблицу во время сохранения пользователем.
Обобщается та же схема: один ресурс, два автора и отсутствие гарантии порядка выполнения. Запуск сценария во время тестирование системыПеред добавлением нагрузки обеспечивает чистоту диагностики.
Преимущества параллельного тестирования
- Это значительно сокращает трудозатраты на тестирование приложения, ограничивая область одновременного взаимодействия несколькими широко используемыми и хорошо протестированными компонентами.
- Инкапсуляция позволяет анализировать поведение отдельной части программы без необходимости изучения всей кодовой базы.
- Это помогает повысить надежность и устойчивость параллельных программ.
- Это позволяет заблаговременно выявлять ограничения на блокировку и блокировку, поэтому решения о пропускной способности принимаются на основе взвешенных показателей конкуренции, а не на основе оценок.
Недостатки параллельного тестирования
Перечисленные ниже недостатки обычно встречаются тестировщикам при проведении параллельного тестирования.
- Приложение необходимо протестировать на нескольких платформах.
- Для сценариев параллельного выполнения требуются более интенсивные тесты, чем для сценариев последовательного выполнения.
- Функции не возвращают результат вызывающей стороне немедленно; вместо этого результат может быть доставлен позже через уведомления, блоки, функции обратного вызова или аналогичные механизмы, что затрудняет тестирование.
- Информационный или программный поток не отражается в стеке вызовов.
- Количество путей выполнения в системе может быть чрезвычайно большим, поскольку процессы в параллельной системе взаимодействуют друг с другом во время выполнения.
- Параллельные программы имеют более высокий процент отказов, чем последовательные.
- Отладка параллельно работающих программ — сложная задача, поскольку подключение отладчика изменяет временные параметры, вызвавшие сбой.
