Классы эквивалентности для строки, которая обозначает число

Автор: Алексей Баранцев

Ещё в самом начале предыдущего онлайн-тренинга "Практикум по тест-дизайну" я обещал ученикам написать о том, как выполнять разбиение входных данных на подобласти (классы эквивалетности) в ситуациях, когда в поле ввода можно указать произвольную строку, а по смыслу туда должно быть введено число. Увы, им пришлось выполнять домашние задания без моих подсказок (впрочем, может быть это совсем не плохо). Но я всё таки решил перед тем, как начнутся занятия следующей группы, написать небольшую “шпаргалку”.

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

А что рекомендуется делать с “нечислами”? Они все объединяются в один большой класс “невалидных” данных, из него наугад берётся одно-два значения и всё.

И всё? А вот и нет!

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



Читать дальше

А вот пример приложения – калькулятор доходности вкладов, в котором число в шестнадцатеричном представлении проходит валидацию, которая выполняется средствами JavaScript, но вызывает проблемы при вычислениях на серверной стороне. Попробуйте указать сумму вклада в шестнадцатеричном виде, например, 0xff – и вы увидите, что серая табличка с расчётами не появится на странице. Добиться аналогичного эффекта, вводя десятеричные числа, мне не удалось.

Хм... а "-1" не является десятеричным числом?

А вот пример приложения – калькулятор доходности вкладов, в котором число в шестнадцатеричном представлении проходит валидацию, которая выполняется средствами JavaScript, но вызывает проблемы при вычислениях на серверной стороне. Попробуйте указать сумму вклада в шестнадцатеричном виде, например, 0xff – и вы увидите, что серая табличка с расчётами не появится на странице. Добиться аналогичного эффекта, вводя десятеричные числа, мне не удалось.

Хм... а "-1" не является десятеричным числом?

Великолепно! Хорошо писать статьи для тестировщиков :)
Я имел в виду положительные значения, но, увы, не досмотрел, не написал про это, и Вы меня поймали, за что огромное спасибо!
Исправил в тексте статьи.

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

Отличная статья. Спасибо!

Если ввести значение 12e+23, то заметна UI бага.

Любопытная статья.

Есть подозрение, что в данное место вкралась неточность:
"Во-вторых, добавлять сначала нули, а потом пробелы можно, а вот наоборот нельзя:" -> "Во-вторых, добавлять сначала пробелы, а потом нули можно, а вот наоборот нельзя:"

PS: кому интересно, тут http://javascript.ru...a/part9#a-9.3.1 есть правила преобразования и можно сделать вывод, что рассматриваемый конвертр ведет себя именно так, как описано. Т.е. используется встроеное в язык javascript преобразование из строки в число. А вот альтернативный конвретер, на который ссылается Алексей делает преобразование из строки в число собственными силами. Например, он не понимает символов табуляции, хотя легко рассправляется с пробелами. А о чем это говорит? Как минимум о том, что авторы изобретали велосипед (убедиться можно открыв соотв. джаваскриптовый файл). Думаю понятно при каком подходе тестер вправе ожидать большее количество ошибок в реализации.

PSS: да. кстати, в русскоязычном описании преобразования ToNumber на сайте javascript.ru есть ошибка для шестнадцатиричных чисел, в оригинале стандарта ее нет.

а я ввела строку "0000" в ... сидю... ждю.... ничего не появилось

Есть подозрение, что в данное место вкралась неточность:
"Во-вторых, добавлять сначала нули, а потом пробелы можно, а вот наоборот нельзя:" -> "Во-вторых, добавлять сначала пробелы, а потом нули можно, а вот наоборот нельзя:"

Да уж. Это иллюстрация к теме неоднозначности спецификаций.

Когда я писал, я имел в виду порядок следования символов справа налево (сначала значащие цифры, потом нули, а затем пробелы).
А потом подумал: ведь если я говорю про нули и/или пробелы в конце, тогда я буду иметь в виду порядок следования слева направо.
Нелогично. Подумал ещё раз. Понял, что в голове у меня эти дополнительные символы следуют в порядке "от центра к краю", а центром является значащее число.

Ужас, короче. Бедные аналитики...

Ещё мы с коллегами постоянно спорим, где у дерева (структуры данных, а не растения) правильнее рисовать корень -- сверху (ветви направлены вниз) или снизу (ветви направлены вверх).
Одни представляют себе деревья так, другие наоборот. Некоторые ещё представляют справа налево, но среди моих знакомых таких нет :)
И когда за чашкой кофе обсуждаются какие-нибудь алгоритмы, время от времени можно услышать: "... спускаемся по дереву вниз ... " - "вниз это от корня или к корню?"

а я ввела строку "0000" в ... сидю... ждю.... ничего не появилось

Как, совсем ничего?

Есть подозрение, что в данное место вкралась неточность:
"Во-вторых, добавлять сначала нули, а потом пробелы можно, а вот наоборот нельзя:" -> "Во-вторых, добавлять сначала пробелы, а потом нули можно, а вот наоборот нельзя:"

Да уж. Это иллюстрация к теме неоднозначности спецификаций.

Когда я писал, я имел в виду порядок следования символов справа налево (сначала значащие цифры, потом нули, а затем пробелы).
А потом подумал: ведь если я говорю про нули и/или пробелы в конце, тогда я буду иметь в виду порядок следования слева направо.
Нелогично. Подумал ещё раз. Понял, что в голове у меня эти дополнительные символы следуют в порядке "от центра к краю", а центром является значащее число.

Ужас, короче. Бедные аналитики...

А когда я писал, то я думал о кнопках которые надо нажимать - так получается проще.

Ещё мы с коллегами постоянно спорим, где у дерева (структуры данных, а не растения) правильнее рисовать корень -- сверху (ветви направлены вниз) или снизу (ветви направлены вверх).
Одни представляют себе деревья так, другие наоборот. Некоторые ещё представляют справа налево, но среди моих знакомых таких нет :)
И когда за чашкой кофе обсуждаются какие-нибудь алгоритмы, время от времени можно услышать: "... спускаемся по дереву вниз ... " - "вниз это от корня или к корню?"

Обычно сверху корень. Не припомню, чтобы снизу был. Да и логичнее это, мы читаем сверху-вниз, а обход деревьев происходит от корня. Иначе как-то странно было бы.
А слева на право, имхо, растут графы! Справа налево соотвественно семитские графы :)

а я ввела строку "0000" в ... сидю... ждю.... ничего не появилось

Как, совсем ничего?

Нового - ничего.
Экран обновился,картинка калькулятора переместилась наверх - только нижний кусочек виден. Снизу - "Вклад зимний подарок".

Ну вот вчера на "рассчитать" сразу стала нажимать --- быстренько какое сообщение поскочило - вроде "ждите... считаем.." -- но так быстро, что в общем и не успеть прочесть..
Сегодня так не получилось.

ПС.
А мы банки.ру не сломаем начисто?

(тихо впадаю в мерлихлюндию...)

А ежели ВООБще ничего на вводить (Да! Лень вот!),
то выведется совершенно дивное сообщение (скопипастила, правописание не меняла):

"Не возможно произвести расчет!
Укажите, пожалуйста:
- сумму вклада
"
А снизу - кнопка "ОК"

А когда я писал, то я думал о кнопках которые надо нажимать - так получается проще.

Вот именно это я и имел в виду: проще -- понятие субъективное.

А мы банки.ру не сломаем начисто?

Да-да, за это я и люблю тестировщиков.
Просто к слову упомянул, что на таком-то сайте видел вот такое-странное поведение, для демонстрации какой-то своей мысли -- и тут же дополнения: ух ты, а ещё оно вот так не работает, и вот так, и ещё вот так :)

Ну вроде место подходящее для вопроса. Может кто знает?
Читаю ГОСТ РВ 00019-001-2006.
п. "План квалификационного тестирования ПО".
пп. Стратегия квалификационного тестирования.
Раздел должен содержать:
-...
- выбранные классы эквивалентности тестов;
- установленная степень выборки тестируемых данных в классах эквивалентности, которая будет выполняться, и ее обоснование (тут я споткнулась еще вчера.....)

Вопрос простой.
Вот эта степень выборки для разобранных выше примеров что такое? Для классов эквивалентности для строки, которая обозначает число?

Ну т.е. я ВООБЩЕ не понимаю, что это за степень, ну и тем более - как ее обосновать!!!! . ( )

Ну т.е. я ВООБЩЕ не понимаю, что это за степень, ну и тем более - как ее обосновать!!!! . ( )

Может быть это количество представителей данного класса эквивалентности?
А обоснование - от задачи исходить должно и от возможных вариантов.

Пример. Есть функция fac(int i) - считает факториал. Разбиваем значения по классам эквивалентности
1) отрицательные, 2) 0, 3) 1, 4) 2, 5) >2 6) max_int, 7) max_allowed, 8) min_int ... можно еще напридумывать, но к делу уже не относится.
Сколько брать представителей из какого класса?
Понятно, что для классов 2) 3) 4) 6) 7) 8) - есть только один представитель класса, его и возьмем.
Что делать с классами 1) и 5)?
Для класса 1) я бы взял -1 (вдруг проверка на отрицательные числа сделана так: if(i < -1) return "only positive values") и еще одного любого представителя класса. Альтернативно -1 можно сделать отдельным классом.
Для класса 5) я бы тоже взял 2-х представителей. Чтобы избежать антипатерна happy path test. В конкретном случае может быть такая реализация метода, которая возвращает не вычисленный факториал, а константу, равную факториалу числа поданного на вход (тут пример с факториалом: http://www.ibm.com/d...brary/os-junit/).

Может быть это количество представителей данного класса эквивалентности?
А обоснование - от задачи исходить должно и от возможных вариантов.

Упс! Спасибо! Попробую в эту сторону поприкидывать - подумать.

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

1) А почему б не добавить клас еквивалентности "числа в двоичнoй системе", и вообще все системи исчисления?
2) И что ви думаете про иероглифы, кирилицу и латинские символи, может стоит их добавить
3) Выделение класов еквивалентности для приведенного примера не базируется на требованиях, а на том что мы видем(юзер интерфейс) так ли ето? Если да, стоит ли в таком случае вообше тестировать? Как мы можем утверждать что у нас два класа с самого начала, а может приложение должно принимать все что юзер ввел и интерпритировать инпут как то посвоему (пример - исчесляет код символа, сумирует, множет на 100, делит на 5 и тоогда считает минуты)