ВУЗ: Не указан
Категория: Не указан
Дисциплина: Не указана
Добавлен: 30.11.2023
Просмотров: 23
Скачиваний: 1
ВНИМАНИЕ! Если данный файл нарушает Ваши авторские права, то обязательно сообщите нам.
Определение значимых транзакций
Навигационная карта показывает все перекрестные связи между экранами. Разработчик тестов может использовать эти связи для моделирования потока транзакций. Для данного примера создание тестовых сценариев, которые сопоставлены навигационным потокам, приведено в таблице 1.
Таблиц
| Серийный номер | Тестовый сценарий | Описание | Чередование экранов: << экран>> | Наборы данных: <<форма ввода>> Либо тестовые данные | Сценарий тестирования | Зависимость | Ожидаемое значение |
| 1 | Основной поток | Покупка билетов в кино | MainFrm (основная форма) | Форма регистрации | Регистрация | Нет | - |
| | | | Страница фильмов | Форма выбора фильма | Выбор фильма | MainFrm (основная форма) | - |
| | | | Результаты выборафильма | | Страница результатов | Страница фильмов | Коррекция стоимости билетов |
| 2 | Подчин-енный поток | Предвар-ительный просмотр фильма | MainFrm (основная форма) | Регистра-ционная форма | Регистрация | Нет | - |
| | | | Страница фильмов | Тестовые данные: Название фильма | Выбрать фильм | MainFrm (основная форма) | |
| | | | Отобразить рецензию на фильм | | Отобразить рецензию | Страница фильмов | Извлечь правильную рецензиюна фильм |
| Общее количество тестовых сценариевОжидаемое время записи на один тестовый сценарийУсилие | x y x*y*2 | ||||||
Сначала специалистам по тестированию необходимо увидеть все значимые транзакции, которые необходимо проверить. Обычно каждая значимая транзакция соответствует одному тестовому сценарию. Под термином "значимая" понимается значение, с точки зрения пользователя, для выполнения некоторой задачи с помощью приложения. Согласно этому определению, значимой является только завершенная и корректная транзакция, поскольку неполные и неточные транзакции не выполняют полностью желания пользователя. Из навигационной карты видны два возможных пути для достижения двух конечных точек: Отобразить рецензию на фильм и Результаты выбора фильмов. В таблице они соответствуют основному и подчиненному потокам.
О незавершенных операциях мы поговорим в разделе "Детализация тестовых сценариев". Незавершенные транзакции в архиве эксплуатационных прецедентов соответствуют альтернативному потоку.
Оценка усилий по тестированию
Таблица 1 также объясняет усилия, необходимые для выполнения тестовых сценариев. Усилия привязываются к технологии, которая необходима для достижения конечного результата. Если для автоматизации усилия используется средство для записи и воспроизведения, то вместе взятое минимальное время на реализацию тестовых сценариев составляет удвоенное время процесса записи. Это будет важным фактором при принятии решения о необходимых ресурсах и планировании тестов. Например, если пользователю необходимо y минут для достижения страницы результатов выбора фильма и завершения транзакции покупки, то для получения суммарного времени (z), необходимого на запись и воспроизведение одной такой транзакции, можно умножить y на 2. Суммарные необходимые усилия будут равны z, умноженному на количество тестовых сценариев. Это конечное число можно использовать для итерационного планирования.
Определение тестовых данных
Столбец 5 в таблице 1 показывает наборы данных, необходимые для выполнения тестовых сценариев. Тестовые данные для первого тестового сценария (Основной поток 1) можно легко вывести, взглянув на регистрационную форму и форму выбора фильма. Для нахождения тестовых данных для второго тестового сценария (Подчиненный поток 1) необходимо проверить действия, которые ведут к отображению следующего экрана, который перечисляет фильмы, которые можно выбрать.
Создатель тестов теперь располагает списком тестовых данных, с которыми может работать. Когда есть уже существующая база данных приложений, большая часть работы специалиста по тестированию направлена на определение полезности записей в этой базе. Для достижения широты и глубины охвата тестовых данных специалисту по тестированию необходимо пересмотреть сведения из архива эксплуатационных прецедентов. До тех пор, пока не будут детально продуманы реальные тестовые данные для поддержки соответствующих тестовых сценариев, не будет проделана никакая реальная работа.
Планирование модульности
Ранее объяснялась необходимость определения значимой транзакции. Каждая из этих транзакций может быть представлена одним сценарием тестирования. Транзакции обладают некоторым подобием. Например, каждая транзакция должна начинаться с регистрации в системе, а заканчиваться выходом из системы. Так что сценарии тестирования для каждой из транзакций будут обладать некоторой совершенно одинаковой частью. Когда в одной из этих транзакций требуется произвести некоторые изменения, эти изменения необходимо повторить в сценариях с идентичными транзакциями. Конечно, выполнение большого количества повторений может быть обременительно и занимать много времени.
С применением модульности сопровождение сценариев тестирования становится удобнее. Путем разбиения транзакций на последовательности экранов (как в столбце 4 таблицы 1) можно достигнуть модульности в том случае, если, например, один экран соответствует одному сценарию тестирования.
Таким образом, при изменении основного экрана регистрации (MainFrm), из столбца сценария тестирования (столбец 6 таблицы 1) можно увидеть, что затрагиваются два тестовых сценария. Все, что необходимо сделать, - это изменить всего один сценарий: сценарий регистрации.
Модульность требует создания зависимостей между транзакциями, а следовательно, необходим столбец "Зависимость" в таблице 1. Зависимость может также иметь более широкий контекст: например, она может показывать состояние приложения, от которого зависит текущая транзакция, или показывать завершение выполнения другой транзакции. Для выполнения первого тестового сценария необходимо выполнить три сценария в следующей последовательности: сценарий регистрации, сценарий выбора фильма и сценарий страницы результатов.
Определение правильности транзакций
Последний столбец в таблице 1 определяет ожидаемые результаты тестовых сценариев. Этот столбец является необходимым. Не все шаги проверяются, поскольку это было бы утрированием тестирования. Поскольку целью является возможность для пользователя выполнения транзакции, то проверка ограничивается конечным результатом той транзакции, которая проверяется. Для тестового сценария "Основной поток" проверяется стоимость билета (или билетов) на фильм, полученная из системы. Это цель тестирования. В промежуточной проверке необходимости нет.
Полное тестирование экрана, то есть проверка всех кнопок, комбинированных управляющих элементов, списков, состояний, в котором они находятся, цветовой схемы страницы, размера шрифта каждого символа и т.д., определенно является излишним и никогда не будет хорошей первоочередной целью. Одним из способов узнать, не является ли работа по тестированию лишней, является взгляд на цель тестовых сценариев или любые установленные требования. Исключая явно выраженные обратные инструкции, обычно наилучшим вариантом будет не выходить за рамки этих требований. Следуйте этому правилу, а иначе тестирование может стать слишком непрактичным.
Коротко говоря, навигационная карта позволяет управляющему по тестам следующее: (1) разрабатывать высокоуровневый черновик тестовых сценариев для всего приложения; (2) определять количество создаваемых тестовых данных. Этот черновик можно детализировать в степени, достаточной для указания проверяемых транзакций и ожидаемых выходных значений.
Каталог тестовых идей
Здесь стоит упомянуть "тестовые идеи" и каталог тестовых идей (артефакт RUP). Не покрытые до настоящего времени тестом транзакции являются тестовыми идеями. Тестовые сценарии, которые они представляют, по-прежнему нуждаются в уточнении и детализации. RUP определяет тестовую идею следующим образом:
Краткое утверждение, определяющее тест, который потенциально полезно выполнить. Это утверждение часто представляет один аспект заданного теста: вход, условие выполнения или ожидаемый результат, но обычно только что-то одно из перечисленного. Тестовая идея отличается от тестового сценария тем, что не содержит спецификации работы теста, а только общую его идею.
Тестовые идеи представляют собой высокоуровневые важные средства для выполнения тестов. Вся эта информация помогает менеджерам оценить ресурсы и запланировать все, что необходимо для выполнения тестирования.
В большинстве организаций опыт тестирования является собранием значительно различающегося опыта членов коллектива, работающего над проектом. А методология унификации полученного опыта обычно отсутствует. В качестве решения этой проблемы каталог тестовых идей предоставляет механизм для сбора и повторного использования опыта тестирования различных коллективов и отдельных работников. Чтобы быть по-настоящему полезным, каталог тестовых идей должен предоставлять четкое соответствие между тестовыми идеями и их реализацией (то есть всеми известными тестовыми сценариями).
Примером каталога тестовых идей служит таблица 2. Соответствующая информация по проектам собирается в строках "Создать (записи о билетах в кино)" и "Выбрать (рецензии на фильм)". Также могут существовать подобные тестовые идеи из другого проекта, как в строке "Создать (другие)".
Таблица 2: каталог тестовых идей
| Серийный номер | Функции | Описание проекта | Рассмотрение тестов | Подробности требований к проекту | Сценарий тестирования проекта | Наборы тестовых данных проекта |
| 1 | Создать (записи о билетах в кино) | Привилегированный профиль регистрации , возможность создавать запись о билете, одновременная возможность выбора посадочного места. | Использование различных профилей, использование различных комбинациймест, выборав ремени и т.д. | См. требования к проекту xx Раздел x.x | Регистрация Выбрать экран | См. таблицу, которая содержит наборы тестовых данных |
| 2 | Выбрать (рецензии на фильм) | Отображение статичной страницы | Выбрать различные комбинациив соответствии с объемом возвращенных данных и т.д. | См. требования к проекту xx Раздел x.x | | |
| 3 | Создать (другие) | | | | | |