Мысли вслух о разнице между автотестами на ПИП и для Большеданных приложений

Просто наблюдение "внимательного индейца Джо":
1. На уровне "квадратиков" подход к авто-тестированию тылового междумордия( ПИП) выглядит так:

2. А вот в случае всяких большеданных приложений типа "Взять-Преобразовать-Выдать":

Великой разницы нет, почти те же самые тесты на междумордий, однако:
а. работать приходится не с самим приложением, а с некими дополнительными приспособами которые запускают уже само приложение и т.д.
б. непосредственного ответа от тестируемого приложения может и не быть ("запрос - ответ - проверка что там в ответе пришло" меняется на "запрос на запуск - ожидание - проверка данных в выдаче")
в. работа со входными-выходными данными (на уровне библиотек и вызовов) - практически такая же.
г. за счёт работы через "посредников" количество дополнительных библиотек в проекте возрастает.
д. Сами проверки выхлопа часто включают в себя "похоже ли на правду" ибо при больших объёмах жёстко сравнивать вход-выход может быть ооооочень дорого.

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

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

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. На практике даже вроде работает.

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

 На проекте завёлся 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... .
         }
    }
  } 
 }
}

TestNG, мелкие дробности перезапуска упавших тестов.

Авто-тесты падали, падают и будут падать. Это данность данная нам в болевых ощущениях, яркостью которых конечно же хочется управлять - перезапуская упавшие тесты например. TestNG поддерживает это желание и предоставляет набор стандартных средств для программного перезапуска. Как, что и где хорошо написано вот в этой статье (и в этой), однако "есть нюансы". А именно, каждый прогон теста попадает в отчёт, т.е. перезапущенные тесты  показываются и в "пропущенных" и в "прошедших"/"упавших" - тест 1 раз упал, 3 раза был перезапущен (два раза упал, на последнем прогоне внезапно "позеленел") - в итоге отчёт честно покажет 3 пропущенных и один успешных прогон, но нужно ли это нам? По-хорошему в итоговом отчёте "для начальства" нам интересен только последний раз, именно он идёт в зачёт. Итого появляется задача убирать "ложные" прогоны из отчёта. Как обычно"всё придумали до нас". Добавлю что отфильтровывать лишнее можно по-разному и в разных местах:
- #onFinish() в собственной реализации TestListenerAdapter;
- @AfterMethod/Group/Suite в базовом классе;
- #retry() в реализации IRetryAnalyzer. Но! Это будет работать только для тестов которые так и на "позеленели" в процессе перепрогона.

Выбирайте кому что и когда.

Почему падают авто-тесты?

Летним ветром навеяло:
Почему падают авто-тесты, какие типовые причины и вообще - доколе? Я бы выделил четыре группы причин:
1. "Битая" функциональность, т.е. таки изъян в тестируемой системе;
2. "Поломанные" тесты - кто-то что-то улучшил, изменились локаторы, поменялась логика работы системы ... ;
3. Что-то нездоровое было с окружением: сеть(задержки-огнестены-впн-ы и т.д.), драйверы, электропитание, админы празднуют Новый Год ... ;
4. НЁХ - "неведомое ёлочное художество". Упали потому что упали, жалко что ли?

ИИ всё ближе / 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.

Актуальная банальность (е.н. Прописная истина) / Actuality.

Если нет стабильных тестовых окружений, то количество отличных тестов в наборе это просто цифра.

-------------------
If you do not have stable environments then it does not really matter how many excellent tests you have in the suite.

Что бы такого учесть при оценке трудозатрат на АТ.

Классический вопрос обоснования необходимости автоматизации тестирования(и не только) -
"Что мы с этого будем иметь? Сколько сэкономим, сколько заработаем, скольких уволим и сколько можно будет перевести в премии?". И как всегда есть очевидные, известные и не очень вещи. Обычно пишут об эффективности автоматизации функционального тестирования как некоей загадочной величине пропорциональной отношению затрат на ручное тестирование к затратам на автоматизированное. И что включать в каждый вид затрат - тут каждый сам себе художник и научрук.

 На мой выпуклый военно-морской в затратах на автоматизацию следует в том числе учитывать:

- людей: кто, когда, с какой мотивацией и под какой стимуляцией будет всё это делать, развивать и поддерживать;

- документированность: насколько быстро можно получить ответы на внезапные вопросы,

нужно ли разрабатывать сценарии или использовать готовые и проверенные тестослучаи для ручного тестирования, каков вообще порог вхождения в проект(в месяцах). Здесь же можно упомянуть и общую зрелость проекта — если всё работает «не-так», то автоматизация вряд ли будет быстрой и эффективной;

- архитектуру и структуру. Проистекает из вопроса "что покрываем?". Навскидку:

 а. микросервисы или монолит;

 б. сервисы на основе бинарных протоколов или РЕСТ какой-нибудь;

 в. нужно воздействовать на одну систему или несколько.

- технологии тестируемого: есть ли вообще инструменты позволяющие это автоматизировать (пример - мордочки на флеше которые не всякий популярный инструмент возьмёт);

- технологии тестового решения. Например использовать Селениум или Сикули это две большие разницы в затратах и на разработку и на поддержку;

- данные: стабы, моки или живые данные? Как генерировать и валидировать тестовые данные(особенно в случае критических систем(медицина, авиация))? Если моки-стабы, то есть ли что-то готовое или нужно будет писать своё?

- безопасников - дадут ли доступ и добро на манипуляции с системой, тестовые сборки с "дополнительными"(отладочными) функциями?

- среды: всяко-разные, начиная от где это запускать и где разворачивать тестируемое. Далеко не всегда можно получить стенды вот так сразу, возможно придётся подождать годик-два;

- СИ: строить с ноля или интегрироваться в существующее решение?

- 3-и стороны: не всем наши усилия могут нравиться, некоторые могут посчитать, что отбиваем хлеб, забираем масло и плюём в душу. А уж палки в колёса ставить могут просто рефлекторно.

Вышеперечисленное конечно же требует творческого расширения, углубления и всяческого дополнения. На то она и затравка.

Ссылки россыпью:

http://bytextest.ru/2017/06/20/autotest-vs-reality/#more-5727

https://pikabu.ru/story/post_2_yeffektivnost_avtomatizatsii_testirovaniya_3974390

http://www.a1qa.ru/blog/otsenka-effektivnosti-avtomatizatsii-testirovaniya/

О вежливости и эффективности в переписке, Н-2.

Ещё один совет из области рабочего общения: 

http://neprivet.ru

Коротко:

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

A short translation for language impaired ones:

"Do NOT  IM like

- You: Hello

- Your colleague: Hello

- You: Would you be able to .... .

---

DO it  like:

- You: Hello. Would you be able to ... ."

Just save the time.