Что такое тестирование потоков в тестировании программного обеспечения?
Томас Гамильтон
⚡ Умное резюме
Многопоточное тестирование проверяет ключевые функциональные возможности отдельной бизнес-задачи по мере ее прохождения через интегрированную систему и выполняется на ранних этапах интеграционного тестирования, а не после завершения работы над каждым компонентом.
Что такое тестирование потоков?
Тестирование потоков Это тип тестирования программного обеспечения, который проверяет ключевые функциональные возможности конкретной задачи, называемой потоком. Обычно он проводится на ранней стадии разработки. интеграционное тестирование Этап. Тестирование на основе потоков — одна из стратегий поэтапного внедрения, применяемых при интеграционном тестировании системы. Поэтому тестирование потоков правильнее описывать как… тест взаимодействия потоков.
В данном случае под потоком понимается не только поток операционной системы. разработка программного обеспечения В терминах, поток информации — это одна завершенная бизнес-транзакция, например, «клиент размещает заказ». tracПропускается через каждый модуль, к которому прикасается. Потоковая проверка проверяет, продолжает ли этот единственный путь работать корректно после того, как модули соединены между собой.
На приведенной ниже диаграмме показано, как отдельные потоки интегрируются и запускаются в качестве подсистемы до сборки всей системы.
Типы тестирования потоков
Потоковое тестирование подразделяется на две категории, и это различие определяет как тестовые данные, так и вероятные дефекты, которые вы сможете обнаружить.
- Тестирование в однопоточном режиме: Тестирование в однопоточном режиме включает в себя обработку только одной транзакции приложения за раз. Обрабатывается только один запрос, поэтому поведение ответа предсказуемо, а тест легко написать и воспроизвести.
- Многопоточное тестирование: Многопоточное тестирование включает в себя одновременное выполнение нескольких активных транзакций. Для одной и той же службы подготавливаются отдельные потоки, чтобы можно было наблюдать за отзывчивостью и обработкой общего состояния при одновременной нагрузке.
Транзакция, которая успешно проходит тестирование в однопоточном режиме, может завершиться неудачей в многопоточном режиме, поскольку при повторном запуске возникает конкуренция за те же записи, соединения и память.
Как провести тестирование потоков
Процесс разработки, основанный на использовании потоков данных, фокусируется на интеграционных мероприятиях, а не на полном цикле разработки. На практике подход работает следующим образом.
- Потоковое тестирование — это обобщенная форма сеансового тестирования, в которой сеансы представляют собой форму потока, но поток не обязательно является сеансом.
- Поток или программа (с небольшим функционалом) интегрируется и тестируется поэтапно как подсистема, а затем выполняется для всей системы.
- На самом базовом уровне это позволяет интеграторам лучше понимать, что именно нужно тестировать.
- Вместо непосредственного тестирования программных компонентов, это требует от интеграторов сосредоточиться на тестировании логических путей выполнения в контексте всей системы.
Поскольку единицей работы является бизнес-процесс, а не компонент, тестирование потоков органично вписывается в общую схему. тестирование модуля и полный тестирование системы.
Советы по многопоточному тестированию
Многопоточные дефекты зависят от времени выполнения, поэтому один чистый запуск мало что доказывает. Приведенные ниже советы повышают вероятность их обнаружения.
- Протестируйте свою многопоточную программу, многократно запуская её с различным набором запущенных приложений.
- Протестируйте свою многопоточную программу, запустив одновременно несколько её экземпляров.
- Запустите свою многопоточную программу на различных моделях оборудования с разным уровнем нагрузки и производительности.
- Используйте анализ кода, поскольку некоторые ошибки синхронизации проще прочитать, чем воспроизвести.
- Собирайте только ошибки и сбои, произошедшие в потоках, отличных от основного.
Типичные дефекты, выявляемые при проверке резьбы.
Ошибки параллельного выполнения редко проявляются в виде чистого стека. trace. Приведенные ниже категории охватывают большую часть того, что выявляет многопоточный режим работы, и каждая из них имеет свой отличительный симптом, на который стоит обратить внимание.
- Условия гонки: Два потока считывают и записывают одно и то же значение без определенного порядка, поэтому конечный результат зависит от того, какой поток завершился первым. Симптом: итоговые значения верны в одних запусках и неверны в других.
- Тупик: Два потока удерживают по блокировке, необходимой другому, и ни один из них не продолжает выполнение. Симптом: транзакция зависает на неопределенное время, а не завершается с ошибкой.
- Конфликт за ресурсы: Потоки ставят в очередь одно и то же соединение, дескриптор файла или запись, и пропускная способность резко падает задолго до достижения аппаратного предела.
- Повреждение данных: Частично записанные разделяемые структуры оставляют записи в состоянии, которое невозможно создать с помощью действительной транзакции.
- Голодание: Низкоприоритетный поток никогда не получает необходимый ресурс, поэтому один из пользовательских путей завершается по истечении времени ожидания, в то время как остальная часть системы выглядит работоспособной.
Для каждого из этих случаев необходимо зафиксировать неудачный запуск в журналах, поскольку дефект, воспроизводящийся один раз из пятидесяти попыток, иначе невозможно выявить. процесс управления дефектами.
Тестирование потоков, параллельное тестирование и интеграционное тестирование.
Эти три термина частично совпадают и часто путаются в планах тестирования. В таблице они разделены по назначению.
| Аспект | Тестирование потоков | Тестирование параллельного выполнения | Интеграционное тестирование |
| Испытательный модуль | Одна бизнес-транзакция между модулями | Одновременное действие нескольких пользователей или потоков | Интерфейсы между двумя или более компонентами |
| Основной вопрос | Работает ли этот ключевой путь от начала до конца? | Что происходит при одновременном доступе? | Модули корректно взаимодействуют друг с другом? |
| Типичная стадия | Раннее интеграционное тестирование | Системное или производительное тестирование | После модульного тестирования |
| Выявленные дефекты | Нарушенные пути выполнения, отсутствующие передачи данных. | Взаимоблокировки, состояния гонки, борьба за блокировки | Несоответствия интерфейсов, неверные данные.tracts |
| Родство | Многопоточный вариант частично совпадает с тестированием параллельного выполнения. | Более широкий охват, чем многопоточный срез тестирования потоков. | Тестирование потоков — это один из поэтапных методов в рамках данной стратегии. |
Короче говоря, тестирование параллельного доступа Тестирование потоков задает вопрос о том, как одновременный доступ влияет на систему, в то время как тестирование потоков проверяет, сохраняется ли вообще какой-либо важный путь интеграции. Команды, которые проводят оба теста, обычно планируют тестирование потоков в первую очередь.
Преимущества проверки резьбы
Данная методика заслуживает места в плане интеграции по нескольким практическим причинам.
- Ключевые бизнес-процессы проверяются на ранних этапах, поэтому сбой в передаче данных обнаруживается до того, как система будет полностью собрана.
- Интеграторы получают четкое представление о масштабе проекта, поскольку тестовый модуль представляет собой узнаваемую транзакцию, а не абстрактную модель.tracГраница компонента t.
- Тестирование логических путей выполнения в контексте системы выявляет ошибки, которые можно локализовать. тестирование компонентов не могу видеть.
- Многопоточные вычисления выявляют дефекты параллельного выполнения — взаимоблокировки, состояния гонки и конфликты ресурсов, — которые в противном случае попали бы в производственную среду.
- Поэтапная интеграция позволяет уменьшить область отладки, поскольку за один раз добавляется только один поток.
- Результаты напрямую используются в регрессионное тестирование, потому что мимолетная нить — очевидный кандидат для включения в набор регрессионных тестов.
Недостатки тестирования потоков
- При тестировании многопоточности наибольшую сложность представляет возможность запрограммировать воспроизводимый тест для модульного тестирования.
- Написание модульных тестов для многопоточного кода — задача непростая.
- Критерии тестирования многопоточности отличаются от критериев тестирования однопоточности. При многопоточном тестировании такие факторы, как объем памяти, емкость хранилища и проблемы синхронизации, различаются в зависимости от того, вызывается ли код на различном оборудовании.
- Тестирование потоков невозможно до тех пор, пока не станут доступны модули, через которые они проходят, поэтому планирование зависит от порядка интеграции.
- Периодические сбои легко списать на посторонние шумы, поэтому систематическая регистрация данных крайне важна.
