Почему бы не ускорить тестирование, используя график зависимости функций?

Question

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

По сути, вы сможете точно сказать тестировщикам, какие функции тестировать, поскольку остальные функции остаются неизменными с точки зрения исходного кода.

Если, например, вы изменили орфографическую ошибку в одном фрагменте кода, нет причин снова запускать весь тестовый скрипт «на всякий случай», если вы ввели критическую ошибку.

Мой вопрос, почему деревья зависимостей не используются в разработке программного обеспечения и если вы их используете, как вы их поддерживаете? Какие инструменты доступны для генерации этих деревьев для исходного кода C # .NET, C ++ и C?

Answer 1

Высокопроизводительные версии Visual Studio 2010 (Premium и Ultimate) в сочетании с TFS предоставляют такой анализ зависимостей, который называется «анализ воздействия».

См. « Оптимизация процесса тестирования с тестированием».Анализ воздействия"и" Определение воздействия изменения кода на тесты".

Answer 2

Это очень хорошая идея, как только вы начнете испытывать тесты, которые стоят дороже (много времени занимает запуск).Кроме того, хороший набор тестов может быть испорчен только потому, что его никто не запускает, потому что у разработчика нет терпения ждать запуска.

Softagram - это один автономный анализатор зависимостей исходного кода, который предоставляет информацию также для целей автоматизации тестирования.Он анализирует все основные языки, такие как Java, C, C ++, C #, Python, PHP, JavaScript, TypeScript и т. Д.

В настоящее время существует REST API, который предоставляет информацию, которая обычно используется в сценариях Jenkins.С помощью веб-заданий и настройки централизованного анализа Softagram может автоматически анализировать все запросы на извлечение, как только они появляются или изменяются, а также любые незавершенные ветви, и тогда автоматизация тестирования имеет как можно более свежие данные для выбора затронутыхконтрольные примеры.

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

В настоящее время существуют ограничения в том, что анализатор Softagram нельзя установить на рабочую станцию ​​разработчика, ноэто установка сервера вместо этого.Он не анализирует побочные эффекты.В динамических языках трудно правильно определить все вызовы функций, поэтому полезно, если в вашем коде также есть несколько операторов # include / import, чтобы инструмент анализа знал о зависимости файла от файла.

Отказ от ответственности: я из Softagram , и мы используем его сами для вышеуказанной цели.

Answer 3

Помимо visual studio существует множество автономных анализаторов зависимостей исходного кода, которые можно использовать для этого; Source Insight - это один из таких инструментов, который предоставляет граф зависимостей и визуальный стек вызовов.

Answer 4

Я не согласен с вашими предположениями. Ваш код имеет зависимости данных в дополнение к зависимостям пути выполнения. Допустим, у вас запущены потоки A и B. A звонит a(), что делает:

shared_memory.x.inc_by(2);

Тема B звонит b():

assert(shared_memory.x.value % 2 == 0);
...

И все отлично работает (скажем;)). Затем однажды вы меняете первую функцию и делаете

shared_memory.x.inc_by(3);

вместо этого по какой-то причине. Если вы проверяете только функции в зависимости от a(), вы никогда не сможете проверить b(), потому что в некотором месте он разветвлен - это может быть даже динамический обратный вызов.

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

Возможно, в некоторой степени возможно провести такой анализ на некоторых языках - либо из-за отсутствия побочных эффектов, либо из-за некоторого статического анализа управляемого кода - но в некоторых случаях (C / C ++), во многих случаях вы не получите от него никаких полезных данных.

Answer 5

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

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

Но вы можете найти то, что вы хотите в VS2010, в инструментах архитектуры (http://blogs.msdn.com/b/somasegar/archive/2009/08/29/architecture-tools-in-vsts-2010.aspx), или в VS2008, это может быть полезно: http://www.codeproject.com/KB/cs/depgraph.aspx.

Моя проблема с диаграммой VS2010 состоит в том, что для ее завершения она становится слишком сложной, чтобы ее можно было использовать.

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