Когда-то сам копал в эту сторону и пришел к выводу, что оно того не стоит. Почти везде, где нужно серьёзное тестирование (и как следствие приличные зп) невозможно впринципе тестировать из дома.

Неправда ваша. У меня среди знакомых есть обратные примеры.

В своем комментарии я признал, что отчасти напрасно критиковал доукментацию на Selenium 2.
Полагаю все же, что уделить внимание именно ПОСТРОЕНИЮ ТЕСТОВ можно было бы, хотя бы и не в основной части.

Еще раз повторю, Селениум не вправе диктовать то, как автор тестов их будет организовывать. Способов очень много и я считаю, что это очень хорошо, что они не захламляют официальную документацию. Вот, кстати, вчера в твитленте обнаружил "Selenium is a BROWSER automation tool. For every-fucking-thing else please ask some-fucking-where else other than a Selenium user group." (отсюда: https://twitter.com/#!/FuckingSeTips)

Не порекомендуете какой-либо связный материал по построению тестов на WebDriver + Java?
...
Видимо, это в определенной степени востребовано,
но для новичков или начинающих, к коим я себя отношу, полезны были бы материалы начального уровня,
к-рые можно было бы изучить off-line, сравнить методики, выбрать более приемлемые и понятные, а не закладываться
на суждения и опыт "драйвера" данного сайта.

Скорее всего не посоветую ибо просто не знаю что можно посоветовать. Ищите в блогах на английском. Книгу по xUnit, которую Алексей предложил я (совершенно независимо) вчера скачал с корпоративной библиотеки и собираюсь читать сам). Какие-то сравнения фреймфорков организации тестов скорее всего можно найти в инете, никогда не искал. Нашел вот список, например http://java-source.n...e/testing-tools, но они тут все из разной оперы. Читайте, выбирайте тот, который подходит и используйте для организации своих тестов.
Что касается Junit, то JUnit4 мне не понравился и я бы посоветовал использовать JUnit3. Он проще сам и его при желании проще модифицировать. Или посмотрите в сторону TestNG, говорят он получше. По крайней мере его авторы не поленились написать документацию.

Все понял, но осталось нек-рая неудовлетворенность документацией на Selenuim,
к-рая умалчивает о проверках и "игнорирует" JUnit.
Правда, там еще есть полезный раздел 7, но и он неполон.
Хотя, и это объяснимо: документация описывает ср-ва WebDriver, а построение тестов - шире и
предполагает применение JUnit или подобного инструмента в случае использования Java,
или дополнительного кода (или пакетов) для python, ruby и пр.
Впрочем, всегда можно обойтись и базовыми ср-вами языка.

Судя по вашему комментарию, все-таки не все поняли. Ожидать от документации селениума описания того как работает junit не стоит. Это все-равно, что ожидать увидеть в документации к дрели, которая делает дырки, описание того как правильно пользоваться лазерным уровнем для верного определения места где эти дырки быть должны.
Например. Недавно одни и те же тесты для сравнения я реализовал на связке selenium + ruby + одна из технологий (просто руби без дополнений, Test::Unit, Cucmber, FitNesse и RSpec). И еще rake пускалку приделал. Спрашивается какая технология должна какую описывать в своей документации?

И построение селениум тестов на java вовсе не предполагает использование junit. Только автор тестов знает что он будет использовать, авторы селениума не знают и не хотят гадать или заставлять. Selenium WD - это, по большому счету, только лишь автоматическая генерилка пользовательских событий (клик мышки, нажатие на кнопку клавиатуры, переход на страничку) в браузере. И все.

Вы можете использовать селениум вовсе не для тестирования, а для отсылки спама или для написания автоматических коментов в этот форум.

Xenu's Link Sleuth

это хорошее средство. но надо такое, которое можно было бы запускать из консоли на линуксе

чем обусловлено требование из консоли на линуксе? Почему нельзя воспользоваться виндовой виртуалкой?
Из консоли на линуксе хорошо запускается wget+grep

А что найдет wget + grep? Даже если рекурсивно wget запускать и потом анализировать коды ответа (хотя тут grep-а явно не хватит), то он битые ссылки внутри документа все-равно не найдет.

сам искал такое.
Если найдете, сообщите пожалуйста.

Ничего вы не искали.
Вот например поищите на этом форуме по словам "проверка ссылок".
А вот то, что я рекомендую, чем пользовался 7 лет: linklint (но есть недостатки).
Ну и конечно есть linkchecker который мне же на этом форуме и посоветовали.

сам искал такое.
Если найдете, сообщите пожалуйста.

Ничего вы не искали.
Вот пример поиска: http://software-test...ch&fromsearch=1
А вот то, что я рекомендую, чем пользовался 7 лет: http://software-test...ch&fromsearch=1 (но есть недостатки).
Ну и конечно есть linkchecker который мне же на этом форуме и посоветовали.

Ок. Спасибо. Только поправьте первые две ссылки.
Linklint - не староват? как понимаю, вы им пользуетесь?
A xenu хорошь тем, что в virtualbox работает с куками IE, а у нас внутренние порталы с авторизацией.

Ссылки не поправляются ибо мудрые создатели IPBoard-а считают, что давать ссылку на результаты поиска никому не надо. Я уже отредактировал коммент.

linklint староват. Сейчас уже ничем не пользуюсь, но для наших целей на прошлой моей работе его хватало (API Javadoc тестировать). У нас его кто-то немного допиливал самостоятельно и много он не умеет (например https). Смотря для чего надо.

А linkchecker поумнее.

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

Конечно, случаи разные бывают. Но из описания понятно, что баг не исчез, а остался. Меня-то это зацепило.
И сделать сообщение об ошибке, в случае если exception ожидаем ничего не стоит. Абсолютно. 5 минут фикс + 25 тестирование программистом, если конечно в программе вообще есть унифицированный механизм сообщения об ошибках.
Пользователю, в подавляющем большинстве случаев exception ничего не скажет, но сообщение вида "Ошибка возникла потому, что вы нажали сюда, а потом сюда. Так делать нельзя. Сначала надо нажать туда, а потом сюда" - скажет. И это решит проблему. Повторюсь. Это ничего не стоит и нормальный программист сможет легко найти путь исправления, и убедить руководителя, что 30 минут его времени будет потрачено не зря.

Это у вас человек на первый-второй день так работает? Тогда самое время признать свою ошибку и исправить её. То есть уволить этого сотрудника. Если, конечно, вы всё адекватно описали. В любом случае выглядит так, что вы совершаете ошибки, уж извините.

Поддерживаю. Желание из такого сделать конфетку ни к чему хорошему не приведет. Вы либо его уволите позже, когда все с ним намучаются. А чем дальше, тем сложнее будет уволить, будет жалко потраченных сил и тд. Либо он достанется кому-нибудь другому (в другой отдел, или вы уйдете, например на повышение итд). Уж поверьте, добрым словом по поводу такого работника вас поминать не станут.
А если есть команда, то за все косяки данного сотрудника придется расплачиваться членам команды - доделывать за него, тратить время на объяснения (в пустую, как понимаю) и тд.

Ну т.е. я ВООБЩЕ не понимаю, что это за степень, ну и тем более - как ее обосновать!!!! . ( )

Может быть это количество представителей данного класса эквивалентности?
А обоснование - от задачи исходить должно и от возможных вариантов.

Пример. Есть функция fac(int i) - считает факториал. Разбиваем значения по классам эквивалентности
1) отрицательные, 2) 0, 3) 1, 4) 2, 5) >2 6) max_int, 7) max_allowed, 8) min_int ... можно еще напридумывать, но к делу уже не относится.
Сколько брать представителей из какого класса?
Понятно, что для классов 2) 3) 4) 6) 7) 8) - есть только один представитель класса, его и возьмем.
Что делать с классами 1) и 5)?
Для класса 1) я бы взял -1 (вдруг проверка на отрицательные числа сделана так: if(i < -1) return "only positive values") и еще одного любого представителя класса. Альтернативно -1 можно сделать отдельным классом.
Для класса 5) я бы тоже взял 2-х представителей. Чтобы избежать антипатерна happy path test. В конкретном случае может быть такая реализация метода, которая возвращает не вычисленный факториал, а константу, равную факториалу числа поданного на вход (тут пример с факториалом: http://www.ibm.com/d...brary/os-junit/).

а вообще вопрос "зачем" это офтопик :)
Мы тут поставленные задачи решаем.
Примет вообще интересный по сути.

Конечно можно решать задачи через жопу. А можно пойти на сервис типа http://mailinator.com/ и решить для себя проблему раз и на всегда.

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

Беда, коль пироги начнет печи сапожник... (с) Иван Крылов.

На самом деле технические подробности знают лучше всего, конечно, программисты. Но они не умеют писать пользовательскую документацию. Вообще не умеют. Они, обычно, пишут ориентируясь на таких же программистов, с тем же уровнем знания продукта.
Еще зачастую имеет место быть знание языка. Даже те, кто считает, что они знаю иностранный язык хорошо, не смогут написать нормальную и понятную документацию для носителей языка.

Вы не поверите, у меня подобное было. Когда заполняла договор, были поля "Секретный вопрос" и "Ответ на секретный вопрос". В такие места обычно любят писать девичью фамилию матери. Написала... Через некоторое время случилась неприятность с этой карточкой - нужно было разблокировать её. По телефону девушка спрашивает: Ваше кодовое слово? Я сначала испугалась, потому что никаких кодовых слов не помню. Через несколько секунт догадалась, что это ответ на секретный вопрос имеется ввиду.
Смешно, потому что догадаться, что тебя спрашивают легко. Но несколько секунд страха: "Какое кодовое слово??? Я не помню такого!!!" всё же неизбежны.

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

При выполнении тестового задания самое главное не то как вы проставите северити, а то как вы объясните почему вы поставили такую северити.
Выбираете систему оценок и оцениваете найденные баги, в каких-то местах объясняете почему такая оценка.

Вы написали 6 строчек кода, тогда как можно написать 1 при инициализации драйвера (для implicit wait). И далее забыть об этих ожиданиях в своем тестовом коде, т.к ожидание будет включено при каждом поиске элемента.
Плюс к этому зачем писать свой метод, если уже есть готовый?

Пришла рассказать о своих небольших достижениях.

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

Всех желающих приглашаю поглядеть на мое "детище"!

Мое, сугубо личное мнение - делать еще один форум это не польза, а вред. Чем больше форумов, тем меньше на них людей и полезной информации.

Если честно, я не совсем понял как работают те методы, поэтому и написал свой

Там же написано как работает неочевидное (implicit) ожидание. Драйвер раз в 500мсек опрашивает модель и если элемент появился - возвращет его, если нет, то падает с exception по истечении времени ожидания. Поэтому, если у вас, например, 3 места - элемент А появляется через 5 сек, элемент Б через 2 сек, а элемент С есть сразу - то ставьте 5 и оно будет одинаково хорошо работать во всех трех случаях. При этом установка значения 5 надо сделать всего один раз и больше не трогать.

Единственно, если элемент Б или С не появлется вовсе, то драйвер будет ждать максимальное время.

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

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

Интересная идея, надо обдумать. Хотя она не отменяет прохождение по специфицированным (читай acceptance) сценариям. А тестирование сценариев, конечно же, не отменяет функционального тестирования.

Скорость написания в третьем случае иллюзорна - быстро будет написан первый тест(пока вилларибо пишет фреймворк, виллабаджо наклепала 3 теста), потом копипаст утянет в пучину.
Первый вариант кстати лично меня отталкивает лишь наличием приведения - из-за снижения читабельности и рассеивания внимания +)
Второй вариант конечно заманчив - но решительность при выборе в его пользу зависит от сложности системы в целом.
Я бы начал со второго варианта, но не слишком бы убивался пытаясь придерживаться его - написал бы некоторое кол-во разноплановых тестов, а потом бы уж точно определился со стилем. Да и вообще бы на первых порах написания фреймворка не советовал наращивать "критическую массу" тестов.

В первом варианте приведения вроде можно избежать, как сделать я придумал только вот сейчас отвечая на вопрос. Завтра попробую. Да и возникают они только после метода open общего для всех страниц. А метод используется редко сам по себе.
Ну и конечно его можно избежать, разбив на две строки. Такова уж неповоротливая джава.
И так и есть, пока есть представители всех 3х вариантов тестов. 3й я стараюсь переводить в первый. Второй экспериментальный, сделал на выходных и пока не советовался с программистами, насколько он им будет удобен. В том-то и дело, что он заманчивый (с точки зрения тестировщика), но есть некоторые моменты, которые меня смущают.

Всем привет!
Продублирую вопрос, заданный мной в фейсбуке (и твитере), т.к. здесь наверное более удобно обсудить различные точки зрения.

Пишу селениумные тесты. Скажите плз, какой из вариантов на ваш взгляд выглядит лучше и будет более удобен на практике (и для написания тестов и для их поддержки). Учтите, что тесты пишутся в среде, где все умеют так или иначе программировать.
=============
http://pastebin.com/Wc6K4z4K
=============
1) 1й вариант - то что есть сейчас. Требует компромисса между скоростью написания и читабельностью. Неплохо приспособлен к изменениям, но требует определенных затрат на это.
2) 2й вариант требует затрат на фреймворк, без выигрыша по скорости написания, но с превосходной читабельностью и замечательной реакцией на изменения.
3) 3й вариант - почти "сырой" - т.е. почти никакой не нужен фреймворк и достаточно быстрое написание тестов. Но никакая читабельность и солидные затраты на изменения.

----
На данный момент все подходы применимы, некоторые в экспериментальном варианте. Нужно выбрать. Прошу мнений.
Есть еще подвариант второго варианта
http://pastebin.com/kDf6e9xh

Вообще второй вариант задуман для отвязки проверок от используемого фрейворка (junit, testng etc) и ради возможности следить за тем, чтобы не было тестов без проверок и еще ради возможности найти все ошибки сразу, а не падать на первом же ассерте. Хотя при написание тестов и проверок требует больших затрат.

...

Спасибо за столь детальный анализ. На мой взгляд не хватает обобщенного вывода в конце, по которому можно было бы принять решение.
И конечно, данный анализ чрезмерно сложен для такой задачи. В качестве пояснения скажу, что весь код модифицируем так как этого хочется (в том числе и код приложения); а данные (например имена пользователей) заточены на специальное тестовое наполнение базы. В отличие от абстрактного ПО, рассчитанного на массового пользователя у этих тестов и фреймворка ограниченное и однозначное использование во вполне однозначных начальных условиях.

Что касается ваших примеров:
1. Изменились параметры корректного пользователя
Есть (или будут) такие тесты, которые это проверяют. Поэтому весьма штатная ситуация, предусмотренная реализацией типа User. Для всех трех вариантов тестов это не проблема. Наверное следует отметить, что в данном случае объект User - это не объект пользователя, зарегистрированного в системе, а некий тестовый субъект решивший зарегистрироваться или залогиниться в систему.

2. Изменилась форма логина: нужно ввести дополнительный код (инвайт)
Тут два подхода. Наиболее логичным, на мой взгляд, является изменение типа User, у которого помимо атрибутов "имя" и "пароль" будет еще и "инвайт", т.к. этот "инвайт" также является объектом для написания нескольких тестов.
Второй подход - это создание отдельного типа Invite, который в паре с пользователем будет передаваться в метод login. Можно написать два метода login(User u) и login(User u, Invite in), сохраняя неизменными те тесты, где нам неинтересно значение поля Invite. Очевидно, что первый укороченный вариант метода login будет только создавать внутри правильный Invite и вызывать второй метод, как это обычно и делается. Здесь третий вариант проигрывает, т.к. не имеет отдельного метода и возникнет необходимость менять все тесты на эту функциональность.

3. Изменилась проверка того, что пользователь успешно залогинился
Здесь вообще следует отметить, что на практике (при тестировании других объектов) зачастую возникает необходимость делать одинаковые проверки в разных тестах и логично при этом все такие проверки (asserts) выносятся в приватный метод внутри тестового класса. Поэтому, что в первом, что в 3м варианте все-равно будет метод checkIsLoggedIn, в который и надо будет внести изменения. Во втором варианте тестов этот метод принадлежит не тесту, а типу User.

По результатам общения и размышлений пришел к выводу, что надо реализовывать вариант №2.
Объясню почему.
1) Он дает возможность более просто писать тесты, оперирующие с разными наборами данных, но с примерно одинаковым алгоритмом действий.
2) Оперирует объектами бизнес логики приложения отдаляясь от конкретной реализации страниц. Страницы же отвечают за предоставление информации об элементах и их содержимом.
3) При реализации этого подхода, вариант №1 остается доступным.
4) Более просто проследить сценарии, описанные в спецификациях.
5) Позволяет более "чисто" писать именно сценарные тесты с несколькими проверками по ходу дела и оперирующими несколькими объектами (а не только пользователем, как в примере).
6) Даёт простую возможность переиспользовать методы объектов как предварительные акции и без всяких изменений. Надо только убрать методы "checkXXX".
7) Очень важно то, что он даёт возможность следить за тем, чтобы в методах был бы вызван хоть раз хоть один check, в отличие от стандартного unit теста, который будет пройден, даже если в нём нет ни одной проверки.
8) Позволяет использовать проверки неоднократно (не в рамках одного теста, а "шарить" их между разными тестовыми классами).
9) Позволяет проверить результат всех проверок (asserts) в тесте, в отличие от junit, где падение происходит на первой же проверке. Очень удобно при отладке тестов.
10) Позволяет делать негативные проверки без перехвата AssertError (или что там используется) в каждом тесте, где есть такая необходимость.

Что касается возможности вешать дополнительные asserts, то она ровно такая же как и в первом варианте.
Что касается сложности отладки или поиска неисправности во втором варианте - зависит от того как выдаётся информация при ошибке.
Что касается того, что все перевести на вариант №2 не получится, ну и ладно. Вариант №1 меня тоже устраивает, а вариант №3 при появлении будет переводиться в вариант №1 или №2. Вообще оптимальным при написании нового теста кажется такая последовательность: пишется тест в варианте №3 (можно опустить) и потом переделывается в №1, при появлении большего количества тестов на данную функциональность всё рефакторится к виду №2.

Походу можно новую тему открывать :) про уровни автоматизации тестирования :)

Только что обсуждали эти уровни с коллегами. Сошлись для начала на 3х (это для GUI тестирования только)
1) PreCommitTests - маленький набор, поддерживаемый в "зеленом" состоянии программистами и ими же используемый перед комитом.
2) ReqTests - набор тестов написанных по спеке, покрывающий как отдельные функциональные требования, так и описанные сценарии. Второе в будущем может трансформироваться в отдельный Acceptance Tests
3) OtherTests - тесты с разными наборами данных, негативные тесты (неописанные в спеке) и прочие тесты (например необходимые для воспроизведения дефекта и его верификации).

Если решим запускать в CI после каждого комита какие-то тесты, то вероятно появится еще поднабор, состоящий из 1 и части 2.
Понятно, что один тест может входить в несколько тестовых наборов.

№2 еще бы допилить, чтобы ассерты были только в одном тесте, ну и в идеале - один ассерт = один тест.

Зачем? Зачем я буду следовать синтетическому ограничению, которое в основном советуют люди, которые пишут книги, а не тесты?
Возможно (хотя я не верю) в "настоящих" юнит тестах такое ограничение имеет смысл. Но у меня же UI тесты имитирующие действия пользователя.

В моих тестах будет столько проверок, сколько требуется. Я буду проверять прекондишены перед запуском основного действия, например для уменьшении времени при неуспешном выполнении подготовительного действия. Более того, далее стоит задача покрывать сценарии, описанные в спеке, т.е. там сделал действие, проверил, сделал, проверил итд в одном тесте.
Или вот например:

.doLogout()
      .checkLoggedIn(false)
      .checkLoggedOut(true);

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

Честно говоря я большой непоклонник слепого следования сомнительным "бест практисам".

Только что обсуждали эти уровни с коллегами. Сошлись для начала на 3х (это для GUI тестирования только)
1) PreCommitTests - маленький набор, поддерживаемый в "зеленом" состоянии программистами и ими же используемый перед комитом.

Жутко интересно, как вы ограничили размер набора. Выбрали самое важное что укладывается в n минут? GUI тесты имеют свойство идти долго. Если не секрет, сколько идет этот зеленый набор?

Да никак пока не ограничили. Сейчас тесты идут порядка 3х минут ибо их не много еще. Добрая половина из них уедет в другие наборы, когда я наконец засетаплю все через хадсон. Программисты обычно не делают много комитов за день (имеется ввиду в интеграционное пространство) и пару раз запустить такой набор - не проблема, тем более, что это их инициатива изначально.

1. Если вам нравится визио или в нем хорошо выходит рисуйте в Visio! Но нужен инструмент для создания презентаций. Т.к. PowerPoint стоит денег (правда кого это в России волнует) я советую бесплатный libre office impress (http://www.libreoffice.org/download). Копируете картинку из визио, вставляете в слайд.
Учтите, на слайдах все должно быть крупным. Мелкие, детализированные диаграммы из визио могут стать абсолютно неразборчивыми и скучными.

2. Если вы выступаете первый раз - не надо никакого интерактива. Просто расскажите и ответьте на вопросы.

3. Я свои выступления на конференциях всегда и репетирую и "тестирую" на коллегах. Они дают дополнительную пищу для размышлений, находят опечатки итд. Очень полезно.

4. Если хотите сделать слайдкаст, то slideshare.net вам поможет. Регистрируетесь, загружаете слайды, загружаете звуковую дорожку доклада и синхронизируете слайды со звуком. Все очень просто. Потом можно поделиться с кем угодно.
Можно выложить отдельно звук и слайды, но это хуже. А еще хуже делают люди, неуважающие слушателей - они выкладывают на slideshare слайды и звук и не синхронизируют. Не делайте никогда так.

5. Если хотите провести вебинар, то подумайте ... и не делайте. Судя по всему опыта в этом деле у вас нет. Шансы на то, что получится сделать "живой" вебинар малы. Люди злые и если у вас будут накладки, то сделаете себе антирекламу. Запишите лучше для начала "оффлайн" презентацию со звуком. Разошлите знакомым. Анонсируйте тут на форуме.

И еще, а из какого вы города? Уже много где есть сообщества тестировщиков, можно договориться с организаторами и выступить на одной из встреч (если у вас в городе оно есть, а если нет - то кто мешает создать? Опытом создания готовы делиться). Лучше начинать с "живых" презентаций, когда видны глаза слушателей и есть обратная связь.