Как измерить надежность?
https://stackoverflow.com/questions/2354379
-
23-09-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianВопрос
Я работаю над диссертацией об обеспечении качества продукта.Продуктом в данном случае является веб-сайт.Я выделил несколько признаков качества и методов измерения.
Одним из атрибутов качества является "Надежность".Я хочу как-то в этом убедиться, но я не могу найти никакой полезной информации о том, как сделать это объективным образом.
Существует ли какая-либо статическая или динамическая метрика, которая могла бы обеспечить надежность?Т. е., подобно покрытию модульным тестированием, есть ли способ обеспечить подобную надежность?Если да, то есть ли какой-нибудь (бесплатный) инструмент, который может это сделать?
Есть ли у кого-нибудь опыт работы с таким инструментом?
И последнее, но не менее важное: возможно, существуют другие способы определения надежности, если у вас есть какие-либо идеи по этому поводу, я весь внимание.
Заранее большое спасибо.
Решение
Что ж, короткий ответ - "нет". Надежность может означать многое, но лучшее определение, которое я могу придумать, - "действовать правильно в любой ситуации". Если вы отправляете неверный HTTP-заголовок на надежный веб-сервер, он не должен аварийно завершать работу.Он должен возвращать точно правильный тип ошибки и где-то регистрировать событие, возможно, настраиваемым способом.Если надежный веб-сервер работает очень долго, объем его памяти должен оставаться неизменным.
Многое из того, что делает систему надежной, - это то, как она справляется с крайними случаями.Хорошие модульные тесты являются частью этого, но вполне вероятно, что модульных тестов ни для одной из проблем, имеющихся в системе, не будет (если бы эти проблемы были известны, разработчики, вероятно, исправили бы их и только потом добавили тест).
К сожалению, практически невозможно измерить надежность произвольной программы, потому что для этого вам нужно знать, что эта программа должна делать.Если бы у вас была спецификация, вы могли бы написать огромное количество тестов, а затем запустить их против любого клиента в качестве теста.Например, посмотрите на тест браузера Acid2.Он тщательно измеряет, насколько хорошо тот или иной веб-браузер соответствует стандарту простым и воспроизводимым способом.Это настолько близко, насколько это возможно, и люди указали на множество недостатков такого подхода (например, является ли программа, которая чаще выходит из строя, но делает одну дополнительную вещь в соответствии со спецификацией, более надежной?)
Однако существуют различные проверки, которые вы могли бы использовать в качестве приблизительной числовой оценки работоспособности системы.Покрытие модульных тестов довольно стандартное, как и его собратья, покрытие ветвей, покрытие функций, покрытие операторов и т.д.Еще один хороший выбор - "ворсистые" программы, такие как FindBugs.Это может указывать на потенциальные проблемы.О проектах с открытым исходным кодом часто судят по тому, как часто и недавно делаются коммиты или выпускаются релизы.Если в проекте есть система исправлений ошибок, вы можете измерить, сколько ошибок было исправлено, и их процент.Если вы измеряете конкретный экземпляр программы, особенно с большой активностью, наработка на отказ (среднее время между отказами) является хорошим показателем надежности (см. Ответ Филиппа)
Однако эти измерения на самом деле не говорят вам, насколько надежна программа.Это всего лишь способы догадаться об этом.Если бы было легко определить, надежна ли программа, мы бы, вероятно, просто заставили компилятор проверить это.
Удачи вам с вашей диссертацией!Я надеюсь, вы придумаете какие-нибудь новые интересные измерения!
Другие советы
Вы могли бы изучить среднее время между отказами как мера устойчивости.Проблема в том, что это теоретическая величина, которую трудно измерить, особенно до того, как вы развернете свой продукт в реальной ситуации с реальными нагрузками.Частично это связано с тем, что тестирование часто не охватывает реальные проблемы масштабируемости.
В нашей книге по фаззингу (автор: Таканен, ДеМотт, Миллер) есть несколько глав, посвященных метрикам и охвату негативного тестирования (робастность, надежность, проверка грамматики, фаззинг, множество названий одного и того же).Также я попытался обобщить наиболее важные аспекты технического документа нашей компании здесь:
http://www.codenomicon.com/products/coverage.shtml
Фрагмент оттуда:
Покрытие можно рассматривать как сумму двух характеристик: точности и достоверности.Точность связана с покрытием протокола.Точность тестирования определяется тем, насколько хорошо тесты охватывают различные сообщения протокола, структуры сообщений, теги и определения данных.С другой стороны, точность показывает, насколько точно тесты могут обнаружить ошибки в различных областях протокола.Таким образом, точность можно рассматривать как форму покрытия аномалий.Однако точность и аккуратность — довольно абстрактные понятия, поэтому нам нужно будет рассмотреть более конкретные показатели для оценки охвата.
Первый аспект анализа покрытия связан с поверхностью атаки.Анализ требований к тестированию всегда начинается с определения интерфейсов, которые необходимо протестировать.Количество различных интерфейсов и протоколов, которые они реализуют на разных уровнях, определяют требования к фаззерам.Для каждого протокола, формата файла или API может потребоваться свой тип фаззера в зависимости от требований безопасности.
Вторая метрика покрытия связана со спецификацией, которую поддерживает фаззер.Этот тип метрики легко использовать с фаззерами на основе моделей, поскольку основу инструмента составляют спецификации, использованные для создания фаззера, и поэтому их легко перечислить.Фаззер на основе модели должен охватывать всю спецификацию.Принимая во внимание, что фаззеры на основе мутаций не обязательно полностью покрывают спецификацию, поскольку реализация или включение одного образца обмена сообщениями из спецификации не гарантирует охвата всей спецификации.Обычно, когда фаззер на основе мутаций заявляет о поддержке спецификации, это означает, что он совместим с тестовыми объектами, реализующими спецификацию.
Третьим наиболее важным показателем, особенно в отношении фаззинга протоколов, является уровень сохранения состояния выбранного подхода к фаззингу.Полностью случайный фаззер обычно проверяет только первые сообщения в сложных протоколах с отслеживанием состояния.Чем более учитывающим состояние является используемый вами подход к фаззингу, тем глубже фаззер может проникнуть в сложные обмены протоколами.Статусность — сложное требование для инструментов фаззинга, поскольку это скорее показатель для определения качества используемой модели протокола, и поэтому его можно проверить только путем запуска тестов.
Я надеюсь, что это было полезно.У нас также есть исследования по другим метрикам, например, по покрытию кода и другим более или менее бесполезным данным.;) Метрики — отличная тема для дипломной работы.Напишите мне по адресу ari.takanen@codenomicon.com, если вы хотите получить доступ к нашим обширным исследованиям по этой теме.
Вы могли бы изучить среднее время между отказами в качестве показателя надежности.
Проблема с "наработкой на отказ" заключается в том, что она обычно измеряется положительным трафиком, в то время как сбои часто происходят в неожиданных ситуациях.Это не дает никаких указаний на надежность.Независимо от того, всегда ли веб-сайт остается включенным в лабораторной среде, он все равно будет взломан через секунду в Интернете, если у него есть слабое место.
