Как Вы организуете/расположение свои сценарии тестирования
Плагин Git-Parameter не требуется в этом решении
Затем в разделе «Управление исходным кодом» обновите ветки, чтобы построить для использования строкового параметра. определены 
Это позволит заданию jenkins использовать ветвь по умолчанию в качестве главной, а для ручных сборок будет предложено ввести сведения о ветке (для справки: по умолчанию установлено мастер)
4 ответа
Тесты, выполняемые людьми, должны быть на очень высоком уровне абстракции.
Например, тестовый сценарий для stackoverflow регистрации:
Хороший:
Посетитель сайта с существующей учетной записью OpenId регистрируется как stackoverflow пользователь и отправляет ответ.
Плохо:
1) Перейдите на http://stackoverflow.com, 2) Нажимают на ссылку входа в систему 3) И т.д...
Это важно по нескольким причинам:
a) это сохраняет тесты удобными в сопровождении. Таким образом, Вы не должны обновлять свой сценарий тестирования каждый раз, когда элементы навигации повторно маркированы (например, 'вход в систему' изменяется для 'регистрирований').
b) это сохраняет Ваши тестеры от схождения с ума от скуки мелких подробностей.
c) запись сценариев тестирования подробного руководства является плохим использованием Ваших конечных тестовых ресурсов.
Сценарии тестирования подробного руководства отклонят Ваши тестеры в запись ошибок для незначительных проблем документации. Вы хотите использовать свое время для нахождения реальных ошибок, которые повлияют на клиентов.
Тесты могут быть сгруппированы приоритетом. Тесты BVT/smoke могли иметь самый высокий приоритет с функциональным, интеграцией, регрессией, локализацией, напряжением и производительностью, имеющей более низкие приоритеты. В зависимости от Вашей тестовой передачи Вы выбрали бы приоритет и запустили бы все тесты с этим или более высокими приоритетами. Все, что необходимо сделать, определяют, какой приоритет конкретный тест.
Я пытаюсь заставить ручные тесты вписаться в автоматизированную структуру---, у Вас могут быть оба.
Организационные схемы, используемые автоматизированными тестами (например, xUnit платформы), работают на меня. На самом деле они могут использоваться для полуавтоматизирования тестов, останавливаясь и призывая, чтобы ручной тест был выполнен или введен помещенные, чтобы быть введенными, или GUI, который будет осмотрен. Схема обычно состоит в том, чтобы зеркально отражать структуру каталогов производственного кода, или включать тесты в производственном коде, иногда как внутренние классы. Тесты выше уровня единицы могут часто быть, вписываются в высокоуровневые каталоги (предполагающий, что у Вас есть достаточно глубокое дерево каталогов). Эти высокоуровневые тесты могут войти в (зеркальные) каталоги, которые не имеют никакого производственного кода, но являются там в организационных целях.
Уровень детализации---хорошо, который зависит, правильно?
Мэтт Андресен дал хороший ответ, в общем случае, но бывают ситуации, когда вы не можете сделать это таким образом. Например, когда вы работаете над проверенными приложениями, которые должны соответствовать правилам других сторон, таких как FDA, и они проходят очень интенсивный аудит, проверку, подписание, после чего требуется 2 формы ответа на ваш пример. Хотя в этом случае я бы предпочел перейти к автоматизации с помощью HP QuickTestPro или IBM RationaRobot.
Может, вам стоит попробовать с репозиторием некоторых тестов? Снова есть инструменты из продуктов HP QualityCenter и IBM, но это может быть дорого. Вы можете найти более дешевый вариант, который позволит вам организовать их в древовидные структуры по требованиям / функциям, назначить им приоритеты, сгруппировать их в наборы тестов для выпусков, сгруппировать их в наборы для регрессионного тестирования и т.д.