Home

Выступление Андрея Дзыни с конференции 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.

По традиции публикуем лучший доклад лучший доклад недавно прошедшей онлайн-конференции Auto ConfeT&QA.

Больше всех голосов было отдано за Михаила Поляруша с докладом “Sikuli, инструмент на все случаи жизни?”.

Михаил Поляруш практикующий консультант и тренер по автоматизации тестирования ПО http://poliarush.com. Основатель портала http://automated-testing.info и конференции по автоматизации http://atdays.com

Что нам надо делать когда нужно автоматизировать веб-приложения? Просто гуглим и находим нужную информацию. А когда нужно автоматизировать что-то необычное? Например, Windows приложение с самописными контролами и объектами. Сразу приходят в голову страшные слова как QTP или TestComplete. Но даже эти инструменты не всегда справляются с задачей расспознавания объектов. И что тогда? Не делать автоматизацию?!

Sikuli – это универсальный инструмент, который должен быть в арсенале каждого автоматизатора. В своем докладе я покажу, на практическом примере, как выполнить автоматизацию, даже если ее нельзя выполнить обычными инструментами (QTP, TestComplete, Selenium, и т.д.).

Работа с инструментом будет продемонстрирована в реальном времени в прямом эфире.

Уже меньше недели осталось до онлайн-конференции по автоматизации тестирования Auto ConfeT&QA и чтобы у тех, кто еще не решился участвовать было предоставление о том, что это такое, мы решили выложить один из докладов прошлой конференции.

Доклад Ольги Киселевой с рассказом про написание тестов на русском языке вызывал в твиттере и чате противоречивейшие эмоции, от «вау!» до «ересь!», но никого не оставил равнодушным и в итоге занял третье место по результатам зрительского голосования.

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

формочка

.Открыть
.НайтиОбъект
.ПерейтиНаОбъект
.ВвестиФигню
.ЕстьСообщениеОбОшибке
.Закрыть

Это возможно! На примере Visual Studio 2010 + Watin + NUnit + ReSharper и c использованием языка C# я покажу вам, что такие тесты… работают!