3.3 Предложения по доработке системы

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

1. Обеспечение возможности тестирования приложений, функционирующих под Windows, но написанных не на vip.

Речь идет, по крайней мере, об обеспечении интерфейса AQA с другими Windows-приложениями, позволяющего выполнять некоторые тестовые действия, возможно, с определенными ограничениями по сравнению с возможностями AQA.

Данная функция позволит:

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

• Выполнять в AQA-тесте некоторые действия с окнами Word, Excel, а также Galagraf, например, скроллинг, закрытие окон и т. п. Не исключено также, что в дальнейшем может потребоваться и воспроизведение при прогоне теста редактирования в этих окнах.

2. Обеспечение возможности контроля отчетов, выпускаемых в формате Word и Excel.

Другими словами, необходимо иметь возможность установки контрольной точки на окна Word и Excel, аналогично тому, как это делается в окне редактора БизнесТекст. Актуальность данного требования обусловлена большим количеством подобных отчетов (особенно в формате Word), выпускаемых в Галактике в настоящее время и контролируемых визуально на экране и путем распечатки. Ручное сравнение этих отчетов с эталоном резко снижает эффективность тестирования. Сложность выпускаемых отчетов и рост количества отчетов, выпускаемых согласно законодательных актов, приведет в дальнейшем к еще большему использованию указанных форматов, что повышает степень актуальности проблемы.

Решение этой задачи, очевидно, связано с решением требования 1.

3. Обеспечение возможности контроля свойств объектов экранных форм.

В настоящее время состав экранной формы может быть проконтролирован только путем «пробега» по всем ее элементам, причем свойства объектов не контролируются, кроме значения полей и то не всех – нет возможности контроля вычисляемых полей. Вследствие трудоемкости на практике это, как правило, не делается. С другой стороны, при тестировании экранной формы, как таковой (GUI-тестирование), необходимо контролировать состав формы (какие содержит поля, кнопки, переключатели (Radiobutton), флаги (Checkbox), вкладки (Tabcontrol) и т.п.) и свойства ее элементов – расположение, наименование, доступность, состояние (вкл./выкл.) и др.

Другими словами, задача заключается в расширении понятия контрольной точки — возможность хранения не одного свойства объекта (значение), а нескольких. В общем случае данная задача состоит из двух частных:

• Контроль экранной формы (анкетной, табличной, диалоговое окно) в целом – состав, наименование окна);

• Контроль свойств отдельных элементов (объектов) экранной формы.

4. Обеспечение возможности просмотра/корректировки контрольных точек теста

В настоящее время выяснить, что содержится в контрольной точке можно только в случае несовпадения с текущим значением при выполнении теста.

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