С праздниками, друзья! Если вы не против научиться на каникулах чему-то новому, прочитайте лекцию Кирилла Борисова — разработчика систем авторизации Яндекса. Кирилл объясняет, как построить процесс тестирования Android-приложений, знакомит с современными инструментами и спецификой их использования.
— Прежде чем двинуться вперед, давайте устроим небольшой соцопрос. Кто из вас знает, что такое тесты? Кто пишет тесты? А кто знает, зачем он пишет тесты? Читать полностью »
Пока мы после конференции Heisenbug собирали и анализировали зрительский фидбэк, на Хабре появился подробный пост IvanPonomarev с его впечатлениями зрителя. И чтобы не повторять его, а дополнить, мы решили построить свой текст о конференции иначе.
Не описывать последовательно все два дня с вечеринкой, а посмотреть по зрительским оценкам, какие из не упомянутых Иваном докладов сильнее всего понравились аудитории (у всех таких оценки оказались выше 4.2), и рассказать немного о них. В итоге получился список «шесть вещей, которые привлекли зрителей Heisenbug» — по нему можно оценить и конкретные темы, и их разброс.
Овидиу Черешес, автор статьи, перевод которой мы сегодня публикуем, написал тысячи тестов пользовательских интерфейсов. Он говорит, что тестирование должно вселять в разработчика уверенность в том, что его программы работают именно так, как он ожидает, и, в том, что они продолжат делать своё дело и после того, как их модифицируют и расширяют. Однако, тестирование пользовательских интерфейсов редко даёт уверенность. Вместо этого оно часто ведёт к разочарованиям и к мыслям о непродуктивности программистского труда.
Он говорит, что поднимает вопрос тестирования интерфейсов, написанных на React, так как сталкивался с характерными для этого процесса проблемами за годы до широкого распространения этого фреймворка, и потратил на их решение уйму времени. Он думает, что ему удалось подобрать инструменты и методы работы, которые позволяют сделать тестирование компонентов React столь же простым, как и их создание.
Он начнёт рассказ с двух базовых принципов, понимание которых важно для нахождения правильного подхода к тестированию, далее будут даны примеры и представлен один полезный инструмент, способный значительно облегчить жизнь тем, кому приходится тестировать React-приложения.
Читать полностью »
На пороге уже стоит 2018 год. Но большинство бородатых уязвимостей продолжает жить в разрабатываемых системах. И не смотря на то что появился OWASP Top-10 2017. И приоритетность определенных вещей сильно поменялась. По прежнему ничего не мешает натыкаться на ситуации, которые были актуальны в 2010.
История началась с банального любопытства к продукту компании, в которой работает мой знакомый. Продукт интересный. Покупают данный продукт очень вдумчиво и за ценники с 6 знаками. Баг-баунти официальной у этой компании нет. Но я подумал, что даже если что-то найду — через знакомого разрулю и передам.
История последних дней. Есть у нас два SQL Server'а (2016 c SSD диском) и Express Edition (2012 с традиционным HDD). Аппаратно оба компьютеры примерно похожи (CPU/RAM/LAN). В целом 2016 «отдает» данные в 2-5 раз быстрее, за исключением некоторого набора таблиц, для которых 2012 работает быстрее в 1,5-2 раза. Такое поведение полностью противоречит какой бы то ни было логике. Любые манипуляции с настройками базы данных только ухудшают ситуацию. 2016 все более замедляется, но только для этого набора таблиц.
Для понимания парадоксальности ситуации — на обоих серверах развернута одна и та же база (с одного и того же файла backup'a). В этой базе порядка 600 таблиц. Те 5-6 которые ведут себя удивительно ничем не отличаются от десятков подобных (по структуре и количеству записей) с которыми такой проблемы нет. На обоих «серверах» — Windows 10 с последними обновлениями (это сервера разработок, а не продуктивные). На обоих SQL Server'ах последние сервис паки (без hot fix'ов). Никакие специальные «режимы» (trace flags и пр.) SQL Server'ов не включены.
Загадка сия была велика, но мой коллега ее решил. Вы даже знаете как…
Читать полностью »
Мы все понимаем, что такое автоматические тесты. Мы разрабатываем софт, и хотим, чтобы он решал какие-то проблемы пользователей. Написав тест, мы убеждаемся, что конкретная проблема решается конкретным участком кода. Потом требования изменяются, мы меняем тесты и меняем код соответствующим новым требованиям образом. Но это не всегда спасает. Кроме высокого тестового покрытия наш код должен быть спроектирован таким образом, чтобы защищать разработчика от ошибок ещё при его написании.
В статье я постарался описать одну из проблем, которую может решить хорошая архитектура: связанные участки кода могут разъезжаться между собой, это может приводить к багам, и тесты тут не спасут. А грамотный дизайн может помочь.
Читать полностью »
Логирование относится к сквозной функциональности — разбросанной по коду и, как правило, редко покрываемой юнит-тестами. Слабое покрытие тестами, очевидно, связано с тем что вывод в лог не всегда достаточно важен и воспринимается скорее как вспомогательная функция а не цель работы метода, к тому же тестировать сквозную функциональность бывает достаточно сложно.
Но когда корректность вывода в лог становится критичной или же чувство прекрасного требует от нас полного покрытия кода тестами — без тестирования логгеров становится не обойтись.
Читать полностью »
Статья публикуется от имени Сергея Масленникова, sergeymasle
Продолжаем цикл статей про нагрузочное тестирование на фреймворке gatling.io. В этой статье расскажем про основные приемы использования Gatling DSL, которые в большинстве случаев используются при разработке любых скриптов нагрузочного тестирования. Итак, прошу под кат.
Когда у молодого спеца что-то не получается, он занимается самокопанием и начинает думать, что у него не получится вообще ничего. Так как людям часто свойственно видеть корень зла в окружающем — обстоятельствах/начальниках/коллегах, — на поиски причин в себе времени уже не остается. Но, как мне кажется, оба подхода не до конца верные.Читать полностью »
ISTQB (International Software Testing Qualifications Board) это международно признанная программа сертификации специалистов по тестированию. Для получения сертификата ISTQB необходимо успешно сдать экзамен, организованный уполномоченным провайдером.
На сегодня существует три уровня сертификации: базовый (Foundation), продвинутый (Advanced) и экспертный (Expert), причем наличие соответствующего сертификата предшествующего уровня является одним из условий для прохождения сертификации последующего уровня. Продвинутый уровень разделен на несколько модулей, об одном из которых пойдет речь в данной статье — Test Manager.
Дабы не уходить далеко в оффтоп, подробнее со схемой доступных квалификаций можно ознакомиться на официальном сайте www.istqb.org.
Хотя существует достаточно много аккредитованных и сторонних обучающих центров подготовки к ISTQB, сдать экзамен самостоятельно — вполне реально, и цель данной статьи — поделиться своим опытом в этом предприятии. А также пара слов об актуальности этой сертификации в российских реалиях на примере нашей компании в конце.
Читать полностью »
