Сообщений в теме: 68

[ryjii]

Я правильно понимаю, что есть всего три класса эквивалентности при тестировании чисел:

 

 

1. заданный по требованиям интервал;

2. всё, что меньше левой границы интервала;

3. всё, что больше правой границы интервала.

И границы отдельно тестировать не надо, это лишняя трата времени?

Есть тестирование классов эквивалентности и  граничных условий.

Эти две техники всегда идут рука об руку, хотя формально являются двумя разными техниками.

Так вот, давайте начнём с классов эквивалентности. В условиях задачи их три:

1. Допустимые значения. В математической нотации [1,10]

2. Недопустимые ниже минимального. (-infinity, 1) либо (-infinity, 0], как вам больше нравится.

3. Недопустимые выше максимального. (10, infinity)

 

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

 

С точки зрения граничных условий, мы должны проверить 1 и 10. Это граничные условия для набора допустимых значений (а не 2 и 9, как вы написали).

Также мы можем проверить 0 и 11, как граничные условия 1 и 3 классов соответственно.

 

А вообще, конечно, техника классов эквивалентности сильна в теории, на практике её не применяет почти никто. В том плане, чтобы применять осознанно, обоснованно и правильно. Я уже не раз советовал на этом форуме новую книгу Канера Domain Testing Workbook, в ней как раз отлично разбирается, как применять это на практике.

[ch_ip]

ryjii, you made my evening!

И я пока ничего не писал про 2 и 9

[ryjii]

Виноват, перепутал вас с Сергеем Петровым.

Кстати, сегодня на свежую голову посмотрел свой предыдущий пост, упущен ещё интересный момент.

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

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

[vmaximv]

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

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

А вы знаете, какая цель преследуется этими тремя кейсами?
допустим, кейс 1+5 не работает. Тогда второй кейс будет точно содержать слагаемое "2".

Бисекция, заложенная в тесткейсы... Вряд ли кто-то так поступает. Вот для инвестигации - это ок.
 

Потому что мне неясно, зачем нужен кейс 10+1.

Что бы покрыть верхнюю и нижнюю границу первого и второго слагаемого соответственно. Если у вас есть другие варианты, будет интересно почитать.

[vmaximv]

Есть тестирование классов эквивалентности и  граничных условий.

Я не хочу вас расстраивать, но... Любое закрытое множество может быть разбито как минимум на два класса эквивалентности - множество граничных точек и множество внутренних точек.

[wret]

Развели спор, все же вроде ясно:

1. 1 + rnd(2,9) граничное условие, уменьшить пестицид, проверка основного функционала
2. 10 + 1 оба граничных условия, переполнение
3. rnd(2,9) + 10 граничное условие, переполнение, уменьшить пестицид

Хорошо бы разнести на 4 случая, чтобы программисту проще было поправить возможный баг во втором кейсе выше:

1. 1 + rnd(2,9)
2. 10 + rnd(2,9)
3.  rnd(2,9) + 1
4.  rnd(2,9) + 10

[ryjii]

 

Есть тестирование классов эквивалентности и  граничных условий.

Я не хочу вас расстраивать, но... Любое закрытое множество может быть разбито как минимум на два класса эквивалентности - множество граничных точек и множество внутренних точек.

 

Хм, то есть вы утверждаете, что в любой реализации программы из первого поста 1 и 10 ведут себя одинаково, 2-9 тоже, но не так же, как 1 и 10?

Это мне кажется необоснованным предположением.

 

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

[vmaximv]

Разбитие на классы эквивалентности должно происходить с точки зрения

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

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

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

[ryjii]

Разбитие на классы эквивалентности должно происходить с точки зрения

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

Это верно с точки зрения опыта тестировщика в аналогичных проектах. Просто когда нам урезают количество тестов до 3х, особой возможности разгуляться с вариантами нет. Если бы она была, я бы обязательно проверял кейсы с суммой меньше 10, ровно 10, строго от 10 до 20, ровно 20. К сожалению, это уже 4 теста.
 

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

С этим соглашусь. Просто граничные условия именно в виде такого термина более понятны, чем "класс эквивалентности: граничное значение"

[BadMF]

1) 0+1

2) 10+11

3) 1+10

[ch_ip]

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

[wret]

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

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

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

[ch_ip]

На мой взгляд в топике пока нет правильного варианта. Сами варианты без их объяснения тоже бесполезны.

[BadMF]

На мой взгляд в топике пока нет правильного варианта. Сами варианты без их объяснения тоже бесполезны.

 

1) 0+1

потому что негативное граничащее значение 0 

2) 10+11

потому что негативное граничащее значение 11

3) 1+10

потому что позитивные граничащие значения 1 и 10.

 

тут собстно и думать то особо нет смысла, элементарная задача на понимание граничных условий и отсутствия выдумывания несуществующих требований типа "дробноотрицательныхсимволов"

[wret]

 

На мой взгляд в топике пока нет правильного варианта. Сами варианты без их объяснения тоже бесполезны.

 

1) 0+1

потому что негативное граничащее значение 0 

2) 10+11

потому что негативное граничащее значение 11

3) 1+10

потому что позитивные граничащие значения 1 и 10.

 

тут собстно и думать то особо нет смысла, элементарная задача на понимание граничных условий и отсутствия выдумывания несуществующих требований типа "дробноотрицательныхсимволов"

 

Ну тут скорее имеют ввиду не калькулятор, а некий сумматор, на котором нет клавиши 0, и нельзя два раза ввести единицу (11), а есть клавиша 10

[vmaximv]

Да даже если и есть: стоит ли проводить негативные тесты жертвуя тестированием основного функционала в условиях жесткого цейтнота?

[BadMF]

Да даже если и есть: стоит ли проводить негативные тесты жертвуя тестированием основного функционала в условиях жесткого цейтнота?

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

 

 

 

Ну тут скорее имеют ввиду не калькулятор, а некий сумматор, на котором нет клавиши 0, и нельзя два раза ввести единицу (11), а есть клавиша 10

откуда в вас эта уверенность? я из первоначального задания этого не понял (весь флейм не читал)

[vmaximv]

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

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

public mytype3 sum(mytype1 s1, mytype2 s2){
  return 11;
}

[wret]

 

Ну тут скорее имеют ввиду не калькулятор, а некий сумматор, на котором нет клавиши 0, и нельзя два раза ввести единицу (11), а есть клавиша 10

откуда в вас эта уверенность? я из первоначального задания этого не понял (весь флейм не читал)

 

> условии ввода только целых чисел от одного до десяти 

Чисел от 1 до 10, не цифр от 0 до 9

[BadMF]

 

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

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

public mytype3 sum(mytype1 s1, mytype2 s2){
  return 11;
}

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

 

ваш пример явно некорректен, потому как было ещё как минимум 2 теста которые не могли вернуть 11.

хотите выдумывать несуществующие проблемы, ваше право.