Подход к тестированию для многопоточного программного обеспечения

Как упоминает Лен Холгейт, я бы предложил провести рефакторинг (при необходимости) и создать интерфейсы для частей кода, где разные потоки взаимодействуют с объектами, несущими состояние. Затем эти части кода можно протестировать отдельно от кода, содержащего фактическую функциональность. Чтобы проверить такой модульный тест, я бы подумал об использовании инструмента покрытия кода (для этого я использую gcov и lcov), чтобы убедиться, что все в поточно-безопасном интерфейсе покрыто.

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

Некоторые предложения:

• Используйте закон больших чисел и выполняйте тестируемую операцию не только один раз, но и несколько раз. раз.
• Проведите стресс-тест вашего кода, преувеличивая сценарии. Например. для тестирования вашего класса, содержащего мьютекс, используйте сценарии, в которых код, защищенный мьютексом:
  • очень короткий и быстрый (одна инструкция)
  • занимает много времени (спите с большое значение)
  • содержит явные переключатели контекста (Sleep (0))
• Запустите тест на различных архитектурах. (Даже если ваше программное обеспечение предназначено только для Windows, протестируйте его на одно- и многоядерных процессорах с гиперпоточностью и без нее, а также в широком диапазоне тактовых частот)
• Постарайтесь разработать свой код таким образом, чтобы большая часть его не подвергалась проблемам с многопоточностью . Например. вместо доступа к совместно используемым данным (что требует блокировки или очень тщательно разработанных методов предотвращения блокировок) позвольте вашим рабочим потокам работать с копиями данных и связываться с ними с помощью очередей.Затем вам нужно только проверить свой класс очереди на безопасность потоков.
• Запускайте тесты, когда система простаивает, а также когда она находится под нагрузкой из-за других задач (например, наш сервер сборки часто запускает несколько сборок параллельно. Это само по себе показало много ошибок, связанных с многопоточностью, которые возникали, когда система находилась под нагрузкой.)
• Избегайте установки таймаутов. Если такое утверждение не удается, вы не знаете, поврежден ли код или слишком короткое время ожидания. Вместо этого используйте очень большой тайм-аут (чтобы убедиться, что тест в конечном итоге не сработает). Если вы хотите проверить, что операция не занимает больше определенного времени, измерьте продолжительность, но не используйте для этого тайм-аут.

Не совсем ответ:

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

• Тип процессора
• Скорость процессора
• Количество процессоров/ядер
• Уровень оптимизации
• Работа внутри или вне отладчика
• Операционная система

Наверняка есть еще предпосылки, о которых я забыл.

Поскольку MT-баги так сильно зависят от точного времени выполнения кода, здесь вступает в силу "принцип неопределенности" Гейзенберга: Если вы хотите протестировать MT-баг, вы изменяете время выполнения кода своими "мерами", которые могут предотвратить появление бага...

Временные параметры - это то, что делает MT-баги настолько недетерминированными. Другими словами: У вас может быть программа, которая работает месяцами, а затем в какой-то день происходит сбой, и после этого может работать годами. Если у вас нет отладочных журналов/ дампов ядра и т.д., вы можете никогда не узнать, почему она падает.

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

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

Представьте, что у вас есть класс. Вы хотите, чтобы этот класс автоматически удалялся, если его больше никто не использует. Поэтому вы встраиваете в этот класс счетчик ссылок: (Я знаю, что это плохой стиль - удалять экземпляр класса в одном из его методов. Это происходит из-за упрощения реального кода, который использует класс Ref для обработки подсчитанных ссылок.)

class A {
  private:
    int refcount;
  public:
    A() : refcount(0) {
    }
    void Ref() {
      refcount++;
    }
    void Release() {
      refcount--;
      if (refcount == 0) {
        delete this;
      }
    }
};

Это выглядит довольно просто и не о чем беспокоиться. Но это не потокобезопасно! Потому что "refcount++" и "refcount--" - это не атомарные операции, а три операции:

• чтение refcount из памяти в регистр
• инкремент/уменьшение регистра
• запись refcount из регистра в память

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

• Поток A: прочитать счетчик из памяти в регистр (счетчик: 8)
• Поток A: увеличить регистр
• • CONTEXT CHANGE -
• Поток B: прочитать счетчик из памяти в регистр (счетчик: 8)
• Thread B: increment register
• Thread B: write refcount from register to memory (refcount: 9)
• • CONTEXT CHANGE -
• Thread A: write refcount from register to memory (refcount: 9)

В результате получается: refcount = 9, а должно быть 10!

Это можно решить только с помощью атомарных операций (т.е. InterlockedIncrement() & InterlockedDecrement() в Windows).

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

Но это может произойти! (Вероятность возрастает, если у вас многопроцессорная или многоядерная система, потому что для этого не нужно переключать контекст). Это произойдет через несколько дней, недель или месяцев!

Похоже, вы используете инструменты Microsoft. В Microsoft Research есть группа, которая работает над инструментом, специально разработанным для устранения ошибок параллелизма. Проверьте ШАХМАТЫ . Другие исследовательские проекты, находящиеся на ранних стадиях, - это Cuzz и Featherlite .

VS2010 включает очень красивый профилировщик параллелизма, видео доступно здесь.

Хотя я согласен с ответом @rstevens в том, что в настоящее время не существует способа юнит-тестирования потоковых проблем со 100% уверенностью, есть некоторые вещи, которые я нашел полезными.

Во-первых, какие бы тесты вы ни проводили, убедитесь, что вы запускаете их на множестве разных машин. У меня есть несколько машин для сборки, все они разные, многоядерные, одноядерные, быстрые, медленные и т.д. Их разнообразие хорошо тем, что на разных машинах возникают разные проблемы с потоками. Я регулярно удивлялся, когда добавлял новую машину в свою ферму и внезапно обнаруживал новую ошибку потоковой обработки; и я говорю о том, что новая ошибка обнаруживается в коде, который выполнялся 10000 раз на других машинах и который проявляется 1 из 10 на новой...

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

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

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

Теперь вы проводите все эти тесты много раз на разном оборудовании...

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

Пример того, как я тестирую многопоточный C++ код, можно посмотреть здесь: http://www.lenholgate.com/blog/2004/05/practical-testing.html