"Опыт создания системы управления сборкой и тестированием" (полная)SPB SQA Group
Доклад посвящен вопросам создания и использования собственной системы управления процессами сборки и тестирования ПО. Описываются ключевые моменты построения таких систем, в частности: вопросы интерфейсов, быстродействия, качества и интеграции в общую инфраструктуру. Затрагиваются концепции встраивания качества в код, сбора и использования метрик ПО, неотделимости сборки от тестирования, автоматизированного ведения базы знаний об ошибках и другие.
В докладе я расскажу о том как я вижу и применяю TDD, почему мне это нравится и почему я хочу, чтобы это нравилось другим. Все это на примере какого-нибудь мини-приложения на базе Django.
21 октября состоялась 1 встреча одесского сообщества Python-разработчиков - Python Meetup.
Поговорили о новых технологиях, диалектах и инструментарии для создания графических интерфейсов.
Докладчики:
Александр Степанов (Python Team Lead at SteelKiwi Inc.)
Тема: Шаблон проекта. Использование Vagrant, VirtualEnv и Ansible provisioner. Зачем это необходимо?
Евгений Гетманский (Рython team lead at SteelKiwi Inc.)
Тема: Оптимизация работы веб сервера с базой данных на примере Django.
"Опыт создания системы управления сборкой и тестированием" (полная)SPB SQA Group
Доклад посвящен вопросам создания и использования собственной системы управления процессами сборки и тестирования ПО. Описываются ключевые моменты построения таких систем, в частности: вопросы интерфейсов, быстродействия, качества и интеграции в общую инфраструктуру. Затрагиваются концепции встраивания качества в код, сбора и использования метрик ПО, неотделимости сборки от тестирования, автоматизированного ведения базы знаний об ошибках и другие.
В докладе я расскажу о том как я вижу и применяю TDD, почему мне это нравится и почему я хочу, чтобы это нравилось другим. Все это на примере какого-нибудь мини-приложения на базе Django.
21 октября состоялась 1 встреча одесского сообщества Python-разработчиков - Python Meetup.
Поговорили о новых технологиях, диалектах и инструментарии для создания графических интерфейсов.
Докладчики:
Александр Степанов (Python Team Lead at SteelKiwi Inc.)
Тема: Шаблон проекта. Использование Vagrant, VirtualEnv и Ansible provisioner. Зачем это необходимо?
Евгений Гетманский (Рython team lead at SteelKiwi Inc.)
Тема: Оптимизация работы веб сервера с базой данных на примере Django.
"Опыт создания системы управления сборкой и тестированием" (слайдкаст)SPB SQA Group
Доклад посвящен вопросам создания и использования собственной системы управления процессами сборки и тестирования ПО. Описываются ключевые моменты построения таких систем, в частности: вопросы интерфейсов, быстродействия, качества и интеграции в общую инфраструктуру. Затрагиваются концепции встраивания качества в код, сбора и использования метрик ПО, неотделимости сборки от тестирования, автоматизированного ведения базы знаний об ошибках и другие.
*Netpeak Talks — это серия ивентов от Netpeak Group в Одессе (при поддержке ассоциации продуктовых компаний IT-Products Odessa).
В рамках этих встреч есть возможность обсудить с практикующим спикером наболевшие темы, связанные с R&D, дизайном, менеджментом, интернет-маркетингом, QA, Customer Success, аналитикой и др. (все темы от встречи к встрече не повторяются и отличаются друг от друга).
______________________
Тема #11: Как работать с legacy проектом, которому больше 10 лет?
Спикер: Денис Воскобойник — Team Lead отдела разработки внутренних продуктов в Netpeak Agency.
Тезисы видео:
✔ Построение процессов разработки.
✔ Подготовка команды к проекту.
✔ Внедрение / обновление стека технологий.
✔ Как рефакторить?
✔ Как понять, что нужно вынести отдельно и нужно ли это?
✔ Как тестировать то, что никогда не тестировалось?
✔ Code Review.
_____________________
Информацию об этом и следующих мероприятиях ты можешь отследить:
Сайт: http://netpeak.group/talks
Facebook: https://www.facebook.com/NetpeakTalks/
Телеграм: https://t.me/netpeaktalks
"Опыт создания системы управления сборкой и тестированием" (слайдкаст)SPB SQA Group
Доклад посвящен вопросам создания и использования собственной системы управления процессами сборки и тестирования ПО. Описываются ключевые моменты построения таких систем, в частности: вопросы интерфейсов, быстродействия, качества и интеграции в общую инфраструктуру. Затрагиваются концепции встраивания качества в код, сбора и использования метрик ПО, неотделимости сборки от тестирования, автоматизированного ведения базы знаний об ошибках и другие.
*Netpeak Talks — это серия ивентов от Netpeak Group в Одессе (при поддержке ассоциации продуктовых компаний IT-Products Odessa).
В рамках этих встреч есть возможность обсудить с практикующим спикером наболевшие темы, связанные с R&D, дизайном, менеджментом, интернет-маркетингом, QA, Customer Success, аналитикой и др. (все темы от встречи к встрече не повторяются и отличаются друг от друга).
______________________
Тема #11: Как работать с legacy проектом, которому больше 10 лет?
Спикер: Денис Воскобойник — Team Lead отдела разработки внутренних продуктов в Netpeak Agency.
Тезисы видео:
✔ Построение процессов разработки.
✔ Подготовка команды к проекту.
✔ Внедрение / обновление стека технологий.
✔ Как рефакторить?
✔ Как понять, что нужно вынести отдельно и нужно ли это?
✔ Как тестировать то, что никогда не тестировалось?
✔ Code Review.
_____________________
Информацию об этом и следующих мероприятиях ты можешь отследить:
Сайт: http://netpeak.group/talks
Facebook: https://www.facebook.com/NetpeakTalks/
Телеграм: https://t.me/netpeaktalks
Тест-план и исследовательское тестированиеVasiliy Burov
В своем докладе я расскажу как мы в своей работе совмещаем тест-план и исследовательское тестирование. С первого взгляда, может показаться что это не совсем совместимые вещи. Исследовательское тестирование ассоциируется с методом свободного поиска, а тест-план наоборот – следование заданному порядку. Как совместить эти сущности и ничего не потерять – я попытаюсь рассказать.
Зачем тестировать? Тестирование в интерпретаторе и доктесты. Модуль unittest. Пакет py.test - на порядок лучше. Тестирование свойств и пакет hypothesis.
Презентация делалась для JuJa конференции - Java конференции для (пре) Juniors: https://juja.com.ua/materials/jujacon-2017/
В ней
- описываются основные темы-вопросы, которые часто спрашивают на собеседовании на позицию Junior Java Developer;
- советы, что спросить собеседующего;
- как себя позиционировать, как относиться к собеседованию, как не бояться и как понять, что вам "туда".
В длительной перспективе ретроспективы – самая важная часть гибких процессов. Но очень часто у команд не получается запустить процесс непрерывного улучшения, либо через некоторое время этот процесс обрывается, когда команда думает, что все проблемы решены. Я расскажу не только теоритическую часть, которая позволит преодолеть эти проблемы, но и дам несколько десятков примеров конкретных практик, которые применяются на эффективных ретроспективах. Доклад рассчитан, как на начинающих ретроспективы, так и практиков гибких методологий.
This document discusses continuous performance testing (CPT) and introduces the Jagger CPT solution. It provides an overview of why performance testing is important, outlines the principles and goals of CPT, and describes the key parts of the Jagger CPT platform including load generation, metrics collection, test data management, and environment management. It also provides an example customer success story where Jagger was used for continuous performance testing of a large ecommerce site.
Мощь переполняет с JDI 2.0 - новая эра UI автоматизацииSQALab
This document provides an overview of the JDI (Java UI test automation framework). It discusses features of JDI including being UI element oriented, providing common UI elements and solutions to common problems. It provides examples of how to write tests using JDI annotations and page object pattern. The document also summarizes benefits of JDI such as reducing test code, improving test clarity, reuse across projects. Finally it outlines new features planned for JDI 2.0 including layout verification, page object generator, integration with Selenium and expanding JDI to other languages like Python.
The document discusses testing of geolocation systems. It provides an overview of geolocation, including definitions and importance. It then outlines the speaker's experience and work testing GIS systems. The rest of the document details approaches to testing geolocation, including simulating calls, checking responses and databases, and verifying accuracy. It also discusses common data formats, projections, tools like PostGIS and QGIS, and potential bugs to watch for like coordinate jumbling. The conclusion emphasizes starting simple, practicing to improve, and for tests to grow with knowledge as geolocation is important for future IT.
10. Понедельник: подготовка к тестированию
Нужна серьезная подготовка к тестированию
производительности …
11. Обработка запросов
Запрос
1. Разбирает запрос
2. Оценивает окружение
3. Анализирует
распределение данных
4. Строит эффективный
план запроса
5. Выполняет запрос
Данные
Вывод: оптимизация очень сильно зависит от
конкретных условий выполнения.
12. Подготовка к тестированию
производительности запросов
Цель – быть как можно “ближе” к реальному
окружению.
Необходимо:
1. Проконтролировать одинаковость
тестового и реального окружений.
2. Сверить совпадение схем баз данных.
3. Собрать достаточное количество реальных
запросов.
4. Подготовить процесс запуска запросов и
сбора метрик.
13. Подготовка: 1 - тестовое окружение
Необходимо проверить:
1. Что тестовый сервер как можно ближе к
“реальному”: CPU, жесткий диск, RAID-
ы, оперативная память.
2. Совпадение операционных
систем, обновлений.
3. Настройки СУБД: версия, сколько памяти
выделено, на какие диски смонтированы базы, collation-
ы.
14. Подготовка: 2 - база данных
1. Проверить совпадение схем баз данных:
одинаковость
индексов, функций, статистики, collation.
2. Данные должны быть близкие к реальным.
Нет никакого смысла тестировать производительность
запросов на тестовых (смоделированных) данных.
15. Подготовка: 3 - запросы
Запрос
Запрос
1. Необходимо использовать только запросы
от реальных пользователей.
2. Количество запросов должно быть
достаточным.
16. Подготовка: 4 - процесс запуска
Цель - получать контролируемые результаты
для их дальнейшего анализа.
Необходимо создавать как можно более
стабильную из теста в тест нагрузку. Поэтому
важно контролировать:
1. Порядок запуска запросов (иначе возможны
серьезные расхождения в результатах из-за
разных закешированных планов запроса).
2. Создаваемую нагрузку (количество
параллельно запускаемых запросов).
17. Выводы
1. Обязательно контролировать, что тестируемые
сервера обладают сравнимой с продакшеном
производительностью.
2. Нет большого смысла тестировать
оптимизацию на смоделированных данных.
3. Необходимо стремиться воспроизводить как
можно более похожую на реальную нагрузку.
4. Если вы проигнорировали или не обеспечили
хотя бы один из подготовительных шагов –
вашим тестам нельзя доверять.
24. Анализ результатов: метрики
1. Время выполнения запроса.
2. Количество логических чтений.
3. Время СУБД на обработку запроса.
4. Количество памяти, выделенное на
обработку запроса.
26. Анализ результатов: распределение
по времени выполнения.
Главный пик сместился, т.е
большинство запросов
стало быстрее.
Но появился новый
пик, которого раньше не
28. Выводы
1. Практически невозможно оптимизировать
запрос так, чтобы не замедлить что-то
другое.
2. Обычно нет проблем оптимизировать один
проблемный запрос. Наибольшая сложность
- оптимизировать весь набор запросов.
3. Поэтому - чем более универсальный
запрос, тем он медленнее!
4. Это первый из “балансов”. Можно
оптимизировать какой-то конкретный
запрос за счет других.
33. Экспресс анализ изменений
create view dbo.v_diagnosis_clustered
with schemabinding as
select g.diagnosis_id, g.patient_id,
g.desease_name, g.create_time,
d.doctor_id, d.hospital_id, d.doctor_name
from DIAGNOSIS g
inner join DOCTOR d
on g.doctor_id = d.doctor_id
select …
from PATIENT p
cross apply
(
select top 1 desease_name, doctor_name
from V_DIAGNOSIS_CLUSTERED g
where g.patient_id = p.patient_id
and g.hospital_id = @hospital_id
order by g.create_time
) d
select …
from PATIENT p
cross apply
(
select top 1 desease_name, doctor_name
from DIAGNOSIS g
inner join DOCTOR d
on g.doctor_id = d.doctor_id
where g.patient_id = p.patient_id
and d.hospital_id = @hospital_id
order by g.create_time
) d
create unique clustered index clustered_index
on dbo.v_diagnosis_clustered
(hospital_id, patient_id)
Старая версия Новая версия
34. View vs Indexed View
1. Виртуальная
(логическая)
таблица, представляюща
я собой поименованный
запрос.
2. Физически данные не
хранятся. SELECT
вычисляется каждый
раз, когда к нему
обращаются.
View Indexed View
1. Представление, на
котором создан
кластерный индекс.
2. Физически данные
хранятся, как и в
обычной таблице.
35. Баланс скорости чтения и скорости
модификаций
1. Кластерное представление будет
пересчитываться при каждой модификации
исходных таблиц.
2. Модификация станет медленнее, а
чтение, скорее всего, быстрее.
3. Баланс №2 – оптимизация скорости чтения
за счет скорости модификаций или
наоборот.
40. Выводы
1. Наиболее важный баланс в оптимизации
запросов – это баланс скорости чтений и
скорости модификаций.
2. Практически всегда можно ускорить
чтения, замедлив соответствующие
изменения данных.
3. Принимать решения о приемлемости такой
оптимизации необходимо, основываясь на
знаниях о приложении.
44. Индексы: куча
extent
IndexAllocationMap
extent
extent
create table DOCTOR
(
doctor_id int identity(1,1) not null,
hospital_id int not null,
first_name nvarchar(50) not null,
last_name nvarchar(50) not null,
create_time datetime not null
)
Так как нет кластерного
индекса, очевидно, что
данные в куче
неупорядоченные.
Table Scan
Table Scan
Table Scan
45. Индексы: кластерный индекс
ALTER TABLE DOCTOR
ADD CONSTRAINT PK_DOCTOR
PRIMARY KEY CLUSTERED
(
doctor_id asc
)
Data Rows
264 …
… …
312 …
Data Rows
210 …
… …
263 …
Data Rows
157 …
… …
209 …
Data Rows
104 …
… …
156 …
Data Rows
53 …
… …
103 …
Data Rows
1 …
… …
52 …
Index Rows
157
210
264
Index Rows
1
53
104
Index Rows
1
157
Root
Intermediate Level
Leaf / Data Level
На листовых уровнях хранятся
значения всех столбцов
Определяет физический порядок
даных, поэтому может быть
создан только однин кластерный
индекс на таблице
Все индексы
организованы
как B-Tree
46. CREATE NONCLUSTERED INDEX IX_HOSPITAL
ON DOCTOR
(
hospital_id
)
Data Rows
264 …
… …
312 …
Data Rows
210 …
… …
263 …
Data Rows
157 …
… …
209 …
Data Rows
104 …
… …
156 …
Data Rows
53 …
… …
103 …
Data Rows
1 …
… …
52 …
Root
Intermediate
Level
Leaf Level
Index Rows
1
25
Index Rows
51
75
Index Rows
1
51
Index Rows
1
…
24
1
...
104
Index Rows
25
…
50
100
...
209
Index Rows
51
…
74
106
...
202
Index Rows
75
…
83
264
...
210
ClusteredIndex
Тоже организован как B-Tree
Не задает физический
порядок хранения данных
в таблице, а сортирует
данные в каком-то порядке
Содержит копии
данных из таблицы
На листовом уровне
содержатся ссылки на
кластерный индекс
Индексы: некластерный индекс
50. Выводы
1. Изменения индексов – наиболее
популярный и простой способ
оптимизации.
2. Индексы, как и кластерные
представления, замедляют операции
модификации.
3. Обычно функциональное тестирование
не требуется.
54. Выводы
1. Для любой задачи существует несколько
путей и подходов оптимизации.
2. Оптимизация запросов – это всегда
вопрос баланса, поэтому задача
тестирования - правильно выявить этот
баланс.
3. Выбор того или иного решения всегда
зависит от специфики приложения.
55. Выводы недели
1. Подготовка к тестированию – самый
важный этап. Если вы проигнорировали хотя
бы один из подготовительных шагов – вашим
тестам нельзя доверять.
2. Оптимизация – это вопрос баланса:
• оптимизация какого-то конкретного
запроса за счет других;
• оптимизация чтений за счет
модификаций;
3. Поэтому почти всегда можно найти, что в
действительности стало медленнее.
58. Подводим итоги недели
1) Разобрались с операциями над
множествами, такими как except и
union. И даже реализовали except all.
2) Мы разработали метод
функционального тестирования
запросов.
3) Нашли очень замысловатую
логическую ошибку и исправили
старый функциональный баг.
Подход Доктора Хауса к тестированию
оптимизации запросов
1. Разбираться в
проблеме до конца.
2. Быть одной
командой.
3. Все врут, а значит -
всё нужно
перепроверять.
4. Не бояться резать по
живому, но всегда
контролировать.
5. Не сдаваться!!!
59. Вопросы?
Team Lead / Software
Developer in VIAcode
www.linkedin.com/in/ssmikhalev
vk.com/ssmikhalev
ssmikhalev@gmail.com
f1incode.com