Разработка тестового сценария оценка необходимого количества тестов

Подборка по базе: Безопасность клиентских операционных систем «Синергия» лучшая оц, Инициация и оценка эффективности инвестиционного проекта по оказ, Метоическая разработка опбд.docx, Метод разработка 14.3 ПЗ.docx, Презентация Оценка Бизнеса ПАО РОСТЕЛЕКОМ.pptx, План-конспект урока по художественному труду на тему _Обсуждение, Практическая работа по дисциплине оценка и управление стоимостью, титульный методическая разработка.docx, 2021. Анализ и оценка финансового состояния предприятия на приме, Задание 2. Оценка эффективности инноваций.docx

Разработка тестового сценария. Оценка необходимого количества тестов
Цель: усвоить знание о видах тестирования; освоить способы обнаружения и фиксирования ошибок. Научиться оценивать необходимое количество тестов.
Форма отчета:

−выполнить задание;

−показать преподавателю;

−ответить на вопросы преподавателя.
Теоретические сведения

Разработка тестового сценария

Software Configuration Management или Конфигурационное управление подразумевает под собой комплекс методов, направленных на то, чтобы систематизировать изменения, вносимые разработчиками в программный продукт в процессе его разработки и сопровождения, сохранить целостность системы после изменений, предотвратить нежелательные и непредсказуемые эффекты, а также сделать процесс внесения изменений более формальным.

К процедурам можно отнести создание резервных копий, контроль исходного кода, требований проекта, документации и т. д. Степень формальности выполнения данных процедур зависит от размеров проекта, и при правильной ее оценке данная концепция может быть очень полезна. Конфигурационное управление требует выполнения множества трудоемких рутинных операций. На практике, в большинстве случаев, для конфигурационного управления применяются специальные системы контроля версий исходного кода программ. В качестве примера рассмотрим информационную систему Subversion. Это бесплатная система управления версиями с открытым исходным кодом.

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

Заповеди по отладки программного средства, предложенные Г. Майерсом.

Заповедь 1. Считайте тестирование ключевой задачей разработки ПС, поручайте его самым квалифицированным и одаренным программистам, нежелательно тестировать свою собственную программу.

Заповедь 2. Хорош тот тест, для которого высока вероятность обнаружить ошибку, а не тот, который демонстрирует правильную работу программы.

Заповедь 3. Готовьте тесты как для правильных, так и для неправильных данных.

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

Заповедь 5. Каждый модуль подключайте к программе только один раз, никогда не изменяйте программу, чтобы облегчить ее тестирование.

Заповедь 6. Пропускайте заново все тесты, связанные с проверкой работы какой-либо программы ПС или ее взаимодействия с другими программами, если в нее были внесены изменения (например, в результате устранения ошибки).
Оценка необходимого количества тестов

Сколько тестов понадобится, чтобы обнаружить ошибки?

Для ответа на этот вопрос предлагается следующая модель. Утверждается, что вероятность успешности очередного теста зависит от процента оставшихся ошибок. Последние ошибки обнаружить сложнее. (Заметим, что данное утверждение вполне соответствует опыту.)

Пусть T_n — среднее количество тестов, необходимых для обнаружения n ошибок, N — число ошибок в программе. Для оценки T_n предлагается следующая формула:

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

Мы хотим оценить количество тестов, которое потребуется для нахождения всех N ошибок. Посчитать напрямую T_n мы не можем, поскольку не знаем коэффициента α. Чтобы исключить его из вычислений, перейдем от абсолютных величин к относительным. Попробуем оценить, какую часть от всех необходимых тестов придется выполнить для того, чтобы найти первые n ошибок

Теперь осталось подставить в формулу для P конкретные значения N и n. Результаты — очень интересные — представлены в таблицах. В первой таблице N изменяется от 10 до 100, во второй таблице — от 1 до 10. Последняя таблица построена специально для новичков, программы которых настолько малы по размерам, что в них просто не найдется места для сотни ошибок.

Таблица. Средний процент тестов, необходимых для обнаружения заданного процента ошибок (в зависимости от общего числа ошибок в программе)

Оказывается, что при N = 10 первые 22% тестов обнаружат половину всех ошибок (5 штук). Для того чтобы обнаружить две следующие ошибки, количество тестов придется увеличить в 1,7 раза — до 37%. Поиск следующих двух ошибок потребует увеличения количества тестов еще в 1,8 раза — до 66%. И наконец, поиск последней ошибки потребует оставшихся 34% тестов.

Чем больше ошибок в программе, тем дороже обойдется поиск последних ошибок. При N = 50 для обнаружения 50% ошибок достаточно 15% тестов, 70% ошибок будут найдены с помощью 26%, 90% ошибок — с помощью 49% тестов. Поиск последних 10% ошибок будет стоить дороже, чем поиск первых 90%!

При увеличении количества ошибок с 10 до 100 стоимость поиска последних 10% ошибок возрастает с 34% тестов до 66%.

Заметим, что речь идет не об абсолютном числе тестов, а о их доле. Поскольку программа, содержащая 100 естественных ошибок, скорее всего, сложнее программы, в которой ошибок только 10, есть основания полагать, что общее число тестов также будет возрастать. То есть придется брать больший процент от большего числа тестов

В следующей таблице N изменяется от 1 до 10. В этом случае говорить о процентах найденных ошибок смысла нет. Поэтому в боковике записаны не относительные, а абсолютные значения. Поскольку указанное количество ошибок вполне реально для учебных программ, интересно было сравнить модельные данные, приведенные в таблице, с реальными данными из практики. Надо только помнить, во-первых, что речь идет о средних значениях. А во-вторых, что данные в таблице получены из статистической модели. А статистика любит большие числа.

Таблица. Средний процент тестов, необходимых для обнаружения заданного количества ошибок (в зависимости от общего числа ошибок в программе)

Имея такие оценки относительного количества тестов, в конкретном проекте можно перейти к абсолютным величинам.

Поскольку нам известно, сколько тестов нам понадобилось для нахождения n ошибок, легко оценить, сколько понадобится для нахождения оставшихся. Если количество ошибок в программе оценено в 10 и для обнаружения первых пяти потребовалось, например, 7 тестов, то для поиска двух следующих ошибок количество тестов придется довести до 12 (5 дополнительных тестов на 2 ошибки), для поиска следующих двух — до 21 (9 дополнительных тестов на 2 ошибки). Все 10 ошибок есть надежда найти за 32 теста.

Подобные оценки можно использовать для планирования времени и ресурсов, выделяемых для процесса тестирования.
Задание практической работы

Методика выполнения

Разработка тестового сценария

Задача: Найти минимальный набор тестов для программы нахождения вещественных корней квадратного уравнения .

Решение:

Таким образом для этой задачи предлагается минимальный набор функциональных тестов, исходя из 7 классов выходных данный.
Оценка необходимого количества тестов
Контрольные вопросы

1. Что такое тестирование? Что является объектами тестирования?
2. Опишите виды тестирования.
3. Поясните понятия «тест», «тестовые данные», «тестовый эксперимент».

Цель
работы: описать набор тестовых сценариев
для верификации ПО. Оптимизировать
тестовый набор. Научиться составлять
спецификацию для разработки тестов.

Отчет
по лабораторной работе: набор тестовых
сценариев, спецификация для тест дизайна.

Теоретическая часть Функциональное тестирование или Functional Testing

Функциональное тестированиерассматривает заранее указанное
поведение и основывается на анализе
спецификаций функциональности компонента
или системы в целом.

Функциональные тестыосновываются
на функциях, выполняемых системой, и
могут проводиться на всех уровнях
тестирования (компонентном, интеграционном,
системном, приемочном). Как правило, эти
функции описываются в требованиях,
функциональных спецификациях или в
виде случаев использования системы
(use cases).

Тестирование функциональности может
проводиться в двух аспектах:

• требования

• бизнес-процессы

Тестирование в перспективе «требования»
использует спецификацию функциональных
требований к системе как основу для
дизайна тестовых случаев (Test Cases). В этом
случае необходимо сделать список того,
что будет тестироваться, а что нет,
приоритезировать требования на основе
рисков (если это не сделано в документе
с требованиями), а на основе этого
приоритезировать тестовые сценарии
(test cases). Это позволит сфокусироваться
и не упустить при тестировании наиболее
важный функционал.

Тестирование в перспективе «бизнес-процессы»
использует знание этих самых
бизнес-процессов, которые описывают
сценарии ежедневного использования
системы. В этой перспективе тестовые
сценарии (test scripts), как правило,
основываются на случаях использования
системы (use cases).

Преимущества функционального
тестирования:

• имитирует фактическое использование
  системы;

Недостатки функционального тестирования:

• возможность упущения логических ошибок
  в программном обеспечении;

• вероятность избыточного тестирования.

Достаточно распространенной является
автоматизация функционального
тестирования.

Тестовый случай (Test Case)

Тестовый случай
(Test Case)
— это артефакт, описывающий совокупность
шагов, конкретных условий и параметров,
необходимых для проверки реализации
тестируемой функции или её части.

Под тест кейсом понимается
структура вида:

Action
> Expected Result
> Test Result

Пример:

Виды Тестовых Случаев

Тест кейсы разделяются по
ожидаемому результату на позитивные
и негативные:

• Позитивный тест кейс
  использует только корректные данные
  и проверяет, что приложение правильно
  выполнило вызываемую функцию.

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

Структура Тестовых Случаев (Test Case Structure)

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

Каждый тест кейс должен
иметь 3 части:

Примечание:
Post Conditions
не является обязательной частью. Это
скорее всего — правило хорошего тона:
«намусорил — убери за собой». Это
особенно актуально при автоматизированном
тестировании, когда за один прогон можно
наполнить базу данных сотней или даже
тысячей некорректных документов.

Пример
тест кейса:

do
A1, verify B1

do
A2, verify B2

do
A3, verify B3

В приведенном примере
конечная проверка — В3. Это значит, что
именно она является ключевой. Значит,
A1 и А2 — это действия приводящие систему
в тестопригодное состояние. А В1 и В2 —
условия того, что система находится в
состоянии пригодном для тестирования.
Таким образом имеем:

PostConditions в данном примере
не были описаны, но по логике вещей надо
выполнить шаги, которые бы вернули
систему в первоначальное состояние.
(например, удалили созданную запись,
или отменили бы изменения сделанные в
документе).

Теперь ответим на вопрос:
«Почему данное разбиение удобно
использовать?»

Ответ: конечная проверка
одна, т.е. в случае если тест провален
(test failed)
будет сразу ясно из-за чего. Т.к. если
провальными окажутся проверки В1 и/или
В2, то тест кейс будет заблокирован (test
blocked), из-за того, что
функцию не возможно привести в
тестопригодное состояние (состояние
пригодное для проведения тестирования),
но это не значит, что тестируемая функция
не работает.

Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]

• #
• #
• #
• #
• #
• #
• #
• #
• #
• #
• #

Автор: Екатерина Курач

Написать тест кейсы для «полного» тестирования продукта — просто невозможно. Мы можем разработать миллионы тестов, но будет ли время у нас их выполнить? Вероятнее всего — нет. Поэтому приходится тщательно выбирать тест кейсы, которые мы будем проводить.

В последние несколько лет наметилась тенденция, когда усилия фирм-разработчиков программного обеспечения направлены на повышение качества своих программных продуктов. Постепенно производители отказываются от «интуитивного» тестирования программ и переходят к формальному тестированию, с написанием тест кейсов.

Но, как известно, полностью протестировать программу невозможно по следующим причинам:

1. Количество всех возможных комбинаций входных данных слишком велико, чтоб его можно было проверить полностью.
2. Количество всех возможных последовательностей выполнения кода программы также слишком велико, чтобы его можно было протестировать полностью.
3. Пользовательский интерфейс программы (включающий все возможные комбинации действий пользователя и его перемещений по программе) обычно слишком сложен для полного тестирования.

Т.е. написать тест кейсы для «полного» тестирования продукта — просто невозможно. Мы можем разработать миллионы тестов, но будет ли время у нас их выполнить? Вероятнее всего — нет. Поэтому приходится тщательно выбирать тест кейсы, которые мы будем проводить.

Характеристики хорошего теста:

• Существует обоснованная вероятность выявления тестом ошибки
• Набор тестов не должен быть избыточным
• Тест должен быть наилучшим в своей категории
• Он не должен быть слишком простым или слишком сложным

В настоящее время наблюдается несколько методологий разработки тест кейсов. Они отличаются и теоретическим подходом, и практической реализацией.

Наиболее часто употребляемая методология разработки тестовых случаев — методология, при которой источниками тестовых случаев выступают случаи использования.

Методология разработки тестовых случаев на основе сценариев использования

Случай использования состоит из некоторого множества сценариев: нормальный случай, расширения и исключительные ситуации. Для разработки тест кейсов на основе одного случая использования разрабатываются несколько сценариев, соответственно: Сценарий использования представляет собой оптимистический сценарий, который выбирается чаще других. В раздел Альтернативные пути могут быть включены несколько сценариев, которые отличаются от сценария использования в различных аспектах, однако остаются полноценными путями исполнения. В раздел Исключительные пути попадают те сценарии, которые приводят к возникновению ошибок. Каждый сценарий предусматривает действия, предпринимаемые действующим субъектом, и требует от системы отклика, который соответствует основной части тестового случая. Тестовый случай состоит из некоторого набора предусловий, стимулирующего воздействия (входные данные) и ожидаемого отклика.

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

Комбинация рейтингов частоты использования и критичности, применяемая для того, чтоб упорядочить случаи использования, обеспечивает получение определенного критерия качества. Например, можно нарисовать эмблему в правом нижнем углу каждого окна. Это повторяется довольно часто, но если это не получится, система все еще способна выполнять наиболее важные функции для пользователя. Аналогично, соединение с сервером локальной базы данных происходит крайне редко, однако неудача этой операции сделает невозможным успешное выполнение множества других функций. Количество тестовых случаев, приходящихся на один случай использования, выбирается в зависимости от положения этого случая использования в рейтинговой таблице (чем чаще встречается данный случай использования и чем критичней его неверное выполнение для системы — там больше тест кейсов должно быть разработано). На этом этапе тестирования поддерживается проведение тестирования приложения в таком режиме, в каком оно будет использовано на практике.

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

Очень редко все эти действующие субъекты используют систему одним и тем же способом. Поле частоты случая использования представляет собой композицию значений частоты использования отдельных профилей действующих субъектов.

Этот подход весьма полезен для систем, которые ни разу не устанавливались. Он дает более точную оценку того, как действующий субъект будет использовать систему, по сравнению с простым угадыванием того, каким окажется совокупный результат отдельных случаев использования.

Случай использования обычно содержит многочисленные сценарии, которые могут быть преобразованы в тестовые случаи.

Разработка сценария для случая использования предусматривает выполнение четырех действий:

1. Идентификация всех значений, которые вводятся действующими субъектами, содержащимися в модели случая использования
2. Выделение классов эквивалентности значений каждого типа входных данных
3. Построение таблиц, в которые помещен список комбинаций значений из различных классов эквивалентности
4. Построение тестовых случаев, в которых сочетаются одна перестановка значений с необходимыми внешними ограничениями

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

В таблице 1 показаны классы эквивалентности этих трех переменных.

Спецификация входных значений для системы управления кадрами

В таблице 2 каждой из этих переменных отводится отдельный столбец. В эти столбцы помещены значения из различных классов эквивалентности рассматриваемых переменных. Каждая строка таблицы представляет собой описание конкретного теста.

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

Перестановки входных данных системы управления персоналом

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

При тестировании сложных систем одна из наиболее трудных задач заключается в том, чтобы определить результаты, ожидаемые от прогона конкретного теста. Телекоммуникационные системы, программное обеспечение управления космическим кораблем, информационные системы многонациональных корпораций — это случаи систем, для которых построение тестовых данных и тестовых результатов обходится особенно дорого. Некоторые методы разработки тест кейсов могут оказаться полезными для снижения затрат усилий на разработку и описание ожидаемых результатов. Первый из них предусматривает построение результатов в так называемом инкрементальном режиме. По условиям этого подхода тестовые случаи создаются с целью покрытия некоторого поднабора случаев использования системы, возможно, только некоторых процедур ввода данных. В последующих случаях покрытия расширяются с целью проверки использования системы в полном объеме. С расширением тестовых случаев, тестовые результаты тоже расширяются.

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

Второй подход заключается в разработке тестовых случаев большого цикла (grand tour test cases), в котором каждый тестовый случай генерирует данные, которые служат входом для следующего тестового случая. По условиям такого подхода каждый тест переносит тестовые данные через весь жизненный цикл. Полученное при этом состояние базы данных используется в качестве входного для следующего теста. Этот метод особенно эффективен при тестировании жизненного цикла после того, как тестирование нижнего уровня позволило выявить большую часть дефектов, вызывающих отказы. Если выстроить тестовые случаи в соответствующую последовательность, то после успешного выполнения тестового случая 1 устанавливается такое состояние программы, которое ожидается как входное для тестового случая 2. Очевидная проблема в условиях очерченного подхода заключается в том, что неудачное выполнение тестового случая 1 оставляет программу в состоянии, которого мы не ожидали, в результате чего мы не можем выполнять прогон тестового случая 2 или даже вернуть программу в рабочее состояние.

Итак, при разработке тест кейсов на основе случаев использования процедура в общем-то ясна. Однако возникает другой вопрос — что необходимо подвергнуть тестированию? Какие аспекты функционирования системы? Рекомендуется проводить следующие виды тестирования:

• Тестирование на соответствие функциональным требованиям
• Проверка качественных системных атрибутов. Добротная организация разработок программного обеспечения предусматривает методы подтверждения всех системных «требований», включая и претензии на придание программному продукту особых качеств. Существуют два вида претензий, с которыми может столкнуться программа при разработке продукта. Первый вид претензий представляет интерес только для организаций, занимающейся разработкой программных продуктов. Например, утверждение, что «программный код допускает многократное использование». Второй тип претензий представляет интерес для пользователей системы. Например, утверждение о том, что система является более полной, нежели другие системы подобного класса, предлагаемые на текущий момент на рынке программных продуктов. Вполне понятно, что не все эти претензии могут подвергаться проверке через тестирование. Однако на это следует обратить внимание.
• Тестирование механизма развертывания системы
• Тестирование после развертывания системы. Естественное расширение тестирования механизма развертывания системы заключается в добавлении в тестируемый программный продукт функциональных средств самопроверки. Считается, что система «изнашивается» во времени по причине изменений, имеющих место в ее взаимодействии с окружением, примерно так же, как со временем изнашивается механическая система из-за трений между ее компонентами. По мере того, как устанавливаются все более новые версии стандартных драйверов и библиотек, несоответствия возрастают вместе с ростом вероятности возникновения отказов. Каждая новая версия dll-библиотеки привносит возможность появления новых областей нестыковки стандартных интерфейсов или появления состояния гонок между этой библиотекой и приложением. Функциональные средства самотестирования должны обеспечивать выполнение тестов, которые исследуют работу интерфейсов между этими программными продуктами.
• Тестирование взаимодействий окружения
• Тестирование системы безопасности

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

Литература:

1. Сэм Канер, Джек Фолк, Енг Кек Нгуен. Тестирование программного обеспечения. — Киев: Издательство «Диа Софт», 2001.—544 с.
2. Макгрейгор Джон, Сайкс Девид. Тестирование объектно-ориентированного программного обеспечения. Практическое пособие. — Киев: ООО «ТИД «ДС»», 2002.—432 с.

Что такое тестирование сценария?

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

Давайте изучим это с помощью видео ниже —

Зачем создавать тестовые сценарии?

Тестовые сценарии создаются по следующим причинам:

• Создание тестовых сценариев обеспечивает полное покрытие тестами
• Сценарии тестирования могут быть одобрены различными заинтересованными сторонами, такими как бизнес-аналитик, разработчики, клиенты, для обеспечения тщательного тестирования тестируемого приложения. Это гарантирует, что программное обеспечение работает для наиболее распространенных случаев использования.
• Они служат быстрым инструментом для определения трудозатрат на тестирование и, соответственно, создают предложение для клиента или организуют рабочую силу.
• Они помогают определить наиболее важные сквозные транзакции или реальное использование программных приложений.
• Для изучения сквозного функционирования программы, тестовый сценарий имеет решающее значение.

Когда не создать тестовый сценарий?

Тестовые сценарии не могут быть созданы, когда

• Тестируемое приложение является сложным, нестабильным, и в проекте есть время.
• Проекты, которые следуют Agile методологии, такие как Scrum, Kanban, могут не создавать тестовые сценарии.
• Сценарий тестирования не может быть создан для исправления новой ошибки или регрессионного тестирования . В таких случаях сценарии тестирования должны быть уже задокументированы в предыдущих циклах тестирования. Это особенно верно для проектов технического обслуживания.

Как написать тестовые сценарии

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

• Шаг 1 : Прочтите документы с требованиями, такие как BRS, SRS, FRS, тестируемой системы (SUT). Вы также можете сослаться на примеры использования, книги, руководства и т. Д. Приложения, подлежащего тестированию.
• Шаг 2 : Для каждого требования определите возможные действия и цели пользователей. Определить технические аспекты требования. Определите возможные сценарии злоупотребления системой и оцените пользователей с менталитетом хакера.
• Шаг 3: После прочтения Документа с требованиями и проведения надлежащего анализа перечислите различные сценарии тестирования, которые проверяют каждую функцию программного обеспечения.
• Шаг 4: После того, как вы перечислили все возможные сценарии тестирования, создается матрица отслеживания, чтобы убедиться, что каждому требованию соответствует соответствующий сценарий тестирования.
• Шаг 5: Созданные сценарии проверяются вашим руководителем. Позже они также рассматриваются другими заинтересованными сторонами в проекте.

Советы по созданию тестовых сценариев

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

Пример 1. Сценарий тестирования для приложения электронной коммерции

Для приложения электронной коммерции несколько тестовых сценариев

Тестовый сценарий 1: проверка функциональности входа

Чтобы помочь вам понять разницу между сценарием тестирования и тестовыми сценариями, для этого сценария тестирования будут использоваться конкретные тестовые сценарии.

1. Проверьте поведение системы при вводе действительного адреса электронной почты и пароля.
2. Проверьте поведение системы при вводе неверного идентификатора электронной почты и действительного пароля.
3. Проверьте поведение системы при вводе действительного адреса электронной почты и неверного пароля.
4. Проверьте поведение системы при вводе неверного идентификатора электронной почты и неверного пароля.
5. Проверьте поведение системы, если адрес электронной почты и пароль оставлены пустыми и введен вход.
6. Проверить Забыли пароль работает как положено
7. Проверьте поведение системы при вводе действительного / недействительного номера телефона и пароля.
8. Проверять поведение системы, когда установлен флажок «Держать меня в подписи»

Как видно, тестовые случаи являются более конкретными.

Тестовый сценарий 2. Проверка функциональности поиска