Версия-контроль тестовых случаев

Question

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

ОБНОВЛЕНИЕ: Я ищем веб-систему управления тестированием для моей операции, так как она обеспечивает легкий доступ к членам команды разработчиков (т. Е. Не нужно использовать VC для проверки плана тестирования из репозитория). Тем не менее, я бы предпочел, чтобы эти контрольные планы контролировали версию, синхронизированную с основными этапами/версиями программного обеспечения. Я не нашел никакой системы управления тестированием, удовлетворяющей эту потребность. Или я ищу не в том направлении?

Answer 1

Это имеет смысл для меня. Я ожидаю, что тесты (будь то ручные спецификации или модульные тесты) и соответствующий код будут заблокированы. Я бы также ожидал (возможно, оптимистично!), Что документация будет в значительной степени соответствовать коду для конкретной проверки.

Возможно, если вы не можете полностью их соблюдать, вы можете использовать механизмы тегов (или ветвления?) Исходного кода для идентификации согласованных наборов версий? Это может иметь больший смысл, если ваш контроль версий содержит тесты, которые вы пересматриваете/создаете свою базу кода для достижения (т. Е. Ваши тесты приводят ваш код - ни в коем случае не необычная ситуация).

Answer 2

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

Некоторые команды используют инструмент, например TestDirector, для управления планами тестирования, тестовыми примерами и подключения к системе отслеживания ошибок. Каждый тестовый пример, ошибка и т. Д. Имеет историю изменений, хранящихся в базе данных, так что вы можете вернуться и просмотреть ее (и искать ее, с небольшим количеством работы и некоторого jiggery-pokery, как сказал бы The Doctor). Тем не менее, мы никогда не добавляем это в синхронизацию с кодом, за исключением основных этапов, когда мы делали код зависанием, и в то время код + скрипты переходили в MKS Integrity (лично я чувствую, что мы недоиспользовали Integrity на нашем месте работы ... он предназначен для использования со всей командой разработчиков, а не только промоутеров кода).

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