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

Question

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

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

Есть ли статическая или динамическая метрика, которая могла бы измерить надежность? То есть, как покрытие модульных тестов, есть ли способ измерить устойчивость таким образом? Если так, есть ли (бесплатный) инструмент, который может сделать такую ​​вещь?

У кого-нибудь есть опыт работы с такими инструментами?

И последнее, но не менее важное: возможно, есть и другие способы определения надежности, если у вас есть идеи по этому поводу, я весь слух.

Заранее большое спасибо.

Answer 1

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

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

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

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

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

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

Answer 2

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

Answer 3

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

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

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

---

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

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

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

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

---

Надеюсь, это было полезно. У нас также есть исследования по другим показателям, таким как анализ покрытия кода и других более или менее бесполезных данных. ;) Метрика - отличная тема для дипломной работы. Напишите мне по адресу ari.takanen@codenomicon.com, если вы заинтересованы, чтобы получить доступ к нашим обширным исследованиям по этой теме.

Answer 4

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

Answer 5

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

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