Что такое?

Выполнение действий над элементами графического интерфейса в случайном порядке.

Для чего нужно?

Человек, выполняющий тестирование, это Homo sapiens, т.е. он обладает неким интеллектом. Этот самый интеллект, мешает (очень редко, но мешает) ему находить «нелепости поведения» приложения связанные с непредвиденными ситуациями. Он просто не может представить себе настолько нелогичную ситуацию.
Пользователь же, намного превосходит QA в количестве и может значительно уступать ему в IQ. Отсюда, вероятность непредвиденного поведения пользователя отнюдь не крайне мала.
Итак, что нам, обладая свободными ресурсами и желанием, мешает принять меры по предотвращению подобных ситуаций? — Ничего.
Теперь сформулируем конкретные задачи, в которых «бессмысленное клацанье» по кнопкам может быть полезно:

• Дополнить существующее тестирование стабильности приложения путем введения модели нелинейного поведения пользователя в GUI.
• Исследовать потребление ресурсов при всех возможных вариантах работы приложения (инициированные из GUI).

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

Как делать будем?

Дальнейшее описание предназначено для тестирования приложений на платформе Windows.
Предлагаю воспользоваться связкой python + pywinauto. Хотя pywinauto и имеет некоторые ограничения в плане доступа к элементам окна, для большинства случаев этого должно быть достаточно.
Честно говоря, альтернативы я не вижу. Все знакомые мне средства автоматизации тестирования GUI не обладают динамичностью, показанной ниже – уже во время выполнения теста получать список контролов, определять их тип и выполнять допустимое действие.
Также не стоит недооценивать возможностей самого Питона и его модулей. Тут вам можно и видео снять, CPU замерить и сообщение, куда надо, в случае чего отправить…

Иногда очень хочется что-то протестировать «по-быстрому». Чаще всего это плохо работает, если только вы не знаете точно, что делаете и зачем.

1.

Вы руководите разработкой продукта в небольшой компании. Процесс разработки построен на базе двухнедельных итераций, периодически проводятся демо готовых вкусняшек для заказчика. Разработчики у вас достаточно сильные и опытные, продукт не выглядел чересчур сложным, так что тестировщиков на проекте изначально не было, и сейчас тоже нет.
За уже прошедшие со старта полгода вы неплохо поработали, заказчик в целом доволен ходом работ, хотя, конечно, падения и неадекватное поведение продукта во время демонстраций его смущают. Последняя демонстрация особенно удалась – из-за возникших технических проблем показать новые фичи не получилось. Заказчик потребовал больше внимания уделять стабильности и качеству продукта.
По планам до завершения проекта осталось три с половиной итерации, время разработчиков уже распланировано, и вы решаете нанять тестировщиков – чтоб они быстренько все протестировали, выгребли хотя бы основные проблемы и помогли тем самым выпустить достаточно хороший продукт.
Эй, это не сработает!

Каждый обеспокоен своей безопасностью. Можно попросить проектно-монтажную организацию сделать проект, а потом по нему монтаж. Но это неинтересно и втыкается в бюджет. Так что рассмотрим сигнализацию своими руками. Рассматривать будет охранно-пожарную сигнализацию (ОПС) и систему контроля управления доступом (СКУД) в квартире и доме (коттедже)

В этой статье будет рассмотрена возможность использования аннотации @FindBy для поиска элементов на странице, а так же создание своих классов для работы с элементами и контейнерами вроде форм, таблиц и т.д.

Продолжение статьи «Тестерские конференции Европы или повод пошопиться?»

Уже писали ранее о том многообразии городов захваченных тестерами в пределах нашей бывшей родины (ныне СНГ), которые появляются пачками после очередной SQA Days. А теперь я решил заглянуть дальше, за границы СНГ и спросить, а есть ли жизнь на Марсе? И решил значит поискать в интернете, а какие вообще «качественному» человеку качественные конференции стоит предложить?

Я использую C для научных расчётов. А в этом случае, стоит крепко подумать, а надо ли вам вообще C?

Язык C нужен только в случае, если в ваших расчётах очень критична производительность или критичен доступ к железу. Во всех остальных случаях, я очень рекомендую высокоуровневые языки типа Ruby или Python (почти что стандарт языка для научных расчётов, очень много научных пакетов разного толка от математики до биологии) или, что лучше, сразу научные пакеты типа Sage (надстройка над python с возможностью использования символьных вычислений и очень много чего ещё, а также с возможностью подключения других математических пакетов, в случае, если возможностей Sage не хватает, прямо внутри Sage программы; о Sage, кстати, писали на хабре).

Для Python же, если производительность важна и вы не готовы вылизывать C-код до совершенства, есть Cython (авторы которого являются также авторами Sage), который компилирует почти питоновский код в C-код, достигая очень высоких показателей производительности.

Так что на этом этапе призываю вас ещё раз: подумайте, прежде чем использовать C для научных или иных расчётов! Иначе, поехали!

Итак, вы всё-таки решили использовать C. В этом случае надо организовать рабочую тестовую среду, а именно:

• Модульное (unit) тестирование
• Автоматический запуск тестов, при изменении кода

 

Tsung — это распределенная система нагрузочного тестирования, написанная на Erlang'е. Заявлена поддержка HTTP, WebDAV, SOAP, PostgreSQL, MySQL, LDAP and XMPP/Jabber. В этой статье я опишу как протестировать обычный web сайт на нагрузку.

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

Далее о том, как все это дело автоматизировать.

Все, кто использует Selenium тесты в своём билде, знают, что это достаточно дорогое удовольствие, потому что очень медленно. Из-за этого многие не запускают билд полностью перед коммитами или, вообще, запускают билд только по ночам. Итак, делаем наши тесты быстрее.

TDD на примере UrlBuilder

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

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

Координационный центр операции располагается на форуме разработчиков.

Что требует внимания тестеров:

I Работа на реальном железе

• сетевые карты
• USB мыши и клавиатуры
• управление питанием — включение выключение через «пуск» и по аппаратной кнопке.

II Неподтвержденные баги

В багтрекере проекта накопилось серьёзное количество неподтверждённых или имеющих некорректное описание багов. Необходимо провести тестирование свежих билдов и по результатам подтвердить или опровергнуть соответствующие баги.

Подробности и список багов. На данный момент их осталось менее пятидесяти.

В этом посте я опишу свои исследования, которые мне пришлось проделать, когда на проекте стал вопрос об автоматизации тестирования. Проект представляет собой веб-сайт, клиентская часть которого написана на Flex, а серверная — на Python(Django).

Выбор средств для автоматизации

Для начала рассмотрим путь от начала, который я прошел, прежде чем остановился на связке Java + Selenium + FlexMonkium. А это:

• Selenium + Sfapi
• Ranorex
• FlexMonkey
• Selenium + FlexMonkium

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

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

Если верить русской википедии, то сегодня день тестировщика.

Иногда нужно протестировать работу клиентского приложения в сетевых условиях, приближенных к боевым. Что при разработке, что при выборе софта. Как правило, сервер рядом, а нужно оттестировать и на таком канале, и на таком. Как ни странно, удобного средства управления трафиком (traffic shaping) под Windows мне долго не удавалось найти. Из поисков запомнилось: кто-то советовал для тестовых целей купить модем. Можно поставить роутером машину на Linux и на ней рулить трафиком, но мне такой подход кажется слегка чрезмерным.
Оказывается, не меньше года в проекте Dummynet есть бинарники для Windows, которые позволяют легко и непринужденно управлять, как минимум, полосой канала (bandwidth) и задержкой (latency).

Недавно один из заказчиков TestLab² пожелал узнать, как будет работать его инсталлятор (с закачкой всякого на лету) на разных каналах. Внезапно первые подходы показали, что нам везет и обычные edge, umts и wimax-каналы (не говоря о проводных) в нашей округе как-то уж очень хорошо работают.
Чтобы создать тяжелые условия мы нашли и применили специализированный инструмент WANem, о котором я расскажу под катом.

Часто мне приходилось слышать, что кто-то послушал лекцию или прочитал статью про юнит-тесты, вроде как всё понял; решил сам попробовать — и ничего не получилось.

Почему так получается?

По-видимому, причина в том, что юнит-тесты обычно демонстрируют на простых примерах. А в жизни код сложнее. В реальных проектах код использует базы данных, веб-сервисы, код, написанный другими компандами и т.д.

В этом видео на живом примере показано, как писать юнит-тесты для кода с внешними зависимостями.

www.devclub.eu/2011/06/06/asolntsev-real-life-unit-tests

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

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