Параллельное тестирование - Concurrent testing

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

Исследование и изучение параллелизма программ началось в 1950-х годах,[3] с исследованиями и изучением параллелизма программ тестирования, появившимися в 1960-х годах.[4] Примерами проблем, которые может выявить тестирование параллелизма, являются неправильный доступ к общей памяти и неожиданная последовательность выполнения сообщения или потока.[5]:2[1] Спор за ресурсы разрешающая способность, планирование, тупик избегание инверсия приоритета и условия гонки также выделены.[6]:745

Избранная история и подходы к тестированию параллелизма

Подходы к параллельному тестированию могут быть на ограниченном уровне модульного тестирования вплоть до уровня системного тестирования.[7]

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

  • Выполните тест один раз.[8]:63
Это считалось неэффективным для тестирования параллелизма в недетерминированной системе и было эквивалентно тестированию последовательной непараллельной программы в системе.
  • Выполнение одной и той же тестовой последовательности несколько раз.[8]:63
Считается вероятным обнаружить некоторые проблемы при недетерминированном выполнении программного обеспечения.
Позже это стало называться недетерминированным тестированием.[9]
  • Детерминированное тестирование.[8]:63
Это подход для установки системы в определенное состояние, чтобы код мог выполняться в известном порядке.
  • Проверка доступности[9][10]
Попытка протестировать комбинации последовательностей синхронизации для указанного входа (доступ к общей переменной не нарушен, эффективное тестирование переменных условий гонки). Последовательность обычно получается для недетерминированного выполнения теста.
  • Структурные подходы / Статический анализ
Анализ структуры кода и инструменты статического анализа.
Примером был эвристический подход[11]
Это привело к разработке программы проверки кода, например jlint.[12] Исследование и сравнение программ статического анализа и проверки кода на предмет ошибок параллелизма [13]
Смотрите также Список инструментов для статического анализа кода
  • Многопользовательский подход
Это подход к тестированию параллелизма программ, рассматривая доступ нескольких пользователей, одновременно обслуживая разных пользователей или задачи.[2][6] :745

Тестирование программного обеспечения и параллелизма системы не следует путать с Стресс-тестирование, что обычно связано с загрузкой системы сверх определенных пределов. Тестирование параллельных программ может выявить проблемы, когда система работает в установленных пределах. Большинство вышеперечисленных подходов не основаны на перегрузке системы. Немного литературы[6]:745 заявляет, что тестирование параллелизма является предварительным условием стресс-тестирования.

Уроки, извлеченные из исследования характеристик ошибок параллелизма

Исследование 2008 г.[11] проанализировали базы данных ошибок в избранном программном обеспечении с открытым исходным кодом. Считалось, что это первое реальное исследование ошибок параллелизма. 105 ошибок были классифицированы и проанализированы как ошибки параллелизма, при этом 31 ошибка была тупиковой, а 74 - не тупиковой. В исследовании было сделано несколько выводов для возможного последующего наблюдения и расследования:

  • Примерно одна треть ошибок параллелизма вызывает сбои или зависание программ.
  • Большинство ошибок параллелизма без взаимоблокировки атомарность или нарушение порядка.
Т.е. сосредоточение внимания на атомарности (защищенном использовании общих данных) или последовательности потенциально может найти большинство ошибок, не связанных с взаимоблокировкой.
  • Большинство ошибок параллелизма связаны с 1 или 2 потоками.
Т.е. Большое количество одновременных пользователей / использования не является причиной этих ошибок. Есть предположение, что попарное тестирование может быть эффективным для выявления подобных ошибок.
  • Более 20% (7/31) ошибок взаимоблокировки возникали в одном потоке.
  • Большинство ошибок взаимоблокировки параллелизма (30/31) затрагивают только один или два ресурса.
Подразумевается, что попарное тестирование с точки зрения использования ресурсов может применяться для выявления тупиковых ситуаций.

Смотрите также

Рекомендации

  1. ^ а б Ван, Чао; Сказал, Махмуд; Гупта, Арти (21–28 мая 2011 г.). Систематическое тестирование параллелизма, управляемое охватом. ICSE '11 Материалы 33-й Международной конференции по программной инженерии. Вайкики. С. 221–230.
  2. ^ а б Дастин, Эльфриде (28 декабря 2002 г.). Эффективное тестирование программного обеспечения: 50 способов улучшить тестирование программного обеспечения. Эддисон-Уэсли Лонгман. п. 186. ISBN  0201794292.
  3. ^ Leiner, A.L .; Notz, W.A .; Smith, J.L .; Вайнбергер, А. (июль 1959 г.). «ПИЛОТ - Новая многокомпьютерная система». Журнал ACM. 6 (3): 313–335. Дои:10.1145/320986.320987. S2CID  19867617.
  4. ^ Дейкстра, Эдсгер В. (май 1968 г.). «Структура« Мультипрограммной системы »». Коммуникации ACM. 11 (5): 341–346. Дои:10.1145/363095.363143. S2CID  2021311.
  5. ^ «Параллельное тестирование программного обеспечения: систематический обзор» (PDF). Архивировано 24 сентября 2015 года.. Получено 4 марта 2014.CS1 maint: BOT: статус исходного URL-адреса неизвестен (связь)
  6. ^ а б c Биндер, Роберт В. (1999). Тестирование объектно-ориентированных систем: модели, шаблоны и инструменты. Эддисон-Уэсли Лонгман. ISBN  0-201-80938-9.
  7. ^ Мело, Сильвана Морита; Соуза, Симоне ду Росио Сенгер де; Соуза, Пауло Сержио Лопес де; Карвер, Джеффри С. (2017). Как протестировать параллельное ПО: подход к выбору методов тестирования. Конференция по системам, программированию, языкам и приложениям: программное обеспечение для человечества - SPLASH.
  8. ^ а б c К.С., Тай (20–22 сентября 1989 г.). Тестирование параллельного ПО. Материалы тринадцатой ежегодной международной конференции по компьютерному программному обеспечению и приложениям. Орландо, Флорида, США, США. С. 62–64.
  9. ^ а б Хван, Кван-Хван; Тай, Куо-Чунг; Хуанг, Тин-Лу (1995). «Тестирование доступности: подход к тестированию параллельного программного обеспечения». Международный журнал программной инженерии и инженерии знаний. 5 (4): 493–510. Дои:10.1142 / S0218194095000241.
  10. ^ Ци, Сяофан; Ли, Юэран (23–24 ноября 2018 г.). Параллельное тестирование доступности на основе Hadoop MapReduce. -я международная конференция, SATE 2018. Шэньчжэнь, Гуандун, Китай. С. 173–184. Дои:10.1007/978-3-030-04272-1_11.
  11. ^ а б Лу, Шань; Пак, Соён; Со, Ынсу; Чжоу, Юаньюань (1–5 марта 2008 г.). Учимся на ошибках: всестороннее исследование реальных характеристик ошибок параллелизма. ASPLOS XIII Труды 13-й международной конференции по архитектурной поддержке языков программирования и операционных систем. Сиэтл, Вашингтон, США. С. 329–339.
  12. ^ Арто, Сирилла; Биэр, Армин (27–28 августа 2001 г.). Применение статического анализа к крупномасштабным многопоточным программам Java. Слушания 2001 Австралийская конференция по разработке программного обеспечения. Канберра, Австралия, Австралия. С. 68–75.
  13. ^ Манзур, Нуман; Мунир, Хусан; Моайед, Мисаг (27–30 ноября 2012 г.). Сравнение инструментов статического анализа для поиска ошибок параллелизма. 2012 г. 23-й Международный симпозиум IEEE по проектированию надежности программного обеспечения. Даллас, Техас, США. С. 129–133.

Общие ссылки