Как измерить надежность?

Что ж, короткий ответ - «нет». Надежность может означать многое, но лучшее определение, которое я могу придумать, - это «правильно работать в любой ситуации». Если вы отправите плохой HTTP-заголовок на надежный веб-сервер, он не должен дать сбой. Он должен возвращать именно тот тип ошибки, и он должен где-то регистрировать событие, возможно, настраиваемым способом. Если надежный веб-сервер работает очень долго, объем его памяти должен оставаться неизменным.

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

К сожалению, практически невозможно измерить надежность произвольной программы, потому что для этого вам нужно знать, что эта программа должна делать. Если бы у вас была спецификация, вы могли бы написать огромное количество тестов, а затем запустить их для любого клиента в качестве теста. Например, посмотрите тест браузера Acid2. Он тщательно измеряет, насколько хорошо тот или иной веб-браузер соответствует стандарту, простым и повторяемым образом. Это настолько близко, насколько это возможно, и люди указали на множество недостатков такого подхода (например, программа, которая дает сбой чаще, но делает одну дополнительную вещь в соответствии со спецификацией более надежной?)

Однако существуют различные проверки, которые можно использовать для грубой численной оценки состояния системы. Покрытие модульными тестами является довольно стандартным, как и его братья и сестры, покрытие ветвей, покрытие функций, покрытие операторов и т. Д. Еще один хороший выбор - это программы "lint", такие как FindBugs. Это может указывать на потенциальные проблемы. О проектах с открытым исходным кодом часто судят по тому, как часто и недавно были сделаны коммиты или выпущены релизы. Если в проекте есть система ошибок, вы можете измерить, сколько ошибок было исправлено, и их процент. Если есть конкретный экземпляр программы, которую вы измеряете, особенно с большой активностью, MTBF (среднее время наработки на отказ) является хорошим показателем надежности (см. Ответ Филиппа)

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

Удачи с диссертацией! Надеюсь, у вас появятся новые классные измерения!

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

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

http://www.codenomicon.com/products/coverage.shtml

Фрагмент оттуда:

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

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

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

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

Я надеюсь, что это было полезно. У нас также есть исследования по другим показателям, таким как покрытие кода и другие более или менее бесполезные данные. ;) Метрики - отличная тема для дипломной работы. Напишите мне по адресу [email protected], если вы хотите получить доступ к нашим обширным исследованиям по этой теме.

Надежность очень субъективна, но вы можете взглянуть на FingBugs, Cobertura и Hudson, которые при правильном вместе взятые, со временем могут дать вам чувство безопасности и надежности программного обеспечения.

Вы можете посмотреть на среднее время наработки на отказ в качестве меры устойчивости.

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