Home

Как обычно после очередной онлайн-конференции серии ConfeT&QA мы публикуем лучший доклад.

Сегодня мы опубликуем в открытом доступе доклад Игоря Хрола “Можно ли перевернуть пирамиду?” – автоматизируем тестирование с меньшим числом посредников”, который был признан лучшим на прошедшей онлайн-конференции для для специалистов по автоматизации тестирования Auto ConfeT&QA.

Когда мы говорим об автоматизации тестирования, чаще всего вспоминается Selenium, Microsoft Coded UI, QTP и другие аналогичные инструменты. Мы хотим воспроизводить действия ручного тестирования с максимальной точностью, чтобы можно было с уверенностью сказать, что тот или иной тест-скрипт повторяет какую-то часть сложившихся на проекте тестов. Когда же тестов становится чуть больше, то мы обнаруживаем, что наши тесты запускаются долго, работают нестабильно. После чего мы начинаем говорить о параллелизации, виртуализации, четырёхслойной архитектуре фреймворка и прочих жутко интересных вещах… Это всё очень хорошо, но главная цель где-то остаётся в стороне – контроль качества нашего продукта.

В своём докладе я попытаюсь слегка задать направление другой альтернативе: отойти от автотестов через пользовательский интерфейс в сторону более низкоуровневых, которые значительно быстрее и стабильнее. Если вас также волнует “переворачивание” пирамиды автоматизации тестирования, то приглашаю присоединиться к обсуждению этой сложной и важной темы.

Публикация от Андрея Дзыни, автора тренинга Автоматизация тестирования Android приложений

Не так давно вышел релиз новой версии Robotium 4.0, который стал знаменательным в истории этого инструмента. До недавнего времени, автоматизировать тестирование компонента WebView(отображающего Web страницу внутри Native Android приложения) было возможно лишь при помощи кликов по координатам.

solo.clickOnScreen(float x, float y)

Или же посредством подключения расширения ExtSolo от компании Bitbar.

После выхода Robotium 4.0 надобность в подобного-рода хаках отпадает. Появилась возможность работать с Web элементами напрямую через объект Solo, да и еще посредством использования класса By, для формирования локатора в стиле WebDriver API

Примеры доступных команд:

clickOnWebElement(By by)

enterTextInWebElement(By by, java.lang.String text)

getCurrentWebElements(By by)

getWebElement(By by, int index)

typeTextInWebElement(By by, java.lang.String text)

waitForWebElement(By by)

Полный список команд и их описания можно посмотреть в JavaDoc API

https://robotium.googlecode.com/files/robotium-solo-4.1-javadoc.jar

Выступление Андрея Дзыни с конференции UA Mobile

Мир мобильных телефонов очень сильно изменил нашу жизнь. В наше время невозможно представить современного человека, без этого чудо устройства. На рынке появляется все больше устройств и приложений. И чтобы удобнее пользоваться этими приложениями пользователи выбирают “умные” телефоны, или как их еще принято называть смартфоны. В этом докладе Андрей Дзыня, автор тренинга Автоматизация тестирования Android приложений хочет поделиться своим опытом автоматизации приложений под Android и iOS. Он расскажет о том, какие инструменты автоматизации он использовал. Поговорит о недостатках этих инструментов и какие из них стоит использовать у себя на проекте.

Автор: Киселева Ольга

Начнем с основ - что вообще такое робот и зачем он нужен?

Робот - это приложение, которое выполняет какую-то работу за нас. Но не всю - он делает маленький кусочек, а остальное проверяет тестировщик вручную. Такая полуавтоматизация.

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

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

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

Создаем карточку раз, создаем карточку два, создаем карточку три... создаем карточку одна тысяча сто восемьдесят шесть... И каждый раз заполняем одни и те же поля. И вот здесь нам и поможет наш робот - заполняем карточку один раз, пока пишем программу, а потом робот это делает за нас! Заманчиво, не правда ли? А ведь это еще и легко осуществимо!

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

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

Автор: Алексей Алексеев

Статья была написана для декабрьского номера журнала Tester's Life.

Автоматизированный тест – это скрипт или программа, которая имитирует взаимодействия пользователя с приложением для нахождения дефектов в приложении. Данное определение справедливо пожалуй только для GUI тестирования. К авто-тестам также можно отнести и модульное тестирование — процесс в программировании, позволяющий проверить на корректность отдельные модули исходного кода программы.

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

Автор: Сергей Высоцкий

Оригинальная публикация

Традиционный подход к автоматическим тестам выглядит примерно так - тестописатель изучает тестируемую систему и после этого руками пишет каждый отдельный сценарий для проверки искомой системы. Кто-то может написать тут гордое слово "handcrafted", а я называю это словом "handjob". А все потому, что обычно этот подход к созданию и написанию тестов страдает от двух проблем:

• "Парадокс пестицида", описанный Борисом Бейзером в 1990-м году. Заключается он в том, что тесты все менее и менее эффективны в отлове багов, так как баги, для обнаружения которых эти тесты написаны, уже найдены и починены. Если же этого не происходит, то возникают серьезные вопросы к написанному коду и к рабочим процессам
• Тесты статичны и их сложно менять, в то время как тестируемая система имеет свойство постоянно эволюционировать, обрастать новым функционалом и менять поведение старого. И тесты нужно менять каждый раз, когда функционал изменяет внешний вид программы или ее поведение. И с ростом сложности обновления тестов оправдывать чудовищные издержки на поддержку тестов становиться все сложнее.

Model-Based Testing данные проблемы практически полностью игнорирует, поскольку тесты создаются автоматически из точной модели приложения. Это сильно упрощает как поддержку уже существующих, так и генерацию новых, крайне полезных и гибких тестов.

Публикуем доклад Дмитрия Жария с прошедшей осенью очередной онлайн-конференции Auto ConfeT&QA.

Я уверен в том, что многие из нас, тестировщиков-автоматизаторов, прикладывают огромные усилия для того, чтобы результате тестового прогона создавался красивый, понятный и читабельный отчет. Чтобы был не просто голый call-stack c “NoSuchElementException”, а чтобы было ясно, что делал тесткейс и на каком шаге он упал, чтобы были картинки и видео, чтобы было просто приятно его читать и не стыдно другим показать.

+
Пусть наши коллеги из мира Java продолжают настраивать Jenkins и писать собственные парсеры для логов JUnit. А в мире .NET, есть замечательные бесплатные инструменты – MbUnit, Gallio Icarus, BDDfy – которые помогут сделать из Вашей автоматизации – кон-фЭтку!

Автор: Дмитрий Марков

В инструменте TestComplete уже давно (начиная с древних версий) есть модули, позиционируемые как ODT (Object-driven testing) и KDT (keyword-driven testing). Являются ли эти модули удобными для реализации этих подходов или это просто красивое название? Об этом и порассуждаю в этой заметке.

Все, что написано ниже — сугубо мое мнение, основанное на 5-летнем опыте автоматизации на TestComplete, начиная с версии 6.0 и заканчивая последней (на данный момент 9.10).

Пара слов о самом TestComplete

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

Также очень большой плюс инструмента — это поддержка таких технологий, как Flash, Flex, AJAX, Silverlight. Ну и другое (что, впрочем, есть и в других инструментах).

В отличие от того же (конкурента) QTP, TestComplete, например, дает возможность выбора скриптового языка: C++, C#, DelphiScript, VBS, JScript. Не все стоит использовать (об этом напишу отдельную заметку), но есть выбор — это само по себе уже плюс.

Также есть полнофункциональный 30-дневный триал в версии Enterprise, что очень удобно и хорошо.

Выступление Алексея Баранцева на онлайн-конференции Auto ConfeT&QA 2012.

Я расскажу, как запротоколировать выполнение тестов, разработанных с использованием инструмента Selenium, фреймворка TestNG и языка программирования Java.

Я не буду рассказывать о том, как сделать красивый отчёт о выполнении тестов.

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

Я не буду рассказывать о том, как сделать собственный фреймворк для протоколирования.

Вместо этого я покажу, как выжать максимум из того, что уже имеется в Selenium и TestNG. Разные библиотеки используют разные фреймворки протоколирования, я расскажу, как всё это перенаправить в единый фреймворк-фасад slf4j и при помощи фреймворка протоколирования logback сохранить всё в базу данных. При этом будут рассмотрены разные варианты запуска тестов – локально, удалённо, с использованием Selenium Grid, а также запуск тестов в облаках с использованием сервиса SauceLabs.

Автор: Геннадий Алпаев

За последние несколько лет было написано и переведено столько статей по тестированию и качеству, что практически никто уже не сомневается: тестирование – это систематический процесс, у которого есть подходы, критерии и законы. Так называемое «обезьянье тестирование» (monkey testing) если когда-то и существовало, то уже давно вымерло. Сегодня к тестировщикам предъявляются высокие требования, вплоть до умения программировать, и простое «кликанье» по приложению уже никому не нужно.

Однако так ли это на самом деле?

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

Все эти проблемы можно решить с помощью инструмента TestRecorder от компании SmartBear.