Что такое статистическая отладка?

Question

Что такое статистическая отладка? Я еще не нашел четкого и краткого объяснения, но этот термин звучит впечатляюще.

Это просто тема исследования или она где-то используется для реальной разработки? Другими словами: поможет ли мне найти ошибки в моей программе?

Answer 1

Я создал статистическую отладку вместе с различными замечательными сотрудниками на протяжении многих лет. Хотел бы я заметить твой вопрос несколько месяцев назад! Но если вам все еще интересно, возможно, этот поздний ответ будет лучше, чем ничего.

На очень высоком уровне статистическая отладка - это идея использования статистических моделей успеха / неудачи программы для отслеживания ошибок. Эти статистические модели раскрывают взаимосвязи между определенным поведением программы и возможным успехом или неудачей прогона. Например, предположим, вы заметили, что в программе есть определенная ветка, которая иногда идет влево, иногда вправо. И вы также заметили, что прогоны, в которых ветвь идет влево, хороши, но прогоны, в которых ветвь идет вправо, с вероятностью 75% сбоят. Таким образом, здесь есть статистическая корреляция, которую, возможно, стоит изучить более внимательно. Статистическая отладка формализует и автоматизирует этот процесс обнаружения программных (ошибочных) действий, которые коррелируют с ошибками, тем самым направляя разработчиков к основным причинам ошибок.

Возвращаясь к исходному вопросу:

Это просто тема исследования или она где-то используется для реальной разработки?

Это в основном тема исследования, но она существует в «реальном» мире двумя способами:

1. Общедоступное развертывание проекта Cooperative Bug Isolation Project обнаруживает ошибки в различных программах с открытым исходным кодом, работающих под Fedora Linux. Вы можете загрузить предварительно инструментированные пакеты и каждый раз, когда вы их используете, вы предоставляете нам данные, чтобы помочь нам находить ошибки.

2. Microsoft выпустила Holmes, реализацию статистической отладки для .NET . Он прекрасно интегрирован в Visual Studio и должен быть очень простым способом использовать статистическую отладку, чтобы помочь находить собственные ошибки в собственном коде. Я тесно сотрудничал с Microsoft Research по Холмсу, и это хорошие умные люди, которые знают, как выпускать высококачественные инструменты.

Следует иметь в виду одно предупреждение: для отладки статистики необходимы достаточные необработанные данные для построения хороших статистических моделей. В публичном развертывании CBI эти необработанные данные поступают от реальных конечных пользователей. Я думаю, что с Холмсом Microsoft предполагает, что необработанные данные будут получены из собственных автоматических модульных тестов и ручных тестов. То, что не будет работать , - это код без запусков или только с ошибочными запусками, но без успешных контрпримеров. Статистическая отладка работает на контрасте между хорошими и плохими прогонами, поэтому вам нужно кормить их обоих. Если вам нужны инструменты для поиска ошибок без прогонов, вам понадобится какой-то статический анализ. Я тоже исследую это, но это не статистическая отладка. : -)

Надеюсь, это помогло и было не слишком долго. Я рад ответить на любые дополнительные вопросы. Удачной охоты на насекомых!

Answer 2

это когда вы отправляете программное обеспечение со словами "ну, это вероятно работает ..." ; -)

РЕДАКТИРОВАТЬ: это тема исследования , где машинное обучение и статистическая кластеризация используются, чтобы попытаться найти шаблоны в программах, которые являются хорошими предикторами ошибок, чтобы определить, где больше ошибок могут скрываться.

Answer 3

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

Статистическая выборка требует проверки определенного процента продуктов, чтобы убедиться, что все они без проблем. Это сводит к минимуму усилия, связанные с риском возникновения некоторых проблем, и является абсолютно необходимым, когда процесс тестирования является деструктивным - если вы проводите деструктивное тестирование на 100% своей производственной линии, это не собирается оставлять много для распространения :-)

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

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

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

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