Mock на английском значит «имитация», «подделка». Модуль с таким названием помогает сильно упростить тесты модулей на Питоне.

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

Такое поведение — уже не надувные ракетные установки, а целая надувная земля, вокруг которой могут летать испытуемые ракеты и самолёты.

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

Добрый день дамы и господа!

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

Идея родилась в моей голове от нашей бедности наших потребностей. Для тех, кто решил освоить какой-нибудь САПР, казалось бы, выбор должен быть всегда очевиден — это должен быть тот же САПР, что используется на предприятии, где работаешь, или же хочешь работать. Причины, по которой трудно сделать выбор могут быть разными, к примеру – у всех ленивых возникнет вопрос: «А что освоить легче?» или «Пойдет ли он на моем компьютере, если я хочу сделать нечто и в определённом количестве?». На выбор может так же повлиять наличие в программе нужных функций и, как это не странно прозвучит, цена. На эти и возможно некоторые другие вопросы ответы под катом.
ФОТО!!!

Когда 3 февраля Джеймс Виттакер написал в Твиттере, что он уходит из Google, у всех возник миллион вопросов. Потом он написал пост о том, почему он так поступил (оригинал и перевод). И вот теперь Джеймс объясняет, почему выбрал именно Microsoft.

Похоже, что намеки на то, что переходы из Google в Microsoft не так уж редки, не послужили достаточным объяснением, поэтому вот вам более развесистый отчет. Для тех, кому неинтересны подробности в деталях, приведу короткую версию. Я думаю, что происходящее в мобильном и веб-ориентированном мире — неправильно, и со временем становится все более неправильным. Пользователи в опасности: они теряют контроль над персональными данными и над своей сетевой индивидуальностью. Независимые разработчики вынуждены стучаться в закрытые двери в попытках двигать веб вперед. Решение этих проблем потребует больших запасов интеллектуальной собственности, технических и информационных возможностей и дружелюбного отношения к производителям ПО. Мне кажется, что Microsoft — одна из лучших компаний, способных возглавить такое направление.

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

Большие компании — это не круто, так почему вы ушли из одной в другую?

Наконец-то мы завершили и опубликовали перевод на русский язык документации по инструменту Selenium, пожалуй, наиболее популярному в последнее время инструменту автоматизации тестов для веб-приложений.

Русская версия в определенном смысле даже лучше, чем оригинальная, потому что в нее включены дополнительные главы, скомпилированные из статей в Selenium Wiki, которые заполняют «белые пятна», имеющиеся в официальном руководстве пользователя.

Мы надеемся, что теперь, благодаря преодолению языкового барьера, число поклонников Selenium будет расти ещё быстрее, и мы будем рады видеть Вас в наших рядах!

(Под катом — благодарности спонсорам и участникам проекта по переводу)

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

Введение

Как-то я начал осваивать новый инструмент — JМeter — и не смог найти какого-то полноценного руководства как руководства к действию. Постепенно, разобравшись по некоторым довольно полезным статьям и блогам, пользовательской документации, я начал что-то понимать. И решил, что, возможно, я не один ищу то, с чего можно начать работать. Освоить некоторые принципы построения и логику самого инструмента. Так что вот — статья о том, как начать.
Так что в этой статье мы рассмотрим пример создания скрипта для 3 пользователей, которые хотят:
1. залогиниться;
2. добавить в какой-нибудь альбом новую фотографию;
3. поменять аватарку.
Как таковой — это обычный бизнес процесс для какой-нибудь социальной сети.

Что такое?

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

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

Человек, выполняющий тестирование, это 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 Неподтвержденные баги

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

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