Differences

This shows you the differences between two versions of the page.

--- mdd:prediction_models [2026/08/29 07:53] – Bulk sync migration user
+++ mdd:prediction_models [2026/08/29 07:59] (current) – external edit 127.0.0.1
@@ Line 1: / Line 1: @@
+====== Использование ошибок пре-релизных тестов для построения ранних моделей прогнозирования пост-релизных дефектов ======
+=== Kim Herzig ===
+**Cambridge, United Kingdom**
+**Kim Herzig. 2014. Using Pre-Release Test Failures to Build Early Post-Release Defect Prediction Models. In Proceedings of the 2014 IEEE 25th International Symposium on Software Reliability Engineering (ISSRE '14). IEEE Computer Society, Washington, DC, USA, 300-311. DOI=[[http://dx.doi.org/10.1109/ISSRE.2014.21|http://dx.doi.org/10.1109/ISSRE.2014.21]]**
+==== Введение ====
+Качество программного обеспечения является одной из наиболее актуальных проблем для большинства разработчиков программного обеспечения. В то же время, компании, выпускающие ПО, также стремятся сократить свои циклы выпуска для удовлетворения потребностей рынка, сохраняя при этом качество продукции. Определение проблемных областей кода становится все более и более важным. В последние годы стали популярны модели прогнозирования дефектов и были изучены многие различные метрики кода и разработки.
+Мы покажем, что тестовые показатели, собранные в процессе разработки Windows 8 могут быть использованы для создания пре- и пост-моделей прогнозирования дефектов на ранних стадиях процесса разработки ПО. Модели качества должны быть доступны на ранних стадиях процесса разработки и должны быть способны приспособиться к изменениям кода.
+Сбор результатов выполнения теста обеспечивает историю поведения программы в течение отдельных периодов развития.
+Мы не будем рассматривать вероятностную модель возможной эволюции качества продукта, а скорее будем исследовать корреляцию между тесткейсами в долгосрочной разработке и качеством кода ПО. Для этой цели мы собираем и интерпретируем результаты тестирования системы и интеграции, собранные во время разработки Windows 8. Кроме того, мы представляем серию метрик выполнения тестов, которые обобщают результаты.
+==== Основная часть ====
+[[mdd:_detail:mdd:ветки_разработки.jpg|]]
+Рис.1
+Ветки (структура отображена на рис.1):
+Структура веток для больших программных систем, таких как операционная система Windows от Microsoft, являются сложными. Но вкратце, ветки организованы в виде древовидной структуры с устойчивой главной веткой в качестве корневого узла. Отрасли сгруппированы по уровням. Разработчики вносят изменения в код в ветках разработки, на рисунке они показаны как отделения от узлов ветвления дерева, что позволяет им работать в изоляции.
+Ворота качества: Каждое ребро в дереве Windows, представляет собой путь интегрирования от одной ветки к другой, более низкого уровня. На каждом из этих путей интеграции стоят ворота качества, которые являются крупными системами тестирования, проверяющие то, что изменения кода соответствуют стандартам качества.
+Ворота качества выполняют тесткейсы в различных контекстах исполнения: на разных ветках, на различных архитектурах (например, x86), на различных языках (например, EN-US), а также на различных типах сборки (с и без отладочных символов). Сочетание этих четырех факторов (ветви, архитектуры, типы сборки и язык) определяет контекст выполнения тесткейса. Тесткейсы, выполненные в различных контекстах выполнения, должны обрабатываться отдельно.
+Тестовые метрики, используемые в данном исследовании.
+Для каждой метрики мы собрали абсолютные и относительные цифры. Например:
+FPFailures - Количество индивидуальных сбоев тестов из-за запросов тестирования и инфраструктуры; по всем веткам.
+TPFailures - Количество сбоев отдельных тестов, которые падали по крайней мере один раз; по всем веткам.
+FPGates – Количество ворот качества, которые сообщили по крайней мере об одном ложном положительный сбое теста.
+TPGates – Количество сбоев отдельных тестов, которые падали по крайней мере один раз
+про другие будет рассказано чуть позже.
+Будем поступать следующим образом:
+Шаг 1) Для каждого изменения кода, мы получаем последовательность ветвей и меток времени, которые определяют, когда и где было применено изменение. Используя эту последовательность, мы можем определить ворота качества, которые тестировали это изменение на всех ветках.
+Шаг 2) Затем мы разделяем ворота качества на отдельные тесткейсы, их контексты выполнения, и результаты каждого выполняемого теста к соответствующему изменению кода.
+Шаг 3) Находим файлы, которые были, соответственно, изменены и связываем их с метриками. Мы собираем тестовые метрики нескольких изменений в один объект, используя следующие функции агрегации: сумма, среднее значение, медиана, максимум.
+Для того, чтобы оценить качество и надежность тестов, мы классифицируем данные на три категории: (1) тестируется, (2) тест на ошибку, но выдаётся ложное сообщение (ложный, положительный результат: FP), или (3) тест нормальный и код выдает отчет (правильный, положительный результат: TP). Чтобы отличить ложные сообщения от ошибок тестирования из-за проблем кода, мы используем сообщения об ошибках. Основной причиной FP являются тестовые и инфраструктурные ошибки, например, тест требует удаленного сервера, для создания тестового входа, но удаленный сервер недоступен. FP могут иметь серьезные последствия, как требование ручной проверки.
+Будем считать количество ошибок отдельных тестов и ворот качества. Таким образом, чем чаще файл или двоичный файл изменяется, тем больше тестов будет выполняться и тем больше результатов испытаний мы сможем связать с кодовыми структурами, также можно будет отследить более серьезные и широкие проблемы.
+Следующая группа тестовых метрик подсчитывает количество неудач при различных контекстах выполнения тестов. Для оценки серьёзности проблемы мы будем считать эти метрики в относительных величинах.
+Пока что ни один из рассмотренных показателей не отражает возможные зависимости между наблюдаемыми ошибками тестирования. Определим тестовые всплески по двум параметрам:
+) Промежуток между двумя ошибками в последовательности(G) – если меньше заранее заданной константы G, то относятся к одному всплеску.
+) Размер всплеска (B) – минимальное число последовательных (по отношению к указанной величине промежутка) истинно положительных сбоев тестов. Если число истинно положительных ошибок тестирования меньше чем константа B, то она не будет рассматриваться.
+Рассмотрим метрики обзора кода (Code Review) – индикаторы того, был ли код изменения протестирован вручную или нет. Эти метрики будут указывать на присутствие в коде ошибок, которые трудно обнаружить, что говорит о качестве и читаемости кода.
+Для количественной оценки качества продукта во время его разработки и поддержки будем рассматривать количество дефектов перед и после выпуска продукта. Для этого будем извлекать все сообщения об ошибках, предварительно их отфильтровав по времени и меткам «решено», «закрыто» и так далее, сопоставлять им изменения кода.
+Во всех экспериментах, из-за особенностей моделей прогнозирования Microsoft Windows мы будем явно различать два уровня: двоичные файлы и файлы исходного кода. К тому же прогнозирование дефекты на уровне исходных файлов является более сложным.
+Для предсказания пост-релизных дефектов мы разделили общий набор данных как 2/3 на обучение и 1/3 на тестирования с использованием стратифицированной выборки. Кроме того, мы использовали исходные данные наборы 100 раз (100-кратная кросс-проверка) с использованием нашей схемы разделения для того, чтобы генерировать 100 подмножеств для обучения и тестирования.
+Мы провели эксперименты с использованием статистического программного обеспечения (R пакет каретки Макса Куна), чтобы обучать, настраивать и тестировать набор из шести различных моделей машинного обучения.
+Кроме того, перед применением анализа главных компонент (PCA) мы удалили постоянные метрические и высоко коррелирующие между собой метрики. Используя PCA, мы выбрали основные компоненты, на которые приходилось 95% дисперсии.
+Сделаем 4 категории и в качестве меры оценки мы получим следующие переменные:
+precision (точность) = TP (TP + FP),
+recall(полнота) = TP + (TP + FN), где:
+TP - Прогнозируемый и наблюдаемый
+FP – Прогнозируемые, но не наблюдаемый
+FN – Не прогнозируемый и наблюдаемый
+TN – Не прогнозируемый и не наблюдаемый
+precision == 1, означает классификацию исправного кода как дефектного.
+recall == 1, означает, что модель классификации не сообщает ни о каких-либо ложных негативах.
+Для исследования того, какие из наших тестовых метрик поведения выполнения, больше всего подходят для прогнозирования дефектов кода пре- и пост-релиза, мы использовали функцию, использующую так называемые кривые ROC.
+==== Заключение ====
+Из результатов корреляции между тестовыми метриками и количества пост-релизных дефектов мы можем сказать, что число архитектур, на которых происходит сбой, отражает качество выпускаемого кода. Если ошибки происходят на нескольких архитектурах, то изменения могут быть более серьезными.
+Медиана для precision по всем моделям лежит на уровне 0,75, медиана по recall лежит на 0,44
+Как и ожидалось, модели прогнозирования на уровне файлов работают хуже, чем модели на уровне двоичных файлов. Медиана для precision этих моделей лежит в 0,63 и их медиана по recall лежит на 0,19.
+Модели прогнозирования для Windows 8 обученные на тестовых метриках показали относительно высокие значения precision и recall по сравнению с предыдущими моделями прогнозирования для ранее зарегистрированных Windows. Также, было показано, что показатели тестов могут быть использованы для прогнозирования ошибок между отдельными этапами развития, а не между отдельными выпусками, и что тестовые показатели являются более многозначительными, чем простые подсчеты предыдущих ошибок. Первоначальный анализ важности отдельных показателей показал, что тестовые всплески, ложные тестовые сигналы ошибок, а также показатели количества различных свойств контекста выполнения являются одними из наиболее влиятельных метрик. Необходимо провести большую работу, чтобы подтвердить эти результаты и закрепить текущий набор коррелированных метрик тестирования и найти более плотный и оптимальный набор.