8 ноября 2010 г.

Decision Table Testing

Мы уже рассмотрели 2 техники тест дизайна:
Пришел черед Decision Table Testing.

Introduction
Decision Tables - хороший инструмент для фиксирования требований и описания функциональности приложения. Этими таблицами очень удобно описывать бизнес логику приложения, и в добавок они могут служить отличной основой для создания тест кейсов.


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


Aproach
Decision Tables описывают логику приложения основываясь сущностях(свойствах/условиях) состояния системы. Каждая decision table должна описывать 1 состояние системы. Шаблон таблицы решений следующий:


Правило 1Правило 2Правило p
Сущность
Свойство-1
Свойство-2

Свойство-m

Действия
Действие-1
Действие-2

Действие-n

Не бойтесь, скоро все станет понятно ;)

Сущность(conditions) от 1 до m - это разные свойства системы, они представляют в таблице входные данные, которые можно ввести в систему. Действия(actions) от 1 до n - это действия которые могут произойти с указанной комбинацией сущностей, в зависимости от комбинации всех входных данных сущностей, действия принимают нужные значения. Каждое правило определяет уникальный набор входных данных всех свойств, которые приводят к исполнению конкретных действий.


Правило для создания тест кейсов просто - создайте как минимум 1 тест кейс на каждое правило в таблице. Просто поменяйте имена столбцов.
Тест кейс 1Тест кейс 2Тест кейс p
Входные данные
Свойство-1
Свойство-2

Свойство-m

Ожидаемый результат
Действие-1
Действие-2

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



Пример 1. 2 бинарных сущности, 1 действие

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


Начнем со сущностей, их у нас всего 2 - был ли клиент хороший студент и состоит ли в браке. Каждое из свойств бинарное - т.е. может принимать значение либо true либо false.
Правило 1Правило 2Правило 3Правило 4
Сущность
Состоит в браке?YesYesNoNo
Хороший студент?YesNoYesNo
Эта таблица содержит все возможные комбинации значений наших сущностей(сущности - "Состоит в браке?" и "Хороший студент?").


Теперь разберемся с действиями. В зависимости от комбинации значений наших сущностей у нас вычисляется скидка - то есть скидка - это результат взаимодействия сущностей, то есть - это и есть наше действие.
Правило 1Правило 2Правило 3Правило 4
Сущность
Состоит в браке?YesYesNoNo
Хороший студент?YesNoYesNo
Действия
Скидка ($)6025500
Теперь мы явно видим какую форму примет действие при каких значениях сущностей.


Делать тест-кейсы по Decision table очень легко - создайте как минимум 1 тест кейс на каждое правило. Вот так:
Тест кейс 1Тест кейс 2Тест кейс 3Тест кейс 4
Входные данные
Состоит в браке?YesYesNoNo
Хороший студент?YesNoYesNo
Ожидаемый результат
Скидка ($)6025500
или вот так:
Test Case IDСостоит в браке?Хороший студент?Ожидаемый результат
TC1YesYesскидка = 60
TC2YesNoскидка = 25
TC3NoYesскидка = 50
TC4NoNoскидка = 0


Вот уже стало яснее :) Давайте разбираться дальше.

Пример 2. 4 бинарных сущности, 3 действия

Представим, что мы тестируем форму регистрации студентов. С помощью этой формы мы можем создавать, редактировать и удалять студентов из БД. Чтобы создать нового студента нужно ввести его имя, фамилию, адрес и нажать кнопку enter. Запись о студенте будет сохранена в БД и приложение вернет ID новосозданного студента. 

Для того чтобы отредактировать или удалить данные студента нужно ввести ID студента и выбрать радиобуттон Modify или Delete соответственно. 

По такому поводу я даже нарисовал пример формочки, чтобы ее было легче визуализировать :) 




Decision table опишет эту логику так:
Правило 1Правило 2Правило 3Правило 4Правило 5Правило 6Правило 7Правило 8Правило 9Правило 10Правило 11Правило 12Правило 13Правило 14Правило 15Правило 16
Сущность
Введены данные о студенте?NoNoNoNoNoNoNoNoYesYesYesYesYesYesYesYes
Введен ID студента?NoNoNoNoYesYesYesYesNoNoNoNoYesYesYesYes
Выбран Modify?NoNoYesYesNoNoYesYesNoNoYesYesNoNoYesYes
Выбран Delete?NoYesNoYesNoYesNoYesNoYesNoYesNoYesNoYes
Действие
Создать нового студентаNoNoNoNoNoNoNoNoYesNoNoNoNoNoNoNo
Отредактировать данные студентаNoNoNoNoNoNoYesNoNoNoYesNoNoNoNoNo
Удалить студентаNoNoNoNoNoYesNoNoNoNoNoNoNoNoNoNo
Примечание: Все сущности и действия специально сведены к бинарным значениям для простоты примера. В реальной жизни такие сущности как "данные о студенте", "ID студента" должны быть разобраны на сущности и представлены различными символьными и численными значениями, выбранными определенным образом.


После составления decision table, как правило, возможно упростить таблицу. Например убрать невозможные варианты - мы никогда не сможем указать одновременно радиобатан modify и delete (таких невозможных правила у нас четыре  - 4, 8, 12, 16).
Правило 1Правило 2Правило 3Правило 4Правило 5Правило 6Правило 7Правило 8Правило 9Правило 10Правило 11Правило 12
Сущность
Введены данные о студенте?NoNoNoNoNoNoYesYesYesYesYesYes
Введен ID студента?NoNoNoYesYesYesNoNoNoYesYesYes
Выбран Modify?NoNoYesNoNoYesNoNoYesNoNoYes
Выбран Delete?NoYesNoNoYesNo| NoYesNoNoYesNo
Действие
Создать нового студентаNoNoNoNoNoNoYesNoNoNoNoNo
Отредактировать данные студентаNoNoNoNoNoYesNoNoYesNoNoNo
Удалить студентаNoNoNoNoYesNoNoNoNoNoNoNo

После чего с легкостью преобразовываем таблицу решений в тест кейсы:
Тест Кейс 1Тест Кейс 2Тест Кейс 3Тест Кейс 4Тест Кейс 5Тест Кейс 6Тест Кейс 7Тест Кейс 8Тест Кейс 9Тест Кейс 10Тест Кейс 11Тест Кейс 12
Входные данные
Введены данные о студенте?NoNoNoNoNoNoYesYesYesYesYesYes
Введен ID студента?NoNoNoYesYesYesNoNoNoYesYesYes
Выбран Modify?NoNoYesNoNoYesNoNoYesNoNoYes
Выбран Delete?NoYesNoNoYesNo| NoYesNoNoYesNo
Ожидаемый Результат
Создать нового студентаNoNoNoNoNoNoYesNoNoNoNoNo
Отредактировать данные студентаNoNoNoNoNoYesNoNoYesNoNoNo
Удалить студентаNoNoNoNoYesNoNoNoNoNoNoNo

Вот собственно и всё, пользуйтесь на здоровье.

Этот пост является вольным переводом Chapter 5 из книги "A Practitioner'S Guide To Software Test Design" by Lee Copeland.

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

  1. Lee Copeland "A Practitioner'S Guide To Software Test Design"

    ОтветитьУдалить
  2. Первый абзац примера 2.4 в слове modify ошибочка (mofify). А в целом спс за инфу, полезно почитать начинающему тестеру)

    ОтветитьУдалить
  3. Simplex, спасибо за поправку - исправил.
    На здоровье :)

    ОтветитьУдалить
  4. Мелкие очепятки :-)
    "Свойства(conditions) от 1 до m - это разные свйоства(сущности), они представляют в таблице входные данные, которые можно ввести в систему."
    (СВОЙСТВА)
    "Чтобы создать нового студента нужно ввести Имя, фамилию и адресс студента и нажать кнопку enter."
    (АДРЕС)
    Наследие педунивера неистребимо :-D
    Спасибо за перевод, по-английски я бы это дооолго читала.

    ОтветитьУдалить
  5. Спасибо большое!Очень наглядное и понятное объяснение.

    ОтветитьУдалить
  6. Пожалуйста. Надеюсь будет полезно.

    ОтветитьУдалить
  7. Aproach пишется с двумя РР, и это не потому что я такой умный, а потому что я забыл это слово и полез в словарь :)

    ОтветитьУдалить
  8. Где ж ты Дима раньше был... Я уже столько апроачей с 1 п написал... На их апроачность конечно не влияет, но редактировать везде прийдется :)

    ОтветитьУдалить
    Ответы
    1. Анонимный1 окт. 2013 г., 9:57:00

      ненавижу вот эти все поправления, но в данном случае это почти забавно ) "придется" - правильно писать )

      Удалить
    2. Марь Ивановна, я думал вы меня после школы не найдете :) Ладно... обещаю вытянуть русский язык минимум на четверочку в этой четверти :)

      Удалить
    3. Анонимный2 окт. 2013 г., 7:44:00

      да ты ж мое золото )))) авансом 4 ставлю в журнал, не подведи! ))

      Удалить
    4. В последний раз когда мне такое говорили в школе я слинял в техникум :D

      Удалить
  9. Спасибо! Очень полезно для начинающего тестировщика и на русском языке! ...хотя знакомые советуют привыкать читать в оригинале (на английском) техническую литературу...Павел, а Вы этот блог ещё ведете? (rss не показала новых записей)

    ОтветитьУдалить
    Ответы
    1. Перебрал десяток интересных тем и ни про что не написал :D

      Сейчас читаю отличную книгу по тест дизайну, может что то навеит.

      Удалить
    2. А что за книга, подскажите?

      Удалить
    3. "Essential Software Test Design" by Torbjorn Ryber

      Удалить
  10. что тестируем тест кейсами №1, №10. Проосто смотрим на монитор- действительно хороший тест кейс, лучше не придумано за всё времена. Или я не понимаю логику?

    ОтветитьУдалить
    Ответы
    1. Нужно осуществить непосредственно ввод (нажать "Enter") и проконтролировать, что именно ничего не произошло, ничего не отредактировалось, не удалилось и не создалось.
      Если ввод не осуществить, то во всех кейсах можно просто в монитор смотреть.

      Удалить
  11. у нас есть четыре значения для ввода: данные студента, id, modify, delete. а если их будет больше? как перебрать все возможные комбинации и не запутаться? есть какая-то система

    ОтветитьУдалить
  12. Спасибо за статью. Тест кейсы 10, 11, 12 содержат противоречивые условия: одновременно вводятся данные для нового студента и для существующего. Может быть их тоже надо было исключить из рассмотрения?

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

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