Самый первый метод тест-анализа, который каждый начинающий тестировщик постигает инстинктивно, – это метод граничных значений. Но так ли он прост, как это кажется на первый взгляд? Давайте разберемся!
Для сравнения разных подходов возьмем конкретный пример. Пусть у нас на сайте есть форма предварительного расчета стоимости страховки жизни, базирующаяся на очень простой формуле. Клиент вводит возраст и сумму в рублях, на которую он хочет застраховать свою жизнь. Если клиент моложе 18 лет или старше 60, выводится сообщение: «К сожалению, на данный момент у нас нет для вас подходящих предложений». Во всех остальных случаях мы просто считаем процент от введенной суммы; этот процент равен возрасту клиента. Да, я знаю, что в реальности расчет будет гораздо сложнее, но для наших целей такая модель подойдет.
Что нам говорит здравый смысл
Итак, любой новичок, который буквально пару дней придумывает тесты, сразу понимает, что нужно как-то проверить условия 18 и 60 лет. Скорее всего, для надежности он выберет (17, 18, 19 лет) и (59, 60, 61 год). И это хороший выбор! Действительно, если сбой есть хоть на каких-то значениях, то его будет видно и около границы с той или другой стороны. Более того, сбой чаще всего проявляется именно на самих граничных значениях.
Что нам говорит определение ISTQB FL
Теперь посмотрим, что нам рекомендует такой надежный источник, как Силлабус ISTQB FL: «Минимальные и максимальные значения сегмента являются граничными значениями. Граничное значение для валидного сегмента является валидным граничным значением, для невалидного сегмента – невалидным». Другими словами, мы имеем тут три диапазона (… по 17, от 18 до 60, от 61 и выше) и только по два значения на каждую границу (17, 18 и 60, 61). Именно такой ответ будет требоваться на экзаменах ISTQB, и это часто сбивает с толку новичков, которым хочется проверить границы со всех сторон.
Определенная логика в подходе составителей Силлабуса есть: если на 18 и 60 годах система правильно посчитала процент, то ожидать, что на 19 и 59 она вдруг опять покажет ошибку «ваш возраст нам не подходит», было бы странно. Точнее, ошибка на этих значениях возникнуть может, но с такой же вероятностью, как и на любых других числах диапазона (а мы уже решили, что такая вероятность невысока).
Что нам говорит Ли Копленд про тестирование границ
Теперь давайте обратимся к классику тест-анализа Ли Копленду и его известной книге «A Practitioner’s Guide to Software Test Design», которая, к сожалению, не переводилась на русский. Заглянув в раздел «Граничные значения», мы увидим все то же решение, первым приходящее в голову: (граница — 1), граница, (граница + 1). Кстати, именно у Копленда вы можете прочитать подробное обоснование того, почему ошибки в коде чаще всего заметны на границах диапазона и очень редко встречаются на одиноком случайном значении внутри диапазона.
При этом в разделе «Доменный анализ» (термин можно понимать как «Анализ диапазонов», используется он для случаев учета границы не у одного параметра, а у двух и более) терминология резко меняется. Появляются такие понятия как ON, OFF, IN и OUT. Чтобы понять, откуда они взялись, и почему их четыре, нам понадобится ознакомиться с предысторией вопроса.
На заре эры тестирования некоторые параметры программы были просты, как выключатели. Например, человек вводил ответ на тест – число, правильным ответом было 10. На ввод всех прочих чисел система должна была писать «неверно», а на 10 – «молодец». Для таких параметров ввели первые очень простые границы – ON/OFF. ON – это в данном случае 10, то есть значение или граница, на котором выключатель включился. Все остальные значения попадали в OFF. Другие параметры могли быть сложнее, и результаты стали задаваться не просто точкой, а целыми интервалами. Скажем, в нашем примере клиент мог застраховать жизнь при возрасте 18 до 60 лет – следовательно, появились границы IN/OUT (внутри и вне диапазона). Все числа от 18 до 60 попадали в IN, остальные – в OUT.
Пока все было логично, но появилась новая проблема: теперь названия границ могут быть разными в разных параметрах. А если параметр работает как выключатель, но в двух точках? А если есть и точка и интервал? В конечном итоге все эти 4 границы решили определить для любого параметра; тестировщикам предоставлялся выбор конкретного варианта.
Были приняты такие определения (они фигурируют и в книге Копленда), которые мы проиллюстрируем числами из нашего примера:
- ON – любая точка строго на границе (не важно, в диапазоне или нет), у нас это 18 и 60.
- OFF – любая точка не на границе (не важно, в диапазоне или нет). Все числа, кроме 18 и 60. Для тестирования Копленд рекомендует выбирать максимально близкие к границам диапазона значения (17 и 61).
- IN – любая точка в диапазоне, но только не на границе (все числа от 19 до 59).
- OUT – любая точка вне диапазона. В нашем примере это все числа меньше 18 и больше 60. В дальнейшем описании метода этот термин Копленд не использует.
Итак, для применения метод «доменного анализа» к нашему примеру нам потребуется установить ограничения и на сумму в рублях, которую вводит пользователь. Предположим, что эта сумма будет не меньше 100 000 рублей, но не больше 2 000 000. Во всех остальных случаях мы тоже пишем «К сожалению, на данный момент у нас нет для вас подходящих предложений». Сами по себе границы нам понятны:
- ON – 100 000 и 2 000 000;
- IN – 100 001 и 1 999 999;
- OFF – 99 999 и 2 000 001.
Правда, хорошо, что у нас нет копеек? Здесь, кстати, я хотела бы сделать первую ремарку.
Метод граничных значений отлично работает на самих целых числах, а также на таких целочисленных параметрах, как количество символов в поле или количество товара в корзине. Однако, как только вы перейдете хотя бы к десятичным дробям, сложностей станет больше. Однажды я тестировала границы диапазона поля, где можно было вводить числа в экспоненциальной форме, и тут попытка найти число, ближайшее к 1.0Е-15 не увенчалась успехом. Нет, это не 1.0Е-14, ведь 1.1Е-15 будет ближе. А 1.00001Е-15 еще ближе. А может попробовать 1.0000000000001Е-15 ? В конечном счете решение пришлось строить не от ближайшего числа (которого, строго говоря, и не существует с математической точки зрения), а от самого длинного из «влезающих» в форму.
В нашем примере все числа целые, так что попробуем использовать метод Копленда и составить таблицу доменного анализа так, чтобы проверить границы обоих параметров.
В соответствии с методикой нельзя совмещать два ON, ON и OFF или два OFF, ведь такое совмещение при падении теста усложнит локализацию, особенно если тесты подлежат автоматизации. Тем не менее иногда такие тесты делают специально (например, «нарушить границы в нескольких полях в форме и проверить, что система покажет все сообщения об ошибках разом»). Мы пока все делаем строго по методике и проверяем все границы по одной. В первую очередь расставляем все значения ON и OFF, которые нам надо проверить. Получается восемь тестов:
По клику на картинку откроется полная версия.
Мы не можем провести тесты, указав только одно значение, поэтому теперь везде, где не хватает значения, мы ставим недостающее IN. Пусть для возраста это будет 40, а для суммы – 200 000 рублей.
Вот мы и получили 8 тестов для проверки границы уже не одного, а сразу двух параметров, имеющих ограниченные позитивные диапазоны:
По клику на картинку откроется полная версия.
Уверена, что при взгляде на эту таблицу вам инстинктивно хочется добавить девятый тест, в котором оба значения – IN. Но Копленд рассматривает именно проверки границ, а тесты, где все значения IN, к граничным не относятся.
А теперь десерт!
Что делать, если диапазон и границы заданы не только для входных параметров, но и для итога работы программы?
Вот реальные примеры:
Дата окончания договора рассчитывается автоматически от даты заключения с добавлением продолжительности договора. При этом в зависимости от года окончания договора он хранится в разных хранилищах и имеет разные условия расторжения.
Программа обработки изображений позволяет изменить качество и размер изображения, но если у выходного изображения размер будет больше 3 MB или произведение сторон будет больше 16 мегапикселей, то получить изображение можно будет только как внешнюю ссылку на хранилище.
Назначенные в таск-трекере на одного человека задачи не должны превышать 8 часов за сутки (или уж хотя бы 24 часа за сутки, так и быть!).
То есть, мы изначально имеем границы на результат обработки данных, но при этом для тестирования указываем значения только тех параметров, которые можем напрямую задать программе. Получается, что результат зависит от параметров, имеющих собственные границы. Кроме того, иногда в обработке возникают и промежуточные этапы; параметры на этих этапах также могут иметь промежуточные значения.
Для наглядности давайте вернемся к нашему примеру и введем дополнительное ограничение: мы не хотим связываться с теми, кто заплатит нам за страховку меньше 50 000 рублей, они также получат сообщение «К сожалению, на данный момент у нас нет для вас подходящих предложений».
Как нам составить набор тестов для такого случая? Вновь используем технику «доменного анализа» Копленда, но теперь таблица станет чуть-чуть сложнее: у нас появится еще один параметр «к оплате». Сначала, как и прошлый раз, расставим все значения ON и OFF, которые нам надо проверить. Добавляем два дополнительных граничных теста для значения «к оплате»:
По клику на картинку откроется полная версия.
Мы не можем провести тесты, указывая только одно значение или вообще ничего не вводя. Нам снова надо заполнить недостающие данные, но теперь у нас нет возможности сделать это произвольно. Дело в том, что значение параметра «к оплате» у нас равно проценту от суммы, которую ввел клиент, а этот процент равен его возрасту.
Если мы (как в прошлый раз) подставим сумму 200 000 рублей и возраст 40 лет, а потом посчитаем, то у нас получится куча тестов либо с двумя OFF, либо с совпадением ON и OFF. Как мы помним, это совершенно недопустимо!
По клику на картинку откроется полная версия.
А ведь мы еще даже не начали указывать значения суммы и возраста для двух последних тестов, но и их тоже нельзя брать наугад – они должны дать нам именно наши граничные значения параметра «К оплате»! Что же делать?
Вообще говоря, мы можем использовать обычный метод тыка: сдвигать по чуть-чуть значения суммы и возраста до тех пор, пока не попадем в нужный нам диапазон. Копленд предлагает другое решение.
Давайте нарисуем график зависимости параметра «к оплате» от суммы и возраста и отметим на графике наши границы. Красная кривая показывает нам область, где параметр «к оплате» будет равняться 50 000 рублей. Пары значений ниже этой линии брать нельзя (то есть, для возраста 18 мы сразу видим, что сумма должна быть больше 282 000 рублей).
По клику на картинку откроется полная версия.
Теперь, глядя на этот график, мы легко выберем те граничные значения, которые нам подойдут, и получим, например, такой набор тестов:
По клику на картинку откроется полная версия.
Как видите, все границы всех диапазонов проверены. Более того, нам удалось выполнить правило «в тесте может быть только одно значение OFF или ON, а все остальные обязательно должны быть IN». Выглядит сложно, но мы знаем, как это работает, и можем помочь вам с тестированием вашего продукта.
Теперь я бы хотела сделать вторую ремарку.
Я уже много лет являюсь тренером в Школе Тест-аналитика от Натальи Руколь, где мы подробно разбираем именно эту методику. Все эти годы я слышу один и тот же вопрос: «Погодите, а как же ноль? Разве нам не надо проверить его? А если пользователь введет возраст 0 или сумму 0?». Этот вопрос имеет под собой глубокие корни. Дело в том, что любой тестировщик, хотя бы полгода проработавший на любом проекте, очень быстро обнаруживает, что ноль – это всегда слабое место в системе, это проверенная наживка, на которую всегда ловится большое количество жирных багов. Многие алгоритмы с трудом переваривают такое «невкусное» число, как ноль. До сих пор классическим примером негативного теста простого калькулятора является именно деление на ноль. Однако, надо понимать, что в прямом смысле слова ноль не является вечной границей для абсолютно любого параметра, поэтому я согласна с Ольгой Киселевой, которая в своей статье обозначила его как отдельный класс эквивалентности. Поэтому в этой статье я не уделила ему много внимания.
Итак, я надеюсь, что теперь, разобрав разные школы и подходы к тестированию границ, вы убедились: метод этот хоть и не столь прост, как кажется на первый взгляд, но все-таки крайне полезен для начинающего тест-аналитика. Я рекомендую сначала освоить все перечисленные мной методы, а потом определить тот, который выгоднее всего использовать именно на вашем проекте.
