Наиболее важным моментом в методах, основанных на спецификациях, является то, что
спецификации или модели не определяют (и не должны) определять, как система должна достигать заданного поведения при ее построении; это спецификация требуемого (или, по крайней мере, желаемого) поведения. Один из трудных уроков, который инженеры-программисты усвоили из своего опыта, заключается в том, что важно отделять определение того, что система должна делать (спецификацию), от определения того, как она должна работать (проект). . Это разделение позволяет двум группам специалистов (тестерам по спецификациям и дизайнерам по дизайну) работать независимо друг от друга, чтобы позже мы могли проверить, пришли ли они к одному и тому же месту, т.е. они вместе построили систему и проверили, работает ли она в соответствии со своей спецификацией. .

  • Анализ граничных значений
  • Тестирование таблицы решений
  • Тестирование перехода состояния
  • Тестирование варианта использования
  • Анализ граничных значений
    Одна вещь, которую мы знаем о видах ошибок, которые допускают программисты, заключается в том, что ошибки, как правило, группируются вокруг границ. Например, если программа должна принять последовательность чисел от 1 до 10, наиболее вероятной ошибкой будет неправильное принятие значений, выходящих за пределы этого диапазона, или неправильное отклонение значений, находящихся только внутри этого диапазона. В мире программирования эти ошибки совпадают с определенными структурами программирования, такими как количество выполнений программного цикла или точная точка, в которой цикл должен прекратить выполнение. границы. Раздел целых чисел от 1 до 99, например, имеет наименьшее значение 1 и максимальное значение 99. Они называются граничными значениями. На самом деле они называются действительными граничными значениями, потому что они являются границами внутри действительного раздела. А как насчет внешних ценностей? Да, у них тоже есть границы. Таким образом, граница недопустимых значений на нижнем конце будет равна нулю, потому что это первое значение, к которому вы приходите, когда выходите за пределы раздела на нижнем конце. (Вы также можете думать об этом как о самом высоком значении внутри недопустимого раздела целых чисел, которые меньше единицы, конечно.) В верхней части диапазона у нас также есть недопустимое граничное значение, 100. Это метод граничных значений, более или менее. Для большинства практических целей метод анализа граничных значений должен идентифицировать только два значения на каждой границе. По причинам, которые не должны нас здесь останавливать, существует альтернативная версия метода, использующая три значения на каждой границе. Для этого варианта, который задокументирован в BS 7925–2, мы включаем еще одно значение на каждую границу, когда используем анализ граничных значений: правило состоит в том, что мы используем само граничное значение и одно значение (настолько близкое, насколько это возможно). ) по обе стороны границы. Итак, в этом случае нижние граничные значения будут 0, 1, 2, а верхние граничные значения будут 98, 99, 100. Что означает «настолько близко, насколько мы можем получить»? Это означает взять следующее значение в последовательности, используя точность, которая была применена к разделу. Например, если числа имеют точность 0,01, нижние граничные значения будут 0,99, 1,00, 1,01, а верхние граничные значения будут 98,99, 99,00, 99,01.
    Когда вы придете на экзамен, вы обнаруживают, что экзамен признает наличие двух возможных подходов к анализу граничных значений. По этой причине любые вопросы об анализе граничных значений будут ясно сигнализировать о том, должны ли вы определить 2 или 3 значения на любой границе. Вы обнаружите, что это не вызывает проблем, но ниже приведены примеры, в которых используется как двухзначный, так и трехзначный подход, просто на всякий случай и убедитесь, что вас не застанут врасплох на экзамене.
    Лучший способ закрепить представление о границах — рассмотреть несколько примеров.
    ГРАНИЧНЫЕ ЗНАЧЕНИЯ — ПРИМЕР 4.2
    Температура кипения воды — граница составляет 100 градусов Цельсия, так что для подхода с 3 границами значений граничные значения будут 99 градусов, 100
    градусов, 101 градус — если у вас нет очень точного цифрового термометра, в этом случае они могут быть 99,9 градуса, 100,0 градуса, 100,1 градуса. Для подхода с двумя значениями соответствующими значениями будут 100 и 101.
    Экзамен сдан — если экзамен имеет границу сдачи на уровне 40 процентов, заслуга на уровне 60 процентов
    и отличие на уровне 80 процентов, то 3 границы ценности будут 39, 40, 41 для прохода, 59, 60, 61 для достоинства, 79, 80, 81 для отличия. Маловероятно, что метки будут записаны с большей точностью, чем целые числа. Эквивалентами двух значений будут 39 и 40, 59 и 60 и 79 и 80 соответственно.

Эквивалентное разбиение (входные разделы)
Эквивалентное разбиение основано на очень простой идее: во многих случаях входные данные для программы могут быть «разбиты» на группы похожих входных данных.

Предположим, в качестве примера, что программа принимает любое значение от -10 000 до +10 000 (компьютеры фактически представляют числа в двоичной форме, что делает их гораздо менее похожими на те, с которыми мы знакомы, но мы будем придерживаться знакомого представления). Если представить себе программу, которая разделяет числа на две группы в зависимости от того, положительные они или отрицательные, весь диапазон целых чисел можно разделить на три «раздела»: значения меньше нуля; нуль; значения больше нуля.

Каждый из них известен как «раздел эквивалентности», потому что каждое значение внутри раздела точно эквивалентно любому другому значению, насколько это касается нашей программы. Поэтому, если компьютер принимает -2905 как допустимое отрицательное целое число, мы ожидаем, что он также примет -3. Точно так же, если он принимает 100, он также должен принимать 2345 как положительное целое число. Обратите внимание, что мы рассматриваем ноль как особый случай. Мы могли бы, если бы захотели, включить ноль в положительные целые числа, но моя элементарная спецификация не указывала это четко, поэтому на самом деле оставлено как неопределенное значение (и это не нетипично находить такие неясности или неопределенные области в спецификациях). Часто нам удобно рассматривать ноль как особый случай для тестирования, в котором участвуют диапазоны чисел; мы рассматриваем его как раздел эквивалентности только с одним элементом.

Разделы, которые мы идентифицировали до сих пор, называются допустимыми разделами эквивалентности, потому что они разбивают набор допустимых входных данных, но есть и другие возможные входные данные для этой программы, которые не будут действительными — например, действительные числа. У нас также есть два входных раздела целых чисел, которые недействительны: целые числа меньше -10 000 и целые числа больше 10 000. Мы должны проверить, что программа их не принимает, что так же важно, как и программа, принимающая допустимые входные данные.
Недопустимые разделы также важно проверить. Если вы подумаете о примере, который мы использовали, вы скоро поймете, что возможных недопустимых входных данных гораздо больше, чем допустимых, поскольку все действительные числа (например, числа, содержащие десятичные дроби) и все символы в этом случае недействительны. Как правило, способов ввести неверный ввод гораздо больше, чем способов ввода правильного; в результате нам нужно убедиться, что мы протестировали программу на возможных недопустимых входных данных. Здесь нам снова приходит на помощь разбиение эквивалентности: все действительные числа одинаково недействительны, как и все буквенные символы. Они представляют собой два недопустимых раздела, которые мы должны проверить, используя такие значения, как 9,45 и «r» соответственно. Будет много других возможных недопустимых входных разделов, поэтому нам, возможно, придется ограничить тестовые примеры теми, которые, скорее всего, возникнут в реальной ситуации.
ПРИМЕР ЭКВИВАЛЕНТНЫХ РАЗДЕЛОВ
Допустимый ввод: целые числа в диапазоне от 100 до 999.
- Допустимый раздел: от 100 до 999 включительно.
- Недопустимый раздел: меньше 100, больше чем 999, действительные (десятичные)
числа и нечисловые символы.
Допустимый ввод: имена, содержащие до 20 буквенных символов.
- Допустимый раздел: строки из до 20 буквенных символов.
- Недопустимые разделы: строки, содержащие более 20 буквенных символов,
строки, содержащие небуквенные символы.

Тестирование таблицы решений
Спецификации часто содержат бизнес-правила для определения функций системы и условий, при которых работает каждая функция. Отдельные решения обычно просты, но общий эффект этих логических условий может стать довольно сложным. Как тестировщики, мы должны иметь возможность убедиться, что каждая комбинация этих условий, которая может возникнуть, была протестирована, поэтому нам нужно зафиксировать все решения таким образом, чтобы мы могли исследовать их комбинации. Механизм, обычно используемый для регистрации логических решений, называется таблицей решений.
В таблице решений перечислены все входные условия, которые могут возникнуть, и все действия, которые могут возникнуть из них. Они структурированы в виде таблицы в виде строк, с условиями в верхней части таблицы и возможными действиями в нижней части. Бизнес-правила, которые включают в себя комбинации условий для выполнения некоторой комбинации действий, располагаются вверху. Таким образом, каждый столбец представляет одно бизнес-правило (или просто «правило») и показывает, как входные условия объединяются для выполнения действий. Таким образом, каждый столбец представляет собой возможный тестовый пример, поскольку он определяет как входные данные, так и ожидаемые результаты. Схематично это показано в рамке ниже.

Бизнес-правило 1 требует, чтобы все условия были истинными для создания действия 1. Бизнес-правило 2 приводит к действию 2, если условие 1 ложно, а условие 2 истинно, но не зависит от условия 3. Бизнес-правило 3 требует выполнения условий 1 и 2 быть истинным, а условие 3 — ложным.

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

ПРОВЕРКА ТАБЛИЦЫ РЕШЕНИЙ — ПРИМЕР 4.3
В супермаркете действует программа лояльности, которая предлагается всем покупателям. Владельцы карт лояльности
пользуются преимуществами либо дополнительных скидок на все покупки
(правило 3), либо приобретения баллов лояльности (правило 4), которые можно конвертировать в ваучеры для супермаркета или в эквивалентные баллы по схемам. управляется партнерами. Покупатели без карты лояльности получают дополнительную скидку только в том случае, если они тратят более 100 фунтов стерлингов за одно посещение магазина (правило 2), в противном случае применяются только специальные предложения, предлагаемые всем покупателям (правило 1).

Из таблицы решений мы можем определить тестовые примеры, установив значения для условий
и определив ожидаемый результат, например. из правила 1 мы могли ввести обычного клиента с транзакцией на 50 фунтов стерлингов и проверить, не применялась ли скидка. Тот же клиент с транзакцией на 150 фунтов стерлингов (правило 2) должен получить скидку. Таким образом, мы видим, что каждый столбец таблицы решений представляет собой возможный тестовый пример.

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

Если у нас есть представление системы в виде диаграммы переходов состояний, мы можем проанализировать поведение с точки зрения того, что происходит, когда происходит переход.
Переходы вызываются событиями, и они могут генерировать выходные данные и/или изменения состояния. Событие — это все, что действует как триггер для изменения; это может быть вход в систему или что-то внутри системы, которое по какой-либо причине изменяется, например, поле базы данных обновляется.
В некоторых случаях событие создает вывод, в других — изменяет
внутреннее состояние системы без генерации вывода, а в некоторых случаях событие может вызвать вывод и изменение состояния. Что происходит при каждом изменении, всегда можно вывести из диаграммы перехода состояний.

ДИАГРАММА ПЕРЕХОДА СОСТОЯНИЙ — ПРИМЕР 4.4
Часы для пешеходов имеют два режима: время и альтиметр. В режиме времени
нажатие переключателя режима приводит к переключению часов в альтернативный режим; повторное нажатие
Mode возвращает в режим Time. Пока часы находятся в режиме Alt, кнопка Set
не действует.
Когда часы находятся в режиме Time, нажатие кнопки Set переводит часы в режим Set Hrs, из которого отображение часов можно увеличивать, нажимая кнопку Установить. Если переключатель режима нажат, когда часы находятся в режиме установки часов, часы переходят в режим установки минут, в котором нажатие кнопки «Установить» увеличивает отображение минут. Если в этом режиме нажать кнопку «Режим», часы перейдут обратно в режим «Время» (рис. 4.1).
Обратите внимание, что не все события действуют во всех состояниях. Если событие не влияет
на данное состояние, оно обычно опускается, но может быть показано стрелкой, начинающейся от состояния и возвращающейся к тому же состоянию, чтобы указать, что переход не происходит; это иногда называют «нулевым» переходом или «недопустимым» переходом.

Вместо того, чтобы выяснять, что происходит для каждого события каждый раз, когда мы хотим инициировать тест, мы можем сделать промежуточный шаг и создать так называемую таблицу состояний (ST). ЗБ записывает все возможные события и все возможные состояния; для каждой комбинации события и состояния он показывает результат с точки зрения нового состояния и любых сгенерированных выходных данных.
ST — это источник, из которого мы обычно получаем тестовые примеры. Это имеет смысл
делать именно так, потому что анализ переходов между состояниями требует времени и может
быть источником ошибок; лучше выполнить эту задачу один раз, а затем иметь простой
способ генерации тестов из нее, чем делать это каждый раз, когда мы хотим создать новый тестовый пример.
Вот пример того, что такое ST похоже.

ТАБЛИЦА СОСТОЯНИЙ — ПРИМЕР 4.4
В ST есть строка для каждого состояния на диаграмме переходов состояний и столбец для каждого события. Для заданного пересечения строки и столбца мы считываем состояние с диаграммы переходов состояний и отмечаем, какой эффект (если есть) оказывает каждое событие. Если событие не имеет никакого эффекта, мы помечаем запись в таблице символом, указывающим, что ничего не происходит; это иногда называют «нулевым» переходом или «недействительным» переходом. Если у события есть действующая метка, запись в таблице с состоянием, в которое переходит система при возникновении данного события; если есть еще и выход (иногда есть, но не всегда), то выход указывается в той же записи таблицы, отделенной от нового состояния символом «/». Пример, показанный в таблице 4.1, — это ST для рисунка 4.1, который мы нарисовали в предыдущем блоке.

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

ТЕСТИРОВАНИЕ ПЕРЕХОДА СОСТОЯНИЯ — ПРИМЕР 4.4
Мы генерируем тестовые случаи, проходя через ST. Если мы начнем в режиме Time, то первым тестовым примером может быть нажатие Mode и наблюдение за тем, как часы переходят в состояние Alt; повторное нажатие режима становится тестовым примером 2, который возвращает часы в состояние времени. В тестовом примере 3 можно нажать кнопку «Установить» и наблюдать за переходом в режим «Установить часы», а затем попробовать несколько раз нажать кнопку «Установить», чтобы проверить, работает ли механизм увеличения. Таким образом, мы можем систематически обходить ST до тех пор, пока не будет отработан каждый отдельный переход. Если мы хотим быть более изощренными, мы можем использовать пары переходов, например. нажав Set дважды в качестве одного тестового случая, чтобы проверить правильность приращения Hrs. Мы также должны протестировать все отрицательные случаи, т. е. те случаи, когда ST указывает на отсутствие действительного перехода.

СЛУЧАИ ИСПОЛЬЗОВАНИЯ
На диаграмме вариантов использования (например, на рис. 4.3) каждый тип пользователей известен как действующее лицо, а действующее лицо обозначает всех пользователей данного типа. Варианты использования — это действия, выполняемые системой для этого субъекта. По сути, это высокоуровневое представление требований. Сама по себе диаграмма не дает достаточно подробностей для тестирования, поэтому нам также необходимо текстовое описание задействованных процессов.

Основное преимущество тестирования вариантов использования заключается в том, что оно связано с реальными пользовательскими процессами, поэтому оно дает возможность проверить весь процесс. Здесь можно применить принципы, применяемые в других местах: сначала протестируйте наиболее приоритетные (наиболее ценные) варианты использования на типичных примерах; затем предпримите несколько попыток неправильной последовательности процессов; а затем тренируйте границы.

ISTQB «Методы «черного ящика» дизайна тестов»