Сегодня в долгожданной рубрике «Матчасть» продолжим разбирать техники тест-дизайна и, как и обещали в прошлом выпуске, поговорим про подход к проектированию тест-кейсов под названием «Анализ граничных значений». #куатулерн Когда разработчик пишет логику обработки данных, самое интересное происходит не в «обычном» русле работы приложения, а в его «переходных процессах», когда коду внутри приложения нужно принимать решения или переключать ветки логики работы. Аналогичная ситуация происходит и с данными, с которыми работает приложение. Ошибки чаще всего появляются на границах разных диапазонов данных, а не в их «середине». Именно поэтому технику классов эквивалентности чаще всего дополняет техника «Анализ граничных значений». По статистике, до 70% ошибок, связанных с вводом данных, возникает именно на границах. А всё потому, что в коде могут таиться ошибки неправильного сравнения (например, знак >= вместо > или же = вместо >=), ошибки округления, особенности типов данных и их преобразований. Если максимально просто — смысл этой техники состоит в том, что мы по очереди берем каждую границу диапазонов и составляем тесты для проверки следующих значений: Значение самой границы Значение, максимально близкое «сверху» к границе Значение, максимально близкое «снизу» к границе. Но тут есть крайне важный нюанс, про который забывают неопытные тестировщики! Единственным правильным способом применить технику анализа граничных значений является понимание, какой у нас «минимальный шаг изменения» значения, которое мы тестируем. Неправильно выбранный шаг приводит к тому, что нужные условия не проверяются и баги продолжают жить в коде так и не обнаруженными. В большинстве примеров речь идет про границу и значения +1 и -1 для нее. Однако во многих случаях это неправильно. Например: Для операций с процентами числа минимальный диапазон изменения может быть 0.01, т.е. когда мы тестируем границу 100, то нужно еще проверить 99,99 и 100,01% Для временных значений часто важна 1 мс (миллисекунда) или еще меньше, т.е. если какая-то операция должна длится «не более 10 секунд» — обязательно проверяем 9 сек. 999 мс. и 10 сек. 1 мс. Для координат, точных математических или физических расчётов «цена деления» может быть 0.0001 или меньше! Т.е. вполне реальна ситуация, когда вместе с границей в 1 нужно проверить значения 0,999999999999 и 1,00000000000001 Уверены, что теперь вы знаете чуть больше про проектирование тестов! В нашей практике, мы обязательно закладываем время в оценке трудоемкости наших работ для того чтобы провести качественный тест дизайн и проектирование тестов. Такой подход позволяет заранее спланировать все нужные проверки, чтобы ничего не пропустить. Это основа для системной и качественной проверки любого приложения.