Home

Автор: Майкл Болтон (Michael Bolton)
Оригинал статьи
Перевод: Ольга Алифанова

Эта статья начиналась, как пост, отвечающий на этот опрос:

Поле ввода принимает годы рождения между 1900 и 2004. Каковы граничные значения для этого поля?

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

Вот как мы определяем «границу» в Rapid Software Testing:

«Средство для классификации или фильтрации чего-либо».

Это означает, что граница может быть точкой деления между двумя смежными регионами поведения или данных. Второй вариант выражается широко распространенным термином «граничное значение», но давайте не сводить анализ и тестирование границ только к данным. Другие элементы граничного поведения могут включать:

• Принцип, согласно которому что-то распределяется по категориям или хранилищам
• Интерфейс, предоставляющий функцию «выборки», дающую нам подмножество какого-либо множества
• Наиболее раннее или позднее возможное время выполнения процесса
• Точка, в которой процесс блокирует что-то иное.

Можно привести множество других примеров, попробуйте сами.

Учитывая это, ни один из предложенных в вопросе вариантов ответов – не граничные значения для тестирования этого поля. Это граничные значения, которые можно ассоциировать с данным описанием.

В чем разница?

А вот в чем: описание – это одно, а реальное поведение продукта – совершенно другое.

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

Вот как мы описываем граничное тестирование в Rapid Software Testing:

Тестирование, сконцентрированное на связанном с границами риске.

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

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

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

К примеру, возможно, «2004» - часть более крупного набора граничных значений; возможно, даты позднее 30 июня 2004 года должны отвергаться, а даты до и включительно – приниматься. Я пишу эту статью 1 июля 2023 года, а 30 июня 2004 было 19 лет и один день назад. Важен 2004 год, или «19 лет назад»? Это граничное значение (и «правильный ответ») могут со временем меняться.

Как внедрено это поле ввода? Как раскрывающийся список? Если это так, 1899 или 2005 могут быть в принципе недоступны в качестве возможных для выбора. Реализовано ли поле как текстовое или комбо-бокс, позволяющий как вводить значение от руки, так и выбирать из списка? Если это так, возможно, существуют границы по длине ввода. Возможно, при вводе менее чем 3 цифр или более чем 4 возникает странное поведение или плохая обработка ошибок.

Может существовать граница между 2004 и 2005. Есть ли потенциальная граница между 2004 и 2004.00000001?

Возможно, продукт не может обработать границу между 0 и -1, или между «тем, что является числом и тем, что им не является». К примеру, в Ruby есть функция to_i, конвертирующая строки (вроде «143» или «-2») в числа (143 и -2). Эта функция делает две удивительные вещи. Во-первых, получая строку вроде «3.9», функция обрезает число, а не округляет его. Во-вторых, получая строку, не соответствующую сравнениям с паттернами функции, она не возвращает ошибку или исключение – она возвращает 0!

Несколько десятилетий назад существовала знаменитая значимая граница между 1999 и 2000. Помните? Нам грозит еще одна в начале 2038: Эпохалипсис.

Фильтруется ли ввод для нашего поля, ограничен ли он чем-нибудь – например, только цифрами? Где применяются ограничения ввода? На фронтэнде? Можно ли избежать этих ограничений, обойдя браузер и отправляя запрос на бэк напрямую? Проводит ли бэкэнд валидацию данных и проверку ошибок?

Возможно, проверка ошибок и обработка исключений правильно обращаются со значениями определенного содержания или длины, но отказывают, если перегружены (я только что наблюдал именно такую ситуацию – приложение для заметок Google Keep ловко управлялось с датами до 275760 года, сохраняя их, но любой более поздний год заставлял дату и время отображаться и сохраняться, как “NaN Nan, 12:00NaN AM”. Однако, согласно моим заметкам, раньше последним годом перед появлением NaN-эффекта был 275749, поэтому тут должны быть задействованы иные переменные.

Граница вроде бы между 275760 и 275761… но так ли это?

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

Возможны границы, ориентированные на время. В этом году граница между 1902 и 1903 может быть значимой, если система обрабатывает разницу между «век назад» и «сегодня», используя для хранения или отображения только две цифры. Могут быть временные границы – ответ должен быть дан в течение определенного времени или не слишком рано.

И так далее.

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

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

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

Обсудить в форуме