Какие бывают баги

1. Немного этимологии и энтомологии
Давайте посмотрим попристальней на такое знакомое и (до боли?) родное слово БАГ. Происходит оно от английского слова Bug, означающего «насекомое». Есть еще много сторонних значений, в частности английское выражение «to go bugs» — сойти с ума, что легко кореллируется со вполне русским «тараканы в голове завелись». Также вспоминаются и «жучки на линии» (тоже, кстати, по-английски – bugs). И опять мы пришли к насекомым.

Для любого программного приложения, предназначенного для массового обслуживания пользователей, необходимо проводить нагрузочное тестирование на предмет его надежности и отказоустойчивости. А так как любой web-сайт — это по своей сути система массового обслуживания, то проверка его на отказоустойчивость всегда является неотъемлемой частью разработки. Существуют различные решения для проведения нагрузочного тестирования веб-приложений. Я не буду сейчас описывать их подробно, про некоторые из них есть упоминания здесь.

В этой статье я хочу поделиться своим опытом использования такого средства, как Apache JMeter. После того как мною были перепробовано с десяток различных подобных инструментом, в итоге я остановился именно на JMeter, так как его возможности с лихвой охватывали мои цели и задачи. И при этом данное программное средство весьма быстрое и легковесное.

Для тех кто ни разу не использовал JMeter, рекомендую для начала почитать базовые обзоры, например, Простой нагрузочный тест с Apache JMeter. Когда я первый раз запустил данную программу, первая мысль была разобраться во всем методом «тыка», но как выяснилось это вообще нереально, и метод «тыка» неприменим к JMeter. Поэтому если хотите его использовать, то сразу открывайте мануал, поверьте, вам придется заглядывать туда очень часто, пока полностью не разберетесь, что и как. Я же здесь сейчас опишу самое очевидное и важное, а именно: как собственно создавать нагрузочные тесты. Если бы я в свое время сразу нашел подобную статью, то сэкономил бы без малого день на изучении этой софтины.

Если присмотреться к различным ИТ-профессиям, складывается ощущение, что «движухи» у тестировщиков больше, чем в любом другом направлении. Оно и понятно: отрасль молодая, незрелая, и уровень квалификации по сравнению с западным отстаёт.

При этом может показаться, что обучение — это сложно или дорого. Как бы не так! У тестировщиков есть масса возможностей учиться либо совсем недорого, либо вообще бесплатно! Сегодня я хочу поделиться новостями в мире обучения тестировщиков: надеюсь, каждый заинтересованный найдёт для себя что-то подходящее.

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

Можно стараться запускать полный прогон перед каждым коммитом. Но затраты времени на кино в виде пробегающих по экрану фич cucumberа, а также выход из потока снизят эффективность разработчиков в разы.

В одном из наших проектов, в который согласно записям redmine вложено около 400 часов работы нашего коллектива ситуация с тестами до распараллеливания выглядела так (пару дней назад):
151 scenarios (151 passed)
3997 steps (3997 passed)
17m49.257s


18 минут!!!

За это время разработчик может сварить кофе, выкурить сигарету, сходит в туалет, ущипнуть за попу симпатичную коллегу и успеть посмотреть последние 3 минуты «матрицы» на экране. Если требовать от него чтобы полный прогон запускался перед каждым коммитом, то он только и будет делать что смотреть «матрицу» и щипать попы пить кофе.

Но анализ загрузки процессора при прогоне показывает, что в работе участвует только лишь одно ядро независимо от того, сколько их всего есть. Как говорит пословица, лучше день потерять, а потом за пять минут долететь. Порыскав в гугле мы нашли гем parallel_tests. Теперь мы не с такой завистью будем смотреть на erlang группу, которые могут спокойно распараллелить свои тесты на кластер арендованных облачных машин в Selectel.

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

Появляется все больше и больше полезных приложений, библиотек и плагинов, которые частично облегчают головную боль, возникающую в ходе попыток сделать тесты полезными для всей команды. Примерами прекрасных инструментов, которые есть в нашем распоряжении, могут быть Hudson для непрерывной интеграции, Cucumber для интеграционных тестов и Selenium для автоматизированного тестирования веб-приложений в реальном браузере. Но организация совместной работы всего этого требует все больше и больше настроек и конфигураций на сборочном сервере.

Наша цель — задокументировать шаги, требуемые для преодоления встречающихся препятствий на пути к запуску полного набора тестов Cucumber со сценариями на Selenium на сборочном сервере Hudson.

Продолжение к посту модель Миллса.

Парная оценка

Данная модель требует тестирование программы двумя специалистами (или группами специалистов). Зато не требует внесение в программу искусственных ошибок. Итак, пусть программу тестируют независимо друг от друга две группы специалистов. Предположим, что в программе содержится N ошибок. Пусть первая группа нашла N₁ ошибок, а вторая — N₂. Часть ошибок обнаружена обеими группами. Пусть таких ошибок N₁₂.

Upd: добавлены скиншоты.

19-20 мая в Минске проходил Software Engineering Forum 2011. Мы выступили с докладом «Новый уровень автоматизации тестирования», или альтернативный длинный вариант – «Доавтоматизация» автоматизированного тестирования через интеграцию тестового инструментария». В нем мы раскрыли три основных вопроса:

1. Уровни автоматизации тестирования в организации.
2. Основные моменты, на которые стоит обратить внимание при автоматизации тестирования (на основе собственного опыта и опыта коллег, а также результатов опросов).
3. Прототип решения для управления автоматизированным тестированием (на базе внутренней разработки Octopus).

Под катом – содержание доклада, ссылка на промо-версию Octopus. Длинный пост.

Зачем нужны тестеры набранные из пользователей

Бывает что силами внутреннего отдела тестирования нельзя проверить некоторые вещи, так как они требуют например массовости или захода одновременно с нескольких IP-адресов, что сложно воспроизводимо в условиях офиса. Тогда на помощь отделу тестирования приходят пользователи, которые готовы безвозмездно, ради улучшения качества проекта, помочь администрации.

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

Я провел настоящее исследование ситуации с автоматизированным тестированием интерфейса мобильных приложений. Речь идет не о тестировании модулей, а именно о тестировании интерфейса финального приложения. И, да, прямо на телефоне!

Зачем это нужно? В первую очередь, для гарантированного улучшения качества вашего ПО и улучшении настроения тестировщиков.

В чем идея? Чаще всего тестирование мобильных приложений осуществляется людьми: тестировщик берет приложение, iPhone 3, iPhone 4, iPad, если ему не повезло, то еще берет пару андроидов и GalaxyTab, и тестирует ваше приложение, 80% тестирования составляют примерно такие сценарии:
— запустить приложение, убедиться, что оно не падает;
— перейти на вкладку места, убедиться, что все пункты на месте;
— зайти в один из пунктов, убедиться, что описание на месте;
…

Такие тесты проводятся после каждого релиза и занимают очень много времени.

В свое время в вебе на помощь пришел Selenium, который позволил через специальный плагин к браузеру записывать действия тестировщика (все помнят макросы в MS Word?) и затем проигрывать их автоматически с проверкой результата. Можно запускать тесты даже на разных браузерах! Мы использовали это решение в своей компании, и оно, действительно, работает. Усилия на разработку тестов окупились.

По сравнению с вебом мобильная разработка еще очень молодая область, и я не ожидал увидеть хороших решений для автоматизированного тестирования интерфейсов. Оказалось, что их более чем достаточно. Хочу рассказать вам о некоторых из них.

Сколько ошибок в программе? Это вопрос, который волнует каждого программиста. Особую актуальность придает ему принцип кучкования ошибок, согласно которому нахождение в некотором модуле ошибки увеличивает вероятность того, что в этом модуле есть и другие ошибки. Точного ответа на вопрос о количестве ошибок в программе очень часто дать невозможно, а вот построить некоторую оценку — можно. Для этого существуют несколько статических моделей. Рассмотрим одну из них: Модель Миллса.

Немного истории

Slash

Возникновение слеша относят к временам Римской империи. На ранних стадиях современности, во Фрактуре [1], которая была широко распространена по всей Европе в средневековье, слеш (/) использовался вместо запятой, в то время как двойной слеш (//) использовался вместо тире. Двойной слеш, в конечном счете, превратился в символ похожий на знак равенства (=), а позже был еще больше упрощен до тире или дефиса [2].

Здравствуйте, уважаемые хабровчане!
Мы с коллегой готовим для конференции доклад на тему автоматизации тестирования desktop-приложений. Ценность и полезность доклада возрастет, если мы сможем использовать в выступлении результаты опроса профессионального сообщества.
Результатами поделюсь на Хабре.

«Сначала ваши попытки должны были потерпеть крах, чтобы вы были готовы ухватиться за спасательный круг, который вам бросят.»
Е. Херригель
«Дзен и искусство стрельбы из лука»

Ты ручной тестировщик?
На автоматизацию тестирования нет времени?
То, что нужно тестировать, невозможно автоматизировать?
Ты уже достиг вершин, но хочешь посмотреть чей-то чужой путь?

Тогда прошу под кат!

Дорогой_хабрахабр_прости_пожалуйста_но_какой_тестировщик_не_проверит_эту_ может_и_бесполезную_штуку_в_блоге_по_тестированию?



Для придания посту минимальной информационной ценности, добавлю:
тестирование «неправильного» поведения пользователя называется негативным тестированием.

В апреле этого года в Казани пройдёт 9-я конференция SQA Days. На ней, как и всегда, соберутся ведущие умы, гуру и эксперты в области тестирования. Её участниками, как и всегда, будут наиболее активные представители сферы контроля качества. На ней, как и всегда, каждый получит желаемое: тонны информации, века консолидированного опыта, террабайты мотивашечек.

Все вышеперечисленные фенечки и плюшечки ни капельки не удивят того, кто хоть раз посещал грамотные конференции. Однако, при этом, в SQA Days есть множество воистину удивительных вещей: стабильность, темпы развития, широкая география проведения… и люди!

Сказки про ссоры разработчиков и тестировщиков когда-то были правдой, но сейчас таких конфликтов почти не встретишь. Спокойная совместная работа над выпуском ПО, ориентация на общие цели, бла-бла-бла…

Но если присмотреться внимательнее, то под видимостью продуктивного сотрудничества зачастую скрывается абсолютное непонимание разработчиков: «зачем эти тестеры вообще нужны??». Это непонимание нередко является взаимным, и несмотря на кажущуюся миролюбивость, оставляет в совместной работе лишь видимость продуктивности.

В качестве предисловия скажу, что я пришла в Иннову чуть больше года назад, моей задачей было «сделать тестирование в компании». Мой отдел тестирования состоит из двух групп: группа тестирования веб-приложений и группа тестирования игровых приложений. Такое разделение сложилось потому, что у этих направлений разные задачи и разные требования к сотрудникам.

Дальше рассказ будет про направление игрового тестирования. Это рассказ про моих ребят, про наши процессы, про нашу организацию работы. Приглашаю на словесную экскурсию.

Стоит ли вообще браться за JMeter

Если с JMeter-ом вы не знакомы, то, например, по-быстренькому с ним у вас точно не выйдет.
Если вы все же решили взяться и выделить пару дней, то могу предложить свой рецепт по приготовлению нагрузочного теста на JMeter.

Составление сценария

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

Много слов сказано о достоинствах юнит-тестов (TDD, BDD — в данном случае неважно), а также о том, почему люди всё-таки их не используют.

Но я думаю, что одна из главных причин заключается в том, что люди не знают, с чего начать. Вот прочитал я статью про юнит-тесты, понравилось; решил, что надо бы когда-нибудь попробовать. Но что дальше? С чего начать? Как придумывать все эти требования, как называть тест-методы?

В последнее время набирает популярность тенденция превращать юнит-тесты в BDD-спецификации, то есть говорится о том, что хороший юнит-тест должен не тестировать что-то, а описывать поведение программы. Но как описать это чёртово поведение; откуда брать вдохновение, чтобы придумать названия для всех этих тест-кейсов?

Об этом и пойдёт речь:

Я работаю в автоматизации тестирования уже более пяти лет. Более всего я работал с ОС Windows. Мы пишем скрипты на Borland SilkTest. Я знаком и с другими средами разработки автоматизированных тестов, такими как QTP и TestComplete – у каждого продукта есть свои достоинства, но, к сожалению, и свои недостатки. Возникают проблемы, которые очень сложно решить «не выходя из системы»*