Использование ошибок пре-релизных тестов для построения ранних моделей прогнозирования пост-релизных дефектов

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

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

Мы не будем рассматривать вероятностную модель возможной эволюции качества продукта, а скорее будем исследовать корреляцию между тесткейсами в долгосрочной разработке и качеством кода ПО. Для этой цели мы собираем и интерпретируем результаты тестирования системы и интеграции, собранные во время разработки Windows 8. Кроме того, мы представляем серию метрик выполнения тестов, которые обобщают результаты.

Рис.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. Также, было показано, что показатели тестов могут быть использованы для прогнозирования ошибок между отдельными этапами развития, а не между отдельными выпусками, и что тестовые показатели являются более многозначительными, чем простые подсчеты предыдущих ошибок. Первоначальный анализ важности отдельных показателей показал, что тестовые всплески, ложные тестовые сигналы ошибок, а также показатели количества различных свойств контекста выполнения являются одними из наиболее влиятельных метрик. Необходимо провести большую работу, чтобы подтвердить эти результаты и закрепить текущий набор коррелированных метрик тестирования и найти более плотный и оптимальный набор.