G'day,
То, что вы описываете, это на самом деле не регрессионного тестирования. Вы просто тестируете новые функции.
Регрессионное тестирование - это то, где вы специально запускаете свой полный набор тестов, чтобы узнать, прервал ли код, поддерживающий вашу новую функцию, предыдущий рабочий код.
Я настоятельно рекомендую прочитать превосходную бумагу Мартина Фаулера «Continuous Integration», которая охватывает некоторые аспекты, о которых вы говорите.
Он также может предоставить вам лучший способ работы, в частности аспекты CI, о которых говорит Мартин в своей статье.
Редактировать: Тем более, что у CI есть скрытые маленькие ловушки, которые очевидны в ретроспективе. Такие вещи, как остановка тестеров, пытающихся протестировать версию, в которой еще не было файлов, реализующих новую функцию. (Вы проверяете, что за последние пять минут никаких коммитов не было).
Другим важным моментом является потеря времени, если у вас сломанная сборка и вы не знаете, что она сломана, пока кто-то не проверит код, а затем попытается построить его, чтобы они могли его протестировать.
Если он сломан, теперь у вас есть:
- тестер сидеть не в состоянии сделать запланированные тесты,
- разработчик прерывая свою текущую работу, чтобы вернуться к прежней работе, чтобы разобраться, что вызывает сломанная сборка.Скорее всего, это разработчики, потому что проблема заключается в взаимодействии двух отдельных частей, каждый из которых работал сам по себе.
- Потеря времени, связанная с тем, что разработчик (разработчики) должен вернуться к мышлению для этой предыдущей работы, и
- потеря времени для разработчика, чтобы вернуться к мышлению нового произведения, работая до прерывания расследования.
Основная идея CI заключается в том, чтобы сделать несколько сборок полного продукта в течение дня, чтобы вы как можно раньше ловушки сломанной сборки. Вы даже можете выбрать несколько тестов, чтобы проверить, что основные функции вашего продукта все еще работают. Еще раз, чтобы как можно скорее известить о том, что существует проблема с текущим состоянием вашей сборки.
Редактировать: Что касается вашего вопроса, как насчет пометки репозитория, когда вы проводили тестирование, например. TESTS_COMPLETE_2009_12_16. Затем, когда вы будете готовы выработать то, что следующий набор тестов выполняет «svn diff -r» между этими последними тегами завершенного тега и HEAD?
НТН
КСТАТИ Я буду обновлять этот ответ с некоторыми дополнительными предложениями, как я думаю о них.
веселит,
Роб, благодарю вас за ответ. На самом деле я знаю - и сторонник публикаций Мартина Фаулера, и мы используем непрерывную интеграцию, включая автоматическое модульное тестирование. Дело в том, что у нас также есть отдельная команда QA, которая фокусируется на тестировании функций - «истории» с точки зрения XP. Мы хотели бы иметь возможность вести их, по которым история (ы) должна быть повторно протестирована после ряда коммитов, особенно в целях предотвращения «чрезмерного тестирования» историй, которые, возможно, не могли быть регрессированы. –
@Denis, приветствия. Может ли ваш dev, возможно, отметить коммит для одной истории пользователя? Создание единого фиксации, когда история завершена, вероятно, опасна (как в случае потери работы из-за потери локальной копии) и негибкой. Я предлагаю, возможно, пометить хранилище, когда США закончены и совершены. Кстати, я бы хотел, чтобы у меня был доллар за каждый раз, когда кто-то сказал «не мог бы меня отступить», когда это было ясно! (-: –