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


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

Котекст проекта Avaya. Аvay проект в рамках исследования это колл центр. Проект использует SQL, C, CPP в дополнение к основной части кода на Java языке. Проект в стадии изучения использовал ClearCase для отслеживания изменений к коду и фирменную систему замененили на Clear-Quest для отслеживания дефектов программного обеспечения. Покрытие кода измеряли с помощью инструмента Cobertura. Мы получили историю изменения кода, используя команду “LSH” в ClearCase. За исключением изменений, сделанный на приватных брачная, все коммит_ы имели модификационный запрос индетификатора(MR), который мы автоматически извлекли из изменений комментария. Этот идентификатор MR был использован для получения более подробной информации об изменении. Мы использовали информацию из ClearQuest и фирменная система слежения определяла фазы MR отчетов. В особенности мы идефицировали пост-СV MRs который мы обнаружили в ходе альфа и бета тестирований и от клиентов финального релиза. Мы также определяли MRs наблюдаемый в системной интеграции и тестировании. В заключении, мы подсчитали количество MRs, связанных с каждым файлом(нам пришлось map-ить MR id взятых из старых систем в MR id новых систем чтобы избежать двойного учета этих MRs). Для отслеживания покрытия кода мы использовали ежедневные и финальные моментальные снимки отчетов покрытия в плагине Cobertura. Мы использовали два номера из этих отчетов: количество актов Ns(f,t) и количество покрытых актов Nc(f,t), где f представляет файл, t представляет снимок во времени, когда было получено покрытие. Количество покрытия, которое использует в нашей модели получается путем определения максимума отношения покрытых и ко всем актов:
 C( f) = max(Ns(f,t)/Nc(f,t)). Очевидно, другие меры, включающие циклическую сложность, некомментированные строчки кода, и FanOut различаются во времени. Для каждого из них мы выбрали максимум периода наблюдения. Мы выбрали изменения, MRs, покрытие для интервала до момента релиза ПО в качестве периода наблюдения. Единственным исключением был клиент в отчете MR: целый интервал включающий 8 месяцев после даты релиза использовался для определения файлов c полевыми дефектами. Мы обратили внимание на альтернативные меры покрытия, цикломатической сложности, FanOut и NCSL, вычисленных со временем путем средних минимумов вместо средних максимумов, но результаты регрессии было похожи на те, для которых использовалась C(f).

Контекст проекта MS Размер проанализорованного базого кода был 40+ миллионов LOC. Покрытие кода в Windows занимает места на уровне двоичных файлов. Мы также собираем и мапим пост-релиз фейлы, полученные для WV(Vista), которые мы обнаружили в течении 6 месяцев после публикации релиза WV. Размер кода и метрики сложности были выбраны похожими на те, что использовались в случае Avaya, и собраны на двоичном базисе в релизной точке системы к полю. Мера покрытия кода немного отлична и описана ниже. Для мер покрытия кода в двоичных файлах мы используем дугу и покрытие блока, аналогичные актам и веткам покрытия. Рисунок 1 представляет простой пример где дуги выделены желтым, а блоки выделены серым. Настройки покрытия кода основываются на фреймворке: Vulcan binary analysis framework at Microsoft.

Наша теоретическая предпосылка основана на интуиции, что дефекты локализуются в части кода, которая не охвачена путем выполнения теста и не могут быть обнаружены с помощью этого тестового набора. Фундаментальная слабость этого допущение, что не ясно, какая часть дефектов локализована. Другими словами, это может быть случай, когда самые важные дефекты могут обнаружиться за счет набора тестов, который не охватывает полного или высокого уровня покрытия. Практическая слабость подхода это когда даже если практическая часть кода покрыта набором тестов, это не гарантирует, что все или несколько недостатков существуют в той части кода, которая бы подверглась тестам. Несмотря на эти недостатки, разумно ожидать, что учитывая все другие подобные условия, увеличение покрытия кода должно уменьшать дефекты, наблюдаемые за счет пост SV. 
Учитывая, что особенные файлы/двоичные файлы имеют различную функциональность, написанные различными разработчиками и тестровщиками, разных размеров, и разной истории, то неразумно ожидать, что все другие условия эквивалентны. Для того, чтобы справиться с этими изменениями мы попытались скорректировать факторы, которые, как известно, влияют на пост-SV дефекты. Есть целый ряд исследований в этой области, использующий различные факторы для прогнозирования дефектов после релиза. Несмотря на это, Тем не менее, оказывается, что одного предсказателя от общего количества изменений, внесенных в файл является наиболее важным прогностическим фактором, который практически невозможно улучшить. Кроме того, предсказатели такие как модифицированные строки кода и количество изменений в модуле(части кода) часто сильно коррелируют. Таким образом, наша основная гипотеза в том, что увеличение покрытия модуля кода, настроенных для изменения сделанных в модуле, должно уменьшить пост-релизные дефекты.

Все меры для Avaya написаны на Java только из-за зернистости файла(класса). По причине нашей меры реагирования для пост-релиз дефектов, мы убрали весь код, который не выполнялся клиентами, и таким образом, не мог быть связан с такими дефектами. В частности, все тестовые примеры и стабы, такие как сборка, тест, и другие разработанные инструменты поддержки кода исключены из наших отчетов. Нотация:

Мы исследуем коррелирует ли уровень дефектов с уровнем покрытия. Рисунок 2 показывает GMR в файле, нормированным за счет MR, NCSL, CC, and FanOut для файлов с различным уровнем покрытия. Каждая мера масштабируется, чтобы поместиться на одном экране. Обе средние и стандартные ошибки представлены чтобы определять изменчивость оценок. Последовательное снижение скоро
В то время как стандартные ошибки достаточно велики, существует статистически значимая разница между степенями самого большого и самого маленького покрытия. Как и в таблице 2, такой уровень детализации может быть опубликован только для проекта Avaya. В таблице 3 представлен Spearman correlations 2 между двумя переменными для проекта Avaya. Покрытие отрицательно коррелирует только с GMR, но корреляция очень мала, но корреляция очень мала( хотя значима при p - val < 0.0001, как и все другие корреляции). В таблице 4 показаны Спиармен корреляция для переменных в проекте Microsoft.

Мы конвертировали коэффициенты регрессии таблицы 5 в более интерпретируемые переменные вероятности, что класс будет иметь пост CV дефект. Результат, представленный на рисунке 2, показывает отношение между самыми высокими уровнями и никакого низкими уровнями покрытия.
 В таблице 4 приведены корреляции Спирмена среди переменных в проекте Microsoft. Обратим внимание, что здесь увеличение покрытия положительно коррелирует с количеством фейлов(опять же, все корреляции невелики и весьма значительны). Это феномен может объяснить такую низкую отрицательную корреляцию в исследовании Avaya.

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


1. D. Atkins, T. Ball, T. Graves, and A.Mockus. Using version control data to evaluate the impact of software tools: A case study of the version editor.
2. T. Ball, P. Mataga, and M. Sagiv. Edge profiling versus path profiling: The showdown. In Symposium on Principles of Programming Languages, 1998.
3. Audris Mockus, Nachiappan Nagappan, and Trung T. Dinh-Trong. 2009. Test coverage and post-verification defects: A multiple case study. In Proceedings of the 2009 3rd International Symposium on Empirical Software Engineering and Measurement (ESEM '09). IEEE Computer Society, Washington, DC, USA, 291-301. DOI=http://dx.doi.org/10.1109/ESEM.2009.5315981