Статьи

Тестирование веб-приложений с Selenium

Существует много общих проблем для многих систем тестирования: они отличаются от реального клиента (в случае веб-приложений — браузера). Zend_Test , HttpUnit и подобные инструменты выполняют поддельные HTTP-запросы (которые могут идти или не проходить через стек TCP / IP) и проверяют HTTP-ответ в HTML или XML, чтобы убедиться, что ваше приложение дает правильные результаты.

Другая проблема состоит в том, что обычно JavaScript не выполняется этими инструментами (и если он выполняется, как в случае HttpUnit, это подмножество реального JavaScript, доступного в браузерах и может не иметь некоторых объектов или методов в DOM.)

Selenium использует настоящие браузеры

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

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

Как расширение Firefox

Существуют разные распределения Selenium. Selenium IDE — это инструмент записи и воспроизведения : в основном вы устанавливаете его как расширение Firefox, посещаете узел, на котором находится сайт или приложение для тестирования, и сохраняете то, что вы делаете в браузере, в виде HTML-файлов (очень похоже на приемочные тесты FitNesse).

Затем вы можете воспроизвести набор тестов в браузере или через API (обсуждается позже) на любом хосте (указав в то время localhost , stagingserver и т. Д.)

Проблема, которая мне пришла в голову, заключается в том, что Selenium IDE не адаптируется к разработке через тестирование: должен существовать пользовательский интерфейс, прежде чем вы сможете записать тестовый пример. Поэтому вы теряете преимущества тестируемости как инструмента дизайна (не графический дизайн, а дизайн приложения).

Тем не менее, я все еще учусь тестировать интерфейс AJAX, и, возможно, разработка через тестирование не очень полезна для GUI. Тем не менее, Acceptance Test-Driven Development с HTML и CSS была обаянием (в тестах я проверял, что выражения XPath или CSS выбирают элемент, который содержит определенный текст, или что таблица или список имеет N элементов …)

Как сервер, на который можно ссылаться в ваших сборках

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

Selenium RC (Remote Control) — это сервер, который запускает браузеры по запросу своих клиентов. Клиентами могут быть тестовые примеры xUnit на выбранном вами языке (JUnit, PHPUNit), которые получают доступ к Selenium Api, предоставляемому в виде библиотеки в самом пакете Selenium RC. Это значительно лучше, если вы тестируете пользовательский интерфейс.

Вы можете запускать Selenium RC при каждом запуске теста, передавая ему набор тестов в формате HTML, или просто оставить его на сервере (возможно, в Continuous Integration). Я запускаю его как демон на машине Ubuntu, которая выполняет сборку.

При использовании Selenium RC вы фактически увидите, что Firefox запускается и завершается для тестовых запусков на компьютере, на котором он размещен, и прохождение приложения будет выполнено для вас в любое время. Вы даже можете снять его вручную или программно, а в случае тестовой регрессии пересмотреть его, чтобы увидеть, что пошло не так. Selenium RC, очевидно, тяжелее, чем HttpUnit и другие низкоуровневые инструменты, но на самом деле просмотр доступа к приложению через браузер гораздо более мощный и показательный.

Java Api

Если вы используете Java для своих тестов, SeleneseTestCase — это класс, на который вы будете ссылаться (вы найдете Jar в пакете, содержащем Selenium RC.) Вам не нужно всегда расширять его, вы можете просто создайте его один раз, добавьте метод getSelenium () и скомпонуйте его в своих приемочных тестах.

Вот мой SeleniumIntegrationTest (проверяет, что Api и Selenium RC установлены и работают, и моя оболочка SeleneseTestCase, чтобы использовать его в качестве соавтора в вашем тесте, а не как суперкласс.

//SeleniumIntegrationTest.java
package it.polimi.chansonnier.test;

import java.io.File;

import junit.framework.TestCase;

import com.thoughtworks.selenium.*;

public class SeleniumIntegrationTest extends TestCase {
WrappableSeleneseTestCase wrapped;
Selenium selenium;


public void setUp() throws Exception {
wrapped = new WrappableSeleneseTestCase();
wrapped.setUp("http://www.google.com/", "*chrome");
selenium = wrapped.getSelenium();
}

public void tearDown() throws Exception {
wrapped.tearDown();
}

public void testSeleniumRCIsStartedAndWorks() throws Exception {
selenium.open("/");
wrapped.verifyTrue(selenium.isTextPresent("Google"));
}
}

//WrappableSeleneseTestCase.java
package it.polimi.chansonnier.test;

import com.thoughtworks.selenium.SeleneseTestCase;
import com.thoughtworks.selenium.Selenium;

public class WrappableSeleneseTestCase extends SeleneseTestCase {
public Selenium getSelenium() {
return selenium;
}
}

В сборке серверов

Selenium RC обычно требует графической среды, поскольку современные браузеры не запускаются без дисплея для визуализации. Но все же полезно использовать Selenium RC для автоматизации сборки, возможно, на сервере без графического интерфейса.

Моя ситуация была именно такой: я запускаю свои сборки и тестовые наборы на сервере Ubuntu. Но по крайней мере в Unix серверы не имеют графических интерфейсов. К счастью, это Linux, и вы можете подключить программное обеспечение, такое как Lego bricks: познакомьтесь с виртуальным кадровым буфером X , по сути паттерном тестирования Fake, примененным к XServer:


В системе X Window виртуальный кадровый буфер Xvfb или X — это сервер X11, который выполняет все графические операции в памяти, не показывая никакого вывода на экран.
С точки зрения клиента, он действует точно так же, как и любой другой сервер, обслуживая запросы и отправляя события и ошибки соответствующим образом. Однако выходные данные не отображаются. Этот виртуальный сервер не требует, чтобы на компьютере, на котором он запущен, даже был экран или любое устройство ввода. Необходим только сетевой уровень.

Конечно, у каждого сервера есть сетевой уровень, иначе вы не сможете получить к нему доступ через ssh.

Таким образом, я установил пакеты xvfm и firefox на Ubuntu Server, и вместо запуска сервера selenium RC вот так:

sudo java -jar selenium-server.jar -log /home/giorgio/log/selenium &

в моем /etc/rc.local я теперь запускаю его так:

sudo xvfb-run -e /home/giorgio/log/xvfb-run java -jar selenium-server.jar -log /home/giorgio/log/selenium &

Если вы также установите пакет x11-apps , вы можете сделать несколько хороших фотографий с xwd, пока Selenium RC прекрасно справляется со своей работой: