Аннотирование/выборка/сопоставление идентификатора тестового теста Testrail на локальном тестовом тестировании Java TestNG (интеграция тестовой железнодорожной линии Jenkins)

Question

Я пытаюсь использовать Testrail в качестве системы управления тестовыми случаями, и поэтому , интегрирующий тестовые игры с Jenkins, будет полезен.

Это то, что я хочу добиться:

Позволяет сказать, что я вручную создать три теста в testrail с футляром идентификаторами C1, C2 и C3, и эти тестовые случаи будут иметь некоторые уникальные автоматизированные имена тестов, таких как A1, A2 и A3 (более подробная информация будет иметь поле в тестовом реестре с такой уникальной информацией )

Когда я нажал кнопку «Начать автоматизированные тесты» и запустил задание Дженкинса из тестового поля (учитывая, что я уже реализовал интерфейс скрипт для testrail, который имеет эту кнопку):

, я хочу запустить скрипт/что-то, что принимает идентификаторы case из выбранных тестовых случаев и временно аннотировать эти идентификаторы к фактическим испытаниям Java, чтобы он мог запускать эти конкретные тесты и отправлять результаты обратно в Testrail.

подход я могу думать:

Когда я ударил кнопку «Start Automated Tests» на Testrail, я могу сделать скрипт для запуска, чтобы создать файл XML, который будет включать требуемые выбранные тестовые случаи из Testrail. Затем этот XML будет предоставлен в качестве ввода по умолчанию для задания Jenkins, и он будет запускать тестовые примеры, упомянутые в файле XML. Этот XML будет временным и будет заменяться каждый раз, когда выбор производится из Testrail. Однако как вы это делаете? Я новичок в Testrail и читаю его API и, похоже, API будет полезен для публикации результатов на Testrail. Но как мы достигаем отображения идентификаторов?

Кроме того, любые рекомендации по отправке результатов обратно на Testrail будут полезны.

Answer 1

Это не спецификация TestNG, но вы можете сделать пользовательскую аннотацию в java. Вы можете обновить тест TestRail в тестовом прогоне через api либо с помощью идентификатора теста (с использованием add_result), либо как идентификатора случая, так и идентификатора запуска (с помощью add_result_for_case). http://docs.gurock.com/testrail-api2/reference-results

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

Вот что я использую для этой цели:

@Retention(RetentionPolicy.RUNTIME) 
@Target(ElementType.METHOD) 
public @interface TestData 
{ 
    int testId() default 0; 
    String[] tags() default ""; 
} 

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

@Test 
@TestData(
     testId = 177, 
     tags = {"smoke", "authentication"} 
) 
public void testName() 
{ 
    //Do the test 
} 

Затем я использую специальный способ JUnit, чтобы получить имя метода тестирования для использования в методе teardown, но я уверен, что существует множество способов сделать это. Если у вас есть имя метода тест здесь, как я прочитал аннотацию:

@After 
public void baseTearDown() throws Exception 
{ 
    //Good place to record test results 
    Method testMethod = getClass().getMethod(testName); 
    if(testMethod.isAnnotationPresent(TestData.class)) 
    { 
     TestData testData = testMethod.getAnnotation(TestData.class); 
     //Do something with testData.testId(); 
     System.out.println("Test ID = " + testData.testId()); 
    } 

    //other cleanups 
} 

Это mkyong ссылка дает некоторые довольно основные примеры как создание аннотаций и читать его с отражением. Это то, что я использовал для начала: https://www.mkyong.com/java/java-custom-annotations-example/

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