Автоматизация тестирования, какой язык лучше учить?

 Вот созрел человек до "надо что-то менять, может автоматизатором стать" и начинается "а как", "а что", "а где" и "а на чём писать-то". Можно конечно пойти и задать вопрос поисковику, однако это всё статистика, которая вполне может быть далека от конкретных людей и обстоятельств. 

 Если рядом есть разрабы и вообще становление автоматизатором происходит к выгоде конкретного проекта - учите то, на чём пишут разрабы этого проекта. Подход простой, придуман давно, работает. Ибо один язык это такое пространство для общения... . Опять же, надо же помочь реализовать вашим разрабам внутреннюю потребность учить и делиться опытом.

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

Удачи!

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

Просто наблюдение "внимательного индейца Джо":
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());

Как получить список шагов внутри теста без выполнения самих шагов?

Дано:
Авто-тесты(Джава + ТестНГ + Аллюр).
Шаги (@Step) - ничего не возвращают, все войд.
Среди тестов встречаются параметризированные.

Странная задача:
а. Сами тесты (шаги) не выполнять;
б. Получить список всех тестов;
в. Для каждого теста - получить список шагов вместе с параметрами.

Не менее странное влобное решение:
1. Использовать аспекты;
2. Вешать  @Around на ("anyMethod() && withStepAnnotation()");
3. Использовать org.aspectj.lang.reflect для вытаскивания аннотаций и названий/значений параметров;
4. Внутри совета @Around - вытягивать нужную информацию, а сам аллюровский шаг не запускать, возвращать налл.

import org.aspectj.lang.JoinPoint;
import org.aspectj.lang.ProceedingJoinPoint;
import org.aspectj.lang.annotation.Around;
import org.aspectj.lang.annotation.Aspect;
import org.aspectj.lang.annotation.Pointcut;
import org.aspectj.lang.reflect.MethodSignature;
import org.testng.ITestResult;
import org.testng.Reporter;
import ru.yandex.qatools.allure.annotations.Step;
...
@Pointcut("@annotation(ru.yandex.qatools.allure.annotations.Step)")
public void withStepAnnotation() {}

@Pointcut("execution( (..))")
public void anyMethod() {}
...
@Around("anyMethod() && withStepAnnotation()")
public Object logTestStepDataAndSkipExecution(ProceedingJoinPoint point) throws Throwable {
    if (isDryRun) {
        MethodSignature methodSignature = MethodSignature.class.cast(point.getSignature());

        String paramNamesAndValues = getParamNamesAndValues(point, methodSignature);
        
        Util.addStepDescriptionEntry(createTitle(point) + " | " + paramNamesAndValues);

        return null;
    } else {
        return point.proceed();
    }
}
...
private String getParamNamesAndValues(JoinPoint point, MethodSignature methodSignature) {
    String[] paramNames = methodSignature.getParameterNames();
    Object[] paramValues = point.getArgs();
    StringBuilder sb = new StringBuilder();
    for (int i=0; i< paramNames.length; i++) {
        sb.append(paramNames[i]).append("=").append(paramValues[i]).append(" | ");
    }
    return sb.toString();
}


Ссылки:
Основная доля вдохновения почерпнута из https://www.yegor256.com/2014/06/01/aop-aspectj-java-method-logging.html
А в целом - https://duckduckgo.com/?q=Java+AspectJ+examples&t=ffab&ia=web

Как оно, начинать.

 Начать автоматизировать/писать тесты и вообще начать похоже на езду на велосипеде. Вроде всё понятно и со стороны прелестно, а вот когда пробуешь сам, то просто не понимаешь как оно вообще возможно сохранить равновесие и куда-то ещё и ехать. И никакие тренинги, книжки, мастер-классы и прочее и прочее не  сделают за тебя тот самый первый толчок ногой и не проедут первые виляющие метры. Только сам, только набивая шишки.

И снова о локаторах.

Отличный локатор элемента.

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

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

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

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

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

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

Актуальная банальность (е.н. Прописная истина) / 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/

А не позапускать ли мордочковые тесты локально и спокойно?

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

А хочется же как? Запустил-забыл-вспомнил-посмотрел отчёт.

Можно завести себе удалённую машину, поднять там Луниевский сервер, гонять тесты через него и т.д. . Можно и виртуалку поднять с аналогичной начинкой. Или виртуалку, но в облаке.

Но есть и другой способ. Тёплый, ламповый, рабоче-погрузочно-крестьянский.

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

1. Установить Селеноид ("Грузчик" и прочее тоже);

2. Настроить (укажите один браузер для начала);

3. Запустить всё это докерное чудо;

4. Указать http://127.0.0.1:4444/wd/hub в качестве урла удалённого сервака Линия;

5. Запустить тесты;

6. Наслаждаться.

В итоге - ничего не мельтешит, всё по-модному в Докере, ещё и в куче браузеров можно запускать. Лепота.

Ссылки:

https://hackernoon.com/selenium-testing-a-new-hope-7fa87a501ee9#.64hdyki27

https://hackernoon.com/selenium-testing-a-new-hope-a00649cdb100#.7u1pq8hz1

https://habrahabr.ru/post/322742/

https://habrahabr.ru/company/wrike/blog/324418/

https://github.com/aandryashin/selenoid

https://github.com/aandryashin/ggr

http://aerokube.com/

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

Почему я недолюбливаю ключесловный подход в автоматизации, слайды.

См. здесь.

Самотренинг по автоматизации. Локаторы элементов.

Содержание.

Что это?
В плоскости автоматизации тестирования это что-то, что помогает найти элемент на странице или на форме: id, name ... .

Какие локаторы хороши?

• Простые и понятные;
• Устойчивые/гибкие и универсальные;
• Быстрые;
• При необходимости позволяющие задавать сложные условия поиска («3-й сверху во второй таблице слева...»).

Какие бывают?

Проще, лучше, быстрее найти элемент по id или name. Предполагается, что id/name уникально, хотя так и бывает не всегда. Чуть менее надёжно искать по другим атрибутам: классу, типу и т.д.. Сложнее потому что гарантий уникальности много меньше. Более изощрённый подход- использование CSS Selector-ов, а уж совсем вершина вершин - XPath.

Ссылки.

[1] http://www.georgehernandez.com/h/xComputers/XML/XSL/XPath.asp
[2] http://www.w3schools.com/xpath/default.asp
[3] http://www.zvon.org/xxl/XPathTutorial/General_rus/examples.html
[4] Набор шпаргалок. Очень ценно на практике - http://extract-web-data.com/5-best-xpath-cheat-sheets-and-quick-references/
[5] Кое-какие откровения на тему посика элементов в таблицах -  http://autotestgroup.com/ru/blog/85.html
[6] Видеолекция по CSS selector + XPath http://www.youtube.com/watch?v=ahhaMbjqrxM

Самотренинг по автоматизации. Введение в Луний.

Содержание.

Что это?
Луний он же Selenium, он же WebDriver, он же Selenium2.0, он же Selenium WebDriver это:

• Библиотека;
• API для управления браузером;
• Стандарт W3C.

... и с учётом всего этого он/она/оно вовсе не инструмент автоматизации тестирования.

Что умеет?
Довольно много:

• Находить элементы: By.Id, By.Name, By.Xpath, By.TagName, By.ClassName, By.CssSelector, By.LinkText, By.PartionalLinkText;
• Нажимать кнопки, изымать текст, выбирать из списков; 
• Поддерживает: FF, IE, Chrome, HtmlUnitDriver, ... ;
• Ждать: Explicit Waits, Implicit Waits;
• Много чего ещё … .

Достаточно ли этого для автоматизации? Это огромное подспорье, но наш каркас для тестирования требует ещё механизмов структуризации кода, запуска и останова, журналирования, генерации отчётов и т.д. Всё это обеспечивается уже не Лунием, а вещами вроде Maven/Gradle, TestNG/JUnit/NUnit и пр. и пр:

Ссылки

Нет смысла писать ещё одну статью, их за годы скопилась огромная масса. Крайне рекомендую перелопатить немного МежСеть самостоятельно и "сформировать картинку".

[1] http://docs.seleniumhq.org/
[2] http://bugscatcher.net/archives/1232
[3] http://habrahabr.ru/post/152971/
[4]http://refcardz.dzone.com/refcardz/getting-started-selenium-20

[5] http://code.google.com/p/selenium/

[6] http://habrahabr.ru/search/?q=selenium

[7] http://selenium.googlecode.com/svn/trunk/docs/api/java/overview-summary.html

Cамотренинг по автоматизации. Подходы: модельный и гибридный.

Содержание.

Модельный подход.
Основная идея этого подхода - разработать и применять некую модель тестируемой системы, которая представляет собой набор требуемых поведений / функций этой системы. В идеале такая модель предоставляет готовые тестовые случаи, которые при минимальных усилиях превращаются в авто-тесты. Звучит фантастически, особенно учитывая то, что разработка такой модель может быть значительно сложнее разработки самой системы. Чуть больше подробностей сообщает педекивия.

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