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

Question

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

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

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

Answer 1

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

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

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

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

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

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

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

• Возможность выгрузки состояния программы

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

Answer 2

Один совет: держите ваш тестовый код на уровне минимум два уровня абстракции :

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

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

Answer 3

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

Я добился большого успеха, используя Selenium RC и Selenium IDE. Главное - привыкнуть к использованию Selenium и его команд. Также полезно привыкнуть к поиску объектов на странице (XPath и CSS-селекторы, а также функция «содержит»). Чего вы не хотите, так это множества элементов, имеющих одинаковый путь выбора. Если приведенные ниже таблицы и элементы div не содержат уникальной части, это может добавить дополнительную сложность вашим тестам.

<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-объекты, посетите этот сайт .

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

Answer 4

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

РЕДАКТИРОВАТЬ: отличный способ для разработчиков автоматизировать тестирование с помощью настройки теста. В зависимости от вашего приложения, автоматическая настройка теста и демонтаж могут быть проблематичными. Например, в приложении рабочего процесса на складе тесты в начале рабочего процесса (прием товаров на склад) просты в настройке, но тесты в конце рабочего процесса (доставка товара со склада клиенту) много зависимостей (товар должен быть на складе, в достаточном количестве, в правильном месте инвентаризации и т. д.), что большая часть кода автоматизации может иметь дело с простой навигацией и вводом вашего пути через приложение, чтобы добраться до точки, где вы можете выполнить тест. В этих случаях может быть полезно иметь какую-то внешнюю утилиту (вне приложения, поэтому основной графический интерфейс не затрагивается) для введения зависимостей или сброса базы данных до некоторого известного состояния. В моем примере с хранилищем ваша утилита может настроить сценарий на уровне API, чтобы автоматизированный графический тест мог выполнить поиск в соответствующей точке.

Answer 5

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

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

Answer 6

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

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

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