Как вы проверяете свои приложения на надежность при плохом поведении ввода-вывода

Question

Почти каждое приложение выполняет операции ввода-вывода, как с диском, так и по сети.

Поскольку мои приложения работают нормально в среде разработки, я хочу быть уверенным, что они по-прежнему будут работать, когда интернет-соединение медленное или нестабильное, или когда пользователь пытается прочитать данные с плохо записанного CD.

Какие инструменты вы бы порекомендовали имитировать:

• медленный ввод / вывод (открытие файлов, закрытие файлов, чтение и запись, перечисление элементов каталога)
• случайные ошибки ввода-вывода
• случайные ответы «отказано в доступе»
• потеря пакетов в tcp / ip
• и т.д ...

---

EDIT:

Windows
Наиболее близким решением для выполнения описанной работы является коммерческое программное обеспечение holodeck (> 900 долл. США).

Linux:
Открытое решение пока не найдено, но тот же эффект может быть достигнуто как указано smcameron и krosenvold.

---

Шаблон для декоратора - хорошая идея. Это потребовало бы обернуть мои классы ввода / вывода, но в результате в среду тестирования. Единственный оставшийся непроверенный код будет в сторонних библиотеках.

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

---

Теперь я знаю, что то, что мне нужно, называется «инъекция неисправности». Я думал, что это обычная производственная линия с множеством решений, о которых я просто не знал. (Кстати, еще одна хорошая идея - «нечеткое тестирование», спасибо Леннарту)

На мой взгляд, проблема все еще не стоит 900 долларов. Я собираюсь реализовать свой собственный инструмент с открытым исходным кодом, основанный на хуках (нацеленный на win32). Я обновлю этот пост, когда закончу. Вернись через 3 или 4 недели или около того ...

Answer 1

То, что вам нужно, - это система тестирования для инъекций. Джеймса Уиттакера «Как взломать программное обеспечение» - хорошее чтение на эту тему и включает компакт-диск со многими необходимыми инструментами.

Answer 2

Я не стал писать свой собственный фильтр файловой системы, как я изначально думал, потому что есть более простое решение.

1. Сетевой ввод / вывод

Я нашел здесь как минимум 2 способа симуляции ошибок ввода / вывода.

a) Запуск виртуальной машины (например, vmware) позволяет настроить пропускную способность и частоту потери пакетов. Vmware поддерживает отладку на компьютере.

б) Запуск прокси на локальном компьютере и туннелирование всего трафика через него. Для связи по upd / tcp может использоваться проксификатор (например, widecap).

2. Файл ввода / вывода

Мне удалось вывести этот сценарий к предыдущему, сопоставив букву диска с сетевым ресурсом, который находится внутри виртуальной машины. Файл ввода / вывода будет медленным.

Существует более дешевая альтернатива: настроить локальный ftp-сервер (например, FileZilla), настроить скорости и использовать для доступа к нему Novell NetDrive.

Answer 3

Вы не говорите, какая ОС, но если это linux или unix-ish, вы можете обернуть open (), read (), write () или любую библиотеку или системный вызов и т. Д. С помощью библиотеки LD_PRELOAD, способной введите ошибки.

Вдоль этих строк: http://scaryreasoner.wordpress.com/2007/11/17/using-ld_preload-libraries-and-glibc-backtrace-function-for-debugging/

Answer 4

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

Это должно дать вам большую гибкость в настройке того, какие операции будут замедляться, добавляя «случайные» ошибки время от времени и т. Д.

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

Answer 5

Проверьте "Fuzz-тестирование": http://en.wikipedia.org/wiki/Fuzzing

Answer 6

Если вы работаете в Linux, вы можете творить чудеса с iptables;

iptables -I ВЫХОД -p tcp --dport 7991 -j DROP

Может также имитировать соединения вверх / вниз. Там много учебников.

Answer 7

Рассмотрим holodeck для некоторых инъекций сбоев. Если у вас есть доступ к запасному оборудованию, вы можете симулировать сетевое ухудшение, используя Netem или коммерческий продукт на его основе Mini -Максвелл , который намного дороже, чем бесплатный, но, возможно, проще в использовании.

Answer 8

Первое, что вам нужно сделать, это определить, что означает «правильный» в этих обстоятельствах. Вы можете проверить только на предмет определения того, какое поведение предполагается.

Тактика тестирования будет зависеть от технологии. В контексте автоматического модульного тестирования я обнаружил, что в ОО-языках, таких как Java, очень полезно использовать различные варианты «насмешливых» или «заглушающих» для передачи, например. неправильно ведет InputStreams к частям моего кода, которые использовали файловый ввод / вывод.

Answer 9

Для этого вам нужно создать тестовую лабораторию. Какой тип приложения вы создаете в любом случае? Вы действительно ожидаете, что приложение получит поврежденные данные?

Метод тестирования, который, как я знаю, пытались люди Microsoft Exchange Server, заключался в отправке шума на сервер. В основном, снабжая все возможные входные данные случайными данными. Таким образом им часто удавалось сбить сервер.

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

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

Помните, когда и как вы декодируете данные. Это все.