Автоматизированное тестирование GUI: Встреча с нами на полпути

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

Данное приложение представляет собой веб-приложение Java, доступное через AJAX. Большинство существующих функций кодируются с использованием jsp, Javascript и немного Flash 8. Следующая волна функций будет выполнена с помощью библиотеки JUI YUI. Я довольно сильно решен на Selenium в качестве тестового инструмента из-за его гибкости и цены (бесплатно). Основной момент: я нацелен на повторное использование тестов и простоту обслуживания. Я предпочитаю писать код, который обнаруживает, проверяет и использует элементы страницы, а не использует систему записи и воспроизведения для разработки тестов.

Может ли кто-нибудь дать какие-то рекомендации относительно того, какие крючки могут быть помещены в код или какие-то передовые методы, чтобы упростить разработку тестов и сами тесты стали более надежными?

ОТВЕТЫ

Ответ 1

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

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

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

  • Способ определения, на какой странице вы находитесь. Боб может сказать разницу между логином и порядком, но как автоматизировать это знать? Если поле ввода с меткой "Username", страница входа в систему. Если поле ввода с номером заказа, поле заказа.

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

  • Способ уникальной идентификации каждого элемента, с которым вам нужно взаимодействовать (нажмите, введите, проверьте и т.д.) И не INPUT_42....

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

  • Возможность сбросить состояние программы

  • Постоянная обработка ошибок и отчетность (также хороший дизайн пользовательского интерфейса)

Ответ 2

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

У меня был большой успех с использованием Selenium RC и Selenium IDE. Главное - привыкнуть к использованию Selenium и его команд. Также полезно привыкнуть к поиску объектов на странице (XPaths и CSS-селекторам, а также функция "содержит" ). То, что вы не хотите, - это много элементов, которые имеют один и тот же путь выбора. Если таблицы и divs ниже не имеют для них уникальной части, это может добавить дополнительную сложность для ваших тестов.

<html>
  <body>
    <table>
      <tr>
        <td>
          <div></div>
          <div></div>
          <div></div>
        </td>
      </tr>
    </table>
    <table>
      <tr>
        <td>
          <div></div>
          <div></div>
          <div></div>
        </td>
      </tr>
    </table>
  </body>
</html>

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

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

Ответ 3

Один совет: сохраните свой тестовый код в менее двух слоев абстракции:

  • верхний уровень: это должен быть какой-то фасад, ориентированный на вашу конкретную прикладную терминологию/действия и т.д. Этот слой не напрямую использует библиотеку Selenium RC, В фоновом режиме он использует...
  • ... нижний уровень: библиотека с некоторыми распространенными шаблонами тестирования (пример: "утверждать, что выбрано значение X элемента управления радиокнопками" ), в котором используется библиотека Selenium RC.

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

Ответ 4

Добавление комментариев к файлам McWafflestix и s_hewitt - gui должно быть правильно помечено, уникально и предсказуемо для успеха с автоматизацией gui. Если идентификаторы элементов не предсказуемы, у вас возникнут проблемы. Предсказуемый не обязательно означает статичность. Для статических элементов страницы, таких как поле имени пользователя или кнопка входа в систему, я ожидал бы, что имя/идентификатор для них будет статичным из сборки для сборки и запуска для запуска. Для флажков, переключателей, динамического содержимого я бы ожидал, что они будут динамичными, но предсказуемыми. Например, у вас может быть div с классом = "contentdetail" и id = "12345". Пока вы можете создать свой xpath, чтобы найти объект, с которым вам нужно взаимодействовать с надежностью, вы должны быть добрым.

EDIT: отличный способ для разработчиков, чтобы поддерживать автоматизацию тестирования, - это настройка теста. В зависимости от вашего приложения автоматическая настройка теста и срыв могут быть проблематичными. Например, в приложении рабочего процесса хранилища тесты в начале рабочего процесса (принимать элементы на склад) просты в настройке, но тесты в конце рабочего процесса (отправка товара со склада заказчику) имеют многие зависимости (элемент должен находиться на складе, с достаточным количеством, в правильном месте инвентаря и т.д.), что большая часть вашего кода автоматизации может иметь дело с просто навигацией и вводом вашего пути через приложение, чтобы добраться до точки, где вы можете выполнять тест. В этих случаях может оказаться полезным иметь какую-то внешнюю утилиту (вне приложения, поэтому основной gui не затрагивается) для ввода зависимостей или reset базы данных в какое-то известное состояние. В моем примере хранилища ваша утилита могла настроить сценарий через уровень api, чтобы автоматизированный тест gui мог подняться в соответствующей точке.

Ответ 5

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

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

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

Ответ 6

Очень мало того, что разработчики могут добавить в код, чтобы помочь.

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