Оптимизация регрессионного тестирования в среде C ++ - PullRequest
6 голосов
/ 16 декабря 2009

Чтобы избежать слишком большого количества испытаний, я хотел бы предоставить группе обеспечения качества (QA) подсказки, какие функции должны быть регрессивно протестированы после итерации разработки. Знаете ли вы инструменты, которые могли бы сделать это в среде разработки C ++ и Subversion (и Visual Studio)?

Подробная информация о сценарии использования:

  1. Особенности будут определены команда разработчиков с точки зрения входа очки, как правило, классы или класс методы. Скажем, функция "Excel файл импорт "определяется методом ImportExcelFile (...) класса FileImporter.
  2. Во время итерации разработки команда разработчиков совершает некоторые изменения в некоторых методах некоторых классы. Скажем, один из этих классов косвенно используется методом ImportExcelFile ()
  3. В конце итерации все коммиты анализируются инструментом и отчет составлен и доставлен в команду QA. В нашем примере Команда QA проинформирована об этой функции «импорт файла Excel» должен быть проверен, и что другие функции X Y & Z без изменений.

Очень вероятно, что этот инструмент будет использовать статический анализ кода и использовать API подрывной деятельности. Но существует ли он?

Ответы [ 2 ]

1 голос
/ 16 декабря 2009

G'day,

То, что вы описываете, на самом деле не является регрессионным тестированием.Вы просто тестируете новые функции.

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

Я бы очень хотелрекомендую прочитать превосходную статью Мартина Фаулера « Непрерывная интеграция », которая охватывает некоторые аспекты, о которых вы говорите.

Она также может предоставить вам лучший способ работы, в частности аспекты CI Martinоб этом говорится в его статье.

Редактировать: Тем более, что у КИ есть некоторые скрытые маленькие ловушки, которые очевидны задним числом.Такие вещи, как остановка тестеров, пытающихся протестировать версию, в которой еще не было всех файлов, реализующих новую функцию, зафиксированы.(Вы проверяете, что за последние пять минут не было никаких коммитов.)

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

Если он сломан, у вас теперь есть:

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

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

Редактировать: Что касается вашего вопроса, как насчет пометки хранилища, когда вы сделали?ваше тестирование, например, TESTS_COMPLETE_2009_12_16.Затем, когда вы будете готовы выяснить, какой следующий набор тестов выполнит "svn diff -r" между тегом последних завершенных тестов и HEAD?

HTH

Кстати, я обновлюэтот ответ с некоторыми дальнейшими предложениями, как я думаю о них.

ура,

0 голосов
/ 16 декабря 2009

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

Make перестроит любой исполняемый файл при изменении его зависимостей.

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

Все, что было построено после этой точки, нуждается в модульном тестировании.

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

Все, что было построено после определенной точки, нуждается в регрессионном тестировании.

Если вы не работаете в среде, в которой гарантированно не хватает ресурсов (например, TinyC), вы в конечном итоге будете регрессировать все. Регрессионное тестирование не является модульным тестированием.

...