Программирование • 27 декабря 2022 • 5 мин чтения
Как таблица решений помогает провести все тест-кейсы и ничего не забыть
Учимся использовать один из самых простых методов тест-дизайна
- Зачем нужна таблица принятия решений
- Преимущества и недостатки метода
- Как составить таблицу принятия решений за шесть шагов
- Как работать с таблицей принятия решений
- Примеры таблиц принятия решений
- Совет эксперта
Таблица принятия решений — инструмент тест-дизайна, или процесса создания тестов. Таблица помогает придумать, как и что тестировать в программном обеспечении, например на сайте или в приложении. Её можно использовать для проверки требований, собранных для разработки ПО, например проверять, что учтены все возможные варианты.
Правил и условий может быть неограниченное количество, но чем их больше, тем неудобнее работать с таблицей. Действие обычно одно или два, но это число тоже ничем не ограничено
Ячейки таблицы заполняются с опорой на три параметра, которые расположены в шапке и первом столбце. Всё начинается с условий работы системы, выбранных из требований. Далее идут правила, которые отражают выполнение условий. Завершается таблица действиями — это результаты, которые наступают при соблюдении правил.
Допустим, тестировщик работает над системой скидок в продуктовом магазине. Скидка зависит от частоты совершения покупок и их суммы. Матрица в этом случае может выглядеть так.
Таблицей принятия решений преимущественно пользуются тестировщики — если знают, как её строить, и имеют на это достаточно времени. Кроме тестировщиков таблица может быть полезна продакт-менеджеру или системному аналитику.
Зачем нужна таблица принятия решений
Один из принципов тестирования звучит так: избыточное тестирование невозможно. Поэтому тестировщик вынужден выбирать, на что потратить время и какой метод выбрать, чтобы собрать максимум информации о работоспособности продукта или системы за минимальное время.
Таблица помогает ничего не пропустить и не держать в голове миллион вариантов.
Таблица принятия решений полезна там, где есть требования, которые описывают несколько разных исходов ситуации в зависимости от условий. Например, с ней будет удобно рассчитать скидку в магазине, размер бонусов или кэшбэка, процентную ставку по ипотеке. Таблица поможет собрать все условия в одном месте и убедиться, что требования полные и непротиворечивые.
В примере с расчётом скидки в продуктовом магазине таблица неполная. На первый взгляд в ней всё логично, но что будет, если человек делает покупки четыре раза в неделю, но каждый раз только на 500 рублей? Научиться видеть такие нюансы помогают наставники на курсе «Инженер по тестированию». Пройти первый блок можно бесплатно.
Начните карьеру в IT с профессии тестировщика
Спустя 4 месяца обучения в вашем портфолио будет 6 протестированных приложений. Пройдите бесплатную вводную часть курса, чтобы попробовать себя в роли тестировщика.
Преимущества и недостатки метода
Таблица принятия решений в тестировании не единственный инструмент. Она не универсальна, но нельзя сказать, что это недостаток. С помощью таблицы не получится проверить корректность ввода логина или пароля — потому, что условий может быть слишком много. Придётся вносить в таблицу миллионы комбинаций из букв, цифр и специальных символов, и всё это с учётом регистра. Это только усложнит работу тестировщика, поэтому для проверки полей ввода обычно используют другие инструменты, например классы эквивалентности и граничные значения.
Таблица не подойдёт для тестирования линейных процессов — например, экранов приложения, где пользователь может нажать только одну кнопку вроде «Согласен» или «Принять».
На экране только одна кнопка «Далее», поэтому для таблицы принятия решений будет только одно условие — кнопка нажата, — и правила: «да» и «нет». Ради двух проверок нет смысла составлять матрицу, поэтому можно обойтись без неё
Несмотря на ограничения, такая техника, как таблица принятия решений при правильном использовании имеет больше преимуществ, чем недостатков.
Наглядность. Это главное преимущество метода. Вместо того, чтобы текстом описывать тест-кейсы и бояться что-то упустить, можно составить матрицу и быть уверенным, что ни одна проверка не потеряется.
Удобство. Один столбец таблицы — один готовый тест-кейс.
Простота. Таблицу решений можно составить в Google-таблице, Excel, на бумаге или даже на салфетке, если хочется. Чтобы использовать метод, не нужно уметь писать код или осваивать специальную программу.
Долго. Главный минус метода: для составления таблицы нужно время, которого всегда не хватает. Иногда тестировщик думает, что проще потратить полчаса-час на тестирование, а не на составление таблицы.
Иногда к недостаткам таблицы принятия решений относят её громоздкость: количество кейс тестов в столбцах считается по формуле Nm, где N – это количество вариантов ответа на каждое условие, а m — количество условий. Каждое новое условие увеличивает таблицу в геометрической прогрессии, поэтому в какой-то момент она становится неудобной для восприятия. Но это не недостаток метода, а лишь сигнал, что тестировщик неверно использует инструмент или для данной ситуации это не подходит, и стоит подумать над другой техникой тест-дизайна.
Кто такой инженер по тестированию и как им стать, чтобы начать IT-карьеру
Как составить таблицу принятия решений за шесть шагов
Алгоритм составления таблицы следующий:
-
Выписать в первый столбик все условия, по одному в каждой строке.
-
Рассчитать и построить необходимое количество столбцов. Например, если для каждого условия два варианта ответа — «да» или «нет», то правил будет 2(количество условий).
-
В каждый столбец выписать варианты ответов на условия так, чтобы комбинации получались разные. Сначала все «да», потом все промежуточные варианты с «да» и «нет», потом только все «нет».
-
Создать в строке после условий строку с действиями. Под каждым столбцом записать, какое будет решение для данной ситуации.
-
Оптимизировать таблицу: например, удалить столбцы, решения для которых быть не может, и скомпоновать условия, которые дают одинаковый результат. Либо спросить о них у аналитика или продакт-менеджера, если есть сомнения.
-
Использовать получившиеся столбцы как тесты.
После составления таблицы решений в столбцах оказываются готовые текст-кейсы. Их можно не расписывать, а просто идти по столбцам и ставить галочки.
Кейсы в таблице решений помогают освежить взгляд даже на те требования, с которыми тестировщик работает давно
Как работать с таблицей принятия решений
С готовой таблицей решений можно поступить минимум двумя способами:
1. Оптимизировать.
В таблице могут содержаться близкие по смыслу условия. Например, которые касаются одного параметра: цены, возраста, количества заказов. Условие «купленный товар дороже 500 рублей, но дешевле 2000» можно записать по-разному.
Обе записи верные, но вторая сократит количество столбцов таблицы и упростит работу.
2. Инвертировать.
Если тестировщик привык читать таблицы не по столбцам, а по строкам, матрицу можно «перевернуть». Тогда в строках окажутся текст-кейсы, а в последнем столбце — решение для каждого.
Инвертировать можно таблицу любого размера — на ее функциональность расположение столбцов и строк не влияет
Примеры таблиц принятия решений
Допустим, тестировщик проверяет работу формы выдачи кредита на сайте банка. Из требований он знает, что кредит выдаётся со следующими условиями:
● На момент рассмотрения заявки человеку больше 18 лет.
● На момент рассмотрения заявки человеку меньше 55 лет.
● Если ежемесячные выплаты меньше трети ежемесячного дохода, то стандартный процент, иначе — +1%.
● Кредит не выдаётся безработным.
У тестировщика есть четыре условия и два правила — «да» и «нет». Это значит, что количество столбцов будет рассчитываться через степень двойки: 24 = 16.
Так будет выглядеть таблица для тестирования страницы с формой выдачи кредита по четырём условиям. В матрице 16 правил
Первые два условия можно оптимизировать, так как они оба касаются возраста. Тогда получится три условия, а количество столбцов сократится вдвое.
Условия о возрасте получателя кредита можно объединить в одно, тогда число столбцов — это 23, то есть 8
Совет эксперта
Ольга Ермолаева
Какой бы замечательной техника ни была, не используйте её только ради того, чтобы использовать. В каждой конкретной ситуации перед началом работы надо анализировать, что больше подойдёт, какой инструмент, какие техники. Прежде чем заводить таблицу в Excel или Google-таблицах, задайте себе несколько вопросов: что даст использование этой техники именно здесь? Как лучше применить технику? Какие условия выбрать и как правильно их скомпоновать?
Всегда смотрите на картину целиком, и только потом идите в частности. Ведь самый главный и универсальный инструмент тестировщика — его голова. Пользуйтесь этим прекрасным инструментом всегда!
Тот ещё жук: как начинающему тестировщику составить хороший баг‑репорт
Тестирование мобильных приложений: инструкция для начинающих
Время на прочтение
5 мин
Количество просмотров 86K
Decision Table (таблица решений) — техника, помогающая наглядно изобразить комбинаторику условий из ТЗ.
Чем проще и понятнее требования, тем меньше будет разночтений. И тем меньше исправлений после реализации. И тем проще нам, тестировщикам, писать тест-кейсы по таким требованиям.
В тестировании таблица решений используется для того, чтобы на основе требований составить тест-кейсы. И ничего не забыть при сложных комбинациях входных условий! Ведь каждая строка или столбец таблицы → готовый тест-кейс.
Decision Table относится к техникам тест-дизайна. Значит, про неё спрашивают на собеседованиях. И поэтому я сделаю небольшой цикл статей по таким техникам в помощь начинающим тестировщикам. Чтобы ознакомиться с каждой техникой:
-
Вариант использования
-
Decision Table (таблицы решений) — текущая статья
-
State & Transition Diagramm (схема состояний и переходов)
-
Другие диаграммы, схемы, картинки (бонус такой к техникам)
Сегодня говорим про Decision Table (таблица решений):
-
Как составлять таблицу
-
Плюсы подхода
-
Минусы подхода
-
Итого
Помимо статьи есть видео о таблице решений с моего канала. Кому что удобнее! 🙂
Как составлять таблицу
-
По горизонтали — выписываем условия, которые влияют на результат. А чуть ниже — сам результат, в оригинале Action — действие, которое нужно выполнить.
-
По вертикали — правила: конкретная комбинация входных условий.
То есть мы указываем значения условий и результата
|
Правило 1 |
Правило 2 |
… |
Правило N |
|
|
Условия |
||||
|
Условие 1 |
||||
|
Условие 1 |
||||
|
… |
||||
|
Условие N |
||||
|
Действия |
||||
|
Действие 1 |
||||
|
Действие 2 |
||||
|
… |
||||
|
Действие N |
Давайте посмотрим на простом примере — когда у нас один результат (action).
Пример 1. Страховка на автомобиль (один результат)
Я прихожу в страховую компанию и заполняю анкету, где есть 2 вопроса:
-
Есть ли 5 лет стажа вождения?
-
Была ли в авариях?
Ответить можно либо да, либо нет.
Получается 2 условия по 2 возможных варианта, итого 4 варианта пересечения условий, 4 правила. На каждое правило свой результат:
-
Если у меня небольшой стаж и я часто бываю в авариях — придется заплатить по максимуму, иначе страховать такого водителя будет невыгодно.
-
Если нет стажа, но нет аварий — плачу поменьше, но не сильно. Знаете как бывает — первое время катаются очень осторожно, а потом начинают думать «да я царь и бог, не попаду в аварию». И понеслось…
-
Если я опытный водитель, но бываю в авариях — ценник еще чуть ниже. Ведь бывать в авариях — это нормально. Иногда ты просто стоишь на светофоре, а в тебя влетает дурак, ну что тут поделаешь? Но если аварий мало, а опыта много — это хороший знак.
-
Если опытный, да еще и без аварий — меньше всего. Очень аккуратный водитель, платить скорее всего не придется!
А теперь то же самое, только в виде таблички:
|
Правило 1 |
Правило 2 |
Правило 3 |
Правило 4 |
|
|
Условия |
||||
|
Стаж 5 лет |
Нет |
Нет |
Да |
Да |
|
Был в авариях? |
Да |
Нет |
Да |
Нет |
|
Результат |
||||
|
Страховка |
200 руб |
100 руб |
50 руб |
10 руб |
Согласитесь, табличка выглядит лучше стены текста выше, да? Еще лучше может быть только картинка!
Но для красивой картинки нужно уметь рисовать. А для составления таблички — нет! И в этом её удобство — можно не быть художником, но наглядно переписать ТЗ.
Когда текста много, можно что-то пропустить. В виде таблицы намного понятнее, компактнее и мы сразу видим 4 теста, которые надо провести.
У нас может быть не 2 условия, а 3 или больше. И действий тоже может быть больше одного. Получается больше правил и больше возможности их скомбинировать:
|
Правило 1 |
Правило 2 |
… |
Правило N |
|
|
Условия |
||||
|
Условие 1 |
Нет |
Нет |
Да |
Да |
|
Условие 2 |
Да |
Нет |
Нет |
Да |
|
Условие 3 |
Нет |
Нет |
Да |
Да |
|
Действия |
||||
|
Действие 1 |
Do X |
Do Y |
Do X |
Do Z |
|
Действие 2 |
Do A |
Do B |
Do B |
Do A |
Именно для таких случаев и применяется техника — чтобы не запутаться в требованиях, аккуратно выписываем их в табличку.
Пример 2. Интернет-магазин (множественный результат)
Есть интернет-магазин, который предлагает:
-
Скидку постоянного покупателя
-
Количество вещей, которые курьер привезет бесплатно
Это такие плюшки за лояльность и повторную покупку. Как плюшки высчитываются? Есть два условия:
-
Сколько клиент потратил (всего или за какой-то период времени) — бонус добавляется при достижении 100р, 500, 1000 и 5000
-
Какой процент выкупа (а то, может, курьер зря мотается) — бонус получаем при достижении 5%, 30%, 50% и 80%
Если я потратила 100р и почти ничего не выкупила — скидки мне не дадут и вещей мало привезут. Если потратила больше и выкупила больше, то дадут небольшую скидочку. Ещё потрачу — станут вещей больше привозить… И так далее.
Положим требования в таблицу:
|
Правило 1 |
Правило 2 |
… |
Правило N |
|
|
Условия |
||||
|
Потратил |
100 |
500 |
1000 |
5000 |
|
Выкуп |
5% |
30% |
50% |
80% |
|
Плюшка |
||||
|
Скидка |
0% |
6% |
10% |
20% |
|
Кол-во вещей |
2 |
8 |
15 |
20 |
Заметьте, что условия 2, и в каждом возможны 4 варианта — это 16 возможных пересечений, 16 тестов!
Попробуем записать все условия:
Даже в виде таблицы уже сложновато читается… А в виде простого текста вообще ничего не разберешь!
Конечно, интернет-магазин явно не будет мудрить, скорее всего они просто завяжут одну плюшку на одно условие:
-
Потратил 100 р — 0% скидка
-
500 — 5%
-
1000 — 10%
-
5000 — 20%
А количество вещей будет зависеть от выкупа… Тогда и без таблички можно оставить в ТЗ, вполне понятный список!
Но сложные взаимосвязи между разными условиями также встречаются. И если они у вас есть — составьте decision table хотя бы один раз. Чтобы разобраться во всех этих правилах, всё учесть и ничего не забыть!
Плюсы подхода
1. Наглядность — таблица нагляднее текста. Можно взять таблицу и подойти к аналитику с каким-то вопросом. Или к разработчику. Им будет проще понять, о чём речь, чем если вы принесете стену текста.
2. Нарисовал таблицу = записал тест-кейсы. Поменял в заголовках слово «правило» на «тест-кейс», и вот они, готовые тесты! И это будут основные позитивные тесты, которые мы проводим в первую очередь.
Если неудобно, что тест приходится читать сверху вниз, а не слева направо, таблицу можно инвертировать — перевернуть:
|
Тест-кейсы |
Условие 1: Потратил |
Условие 2: Выкуп |
Результат |
|
Кейс 1 |
100 |
5% |
Do X / Do A |
|
Кейс 2 |
500 |
30% |
Do X / Do Y |
|
Кейс 3 |
1000 |
50% |
Do B / Do C |
|
Кейс 4 |
5000 |
80% |
Do B / Do Z |
3. Наглядность поможет найти баги в документации. Так как косяк формулы будет сразу бросаться в глаза.
4. Таблица помогает взглянуть на ТЗ свежим взглядом, по-новому. Пока мы пытаемся перекомбинировать условия, составляя таблицу, мы можем заметить пропущенный ранее баг.
Минусы подхода
Особых минусов нет, но таблица не нужна, если:
-
Слишком простое условие — потому что «но зачем?». И так все понятно.
-
Слишком много входных данных — овер дофига будет колонок. Много тестов, но мало результата, потому что тут уже нужен тест-анализ, pairwise и т.д.
Итого
Decision Table используется для описания сложных системных правил:
-
Условия представляют собой входные данные.
-
Действия – это ожидаемый результат.
-
Колонки – тест-кейсы!
Я настоятельно рекомендую применять эту технику хотя бы однократно — к тем требованиям, которые вы уже знаете наизусть. Думаете, проверили все возможные комбинации? Нарисуйте таблицу решений и результат вас удивит!
Отлично подходит для размыливания взгляда и действительно сложных ТЗ, когда таблица получается на 100 колонок. Поддерживать ее довольно накладно и вряд ли кто-то будет это делать, а вот одноразовая акция найдет баги!
См также:
Как составлять вариант использования — ещё один вариант оформления требований.
State & Transition Diagramm (схема состояний и переходов) — и ещё ))
Визуализация ТЗ — диаграммы, схемы, картинки — про картинки
PowerPoint как инструмент тестировщика — да, так тоже можно было =)
PS — больше полезных статей ищите в моем блоге по метке «полезное». А полезные видео — на моем youtube-канале
Продолжаем разбирать техники тест дизайна. В прошлых частях 1, 2, 3 мы разобрали Классы эквивалентности. В этой продолжаем разбирать остальные.
Таблицы принятия решений
Требования на проектах часто создаются аналитиками в виде сплошного текста с множеством условий. Это предложения вида «если …, то …» Например: «Если пользователь старше 16 лет, то доступ на сайт разрешён», «Если пользователь авторизован в системе, то его личные данные в форме заказа должны быть заполнены автоматически». Тестирование таких требований и создание на их основе тест-кейсов становится трудоёмким — необходимо повышенное внимание. Для таких случаев можно использовать технику тест-дизайна «Таблицы принятия решений».
Таблицы принятия решений (таблицы решений) — способ компактного представления модели со сложной логикой. А ещё это техника тестирования чёрного ящика, которая применяется для систем со сложной логикой.
Таблицы принятия решений используют, чтобы упорядочить и задокументировать сложную логику приложения, а также протестировать все комбинации условий и состояний.
Рассмотрим сущности, из которых состоят таблицы.
Условия (conditions) — короткое описание входных условий (данных), сформулированное в виде вопроса. Ответ на него должен содержать либо «да/нет», либо ограниченный набор значений. Например: «Пользователь авторизован в системе?», «Вид документа, предоставленный клиентом, — паспорт, водительские права, загранпаспорт?»
Действия (actions) — чёткое описание ожидаемого результата, действия системы. Формулировка действия — утвердительное предложение. Одно предложение обязательно описывает только одно действие. Например: «Данные заполнены автоматически», «Сообщение об ошибке отображается на экране».
Значения (values) — значения, допустимые для входных данных, указанных в условии. Например: «да/нет», «Паспорт, водительские права, загранпаспорт».
Правила (rules) — комбинации входных данных, которые отражены в таблице.
Рассмотрим составление таблицы на примере.
Требование: для поддержания системы лояльности провести информационную рассылку постоянным клиентам.
Содержание писем зависит от следующих условий:
- Клиенты типа А, В получают стандартное письмо.
- Клиенты типа С получают специальное письмо.
Клиентам, совершившим пять и более покупок или купившим на сумму более 500 долларов, в письме сообщается о дополнительной скидке 20% на следующий заказ.
Начнём составлять таблицу по плану:
- Разбить требование на условия.
- Посчитать количество возможных правил (комбинаций).
- Составить таблицу принятия решений.
- Исключить лишние комбинации, если они есть.
- Создать тесты.
Разберём каждый пункт.
1. Разбить требование на условия.
В данном случае можно выделить три условия:
- тип клиента;
- пять и более покупок;
- сумма больше 500 долларов.
2. Посчитать количество возможных правил (комбинаций).
Расчёт можно выполнить по формуле: X = Y1 ⋅ Y2 ⋅ … ⋅ Yn, где:
- Х — вычисляемое количество комбинаций;
- Y1…Yn — количество вариантов каждого условия;
- N — количество условий.
Таким образом получим:
- Y1 = 4 (четыре значения для условия «Тип клиента» — «A, B, C, D»);
- Y2 = 2 и Y3 = 2 (по два значения для условий «Пять и более покупок» и «Сумма больше 500 долларов» — «YES/NO»);
- N = 3 (требование содержит три условия);
- X = 4 ⋅ 2 ⋅ 2;
- Х = 16 правил (комбинаций условий).
3. Составить таблицу принятия решений.
Заносим в таблицу условия, значения и правила следующим образом:
В таблицу был добавлен тип клиента «D» — это все остальные типы клиентов (если существуют), если будут выявлены те, что не подпадают под характеристики для клиентов типа «А, В, С». Для правил, которые не отражены в требованиях, использован «?» (в требованиях не указано, какое письмо должно быть отправлено в ситуации, когда сочетаются условия «более пяти покупок» и «сумма больше 500 долларов», а также как поступить с клиентами типа D). Ситуации, помеченные знаком вопроса, надо прояснить с аналитиком или заказчиком.
Первая строка в таблице формируется так: количество всех правил (комбинаций) делится на количество значений первого условия. То есть 16 (число правил) делим на 4 (число значений для условия «Тип клиента»). Получаем ряд из четырёх одинаковых значений подряд (см. таблицу выше). Заполняя остальные строки, необходимо соблюдать последовательность: каждая следующая строка — это предыдущая строка, разделённая пополам. То есть в первой строке каждое значение повторялось четыре раза подряд, во второй — два раза, в третьей уже происходит чередование значений. Если бы в таблице было ещё одно условие, то в следующей строке каждое значение снова повторялось бы четыре раза, потом два раза и так далее.
Также в таблице указываем действия, которые произойдут при совпадении тех или иных условий. И отмечаем, какое именно действие выполняется при совпадении условий. В данном случае выделим четыре действия: «Стандартное письмо», «Специальное письмо», «Сообщение о скидке», «Не получают письмо».
4. Исключить/добавить комбинации.
В этом случае были добавлены комбинации для дополнительного типа клиента «D». Также могут возникать ситуации, когда в таблице появятся комбинации условий, которые на практике невозможны. Например, если тестируется форма с двумя кнопками «Сохранить» и «Отменить», каждая кнопка имеет два значения: «Нажата» / «Не нажата». Одновременно обе кнопки не могут принимать значение «Нажата» — значит, такая комбинация должна быть исключена из таблицы.
5. Создать тесты.
В результате получаем тестовые сценарии, которые можно либо перенести в тест-кейсы, либо оставить в таблице и добавить строку с результатом проверки.
Повторим: таблицы принятия решений хорошо работают для систем со сложной логикой, в которых используется много условий типа «Если …, то …»
Плюсы таблиц принятия решений:
- помогают быстро составлять тестовые сценарии;
- позволяют выявить неполноту требований;
- их можно использовать при отсутствии требований;
- можно быстро проверить покрытие требований тест-кейсами;
- позволяют предугадывать возможные ошибки.
Минусы:
- при большом количестве условий таблицы могут быть громоздкими — их сложно составлять и использовать;
- сложность в корректном определении условий, действий и значений при первоначальном проектировании.
Исследовательское тестирование
Исследовательское тестирование не всегда относят к техникам тест-дизайна. Но по результатам исследовательского тестирования также могут составляться тест-кейсы. Поэтому рассмотрим его как технику. Напомним, что исследовательское тестирование — это подход, когда тестировщик не использует тест-кейсы, а тестирует приложение по определённому сценарию, который часто составляется прямо во время проверки.
Тестировщик проводит исследовательское тестирование приложения, в результате которого выявляются дефекты. Тот сценарий (тест), который выявил дефект, нужно задокументировать (создать тест-кейс), чтобы в дальнейшем проверять, что дефект исправлен и не появился вновь. Кроме того, стоит создать тест-кейсы (если они отсутствуют) и для проверки похожих сценариев, чтобы обнаружить другие подобные дефекты. В некоторых случаях проверки, проведённые при исследовательском тестировании, следует документировать (создавать тест-кейс), даже если они не обнаружили дефект. Это нужно, чтобы повторять эти проверки в будущем, в том числе при регрессионном тестировании.
Таким образом, использование исследовательского тестирования как техники тест-дизайна позволяет дополнять наборы тест-кейсов новыми тестами, а также создавать актуальные тест-кейсы, которые выявляют дефекты.
Исследовательское тестирование также используется как вспомогательный подход к тестированию по тест-кейсам. Оно помогает исключить эффект пестицида (когда тест-кейсы перестают выявлять дефекты) при частом использовании одних и тех же тест-кейсов.
Рассмотрим ещё случаи, когда исследовательское тестирование может быть эффективным:
- Необходимо быстро понять, насколько качественно выполнена новая функциональность: проверить, что в ней нет критических дефектов.
- Нужно быстро изучить тестируемый продукт (например, новому тестировщику на проекте) и получить общую информацию о его основной функциональности.
- Требуется проконтролировать работу других тестировщиков: проверить без использования тест-кейсов, что приложение работает (с позиции пользователя).
- Недостаточно времени для составления тест-кейсов.
- Отсутствуют требования, на основании которых можно составить тест-кейсы.
- Тестируется небольшой проект, для которого не требуется структурированного подхода к тестированию.
- В проекте произошли внезапные изменения, которые требуют быстрой проверки.
Плюсы исследовательского тестирования:
- не нужно тратить время на предварительное описание всех сценариев;
- не нужна поддержка тестовых сценариев;
- не происходит привыкания к тестовым сценариям, их прохождение не происходит «не глядя»;
- не теряется цельное видение продукта;
- критические дефекты находятся быстрее;
- повышается скорость тестирования;
- можно сразу начинать тестировать продукт, даже если требований нет вообще;
- исследовательское тестирование интереснее и креативнее (тесты ограничиваются только фантазией и глубиной знаний о продукте).
Минусы:
- сложно планировать время на проведение тестирования без задокументированных заранее сценариев;
- вероятность пропустить ключевые проверки, так как отсутствует ранжирование сценариев по степени важности;
- сложность оценки полноты покрытия требований тестами;
- требуется высокая квалификация тестировщиков и хорошее знание тестируемого приложения;
- сложно использовать для регрессионного тестирования;
- невозможно автоматизировать такое тестирование.
Важно понимать, что исследовательское тестирование — не хаотичное, без документации и подготовки. Этот подход требует планирования и профессиональных навыков тестировщика. Есть решения, позволяющие сделать исследовательское тестирование более структурированным:
- использование чит-листов — списков базовых проверок, которые можно применять для тестирования однотипных приложений;
- сессионное тестирование — установка временного интервала для проведения исследовательского тестирования, например сессии в 90 минут;
- парное тестирование — проверка одного блока или модуля двумя тестировщиками, один из которых может проводить тестирование, а второй — описывать найденные дефекты;
- тест-туры Джеймса Уиттакера — отдельная тема в исследовательском тестировании.
Тест-туры — неформальный подход к исследовательскому тестированию, который позволяет сделать его ещё более осмысленным и интересным. Они содержат инструкции по исследованию приложения — по аналогии с тем, как турист изучает город. Более подробно с этим способом работы с приложением можете познакомиться в этих статьях:
Исследовательское тестирование и исследовательские туры Виттакера
Как искать баги — исследовательские туры Уиттакера
Исследовательское тестирование можно использовать как технику для проектирования тест-кейсов — нужно помнить о такой возможности.
В этой статье мы рассмотрели 2 техники тест-дизайна: таблицы принятия решений и исследовательское тестирование. Они помогают сделать тестирование эффективнее. Конечно, для применения этих техник на практике нужны навыки — они нарабатываются постепенно. Главное — помнить о существовании этих техник и пробовать внедрять их, учитывая особенности проекта.
- Зачем нужна
- Пример
- Преимущества и недостатки
- Советы по составлению
- Контрольные вопросы / Собеседование
Когда QA тестирует систему с комплекскной бизнес-логикой, ему бывает сложно написать тест-кейсы со всеми возможными комбинациями ввода-вывода: их получается слишком много. Что обычно тестировщики делают в такой ситуации? Пишут тест-кейсы и параллельно продумывают возможные комбинации. Здесь возникает вероятность упустить какие-то сценарии, поскольку внимание рассредоточено между двумя задачами — описаниями тест-кейсов и продумыванием сценариев/комбинаций.
Отличный метод не упустить все возможные сценарии — сделать таблицу решений (Decision Table, DT), где решения описаны в наглядной, легко читаемой форме.
Что это и зачем нужна
Это методика тестирования системы при разных комбинациях на входе, и результатов на выходе. “Системный” подход, организованный, тем и удобный.
Цель тестирования по этой методике — повысить общее тестовое покрытие, не упуская все (возможные) комбинации.
Пример
Например у тестировщика есть страница с логином-паролем.
Имеем требования:
- Пользователь должен залогиниться, вводя правильные User ID/Password.
- Пользователь не должен залогиниться, если комбинация неправильная; выдается сообщение “Неверные данные”, если любое из двух значений неправильное (или пустое).
Глядя на требования, видим, что наша Таблица Решений будет состоять из:
- Двух условий: user_id и password
- Двух действий: Логин успешный; или Ошибка, выдается сообщение “Некорректные данные”
- Трех опций: Пустое; Правильное; Неправильное; (поле)
Теперь заполняем нашу Decision Table:
Готово!
Общее количество тест-кейсов: (опции)^(условия) = 3^2 = 9 тест-кейсов.
Пример 2
Передача на сервер фотографии. Имеем ограничения (требования):
- Исключительно JPEG
- Не превышает 32 Кб
- Разрешение (соотношение сторон) исключительно 137х177
При несоответствии любому из 3 требований система выдает ошибку, с описанием что случилось. Если все 3 требования соблюдены, фотография загружается на сервер.
Формируем нашу таблицу:
| Требования : | Кейс 1 | Кейс 2 | Кейс 3 | Кейс 4 | Кейс 5 | Кейс 6 | Кейс 7 | Кейс 8 |
| Формат | .jpeg | .jpeg | .jpeg | .jpeg | ≠.jpeg | ≠.jpeg | ≠.jpeg | ≠.jpeg |
| Размер | < 32 Кб | < 32 Кб | > или = 32 Кб | > или = 32 Кб | < 32 Кб | < 32 Кб | > или = 32 Кб | > или = 32 Кб |
| Соотношение | 137*177 | ≠ 137*177 | 137*177 | ≠137*177 | 137*177 | ≠137*177 | 137*177 | ≠137*177 |
| Ошибка | Фотография загружена (все ОК) | Недопустимое Соотношение | Ошибка: недопустимый размер | Ошибка: недопустимые размер и соотношение | Ошибка: недопустимый формат | Ошибка: недопустимые формат и соотношение | Ошибка: недопустимые формат и размер | Ошибка: недопустимые формат, размер и соотношение |
Из наших условий следует, что должно быть 8 кейсов.
Преимущества и недостатки метода
Плюсы
- Проверяются все возможные комбинации
- Легко найти какие-то упущенные требования
- Более полное покрытие тест-кейсами, поэтому потом не переписываются сценарии и тест-кейсы
- Сложные бизнес-требования подаются в наглядной форме, удобной пользователям, разработчикам, и разумеется тестировщикам
Минусы
- Бывает довольно сложной при отсутствии требований или неясно сформулированных требованиях
- Таблицы “разрастаются” при большом количестве входных значений, теряя простоту, то есть главное свое преимущество. Ведь количество комбинаций, как известно, равно 2 в степени n, где n = количество вводов
Таблица решений считается “полной” (или сбалансированной”), если содержит все возможные комбинации входных переменных; иными словами, “полная” таблица решений — это когда прописано действие по каждой имеющейся комбинации входных переменных.
Очень древняя методика — применялась еще в 1960х и 1970х для обработки бизнес-логики; создали даже специальные языки программирования под такие задачи.
Советы по составлению
- Классифицируй и сгруппируй условия и действия
- Таблица решений должна иметь только одну “точку входа”
- И может иметь много “точек выхода”
- Правила можно прописывать в любом порядке, но лучше если они логично сгруппированы
- Если есть два условия, одно из которых противоположно другому, убери одно из них
- Максимальное количество колонок у тебя не должно получиться больше чем 2^n, n = количество условий
Контрольные вопросы / Собеседование QA Junior — Таблица решений
Что такое таблица решений?
В более широком смысле: табличное представление процесса принятия решений. В QA: удобнейшая методика тестирования комбинаций вводов (и связанных с ними) выводов, организованных в табличном виде; в таблице решений “вводы” это условия, “выводы” это действия.
Для чего нужна таблица принятия решений? Как ее можно использовать?
Применяется, главным образом, в тестировании черного ящика. Очень помогает в дизайне тест-кейсов. Полезна при обработке сложных бизнес-требований с множеством условий.
Какие компоненты входят в таблицу решений?
Таблица решений — это двухмерная матрица, в которой есть четыре компонента: Заголовок условия (condition stub), Заголовок действия (action stub), Условие (condition entry), и Действие (action entry) — рисунок ниже.
Более простыми словами, таблица решений состоит из условий (в заголовках строчек и колонок), и действий (в точках пересечения условий).
Компоненты таблицы решений:
Какие основные этапы составления таблицы принятия решений?
- Проанализировать требования и создать первую колонку
- Добавить еще колонки, в количестве 2^(количество условий)
- Сократить таблицу при необходимости, убрав ненужные колонки если они идентичные
- Определить и прописать действия в таблице
- Далее написать тест-кейсы.
Одним
из методов тестирования программ по
стратегии ‘черного ящика’ является
метод функциональных диаграмм. Он хорошо
вписывается в методы структурного
анализа, реализующиеся в современных
CASE-средствах
разработки программного обеспечения.
Этот метод излагается в /1/, требует
предварительного изучения методики
построения функциональных диаграмм, в
силу чего является достаточно сложным
для начинающих программистов. Однако
интерес представляет тот факт, что метод
сводится к получению в качестве
промежуточного результата таблицы
решений и составления тестов по этой
таблице. Некоторые методики структурного
анализа также включают тестирование
спецификаций, полученных методами,
обладающими недостаточными процедурными
возможностями (они перечислены первыми
среди методов специфицирования процессов
в пункте 1.2.).
Тестирование ТР
заключается в том, что проектируется
такое количество тестов, которое
позволяет покрыть все возможные
комбинации условий. Как правило,
количество этих тестов совпадает с
числом столбцов в ТР. Так, для рассмотренного
в пункте 1.2 примера выбора символов из
входного потока (см. таблицу 1.2), необходимо
реализовать 4 теста:
а) символ из входного
потока является управляющим;
б) во входном потоке
символов больше, чем помещается в буфере
формируемой строки и ни один символ из
входного потока не является управляющим;
в) во входном потоке
символов меньше, чем вмещает буфер
формируемой строки, среди них нет
управляющих символов, но присутствуют
символы, не входящие в диапазон от ‘а’
до ‘я’;
г) во входном потоке
символов меньше, чем вмещает буфер
формируемой строки и все символы
принадлежат диапазону от ‘а’ до ‘я’.
Метод достаточно
прост, позволяет эффективно проверить
соответствие разработанной программы
ее внешним спецификациям, но не всегда
позволяет выявить случаи, когда программа
делает то, что спецификацией не
предусмотрено. Кроме того, спецификация
может содержать ошибки, которые при
таком тестировании выявлены не будут,
особенно если результаты тестирования
являются правдоподобными. Предварительное
построение сначала функциональных
диаграмм, а затем ТР позволяет осуществлять
логический контроль спецификации
сначала на уровне функциональных
диаграмм, а затем уже на уровне ТР, что
значительно снижает вероятность ошибок
в спецификации.
В заключении
рассмотрим вопрос об областях применения
методов стратегии ‘черного ящика’.
Обращает на себя
внимание тот факт, что все методы
рассматриваются на разных примерах.
Это не является случайностью, так как
не любой метод тестирования спецификаций
может быть эффективно применен для
разрабатываемой программы. Методы
эквивалентного разбиения и функциональных
диаграмм, как правило, применяются при
разработке языковых процессоров,
трансляторов и т.п. Метод граничных
условий применяется при тестировании
программ, осуществляющих статистическую
обработку входной информации. Метод
тестирования внешних спецификаций
может быть применен везде, где в качестве
спецификаций процессов обработки
используются таблицы или деревья решений
/8/.
Однако на практике
можно рекомендовать сочетание таких
методов, как функциональных диаграмм,
таблиц решений и эквивалентного разбиения
с методом граничных значений хотя бы
для таких граничных условий, которые
представляются достаточно явными.
Например, при обработке информации из
файлов такими явными граничными условиями
является пустые файлы данных, файлы с
пропущенными записями или с повторяющимися
записями для тех спецификаций, где
повторения не должно быть.
Соседние файлы в папке Лекции по ТП
- #
- #
- #
- #
- #
- #
- #
- #
- #
Таблица принятия решений(Decision table) — это один из вариантов компактного документа, представляющий бизнес-модель с трудным обоснованием требований и являющийся теоретическим средством для оптимизации и упорядочивания.
Простыми словами, взаимозависимости условий и операций в требованиях и при совместном исполнении приводящих к конкретному результату.
Таблица принятия решений состоит из 5-и блоков:
| Условия | Значения для исполнения действий |
| Действия | Правила исполнения условий |
| Статус тестирования |
Условия (conditions) — листинг критериев.
Действия (actions) — листинг потенциальных операций.
Значения для исполнения действия (values) — входные значения, указанные в требованиях; совокупность исполняемых критериев листинга.
Правила исполнения условий (rules) — директива на выполнение образующейся операции путем выполнения сочетания условий.
Статус тестирования (status) — статус проведения тестирования: passed, failed, draft, blocked.
Ситуации применения таблиц принятия решений вытекают из целей техник состояний и переходов. Когда существует необходимость упорядочивания, документирования логики системы и тестирования всех комбинаций. Данная потребность возникает, когда в требованиях есть, например, сплошной текст с множеством условий.
Алгоритм составления таблицы решений:
- разложить требования на условия
- высчитать количество комбинаций
Комбинации для таблицы рассчитываются по формуле: X = Y1 ⋅ Y2 ⋅ … ⋅ Yn, где:
- Х — количество комбинаций;
- Y1…Yn — количество вариантов условий;
- N — количество условий
- разложить требования на действия
- сформировать таблицу решений (Decision table)
- удалить лишние действия
- сформировать тесты
Плюсы и достоинства использования таблиц принятия решений:
- оперативное составление тестовых сценариев;
- выявляет неполноту требований;
- использование таблиц при отсутствии требований;
- проверка полноты покрытия требований тест-кейсами;
- предугадывание дефектов.
Минусы и недостатки использования таблиц принятия решений:
- при масштабном продукте есть трудность в составлении и использовании;
- при первоначальном проектировании не всегда условия могут быть корректны.
Дополнительно для составления таблиц полезна информация из психологии о «Квадрате Декарта»:
- Что будет, если это произойдет?
Какое действие получается после события
- Что будет, если это не произойдет?
Какое действие, в случае отсутствия события
- Чего НЕ будет, если это произойдет?
Какое действие мы не получим, если выполним условие 1.
- Чего НЕ будет, если это НЕ произойдет?
Какое действие мы не получим, если будет отсутствовать событие
По большому счёту, образованная таблица решений, после анализа требований, должна покрывать вышеперечисленные вопросы.
Пример таблицы принятия решений на основании требований
Заявку на получение кредита может подать заемщик старше 25 лет. Если он уже является клиентом банка, его заявка будет рассмотрена в индивидуальном порядке, и сумма кредита будет выдана выше. Если заемщик является клиентом банка, его заработная плата выше 25 тыс. руб. и он имеет в собственности какую-либо недвижимость, то он может рассчитывать на сумму кредита выше 1 000 000 руб. Если у заемщика-клиента банка заработная плата больше 25 тыс. руб., но в собственности нет недвижимости, то он может получить кредит в размере от 500 000 до 1 000 000 руб. Если заработная плата заемщика-клиента банка ниже 25 тыс. руб., но в его собственности есть недвижимость, то он может рассчитывать на кредит в сумме от 100 000 до 500 000 руб. Если заработная плата заемщика-клиента банка составляет меньше 25 тыс. руб. и у него в собственности нет недвижимости, то максимальная сумма кредита, на которую он может рассчитывать – 100 000 руб. Если заемщик не является клиентом банка, имеет доход выше 25 тыс. руб. и недвижимость в собственности, то ему может быть выдан кредит в размере от 500 000 до 1 000 000 руб. Если заемщик – не клиент банка, его заработная плата ниже 25 тыс. руб. и в собственности есть недвижимость, то сумма кредита – до 100 000 руб. Если заемщик не клиент банка, имеет заработную плату выше 25 тыс. руб., но не имеет недвижимости в собственности, то сумма кредита составить от 100 000 до 500 000 тыс. руб. Если заемщик не клиент банка с заработной платой меньше 25 тыс. руб. и без недвижимости – в кредите ему должно быть отказано.
Из вышеперечисленного можем выделить 4 условия:
- Клиент Банка(Y,N)
- ЗП больше 25 тыс. рублей(Y,N)
- Недвижимость(Y,N)
- Старше 25 лет (Y,N)
В каждом из условий находится по 2 параметра (Y,N). Исходя из формулы, получаем следующее:
N = 4, Y1 = 2, Y2 = 2, Y3 = 2, Y4 = 2.
X = 2 * 2 * 2 * 2
X = 16
16 комбинаций условий.
Определим для каждого теста, согласно требованиям, действие(операцию):
- Отказано
- До 100 тыс. рублей
- От 100 тыс. рублей до 500 тыс. рублей
- От 500 тыс. рублей до 1 млн. рублей
- Выше 1 млн. рублей
Для наглядности сформируем UML (Unified Modeling Language) схему по заявленным требованиям:
По описанным бизнес требованиям не определено:
- действия, производимые с лицами младше 25 лет
- действия, производимые до суммы, указанной в требованиях.
Аналогичным тестам проставляется статус тестирования «Draft». Для действий, не отражающихся в требованиях, используется «?».
Первая строка сформирована по правилу: количество комбинаций разделить на количество значений первого условия. В данном случае 16 / 2(Y,N). Последующие образуются аналогично, делением предыдущего значения на количество условий.
Пример таблицы принятия решений на основании требований
Для людей, сдавших на категорию прав в автошколе, производить рассылку электронных уведомлений. Регламент отправки и содержания письма зависит от условий:
- Водители с категорией B, C получают уведомление согласно регламенту «Выдача категории B, C»
- Водители с категорий A получают уведомление согласно регламенту «Выдача категории A»
Для водителей, сдавших в 2021 году и заплативших более 30 000 рублей за обучение, высылается дополнительное уведомление о скидке в 30% на обучение категории B,C.
В конкретном примере, в отличие от прошлого, не имеет смысла рисовать схему, но для практики и дальнейшему обучению, настоятельно рекомендую.
Получаем 3 условия:
- Категория водителей (A, B, C)
- Год сдачи 2021 (Y, N)
- Оплата более 30 000 рублей (Y, N)
Вычисляем количество комбинаций:
N = 3
Y1 = 3, Y2 = 2, Y3 = 2.
X = 3 * 2 * 2
X = 12
В итоге получаем 12 комбинаций в таблице принятия решений.
Для требований обозначим следующие действия:
- Письмо по регламенту «Выдача категории B, C»
- Письмо по регламенту «Выдача категории A»
- Уведомление о скидке в 30% на обучение категории B,C
Составляем таблицу решений:
Для действий, не отражающихся в требованиях, используется «?»
Из таблицы видно, что возникает спорная ситуация, при которой неизвестна необходимость отправки уведомлений о скидке для водителей, сдавших на категорию B,C.
Заключение
На наглядном примере таблицы принятия решений при тестировании видны достоинства и недостатки подхода, описанные ранее.
В ряде случаев возникает необходимость добавления или удаление тех или иных операций из-за их несоответствия бизнес требованиям или невозможны по выведенным критериям. Например, на странице «Корзина» размещены две кнопки «Купить», «Отменить», с двумя вероятными параметрами «Y, N». В одно и то же время кнопки не могут принимать одинаковые значения «Y», тест с «Y, Y» нивелируется и исключается из таблицы.
Материалы для скачивания
- Скачать таблицы принятия решений
Библиографическое описание:
Полевщиков, И. С. Методика изучения тестирования программного обеспечения с использованием диаграмм причин-следствий студентами бакалавриата / И. С. Полевщиков. — Текст : непосредственный // Молодой ученый. — 2016. — № 2 (106). — С. 94-97. — URL: https://moluch.ru/archive/106/25388/ (дата обращения: 19.04.2022).
Одной из дисциплин, изучаемых студентами бакалавриата по направлению «Программная инженерия», является «Тестирование программного обеспечения». Известно, что тестирование представляет собой один из этапов жизненного цикла разработки программного обеспечения и важнейшую составляющую поддержки качества программного обеспечения [1–7].
В ходе одной из лабораторных работ студент должен научиться производить тестирование программного обеспечения методом, основанным на построении диаграмм причин-следствий. Рассмотрим некоторые особенности разработанного методического пособия по данной теме.
В разделе «Краткие теоретические сведения» методического пособия представлена необходимая теория, посвященная данному способу тестирования, сопровождаемая примерами. Известно, что диаграммы причинно-следственных связей используются для проектирования тестовых вариантов и обеспечивают формальную запись логических условий и соответствующих действий [1, 8]. Детально разобраны основные шаги этого метода тестирования: выявление причин и следствий; построение графа причинно-следственных связей; преобразование графа в таблицу решений; преобразование столбцов таблицы решений в тестовые варианты; сравнение реальных результатов тестовых вариантов с ожидаемыми.
Для иллюстрации способа тестирования рассмотрен пример программы, выполняющей расчет оплаты за Интернет. Расчет может выполняться по одному из двух видов тарифов.
При расчете по первому тарифу:
1) при месячном использовании Интернета меньшем, чем 10 Гб, выставляется фиксированная сумма;
2) при месячном использовании Интернета большем или равном, чем 10 Гб, применяется процедура «А» планирования расчета.
При расчете по второму тарифу:
1) при месячном использовании Интернета меньшем, чем 10 Гб, применяется процедура «А» планирования расчета;
2) при месячном использовании Интернета большем или равном, чем 10 Гб, но при этом меньшем, чем 20 Гб, применяется процедура «Б» планирования расчета;
3) при месячном использовании Интернета большем или равном, чем 20 Гб, применяется процедура «В» планирования расчета.
На первом шаге данного способа тестирования определим причины и следствия, а также присвоим им идентификаторы.
Причинами в данной задаче будут являться:
1) расчет по первому тарифу;
2) расчет по второму тарифу;
3) месячное использование Интернета меньше, чем 10 Гб;
4) месячное использование Интернета больше или равно, чем 10 Гб;
5) месячное использование Интернета больше или равно, чем 10 Гб, но при этом меньше, чем 20 Гб;
6) месячное использование Интернета больше или равно, чем 20 Гб.
Следствиями в данной задаче будут являться:
1) 101 — выставление фиксированной суммы;
2) 102 — применение процедуры «А» планирования расчета;
3) 103 — применение процедуры «Б» планирования расчета;
4) 104 — применение процедуры «В» планирования расчета.
На втором шаге рассматриваемого способа тестирования разрабатывается граф причинно-следственных связей (рис. 1). Узлы причин перечисляются по вертикали в левой части графа, а узлы следствий — в правой части графа. Для следствия 102 возникает необходимость введения вторичных причин, обозначенных как 11 и 12, которые размещаются в центральной части графа.
Рис. 1. Граф причинно-следственных связей
На третьем шаге осуществляется генерация таблицы решений на основе описанного выше алгоритма.
Таблица решений для нашего примера показана в табл. 1.
Таблица 1
Таблица решений для расчета оплаты за Интернет
|
Номера столбцов |
1 |
2 |
3 |
4 |
5 |
|
|
Причины |
1 |
1 |
1 |
|||
|
2 |
1 |
1 |
1 |
|||
|
3 |
1 |
1 |
||||
|
4 |
1 |
|||||
|
5 |
1 |
|||||
|
6 |
1 |
|||||
|
Вторичные причины |
11 |
1 |
||||
|
12 |
1 |
|||||
|
Следствия |
101 |
1 |
||||
|
102 |
1 |
1 |
||||
|
103 |
1 |
|||||
|
104 |
1 |
|||||
На четвертом шаге выполняется преобразование каждого столбца таблицы в тестовый вариант. В нашем примере таких вариантов пять.
Тестовый вариант 1 (столбец 1):
Исходные данные: Расчет по первому тарифу. Месячное использование Интернета меньше, чем 10 Гб.
Ожидаемый результат: Выставление фиксированной суммы.
Тестовый вариант 2 (столбец 2):
Исходные данные: Расчет по первому тарифу. Месячное использование Интернета больше или равно, чем 10 Гб.
Ожидаемый результат: Применение процедуры «А» планирования расчета.
Тестовый вариант 3 (столбец 3):
Исходные данные: Расчет по второму тарифу. Месячное использование Интернета меньше, чем 10 Гб.
Ожидаемый результат: Применение процедуры «А» планирования расчета.
Тестовый вариант 4 (столбец 4):
Исходные данные: Расчет по второму тарифу. Месячное использование Интернета больше или равно, чем 10 Гб, но при этом меньше, чем 20 Гб.
Ожидаемый результат: Применение процедуры «Б» планирования расчета.
Тестовый вариант 5 (столбец 5):
Исходные данные: Расчет по второму тарифу. Месячное использование Интернета больше или равно, чем 20 Гб.
Ожидаемый результат: Применение процедуры «В» планирования расчета.
Таким образом, в разработанном методическом пособии в компактном виде изложена необходимая теория, посвященная основным понятиям и шагам тестирования программного обеспечения методом, основанным на построении диаграмм причин-следствий, снабженная достаточным количеством примеров. Изучив «Краткие теоретические сведения» методического пособия, студенты приступают к самостоятельному решению подобных задач.
Литература:
- Орлов С. А., Цилькер Б. Я. Технологии разработки программного обеспечения: Учебник для вузов. 4-е изд. Стандарт третьего поколения. СПб.: Питер, 2012. 608 с.
- Файзрахманов Р. А., Мурзакаев Р. Т., Брюханова А. А. Командная разработка и непрерывная интеграция в системах автоматизированного проектирования фигурного раскроя // Научное обозрение. 2015. № 1. С. 95–101.
- Темичев А. А., Файзрахманов Р. А. Аналитический обзор средств автоматизации тестирования производительности применительно к системам мониторинга // Вестник Пермского национального исследовательского политехнического университета. Электротехника, информационные технологии, системы управления. 2015. № 3 (15). С. 117–133.
- Полевщиков И. С., Байков В. С., Швецов М. Д. Разработка методического пособия на тему «Тестирование условий» (для студентов и магистрантов направления «Информатика и вычислительная техника») // Педагогика и современность. 2012. № 2. С. 84–90.
- Полевщиков И. С. Разработка методического пособия на тему «Тестирование базового пути» (для студентов бакалавриата направления «Программная инженерия») // Педагогика и современность. 2013. № 4. С. 83–85.
- Селуков Д. А., Полевщиков И. С. Автоматизация процесса тестирования программного обеспечения при использовании тестирования базового пути // Молодой ученый. 2015. № 23. С. 60–63.
- Селуков Д. А., Полевщиков И. С. Автоматизация процесса тестирования программного обеспечения при использовании тестирования условий // Молодой ученый. 2015. № 23. С. 63–67.
- Полевщиков И. С., Кондратович М. А., Селиванова О. И. Разработка методического пособия на тему «Способ диаграмм причин-следствий» (для студентов и магистрантов направления «Информатика и вычислительная техника») // Педагогика и современность. 2012. № 2. С. 79–84.
Основные термины (генерируются автоматически): месячное использование Интернета, планирование расчета, тестовый вариант, ожидаемый результат, программное обеспечение, процедура, Расчет, таблица решений, тариф, фиксированная сумма.
Что такое тестирование таблицы решений?
Тестирование таблицы решений – это метод тестирования программного обеспечения, используемый для проверки поведения системы для различных комбинаций входных данных. Это систематический подход, при котором различные входные комбинации и их соответствующее поведение системы (выходные данные) фиксируются в табличной форме. Именно поэтому его также называют как причинно-следственный столиком , где причиной и последствия захватываются для лучшего тестового покрытия.
Таблица решений – это табличное представление входных данных в сравнении с правилами / случаями / условиями испытаний. Давайте учиться на примере.
Пример 1. Как составить таблицу базовых решений для экрана входа в систему
Давайте создадим таблицу решений для экрана входа в систему.
Условие простое, если пользователь вводит правильное имя пользователя и пароль, он будет перенаправлен на домашнюю страницу. Если какой-либо из вводимых данных неправильный, появится сообщение об ошибке.
| условия | Правило 1 | Правило 2 | Правило 3 | Правило 4 |
| Имя пользователя (T / F) | F | T | F | T |
| Пароль (T / F) | F | F | T | T |
| Выход (E / H) | Е | Е | Е | ЧАС |
Условные обозначения:
- T – правильное имя пользователя / пароль
- F – Неверное имя пользователя / пароль
- E – Сообщение об ошибке отображается
- H – отображается главный экран
Интерпретация:
- Случай 1 – имя пользователя и пароль были неверны. Пользователю показывается сообщение об ошибке.
- Случай 2 – Имя пользователя было правильным, но пароль был неправильным. Пользователю показывается сообщение об ошибке.
- Случай 3 – Имя пользователя было неверным, но пароль был правильным. Пользователю показывается сообщение об ошибке.
- Случай 4 – имя пользователя и пароль были правильными, и пользователь перешел на домашнюю страницу
Преобразуя это в тестовый пример, мы можем создать 2 сценария,
- Введите правильное имя пользователя и правильный пароль и нажмите на кнопку входа, и ожидаемый результат будет пользователь должен перейти на домашнюю страницу
И один из сценария ниже
- Введите неправильное имя пользователя и неправильный пароль и нажмите на кнопку входа, и ожидаемый результат будет, пользователь должен получить сообщение об ошибке
- Введите правильное имя пользователя и неправильный пароль и нажмите на кнопку входа, и ожидаемый результат будет, пользователь должен получить сообщение об ошибке
- Введите неправильное имя пользователя и правильный пароль и нажмите на кнопку входа, и ожидаемый результат будет, пользователь должен получить сообщение об ошибке
По сути, они проверяют одно и то же правило.
Пример 2: Как создать таблицу решений для экрана загрузки
Теперь рассмотрим диалоговое окно, которое попросит пользователя загрузить фотографию с определенными условиями, такими как –
- Вы можете загрузить только изображение в формате .jpg
- размер файла менее 32 КБ
- разрешение 137 * 177.
Если какое-либо из условий не выполняется, система выдаст соответствующее сообщение об ошибке с указанием проблемы, и если все условия будут выполнены, фотография будет успешно обновлена.
Давайте создадим таблицу решений для этого случая.
| условия | Дело 1 | Дело 2 | Дело 3 | Дело 4 | Дело 5 | Дело 6 | Дело 7 | Дело 8 |
| Формат | .jpg | .jpg | .jpg | .jpg | Не .jpg | Не .jpg | Не .jpg | Не .jpg |
| Размер | Менее 32кб | Менее 32кб | > = 32 КБ | > = 32 КБ | Менее 32кб | Менее 32кб | > = 32 КБ | > = 32 КБ |
| разрешающая способность | 137 * 177 | Не 137 * 177 | 137 * 177 | Не 137 * 177 | 137 * 177 | Не 137 * 177 | 137 * 177 | Не 137 * 177 |
| Вывод | Фотография загружена | Несоответствие разрешения сообщения об ошибке | Несоответствие размера сообщения об ошибке | Размер сообщения об ошибке и несоответствие разрешения | Сообщение об ошибке несоответствия формата | Формат сообщения об ошибке и несоответствие разрешения | Сообщение об ошибке несоответствия формата и размера | Сообщение об ошибке несоответствия формата, размера и разрешения |
Для этого условия мы можем создать 8 различных тестовых случаев и обеспечить полное покрытие на основе приведенной выше таблицы.
- Загрузите фотографию в формате «.jpg», размером менее 32 КБ и разрешением 137 * 177 и нажмите «Загрузить». Ожидаемый результат: фотография должна быть успешно загружена
- Загрузите фотографию в формате «.jpg», размером менее 32 КБ и разрешением не 137 * 177 и нажмите «Загрузить». Ожидаемый результат: должно отображаться несоответствие разрешения сообщения об ошибке.
- Загрузите фотографию в формате «.jpg», размером более 32 КБ и разрешением 137 * 177 и нажмите «Загрузить». Ожидаемый результат: должно отображаться несоответствие размера сообщения об ошибке.
- Загрузите фотографию в формате «.jpg», размером более 32 кБ и разрешением не 137 * 177, и нажмите «Загрузить». Ожидаемый результат: должен отображаться размер сообщения об ошибке и несоответствие разрешения.
- Загрузите фотографию в формате, отличном от «.jpg», размером менее 32 КБ и разрешением 137 * 177 и нажмите «Загрузить». Ожидаемый результат: сообщение об ошибке для несоответствия формата должно отображаться
- Загрузите фотографию в формате, отличном от «.jpg», размером менее 32 КБ и разрешением не 137 * 177 и нажмите «Загрузить». Ожидаемый результат: формат сообщения об ошибке и разрешение несоответствия должны отображаться
- Загрузите фотографию в формате, отличном от «.jpg», размером более 32 КБ и разрешением 137 * 177 и нажмите «Загрузить». Ожидаемый результат: сообщение об ошибке для формата и несоответствия размера должно отображаться
- Загрузите фотографию с форматом, отличным от «.jpg», размером более 32 КБ и разрешением не 137 * 177 и нажмите «Загрузить». Ожидаемый результат: сообщение об ошибке для формата, размера и несоответствия разрешения должно отображаться
Почему важно тестирование таблицы решений?
Этот метод тестирования становится важным, когда требуется проверить различные комбинации. Это также помогает лучше тестировать покрытие сложной бизнес-логики.
В программной инженерии граничное значение и эквивалентное разбиение – это другие похожие методы, используемые для обеспечения лучшего покрытия. Они используются, если система демонстрирует одинаковое поведение для большого набора входов. Однако в системе, где для каждого набора входных значений поведение системы отличается , граничное значение и эквивалентный метод разделения не эффективны для обеспечения хорошего охвата тестированием.
В этом случае тестирование таблицы решений является хорошим вариантом. Этот метод может обеспечить хороший охват, а представление простое, поэтому его легко интерпретировать и использовать.
Эта таблица может использоваться в качестве справочного материала для требования и для разработки функциональности, поскольку она проста для понимания и охватывает все комбинации.
Значение этого метода сразу становится понятным по мере увеличения количества входов. Количество возможных комбинаций задается как 2 ^ n, где n – количество входов. Для n = 10, который очень распространен в веб-тестировании, имеющем большие формы ввода, количество комбинаций будет 1024. Очевидно, что вы не можете протестировать все, но вы выберете богатое подмножество возможных комбинаций, используя решение на основе методика тестирования.
Преимущества тестирования таблицы решений
- Когда поведение системы отличается для разных входных данных и не одинаково для диапазона входных данных, как эквивалентное разбиение, так и анализ граничных значений не помогут, но можно использовать таблицу решений.
- Представление простое, так что его можно легко интерпретировать и использовать как для развития, так и для бизнеса.
- Эта таблица поможет составить эффективные комбинации и может обеспечить лучшее покрытие для тестирования
- Любые сложные бизнес-условия можно легко превратить в таблицы решений
- В случае, если мы собираемся на 100% охват, как правило, когда входные комбинации низкие, этот метод может обеспечить покрытие.
Недостатки тестирования таблицы решений
Основным недостатком является то, что с увеличением количества входных данных таблица станет более сложной.
Нажмите здесь, если видео не доступно
Decision Table
A Decision Table is a table that shows the relationship between inputs and
rules, cases, and test conditions. It’s a very useful tool for both complicated
software testing and requirements management. The decision table allows
testers to examine all conceivable combinations of requirements for testing
and to immediately discover any circumstances that were overlooked.
True(T) and False(F) values are used to signify the criteria.
What is Decision Table Testing?
Decision table testing is a type of software testing that examines how a
system responds to various input combinations. This is a methodical
methodology in which the various input combinations and the accompanying system behavior (Output) are tabulated. That’s why it’s also known as a Cause-Effect table because it captures both causes and effects
for improved test coverage.
Let’s start with a simple example.
Example 1 − How to Create a Login Screen Decision Base Table
Let’s make a login screen with a decision table. A login screen with E-mail
and Password Input boxes.
The condition is simple − The user will be routed to the homepage if they give the right username and password. An error warning will appear if any of the inputs are incorrect.
| Conditions | Rule 1 | Rule 2 | Rule 3 | Rule 4 |
|---|---|---|---|---|
| Username (T/F) | F | T | F | T |
| Password (T/F) | F | F | T | T |
| Output (E/H) | E | E | E | H |
Legend
-
T — Make sure your login and password are correct.
-
F — Incorrect login or password
-
E — An error message appears.
-
H — The home screen appears.
Interpretation
-
Case 1 − Both the username and password were incorrect. An error
message is displayed to the user. -
Case 2 − The username and password were both right, however, the
password was incorrect. An error message is displayed to the user. -
Case 3 − Although the username was incorrect, the password was
accurate. An error message is displayed to the user. -
Case 4 − The user’s username and password were both accurate,
and the user went to the homepage.
We may generate two situations when converting this to a test case.
-
Enter the right username and password and click Login; the intended
consequence is that the user will be sent to the homepage.
And one from the situation below.
-
If the user types in the erroneous username and password and then
clicks Login, the user should receive an error message. -
When you provide the proper username and incorrect password and
click Login, the user should see an error message. -
If the user types the erroneous username and password and then
clicks Login, the user should receive an error message.
Because they are both effectively testing the same rule.
Example 2 − How to Make an Upload Screen Decision Table
Consider a dialog box that prompts the user to submit a photo under
particular situations, such as —
-
You can only upload images in the ‘.jpg’ format.
-
a file with a size of fewer than 32 kilobytes
-
137*177 pixels is the resolution.
If any of the requirements are not satisfied, the system will display an error
notice describing the problem, and if all conditions are met, the photo will
be correctly updated.
Let’s make a choice table for this situation.
| Condition s |
Case 1 | Case 2 | Case 3 | Case 4 | Case 5 | Case 6 | Case 7 | Case 8 |
| Format | .jpg | .jpg | .jpg | .jpg | Not.jpg | Not.jpg | Not.jpg | Not.jpg |
| Size | Less than 32 kb | Less than 32 kb | >=3 2 kb | >=32 kb | Less than 32 kb | Less than 32 kb | >=32 kb | >=32 kb |
| Resolution | 137* 177 |
Not 137* 177 |
137* 177 | Not 137*1 77 | 137*1 77 |
Not 137*17 7 |
137*17 7 |
Not 137*177 |
| Output | Photo Uploaded | Error Message resolution mismatched | Error message size mismatch | Error message size and resolution mismatched | Error message for format mismatch | Error message format and resolution mismatch | Error message for format and size mismatch | Error message for format, size, resolutio n mismatch |
Based on the given data, we can develop 8 separate test cases to assure
comprehensive coverage for this condition.
-
Click on upload to add a photo with the type ‘.jpg,’ a file size of less
than 32kb, and a resolution of 137*177 pixels. The expected outcome
is that the photo will upload successfully. -
Click on upload to add a photo with the format ‘.jpg,’ a file size of less
than 32kb, and a resolution of less than 137*177 pixels. The
anticipated outcome is The resolution mismatch in error messages
should be displayed. -
Click on upload to add a photo with the format ‘.jpg,’ a file size of
more than 32kb, and a resolution of 137*177 pixels. The anticipated
outcome is The size of the error message should be displayed. -
Click on upload to add a photo with the type ‘.jpg,’ a file size greater
than 32kb, and a resolution of less than 137*177 pixels. The
anticipated outcome is A discrepancy in the size and resolution of
error messages should be displayed. -
Click on upload and select a photo with a format other than ‘.jpg,’ a
file size of less than 32kb, and a resolution of 137*177 pixels. The
anticipated outcome is If there is a format mismatch, an error
message should be displayed. -
Click on upload and select a photo with a format other than ‘.jpg,’ a
file size of less than 32kb, and a resolution of less than 137*177
pixels. Error message format and resolution mismatch should be
shown as the expected outcome. -
Click on upload to add a photo in a format other than ‘.jpg,’ a file size
greater than 32kb, and a resolution of 137*177 pixels. Error notice for
format and size mismatch should be displayed, as expected. -
Click on upload and select a photo with a format other than ‘.jpg,’ a
file size of more than 32kb, and a resolution of less than 137*177
pixels. The anticipated outcome is If there is a format, size, or
resolution mismatch, an error message should be displayed.
Importance of Decision Table Testing
Decision table testing is important because it allows you to test multiple
combinations of circumstances and ensures that complicated business
logic is thoroughly tested. Decision table testing provides high coverage
and the representation is simple, making it easy to read and apply for
evaluating the behavior of a vast number of inputs where system behavior
vary with each set of input.
Boundary value and analogous partition are two more related strategies
used in Software Engineering to provide greater coverage. They’re utilized
when a system’s behavior is consistent over a wide number of inputs.
However, in a system with varied system behavior for each set of input
values, the boundary value and equivalent partitioning techniques are
ineffective in guaranteeing appropriate test coverage.
Decision table testing is a useful alternative in this instance. This approach
ensures adequate coverage, and the representation is straightforward,
making it simple to understand and apply.
Because it is simple to grasp and covers all possible combinations, this
table may be used as a reference for requirements and functionality
development.
As the number of inputs grows, the relevance of this strategy becomes
apparent. 2 n, where n is the number of inputs, equals the number of
potential combinations. The number of combinations for n = 10, which is
very common in web-based testing with large input forms, is 1024.
Obviously, you cannot test all conceivable combinations, but you may pick
a large subset of them using the decision-based testing approach.
Decision Table Testing’s Benefits
-
When the system behavior varies depending on the input and is not
consistent over a range of inputs, neither equivalent partitioning nor
boundary value analysis can help, but a decision table can. -
The representation is basic enough to be simply understood and may
be utilized for both development and business. -
This table will aid in the creation of successful combinations and can
improve testing coverage. -
Any complicated business situation may readily be transformed into a
decision table. -
This strategy can provide coverage when we are aiming for 100
percent coverage, which is usually the case when the number of input
choices is modest.
Decision Table Testing’s Drawbacks
The biggest drawback is that as the number of inputs grows, the table
becomes more complicated.
Decision Table Testing’s Scope
When data is complicated and every possible combination must be
checked, decision tables can quickly grow to be enormous. You may
intelligently minimize the number of options in each option to only select the
ones that are intriguing and significant. Collapsed Decision Table Testing is
the name for this method.
The redundant criteria that are unrelated to the outcome are eliminated in
this procedure, and various outputs are created. In order for the tester to
execute more effective testing, an additional layer of analysis is added to
the test design.
Decision tables are a dependable specification-based testing tool that may
be used in a variety of contexts. The tabular and graphical representations
are very easy to grasp for all stakeholders and non-technical people.
Through instructive examples and real-life scenarios, project team
members may quickly get thorough insights into the topic at hand.
The usefulness and efficiency of this testing approach may be realized by
proceeding to the next level of collapsible decision-making table.
Published on 01-Dec-2021 05:07:22
- Related Questions & Answers
- What is Spike Testing? Learn With Example
- What is the Spike Testing? Learn with Example
- Path Testing & Basis Path Testing with Example
- What is Recovery Testing? With Example
- Keyword Driven Testing Framework with Example
- Learn V-Model in Software Testing
- Payment Gateway Testing with Example Test Cases
- What is SOA Testing? Tutorial with Example
- End-to-End Testing Tutorial: What is E2E Testing with Example
- Software Testing Methodologies – Learn QA Models
- What is Non-Functional Testing? Types with Example
- What is Negative Testing(Test cases with Example)?
- What is System Integration Testing (SIT) with Example
- Reliability Testing: Methods, Tools, Example
- What is Software Testing Metrics with Types & Example?
