| СТАТЬЯ |
17.07.03
|
|
Управлять тестами стало легче: перспектива модели пользовательского опыта |
© Энди Йэп (Andy Yap)
Специалист по созданию программного обеспечения,
Rational Software
IBM Software Group
Содержание
Во многих проектах по разработке программного обеспечения (ПО) не уделяется достаточного внимания тестированию, и поэтому не выполняется строгое соответствие тестам, необходимым для получения хорошего программного продукта. Часто в этом обвиняют неопытного управляющего по тестам, но иногда просто не хватает времени на то, чтобы одновременно уложиться в сроки реализации проекта и использовать всеобъемлющий подход к тестированию.
Однако, с помощью перспективного планирования, которое поддерживается посредством Rational Unified Process (или RUP), коллективы, работающие над проектами, могут обеспечить необходимый запас времени на тестирование в течение всего жизненного цикла разработки. RUP обеспечивает, наряду с другими функциями, итеративный и основанный на прецедентах использования подход к разработке ПО. Этот подход требует от коллектива разработчиков указания правильных требований к управлению, как к инкрементным добавлениям возможностей, так и к тестированию, основанному на тестовых сценариях. Эксплуатационные прецеденты предлагают хорошо описанные этапы взаимодействия пользователя с системой. Как правило, этапы эксплуатационных прецедентов можно использовать в качестве тестовых процедур, поэтому существует тенденция к сопоставлению прохождения эксплуатационных прецедентов и тестовых сценариев.
Что такое тестовый сценарий? RUP определяет это следующим образом:
Определение (обычно формальное) конкретного набора входных данных теста, условий выполнения и ожидаемых результатов, указанных с целью оценки некоторого конкретного аспекта целевого тестового элемента.
Обозначение высокоуровневых тестовых сценариев запустит процесс управления тестом, который должен быть простым, удобным для обмена данными и легко понятным, поскольку большее количество тестовых сценариев будет задаваться на поздней стадии разработки ПО, или тогда, когда работающий над проектом коллектив лучше поймет требования.
Есть два главных элемента, которые в случае их своевременного и правильного определения, облегчат тестирование:
После определения этих элементов все остальные усилия по управлению тестами становятся на свои места. Эта статья описывает, как происходит управление тестами согласно модели пользовательского опыта (UX - User Experience).1)
Проекты принимают модель пользовательского опыта (UX) как часть операций разработки ПО, поскольку она позволяет им моделировать пользовательские интерфейсы - то есть физический и психологический опыт использования создаваемого приложения. Следовательно, модель UX формирует обобщение прототипа приложения. Это комбинация моделирования и сбора требований для создания прототипа, которая наиболее интересна специалистам по проведению тестов. Сегодня все большее число коллективов, работающих над проектами, знают, как создавать модель UX до создания прототипа. Если Вам необходимо определить тестовые сценарии для функционального тестирования, можно начать с рассмотрения модели UX. Поскольку она описывает то, как пользователь будет работать с интерфейсами для достижения своих целей, то отсюда естественным образом можно получить функциональные тестовые сценарии. Также ее можно использовать для определения рабочей нагрузки для тестирования производительности. Следовательно, модель UX становится для коллектива по тестированию тестовым мотиватором. RUP определяет тестовый мотиватор следующим образом:
Нечто, что предоставляет стимул к проведению тестов, побуждает специалистов по тестированию к действиям и подталкивает их к проведению тестов. Тестовые мотиваторы помогают определить и сделать видимыми те вещи, которые будут побуждать специалистов по тестированию оценивать соответствующие аспекты данной версии ПО: обобщенно, тестовые мотиваторы обычно представляют собой определенные риски качества.
Давайте рассмотрим, как процесс моделирования UX начинает обнаруживать тестовые мотиваторы.
В типичном проекте сначала моделируется экран, который будет видеть конечный пользователь. Это делается с использованием стереотипов классов <<экран>> и/или <<форма ввода>>. Экраны соединяются вместе в цепочку диаграммы смены экранов, которая представляет собой использование приложения каким-либо образом. Текстовым дополнением этого представления является архив эксплуатационных прецедентов. Многочисленные эксплуатационные прецеденты описывают то, как пользователь взаимодействует с приложением. Все главные пути, которыми пользователь может использовать приложения, представляет навигационная карта.
Мы пройдем через пример покупки билета в кино (Purchase Movie Ticket) на основе модели UX, которая состоит из навигационной карты (рисунок 1), архива эксплуатационных примеров покупки билета в кино (рисунок 2) и череды экранов (рисунок 3).
Вот шаги, которые необходимы для получения чернового плана управления тестами:
Рисунок 1 показывает навигационную карту для нескольких экранов, относящихся к одному архиву эксплуатационных прецедентов. Для завершения транзакции покупки билета в кино пользователь должен взаимодействовать с тремя экранами и двумя формами ввода данных. Эти две формы ввода данных (стандартно называемые <<форма ввода>>) служат для ввода входных значений, таких как имя пользователя и пароль. На рис. 1 каждый экран имеет средний раздел, показывающий, что пользователь может видеть, и нижний раздел, показывающий, что пользователь может делать.
Рисунок 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 | Создать (другие) |
После чернового создания высокоуровневых тестовых идей работающий над проектом коллектив может начинать детализировать тестовые сценарии.
Для определения реальных этапов тестовых сценариев мы сошлемся на архив эксплуатационных прецедентов, который является этапами эксплуатационных прецедентов с дополнительной информацией об опыте пользователя. Архив эксплуатационных прецедентов показан на рисунке 2.
Рисунок 2: архив эксплуатационных прецедентов
Чтобы архив эксплуатационных прецедентов был полезен для детализации тестовых сценариев, необходимы некоторые дополнительные сведения:Сбор всего пользовательского в архив эксплуатационных прецедентов предоставляет целенаправленно выделенную важную информацию для выполнения работ по тестированию. Все эти правила помогают детализировать тестовые сценарии, как показано в таблице 1. Использование таблицы для сбора всей информации в одном месте позволяет специалистам по тестированию быстро справляться с требованиями к тестам и определять, какой объем работы потребуется для их выполнения. Позже специалисты могут обнаружить большее количество тестовых сценариев, но общее количество должно быть осуществимо по мере улучшения работы коллектива с тестовыми сценариями. Обычно специалисту по тестированию потребуется выполнить одну итерацию для оценки и понимания этого процесса тестирования.
В модели UX существуют и другие элементы. Например, чередование экранов, показанное на рисунке 3, является циклограммой, а сообщения между экранами являются действиями, которые может выполнить пользователь. На каждый архив эксплуатационных прецедентов существует обычно одна последовательность экранов. Следует заметить, что отдельные действия входят во временную последовательность и могут зависеть от ранее произведенных действий. Так что транзакции должны учитывать такие последовательности. Эта циклограмма позволяет конструктору тестов дополнительно уточнять тестовые сценарии. Однако, большая часть приведенной выше информации доступна в текстовом формате из архива эксплуатационных прецедентов, так что относительно чередования экранов мы не будем предоставлять дополнительную информацию и описание действий.
Рисунок 3: чередование экранов при покупке билетов в кино
Управление тестами включает в себя различные действия: создание коллектива работников, разработку главного плана тестирования, который детализирует используемые для тестирования методы и цель тестирования с точки зрения организации, разработку тестового плана, относящегося к коллективу, работающему над проектом, и многое другое.
Модель UX помогает коллективам начать успешное тестирование. Они могут произвести начальное планирование ресурсов с помощью навигационной карты, не затрачивая слишком много времени на подробности. Затем, по мере прогресса разработки и роста важности детализации тестовых сценариев, они смогут найти в архивах эксплуатационных прецедентов большинство необходимых сведений.
Дополнительная информация
За дополнительной информацией обращайтесь в компанию Interface Ltd.
| INTERFACE Ltd. |
| ||||
