Судя по описанию у вас и вправду используется JUnit 3.x
Там есть класс TestSuite:
http://www.junit.org.../TestSuite.html
Там есть пример как его наполнять. Также можно создавать разные наборы и включать одни наборы в другие. Беда этого подхода (так же как и того, который тут писали) - это статическое перечисление классов с тестами. Т.е. если вы напишите новый класс, то его надо будет добавить в какой-нибудь набор явным образом.

Чтобы этого избежать могу предложить 2 варианта.
1) Напишите ant скрипт. Стандартная таска junit умеет находить все тесты по маске начиная от единого корневого каталога.
2) Напишите свой класс, реализующий динамический поиск тестовых классов, например DynamicTestSuite, который отнаследуйте от стандартного TestSuite. Вызывайте его прямо из IDE.
Для поиска всех классов надо написать некоторые методы самостоятельно ибо такой богатый язык как джава не предоставляет такой возможности. Я у себя применил именно такой подход и воспользовался кодом, приведённом тут: http://stackoverflow...rationtest-in-m
Только метод не работает как там написано и надо в нем что-то поменять по мелочи. Исключить иннер-классы итд.

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

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

А тоже самое, но для вебдрайвера?

Я бы для вебдрайвера сделал через EventFiringWebDriver используя методы beforeOnclick и afterOnClick, которые вызываются последовательно, а данные о странице можно получить прямо там, т.к. одним из параметров методов является объект WebDriver-а.
Это позволит не делать специальных тестов вообще и при этом регистрировать время ожидания каждой загрузки страницы. Что, в свою очередь, даст возможность собирать статистику как для разных страниц, так и для одной и той же страницы в зависимости от её наполнения и условий проводимого эксперимента.

По результатам общения и размышлений пришел к выводу, что надо реализовывать вариант №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.

...

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

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

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

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

Денег никому не надо, я так помнимаю? =))

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

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

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

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

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

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

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

Если у кого-то есть опыт тестирования файловой системы, поделитесь пожалуйста.
Интересует подход к тестированию (что именно вы тестировали, как тестировали, какие tools использовали).
Может есть чек-лист того, что проверяли?
Какие были трудности, нюансы? В общем, инетересует любая информация ))
Спасибо!

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

Вообще, файловую систему никто с чеклистами тестировать не будет. Пишут много-много-много автотестов.

Андрей, поздравляю! Я был поражен твоим мастер классом. Молодец! За 20 минут и рассказать и показать и почти без фейлов (косяк с регистром - не в счет, наоборот, показывает умение быстро понять в чем суть проблемы и как это сделать).

Также поздравляю Сергея. Ничего не имею против того, что он получает приз.
Единственно, что хочется отметить, что письмо с просьбой проголосовать за самого активного участника я получил сегодня в 16-48, а прочитал его в только сейчас в районе 22-00. Но новость о победители уже опубликована в 17-42.

Организаторам мое мнение не интересно, но я голосую за DSM (простите, не знаю ни имени ни фамилии).

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

Полное название "Agile Testing: A Practical Guide for Testers and Agile Teams"

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

Я знаю точно, невозможное возможно...

При этих словах просто необходимо давать ссылку

Вопрос в том есть ли нужда у других тестировщиков знать что-то о кодировках?
Если есть то может что-то конкретное можете сказать?

Артем, отличная идея! Конечно, интересно знать про кодировки, чем больше, тем лучше.
Мне все интересно, особенно, если упорядочено, логично, можно хоть от истоков начинать. ASCI, Unicode, разница кириллическх кодировок. нструменты по преобразованию, как тестировать. Редкие и специальне кодировки, про которые стоит знать тестировщикам.
В общем, пишите, будет полезно!

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

Тоже хочу кружку! так и запишите +1

И еще покажите мне, плиз, кнопочку "Напечатать программу конференции", чтобы она так красиво сразу и на принтер ушла.

Программу в данный момент печатать еще рано. Для печати будет сделана специальная версия, скорее всего в PDF формате. По крайней мере сейчас планируется сделать именно так.

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

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

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

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

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

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

Страницы не существует..

Вас не смущает, что прошло 8 лет?

Нахожусь в поиске удобного и, возможно, наиболее популярного free xml reader, в котором есть возможность поиска по xml файлу.

Кто что может посоветовать?

Web-браузеры умеют. Любой текстовый редактор, обычно и синтаксис подсвечивают.
IDE имеют неплохие возможности для редактирования и валидации.

Что не так с параллельностью в Руби?

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

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

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

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

Вопрос актуальный в контексте собеседования тестировщика.
Я придерживаюсь такой позиции, что не важно как называть эти вещи, главное, чтобы человек умел их применять.
Но иногда сталкиваюсь с ситуацией, когда нужно просто знать точное определение.
Какой, например, должен быть ответ на вопрос "Перечислите методы тестирования, которые вы знаете?"
На сколько я понимаю, методы - это более широкое понятие. Типа метод "белого" и "черного ящика". Техники - это подходы в рамках какого-то метода. Типа Equivalence partitioning и Boundary-value analysis. Технологии - просто слово из рефератов и резюме.
Поправьте, если я ошибаюсь.

Похожего вопроса касались вот тут: http://software-test...9272#entry49272

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

Ты много здесь видел представителей компаний-работодателей?

Еще хотел спросить, входит ли в обязанности тестировщика исправление ошибки, на уровне исходников программы, в моем случае или это зависит от организации и предъявляемым требованиям?

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

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

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

если вводишь верно имя, фамилию и дату рожд. НЕуникального пользователя (Петров Петр 03.03.1993) программа выдает ERROR

По мне так это ошибка в программе - должно логинить

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

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

Только я вот не пойму, почему на всех емейл сервисах, которые я нашел, нет подчинения этим стандартам. По-че-му? Может плохо искал? Могу предположить, что уменьшение количества символов в логине сделано для оптимизации размеров баз данных. А символы причем? Может следует изменить эти стандарты? Как же тогда производить тестирование или даже как кодировать? Выбрать самый требовательный к адресам сервис и по нему ориентироваться? И я так понимаю, что если какая-то форма не пропускает некоторые валидные емейлы из-за недопустимости адреса, то это не баг?

Интересно, сколько раз надо написать одно и тоже...
RFC - стандарт. Если вы пишете почтовый сервер - будьте добры, соблюдать все это.
Если ваша веб-програмулька не понимает всех возможных вариантов почтовых адресов - то это ХОРОШО!
В этом случае ваша программа не протеворечит этому стандарту. Но в ней будет меньше кода, и меньше ошибок, от исправления которых не станет лучше ни одному живому существу на планете.

Да и это нафиг никому не нужно, поддерживать все эти возможные адреса. И если найдется идиот с ненормальным адресом в 64 символа (или сколько их там) на домене второго уровня - то пусть он идет лесом мимо вашей программы со своим адресом.

Если вы не тестируете почтовый сервер (ну и возможно клиент тоже) - то использование всяких экзотических емэйлов - (а) трата времени и (б) создание ненужных записей в трэкере. Если бы я был программистом и ко мне бы пришли и сказали "first.(")middle.last(")@[IPv6:::12.34.56.78]" - не работает, согласно RFC, давай чинить. Я бы послал куда подальше.

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

PS: кстати [IPv6:::12.34.56.78] - нихрена невалидный Ipv6 адрес - очередной булшит