Советы по созданию тестового "фреймворка" с использованием Watir? - PullRequest
2 голосов
/ 26 марта 2012

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

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

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

Таким образом, согласно этой идее, для страницы с, скажем, 40 текстовыми полями, будетЯ создаю метод для каждого текстового поля, который называется «fill_ fieldname »?

. Меня также интересует вопрос о том, как бы я разбил тестовые случаи при наличии предварительных условий.Например, если мне нужно проверить функциональность конкретной формы, мне сначала понадобится клиент для существования.Должен ли я создавать новый клиент для каждого сценария, который я тестирую, или просто использовать один клиент для всех сценариев?Я полагаю, что перед каждым тестовым сценарием мне придется проверять предварительные условия, чтобы убедиться, что клиент все еще «пригоден» для тестирования ...

Я действительно не понимаю, с чего начать, и яМне бы очень хотелось создать хорошую основу с самого начала, а не ломать все после того, как проект стал слишком большим.Любые советы / рекомендации будут очень признательны.

Ответы [ 3 ]

7 голосов
/ 27 марта 2012

Большинство людей собираются связать watir-webdriver с существующей структурой страниц, такой как cucumber или rspec для организации и проверки. После этого, я полагаю, вы обращались к структуре шаблонов объектов страниц для простоты использования и расширения. Вы можете найти несколько великолепных гидов здесь:

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

Надеюсь, у вас есть хорошая документация для приложения или кто-то, предоставляющий вам бизнес / варианты использования продукта. Из бизнес-кейсов очень легко создавать контрольные примеры. Затем просто идите шаг за шагом и разбейте его на наборы функций.

Также может быть сложно продумать приложение до конца и попытаться включить всю эту функциональность в свои тесты с самого начала. Прежде чем вы получите надежную среду, у вас могут быть простые тесты типа инструмента, которые помогут вам быстрее настроить ручное тестирование или выполнить тесты со значимым (но не красивым) выводом. Это все часть процесса. Вы БУДЕТЕ отменить часть того, что вы делаете, но, конечно, вы не хотите отказаться от всего этого. Сохраняйте это простым, делайте его модульным - здесь применяются все традиционные концепции развития, такие как DRY, KISS.

Хорошие автоматизированные тесты рождаются из замечательных тестовых случаев. Если вы попытаетесь пропустить этот шаг (и не имеете большого опыта), вы пожалеете об этом!

Есть много хороших книг по тестированию. Мне лично понравились Уроки, извлеченные при тестировании программного обеспечения - один из авторов Брет Петтикорд , основатель WATIR.

Как только вы разберетесь с основами тестирования, вы сможете попасть в специальные библиотеки для книг, такие как WATIR Book или во многие онлайн-блоги, связанные с упомянутыми выше Watirmelon и Cheezy.

2 голосов
/ 27 марта 2012

Я также обеспокоен тем, как бы я разбил тестовые случаи, когда есть предварительные условия. Например, если мне нужно проверить функциональность конкретной формы, мне сначала понадобится клиент для существования. Должен ли я создавать новый клиент для каждого сценария, который я тестирую, или просто использовать один клиент для всех сценариев? Я полагаю, что перед каждым тестовым сценарием мне придется проверять предварительные условия, чтобы убедиться, что клиент все еще «пригоден» для тестирования ...

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

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

Каждый раз создавать нового клиента.

1 голос
/ 27 марта 2012

Я тоже должен был начать это - используя Selenium (привязки C #) и NUnit.

Шаблон Page Object - это то, на что вы тоже ссылаетесь. От вас зависит, есть ли у вас метод Fill_TextBox в объекте страницы для каждого текстового поля на странице, но вы также можете сгруппировать их в один метод. Например (псевдокод в C #):

private void FillTextBox1()
{
    // fill text box 1
}

private void FillTextBox2()
{
    // fill text box 2
}

private void FillTextBox3()
{
    // fill text box 3
}

private void FillTextBox4()
{
    // fill text box 4
}

public void FillTextBoxes()
{
    FillTextBox1();
    FillTextBox2();
    FillTextBox3();
    FillTextBox4();
}

[Test]
public void TestTextBoxes()
{
    LoginPage loginPage = new LoginPage();
    loginPage.FillTextBoxes();
}

Это один из способов сделать это. Из названия метода вы знаете, какова общая идея того, что он делает, поэтому, если вам нужно, вы можете зайти в него, чтобы точно узнать, с какими текстовыми полями он имеет дело.

Первоначально я начал с создания нового клиента для каждого теста, и в большинстве случаев он работает хорошо, но в других случаях все может стать немного неэффективным - если предыдущий браузер по каким-либо причинам не закрывается правильно, вы можете запустить в несколько проблем. Удовлетворяя его посередине, у NUnit есть TestFixture или классы, содержащие тесты, поэтому мы создаем и открываем браузер для настройки TestFixture, и в конце каждого теста в этом классе мы гарантируем, что достигли разумного чистого состояния для подготовки к следующему тесту - в большинстве случаев это в основном выход из приложения, при этом следующий тест начинается со страницы входа в систему. Я видел много дискуссий об этом - вы должны увидеть, что работает лучше для вас. Это сокращает время, если вам не приходится постоянно выключать и создавать клиента для каждого теста.

...