Показаны сообщения с ярлыком производственное. Показать все сообщения
Показаны сообщения с ярлыком производственное. Показать все сообщения

2019-07-18

О работе с требованиями и общности ИТ с остальным миром.

Перекрёсток, нерегулируемый. Его(перекрёсток) переделывают в регулируемый, Канавы, знаки, светофоры... . Пешеходный переход на этом перекрёстке и пятеро(5-ро) мужиков машут руками, голосят, споря где/как/что тут  копать/штробить/цементировать. И тут один из них выдаёт робкую фразу “А как у нас по проекту должно быть?“. 
Оказывается не только лишь в ИТ так, не только лишь... .

2018-05-18

О статусе релиза.

- What is the release status?
- "We have enough fails for now"(c).

2018-01-23

О бардаке с управлением и рулением.

"Никакого бардака с рулением нет, у нас спонтанно-динамическая стабилизация по всем каналам управления с элементами роевой самоорганизации."(а).

2018-01-17

TestNG, пропущенные тесты и информация о причинах.


 Как общенеизвестно тесты после прогона бывают прошедшие, упавшие и пропущенные.
ТестНГ "пропускает" тесты в том числе и потому что что-то упало на этапе подготовки -
если где-то в глубинах @BeforeSuite/Group/Method что-то завалилось, то всё, гонять зависимые тесты уже нет смысла, сворачиваемся и идём обедать.
К сожалению в этом случае тесты хоть и помечаются "пропущенными", но без особого объяснения причин(лишь бодрое ничего приветствует любопытствующих), мол смотрите логи, может повезёт.

А хочется же подробностей и вот что придумалось:
1. TestListenerAdapter#onTestSkipped(ITestResult result);
2. Проверить Throwable в ITestResult;
3. Если налловое, то вытащить пропущенные/порушенные конфигурации через result.getTestContext().getSkippedConfigurations();
4. Способа связать упавший конфиг с конкретным тестом не нашёл, но можно сделать это через тестовый класс:
skippedConfig.getTestClass().equals(result.getTestClass()))
5. Если удалось связать, то через result.setThrowable() "перенести" исключения из конфигов в ITestResult
6. На практике даже вроде работает.

2018-01-11

Программное обновление статуса прогона тестов ТестЛинк.

 На проекте завёлся TestLink - жизнь стала насыщенее и встал вопрос хранения результатов прогона регрессии в том числе и в нём. Сохранять вручную конечно же не вариант, а посему нужно программное решение. И тут началось... .
 Задача - по результатам прогона тестов обновлять соответствующие сущности в ТестЛинке (создавать, удалять объекты не нужно, просто сохранять результаты прогона тестов на конкретной сборке.)
 Идея - использовать некий клиент для тестлинковского ПИП чтобы после прогона теста/тестов загружать результаты.
 Дробности решения:
1. яндексирование выявило лишь одну более-менее свежую реализацию - http://kinow.github.io/testlink-java-api/index.html
2. ПИП этот разрабатывал какой-то маньяк-ветеран. Методы, отсвечивающие стройными рядами входных параметров, прямо таки напомнили "святые 90-е", Win32API и Паскаль.
3. чтобы вызовы заработали нужно не только заиметь/сгенерировать ключ (http://forum.testlink.org/viewtopic.php?f=10&t=2858), но и кое-что включить в настройках сервера - https://github.com/parthibann/Python-TestLink-Runner/wiki/Enabling-Test-Automation-in-Testlink
4. если неизвестно что именно передавать в методы(см. выше), то можно смело пробовать налловые значения, часто помогает.
5. всё очень медленно.
6. "внешние" идентификаторы тестлинковских кейсов можно хранить в аллюровских @TestCaseId (связь тест<->тест_кейс). Вытащить данные из аннотаций достаточно легко. Под "внешними" имеется в виду идентификаторы вида ТА-1234, где ТА это аббревиатура названия проекта в ТестЛинке, а 1234 это порядковый номер кейса.
7. вполне можно делать всё в TestListenerAdapter#onFinish() (речь о TestNG):

URL testLinkURL = new URL(testLinkHost + "/lib/api/xmlrpc.php");
testLinkApi = new TestLinkAPI(testLinkURL, devKey);

report(testLinkApi, testPlan, testBuild, ExecutionStatus.NOT_RUN, 
        testContext.getSkippedTests().getAllMethods()); 

report(testLinkApi, testPlan, testBuild, ExecutionStatus.PASSED, 
        testContext.getPassedTests().getAllMethods()); 

report(testLinkApi, testPlan, testBuild, ExecutionStatus.FAILED, 
        testContext.getFailedTests().getAllMethods());

... 

private void reportResult(TestLinkAPI testLinkApi, TestPlan testPlan, 
                          Build testBuild, ExecutionStatus status, 
                          Collection testNgMethods) 

  for (ITestNGMethod testMethod : testNgMethods) {
    String testCaseId = getExternalIdFromAnnotations(testMethod, testMethod.getMethodName());
    for (String extId : testCaseIds) {                
      try {                    // 'null' - to return the latest version of test case                    
        TestCase testLinkCase = testLinkApi.getTestCaseByExternalId(extId, null);                    
        testLinkApi.reportTCResult(testLinkCase.getId(), null, testPlan.getId(),
                                status, testBuild.getId(), null, 
                                "A note on test case execution,", 
                                null, null, null, null, null, null);
        } catch (TestLinkAPIException e) { 
                           //Do something... .
         }
    }
  } 
 }
}

2017-12-08

ИИ всё ближе / AI is closing.

Разум изнурённый борьбой с постоянными падениями на СИ, протухаущими данными и прочими прелестями "взрослого проекта с длинной историей" начинает требовать внедрения ИИ в тесты - "что оно как-то там само разруливала мелкие падения и вопросы типа 'откуда брать кошерные данные прямо вот сейчас'". Главное чтоб потом код тестов не стал на порядок сложнее кода тестируемого приложения.


-------------

All those failing tests and suddenly became invalid data are so frustrating that engineer's mind strats to demand an AI in the test automation solution - just to decide-on-the-fly what-to-do and where-to-go if something went wrong in runtime. The main concern - test automation code should not be more complex than AUT's one.

2017-02-25

Рекламное немного.

 Контора "КостыльТехРеш" в сжатые сроки преодолеет любые технические трудности заказчика использую многовековые наработки в области самобытных и маловремязатратных решений.