| Both sides previous revision Previous revision Next revision | Previous revision |
| mdd:prediction_models [2016/12/25 15:49] – dmitry.kud | mdd:prediction_models [2026/08/29 07:59] (current) – external edit 127.0.0.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 могут иметь серьезные последствия, как требование ручной проверки. |
| | |
| | Будем считать количество ошибок отдельных тестов и ворот качества. Таким образом, чем чаще файл или двоичный файл изменяется, тем больше тестов будет выполняться и тем больше результатов испытаний мы сможем связать с кодовыми структурами, также можно будет отследить более серьезные и широкие проблемы. |
| | |
| | Следующая группа тестовых метрик подсчитывает количество неудач при различных контекстах выполнения тестов. Для оценки серьёзности проблемы мы будем считать эти метрики в относительных величинах. |
| | Пока что ни один из рассмотренных показателей не отражает возможные зависимости между наблюдаемыми ошибками тестирования. Определим тестовые всплески по двум параметрам: |
| | 1) Промежуток между двумя ошибками в последовательности(G) – если меньше заранее заданной константы G, то относятся к одному всплеску. |
| | 2) Размер всплеска (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. Также, было показано, что показатели тестов могут быть использованы для прогнозирования ошибок между отдельными этапами развития, а не между отдельными выпусками, и что тестовые показатели являются более многозначительными, чем простые подсчеты предыдущих ошибок. Первоначальный анализ важности отдельных показателей показал, что тестовые всплески, ложные тестовые сигналы ошибок, а также показатели количества различных свойств контекста выполнения являются одними из наиболее влиятельных метрик. Необходимо провести большую работу, чтобы подтвердить эти результаты и закрепить текущий набор коррелированных метрик тестирования и найти более плотный и оптимальный набор. |