Автоматизированное функциональное тестирование

Подскажите, пожалуйста новичку. Есть веб-приложение. Для него необходимо сделать с помощью связки JUnit+Selenium+Ant+Java "автоматизированное функциональное тестирование". Правильно ли я понимаю задание?
Необходимо программно проверить каждую кнопочку, каждую ссылочку, каждое поле для ввода. правильные ли вводятся данные, на те ли страницы переходит по ссылке.
Не очень понятен смысл этого тестирования из-за большого колличества написанного кода тестов. Выгодно ли это?

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

Подскажите, пожалуйста новичку. Есть веб-приложение. Для него необходимо сделать с помощью связки JUnit+Selenium+Ant+Java "автоматизированное функциональное тестирование". Правильно ли я понимаю задание?

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

Не очень понятен смысл этого тестирования из-за большого колличества написанного кода тестов. Выгодно ли это?

Очень правильный вопрос. Многое зависит от того, сколько времени будет сэкономлено благодаря такой автоматизации. В целом, если это регрессионные тесты и прогоняются раз в две недели постоянно, то разработка автотестов в течение пары месяцев будет оправдано. Но это мое личное мнение.

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

Лучше будет, что бы в одном модуле \ файле \ классе содержалось то кол-во строк, которые вы можете легко мысленно охватить. У меня это 10 000 строк кода с использованием регионов. Так же различные данные (локаторы, логины\пароли, векторы и прочие метаданные) хранить стоит отдельно от кода. Хотя у нас они длительное время хранились прямо в коде, но всё-таки отдельным блоком.

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

Спасибо большое за ответ!

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

А можно поподробнее - где это почитать?

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

А можно поподробнее - где это почитать?

Мне очень понравился подход Алексея Булата, который он описывает в своём блоге. Вообще-то многие сошлись во мнении, что такая структура хороша на практике.
Ели же говорить об автоматизированном тестировании вообще, то мне помогли следующие книги:

Fewster. Graham. Software Test Automation
Li Wu. Effective GUI.Test Automation Developing
Дастин.Элфрид. Автоматизированное тестирование ПО
McCaffrey. .NET Test Automation Recipes

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