Дело тестера боится: как в опытных руках могут заиграть Java и TestNgIT61
Вячеслав Марков, QA engineer в Weezlabs
Я расскажу о том, как в нашей фирме организовано тестирование бэкенда с помощью тестового фреймворка TestNG и Java. Расскажу о data-driven тестировании и о том, почему его удобно применять. Покажу и опишу разработанную нами структуру типового тестового проекта. Представлю применяемые нами способы сбора и документирования результатов, а так же их анализ в условиях CI.
Дело тестера боится: как в опытных руках могут заиграть Java и TestNgIT61
Вячеслав Марков, QA engineer в Weezlabs
Я расскажу о том, как в нашей фирме организовано тестирование бэкенда с помощью тестового фреймворка TestNG и Java. Расскажу о data-driven тестировании и о том, почему его удобно применять. Покажу и опишу разработанную нами структуру типового тестового проекта. Представлю применяемые нами способы сбора и документирования результатов, а так же их анализ в условиях CI.
В этой презентации я рассказываю не только об автотестах, а о целом комплексе автоматических инструментов для обеспечения качества веб-сервиса на разных этапах разработки.
Как обеспечить проверку формата? Как поддерживать документацию в актуальном виде? Какую архитектуру выбрать для функциональных тестов?
Немного интересного про JSON-схемы и параметризованные тесты, про тестирование API методом чёрного ящика и про выбор исходных данных для тестирования.
В этой презентации я рассказываю не только об автотестах, а о целом комплексе автоматических инструментов для обеспечения качества веб-сервиса на разных этапах разработки.
Как обеспечить проверку формата? Как поддерживать документацию в актуальном виде? Какую архитектуру выбрать для функциональных тестов?
Немного интересного про JSON-схемы и параметризованные тесты, про тестирование API методом чёрного ящика и про выбор исходных данных для тестирования.
QA Fes 2016. Игорь Любин. Об автоматическом тестировании бэкенда в MediaMarktQAFest
В этом докладе пойдет речь исключительно об автоматическом тестировании. Тестировать бэкенд можно только так. Я расскажу об используемых подходах и практиках, которые можно применить в работе. Мы поговорим с чего начинать автоматическое тестирование бэкенда. Задам направление развития и поделюсь идеями, так чтобы вы по-другому взглянули на профессию тестировщика.
21 октября состоялась 1 встреча одесского сообщества Python-разработчиков - Python Meetup.
Поговорили о новых технологиях, диалектах и инструментарии для создания графических интерфейсов.
Докладчики:
Александр Степанов (Python Team Lead at SteelKiwi Inc.)
Тема: Шаблон проекта. Использование Vagrant, VirtualEnv и Ansible provisioner. Зачем это необходимо?
Евгений Гетманский (Рython team lead at SteelKiwi Inc.)
Тема: Оптимизация работы веб сервера с базой данных на примере Django.
Архитектура кода нового 2ГИС Web API или куда мы дели MVCDevDay
Сергей Коржнев
Архитектор версии 1.4 2ГИС Web API
Архитектура кода нового 2ГИС Web API или куда мы дели MVC
Тезисы:
● Как организован код в старой версии.
● Вдумчиво смотрим, как мы используем Yii, хватаемся за голову и клавиатуру. Там отрезаем, тут пришиваем, и вуаля!
● Ну и делаем выводы, как мы забороли две классические проблемы программирования: борьба с дублированием кода и сложностью системы.
Как автоматизировать тестирование WebApi, даже если проект завязан на внешние сервисы. Как тестировать WebApi-сервер без постоянных деплоев, как дебажить во время прогона интеграционных тестов.
Видео https://www.youtube.com/watch?v=fuS1IaLSGV0
Доклад Ильи Кудинова на DevConf 2013. "Организация автоматизированного тестир...Badoo Development
Доклад о том, как выжить в условиях двух релизов в день, не понижая планку
качества проекта и дать разработчикам и QA-инженерам больше времени на
полезные дела.
Подробно:
Прослушав доклад, вы узнаете:
1. Что НА САМОМ ДЕЛЕ называется непрерывной интеграцией;
2. Кому и зачем нужно переходить на Continious Integration;
3. Почему процесс контроля качества начинается ещё до написания кода;
4. Как программисты учавствуют в процессе тестирования;
5. Как устроен наш поток тестирования с пятью (!) уровнями контроля;
6. Как наши QA-инженеры тестируют задачи до релиза в максимально
реалистичных условиях;
7. Как помогает тестированию плотная интеграция Git, Jira и TeamCity;
8. Зачем нужны более 20 тысяч автоматических тестов и кто их должен
разрабатывать и поддерживать;
9. Чем непрерывно занимаются более 10 агентов-тестировщиков в нашей
TeamCity;
10. Какими средствами мы добились того, чтобы пункты 8 и 9 не превращал
QA-процесс в долгое и унылое действо.
Badoo — это большая социальная сеть с более чем 180 млн. пользователей. Большинство новых фич в нашей компании мы предварительно оцениваем посредством A/B тестирования. Вот уже примерно год мы используем собственный высоконагруженный фреймворк тестирования, при этом по моему мнению он очень прост, понятен, и не требует огромных ресурсов на разработку и поддержку. В докладе я расскажу вам о том, почему мы пришли к собственному решению, его архитектуру и принципы работы. Я уверен, каждый из вас может сделать что-то подобное для своего проекта и начать принимать более обоснованные решения.
Тезисы:
* Как мы раньше тестировали
* Почему мы сделали свой инструмент
* Архитектура: API, граф. интерфейсы, транспорт, скрипты, БД
* Структура теста
* Основные правила А/Б тестирования
* Оценка результатов, примеры отчетов
* И заключительная часть про то, что от человека с головой полностью не избавиться
Для кого доклад:
Для разработчиков и техн. менеджеров соц. сетей, сайтов объявлений, блогов с рассылками, проектов, продающих что-то через e-mail расслыки, разных коммьюнити-сайтов, банков и вообще проектов, где взаимодействие с каждым клиентом долгосрочное.
Сложность:
Несмотря на то, что конференция называется Highload++, я уверяю, что представленную здесь архитектуру может потянуть проект с посещаемостью в 1000 чел в день и тремя программистами в штате. Закодить все, что здесь рассказано на PHP займет меньше недели одного человека. А результат, между прочим, пожно вполне изменрять в живой прибыли.
“Можно ли перевернуть пирамиду?” – автоматизируем тестирование с меньшим числ...Igor Khrol
Когда мы говорим об автоматизации тестирования, чаще всего вспоминается Selenium, Microsoft Coded UI, QTP и другие аналогичные инструменты. Мы хотим воспроизводить действия ручного тестирования с максимальной точностью, чтобы можно было с уверенностью сказать, что тот или иной тест-скрипт повторяет какую-то часть сложившихся на проекте тестов. Когда же тестов становится чуть больше, то мы обнаруживаем, что наши тесты запускаются долго, работают нестабильно. После чего мы начинаем говорить о параллелизации, виртуализации, четырёхслойной архитектуре фреймворка и прочих жутко интересных вещах… Это всё очень хорошо, но главная цель где-то остаётся в стороне – контроль качества нашего продукта.
В своём докладе я попытаюсь слегка задать направление другой альтернативе: отойти от автотестов через пользовательский интерфейс в сторону более низкоуровневых, которые значительно быстрее и стабильнее. Если вас также волнует “переворачивание” пирамиды автоматизации тестирования, то приглашаю присоединиться к обсуждению этой сложной и важной темы.
Что могут статические анализаторы, чего не могут программисты и тестировщикиAndrey Karpov
Одной из технологий выявления ошибок на ранних этапах является статический анализ кода. К сожалению, ряд инструментов реализуют анализ весьма поверхностно, что снижает доверие к методологии статического анализа в целом. Некоторые программисты начинают думать, что анализ кода — это нечто, базирующееся на регулярных выражениях и они сами легко найдут такие ошибки. На самом деле всё гораздо сложнее и интересней. Более того, многие ошибки невероятно сложно найти, если не использовать инструменты статического анализа кода. И в этом докладе будет продемонстрировано множество таких случаев. Послушав доклад, вы взглянете на статический анализ совсем по-новому. Дополнительно будет рассказано с чего начать, если вы захотите внедрить инструмент статического анализа в уже существующий процесс разработки.
Наиболее дешевый способ разработки - это тот, где артефакты за ОДНУ итерацию попадают в использование к клиенту. Без 10+ итераций доработок из-за найденных ошибок. В докладе мы рассмотрим набирающий популярность на западе подход shift left testing. Его цель - предотвращение возникновения ошибок, а не привычный для многих поиск уже сделанных ошибок в ПО. Тестирование со сдвигом влево предполагает, что тестирование и разработка работают в тандеме и, как следует из названия, тестирование переносится на самые ранние этапы разработки.
- Вы узнаете зачем нужно тестировать требования и документацию. А также рассмотрим какие инженерные практики помогают сделать это частью культуры в команде. (code review, pull request, spec by example, bdd, atdd)
- Рассмотрим какие виды автоматизированных тестов и когда нужно писать, дабы уменьшить количество ручных тестов на поздних этапах разработки продукта. (tdd, bdd, atdd, компонентные и интеграционные тесты)
- Разберем как изменяются совместные командные активности и функциональные обязанности каждого члена команды. (Планирование, грумминг, ретроспектива, демо, dsm, составление тестовой стратегии, планирование тестирования).
- Вспомним почему так важно проектировать тестовую модель с использованием практик тест-дизайна, а не полагаться только на исследовательское тестирование. Вспомним тестирование потока управления, циклов, потоков данных. Рассмотрим на практических примерах, почему разработчикам необходимо осваивать навыки тест-дизайна.
- В завершение рассмотрим один из способов подсчета test coverage и чем оно отличается от code coverage. В качестве примера нарисуем граф требований и проверим покрытие тестовой модели.
Весь доклад будет рассмотрен на примере тестирования очень простого приложения, состоящего из одного микросервиса, БД и WEB-странички. Shift left testing лежит в основе методологий Agile и DevOps.
Опыт разработки сложных клиент-серверных приложений на TypeScript и ASP.NETGoSharp
Наша команда в DevExpress недавно выпустила Preview версию нового продукта, RTF web-редактора – ASPxRichEdit.
Продукт требует высокой отзывчивости на действия пользователя и максимальной производительности. Поэтому клиент получился «толстым» в отличие от «тонких клиентов» большинства бизнес-приложений.
В составе продукта два полнофункциональных компонента - клиентский и серверный текстовые процессоры. Оба компонента работают независимо друг от друга. Клиентская часть создавалась как оптимизированная версия серверного компонента, переписанного с .NET на TypeScript.
Клиентская часть не уступает в сложности серверной. Кроме того, возникают дополнительные проблемы синхронизации состояний моделей на клиенте и сервере и глубокого тестирования клиент-серверного взаимодействия.
В этом докладе вы узнаете, как мы разрабатывали этот продукт, какие проблемы встретили и какие методики тестирования использовали.
Similar to Автоматизация функционального тестирования REST API: секреты, тонкости и подводные камни (20)
12. ● Ресурсы, однозначно определяемые по URL
● Представления ресурсов (JSON)
● Методы работы с ресурсами
REST - это...
POST /reviews GET /reviews/666
PUT /reviews/666
PATCH /reviews/666
DELETE /reviews/666
23. {
code: 200
status: "success"
review:
{
filial_id: "985690699651034"
text: "Для меня Code Fest - это глоток свежего воздуха. Только
надо баги пофиксить."
is_recommended: false
project_id: 1
source: "flamp"
rating: 4
date_created: "2011-03-28T05:30:50+04:00"
user_id: 171
photo: null
}
}
24. {
code: 200
status: "success"
review:
{
filial_id: "985690699651034"
text: "Для меня Code Fest - это глоток свежего воздуха. Только
надо баги пофиксить."
is_recommended: false
project_id: 1
source: "flamp"
rating: 4
date_created: "2011-03-28T05:30:50+04:00"
user_id: 171
photo: null
}
}
точное значение
25. {
code: 200
status: "success"
review:
{
filial_id: "985690699651034"
text: "Для меня Code Fest - это глоток свежего воздуха. Только
надо баги пофиксить."
is_recommended: false
project_id: 1
source: "flamp"
rating: 4
date_created: "2011-03-28T05:30:50+04:00"
user_id: 171
photo: null
}
}
точное значение
тип значения и его диапазон
26. {
code: 200
status: "success"
review:
{
filial_id: "985690699651034"
text: "Для меня Code Fest - это глоток свежего воздуха. Только
надо баги пофиксить."
is_recommended: false
project_id: 1
source: "flamp"
rating: 4
date_created: "2011-03-28T05:30:50+04:00"
user_id: 171
photo: null
}
}
точное значение
enum
тип значения и его диапазон
27. {
code: 200
status: "success"
review:
{
filial_id: "985690699651034"
text: "Для меня Code Fest - это глоток свежего воздуха. Только
надо баги пофиксить."
is_recommended: false
project_id: 1
source: "flamp"
rating: 4
date_created: "2011-03-28T05:30:50+04:00"
user_id: 171
photo: null
}
}
точное значение
enum
тип значения и его диапазон
формат значения
28. {
code: 200
status: "success"
review:
{
filial_id: "985690699651034"
text: "Для меня Code Fest - это глоток свежего воздуха. Только
надо баги пофиксить."
is_recommended: false
project_id: 1
source: "flamp"
rating: 4
date_created: "2011-03-28T05:30:50+04:00"
user_id: 171
photo: null
}
}
точное значение
наличие атрибута
enum
тип значения и его диапазон
формат значения
30. ● После DELETE сущность стала недоступна
● После логаута access token удаляется
31. ● После DELETE сущность стала недоступна
● После логаута access token удаляется
запрос сущности возвращает 404
32. ● После DELETE сущность стала недоступна
● После логаута access token удаляется
запрос с данным токеном возвращает 401
запрос сущности возвращает 404
33. ● После DELETE сущность стала недоступна
● После логаута access token удаляется
запрос с данным токеном возвращает 401
или
запрос сущности возвращает 404
access token отсутствует в БД
73. public function providerGetBlogAuthors()
{
// запись блога
$article = Db()->table('articles')->isPublished(true)->hasAuthor(true)->getRow();
// неопубликованная запись блога
$article_not_published = Db()->table('articles')->isPublished(false)->getRow();
return [
// опубликованная
[$article, Config()->roles->user, 200],
// неопубликованная под авторизованным юзером
[$article_not_published, Config()->roles->user, 404],
// неопубликованная под гостем
[$article_not_published, Config()->roles->guest, 404],
];
}
public function testGetBlogAuthors($article, $user_id, $expected_code)
Формируем тестовые наборы
74. /**
* @dataProvider providerGetBlogAuthors
*/
public function testGetBlogAuthors($article, $user_id, $expected_code)
{
// Задаём http-метод, метод API, параметры запроса
$this->http_method = 'GET';
$this->method = "blogs/{$article->id}/authors";
// Выполняем запрос и проверяем коды ответа
$this->asUser($user_id)->send();
$this->waitFor($expected_code);
Получаем авторов записи блога
75. // проверяем поля в ответе
if ($expected_code === 200) {
$actual = $this->getResponseBody()->authors;
// авторов может быть много, проверяем первого
$expected[0] = [
'name' => CHECK_STRING_NOT_EMPTY,
'user' => CHECK_NOT_NULL,
];
$this->assert($expected, $actual);
}
Получаем авторов записи блога
76. public function testDeleteReview($entity_id, $cause, $user_id, $expected_code)
{
// Задаём http-метод, метод API, параметры запроса
$this->http_method = 'DELETE';
$this->method = "reviews/{$entity_id}";
$this->params = [
'cause' => $cause
];
// Выполняем запрос и проверяем коды ответа
$this->asUser($user_id)->send();
$this->waitFor($expected_code);
// Проверка на повторное удаление сущности
if ($expected_code === 202) {
$this->asUser($user_id)->send();
$this->waitFor(404);
}
}
Удаляем отзыв