Брутальная тестилка программ

1

2

Вот примерно что я хочу: есть запущенный процесс и нужно натравить на него программу-тестилку. Что может делать эта тестилка: проверяет открытые файлы и рандомно их удаляет/закрывает, шлёт posix сигналы процессу случайным образом, стопает и продолжает работу процесса, подключается к слушающему сокету и пишет туда мусор и т.п. Хотелось бы чтоб такая тестилка ещё могла запускать приложение с разными rlimit, в chroot'е... Ну в общем вы поняли хотелку. Есть ли подобное решение, такая брутальная тестилка?

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

Ссылка

←	Контроль за ресурсами в Haskell-программе.

подскажите алгоритм full outer join

→

проверяет открытые файлы и рандомно их удаляет/закрывает,

Как один процесс может закрыть файл, открый в другом процессе? А удалять файл бесполезно, он же на диске остаётся, пока открыт в другом процессе.

mky ★★★★★
(18.10.14 09:33:53 MSK)

У тебя есть доступ к исходному коду? Или ты просто тестируешь сторонний софт?

uuwaan ★★
(18.10.14 09:47:55 MSK)

Немного не то, но должно помочь в поиске: trinity - «умное» тестирование ядра рандомными вызовами syscall'ов.

Вообще, процесс называется fuzz testing.

mtk ★
(18.10.14 10:06:08 MSK)

Ответ на: комментарий от mky 18.10.14 09:33:53 MSK

Ну gdb может приатачиться к процессу. Ещё есть tcpkill.

Удаление открытых файлов - чтобы понять от каких зависит. Процесс может повторно переоткрыть или для следующего запуска... Тут творчески можно к делу подойти.

nerdogeek ★
(18.10.14 11:44:32 MSK) автор топика

Ответ на: комментарий от uuwaan 18.10.14 09:47:55 MSK

Для тестирования опенсурсных поделок. Код всегда есть.

nerdogeek ★
(18.10.14 11:45:46 MSK) автор топика

Ссылка

Ответ на: комментарий от mtk 18.10.14 10:06:08 MSK

Ясно. Спасибо за наводку. Походу придётся самому велосипедить.

nerdogeek ★
(18.10.14 11:50:21 MSK) автор топика

Ответ на: комментарий от nerdogeek 18.10.14 11:50:21 MSK

Можно сделать обертки для стандартных либсишных функций, собрать их в динамическую библиотеку и подпихнуть через LD_PRELOAD. А уже в обёртках — логгировать или реализовывать желаемые типы сбоев.

Или сделать в виде статической библиотеки и присадить её в Makefile.

uuwaan ★★
(18.10.14 13:26:45 MSK)

Ответ на: комментарий от uuwaan 18.10.14 13:26:45 MSK

Отличная идея! Только вот саппортить будет труднее, по сравнению с внешним супервайзером-тестилкой.

nerdogeek ★
(18.10.14 13:52:58 MSK) автор топика

Ссылка

http://caca.zoy.org/wiki/zzuf

sergej ★★★★★
(18.10.14 14:55:46 MSK)

Ссылка

Ответ на: комментарий от nerdogeek 18.10.14 11:44:32 MSK

tcpkill это сеть, там что угодно может произойти, это можно тестить.

А вот тест типа того, что приатачится к процессу, сделать из его контекста вызов close() и ожидать, что процесс корректно обработает подобное «исчезновение» файлового дескриптора, какой-то странный.

ИМХО, если программа делает read() из локального файла, а ей вдруг возвращается ошибка EBADF, дак это сигнал, что это сбои внутри ядра, возможно из-за глючного железа. Переоткрывать файл и продолжать работать на глючащем железе — зачем закладывать такое поведение в программу?

mky ★★★★★
(18.10.14 17:09:25 MSK)