Инструменты для поиска пересечений покрытия кода?

Наша компания изучает идею использования покрытия кода Cobertura во время ручных регрессионных тестов, чтобы выяснить, где у нас есть «смежные функции». Общая идея заключается в том, что если регрессионный тест A попадает в метод businessLogicFoo(), а регрессионный тест B также попадает в этот метод, мы можем сказать, что регрессионный тест A и B имеют «смежные функции».

Мы особенно заинтересованы в эффективном определении того, какие регрессионные тесты имеют «смежную функциональность», чтобы мы могли планировать лучшие регрессионные прогоны (у нас есть гораздо больше тестов, которые нужно протестировать, поэтому мы всегда заканчиваем тестированием подмножества всех достойных регрессионных тестов).

Кто-нибудь пробовал что-то подобное раньше? С cobertura или какой-либо другой библиотекой покрытия кода?

Мое первое предположение состоит в том, что мы пишем groovy-скрипт (мой предпочтительный язык сценариев) для экспорта отчетов Cobertura в виде XML, затем анализируем охваченные классы/методы — отфильтровываем все лишние классы — и затем находим пересечения методов/классов между двумя отчетами. . В идеале все управление в maven. Но я только предполагаю.


java maven cobertura groovy
person dsummersl    schedule 15.02.2011    source источник
comment
Ваша цель здесь — выявить (почти) повторяющиеся тесты? По моему опыту, иметь гораздо больше тестов, чем время для тестирования, — очень необычное обстоятельство. Почему ваши тесты так долго выполняются?   -  person Dónal    schedule 15.02.2011
comment
У меня была такая ситуация, когда некоторые тесты выполнялись очень долго по разным причинам. Для тестов требовалась действующая база данных, в ней содержался большой объем данных, а наши системы тестирования/разработки работали на очень слабом оборудовании и в сетях. В результате выполнение полного набора тестов для приложения могло занять более получаса (а иногда во время пиковой нагрузки на сеть/базу данных — более 2 часов). Конечно, он редко запускался полностью, обычно мы запускали только подмножества.   -  person jwenting    schedule 16.02.2011
comment
Извините, может быть, это неясно: тесты - это РУЧНЫЕ тесты функций, а не автоматизированные, а не модульные.   -  person dsummersl    schedule 01.03.2011

Ответы (2)


arrow_upward
0
arrow_downward

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

person jwenting    schedule 16.02.2011

arrow_upward
0
arrow_downward

Наши инструменты Покрытие тестами легко вычисляют пересечения, объединения, дополнения, различия наборов векторов покрытия тестами, делая ваши пересечения тривиальными для вычисления.

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

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

person Ira Baxter    schedule 15.06.2011