В этой статье представлено вступление в новый способ генерирования тестовых скриптов для тестирования GUI (основанного на web или rich клиентах) используя model-based подход, а также описание того, как это меняет процесс тестирования. Описанный инструмент для генерирования тестовых кодов (Abstract Testing Tool) был разработан автором, при сотрудничестве с одним из наших клиентов. Сгенерированный код для автоматизации может использоваться для тестирования рабочих характеристик или функционального тестирования.

часть 1 | часть 2

Пример два: импорт файлов AutoCAD

Отдел экспозиции использует AutoCAD для создания плана конференций. Это включает в себя расположение стендов и всего остального,связанного с конференциями, включая непонятные символы и электрические розетки. Но, в любом случае, эти чертежи предназначались для того, чтобы их читали люди.

Требованием для этой информационной системы была демонстрация карты. Посетители могут выбрать расположение на карте, а система покажет им продавца. Для конференц-центра было необходимо импортировать в систему файлы DWG из AutoCAD, созданные отделом экспозиции. Чтение файлов AutoCAD довольно медленно, поэтому файлы конвертируются во внутренний формат, сохраняющий только необходимую информацию, удаляя ненужную, например электрические розетки.

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

На встрече по определению требований мы обсуждали различные возможные исключения, которые система должна поддерживать. Мы начали с абстрактного описания и перешли далее к примерам, как показано в Рис. 1.8.

Тут поделились ссылочкой, http://sourceforge.net/projects/blueducksda/. Проект, который комбинирует Selenium и AutoIt.

Я бы сказал, - гремучая смесь. Кто уже пользовался? Интересно, стоит ли использовать?

Мы с вами делаем хорошее дело - учимся и равиваем автоматизацию. Нет предела совершенству, и поэтому мы идем все дальше и дальше. На носу 5-я встреча автоматизаторов, которая пройдет, как и прошлая встреча, в G-Club компании GlobalLogic. Предыдущая встреча прошла действительно хорошо, атмосфера была дружественная, что особенно способствовало активному общению. Мягкие и удобные диваны и просторное помещение G-Club создают определенный домашний уют, поэтому следующую встречу снова проведем в G-Club.

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

часть 1

Пример: ROBOT FRAMEWORK

В этом разделе представлен короткий пример Robot Framework, который использует систему, над которой мы работали много лет назад. При самой разработке не использовались A-TDD или Robot Framework, то есть пример – новый, система – старая. Это система среднего размера (большие продукты с более сложных или незнакомых доменов сложно использовать в качетсве примера на нескольких страницах.), но, все же, этот пример демонстрирует принципиальные моменты, которые будут актуальными и для среды большего размера.

Robot Framework –фреймворк для автоматизации, использующий keyword-driven подход, созданный Pekka Klärck (Ранее Pekka Laukkanen)  в Nokia Siemens Networks в 2005. Одной из его ранних целей была поддержка A-TDD. Он стал бесплатным в 2008 г. и доступен на www.robotframework.org.

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

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

Технические аспекты

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

В основном, автоматизированный тест состоит из двух частей: тестовые данные и код, который управляет тестируемым приложением. Тестовые данные обычно поддерживаются в отдельной формате или даже в отдельном репозитории. Фактический код автоматизации может строиться через уже существующие фреймворки, такие как FitNesse или RobotFramework или же могут использоваться фреймворки, которые создаются непосредственно в компании для нужд проектов.

Проблема: Как можно создать много тестов без написания большого количества программного кода?

Решение: Используйте обобщенную среду управления сценариями (фреймворк), расширяя ее под нужды вашего проекта.

Контекст:

• Сотрудники: Тестировщики/программисты; специалисты по инструментам для тестирования.
• Продукт: GUI, API, CLI или модульные интерфейсы.
• Цели:
  • автоматизировать тесты, которые понадобятся на протяжении всего жизненного цикла продукта;
  • автоматизировать тесты, которые спланированы заранее;
  • обеспечить максимальную гибкость подхода к автоматизации и его поддержку.

Стратегия тестирования:

• Создание тестов: Тесты пишутся вручную, используя повторения действий через Сapture&Playback, если есть возможность. Тестируемый продукт уже должен быть рабочим и стабильным перед написанием тестов.
• Выполнение тестов: Фреймворк автоматизации предоставляет среду для запуска написанных тестов.
• Оценка результатов тестов:
  • Ожидаемые результаты тестов прописываются в коде теста во время его создания, или
  • Фреймворк может подхватить их для последующего сравнения во время первого запуска тестов и записать, как ожидаемый результат.

Атрибуты качества:
Сопровождение и поддержка:

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

Возможность пересмотра:

• Низкая.
• Тесты пишутся на скриптовом языке, который поддерживается фреймворком.
• Читаемость тестов может быть увеличена через использование стандартных скриптовых языков.

Целостность и зависимость:

• Средняя.
• Языки сценариев обеспечивают достаточную свободу для написания хитрого, запутанного, подверженного ошибкам кода.

Возможность повторного использования:

• Средняя.
• Фреймворк может быть фундаментом для создание других архитектур и фреймворков.

Следующий шаг:
Разработанные сценарии могут быть фундаментом для различных архитектур, включая скрипты на основе данных, таблицы на основе пользовательского интерфейса, ключевые слова-действия, программирование на основе тестов, API-тесты, ограниченное использование графического интерфейса, использование оракула, «Автоматизированная обезьянка».

Структуру разработки сценариев можно расширить, используя Window Maps, Task Libraries, Widget Support Libraries (Error recovery System). Использование стандартизированного скриптового языка может очень помочь в этом шаблоне.