Що таке тестування потоків у тестуванні програмного забезпечення?
⚡ Розумний підсумок
Тестування потоків перевіряє ключову функціональну здатність окремого бізнес-завдання під час його проходження через інтегровану систему та виконується на ранній стадії інтеграційного тестування, а не після завершення кожного компонента.

Що таке тестування потоків?
Тестування потоків – це тип тестування програмного забезпечення, який перевіряє ключову функціональну здатність певного завдання, що називається потоком. Зазвичай воно проводиться на ранній стадії інтеграційне тестування фаза. Тестування на основі потоків є однією з поступових стратегій, що застосовуються під час тестування системної інтеграції. З цієї причини тестування потоків правильніше описати як тест взаємодії потоків.
Потік тут — це не лише потік операційної системи. У розробка програмного забезпечення Іншими словами, потік – це одна завершена бізнес-транзакція, наприклад, «клієнт розміщує замовлення» – tracпроходить через кожен модуль, якого він торкається. Тестування потоків запитує, чи цей єдиний шлях все ще поводиться правильно після з'єднання модулів разом.
На діаграмі нижче показано, як окремі потоки інтегруються та тренуються як підсистема перед тим, як буде зібрана повна система.
Типи тестування потоків
Тестування на основі потоків класифікується на дві категорії, і ця відмінність визначає як тестові дані, так і дефекти, які ви ймовірно знайдете.
- Тестування одного потоку: Однопотоковий тест включає одну транзакцію програми за раз. Обслуговується лише один запит, тому поведінка відповіді передбачувана, а тест легко написати за сценарієм та повторити.
- Багатопотокове тестування: Багатопотоковий тест включає кілька одночасно активних транзакцій. Окремі потоки готуються для однієї й тієї ж служби, щоб можна було спостерігати швидкість реагування та обробку спільного стану під одночасною навантаженням.
Транзакція, яка без проблем проходить однопотокове тестування, все ще може зазнати невдачі в багатопотоковому запуску, оскільки другий запуск додає конкуренцію за ті самі записи, з'єднання та пам'ять.
Як виконати тестування потоків
Процес потоків зосереджений на діяльності з інтеграції, а не на повному життєвому циклі розробки. На практиці цей підхід працює наступним чином.
- Тестування на основі потоків є узагальненою формою тестування на основі сеансів, оскільки сеанси є формою потоку, але потік не обов’язково є сеансом.
- Потік або програма (невелика функціональність) інтегрується та тестується поступово як підсистема, а потім виконується для всієї системи.
- На найнижчому рівні це надає інтеграторам краще уявлення про обсяг тестування.
- Замість безпосереднього тестування програмних компонентів, це вимагає від інтеграторів зосередитися на тестуванні логічних шляхів виконання в контексті всієї системи.
Оскільки одиниця роботи є бізнес-шляхом, а не компонентом, тестування потоків природно розташовується між... тестування модулів і повний тестування системи.
Поради щодо багатопотокового тестування
Багатопотокові дефекти залежать від часу, тому один чистий запуск мало що доводить. Наведені нижче поради збільшують ймовірність їх виявлення.
- Перевірте свою багатопотокову програму, виконавши її неодноразово з різним набором запущених програм.
- Перевірте свою багатопотокову програму, запустивши кілька її екземплярів одночасно.
- Виконайте свою багатопотокову програму на різних моделях обладнання з різним рівнем навантаження та робочими навантаженнями.
- Використовуйте перевірку коду, оскільки деякі помилки синхронізації легше прочитати, ніж відтворити.
- Збирати лише помилки та збої, що сталися в потоках, відмінних від основного.
Поширені дефекти, виявлені під час тестування різьблення
Помилки паралельності рідко оголошують про себе при чистому стеку trace. Наведені нижче категорії пояснюють більшу частину того, що викриває багатопотоковий запуск, і кожна з них має окремий симптом, який варто розпізнати.
- Умови перегонів: Два потоки зчитують та записують одне й те саме значення без упорядкування, тому кінцевий результат залежить від того, який потік завершив роботу першим. Ознака: підсумки, які є правильними в деяких запусках і неправильними в інших.
- Безвихідь: Два потоки мають блокування, потрібне іншому, і жоден з них не продовжує свою роботу. Симптом: транзакція зависає на невизначений термін, а не завершується помилкою.
- Конкуренція за ресурси: Потоки стають у чергу для того самого з'єднання, дескриптора файлу або запису, а пропускна здатність падає задовго до досягнення апаратного ліміту.
- Пошкодження даних: Частково записані спільні структури залишають записи у стані, який не може бути створений жодною дійсною транзакцією.
- голодування: Потік з низьким пріоритетом ніколи не отримує необхідний ресурс, тому один шлях користувача перевищує час очікування, тоді як решта системи виглядає справною.
Кожен з них потребує запису невдалого запуску в журналах, оскільки дефект, який відтворюється один раз на п'ятдесят спроб, інакше неможливо виявити через процес управління дефектами.
Тестування потоків проти тестування паралельності проти тестування інтеграції
Ці три терміни перетинаються та часто плутаються в планах тестування. У таблиці їх розділено за призначенням.
| Аспект | Тестування потоків | Тестування паралельності | Інтеграційне тестування |
| Випробуваний пристрій | Одна бізнес-транзакція в усіх модулях | Кілька користувачів або потоків, що діють одночасно | Інтерфейси між двома або більше компонентами |
| Основне питання | Чи працює цей ключовий шлях від початку до кінця? | Що порушується, коли доступ одночасно? | Чи правильно модулі взаємодіють один з одним? |
| Типова стадія | Раннє інтеграційне тестування | Системне або продуктивне тестування | Після модульного тестування |
| Цільові дефекти | Порушені шляхи виконання, відсутні передачі | Взаємоблокування, умови гонки, конфлікт блокувань | Невідповідності інтерфейсів, неправильні даніtracts |
| Зв'язок | Перекриття багатопотокових варіантів з тестуванням паралельності | Ширший, ніж багатопотоковий фрагмент тестування потоків | Тестування потоків – це одна з додаткових стратегій всередині нього |
Коротше кажучи, тестування паралельності запитує, що одночасний доступ робить із системою, тоді як тестування потоків запитує, чи взагалі один важливий шлях переживає інтеграцію. Команди, які запускають обидва, зазвичай планують тестування потоків спочатку.
Переваги тестування потоків
Цей метод заслужив своє місце в плані інтеграції з кількох практичних причин.
- Ключові бізнес-шляхи перевіряються на ранній стадії, тому перервана передача даних виявляється ще до того, як буде зібрана повна система.
- Інтегратори отримують чітке уявлення про обсяг, оскільки тестова одиниця є розпізнаваною транзакцією, а не аб'єктом ABS.tracмежа t-компоненти.
- Тестування логічних шляхів виконання в системному контексті виявляє помилки, які ізольовані тестування компонентів не бачить.
- Багатопотокові виконання виявляють дефекти паралельності — тупики, умови гонки та конфлікти ресурсів — які в іншому випадку досягли б робочого середовища.
- Інкрементальна інтеграція забезпечує малу поверхню налагодження, оскільки за раз додається лише один потік.
- Результати безпосередньо впливають на регресійне тестування, оскільки прохідний потік є очевидним кандидатом для набору регресій.
Недоліки потокового тестування
- Для багатопотокового тестування найбільшою проблемою є можливість запрограмувати відтворюваний тест для модульного тесту.
- Написання модульних тестів для багатопотокового коду є складним завданням.
- Критерії тестування для багатопотокового тестування відрізняються від однопотокового тестування. Для багатопотокового тестування такі фактори, як розмір пам'яті, ємність сховища та проблеми з синхронізацією, змінюються залежно від виклику коду на різному обладнанні.
- Потоки не можна протестувати, поки модулі, які вони перетинають, не стануть доступними, тому планування залежить від порядку інтеграції.
- Періодичні збої легко ігнорувати як шум навколишнього середовища, що робить дисциплінований журнал необхідним.

