Требования, предъявляемые к утилите Tester
Главное требование заключалось в том, чтобы Tester сосредоточился на одной задаче, но выполнял ее хорошо, а именно: автоматизировал нажатия клавиш в ходе тестирования приложения, обеспечивая ускорение блочного теста. Те, кто работал с коммерческими инструментами регрессивного тестирования, несомненно знают, какую дикую гонку они могут устраивать — от простого управления окном на экране до проверки любых самых сложных и экзотических данных о наиболее тонких свойствах окна. Необходимо было сконцентрировать Tester на потребностях разработчика во время блочного тестирования максимально упростить его использование.
Вот основные требования к утилите Tester:
1. Ею можно управлять через любой язык, который поддерживает модель компонентных объектов (СОМ).
2. Получив входную последовательность нажатия клавиш, в том же формате, который использует VB-функция sendKeys, Tester должен воспроизвести ее в активном окне.
3. Tester может находить любое высокоуровневое или дочернее окно по его заголовку или классу.
4. По заданному произвольному дескриптору HWND Tester может получить все свойства соответствующего окна.
5. Tester должен уведомлять сценарий пользователя о создании или ликвидации конкретного окна, так чтобы сценарий мог обрабатывать состояния потенциальных ошибок или выполнять улучшенную обработку окна.
6. Tester должен поддерживать совместное использование сценариев с любым разработчиком команды.
7. Tester допускает расширения своего кода в любом интересующем разработчиков направлении.
Нетрудно заметить, что в этом списке ничего не сказано о действиях с мышью. Зарегистрировать ввод мыши через журнал относительно легко, но, выбрав этот метод, не забудьте об одной маленькой, но важной детали: воспроизведение "мышиных" действий должно выполняться при том же разрешении экрана, при котором они были записаны. Не многие коллективы разработчиков могут соблюдать это требование. Если разрешение экрана при описании действий с мышью задано жестко, то совместное использование сценария становится практически невозможным. Другая проблема состоит в том, что сценарий прерывается, если переместить управление в UI даже на пиксел или два. Сценарий, записанный после того, как UI "замораживается", оказывается слишком хрупким. Фокус в том, что адекватное тестирование невозможно, пока UI "заморожен".
Tester, вероятно, не является подходящим решением для отдела с 20 специалистами по проверке качества (Quality Assurance — QA). Я намеревался создать инструмент, пригодный для автоматизации блочного тестирования в группе, состоящей из нескольких разработчиков. Думаю, что к настоящему моменту Tester удовлетворяет данному требованию. Эта утилита применялась при разработке GUI-отладчика WDBG, рассмотренного в главе 4, и уберегла меня от тысяч нажатий клавиш — так что я могу еще двигать запястьями!
