На практике классы эквивалентности практически обязательны при тестировании всевозможных форм и полей ввода. Но Если заглянуть немного в глубь реализации функционала то эта техника может стать полезной не только для тестирования форм и полей ввода. Приведем еще один пример (не такой классический как предыдущий, но не менее полезный): У нас есть система работы с файлами. В системе возможны четыре типа файлов А, В, С, D. Каждый файл может находиться в одном из пяти состояний: Created, Edited, Loaded, Saved, Deleted.
Файл типа А может быть удален только в состоянии Created; Файл типа В может быть удален только в состоянии Edited; Файл типа C может быть удален только в состоянии Loaded; Ну а файл типа D можно удалить только в состоянии Saved. Это громоздкое условие можно неплохо иллюстрирует следующая таблица:
В данном примере важно помнить что подобное применение классов эквивалентности возможно только в случае если есть полная уверенность в том что за обработку удалений отвечает один и тот же код. В любом случае возможность познать систему чуть глубже окажет позитивный эффект на тестирование.
Если же у вас достаточно времени на проведение 20ти тестов, то следует провести эти 20 тестов и спать спокойно. Жаль что времени почти всегда не хватает. Граничные значения В отличии от классов эквивалентности техника тест дизайна гордо именуемая Граничные значения произошла не из наблюдения за однотипным поведением тестируемых систем, а из часто наблюдаемых багов в определенных ситуациях. Довольно часто именно на границах диапазонов допустимых значений появляются довольно неприятные баги. Причин у этого может быть много но нас как тестировщиков не интересует что вызывает эти баги, нерадивость программиста или баг в фреймворке который он использует или возможно наш знак зодиака, нам важно знать в каких условиях возник баг.
Граничные значения являются идейным продолжением классов эквивалентности так как именно на границах этих классов проявляются, так интересующие нас, граничные значения.
Граничными значениями как видно являются 1 и 1000. Поскольку эта техника подразумевает проверку не только граничного значения но и двух соседних то к нашему набору тестов прибавятся еще 6 проверок (0, 1, 2, 999, 1000, 1001).
Сами диапазон допустимых значений и особенно их границы за частую не так тривиальны как в нашем примере, но если вы можете их выделить и скомбинировать с классами эквивалентности то вы получите хорошее (качественное) покрытие тестами вашей функциональности. Эпилог Классы эквивалентности и граничные значения одни из базовых техник тест дизайна, но несмотря на кажущуюся простоту и примитивность этих техник они очень полезны и могут в несколько раз сократить время необходимое на один тест раунд. А как показывает практика именно этот ресурс самый ценный в нашей жизни и работе и что особенно не честно невосполнимый.
Тест-дизайн. Классы эквивалентности и граничные значения
В этой статье мы разберем одну из самых известных и фундаментальных техник, технику выделения классов эквивалентности и граничных значений.
В чем суть техники?
Основная задача определения классов эквивалентности и граничных значений — «уйти» от дублирующих проверок. Таким образом, мы сократим количество однотипных тестов до необходимого минимума. Как это можно представить?
Предположим, у нас много-много разных булок, сделаны они по одному рецепту, а вот форма у них немного разная. А теперь представьте, что вам необходимо определить вкус каждой булки. Что вы будете делать? Попробуете все или возьмете только одну, потому что остальные сделаны аналогично? Я думаю второй вариант будет более оптимальным)
В тестировании ситуация аналогичная. Только вместо булок наши тесты. И все немного сложнее.
Классы эквивалентности
Сначала дадим определение классам эквивалентности.
Эквивалентная область (equivalence partition) —часть области входных или выходных данных, для которой поведение компонента или системы, основываясь на спецификации, считается одинаковым.
Скорей всего было не очень понятно…
Проще говоря, любой тест, выполненный из одного и того же класса эквивалентности, приведет к точно такому же результату, как и выполнение всех остальные тестов из этого же класса.
Например, у нас есть 10 тестов из одного класса. Если один из этих тестов проходит корректно, и то все остальные пройдут корректно. И наоборот, если один из тестов приведет к падению системы, то и все остальные тесты, также приведут к падению.
Пока все еще абстрактно, давайте конкретизируем. Предположим, у нас планируется акция «Скидка 10% на покупку от 5 товаров». Нам необходимо проверить функционал скидки в зависимости от количества товаров. Что будем делать? Есть два варианта проверки:
Тестов получается очень много.
2. Попробовать выделить классы эквивалентности и оптимизировать проверки.
Пойдем по второму варианту, он более эффективный. У нас всего два разных результата выполнения теста – со скидкой и без скидки. Логично предположить, что класса эквивалентности тоже будет два. В одном тесты будут проверять наличие скидки в 10%, в другом ее отсутствие.
Графически это можно представить следующим образом:
Т.е. какой бы мы тест не взяли из первого класса, мы получим скидку в 0%, аналогично для второго класса эквивалентности.
Теперь теория и здравый смысл подсказывают нам, что можно взять не все тесты, а только несколько из каждого класса эквивалентности. Этого должно быть достаточно, чтобы проверить оба случая со скидкой.
Но теперь вопрос, какие тесты брать? Есть ли разница между ними, может быть все-таки есть небольшие отличия?
Граничные значения
Путем долгого времени наблюдения за разработкой и анализа багов, специалисты пришли к выводу, что большинство ошибок возникает именно на границах между классами эквивалентности. Т.е. нам в первую очередь важно проверить переходы на стыке границ каждого класса, так как именно там велик риск возникновения ошибок.
Поэтому для эффективного тестирования нам необходимо выделить у каждого класса граничные значения. Давайте попробуем сделать на нашем примере:
Итого, 4 теста вместо 100 с учетом сохранения тестового покрытия.
Наша задача, как тестировщика, уметь правильно определить и работать с классами эквивалентности и граничными значениями. Выше мы рассмотрели пример с позиции черного ящика. У него есть существенные минус, мы не знаем как реализована работа функционала с точки зрения кода. Следовательно, не можем со 100% уверенностью правильно выделить классы эквивалентности.
Давайте рассмотрим пример посложней. Нам необходимо проверить корректность бокового меню на сайте из 10 страниц. Вот такое:
Страницы сами по себе одинаковые и отличаются только содержанием, боковое меню зрительно полностью идентично.
Только что пройденный материал подсказывает нам, что есть один класс эквивалентности и он включает в себя все 10 страниц. Но на практике есть как минимум два варианта: 1. Если сайт сделан на HTML, в том числе и боковое меню, то необходимо проверять КАЖДУЮ страницу, так как на каждой странице боковое меню работает отдельно от остальных. 2. Если сайт сделан с помощью, например, шаблонизаторов, то тогда выделить 10 страниц в класс эквивалентности можно, так как код меню хранится отдельно.
Т.е. в зависимости от реализации, классы будут разные. Как это определить? Если вы знаете языки программирования и у вас есть доступ в репозиторий, то посмотреть в код. Если вы не поняли, что я сейчас написал, то подойдет и второй вариант) Поговорите с программистом, который делал эту функциональность и уточните у него, правильно ли вы делаете.
Тестовые примеры. Классы эквивалентности. Ручное тестирование в MVSTE
5.2.2 Классы эквивалентности
Рассмотрим другой пример.
Функция, которую будем тестировать:
После исправлений функциональное требование 4.2.1.1. будет выглядеть так:
Тестирование на допустимые данные ничем не будет отличаться от тестирования функции деления. Составим классы эквивалентности.
Учитывая то, что у нас два идентичных входных параметра, для полного рассмотрения всех классов эквивалентности необходимо составить и проверить 7*7=49 тестовых примеров, что все равно гораздо меньше, чем полный перебор.
При этом, как показал тест с делением, ошибка может проявиться лишь в нескольких из этих примеров, которые не сильно отличаются от остальных граничных классов эквивалентности.
Некоторые классы эквивалентности не удовлетворяют требованию 4.2.1.1. так как выводят сумму за допустимые пределы. Поведение метода на таких входных данных описано в требовании 4.2.1.2.
На рис.5.2 показано возможное выделение классов эквивалентности (цветами изображены области корректных и некорректных значений, а кружками — сами классы эквивалентности):
Иногда удобнее составить классы эквивалентности по выходному параметру (в данном случае их будет 7) и уже по ним подбирать входные данные и составлять тестовые примеры.
Основной способ поиска дефектов – передача системе данных, не предусмотренных требованиями: слишком длинных или слишком коротких строк, неверных символов, чисел за пределами вычислимого диапазона и т.п. Неверные данные, как и допустимые, также можно разделять на различные классы эквивалентности. В качестве простого примера снова рассмотрим функцию сложения.
Замечание. Как уже отмечалось выше, тест-требования составлены очень подробно и, фактически, соответствуют тестовым примерам. Поэтому поведение метода на некорректных данных описано в спецификации, хотя подобная ситуация в жизни редко встречается.
На самом деле, взглянув на любую из рассмотренных функций, в общем случае выделяют 4 основных класса эквивалентности (рис.5.3).
Это тот минимум, на котором и надо протестировать метод. Однако интуиция и опыт тестировщика подсказывают, что эти классы можно разбить на более мелкие подклассы, в которых часто возникают ошибки. Так, первый класс для функции нахождения частного мы разбили на 14 подклассов, в результате чего и обнаружили ошибку.
Помимо рассмотренных классов тестовых примеров, направленных на выявление различных дефектов в работе программной системы, выделяют также тестовые примеры реинициализации системы, повторного ввода данных, устойчивости системы и другие.
Накидать классы эквивалентности кэ на поле ввода номера дома
Что пишут в блогах
В этом видео я показал как можно визуализировать покрытие автоматическими тестами для GraphQL api с помощью инструмента Reqover.
Cегодня хочу поговорить с вами на тему комьюнити для тестировщиков.
Как и в любой сфере, среди тестировщиков существует куча различных комьюнити. Раньше они организовывались в скайпе.
Забываю похвастаться статусом книги.
Онлайн-тренинги
Конференции
Heisenbug 2021 Moscow Большая техническая конференция для тестировщиков 5-7 октября 2021, онлайн
Что пишут в блогах (EN)
Разделы портала
Про инструменты
Ещё в самом начале предыдущего онлайн-тренинга “Практикум по тест-дизайну” я обещал ученикам написать о том, как выполнять разбиение входных данных на подобласти (классы эквивалетности) в ситуациях, когда в поле ввода можно указать произвольную строку, а по смыслу туда должно быть введено число. Увы, им пришлось выполнять домашние задания без моих подсказок (впрочем, может быть это совсем не плохо). Но я всё таки решил перед тем, как начнутся занятия следующей группы, написать небольшую “шпаргалку”.
Подавляющее большинство книг и статей, где описывается эта техника, в качестве примера рассматривают разбиение на классы множества чисел. При этом совершенно не учитывается тот факт, что в реальных приложениях с пользовательским интерфейсом все поля ввода строковые, и даже если есть ограничения на вводимые символы – это тоже предмет тестирования.
А что рекомендуется делать с “нечислами”? Они все объединяются в один большой класс “невалидных” данных, из него наугад берётся одно-два значения и всё.
Представление о том, что из себя представляет “число” сильно зависит от конкретной реализации, и я покажу вам распространённые примеры строк, которые с точки зрения программы являются числом, хотя не всякий об этом догадается. А также опишу общую схему рассуждений, позволяющую выполнить разбиение на классы эквивалетности для строковых полей ввода, предназначенных для ввода числовых значений.
Итак, давайте представим себе, что у нас есть приложение, которое на вход принимает строку, но по смыслу она должна интерпретироваться как число. Например, вот такое: Онлайн-калькулятор для перевода единиц времени.
Все возможные строки, разумеется, можно разделить на два больших класса – “числа” и “нечисла”. Но я дам этим классам другие, более длинные, но при этом более точные названия:
В такой формулировке сразу становится ясно, что программа на вход получает строку, которая перво-наперво по каким-то правилам преобразуется в число. Если это преобразование прошло успешно – полученное число используется в вычислениях, результат которых мы можем наблюдать. А если преобразовать строку в число не удалось – мы получаем информацию об этом либо в виде сообщения о возникшей проблеме, либо в виде “бессмысленного” результата вычислений.
Мы можем без труда определить, как именно наш преобразователь времени ведёт себя в той и в другой ситуации, для этого достаточно подать на вход какое-нибудь значение, которое вне всяких сомнений должно интерпретироваться как число (например, “1”):
а также какое-нибудь значение, которое абсолютно точно числом не является (например, “привет”):
То есть здесь мы как раз имеем случай, когда “невалидное” входное значение приводить к бессмысленному результату (NaN означает “Not a Number”).
Теперь давайте попробуем определить, какие же строки программа будет интерпретировать как числа, то есть начнём выделять в наших больших классах подклассы меньшего размера, но зато описанные конструктивно. Начнём с простого:
1.1. строка, представляющая собой последовательность цифр, интерпретируется как целое число.
Очевидно? Вполне. Хотя нет, не совсем очевидно. Наверняка вы уже готовы были поймать меня за руку – какой длины последовательность цифр интерпретируется как число? Всё верно, правильный вопрос.
Чтобы ответить на него, нужно опять применить технику разбиения на подобласти. Впрочем, здесь мы как раз имеем достаточно простой случай – длина последовательности это целое неотрицательное число, так что техника работает в полном соответствии с учебниками.
Минимальная длина последовательности – ноль. Максимальная длина – “сколько влезет”.
А сколько влезет? И куда влезет? В обсуждаемом приложении не указано никаких ограничений на размер поля ввода. Может быть браузер накладывает какое-нибудь ограничение, но лично мне про это ничего не известно, и даже если оно есть – наверняка в разных браузерах оно разное. Если введённые данные передаются на сервер в виде GET-запроса, возможно, имеется ограничение на длину запроса – согласно стандарту RFC 2068 они должны поддерживать не менее 255 байтов, но конечно же все реально способны обрабатывать запросы большей длины, и конечно же это опять зависит от браузера и от веб-сервера.
Конвертер, который мы используем в качестве примера, реализован на языке JavaScript, на сервер никаких данных не отправляется, все вычисления производятся внутри браузера. Установленный на моём ноутбуке Google Chrome успешно справился со строкой, состоящей из 10 000 000 девяток, а вот строку из 100 000 000 девяток он обработать уже не смог – после длительного раздумья он вывел сообщение “Опаньки…” и предложил перегрузить страницу, потому что на ней возникла ошибка. Следовательно, где-то между этими значениями и находится та самая максимальная длина, определяемая по принципу “сколько влезет”. Поэтому уточняем:
1.1. строка, представляющая собой последовательность цифр, интерпретируется как целое число, если длина строки не превышает некоторое Максимальное Значение.
Впрочем, куда раньше, на существенно более коротких последовательностях, начинает наблюдаться вот такая картина (скриншот показывает ситуацию, когда введена последовательность из 1000 девяток):
При вычислениях возникло переполнение, однако Infinity – это не NaN, то есть согласно описанном выше уговору мы будем считать, что такая последовательность (а также и более длинные последовательности цифр) всё таки может считаться числом.
А что там с другой стороны? Последовательность нулевой длины – это пустая строка. Число ли это? Чуства и логика подсказывают, что нет, однако приложение не согласно с ними и интерпретирует пустую строку как число ноль:
На всякий случай ещё проверим последовательности длины 1, как ближайшей к минимальной граничной.
Только чур не пытайтесь найти такую длину, при которой ещё не происходит переполнения, потому что это уже к длине не имеет никакого отношения, здесь важна уже не длина последовательности цифр, а само значение числа. Это оставим читателю в качестве упражнения (подсказка: JavaScript реализует стандарт IEEE-754 и может работать с числами двойной точности), а сами вернёмся к рассмотрению разных других строк.
С последовательностями цифр мы разобрались. Давайте попробуем добавить какие-нибудь “нецифры”. Перестанет ли строка быть числом?
Наверняка вы сами без труда вспомните некоторые случаи, когда этого (может быть) не случится – пробелы в начале и в конце, а также ведущие нули. Действительно, они обрезаются, а оставщаяся строка интерпретируется как число. Итак:
1.2 строка, интерпретируемая как число, также интерпретируется как число, если добавить в начале некоторое количество нулей, при этом ведущие нули игнорируются,
1.3. строка, интерпретируемая как число, также интерпретируется как число, если добавить в начале или в конце некоторое количество пробелов, при этом все пробелы игнорируются.
Ладно, двигаемся дальше – вспоминаем про отрицательные числа:
1.4. строка, интерпретируемая как число, также интерпретируется как число, если добавить в начало знак минус или плюс.
Надеюсь про плюс никто не забыл, да? Кстати, между минусом/плюсом и первой цифрой могут быть пробелы. Ну и перед ними тоже, конечно.
Гм… Кажется, у нас проблема. Помните ещё про пустую строку? Мы же согласились считать её как бы числом. Зря согласились – если “перед ней” поставить минус или плюс, числа не получается.
Ладно, выкидываем пустую строку, будем рассматривать её отдельно, как особый случай, а минимальную длину последовательности цифр объявим равной единице.
Кстати, вас не насторожил тот факт, что я перестал говорить “целое число”? В правиле выделения подобласти 1.1 я его написал, а в следующих правилах нет.
Всё верно, эти правила работают также и для нецелых чисел. Добавляем новое правило:
1.5. строка, состоящая из двух неразрывных цепочек цифр, разделённых десятичной точкой, интерпретируется как число
Углубляться в подробности, связанные с точностью вычислений не станем, отметим лишь, что здесь тоже можно применить технику разбиения на подобласти. К чему применить? К количеству значащих цифр, или к количеству знаков после запятой, в зависимости от того, как интерпретируется понятие точности в конкретном приложении. Но при этом следует отметить, что для чисел с плавающей точкой техника разбиения на подобласти работает плохо, за подробностями я отправляю вас к статьям Виктора Кулямина про тестирование математических функций (нетерпеливые могут сразу заглянуть в конец раздела 4.3, а любопытные могут поискать ещё другие статьи и презентации на ту же тему на личной страничке Виктора).
А всё почему? Потому что JavaScript реализует стандарт IEEE-754.
Вообще-то к этому моменту вы, наверное, догадались, что я неспроста уже второй раз упомянул этот стандарт. Да, вы правы. Пришло время перейти к более сложным строкам, которые ну совсем не последовательности цифр, но при этом всё равно интерпретируются как числа. Давайте введём в наше приложение, например, число 120:
Оно работает! Думаете, это только этот конвертер такой, что я специально его выбрал? Ничего подобного! Откройте с десяток наугад выбранных веб-магазинов или онлайн-калькуляторов – добрая половина согласится принять числа в таком формате. А теперь сходите и проверьте своё собственное приложение.
Хотя нет, подождите. Это ещё не всё.
Во-первых, надо добавить ещё одно правило:
1.6. строка, состоящая из числа, за которым следует символ ‘e’, за которым следует целое число, интерпретируется как число
Да, 100e-1 = 10, а плюс можно не указывать, так что 1.0e2 = 1.0e+2 = 100.
А во-вторых, есть ещё и другие строки, которые тоже интерпретируются как числа, вот пример:
Все числа до этого момента у нас были в десятеричном представлении, а теперь появились шестнадцатеричные. Я намеренно в самом начале, когда ещё первый раз сформулировал правило 1.1 не стал акцентировать внимание на том, что такое “цифра”.
Что же, добавляем новое правило:
1.7. строка, состоящая из символов ‘0x’, за которыми следует неразрывная последовательность шестнадцатеричных цифр, интерпретируется как шестнадцатеричное целое число
Правило 1.1 при этом придётся тоже уточнить, указав, что там могут участвовать только десятеричные цифры. Приятной новостью является то, что шестнадцатеричные числа могут быть только целые (ну, то есть, в этом приложении так, может быть где-то и дробные бывают). Так что максимум, что можно ещё сделать с ними – добавить плюс/минус, да пробелы в начале и в конце.
Ну вот, теперь можете проверять своё приложение, сразу и на числа с плавающей точкой, и на шестнадцатеричные числа. А я тем временем расскажу ещё кое-что про строки, которые могут быть числами.
Однажды мне встретился интернет-магазин, который принимал не только числа в шестнадцатеричном представлении, но и в восьмеричном. То есть ноль в начале не игнорировался, как это бывает обычно, а свидетельствовал о том, что число следует интерпретировать как восьмеричное. Так что правило 1.2 тоже не надо вешать на стенку, и оно не всегда справедливо.
Попробуйте в наш подопытный конвертер ввести строку Infinity – вы удивитесь, но это тоже число (а в некоторых языках программирования распознаётся также строка Inf):
В качестве записной книжки для ведения списка дел я использую замечательный сервис Toodledo. Так вот, там при создании записи можно в поле ввода даты написать, например, “tomorrow” или “next Monday” – и оно работает! Для таких преобразований бывают даже специальные библиотеки, например, в языке Perl для анализа дат используется Date::Manip, а для анализа чисел Lingua::EN::Words2Num. Мне лично не приходилось тестировать приложения, где можно было бы вводить числа в текстовом виде, но такое действительно иногда встречается на практике.
Ещё одно любопытное “число”, специально для тех, кто знаком с языком программирования Perl – “0 but true”.
А вот пример приложения – калькулятор доходности вкладов, в котором число в шестнадцатеричном представлении проходит валидацию, которая выполняется средствами JavaScript, но вызывает проблемы при вычислениях на серверной стороне. Попробуйте указать сумму вклада в шестнадцатеричном виде, например, 0xff – и вы увидите, что серая табличка с расчётами не появится на странице. Добиться аналогичного эффекта, вводя положительные десятеричные числа, мне не удалось.
(Примечание: так работал калькулятор во время написания статьи, сейчас реализация уже изменилась)
Этот приём позволяет иногда “протолкнуть” через валидатор неправильное значение, которое может привести к сбоям на серверной стороне.
В общем, надеюсь, вы поняли, что “строка, которая может быть проинтерпретирована как число” – это не такая простая штука, как может показаться на первый взгляд.
А что же попадает во второй большой класс, “нечисла”. Туда попадает всё остальное.
Да, вот такое неконструктивное определение. И при этом я обещал в самом начале статьи рассказать вам общую схему рассуждений, позволяющую выполнить разбиение на классы эквивалетности. Пожалуйста, вот эта схема, в одном абзаце:
Сначала считаем, что все строки находятся в классе “нечисел”. Как только вы прочитали в требованиях, или в документации, или узнали от коллег, или прочитали в какой-нибудь статье (например, в этой) о том, что строки определённого вида могут интерпретироваться как число – вы выделяете соответствующее подмножество строк и проверяете. Если оказалось, что ваше приложение не считает строки такого вида числами, вы сбрасываете всё обратно в большой класс “нечисел”. Ну а если приложение всё-таки согласилось считать эти строки числами, тогда они выделяются в отдельный подкласс и переводятся в класс “чисел”.
Вот и всё, очень простой алгоритм 🙂
Ну так что, принимает ваше приложение шестнадцатеричные числа или нет, а?
