Мы уже рассмотрели 2 техники тест дизайна:
Introduction
Decision Tables - хороший инструмент для фиксирования требований и описания функциональности приложения. Этими таблицами очень удобно описывать бизнес логику приложения, и в добавок они могут служить отличной основой для создания тест кейсов.
Если на тестируемое приложение нет адекватной документации, то это хороший повод использовать decision tables. Представляя требования в простой и компактной форме будет легко создавать тест кейсы.
Aproach
Decision Tables описывают логику приложения основываясь сущностях(свойствах/условиях) состояния системы. Каждая decision table должна описывать 1 состояние системы. Шаблон таблицы решений следующий:
Не бойтесь, скоро все станет понятно ;)
Сущность(conditions) от 1 до m - это разные свойства системы, они представляют в таблице входные данные, которые можно ввести в систему. Действия(actions) от 1 до n - это действия которые могут произойти с указанной комбинацией сущностей, в зависимости от комбинации всех входных данных сущностей, действия принимают нужные значения. Каждое правило определяет уникальный набор входных данных всех свойств, которые приводят к исполнению конкретных действий.
Правило для создания тест кейсов просто - создайте как минимум 1 тест кейс на каждое правило в таблице. Просто поменяйте имена столбцов.
По моему немного путано пока выглядит... Давайте разбирать на примерах.
Пример 1. 2 бинарных сущности, 1 действие
Представим, что тестируем приложение для страховой компании. Это приложение вычисляет скидку на страхование автомобилей, взаимозависимости от того, был ли водитель хорошим студентом и состоит ли он в браке. Как вычисляется скидка от этих условий покажем сразу с помощью decision table.
Начнем со сущностей, их у нас всего 2 - был ли клиент хороший студент и состоит ли в браке. Каждое из свойств бинарное - т.е. может принимать значение либо true либо false.
Эта таблица содержит все возможные комбинации значений наших сущностей(сущности - "Состоит в браке?" и "Хороший студент?").
Теперь разберемся с действиями. В зависимости от комбинации значений наших сущностей у нас вычисляется скидка - то есть скидка - это результат взаимодействия сущностей, то есть - это и есть наше действие.
Теперь мы явно видим какую форму примет действие при каких значениях сущностей.
Делать тест-кейсы по Decision table очень легко - создайте как минимум 1 тест кейс на каждое правило. Вот так:
или вот так:
Вот уже стало яснее :) Давайте разбираться дальше.
Пример 2. 4 бинарных сущности, 3 действия
Представим, что мы тестируем форму регистрации студентов. С помощью этой формы мы можем создавать, редактировать и удалять студентов из БД. Чтобы создать нового студента нужно ввести его имя, фамилию, адрес и нажать кнопку enter. Запись о студенте будет сохранена в БД и приложение вернет ID новосозданного студента.
Для того чтобы отредактировать или удалить данные студента нужно ввести ID студента и выбрать радиобуттон Modify или Delete соответственно.
По такому поводу я даже нарисовал пример формочки, чтобы ее было легче визуализировать :)
Decision table опишет эту логику так:
Примечание: Все сущности и действия специально сведены к бинарным значениям для простоты примера. В реальной жизни такие сущности как "данные о студенте", "ID студента" должны быть разобраны на сущности и представлены различными символьными и численными значениями, выбранными определенным образом.
После составления decision table, как правило, возможно упростить таблицу. Например убрать невозможные варианты - мы никогда не сможем указать одновременно радиобатан modify и delete (таких невозможных правила у нас четыре - 4, 8, 12, 16).
После чего с легкостью преобразовываем таблицу решений в тест кейсы:
Вот собственно и всё, пользуйтесь на здоровье.
Этот пост является вольным переводом Chapter 5 из книги "A Practitioner'S Guide To Software Test Design" by Lee Copeland.
Пришел черед Decision Table Testing.
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 | |
Сущность | ||||
Состоит в браке? | Yes | Yes | No | No |
Хороший студент? | Yes | No | Yes | No |
Теперь разберемся с действиями. В зависимости от комбинации значений наших сущностей у нас вычисляется скидка - то есть скидка - это результат взаимодействия сущностей, то есть - это и есть наше действие.
Правило 1 | Правило 2 | Правило 3 | Правило 4 | |
Сущность | ||||
Состоит в браке? | Yes | Yes | No | No |
Хороший студент? | Yes | No | Yes | No |
Действия | ||||
Скидка ($) | 60 | 25 | 50 | 0 |
Делать тест-кейсы по Decision table очень легко - создайте как минимум 1 тест кейс на каждое правило. Вот так:
Тест кейс 1 | Тест кейс 2 | Тест кейс 3 | Тест кейс 4 | |
Входные данные | ||||
Состоит в браке? | Yes | Yes | No | No |
Хороший студент? | Yes | No | Yes | No |
Ожидаемый результат | ||||
Скидка ($) | 60 | 25 | 50 | 0 |
Test Case ID | Состоит в браке? | Хороший студент? | Ожидаемый результат |
TC1 | Yes | Yes | скидка = 60 |
TC2 | Yes | No | скидка = 25 |
TC3 | No | Yes | скидка = 50 |
TC4 | No | No | скидка = 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 | |
Сущность | ||||||||||||||||
Введены данные о студенте? | No | No | No | No | No | No | No | No | Yes | Yes | Yes | Yes | Yes | Yes | Yes | Yes |
Введен ID студента? | No | No | No | No | Yes | Yes | Yes | Yes | No | No | No | No | Yes | Yes | Yes | Yes |
Выбран Modify? | No | No | Yes | Yes | No | No | Yes | Yes | No | No | Yes | Yes | No | No | Yes | Yes |
Выбран Delete? | No | Yes | No | Yes | No | Yes | No | Yes | No | Yes | No | Yes | No | Yes | No | Yes |
Действие | ||||||||||||||||
Создать нового студента | No | No | No | No | No | No | No | No | Yes | No | No | No | No | No | No | No |
Отредактировать данные студента | No | No | No | No | No | No | Yes | No | No | No | Yes | No | No | No | No | No |
Удалить студента | No | No | No | No | No | Yes | No | No | No | No | No | No | No | No | No | No |
После составления decision table, как правило, возможно упростить таблицу. Например убрать невозможные варианты - мы никогда не сможем указать одновременно радиобатан modify и delete (таких невозможных правила у нас четыре - 4, 8, 12, 16).
Правило 1 | Правило 2 | Правило 3 | Правило 4 | Правило 5 | Правило 6 | Правило 7 | Правило 8 | Правило 9 | Правило 10 | Правило 11 | Правило 12 | |
Сущность | ||||||||||||
Введены данные о студенте? | No | No | No | No | No | No | Yes | Yes | Yes | Yes | Yes | Yes |
Введен ID студента? | No | No | No | Yes | Yes | Yes | No | No | No | Yes | Yes | Yes |
Выбран Modify? | No | No | Yes | No | No | Yes | No | No | Yes | No | No | Yes |
Выбран Delete? | No | Yes | No | No | Yes | No | | No | Yes | No | No | Yes | No |
Действие | ||||||||||||
Создать нового студента | No | No | No | No | No | No | Yes | No | No | No | No | No |
Отредактировать данные студента | No | No | No | No | No | Yes | No | No | Yes | No | No | No |
Удалить студента | No | No | No | No | Yes | No | No | No | No | No | No | No |
После чего с легкостью преобразовываем таблицу решений в тест кейсы:
Тест Кейс 1 | Тест Кейс 2 | Тест Кейс 3 | Тест Кейс 4 | Тест Кейс 5 | Тест Кейс 6 | Тест Кейс 7 | Тест Кейс 8 | Тест Кейс 9 | Тест Кейс 10 | Тест Кейс 11 | Тест Кейс 12 | |
Входные данные | ||||||||||||
Введены данные о студенте? | No | No | No | No | No | No | Yes | Yes | Yes | Yes | Yes | Yes |
Введен ID студента? | No | No | No | Yes | Yes | Yes | No | No | No | Yes | Yes | Yes |
Выбран Modify? | No | No | Yes | No | No | Yes | No | No | Yes | No | No | Yes |
Выбран Delete? | No | Yes | No | No | Yes | No | | No | Yes | No | No | Yes | No |
Ожидаемый Результат | ||||||||||||
Создать нового студента | No | No | No | No | No | No | Yes | No | No | No | No | No |
Отредактировать данные студента | No | No | No | No | No | Yes | No | No | Yes | No | No | No |
Удалить студента | No | No | No | No | Yes | No | No | No | No | No | No | No |
Вот собственно и всё, пользуйтесь на здоровье.
Этот пост является вольным переводом Chapter 5 из книги "A Practitioner'S Guide To Software Test Design" by Lee Copeland.
откуда перевод?
ОтветитьУдалитьLee Copeland "A Practitioner'S Guide To Software Test Design"
ОтветитьУдалитьПервый абзац примера 2.4 в слове modify ошибочка (mofify). А в целом спс за инфу, полезно почитать начинающему тестеру)
ОтветитьУдалитьSimplex, спасибо за поправку - исправил.
ОтветитьУдалитьНа здоровье :)
Мелкие очепятки :-)
ОтветитьУдалить"Свойства(conditions) от 1 до m - это разные свйоства(сущности), они представляют в таблице входные данные, которые можно ввести в систему."
(СВОЙСТВА)
"Чтобы создать нового студента нужно ввести Имя, фамилию и адресс студента и нажать кнопку enter."
(АДРЕС)
Наследие педунивера неистребимо :-D
Спасибо за перевод, по-английски я бы это дооолго читала.
Спасибо, поправил.
ОтветитьУдалитьСпасибо большое!Очень наглядное и понятное объяснение.
ОтветитьУдалитьПожалуйста. Надеюсь будет полезно.
ОтветитьУдалитьAproach пишется с двумя РР, и это не потому что я такой умный, а потому что я забыл это слово и полез в словарь :)
ОтветитьУдалитьГде ж ты Дима раньше был... Я уже столько апроачей с 1 п написал... На их апроачность конечно не влияет, но редактировать везде прийдется :)
ОтветитьУдалитьненавижу вот эти все поправления, но в данном случае это почти забавно ) "придется" - правильно писать )
УдалитьМарь Ивановна, я думал вы меня после школы не найдете :) Ладно... обещаю вытянуть русский язык минимум на четверочку в этой четверти :)
Удалитьда ты ж мое золото )))) авансом 4 ставлю в журнал, не подведи! ))
УдалитьВ последний раз когда мне такое говорили в школе я слинял в техникум :D
Удалитьспасибо
ОтветитьУдалитьПожалуйста ^_^
ОтветитьУдалитьСпасибо! Очень полезно для начинающего тестировщика и на русском языке! ...хотя знакомые советуют привыкать читать в оригинале (на английском) техническую литературу...Павел, а Вы этот блог ещё ведете? (rss не показала новых записей)
ОтветитьУдалитьПеребрал десяток интересных тем и ни про что не написал :D
УдалитьСейчас читаю отличную книгу по тест дизайну, может что то навеит.
А что за книга, подскажите?
Удалить"Essential Software Test Design" by Torbjorn Ryber
Удалитьчто тестируем тест кейсами №1, №10. Проосто смотрим на монитор- действительно хороший тест кейс, лучше не придумано за всё времена. Или я не понимаю логику?
ОтветитьУдалитьНужно осуществить непосредственно ввод (нажать "Enter") и проконтролировать, что именно ничего не произошло, ничего не отредактировалось, не удалилось и не создалось.
УдалитьЕсли ввод не осуществить, то во всех кейсах можно просто в монитор смотреть.
=))
ОтветитьУдалитьу нас есть четыре значения для ввода: данные студента, id, modify, delete. а если их будет больше? как перебрать все возможные комбинации и не запутаться? есть какая-то система
ОтветитьУдалитьСпасибо за статью. Тест кейсы 10, 11, 12 содержат противоречивые условия: одновременно вводятся данные для нового студента и для существующего. Может быть их тоже надо было исключить из рассмотрения?
ОтветитьУдалитьВо втором примере на сколько я понимаю принципы работы радиобаттон она позволяет выбрать только один из вариантов то есть либо удалить либо изменить, выбрать оба свойства она не позволит. Так что можно смело вычеркнуть 4 правила из таблици. Для данного примера подходит чекбокс
ОтветитьУдалить"недостаточно" наречие и пишется вместе
ОтветитьУдалитьhttps://russkiiyazyk.ru/orfografiya/pravopisanie/nedostatochno-ne-dostatochno.html
Этот комментарий был удален автором.
ОтветитьУдалитьЕсть хороший online сервис, который облегчает генерацию таких таблиц: http://decision-table.com/
ОтветитьУдалитьМне кажется в 9 кейсе (если смотреть самую последнюю таблицу) ошибка. Мы вводим данные студента, выбираем Mobify и почему-то редактируем данные студента. Хотя в условии сказано что редактируем при вводе id студента и выборе Modify.
ОтветитьУдалитьФинансиско обновување со помош на Педро Џером. Е-пошта: pedroloanss@gmail.com тоа е неговата е-пошта и ова е неговиот број на whatsapp +18632310632. Јас сум Леонардо Хуго, агроном кој можеше да го оживее своето Производство на добиточна храна што умира преку помош на заемодавачот од GodSent познат како Педро Џером, службеникот за заем. Сакам да знаете дека неговата Служба е вистинското место каде што можете да ги решите сите ваши финансиски проблеми, бидејќи јас сум живо сведоштво и не можам само да го задржам ова за себе кога другите бараат начин да бидам финансиски подигнат. Сакам сите да го контактирате овој заемодавач што го испрати Бог користејќи ги деталите како што е наведено со цел да бидете учесник во оваа одлична можност, а исто така тие работат со добра/реномирана банка која без одлагање префрла пари на мојата сметка.
ОтветитьУдалитьНа днях я смотрел эту книгу до того как увидел твой перевод.
ОтветитьУдалитьВ книге есть ошибка и ты ее сюда перенёс
это фрагмнт описания таблицы из книги:
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.
То есть в описании автор указал верно, но в таблице ошибка.
если я не прав то дайте знать