Тестирование IT-систем *

Хочу поделиться опытом по организации процесса тестирования, который охватывает 3 года моей работы и создание нескольких крупных систем. Описание будет затрагивать только автоматизацию «ручного» тестирования без пересечения с другими аспектами разработки ПО.

Я думаю стоит сразу упомянуть, что на всех этапах мы использовали:

• Модульные тесты с покрытием около 50%
• Continuous Integration с запуском модульных тестов (в последствии и интеграционных), автоматической сборкой и выпуском релиза
• Пересечение из гибких методологий под общим названием ScrumbanXP

Везде, где я буду говорить про автоматизацию тестирования, речь будет идти про тестирование интерфейса с подключением к внешним ресурсам (БД, файловая система, сервисы и т.п.).

Компания Google проводила тесты SPDY, которые показали увеличение скорости загрузки веб-страниц в два раза, а в мобильных сетях — на 23%. Однако, некоторые независимые эксперты выражают сомнения в эффективности протокола. Недавно критический обзор SPDY опубликовали разработчики из компании Opera Software. А сейчас продукту Google нанесён удар под дых — Гай Поджарны (Guy Podjarny), специалист по тестированию производительности, автор сервиса Mobitest один из ведущих разработчиков Akamai выложил свои результаты тестов. Они выглядят удручающе для SPDY. Оказалось, что в большинстве случаев SPDY+HTTPS работает совсем чуть-чуть быстрее HTTPS, но, в среднем, на 3,4% медленнее простого HTTP.

«Вы тестируете? — Возможно.
Все мы согласны, что тестирование – отличная штука, но в реальности доставляет много проблем. В настоящий момент мы занимаемся beta-тестированием партнерского CI сервиса, который предназначен для того, чтобы делать за вас всю тяжелую работу.
Мы работаем над созданием удивительного сервиса CI! Только представьте, что вы сможете использовать исключения для автоматизированного создания тестов! Да, мы работаем над этим!
Ответьте на это сообщение для получения доступа к beta-версии.»

— примерно такие слова в моем вольном переводе с английского я прочитал, зайдя однажды на всем известный airbrakeapp.com, чтобы посмотреть, какие ошибки успели найти юзеры в наших приложениях за ночь.

Здравствуй «ХабраСообщество»!
Выкладываю небольшой обзор и результаты тестирования основных алгоритмов сжатия с Java.
Кому интересно прошу под кат, кому нет — просьба не минусовать и сказать, что тема не достойна хабра – уберу в черновики.

Как и обещали в топике-анонсе нашей игры, выкладываем отчёт о хабраэффекте и детали игрового движка.

Недавно начала вести курсы по основам тестирования, и так получилось, что группа собралась из одних программистов. И каково же было мое удивление, когда люди, задействованные в разработке программного обеспечения, ничего не знают о тестировании. Умные ребята, продвинутые программисты, хорошо разбирающиеся в своей предметной области, ничего не знают о том, как тестировать ими же написанное программное обеспечение.
Несмотря на то, что тестрование существует уже давно, это еще молодое развивающееся направление, про которое зачастую мало что знают, за пределами отдела тестирования. И тогда я задумалась, почему люди идут работать тестировщиками, или наоборот не идут. Движут ли ими какие-то предубеждения и мифы. Как-то на глаза попалась статья Майка Брауна (Mike Brown) про 5 мифов в тестировании, переводом которой хочу с вами поделиться:

Канадский разработчик Стив Ханов (Steve Hanov) рассказывает о простом способе повысить эффективность A/B-тестирования.

Суть заключается в использовании жадного алгоритма (epsilon-greedy method) для решения задачи о многоруком бандите. Другими словами, при выборе между вариантами A/B-тестирования Стив предлагает отказаться от полного рандома, а в 90% случаев выбирать лучший вариант по результатам накопленной к настоящему моменту статистики.

Метод прост до гениальности.

Друзья!

Вчера завершился первый день трансляции с крупнейшей конференции по разработке и тестированию ПО — DevCon'12. Множество интересных докладов, вопросы участников, интервью со спикерами — всё это можно было наблюдать онлайн.



Подключайтесь к трансляции второго дня! Ещё больше докладов и интервью.

Друзья!

Приглашаю вас на прямую трансляцию с крупнейшей конференция Microsoft по разработке и тестированию ПО DevCon’12, которая начнется 23 мая в 10:00. Сегодня вы сможете увидеть более 20 докладов в 5 параллельных треках, а также прямые включения и интервью с докладчиками во время перерывов. Полгода мы готовились к этой конференции, и, наконец, она начинается!

Пока компании вроде Google и Microsoft активно рассказывают простому пользователю о счастье, которое ожидает их на облачных сервисах, я хочу поделиться другой стороной облаков — счастьем для разработчиков и тестировщиков ПО. За те несколько лет, в течение которых я руковожу группой тестирования Parallels Plesk Panel, была собрана неплохая коллекция лайфхаков по использованию облака для наших целей.

Я уверен в том, что изложенный опыт будет полезен подавляющему большинству компаний и стартапов. Во-первых, тестовое облако можно создать самостоятельно. Это важно, когда ваш бюджет ограничен. Во-вторых, тестовое облако в его самом начальном варианте можно развернуть на 2-3 серверах. В-третьих, все хлопоты, связанные с созданием тестового облака, с лихвой окупаются автоматизацией процесса тестирования. Это особенно критично, если вы регулярно выпускаете обновления и если код вашего проекта довольно объемный.

С преамбулой вроде всё. Любопытных приглашаю под кат.

 

Продолжаем познавать тайны тестирования видеокодеков. На этот раз поговорим про энкодеры.
Ссылка на первую часть.

Когда разработчики впервые открывают для себя прелести разработки через тестирование — это как переход в новый, лучший мир, где гораздо меньше стресса и незащищенности. Этот прекрасный опыт действительно стоит отпраздновать. Но осознание преимуществ тестирования — только первый шаг к просветлению. Самое сложное — понять что НЕ нужно тестировать.

Если новичку можно и не заботиться о том что не стоит тестировать в первый день, то на второй день ему бы лучше начать вникать в это. Люди — создания привычки, поэтому если вы начнете формировать плохую привычку избыточного тестирования с самого начала, то вам будет гораздо труднее избавиться от нее потом. А избавиться от этой привычки вы должны.

Вот какие книги советует google books при поиски книг Rex Black ;)



p.s. Конечно аналогии есть, в некотором смысле он прав…

Если вы пишете на javascript и покрываете код юнит-тестами, то, вполне вероятно, вам будет интересно насколько хорошо он покрыт. А если в проекте используется Maven, то хочется получать эту информацию при каждой сборке.

Итак, Saga — анализатор покрытия кода со вкусностями:

• работает с большинством тест-фреймворков
• консольная версия
• maven-плагин версия (на официальном централе)
• красивые и удобные отчёты

Компания Google раскрыла некоторые подробности, как осуществляется тестирование браузера Chrome на уязвимости. Для этого они применяют метод фаззинга (fuzz testing), то есть используют методику тестирования, при которой на вход программы подаются невалидные, непредусмотренные или случайные данные.

Идея заключается в том, чтобы протестировать максимально возможное количество вариантов. Естественно, для этого нужны серьёзные ресурсы. Для тестирования Chrome создан целый кластер серверов ClusterFuzz, состоящий из нескольких сотен виртуальных машин.

Добрый день, уважаемые хаброжители!



Расскажу вам о своём проекте, который делаю в свободное время уже три года.

Работаю в компании занимающейся автоматизацией на должности программиста контроллеров. Последнее время, в основном, используем Siemens, ПЛК SIMATIC S7 и пакет визуализации WinCC, но есть опыт и по другим производителям. Профиль компании – нефтегазовый сектор (резервуарные парки, насосные, железнодорожные эстакады, причальные комплексы, системы пожаротушения).

Наверное, с самого первого проекта, меня интересовал вопрос тестирования программного обеспечения до этапа пуско-наладки на реальном оборудовании. Не так давно, на хабре был пост — Программирование ПЛК Siemens на Simatic Step7, и адреналин, про который говорилось в комментариях, знаком мне не понаслышке.

В настоящий момент, используя мою программную платформу, мы можем избавиться от большей части ошибок и отладить автоматизированные функции в комфортных условиях офиса (а не сидя на катушке кабеля, в неотапливаемом помещении, в морозный зимний день).

Вы помните Историю о развитии форматов видеосжатия (вот эту)?
А со сколькими из описанных там кодеков вы знакомы лично? А какие пробовали писать сами? Какие алгоритмы сжатия наиболее эффективны?
Эти и другие вопосы НЕ будут освещаться в этой статье.

Кёртис Спенсер (Curtis Spencer) с коллегами из компании Spool разработали легковесный сервер Fake S3, который ведёт себя как настоящий Amazon S3 и помогает тестировать проекты, не гоняя данные в облако и не тратя деньги на трафик. К тому же, для тестирования Fake S3 надёжнее, потому что работает локально. Спенсер говорит, что благодаря Fake S3 они сэкономили около $1000 за последний месяц на одной только оплате трафика.

Установка

gem install fakes3

Для запуска сервера нужно указать хост и порт

fakes3 -r /mnt/fakes3_root -p 4567

SoapUI — нужен help

Примерно с полгода назад поручили мне провести тестирование (заодно и автоматизировать его) проекта, активно использующему сервисы, отвечающие по SOAP-протоколу. Показали такую классную программу как SoapUI. То какая замечательная эта программа, какой у нее интутивно понятный интерфейс и интуитивно понятный онлайн-хэлп (soapui.org), мы оставим за рамками статьи.

К сожалению, при всех своих достоинствах она довольна узко специализирована и наверное, поэтому, сейчас наблюдается полное отсутствие материалов о ней на русском. Интуитивно-понятный хэлп на английском не может помочь с какими-либо достаточно сложными задачами (хотя чтобы начать, он незаменим), да и на всех просторах интернета довольно сложно найти step-by-step мануал.