Типы границ для классов эквивалентности

Про типы границ я впервые услышала на тренинге Алексея Баранцева. Зачем они нужны? Да просто чтобы не забыть всё проверить. Написал чек-лист, потом проверяешь себя:

— Все учел? Вот эти классы эквивалентности, какие границы логические? А какие технологические? …

Так можно вспомнить о проверке, про которую забыл или просто не подумал! Полезная штука.

Алексей дал нам тогда про такую типизацию границ:

• Физическая — которую физически нельзя преодолеть.

• Логическая — ограничение, накладываемое логикой, не программой.

• Технологическая — ограничение, накладываемое используемой технологией.

• Произвольная — ограничение, наложенное аналитиком или заказчиком.

Лично я предпочитаю совмещать физическую и логическую. Потому что физическая — это то, что мы вообще преодолеть не можем. Например, при всем желании мы не введем строку отрицательной длины, ну никак не сможем.

Но то, что физически сделать нельзя, часто в программе сделать можно. Например, ввести в количество участников митапа «1,5 человека» — физически невозможно, но программа то позволяет. Значит, для программы это уже логическая, мы же понимаем, что это невозможно.

Так что в моей классификации есть всего три типа границ (сокращенно ЛТП):

1. Логическая — ограничение, накладываемое логикой, не программой.

2. Технологическая — ограничение, накладываемое используемой технологией.

3. Произвольная — ограничение, накладываемое аналитиком или разработчиком.

 Рассмотрим каждую из них:

Логическая граница

 

Логическая граница — ограничение, накладываемое логикой, не программой. Это те аксиомы, которые мы знаем с детства. Или физические ограничения реального мира. Например, «1,5 человека»: в программе ввести такое можно, но логично, что это бред и так не бывает.

Самые важные и базовые границы:

• Ноль — проверяем всегда и везде!

• Один — а вот это неочевидно бывает, обычно только ноль смотрят, а есть еще разница «один-много».

Эти границы надо смотреть всегда. А какие бывают другие? Посмотрим на примерах:

 

1. В минуте 60 секунд

Даже если система дает ввести больше, мы все равно проверяем 60.

Допустим, разработчик поставил ограничение на поле ввода секунд — можно ввести максимум 2 числовых символа. У нас получаются интервалы:

• 0 — 60

• 60 — 99

При этом 0 и 60 — логические границы. Логично, что время НЕ может быть отрицательным (в физическом мире ну никак, даже если программа позволяет ввести такое значение). Также логично, что секунд будет максимум 60, иначе это уже следующая минута.

Что делает интервал «60 — 99» очень интересным для проверки: что будет, если я введу 70 секунд? Система пересчитает это как 1 минуту и 10 секунд? В любом случае это уже разные классы эквивалентности: «нормальное количество секунд» и «больше, чем минута». Проверяем оба + границу между ними.

А вот в числе 99 никакой логики нет. Ее просто такой сделал разработчик. Завтра он передумает и сделает границу в 999 — и что, изменится логика? Нет. Логика от прихоти разработчика не меняется. Какое бы ограничение он не поставил, у нас остаются границы 0 и 60. А вот 99 — это сплошной произвол, к логике отношения не имеет.

 

2. Строки отрицательной длины не бывает

Если у нас есть строковое поле, то самая очевидная граница — ноль. Логично, что символов всегда будет больше нуля, меньше мы ну никак ввести не сможем. Поэтому всегда проверяем:

• Пустое поле (ноль) — логическую границу.

• Один символ (один) — пограничное значение.

• Один пробел — это не то же самое, что один любой символ, поэтому рекомендую проверить.

Даже если разработчик ставит ограничение «имя может быть от 3 до 10 символов», это не отменяет границу в нуле и мы ее все равно проверяем. А потом уже смотрим границы по ТЗ.

 

3. Количество книг или платьев в заказе — положительное целое число

Если мы тестируем интернет-магазин, то добавляем что-то в корзину: платье, пиццу, книжку, пару обуви. И количество товара всегда будет целым положительным числом. То есть 2 логических границы:

• 0 — мы не можем заказать «минус одно платье»;

• Целое число — мы не можем заказать дробное.

Конечно, с нулем проще: мы знаем границу, знаем пограничные значения (-1 и 1), понимаем классы эквивалентности (до нуля и после).

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

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

 

4. Возраст — тоже положительное число

Отрицательного возраста быть не может — это логично. Когда человек рождается, то ему уже 0 лет, 0 минут, сколько-то секунд. Когда он ещё в животике, это тоже не «минус 5 месяцев ему» — это «3 месяца беременности мамы».

Дробное значение у возраста бывает — «1.5 годика», например. А вот отрицательное — нет.

 

Итого!

Запомните правило — логика от прихоти разработчика НЕ меняется.

Если разработчик изменил в программе значение и граница поменялась — значит, она была НЕ логическая. А чтобы найти логическую, включаем мозг и думаем: а каким бывает (или не бывает) наше поле? Абстрагируясь от того, что написано ТЗ. ТЗ у нас пойдет отдельно.

Логика может разделять разные классы (дробное / целое число), а может быть конкретным значением. И если вы нашли число, то всегда проверяйте:

• Ноль — не ноль

• Один — много. 

Технологическая граница

 

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

Например, при попытке запихать в integer больше, чем 2 147 483 647. И так как перфокарты уже давно в прошлом, то сейчас поиск технологической границы — это попытка вставить МНОГО данных в поле. 

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

• Нажать «9» и держать — чтобы получилось «9999999999999999999999999999…» И так сколько влезет.

• Использовать специальные инструменты, например, Perlclip.

См также:

Как сгенерить большую строку, инструменты + помощь ИИ, разумеется

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

И кстати, если в поле нельзя ВВЕСТИ с клавиатуры что-то, это еще не значит, что «плохое» значение туда нельзя ВКОПИПАСТИТЬ. Обязательно пробуйте.

А если говорить про ограничение на длину поля, так это вообще обычно простейший maxlengh, который легко обходится.

Ладно, хватит теории, посмотрим на примерах.

• Типы полей в БД — максимальное число, которое можно туда сохранить или длина поля (в оракл для строки это 5000 символов). При тестировании самой БД это произвол, а теперь это ограничение технологии.

• Путь к файлу — операционная система указывает допустимость символов или длину пути.

• Доступность ресурсов — ограничения ОС тоже, максимальное количество файлов, которые можно открыть. Или номера портов. Максимум — 65535. Портов с более высокими номера не существует.

• БД — количество открытых соединений к ней.

 

1. Числовое поле

Возьмем ТЗ «максимальный возраст участника — 18 лет». Позитивный интервал: 0 — 18. Но является ли «18» технологической границей? Конечно, нет!

Технологическую границу мы ищем «далеко-далеко». Надо попробовать вставить 100 миллионов девяток. Если вставилось, не упало — ну и ладно, границу не нашли. Зато искали!

Бывает важно поискать границу с обеих сторон от нуля. Как «плюс очень много», так и «минус»:

а. Диапазон (-infinity,0) может содержать технологические границы. Контрольный вопрос — верно ли, что если ввести отрицательное значение, состоящее из 5000 девяток, поведение будет такое же, как если ввести -1? А если ввести отрицательное значение, состоящее из 100 000 000 девяток, останется ли поведение таким же?

б. Диапазон (18, infinity) может содержать технологические границы. Контрольный вопрос — верно ли, что если ввести значение, состоящее из 5000 девяток, поведение будет такое же, как если ввести 101? А если ввести значение, состоящее из 100 000 000 девяток, останется ли поведение таким же?

 

2. Строковое поле

Например, формочка ввода имени. Как тут найти технологическую границу, и вообще какую-то другую границу? Правильно, хоть числа тут и нет, мы его ищем. И находим — длина поля.

Для поиска технологической границы пробуем вставить в поле 100 миллионов девяток или любых других символов.  Ничего нового.

Самый яркий пример такой границы — это когда мои студенты тестировали подсказки по организациям и умудрились их повесить. Для этого они просто вставили туда стихотворение Пушкина, и вуаля:

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

Причина простая — поиск работал по каждому слову по условию OR. То есть поисковый механизм искал в справочнике по условию «Слушай, у тебя есть слово 1 ИЛИ слово 2 ИЛИ слово 3 ИЛИ слово 4…?». При этом ограничение сверху не поставили, вот механизму и поплохело.

При этом обратите внимание — если бы ребята вставили не «реальный» текст, а строку из 100 млн одинаковых символов, они бы баг не нашли. Без пробелов это просто одно слово, пусть и длинное, на него подсказок нет, но сервер при этом не виснет.

Поэтому при поиске технологической границы используйте не только одну огромную строку, но и более-менее разумный текст!

 

3. Граница в бассейне (Байка из жизни)

В 17 лет я работала тестировщиком игр для мобильных приложений. В те времена еще не было айпадов, айфонов и андроидов. Да и про тестирование мы мало знали. У нас был старший тестировщик, который подсказывал, на что обращать внимание во время игры. О существовании специальных книг и курсов я узнала года через четыре… Классы эквивалентности? Границы? Не, не слышали.

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

И тут наш старший тестировщик Антон громко заявляет на весь офис:

— Ха-ха! Я зависание нашел! Вы чем тут занимались раньше, что не видели? (зависание — это критичный баг!)

— Как? Где?

— Да на постройке бассейна.

Вся «мелюзга» (junior-чики, я в том числе) тут же подбежали к нему смотреть, как «батька» будет телефон вешать. Антон показывает: он ставит первый квадратик бассейна, а второй уводит далеко-далеко. То есть он просто зажал кнопку «вверх» и мы смотрели, как курсор убегал наверх, а бассейн становился все больше и больше.

И вот Антон отпускает кнопку: бассейн должен построиться по двум точкам, диагонали бассейна. Но… Телефон зависает, причем с концами — чтобы его перезагрузить, приходится доставать аккумулятор. Это самое крутое зависание, когда даже кнопка выключения не отрабатывает.

Я тогда долго ходила под впечатлением. Пострадала моя гордость — почему я не нашла зависание, а он нашел??? Непорядок! Зато эта история врезалась в память, и я помню ее до сих пор (а ведь прошло почти 20 лет!).

Тогда я впервые столкнулась с технологической границей, но ещё не знала, как это называется. Просто запомнила схему шагов, которые могут привести к ошибке. А по сути это ограничение технологии, слишком сильно нагрузили телефон, не смог отрисовать результат.

Как можно было бы найти этот баг самой, зная о границах? Ведь казалось бы, это зоопарк! Там ходят люди, бегают и плавают зверушки. Нет никаких полей для ввода. Но это не мешает нам найти число:

• Длина бассейна.

• Ширина бассейна.

• Площадь бассейна (не просто большая длина ИЛИ ширина, а и то, и другое сразу).

• Количество зверей внутри бассейна.

С каждым числом можно поиграться. Проще всего, конечно, сначала скомбинировать первые пункты и проверить сразу большую площадь. Потом посмотреть по отдельности. А если ширина минимальная (одна клеточка), а длина — уууууу? А что, если размер бассейна минимальный, но живности туда напихано с десяток штук? Или даже больше? Так и ищем границы, а потом пытаемся их преодолеть.

Но технологические границы в мобильных приложениях — до сих пор очень актуальная тема. И всегда надо проверять. Особенно если мы уже нагрузили наш телефон сторонними программами и памяти у него минимум, а мы в игрушке делаем что-то большое-большое. Что случится? Упадет или осилит?

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

Произвольная граница

 

Произвольная — ограничение, накладываемое аналитиком или разработчиком. От технологии не зависит, логики в нем нет, просто «я так сказал». Это те границы, которые прописаны в ТЗ.

Посмотрим на примерах.

 

1. Числовое поле

Вспомним наш пример «максимальный возраст участника — 18 лет». Мы уже выяснили, что позитивный интервал: 0 — 18.

• 0 — логическая граница, ее даже не обязательно писать к ТЗ, но мы про нее помним.

• 18 — произвольная граница.

Можно попробовать соскочить на логику, мол, «это же совершеннолетие! Есть такая граница в реальной жизни, так что логическая». Но завтра аналитик скажет, что портал развивается, становится для всей семьи, и это ограничение вообще уберут.

А зависит ли логика от решения аналитика? Нет! Так что это сплошной произвол, хоть и попал в данном случае на возраст, являющийся границей в реальной жизни.

 

 

2. Строковое поле

Есть ли ограничение на длину ввода в строку? Обычно есть. Допустим, разработчик сказал, что длина имени не может быть больше 24 символов, туда все влезет с запасом. Есть в этом логика? Какая-то есть, безусловно. НО! Число «24» тут взято от балды, с потолка. Поэтому это — произвольная граница.

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

Логика в том, чтобы поставить какое-то ограничение — есть. Но сама цифра логике не поддается и может быть в любой момент изменена. Так что это просто ограничение по ТЗ: произвольная граница.

 

Итого

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

Самые важные и базовые границы:

• Ноль — он есть всегда и везде и часто приводит к багам.

• Один — а вот это неочевидно бывает, обычно только ноль смотрят, а есть еще разница «один-много».

Когда кажется, что уже проверили все, что могли, проверьте себя. Вспомните, границы каких типов существуют. Все ли вы нашли или хотя бы пытались?

• Логическая — что по поводу поля подсказывает логика?

• Технологическая — вводили ли 100 млн данных? Грузили очень большой файл?

• Произвольная — проверили все границы из ТЗ?

У моих студентов обычно возникают проблемы — куда отнести ту или иную границу? Вот если в базе ограничение «varchar(10)», это технология ограничивает или все же ТЗ? Тут ограничивает ТЗ, так как  varchar может быть и 10 символов, и 20, и 150. Технология от этого не изменится, только ТЗ для таблицы.

Но на самом деле не суть важно, отнесли вы границу в логическую или технологическую. Главное, что вы её в принципе нашли! В этом весь смысл типизации — пробежаться по списку и проверить себя, «а ничего ли я не забыл?». Не более того.

PS — моих студентов последний абзац не касается 🙂 На курсе мы учимся выделять границы и даем им названия, чтобы показать, какие типы искали. А вот потом, в дальнейшей жизни, добавлять пометки «логическая граница» уже не надо!

PPS — больше полезных статей ищите в моем блоге по метке «полезное». А полезные видео — на моем youtube-канале или его дубликате в ВК.