QA meetup #4

Дело тестера боится: как в

опытных руках могут заиграть

Java и TestNg

Вячеслав Марков, QA engineer at Weezlabs

Что нужно проверять при

функциональном тестировании

REST API?

Статус-коды ответа при

различных входных данных

Корректность возвращаемых

данных

Корректность логики работы

TestNG TestNG (Next generation) – тестовый фреймворк для написания автотестов на языке Java.

Unit-тестирование

Функциональное тестирование

End-to-End тесты

Интеграционное тестирование

И это далеко не всё!

+- before suite/

+- before group/

+- before test/

+- before class/

+- before method/

+- test/

+- after method/

...

+- after class/

...

+- after test/

...

+- after group/

...

+- after suite/

Как это работает?

TestNG использует иерархический механизм before- и after- аннотаций для конфигурирования тестов

Что можно протестировать с помощью TestNG?

Выполнить функциональные тесты

Провести регрессионное тестирование

Организовать Continuous Integration

Для чего TestNG подходит не так хорошо?

Нагрузочное тестирование

Data-Driven Testing (DDT)

Большие наборы тестовых данных Много данных — один код Лёгкое добавление тестовых данных

Data-Driven Testing - подход к написанию тестов, позволяющий разнести тестовый код и тестовые данные.

Преимущества DDT

Лёгкость изменения и добавления тестовых данных Тест управляется входными данными Отлично подходит для позитивного и негативного тестирования REST API

Недостатки DDT

Не всегда удобно для проверки эйдж-кейсов Усложняется код теста

Data-Provider в TestNG • В TestNG реализовать DDT- подход позволяет механизм Data-Provider,

последовательно предоставляющий тестовому методу элементы набора тестовых данных

• Наборы тестовых данных мы храним в JSON-файлах в виде массивов • В коде теста необходимо описать метод с аннотацией

@DataProvider

@DataProvider(name = "ddtSet")

public Object[][] ddtSet(ITestContext context) throws IOException, URISyntaxException {

String jsonDdtFile = context.getCurrentXmlTest().getParameter("jsonDdtFile");

URL resourceUrl = getClass().getResource(DDT_DATA_PATH+jsonDdtFile);

ArrayList<userSet> userSetArrayList = new ArrayList<userSet>();

userSetArrayList = mapper.readValue(new File(resourceUrl.getFile()),

new TypeReference<ArrayList<userSet>>() {});

Object[][] objectArray = new Object[userSetArrayList.size()][];

for(int i=0;i<userSetArrayList.size();i++){

objectArray[i] = new Object[] {userSetArrayList.get(i)};

}

return objectArray; }

@Test(dataProvider = "ddtSet", description = "Perform single charge")

public void postSingleCharge(userSet testSet)

Пример используемой нами

структуры проекта TestNG

• Maven-проект • Основные элементы структуры

— модели данных (dto), служебные классы, сами тесты (stories), наборы тестовых данных (ddt), наборы тестов (suites)

Библиотека Rest-Assured

Эта библиотека позволяет тестировать REST API Имеется возможность составлять REST-запросы

любой сложности https://github.com/rest-assured/rest-assured

Response response = given().

header("uid", uid).

header("client", client).

header("access-token", access_token).

header("Content-Type", "multipart/form-data").

header("Accept-Charset", "UTF-8").

multiPart((new MultiPartSpecBuilder(file)

.fileName(filename)

.controlName("origin")

.mimeType(media_type).build())).

post("attachments/image_uploader");

Простой пример: тестируем API

для логина

• POST api/v1/users/sign_in

Assertions. Как проверить результат

вызова API? Hard Assertions

Тест отмечается как проваленный при провале Hard

Assert

Выполнение тестового метода прекращается после

провала Hard Assert

Полезны для общих проверок верхнего уровня

Soft Assertions

Провал SoftAssert не приводит к остановке теста

Все проваленные SoftAssert выводятся после

окончания теста

Позволяют проверить множество параметров

А если что-то сложнее логина?

Проверка совершения оплаты при вызове POST api/v1/payment/single_charge/

• Проверяются не только ожидаемые статус-коды • Проверяется корректность расчётов • Вызов многих REST API в одном тесте

А как собрать мои тесты в тест-сьют?

• Списки выполняемых тестов собраны в xml-файлах • Каждый тест может быть легко параметризован

<test name="Sign Up">

<parameter name="runId" value="68"/>

<parameter name="jsonDdtFile" value="SignUp.json"/>

<classes>

<class name="stories.UserStory.SignUp" > </class>

</classes>

</test>

<test name="SignIn">

<parameter name="runId" value="68"/>

<parameter name="jsonDdtFile" value="SignIn.json"/>

<classes>

<class name="stories.UserStory.SignIn" > </class>

</classes>

</test>

Организовываем Continious Integration

Интеграция со всеми наиболее популярными VCS (Git, SVN etc.)

Поддержка Maven Интеграция со Slack Возможность создания

гибкого расписания запуска тестов

Мы используем

Jenkins, и вот почему:

Документирование результатов

• Web-система тест-менеджмента TestRail

• Поддержка интеграции с Jira • Связь с TestRail с помощью

listeners

Наши вакансии в Ростове-на-Дону и

Таганроге

Project Manager Middle iOS developer

Ждём ваших резюме по адресу

hr@weezlabs.com

Спасибо за внимание!

Вячеслав Марков, QA Engineer at Weezlabs

vmarkov@weezlabs.com

vk.com/markov_tgn