Фирма

«Инрэко ЛАН»

Все описанное ниже основывается на книге Рекса Блэка "Advanced Software Testing". В первой статье были рассмотрены принципы построения и использования таблиц альтернатив, какие типы дефектов находятся с помощью этой методики. Во второй статье рассмотрена концепция диаграмм причинно-следственных связей. В этой статье будут рассмотрены принципы комбинирования этих методик с другими классическими методиками.

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

Как только платежная информация поступает для валидации в компанию, осуществляющую обработку кредитной карты, то существует целый набор условий, определяющий процесс обработки:

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

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

  • Нужно ли подтвердить транзакцию?
  • Нужно ли связаться с держателем карты (например, чтобы предупредить его о покупке из подозрительного места)?
  • Нужно ли связаться с эмитентом (например, чтобы попросить его конфисковать карту с истекшим сроком)?
Табл. 1. Пример таблицы альтернатив (свернутая)

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

Можно применить эквивалентное разбиение к вопросу "Как много интересующих - с точки зрения тестирования - случаев, когда счет не является действительным?" Как видно из рисунка 1, это может произойти в шести потенциально интересных случаях:

  • Несоответствие номера карты и держателя;
  • Несоответствие номера карты и даты истечения срока;
  • Несоответствие номера карты и секретного кода;
  • Два из перечисленных несоответствия (три варианта);
  • Все три несоответствия.
Рис. 1. Эквивалентное разбиение и таблицы альтернатив

Таким образом, для этого столбца может быть семь тестов.

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

Как видно из рисунка 2, эквивалентное разбиение и анализ граничных значений дают шесть случаев:

  • Счет начинается с нулевого баланса;
  • Баланс будет находиться в пределах нормы после транзакции;
  • Баланс будет точно на границе лимита после транзакции;
  • Баланс будет точно за границей лимита после транзакции;
  • Баланс был точно на границе лимита до транзакции (что точно приведет к его превышению, если транзакция завершится);
  • Баланс будет на максимальном значении овердрафта после транзакции (что может быть недопустимо).
Рис. 2. Анализ граничных значений и таблицы альтернатив

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

 Заключение

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

Андрей Конушин, ведущий инженер-тестировщик

Метки: тестирование

Добавить комментарий