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

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

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

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

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

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

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

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

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

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

Да и кроме главного направления тестирования в каких еще направлениях смотреть - HTML, sql, Java? Я просматривал чужие резюме и заметил, что много чего мелькает, но что подучить, не сильно отвлекаясь от основной темы ТЕСТИРОВАНИЕ?

Одним из возможных преимуществ для работодателя может быть знание предметной области.

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

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

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

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

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

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

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

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

Попытайтесь неявное ожидание использовать:
Long timeout = 10;
driver.manage().timeouts().implicitlyWait(timeout, TimeUnit.SECONDS);

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

У меня есть 2 таймаута короткий и длинный. Длинный я использую только в определенных местах. А короткий - установлен по умолчанию. Т.е. после длинного ожиания я сбрасываю значение обратно в короткое ожидание, чтобы тесты быстрее падали в случае ошибки. В случае, если элемент есть сразу, то разницы нет никакой, driver делает опрос каждые 500мсек, пока не найдет или пока не вывалится по таймауту.

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

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

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

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

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

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

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

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

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

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

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

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

Здравствуйте, уважаемые форумчане!

Хочу узнать, что входит в понятие "знание Linux/*nix". Например, знание bash-a, уметь написать простой скрипт, знание базовых комманд, умение работать без графической оболочки (только с консолью), умение собрать программу и так далее.
Если можно, поделитесь мыслями с указанием "уровня" знания (знание простейших комманд - beginner level, написать скрипт - intermediate, пересобрать ядро - advanced).

Так же интересно какие таски в этой ОС чаще всего приходилось делать, расскажите о вашем опыте.

В конце хочу составить для себя эдакий список-чеклист того, что надо выучить.

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

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

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

А ядро вам не придется пересобирать (если вы конечно не выберете какой-нибудь gentoo). Людям которым нужно "ехать" это ни к чему, ну а тем кому "шашешчки"...

Могу книгу порекоммендовать - http://www.books.ru/...ruzhenie-82361/
До середины - маст рид.

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

Сомневаюсь :) Люди занимающиеся подбором персонала обычно, в лучшем случае, знают что линукс существует и как-то используется в компании.

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

Вот с этим могу поспорить. Убунта - УГ и вообще бажное УГ. И нервы попортить она как раз может больше чем другие дистры. Я предпочитаю openSuse.

3) Имхо, знание базовых команд не сильно отличается от умения написать скрипт для bash. Скрипт тоже может быть на "базовом" уровне. А вот поднабрать арсенал полезных утилит и опций можно только на практике: почитайте man даже по самым простым командам и убедитесь, что без опыта всё это множество опций освоить нереально.

Абсолютно точно, полностью поддерживаю этот комментарий. Хотите научиться - перебирайтесь на линукс и работайте в нем, если это не критично для тестируемого приложения (ну или пускайте его в виртуалке, если виндовое). Есть рецепт перелезания на линукс, которым я сам и воспольовался - сначала на виндах перейти на кросплатформенные продукты (мс офис - libre office, почтовик - thunderbird итд.) Единственно - нет замены Far-у (есть mc, но это отстой).

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

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

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

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

А какие конкретно у вас затруднения с баг-трекером?
На последней конференции я кое-что рассказывал по этой теме.
http://www.slideshar...haL/ss-10392275

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

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

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

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

По результатам общения и размышлений пришел к выводу, что надо реализовывать вариант №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 теста), потом копипаст утянет в пучину.
Первый вариант кстати лично меня отталкивает лишь наличием приведения - из-за снижения читабельности и рассеивания внимания +)
Второй вариант конечно заманчив - но решительность при выборе в его пользу зависит от сложности системы в целом.
Я бы начал со второго варианта, но не слишком бы убивался пытаясь придерживаться его - написал бы некоторое кол-во разноплановых тестов, а потом бы уж точно определился со стилем. Да и вообще бы на первых порах написания фреймворка не советовал наращивать "критическую массу" тестов.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Пример. Есть функция 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/).

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