суббота, 27 июля 2013 г.

Техники анализа классов эквивалентности и граничных значений

Предыдущее сообщение по теме обучения:
< Мысли об основах тест дизайна

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



Техника анализа классов эквивалентности

Определение


Наверное, вы догадываетесь, что полное тестирование даже простой программы невозможно. А если и возможно, но займет много лет.

Возьмем к примеру калькулятор. Сколько комбинаций входных параметров нужно протестировать? Давайте ограничимся только операцией сложения. 2 числа по 8 знаков – это 108*108= 1016 комбинаций. Если прикинуть, что на каждый тест мы потратим около 10 секунд, то время полного тестирования займет у нас 1017 секунд, то есть больше 3 миллиардов лет непрерывных тестов.

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

Как раз для этих целей используется техника разбиения на классы эквивалентности. Давайте дадим ей неформальное определение:

Это техника, которая заключается в разбиении всего набора тестов на классы эквивалентности с последующим сокращением числа тестов.

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

Цели техники анализа классов эквивалентности


Целью данной техники является не только сокращение числа тестов, но и сохранение приемлемого тестового покрытия.

Здесь мы видим конфликт между сокращением количества тестов и сохранением тестового покрытия, то есть [спасибо Евгению, см. комменты ниже] сохранением способности тестов находить ошибки. Но мы вынуждены идти на этот компромисс, если хотим сократить количество тестов.

При использовании этой техники тестировщик должен помнить о том, что:

  • Слишком большое количество эквивалентных классов увеличивает вероятность, что множество тестов будет лишним (избыточным).
  • Слишком малое число эквивалентных классов увеличивает вероятность, что ошибки продукта будут пропущены.

Эквивалентные тесты


Давайте договоримся о том, какие тесты мы будем считать эквивалентными.

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

Как можно использовать технику


Давайте перейдем от теории к практике.
Примерный алгоритм использования техники такой:

  1. Определить классы эквивалентности. Это главный шаг техники. От него во многом  зависит эффективность её применения.
  2. Затем нужно выбрать одного представителя от каждого класса. На этом шаге из каждого эквивалентного набора тестов мы выбираем один тест.
  3. Нужно выполнить тесты. На этом шаге мы выполняем тесты от каждого класса эквивалентности.
Если есть время, можно протестировать еще несколько представителей от каждого класса. Но нужно иметь в виду, что если мы правильно выполнили первый шаг, то есть правильно определили классы эквивалентности, то дополнительные тесты скорее всего будут избыточными и дадут тот же результат.

На первом шаге, когда мы определяем классы эквивалентности, нам могут здорово помочь программисты. Они могут подсказать, как программа ведет себя при тех или иных входных параметрах.

Можно разбивать тесты на классы эквивалентности по разным принципам. От этого эффективность нашего тестирования может выиграть. Например, если мы тестируем поле ввода, которое принимает максимум 5 символов, то мы можем выбрать разные принципы разбиения на классы эквивалентности:

  • По количеству символов
  • По типу символов (цифры, буквы, спец символы)

Пример использования техники

Давайте рассмотрим пример: функцию подсчета комиссии при отмене бронирования авиабилетов.




Предположим, что размер комиссии зависит от времени до вылета, когда совершена отмена:
  • За 5 суток до вылета комиссия составляет 0%
  • Меньше 5 суток, но больше 24 часов – 50% 
  •  Меньше 24 часов, но до вылета – 75%
  • После вылета – 100%
Теперь давайте пойдем по шагам:

1. Определим классы эквивалентности (для каждого теста из этих классов мы ожидаем получить одинаковый результат):
  • 1 класс: время до вылета > 5 суток
  • 2 класс: 24 часа < время до вылета < 5 суток
  • 3 класс: 0 часов < время до вылета < 24 часа
  • 4 класс: время до вылета < 0 часов (вылет уже состоялся) 
2. Выберем представителя от каждого класса. Здесь мы можем поступить, как нам хочется, и выбрать любые значения из класса. Ведь, если предположить, что мы правильно разбили на классы эквивалентности, то нет разницы, какое значение из диапазона мы выберем.
  • время до вылета = 10 суток (тест из 1-го класса)
  • время до вылета = 3 суток (тест из 2-го класса)
  • время до вылета = 12 часов (тест из 3-го класса)
  • время до вылета = -30 мин (тест из 4-го класса)
3. Выполним тесты:
  • Отменим бронь за 10 суток до вылета и проверим, что комиссия составила 0%.
  • Отменим бронь за 3 суток до вылета и проверим, что комиссия составила 50%.
  • Отменим бронь за 12 часов до вылета и проверим, что комиссия составила 75%. 
  • Отменим бронь через 30 мин после вылета и проверим, что комиссия составила 100%.

Мы видим, что у нас осталось всего 4 теста. А сколько возможных тестов существует?

Даже если мы введем ограничение, что отмена бронирования может произойти в рамках 10 суток до вылета и 1 суток после вылета, то у нас будет около 950400 возможных тестов (я посчитал количество секунд в 11 сутках).

Мы рассмотрели очень простой пример. Редко бывает так, что функция зависит только от одной переменной. Обычно классов эквивалентности больше и выделить их сложнее.

Плюсы и минусы техники анализа классов эквивалентности


Как и любая другая техника, анализа классов эквивалентности имеет достоинства и недостатки.

  • К плюсам можно отнести заметное сокращение времени и улучшение структурированности тестирования.
  • К минусам можно отнести то, что при неправильном использовании техники мы рискуем потерять баги.
Еще раз напомню важный принцип разбиения на классы эквивалентности:

  • Слишком большое количество эквивалентных классов увеличивает вероятность, что большинство тестов будет лишним (избыточным)
  • Слишком малое число эквивалентных классов, хоть и уменьшает время тестирования, но увеличивает вероятность, что ошибки продукта будут пропущены.

Тестировщик должен постоянно держать это в голове.

Он может сделать из этого вывод о том, что лучше перестраховаться и разбить набор тестов на большее число эквивалентных классов (или взять больше одного теста из каждого класса), чем сократить их число и пропустить ошибки.

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

Поэтому тестировщик должен подходить к разбиению на классы эквивалентности очень ответственно.

Техника анализа граничных значений

Определение 

Давайте рассмотрим вторую технику - анализ граничных значений.

Это техника проверки ошибок на границах классов эквивалентности.

Если техника анализа классов эквивалентности ориентирована на тестовое покрытие, то эта техника основана на рисках. Эта техника начинается с идеи о том, что программа может сломаться в области граничных значений.

А почему считается, что с граничными значениями связаны серьезные риски?

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

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

Цель техники анализа граничных значений


Цель этой техники сформулировать несложно - найти ошибки, связанные с граничными значениями.

Как можно использовать технику


Примерный алгоритм использования техники анализа граничных значений:

  1. Во-первых, нужно выделить классы эквивалентности. Опять же, это очень важный шаг, и от правильности разбиения на классы эквивалентности зависит эффективность тестов граничных значений.
  2. Далее нужно определить граничные значения этих классов.
  3. Нам нужно понять, к какому классу будет относиться каждая граница.
  4. Для каждой границы нам нужно провести тесты по проверке значения до границы, на границе, и сразу после границы.
Можно сказать, что количество тестов для проверки граничных значений будет равно количеству границ, умноженному на 3. Причем в литературе по тестированию рекомендуется проверять значения вплотную к границе. Скажем, если мы имеем диапазон целых значений, и граница у нас находится в числе 10, то мы будем проводить тесты с числом 9 (вплотную до границы), 10 (саму границу) и 11 (сразу после границы).

Пример использования


Давайте теперь вернемся к нашему примеру с бронированием и проведем тестирование граничных значений.



Пойдем по шагам: 

1. Выделим классы эквивалентности:
  • время до вылета > 5 суток
  • 24 часа =< время до вылета =< 5 суток
  • 0 часов < время до вылета < 24 часа
  • время до вылета =< 0 часов (вылет уже состоялся) 
2. Определим границы:
  1. 5 суток
  2. 24 часа
  3. 0 часов 
3. Определим, к какому классу относятся границы:
(Примечание: На этом шаге у меня был спорный момент, на который нужно обратить внимание. При составлении задачи я не подумал, какая логика должна быть на самих границах. Это типичный пример того, как составители требований не задумываются о границах. И поэтому программист может трактовать их по-своему.)

  1. 5 суток – к 2-му классу
  2. 24 часа – к 32-му классу [спасибо Анастасии за исправление, см. комментарий ниже]
  3. 0 часов – к 4-му классу 
4. Протестируем значения на границах, до и после них:
  1. Отменим бронь за 5 суток + 1 секунду до вылета (или просто постараемся выполнить бронь как можно ближе к границе, но слева от нее) и проверим, что комиссия равна 0%.
  2. Отменим бронь ровно за 5 суток до вылета и проверим, что комиссия равна 50%.
  3. Отменим бронь за 5 суток – 1 секунду до вылета и проверим, что комиссия равна 50%.
  4. Отменим бронь за 24 часа + 1 секунду до вылета и проверим, что комиссия равна 50%.
  5. Отменим бронь ровно за 24 часа до вылета и проверим, что комиссия равна 7550% [спасибо Анастасии за исправление, см. комментарий ниже].
  6. Отменим бронь за 24 часа - 1 секунду до вылета и проверим, что комиссия равна 75%.
  7. Отменим бронь за 1 секунду до вылета и проверим, что комиссия равна 75%.
  8. Отменим бронь ровно во время вылета и проверим, что комиссия равна 100%.
  9. Отменим бронь спустя 1 секунду после вылета и проверим, что комиссия равна 100%.

Мы получили 9 тестов, по 3 теста на каждую границу.

Если суммировать тесты, необходимые для проверки классов эквивалентности и граничных значений, получим 4 + 9 =13 тестов.

В некоторых источниках рекомендуется использовать классы эквивалентности и граничные условия вместе по следующим соображениям:

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

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

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

Плюсы и минусы техники


Можно выделить следующее преимущество техники анализа граничных значений: 

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

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

Материалы

Как мы уже говорили, о техниках анализа классов эквивалентности и граничных значений вы можете почитать почти во всех книгах по тестированию. Все-таки, это основные техники тест дизайна.

Предлагаю вам почитать о них в книгах (для каждой книги указаны страницы, на которых описываются данные техники):
  • Practitioner’s Guide to Software Test Design (Lee Copeland). Страницы 35-59.
  • Тестирование программного обеспечения (Канер, Фолк, Нгуен). Страницы 183-193.
  • Testing Web applications (Нгуен). Страницы 55-57.
  • Тестирование dot com (Савин). Страницы 195-202.
  • How we test software at Microsoft. Страницы 66-86.
Последнюю книгу я бы особенно выделил, потому что она фокусируется не только на том, какие преимущества дают нам эти техники, но и на том, как можно их использовать неправильно.

Практикум

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

Всем спасибо за внимание! Буду ждать ваших вопросов и замечаний в комментариях!

19 комментариев:

  1. Я бы все-таки сначала дала определение -что такое классы эквивалентности.
    И называла бы далее одинаково.

    )) и четче обрисовала нюанс - КАК выбирать классы эквивалентности? Что для этого нужно знать?

    ОтветитьУдалить
    Ответы
    1. Спасибо, Елена! Про эквивалентность тестов и входных параметров я писал в разделе Эквивалентные тесты, но лучше бы это было сделать в начале, согласен с вами!

      А про одинаковые названия - вы что имели в виду?

      Про лучшую обрисовку выбора классов - да, тут мой промах :) Несколько раз написал, что это самый важный шаг, но не уделил ему даже отдельного раздела.

      Удалить
    2. Ну про названия очень просто.
      Классы эквивалентности Вы выделяете из множества тестов. Так? Т.е. это подмножество тестов, выделенное по неким критериям.
      При этом еще есть эквивалентные тесты и эквивалентность входных данных, и еще ! эквивалентные классы. Видимо, эти понятия как-то связаны с классами эквивалентности для тестов. Из текста можно догадаться- что связь есть .

      Далее по тексту:
      "мы можем выбрать разные принципы разбиения на классы эквивалентности:

      • По количеству символов
      • По типу символов (цифры, буквы, спец символы)
      "

      А тут вроде уже вроде классы выделяются из множества строк (т.е. входных данных), которые можно ввести в поле.

      (Роман. Я еще техпишу понемногу. Отсюда - желание иметь четкие, однозначно понимаемые формулировки. Все-таки речь идет о Технике.)

      Теперь пример.
      Вы выделяете подмножества из множества (чего? видимо, тестов). Хорошо б тогда это множество очертить/определить.
      И еще. Вот этот момент:

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


      Удалить
    3. > Классы эквивалентности Вы выделяете из множества тестов. Так? Т.е. это подмножество тестов, выделенное по неким критериям.
      При этом еще есть эквивалентные тесты и эквивалентность входных данных, и еще ! эквивалентные классы. Видимо, эти понятия как-то связаны с классами эквивалентности для тестов. Из текста можно догадаться- что связь есть.

      Елена, я понял, что вы имеете в виду. Дело в том, что классы эквивалентности могут быть и у тестов, и у входных данных. И мне кажется, что необязательно разграничивать эквивалентность тестов от эквивалентности входных данных. Ведь эквивалентные тесты обычно имеют дело с эквивалентными входными данными. Поэтому я и смешивал эти понятия без объяснений :) Про четкие формулировки - думаю я не настолько хорошо теоретически подготовлен, чтобы их давать, поэтому скорее объясняю понятия так, как сам их понимаю.

      > А тут вроде уже вроде классы выделяются из множества строк (т.е. входных данных), которые можно ввести в поле.

      Наверное я слишком вольно и неявно использовал переходы от эквивалентности классов к эквивалентности входных значений, что вас и запутало :(

      > "Слишком большое количество эквивалентных классов увеличивает вероятность, что большинство тестов будет лишним (избыточным)".
      А как может получится, что выделено много лишних классов?

      Например, когда мы перестраховываемся и решаем, что какие-то конкретные тесты относятся к отдельному классу, нежели к тем классам, что мы уже выделили. Хотя основания отнести их к уже выделенным классам у нас есть. И много такой перестраховки приводит к тому, что эквивалентных классов у нас много и тестов для их проверки тоже нужно выполнить много. Это другая крайность, противоположная той, когда у нас слишком большие классы эквивалентности, и их слишком мало. Хотя, конечно, понятие "слишком большие классы эквивалентности" достаточно размыто. Решения о слишком больших и слишком маленьких классах эквивалентности - субъективны, и к тому же зависят от конкретного приложения.

      Спасибо вам за советы! Я еще только учусь писать, так что ваши профессиональные замечания приму во внимание.

      Удалить
  2. Очень странное неформальное определение классов эквивалентности. Из него следует(как я понял), что мы берем уже готовые тесты, разбиваем их на классы и потом еще сокращаем их(тестов) кол-во. Вы же ссылаетесь на множество разной литературы. Зачем Вам при этом писать какое-то странное неформальное определение, когда можно написать несколько определений от разных авторов. Так же как уже заметили выше, что самого определения "классы эквивалетности" тоже нет.
    "сохранением тестового покрытия, то есть сохранением способности тестов находить ошибки" - Почему Вы приравниваете тестовое покрытие к нахождению ошибок тестами? Покрывая определенный функционал тестами не означает что Вы найдёте какое-то гарантированное кол-во ошибок, просто Вы будете уверены что покрытый функционал работает или не работает.
    "К минусам можно отнести то, что при неправильном использовании техники мы рискуем потерять баги." Может быть рискуем что определенная функция будет не проверена? Или проверена, но не полностью?
    "Если техника анализа классов эквивалентности ориентирована на тестовое покрытие, то эта техника основана на рисках. Эта техника начинается с идеи о том, что программа может сломаться в области граничных значений." А эквивалентные классы говорят о том что программа может одинаково не работать при любом значении из определенного диапазона? Так в чем же принципиальная разница?
    "Если следовать этой рекомендации, то в нашем случае останется 9 тестов." Почему 9, а не 7? Одно значение в пределах класса, одно на границе.

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

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

      > "К минусам можно отнести то, что при неправильном использовании техники мы рискуем потерять баги." Может быть рискуем что определенная функция будет не проверена? Или проверена, но не полностью?

      Да, вы правы, и из-за того, что определенная функция не будет проверена или проверена не полностью, мы рискуем потерять баги. Вернее даже не потерять, а пропустить.

      > "Если техника анализа классов эквивалентности ориентирована на тестовое покрытие, то эта техника основана на рисках. Эта техника начинается с идеи о том, что программа может сломаться в области граничных значений." А эквивалентные классы говорят о том что программа может одинаково не работать при любом значении из определенного диапазона? Так в чем же принципиальная разница?

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

      > "Если следовать этой рекомендации, то в нашем случае останется 9 тестов." Почему 9, а не 7? Одно значение в пределах класса, одно на границе.

      Я считал так: по 3 теста на каждую границе (тот минимум, который нужен для использования предписания техники анализа граничных значений для проверки значений на границе, до границы, и после границы). А 7 тестов получается, если проверять значения на границах и не проверять все значения вокруг границ (хотя при этом мы покрываем все классы эквивалентности).

      Спасибо большое за ваши замечания и вопросы, Евгений! Вы мне здорово помогаете! Надеюсь вы будете так же активно комментировать мои сообщения и дальше!




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

      Удалить
    3. > Все верно, только Вам наверное стоит заменить выражение "масса тестов", на "массу входных значений".

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

      > Иначе получается, что мы уже написали массу тестов и теперь используя технику лишние тесты выкинем.

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

      > А должно быть так, что у нас есть масса входных\выходных значений и мы эту массу разбиваем на классы эквивалентности и уже после этого согласно технике составляем всего несколько тестов.

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

      Спасибо за ваши дельные замечания!

      Удалить
    4. Я просто не могу понять зачем Вы так всё усложняете и выворачиваете наизнанку простую технику.
      Допустим берём классическую трактовку данной техники:
      1. Выделяем из множества значений классы эквивалентности
      2. Для каждого класса пишем по одному позитивному тесту и два негативных теста.

      Ваша трактовка:
      1. Берем множество значений
      2. Прикидываем великое множество возможных тестов
      3. Разбиваем множество тестов на классы
      4. Выбираем из множества выдуманных тестов каждого класса нужные тесты

      Результат по сути тот же, но действий в два раза больше.

      Удалить
    5. На самом деле я тоже описал трактовку из двух шагов, можете посмотреть в примере использования. Разница с классической трактовкой, о которой вы говорите - в том, что у меня описана работа с эквивалентными классами тестов, а в этой трактовке - с эквивалентными классами значений.

      Кстати, а почему в вашей трактовке говорится о 2-х негативных тестах? Имеется в виду проверка значений больше и меньше диапазона данного эквивалентного класса значений?

      Удалить
    6. Да, рекомендуют проверять значения за пределами диапазона. Обычно получается два негативных теста и один позитивный.

      Удалить
  3. Неточности при выделении классов в анализе граничных значений.

    Исходный вариант:

    " время до вылета > 5 суток
    24 часа =< время до вылета < 5 суток
    0 часов < время до вылета < 24 часа
    время до вылета < 0 часов (вылет уже состоялся)

    Определим, к какому классу относятся границы:

    5 суток – к 2-му классу
    24 часа – к 3-му классу
    0 часов – к 4-му классу "

    Более корректный, на мой взгляд, вариант:

    " 1) время до вылета > 5 суток
    2) 24 часа =< время до вылета =< 5 суток
    3) 0 часов =< время до вылета < 24 часа (минуты и секунды учитываются, например, 0 ч 1 сек)
    4) время до вылета < 0 часов (вылет уже состоялся)

    5 суток – ко 2-му классу
    24 часа – ко 2-му классу
    0 часов – к 3-му классу"

    Перевод техник из книги Ли Копланд: http://w1zle.blogspot.ru/2010/11/equivalence-class-testing.html

    Анастасия

    ОтветитьУдалить
    Ответы
    1. И отдельное спасибо за ссылку на перевод книги! Сам когда-нибудь планирую заняться переводом интересных зарубежных ресурсов.

      Удалить
  4. Да, Анастасия, вы правы! Спасибо вам большое! С 24 часами я точно совершил ошибку, отнеся эту границу ко 3-му классу. Познакомился с коварностью граничных значений :-) Насчёт 0 - сознательно отнес её к 4-му классу.

    ОтветитьУдалить
  5. 24 часа =< время до вылета =< 5 суток
    0 часов < время до вылета < 24 часа
    время до вылета =< 0 часов (вылет уже состоялся)

    лучше использовать правильный оператор больше или ровно (<=)

    ОтветитьУдалить
    Ответы
    1. Спасибо! Даже не задумывался над этим. =< как грустный смайлик :-)

      Удалить
  6. Классный блог)

    Жду еще постов...

    ОтветитьУдалить
    Ответы
    1. Спасибо большое, постараюсь найти время :-)

      Удалить
  7. Анастасия заделилась ссылкой:

    Перевод техник из книги Ли Копланд: http://w1zle.blogspot.ru/2010/11/equivalence-class-testing.html

    Дошёл до "Пример 2. Несколько сущностей."

    Увидел сущность "Способ оплаты" и варианты:
    1) Оплата картой,
    2) интернет деньги,
    3) наличные

    Далее следовал комментарий:
    "Для тестирования способа оплаты мы должны выбрать значение «Оплата картой», «интернет деньги» или «наличные». Это тот случай, когда здравый смысл должен победить любые правила :) Хотя правило предлагает нам выбрать одно значение из класса эквивалентности, здесь будет лучше проверить каждое из них. Это имеет смысл потому что здесь входных значений немного. "

    Мне хватило несколько секунд на то, что бы молниеносным движением закрыть вкладку с этим материалом.

    ОтветитьУдалить