Обзор имеющихся средств автоматического тестирования графического интерфейса
Самым распространённым способом тестирования графического интерфейса является ручное тестирование. Естественно, у такого подхода имеются серьёзные недостатки, и самый главный из них – большая трудоёмкость, которая часто становится критичной при организации регрессионного тестирования. Другим недостатком такого подхода является отсутствие гарантий выполнения каждого доступного воздействия из каждого возможного состояния системы. Таким образом, приходится полагаться на однозначность реакции системы на одинаковые воздействия из разных состояний, то есть считать эти состояния эквивалентными для данного воздействия.
Другим способом организации тестирования является автоматическое тестирование [2]. Существуют два раскрытия этого термина:
Из наиболее доступных инструментов для автоматизированного тестирования можно выделить следующие пять:
Перечисленные инструменты применяются для автоматизированного тестирования, в том числе при тестировании GUI. В своей статье [3] Рэй Робинсон приводит сравнительную таблицу (см. таб. 1) этих инструментов по способности удовлетворять заданные потребности пользователя. При этом рассматриваются различные свойства этих инструментов:
- Запись и проигрывание тестов
- Возможности Web-тестирования
- Возможности базы тестов и функции для работы с ней
- Объектное представление
- Сравнение рисунков
- Обработка ошибочных ситуаций
- Сравнение свойств объектов
- Возможности расширения языка
- И т.п.
(по 5-бальной шкале, наивысшая оценка - 1)
| WinRunner | QA Run | Silk Test | Visual Test | Robot | |
| Object Tests | 1 | 1 | 1 | 2 | 1 |
| Support | 1 | 2 | 2 | 2 | 2 |
| Ease of use | 2 | 2 | 3 | 3 | 1 |
| Cost | 3 | 2 | 3 | 1 | 2 |
| Integration | 1 | 1 | 3 | 2 | 1 |
| Environment support | 1 | 2 | 2 | 3 | 2 |
| Extensible Language | 2 | 2 | 1 | 2 | 1 |
| Object Identity Tool | 2 | 1 | 2 | 1 | 1 |
| Object Name Map | 1 | 2 | 1 | 4 | 4 |
| Test/Error recovery | 2 | 2 | 1 | 2 | 2 |
| Image testing | 1 | 1 | 1 | 2 | 1 |
| Object Mapping | 1 | 1 | 1 | 2 | 1 |
| Data functions | 2 | 2 | 2 | 3 | 1 |
| Database tests | 1 | 1 | 1 | 4 | 1 |
| Web Testing | 1 | 2 | 2 | 3 | 2 |
| Record & Playback | 2 | 1 | 1 | 3 | 1 |
Таблица 1.
Кроме самых распространённых, имеется много других инструментов для автоматического прогона тестов, созданных вручную. Но эти инструменты не предоставляют возможности автоматической генерации тестов (исключая процесс записи теста).
В основе всех этих инструментов лежат средства формального описания тестов (разного рода скриптовые языки). Тесты пишутся вручную. Данный подход имеет существенные недостатки. Один из них состоит, как и при полностью ручном подходе, в недостаточной систематичности. Другим серьёзным недостатком является трудность при организации регрессионного тестирования. При изменении тестируемой системы возникает необходимость переписывания (редактирования) большого количества тестов. То есть, например, система изменилась в одном месте – а тесты приходится модифицировать в несравненно большем количестве мест. Причём если некоторые такие проблемы можно обойти созданием набора вызываемых функций, которые также можно изменять в одном месте, то другие (например, изменение в логике программы) так просто не решаются. Кроме того, остаётся проблема дублирования одних и тех же действий (написание одного и того же тестового кода) при совершении одного и того же события из разных состояний. Такой метод сменил ручной прогон тестов на ручное написание самих тестов для дальнейшего автоматического прогона, но само их написание по-прежнему остаётся трудоёмким занятием.
Доступные инструменты для автоматической генерации тестов для GUI нам не известны. Поэтому мы в первую очередь сконцентрировали свои усилия именно на автоматизации генерации тестов для GUI по формальной спецификации. Причем при разработке средств формальной спецификации GUI мы старались максимально использовать существующие, привычные для пользователей методы и инструменты.
