Есть ли лучший способ автоматизировать тестирование утечки памяти?

Question

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

Есть какой-нибудь совет по этому поводу?

Answer 1

Как правило, лучший способ - это делать только то, что, по вашему мнению, вызывает утечку, и, ну, в общем, смотреть, как память только растет.

Но, конечно, вам нужно проверить, что если вы ничего не сделаете в течение этого периода времени, это также не приведет к увеличению памяти.

Из-за этого и в целом запутанной сложной природы отслеживания утечек (особенно в стороннем программном обеспечении) может быть довольно сложно написать для него автоматический тест.

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

Лично у меня была бы отдельная, но все еще частично автоматизированная система для обнаружения утечек, и я запускал ее "время от времени". Если это сторонняя организация, вам нужно будет сделать это только при добавлении новой версии программного обеспечения.

Answer 2

Некоторые инструменты действительно облегчают обнаружение утечек памяти (например, valgrind)

То, что вы могли бы сделать, это смоделировать «интенсивный» ввод вашей программы (через оболочку скрипта) и проанализировать результат valgrind, чтобы увидеть, были ли утечки памяти. Вы также можете использовать его интенсивно (и в течение длительного времени). Valgrind сообщит вам в конце программы, если какая-либо память просочилась (и даже приблизительно, где она просочилась!)

Answer 3

Утечки памяти становятся очевидными при долгом запуске программы. Настройте тестовый компьютер для длительных тестов, где программа запускается один раз, а затем работает в течение нескольких дней без перезапуска. Иметь определенный набор регрессионных тестов, который выполняется снова и снова. Когда потребление памяти достигает некоторого порога, тесты считаются неудачными.

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

Это другой подход, чем обычные регрессионные тесты, когда вы просто запускаете программу один раз для каждого теста или набора тестов.