Сценарии на формальных языках

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

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

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

И при передаче информации в тестируемый интерфейс, и при получении информации для анализа могут использоваться два способа доступа к элементам интерфейса:

· позиционный, при котором доступ к элементу осуществляется при помощи задания его абсолютных (относительно экрана) или относительных (относительно окна) координат и размеров;

· по идентификатору, при котором доступ к элементу осуществляется при помощи получения интерфейсного элемента при помощи его уникального идентификатора в пределах окна.

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

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

Если во второй версии системы после нажатия на кнопку "Передать данные" вначале выводится окно "Вы уверены?" с кнопками "Да" и "Нет", то для проверки работы индикатора прогресса в тестовый сценарий необходимо добавить имитацию нажатия кнопки "Да".

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

Перспективы развития интерфейсов.

В последнее время приобрела отчетливые очертания новая параллельная технология проектирования оборудования и программного обеспечения, значительно изменяющая требования к соответствующим программным инструментальным средствам (ИС).

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

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

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

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

Поскольку теряется разделение во времени этапов эскизного проекта и разработки технологии производства нового оборудования, возникает необходимость почти с самого начала работ воссоздать внешний и внутренний облик проектируемого изделия. Этому способствуют средства компьютерного моделирования и графики.

2. Объективное представление или, другими словами, "виртуальный макет" изделия в состоянии отражать большинство его свойств, в том числе вести продуктивный диалог с заказчиком, конкретизировать и фиксировать его запросы.

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

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

Параллельная работа разных специалистов ведет к объединению разных инструментальных программных средств, например, САПР и Средств Автоматизации Экономической Оценки. Уже практически объединены ИС электрического проектирования, проектирования программного обеспечения, заказных экспериментальных средств, проектирования электронных блоков и плат и подготовки технической документации.