Динамическое (нелинейное) тестирование GUI
Что такое?
Выполнение действий над элементами графического интерфейса в случайном порядке.
Для чего нужно?
Человек, выполняющий тестирование, это Homo sapiens, т.е. он обладает неким интеллектом. Этот самый интеллект, мешает (очень редко, но мешает) ему находить «нелепости поведения» приложения связанные с непредвиденными ситуациями. Он просто не может представить себе настолько нелогичную ситуацию.
Пользователь же, намного превосходит QA в количестве и может значительно уступать ему в IQ. Отсюда, вероятность непредвиденного поведения пользователя отнюдь не крайне мала.
Итак, что нам, обладая свободными ресурсами и желанием, мешает принять меры по предотвращению подобных ситуаций? — Ничего.
Теперь сформулируем конкретные задачи, в которых «бессмысленное клацанье» по кнопкам может быть полезно:
- Дополнить существующее тестирование стабильности приложения путем введения модели нелинейного поведения пользователя в GUI.
- Исследовать потребление ресурсов при всех возможных вариантах работы приложения (инициированные из GUI).
Во-первых, вариант тестирования, описанный в данной статье, должен быть использован, действительно, только как дополнение к существующему тестированию графического интерфейса. Полагаться лишь на хаотичное «клацанье» по кнопкам – по меньшей мере, глупо. Нет никакой проверки, что именно происходит да и происходит ли вообще. Поэтому первый вариант можно рассматривать как дополнительное негативное тестирование на стабильность.
Второй же, максимально эффективен на бесконечном отрезке времени, что часто, невозможно. Поэтому, выбирая период измерений, следует исходить из сложности приложения, его типа и назначения. Например, наверно нет смысла 24 часа гонять «несерверное» приложение, состоящее из двух кнопок и одного чекбокса, которое умножает что-то на два, а потом результат делит пополам.
Как делать будем?
Дальнейшее описание предназначено для тестирования приложений на платформе Windows.
Предлагаю воспользоваться связкой python + pywinauto. Хотя pywinauto и имеет некоторые ограничения в плане доступа к элементам окна, для большинства случаев этого должно быть достаточно.
Честно говоря, альтернативы я не вижу. Все знакомые мне средства автоматизации тестирования GUI не обладают динамичностью, показанной ниже – уже во время выполнения теста получать список контролов, определять их тип и выполнять допустимое действие.
Также не стоит недооценивать возможностей самого Питона и его модулей. Тут вам можно и видео снять, CPU замерить и сообщение, куда надо, в случае чего отправить…
Введение во фреймворки (Часть 1)

Автоматизированное тестирование (АТ) наиболее эффективно, когда реализовано с помощью фреймворка. Несмотря на то, что в АТ термин фреймворк зачастую используется для описания совокупности объектов, которая формирует инструмент модульного тестированиия, эта статья будет в основном сфокусирована на фреймворках другого рода. Мы обсудим типы фреймворков, которые могут быть определены как совокупность абстрактных понятий, процессов, процедур и сред, с помощью которой автоматические тесты проектируются, создаются и реализуется. Кроме того, это определение фреймворка включает в себя физические объекты, используемые для создания тестов и их реализации, а также для организации логического взаимодействия между компонентами.
Автоматизированное тестирование (и, следовательно, фреймворки) развивалось годами, формируясь и усложняясь с каждой новой фазой эволюции. Эти фазы могут быть описаны в терминах трех поколений, каждое из которых обладает набором недостатков и преимуществ, благодаря которым каждое из них остается актуальным, несмотря на новые разработки. Представленные ниже понятия обычно используются для автоматизации функционального тестирования, но в некоторых случаях их можно применить и для решения задач модульного тестирования.
Введение во фреймворки (Часть 2)

Часть 1
Второе поколение фреймворков
Это поколение является промежуточным уровнем фреймворков автоматизированного тестирования, среди них могут быть и достаточно простые фреймворки, а могут быть и достаточно хорошо спроектированные. Подобные фреймворки должны рассматриваться в случае, когда поддержка автотестов является важным фактором. Хорошее понимание этого поколения фреймворков является важным, так как на концепциях фреймворков этого уровня основываются фреймворки третьего поколения.К фреймворкам второго поколения относятся фреймворки ориентированные на данных и фреймворки использующие функциональную декомпозицию. Большинство фреймворков этого уровня являются гибридами и используют оба подхода, но так как возможно использование только одного из них, то эти подходы будут рассмотрены независимо друг от друга.
Page Object Model + Webdriver. Пример реализации на одном тесте
К сожалению не работал с другими инструментами по автоматизации кроме Webdriver или Selenium. Но, не смотря на это, мне кажется, что данный подход может быть использован и с другими инструментами.
Примеры кода будут на C# + NUnit.
Сразу хочу сказать, что данная статья является отражением моего собственного опыта и не содержит никаких ссылок или цитат. Написанное ниже является не более чем повествованием моего видения на данный подход и отнюдь не преподносится как постулат.
Почему же он так эффективен?
Наверное потому, что он вносит этот бесценный порядок в структуру проекта. Следуя принципам этого подхода, мы создаем структуру с четко разграниченными логическими модулями. А каждый такой модуль будет являться отражением логических модулей тестируемого приложения.
Это значительно облегчает поиск и переиспользование методов и, как следствие, облегчает обслуживание проекта. Также, в значительной мере сокращает время, необходимое новому участнику, для «вливания» в проект.
Step-by-step: настройка SpecFlow для русскоязычного проекта при написании тестов в среде .Net
Я все-таки как-то разобралась, и, чтобы другие не сомневались, что это не так уж и сложно сделать, и не набивали собственные шишки, делюсь своей инструкцией. Она прежде всего предназначена для тестировщиков-автоматизаторов, поэтому может содержать некоторые очевидные для программистов моменты.
Эта статья полезна для тех, кто:
- оценивает перспективы применения Specification by Example (BDD) подхода к автоматизации тестирования, и хочет описывать фичи и сценарии на русском языке, и хочет оценить scope работ;
- хочет как можно быстрее начать применять BDD в своем проекте.
Эта статья бесполезна для тех, кто:
- сам знает как это просто делается;
- готов потратить несколько часов работы + владеет английским языком достаточно хорошо, чтобы самому разобраться в инструкциях.
Автоматизация тестирования программных систем
Сканирование с поддержкой JavaScript/Ajax/DomMutation или SlimerJS + CasperJS + Magic = Profit
Путь к непрерывной интеграции. Selenium + TeamCity
Вступ
Рассмотрим интегрирование тестов Selenium IDE в процесс непрерывной интеграции с помощью TeamCity. В многих местах встречал когда QA создает тесты ( в лучшем случае, зачастую бывает когда кликери просто по документу «прокликивают» проект и делает отчеты ) и регулярно запускают их, и как правило все это происходит локально на его же компьютере. Как на меня абсолютно не системный подход, который (сейчас то, в 2014 году ) решается миллионом решений для полной автоматизации процесса.
Ну раз Continuous Integration такая популярная практика, почему же не внедрить функциональное тестирование в процесс непрерывной интеграции, облегчить жизнь тестировщикам и поднять уровень качества продукта в целом.
Что надо и чего хотим
Что есть?
- CI сервер (TeamCity) для сборки и деплоймента проектов
- QA с пачкой тестов созданных в Selenium IDE
- Энтузиазм
Что надо?
- Добавить в процесс непрерывной интеграции исполнение Selenium IDE тестов
Как установить, настроить и сделать первые билд конфигурации на просторах больше чем надо, потому описывать не буду, да и речь не об этом.
Прошу под кат.
Автотесты в функциональном стиле
Элементы функционального программирования появились в Java сравнительно недавно, но приобретает все большую популярность. Особенно в части stream API – наверное нет Java разработчика, который бы не слышал/читал/применял этот API для работы с коллекциями. К сожалению, большинство и не идет дальше использования Stream API, тогда как функциональный подход позволяет значительно упростить жизнь разработчикам автотестов. Ниже я расскажу про два примера такого упрощения – словари проверок и специализированные матчеры
Как мы тестируем взаимодействие с Facebook

Вступление
Привет, хаброжитель! Уже довольно давно я хотел написать статью о том, как у нас в Badoo устроена автоматизация тестирования. Хотелось написать о чем-то интересном и, в то же время, полезном. Поделиться опытом, который можно было бы легко интегрировать почти в любую систему. И вот, такая тема назрела…
Как многие из вас знают, Badoo — это социальная сеть, ориентированная на поиск новых друзей и знакомств. Одной из важнейших задач является верификация пользователя. Ведь всем нам хочется, чтобы привлекательная девушка, с которой у нас назначена встреча, не оказалась дядей Колей из Твери.
Для верификации пользователей у нас существует много различных способов. Некоторые из них довольно привычные, такие, как верификация по номеру телефона. Есть и более необычный — верификация по фотографии. Но самая простая и быстрая — верификация через социальные сети.
Такой способ верификации профиля возможен сразу на момент его создания — регистрация через социальную сеть. Во-первых, это быстро, всего один клик и никаких дополнительных манипуляций с телефоном или веб-камерой. Во-вторых, это удобно, так как при желании можно импортировать фотографии и информацию о себе, вместо того, чтобы вводить их вручную.
Сегодня я расскажу о том, как на Badoo устроена регистрация и верификация через Facebook и о том, как мы научили selenium-тесты ее проверять.
Функциональное тестирование современных web-приложений
Современные web-приложения зачастую содержат множество "движущихся частей" и сторонних зависимостей. В процессе рефакторинга и добавления/изменения функциональности в таком приложении может произойти поломка существующих use-case сценариев и нестабильная работа в определенных браузерах.
Для своевременного обнаружения таких ситуаций и выполнения непрерывной интеграции необходимо функциональное тестирование web-приложения. В статье пойдет речь о двух бесплатных open-source решениях:
Доставляем себе в офис чашку горячего кофе одной командой консоли с помощью TestCafe
Друзья, сегодня я расскажу вам историю о том, как просто и изящно решить проблему еnd-to-еnd тестирования web-сервиса доставки кофе с помощью нового open source тестового фреймворка. Мы проведем проверку не только работы сайта, но и менеджеров и даже службы доставки, к тому же потратим на это минимум усилий и времени. А в качестве бонуса за приложенные усилия получим кружечку горячего кофе прямо в руки. Всех любителей приключений прошу под кат…
Перевод книги Appium Essentials. Глава 1

Ниже приведен перевод первой главы. В планах опубликовать перевод целиком. Публиковать буду или по главам, или по осмысленным логическим блокам.
Местами, в книге будут комментарии от меня [вот в таких скобках]. Они будут небольшие, просто для уточнения контекста, где необходимо. И еще одно: иногда, редко, буду пропускать какие-то совсем уж очевидные вещи из разряда как прописать JAVA_HOME. Пропущенные куски буду обозначать.
На данный момент есть перевод главы 1 (ниже),
Главы 2
и Главы 3
А в целом, с удовольствием принимаю указания на неточности перевода (с потерей смысла).
Надеюсь, перевод будет полезен. Поехали!
Перевод книги Appium Essentials. Глава 4
Глава 4. Поиск элементов по разным локаторам
У Appium есть несколько способов локализовать элементы в мобильном приложении. В этой главе, некоторые техники поиска элементов для нативных и гибридных приложений, с использованием uiautomator и Appium inspector. Чтобы определять элементы в web-приложениях, мы рассмотрим add-on для Chrome, чтобы удаленно локализовать элементы.
В этой главе:
- Поиск элементов с использованием Chrome ADB plugin
- Поиск элементов с использованием Safari Develop
- Поиск элементов с использованием UIAutomator и Appium Inspector
- Поиск элементов по id, Name, LinkText, Xpath, cssSelector, ClassName, AccessibilityId, AndroidUIAutomator и IosUIAutomation
Руководство: Cucumber + Java
В данной статье мы рассмотрим один из самых популярных фреймворков для автоматизации тестирования с использованием BDD-подхода – Cucumber. Также посмотрим, как он работает и какие средства предоставляет.
Перевод книги Appium Essentials. Глава 5
- Глава 1, в которой мы разбираемся, что тут и как
- Глава 2 про установку и настройку всего необходимого для работы
- Глава 3, где мы изучаем, что такое Appium GUI
- Глава 4 о том, как можно локализовать элементы в мобильном приложении
В этой главе мы, переходим к автоматизации приложений:
- Автоматизация нативных приложений
- Автоматизация гибридных приложений
- Работа с веб-приложениями и нативными браузерами
- Работа с веб-приложениями и Safari
Впереди много кода. Поехали!
Перевод книги Appium Essentials. Глава 6
- Глава 1, в которой мы разбираемся, что тут и как
- Глава 2 про установку и настройку всего необходимого для работы
- Глава 3, где мы изучаем, что такое Appium GUI
- Глава 4 о том, как можно локализовать элементы в мобильном приложении
- Глава 5, где мы, наконец-то автоматизируем приложения, но пока только на эмуляторах
В этой главе:
- Автоматизируем набор номера на устройстве Android
- Автоматизируем форму регистрации на Android
- Используя Chrome, залогинимся на Gmail
- iOS. Автоматизируем Body Mass Index (BMI)
- Автоматизация гибридных приложений на устройствах iOS
- iOS. Автоматизация веб-приложений