Как стать автором
Обновить

Комментарии 7

Формальную верификацию в тестирование запишем?

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

Я бы уточнил, что именно физически полное тестирование невозможно. Учесть и предвидеть можно. Невозможно именно все это протестировать за сколько нибудь приемлемый временной отрезок.

Точнее — нецелесообразно.

Whitebox fuzzing, formal verification?

Очень спорно. Точнее, постулат в тестировании такой есть, но в этой статье аргументация этого постулата очень спорная.

Возьмем для примера первый пункт - "1️. Исчерпывающее тестирование невозможно"

Приводится утверждение: "Ну давайте предположим, что максимально в поле мы можем ввести только 3 символа. Даже и в этом случае количество комбинаций, если брать во внимание, что UTF-8 поддерживает 2,164,864 доступных символа"

В формулировке утверждения - "поле", "мы можем ввести", значит, речь идет про пользовательский интерфейс, правильно?

Если рассматривать не сферическое рабочее место пользователя в вакууме, а с обычное, с обычной рабочей станцией, монитором и клавиатурой - каким образом можно ввести эти 2.2 млн символов?

Кроме того, никто не отменял деление входящих значений на классы эквивалентности.

На сколько классов эквивалентности можно разделить 2 164 864 символов?

Статья об этом умалчивает.

В общем, число тестов в размере 10 145 929 857 329 004 544 притянуто за уши...

Возможно, расчет был в том, чтобы впечатлить читателя магией больших цифр)

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

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

Отлично. Кратко, четко, понятно.

Зарегистрируйтесь на Хабре , чтобы оставить комментарий

Публикации

Истории