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

2018-06-10

How-to adapt test Data-pool.


 There is such a thing  Test Data-Pool. Seems to be usefull and there are usage examples but still it is not absolutely clear how-to start.
Given there are tests based on Java+testNG+maven + something else. Let's start:
1. Add maven dependency
 com.griddynamics.qa.datapool
 data-pool
 1.0.1
Specify actual version of course.
2. Greate/find entities package. Add a new entity class
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();
}
Field set could be different.
3. Greate/find  /resources/data directory and add the data-file

!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?}

Let's name the file as ls.yml
4. Highly likely there is a BaseTest so add the following to it
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. And finally, within a test
BitBucketUser usr = getUserByLogin("Uzvr_Odin");
loginPage().login(usr.getLogin(), usr.getPassword());

2018-01-17

TestNG, skipped tests and "why" related information.


 As usually there are passed, failed and skipped tests. TestNG map skip tests due to failures in
precondition steps (i.e. somewhere inside all those @BeforeSuite/Group/Method routines). In such a case there is no quick-human-readable
explanation why a test was skipped. That is a pity, so what about the following:
1. Go to TestListenerAdapter#onTestSkipped(ITestResult result);
2. Check Throwable of that ITestResult;
3. If null then get skipped configurations - result.getTestContext().getSkippedConfigurations();
4. I haven't found a straight way to link skipped configuration and skipped test, but one could try to do that via TestContext/TestClass:
check whether skippedConfig.getTestClass().equals(result.getTestClass()))
5. If there is skipped config caused the test to be skipped then use result.setThrowable() to transfer throwable to ITestResult;
6. No guarantees but seems to work.

2017-12-30

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

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

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


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

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

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-12-05

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

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

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

2017-09-20

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

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

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

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

- архитектуру и структуру. Проистекает из вопроса "что покрываем?". Навскидку:
 а. микросервисы или монолит;
 б. сервисы на основе бинарных протоколов или РЕСТ какой-нибудь;
 в. нужно воздействовать на одну систему или несколько.

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

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

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

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

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

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

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


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

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


2017-03-27

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

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

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

1. Установить Селеноид ("Грузчик" и прочее тоже);
2. Настроить (укажите один браузер для начала);
3. Запустить всё это докерное чудо;
4. Указать http://127.0.0.1:4444/wd/hub в качестве урла удалённого сервака Линия;
5. Запустить тесты;
6. Наслаждаться.

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

Ссылки:






2016-01-28

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!

О наступании на горло собственной песни.

Синьоры!  Когда вы собираетесь замутить что-нибудь такое-этакое в своем очередном каркасе для авто-тестов, помните - вот это вот потом поддерживать мидлам. Пожалейте их мозг  и осталяйте хоть какие-то описания как эта вундервафля предположительно работает.

2015-12-03

You should read documentation, really - Allure reports + TestNG and run from command line.

 One have to read documentation, no options! It clearly stated that you have to run java process in a special way if you want to get steps, attachments etc info in your Allure report upon running a TestNG based test set.  And no, I had to spend two hours just to re-read the spec and discover that aspectjweaver dependency! And only after that it became clear that here is the way:

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