Я участвую в развитии open source проекта Apache Ignite, работая над проектом мне стало интересно оценить тестовое покрытие и вот что из этого получилось.
Я участвую в развитии open source проекта Apache Ignite, работая над проектом мне стало интересно оценить тестовое покрытие и вот что из этого получилось.
Простой в отладке код — это код, который не дурачит вас. Труднее отлаживать код со скрытым поведением, с плохой обработкой ошибок, с неопределённостями, недостаточно или избыточно структурированный, или находящийся в процессе изменения. В достаточно больших проектах вы в конце концов сталкиваетесь с кодом, который не можете понять.
Если проект относительно старый, то вы можете встретить код, про который вообще забыли, и если бы не журнал коммитов, то поклялись бы, что эти строки писали не вы. По мере разрастания проекта становится всё труднее запоминать, что делают разные куски кода. И ситуация усугубляется, если код делает не то, что, вроде бы, должен делать. И когда нужно изменить код, который вы не понимаете, приходится разбираться жёстко: отлаживать.
Умение писать код, который легко отлаживать, начинается с понимания, что вы ничего не помните о ранее написанном.
Читать полностью »
В данной статье мы поделимся собственным практическим опытом, который мы приобрели при тестировании Web Apps приложения (интернет-магазина), работающего в облаке MS Azure, а также опишем, какими инструментами мы пользовались для решения этой задачи и о выводах, которые были сделаны по полученным результатам.
Читать полностью »
Пользователи виртуализированных систем, а особенно – сервис-провайдеры, очень часто задаются вопросом: «как выжать максимум из имеющегося железа?». И в этом контексте нам нередко приходится обсуждать гипервизор KVM и отличия между разными версиями Virtuozzo. В этом посте мы расскажем о ряде тестов последней системы виртуализации вместе с оценками реальной производительности при типовых нагрузках, а также с учетом патчей Meltdown и Spectre.
Читать полностью »
Привет! Меня зовут Артём, и я занимаюсь автоматизацией тестирования. Антипаттерны в разработке — довольно популярная тема. Но ведь в тестировании тоже есть свои "плохие советы", и они довольно забавно пересекаются с разработкой. Недавно мне на глаза попалась ироничная статья про антипаттерны в тестировании. Вашему вниманию!
Мы стараемся как можно скорее доказать, что неправы, потому что только таким образом можем развиваться.
Ричард Фейнман
Есть много способов усложнить жизнь командам автоматизации тестирования. Если вы разработчик или системный архитектор, и недолюбливаете кого-то из тестировщиков, то эта статья — для вас. Вы найдете в ней сокровенное знание, вдохновившись которым, вы научитесь делать интерфейс любого приложения практически непригодным для тестирования.
Ну, а если вы добрая душа и уважительно относитесь к чужому труду, то можете рассматривать эту статью как набор антипаттернов.
Итак, поехали.
Вряд ли кто-то будет спорить, что наблюдение за производительностью дисковой подсистемы — чуть ли не важнейшая задача для всех высоконагруженных систем хранения и баз данных. Я изначально столкнулся с этим давным-давно, еще когда приходилось наблюдать за PostgreSQL. В последнее время вернулся к этому вопросу в связи с необходимостью тестирования различных хранилищ.
Сегодня хочу поделиться с сообществом своим текущим опытом на реальном примере zabbix и его связке с block stat.
Если попытаться описать прошедший Heisenbug одним словом, это будет «разнообразие». Спикеры из гигантских компаний и из юных стартапов, темы от тестирования мобильных игр до тестирования блокчейна, доклады с кучей кода и совершенно без кода; наконец, были вообще не доклады, а сессии «birds of a feather».
Наверное, лучший способ рассказывать о таком событии — не пытаться найти «общий знаменатель», а привести несколько разных примеров того, о чём можно было услышать на прошедшей конференции. Что мы и сделали под катом.
Читать полностью »
В последнее время мне приходится очень много работать с различными текстами, как своими, так и чужими. Поэтому я хотел бы поделиться с вами некоторыми наблюдениями по поводу того, на что следует обращать внимание при написании текстов целью которых ставится что-либо последовательно объяснять другим людям, преимущественно мало ознакомленными с предметом повествования. Примерами таких текстов могут выступать различные руководства, наши драгоценные тикеты, в которых мы конечно же не забываем грамотно и лаконично описывать шаги для воспроизведения проблемы и даже задокументированные тестовые случаи.
Итак, включая режим капитана Очевидности, я натягиваю простынь на плечи как плащ, трусы поверх шорт и, вытянув одну руку перед собой, лечу в густую массу суровых людей с техническим образованием, дабы поучить немного их всех жизни.
Лирическое отступление: у меня сегодня была какая-то странная проблема с подбором КДПВ, так что пусть ею будет вот такой комикс:
В недавней статье наш боевой товарищ actopolus рассказал о том, как мы научились применять Postman для реализации функционального тестирования нашего API проекта. Научившись писать функциональные тесты, и написав их порядка полутора сотен, мы решили, что настало то самое время — время прикрутить эти тесты к нашим CI-сборочкам.
Вообще, изначально процесс интеграции Postman-тестов в сборки можно было разбить на 3 простых этапа:
Однако, нами не был учтён один очень важный нюанс — у нас не было инструмента для измерения покрытия нашего кода Postman-тестами. Без информации о том, насколько хорошо мы покрываем тестами код, нам было сложно понять где мы находимся сейчас и к чему нам нужно стремиться. Следовательно, план был дополнен ещё одним пунктом:
Как мне кажется, одна их самых больших проблем в скраме — это полный рассинхрон между людьми в команде. Мне пока не удавалось увидеть ни одного стабильного решения этой проблемы. Конечно, есть стандартные инструменты, но далеко не всегда они дают ответы на все вопросы и закрывают все дыры.
Предлагаю зайти к нам в гости и посмотреть как с проблемой синхронизации внутри себя борется команда “Онлайн-ипотеки” компании “Альфа-Банк”.
Читать полностью »