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.

32 комментария:

  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. ненавижу вот эти все поправления, но в данном случае это почти забавно ) "придется" - правильно писать )

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

      Удалить
    3. да ты ж мое золото )))) авансом 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 правила из таблици. Для данного примера подходит чекбокс

    ОтветитьУдалить
  14. "недостаточно" наречие и пишется вместе
    https://russkiiyazyk.ru/orfografiya/pravopisanie/nedostatochno-ne-dostatochno.html

    ОтветитьУдалить
  15. Этот комментарий был удален автором.

    ОтветитьУдалить
  16. Есть хороший online сервис, который облегчает генерацию таких таблиц: http://decision-table.com/

    ОтветитьУдалить
  17. Мне кажется в 9 кейсе (если смотреть самую последнюю таблицу) ошибка. Мы вводим данные студента, выбираем Mobify и почему-то редактируем данные студента. Хотя в условии сказано что редактируем при вводе id студента и выборе Modify.

    ОтветитьУдалить
  18. Финансиско обновување со помош на Педро Џером. Е-пошта: pedroloanss@gmail.com тоа е неговата е-пошта и ова е неговиот број на whatsapp +18632310632. Јас сум Леонардо Хуго, агроном кој можеше да го оживее своето Производство на добиточна храна што умира преку помош на заемодавачот од GodSent познат како Педро Џером, службеникот за заем. Сакам да знаете дека неговата Служба е вистинското место каде што можете да ги решите сите ваши финансиски проблеми, бидејќи јас сум живо сведоштво и не можам само да го задржам ова за себе кога другите бараат начин да бидам финансиски подигнат. Сакам сите да го контактирате овој заемодавач што го испрати Бог користејќи ги деталите како што е наведено со цел да бидете учесник во оваа одлична можност, а исто така тие работат со добра/реномирана банка која без одлагање префрла пари на мојата сметка.

    ОтветитьУдалить
  19. На днях я смотрел эту книгу до того как увидел твой перевод.
    В книге есть ошибка и ты ее сюда перенёс

    это фрагмнт описания таблицы из книги:

    Rules 9 through 16 indicate that data was entered about the student. Rules 9 through 12
    indicate that no StudentID was entered so these rules refer to a new student. Rule 9 creates a
    new student. Rule 10 deletes the student. Rule 11 allows modification of the student's data.
    Rule 12 requests that both modification and deletion are to be performed so no action is taken.
    Rules 13 through 16 supply student data indicating a new student but also provide a StudentID
    indicating an existing student. Because of this contradictory input, no action is taken. Often,
    error messages are displayed in these situations.

    Обрати внимание на Rule 10 deletes the student.
    То есть в описании автор указал верно, но в таблице ошибка.
    если я не прав то дайте знать

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