@Sasha_Sereda
Здравствуйте. Хотелось бы сделать несколько замечаний, которые вам позволят еще больше сократить кол-во тестов в данном случае.
Замечание №1:
По классам эквивалентности: неправильное разделение увеличило вам кол-во тестов. Условно я бы разделил хотя бы следующим образом:
Valid price [124…800] - граничные значения для этого класса эквивалентности будут 124 и 800
Invalid price: все, что меньше 124 и все, что больше 800 - граничные значения для этого класса эквивалентности будут 123.99 и 800.01 (я предположил, что цены все-таки могут у вас быть не целыми числами. Если все-таки не могут быть таковыми, то ваши 123 и 801)
Alpha char: нечисловые символы - здесь я, конечно, упростил: не будем привязываться, например, к кодам символов и локалям, тем более, что тот же разделитель целой и дробной части не являетя числом, а так же может быть как точкой, так и запятой. Так что для этого класса возьмем любой буквенный символ.
Так что 125 и 799 не имеют значения, т.к. они входят в класс Valid price
Если хотите взять промежуточное значение из класса Valid price, то хватит одного представителя. Для этого класса границами являются 124 и 800, так что если цены могут быть дробными числами, то я бы взял дробную цену. Например, книга стоит 500.67 (если не поддерживаем дробные цены, то возьмем любую книгу с ценой в промежутке, например, ваши 579)
Итак, на данном этапе получилось, что уже выбросили 3 лишних значения для составления пар значений:
Type: hard, soft
Price: 124, 800, 500.67, 123.99, 800.01, f
Size: 11x11, 11x8.5, 12x14, 15x11, 17.5x12, 20x18, 22x24, 6x6, 8x11, 8x6, 8x8
В этом случае количесво тестов уменьшается до 66
Замечание №2
Не рекомендуется включать негативные тесты в таблицу составления пар. Негативными тестами вы проверяете реакцию системы на неожидаемый ввод (для этого все-таки предназначены негативные функциональные тесты ) и по сути вы в каждом таком кейсе проверяете только один параметр - неожидаемый. А попарное тестирование должно применяться в случае необходимости проверки взаимодействующих значений и реакции системы на это взаимодействие. Т.к. с негативным вводом система и остальные данные взаимодействовать не должны, что должны выявить ранее проведенные функциональные тесты, то и включение этих значений для составления пар не имеет смысла.
В итоге, можно сократить еще на 3 значения, исключив два негативных класса эквивалентности (Invalid price и Alpha char в этом случае)
Type: hard, soft
Price: 124, 800, 500.67
Size: 11x11, 11x8.5, 12x14, 15x11, 17.5x12, 20x18, 22x24, 6x6, 8x11, 8x6, 8x8
В этом случае количесво тестов уменьшается до 33 (+ 3 для тестирования Invalid price и Alpha char)
Замечание №3
Исходя из 2-го: так же попарное тестирование не призвано тестировать и граничные значения - для этого должны быть отдельные тесты. Так что условно для попарного тестирования price можно разделить на valid и invalid. И для тестов использовать только valid значения (несколько реальных цен для книг)
Получается, что можно выкинуть еще 2 значения - граничные
Type: hard, soft
Price: valid (several valid book prices)
Size: 11x11, 11x8.5, 12x14, 15x11, 17.5x12, 20x18, 22x24, 6x6, 8x11, 8x6, 8x8
В этом случае количество тестов уменьшается до 22 (+ 5 для тестирования позитивных граничных значений, Invalid price и Alpha char)
testomat.io управление авто тестами
