Auto ConfeT&QA, весна 2012

Существует 3 основных типа Android приложений:
— Native
— Web
— Hybrid
За 20 минут я успею показать, как автоматизировать Native Android приложения при помощи инструмента Robotium, так чтобы голова не болела.

При подготовке фреймворка автоматизации таких моментов очень много, и чтобы все быстро и шустро работало, а также выглядело элегантно и красиво, и тем более лекго поддерживалось, надо где-то подсолить, а где-то подперчить. Есть очень много примеров релизации фреймворков для автоматизации веб приложений на Selenium c помощью Java, а вот на Python не так много. Я поделюсь своим опытом разработки фреймворка на Python, так чтобы фреймворк выглядел вкусным и аппетитным!

Я расскажу про две типовые стратегические схемы, которые позволяют плавно внедрить автоматизированное тестирование, оставляя возможности для отхода в случае неуспеха (да-да, это очень важно!) с минимальными потерями. Первая схема имеет основной целью сокращение времени на тестирование. Вторая — увеличение тестового покрытия. А последовательное применение этих двух стратегических схем позволяет достичь одновременно обоих целей.

Я хотел бы разсказать о практике использования TestComplete в большом веб проекте для известного банка в текущем проекте, в котором тестируется UI достаточно известного стендэлон приложения. Фреймворк, создаваемый подобным образом, позволит сократить время старта написания тестов для вашего приложения до нескольких часов :)

TDD можно применять не только на уровне модульных тестов, но и на уровне функционального тестирования. Это дает возможность задуматься о структуре и особенностях функциональности еще до ее реализации. Вам не придется мучиться в попытках протестировать приложение, которое не задумывалось для тестирования (сложные локаторы, непонятная структура страниц, запутанные связки элементов). В качестве сопутствующего эффекта, TDD позволяет сократить время на ручную проверку разработчикам и автоматизировать 100% функциональных тестов.
Многим понятны преимущества TDD, но они не знают с чего начать. Некоторым кажется, что написание теста до появления реализации вообще невозможно. В своем докладе я расскажу не только о преимуществах и особенностях данного подхода, но и на примерах продемонстрирую, как работать с TDD на практике. Будут рассмотрены варианты распределения ролей, техники написания тестов и особенности их использования. В качестве основного инструмента для тестирования будет использован WebDriver.

- Отказаться от автоматизации через UI
- Искать инструменты, которые поддерживают данный конкретный пользовательский интерфейс
В своём докладе я рассмотрю еще один вариант обхода данной проблемы: рассматривать UI как набор изображений и манипулировать им на основе предопределённых шаблонов.
Наиболее известным инструментом, который работает на этих принципах, является Sikuli. Разработанный в MIT, Sikuli на данный момент является практически единственным бесплатным вариантом работы с UI на основе изображений. Подход является новым веянием в автоматизации тестирования и обладает весьма специфическими особенностями: как достоинствами, так и недостатками, которые надо учитывать, если Вы выбираете Sikuli в качестве инструмента для автоматизации тестирования.

Вы не можете понять код, записанный с помощью кнопочки record?
Хотите, чтобы тест был не “сломай-глаза”, а нагляден и понятен любому? Например, такой:
формочка .Открыть .НайтиОбъект .ПерейтиНаОбъект .ВвестиФигню .ЕстьСообщениеОбОшибке .Закрыть
Это возможно! На примере Visual Studio 2010 + Watin + NUnit + ReSharper и c использованием языка C# я покажу вам, что такие тесты… работают!

Но не все знают, что можно создать полноценное решение для автоматизации тестирования на проекте c Visual Studio, используя CodedUI как инструмент создания (записи) тестов и Microsoft Test Manager как инструмент для управления и контроля выполнения автоматичеких тестов. Интеграция этих инструментов на платформе Team Foundation Server в полной мере решает большинство задач автоматизации тестирования.
В своем докладе я рассмотрю проблемы установки и настройки всех необходимых компонентов а также приведу пример создания тестового проекта.

1. Промежуточный формат результатов тестирования Log4J/JAXB
2. Представление результатов XSLT/HTML
– уровни представлений (разработчик тестов, тестировщик, менеджер)
3. Хранилище результатов MySQL/Tomcat
– фильтрация результатов;
– анализ результатов;
4. Взаимодействие системы с иструментом TestNG

А тем временем, Вы не можете писать новые тесты и доверие к результатам Вашей автоматизации стремительно падает… И выход есть!
Сделать ход конем! – Обойти проблему и разблокировать авто тесты.
Я покажу, как это можно сделать и с точки зрения процесса разработки, и кода.