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

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

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

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

Как перестать думать и прикрутить ДатаПул к тестам.

Есть вот такая штука - ДатаПул. Вроде бы полезная и примеры есть прямо в местележания, но как-то непонятно с чего начать прикручивать и как использовать.

Допустим есть тесты. Все из себя на Джаве + ТестНГ + мавен + что-нибудь ещё. Приступим:
1. Добавить зависимость
  

 com.griddynamics.qa.datapool

 data-pool

 1.0.1

Версию конечно же нужно проставить актуальную на текущий момент.

2. Создать/найти пакет entities (или что-то подобное) . Допуская, что нам нужны данные тестовых пользователей добавляем что-то вроде

package ru.test.automation.entities;

import com.griddynamics.qa.datapool.DataTypeFactory;

import com.griddynamics.qa.datapool.datatype.IDataType;

/**

 * Represents a BitBucketUser entity.

 */

public interface BitBucketUser extends IDataType {

    static BitBucketUser newUser(){

        return DataTypeFactory.create(BitBucketUser.class);

    }

    Integer getId();

    String getLogin();

    String getPassword();

}

Поля у объекта конечно же могут быть и не такими.

3. Создать/найти директорию /resources/data и добавить туда собственно файл с данными

!DataTypeKey 'interface ru.test.automation.entities.BitBucketUser':

- !IDataType {id: 1, login: Uzvr_Odin, password: Klu4slovo}

- !IDataType {id: 2, login: uzvr-Dva, password: derParrollen}

- !IDataType {id: 3, login: uzvr-Tri, password: AEtoKto?}

Пусть этот файл зовётся ls.yml

4. Наверняка в тестах есть какой-нибудь BaseTest, туда можно-нужно-стоит добавить

import ru.test.automation.entities.BitBucketUser;

import com.griddynamics.qa.datapool.DataPool;

import static com.griddynamics.qa.datapool.FilterCriterion.by;

import static com.griddynamics.qa.datapool.matchers.StandardMatchers.CONTAINS;

...

@BeforeSuite

protected void loadData() {

    ClassLoader classLoader = getClass().getClassLoader();

    DataPool.load(Paths.get(classLoader.getResource("data/ls.yml").getPath()));

    // TODO: Switch to the approach below when Data-pool 1.0.2 is released.// DataPool.load("data/ls.yml");

}

//TODO: Think about moving into a separate data-access class.

protected BitBucketUser getUserByLogin(String partOfLoginName) {

    return DataPool.find(BitBucketUser.class, by("login", CONTAINS, partOfLoginName)).get(0);

}

5. И наконец! В нужном месте, в нужном тесте можно сделать так

BitBucketUser usr = getUserByLogin("Uzvr_Odin");

loginPage().login(usr.getLogin(), usr.getPassword());

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

- 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/

Eng. - be strong and think about others.

Senior engineers!  Just a note - at the very moment you are about to code-up your next shiny, glamorous test automation framework  - think about those middles who will  support and maintain the fruit of your creativity.  Be kind, leave at least couple of notes  on how that "wonderwaffle" is supposed to work!

Документацию надо всё-таки читать - Allure+TestNG и запуск из командной строки.

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

aspectjweaver_jar_file_name="$(ls ./lib/aspectjweaver-*.jar | xargs echo)"

java -ea -javaagent:"$aspectjweaver_jar_file_name" -cp "${full_classpath}" org.testng.TestNG ./test_suites/$testXmlName