Определение значимых транзакций. Определение значимых транзакций
 Скачать 75.05 Kb.
|
Определение значимых транзакцийНавигационная карта показывает все перекрестные связи между экранами. Разработчик тестов может использовать эти связи для моделирования потока транзакций. Для данного примера создание тестовых сценариев, которые сопоставлены навигационным потокам, приведено в таблице 1. Таблиц
Сначала специалистам по тестированию необходимо увидеть все значимые транзакции, которые необходимо проверить. Обычно каждая значимая транзакция соответствует одному тестовому сценарию. Под термином "значимая" понимается значение, с точки зрения пользователя, для выполнения некоторой задачи с помощью приложения. Согласно этому определению, значимой является только завершенная и корректная транзакция, поскольку неполные и неточные транзакции не выполняют полностью желания пользователя. Из навигационной карты видны два возможных пути для достижения двух конечных точек: Отобразить рецензию на фильм и Результаты выбора фильмов. В таблице они соответствуют основному и подчиненному потокам. О незавершенных операциях мы поговорим в разделе "Детализация тестовых сценариев". Незавершенные транзакции в архиве эксплуатационных прецедентов соответствуют альтернативному потоку. Оценка усилий по тестированиюТаблица 1 также объясняет усилия, необходимые для выполнения тестовых сценариев. Усилия привязываются к технологии, которая необходима для достижения конечного результата. Если для автоматизации усилия используется средство для записи и воспроизведения, то вместе взятое минимальное время на реализацию тестовых сценариев составляет удвоенное время процесса записи. Это будет важным фактором при принятии решения о необходимых ресурсах и планировании тестов. Например, если пользователю необходимо y минут для достижения страницы результатов выбора фильма и завершения транзакции покупки, то для получения суммарного времени (z), необходимого на запись и воспроизведение одной такой транзакции, можно умножить y на 2. Суммарные необходимые усилия будут равны z, умноженному на количество тестовых сценариев. Это конечное число можно использовать для итерационного планирования. Определение тестовых данныхСтолбец 5 в таблице 1 показывает наборы данных, необходимые для выполнения тестовых сценариев. Тестовые данные для первого тестового сценария (Основной поток 1) можно легко вывести, взглянув на регистрационную форму и форму выбора фильма. Для нахождения тестовых данных для второго тестового сценария (Подчиненный поток 1) необходимо проверить действия, которые ведут к отображению следующего экрана, который перечисляет фильмы, которые можно выбрать. Создатель тестов теперь располагает списком тестовых данных, с которыми может работать. Когда есть уже существующая база данных приложений, большая часть работы специалиста по тестированию направлена на определение полезности записей в этой базе. Для достижения широты и глубины охвата тестовых данных специалисту по тестированию необходимо пересмотреть сведения из архива эксплуатационных прецедентов. До тех пор, пока не будут детально продуманы реальные тестовые данные для поддержки соответствующих тестовых сценариев, не будет проделана никакая реальная работа. Планирование модульностиРанее объяснялась необходимость определения значимой транзакции. Каждая из этих транзакций может быть представлена одним сценарием тестирования. Транзакции обладают некоторым подобием. Например, каждая транзакция должна начинаться с регистрации в системе, а заканчиваться выходом из системы. Так что сценарии тестирования для каждой из транзакций будут обладать некоторой совершенно одинаковой частью. Когда в одной из этих транзакций требуется произвести некоторые изменения, эти изменения необходимо повторить в сценариях с идентичными транзакциями. Конечно, выполнение большого количества повторений может быть обременительно и занимать много времени. С применением модульности сопровождение сценариев тестирования становится удобнее. Путем разбиения транзакций на последовательности экранов (как в столбце 4 таблицы 1) можно достигнуть модульности в том случае, если, например, один экран соответствует одному сценарию тестирования. Таким образом, при изменении основного экрана регистрации (MainFrm), из столбца сценария тестирования (столбец 6 таблицы 1) можно увидеть, что затрагиваются два тестовых сценария. Все, что необходимо сделать, - это изменить всего один сценарий: сценарий регистрации. Модульность требует создания зависимостей между транзакциями, а следовательно, необходим столбец "Зависимость" в таблице 1. Зависимость может также иметь более широкий контекст: например, она может показывать состояние приложения, от которого зависит текущая транзакция, или показывать завершение выполнения другой транзакции. Для выполнения первого тестового сценария необходимо выполнить три сценария в следующей последовательности: сценарий регистрации, сценарий выбора фильма и сценарий страницы результатов. Определение правильности транзакций Последний столбец в таблице 1 определяет ожидаемые результаты тестовых сценариев. Этот столбец является необходимым. Не все шаги проверяются, поскольку это было бы утрированием тестирования. Поскольку целью является возможность для пользователя выполнения транзакции, то проверка ограничивается конечным результатом той транзакции, которая проверяется. Для тестового сценария "Основной поток" проверяется стоимость билета (или билетов) на фильм, полученная из системы. Это цель тестирования. В промежуточной проверке необходимости нет. Полное тестирование экрана, то есть проверка всех кнопок, комбинированных управляющих элементов, списков, состояний, в котором они находятся, цветовой схемы страницы, размера шрифта каждого символа и т.д., определенно является излишним и никогда не будет хорошей первоочередной целью. Одним из способов узнать, не является ли работа по тестированию лишней, является взгляд на цель тестовых сценариев или любые установленные требования. Исключая явно выраженные обратные инструкции, обычно наилучшим вариантом будет не выходить за рамки этих требований. Следуйте этому правилу, а иначе тестирование может стать слишком непрактичным. Коротко говоря, навигационная карта позволяет управляющему по тестам следующее: (1) разрабатывать высокоуровневый черновик тестовых сценариев для всего приложения; (2) определять количество создаваемых тестовых данных. Этот черновик можно детализировать в степени, достаточной для указания проверяемых транзакций и ожидаемых выходных значений. Каталог тестовых идей Здесь стоит упомянуть "тестовые идеи" и каталог тестовых идей (артефакт RUP). Не покрытые до настоящего времени тестом транзакции являются тестовыми идеями. Тестовые сценарии, которые они представляют, по-прежнему нуждаются в уточнении и детализации. RUP определяет тестовую идею следующим образом: Краткое утверждение, определяющее тест, который потенциально полезно выполнить. Это утверждение часто представляет один аспект заданного теста: вход, условие выполнения или ожидаемый результат, но обычно только что-то одно из перечисленного. Тестовая идея отличается от тестового сценария тем, что не содержит спецификации работы теста, а только общую его идею. Тестовые идеи представляют собой высокоуровневые важные средства для выполнения тестов. Вся эта информация помогает менеджерам оценить ресурсы и запланировать все, что необходимо для выполнения тестирования. В большинстве организаций опыт тестирования является собранием значительно различающегося опыта членов коллектива, работающего над проектом. А методология унификации полученного опыта обычно отсутствует. В качестве решения этой проблемы каталог тестовых идей предоставляет механизм для сбора и повторного использования опыта тестирования различных коллективов и отдельных работников. Чтобы быть по-настоящему полезным, каталог тестовых идей должен предоставлять четкое соответствие между тестовыми идеями и их реализацией (то есть всеми известными тестовыми сценариями). Примером каталога тестовых идей служит таблица 2. Соответствующая информация по проектам собирается в строках "Создать (записи о билетах в кино)" и "Выбрать (рецензии на фильм)". Также могут существовать подобные тестовые идеи из другого проекта, как в строке "Создать (другие)". Таблица 2: каталог тестовых идей
Детализация тестовых сценариев с использованием архива эксплуатационных прецедентов После чернового создания высокоуровневых тестовых идей работающий над проектом коллектив может начинать детализировать тестовые сценарии. Для определения реальных этапов тестовых сценариев мы сошлемся на архив эксплуатационных прецедентов, который является этапами эксплуатационных прецедентов с дополнительной информацией об опыте пользователя. Архив эксплуатационных прецедентов показан на рисунке 2.  Рисунок 2: архив эксплуатационных прецедентов Чтобы архив эксплуатационных прецедентов был полезен для детализации тестовых сценариев, необходимы некоторые дополнительные сведения: Расскажите, как пользователи будут использовать систему. Архив должен предоставлять пошаговый процесс опыта работы пользователя с этим приложением. Этот процесс в конце концов определит тестовые процедуры, так что архив эксплуатационных прецедентов должен предоставлять достаточно подробные сведения. Поскольку наш пример с Web-узлом продажи билетов в кино имеет два подчиненных потока, то необходимо выполнить как минимум два тестовых сценария. Опишите, какие типы объектов могут быть видимыми и их важность для пользователя. Это важная информация для специалистов по тестированию. Вместо того, чтобы полагаться на свой опыт и обучение для определения точек проверки, они находят эти весьма чувствительные точки в архиве эксплуатационных прецедентов. Специалистам по тестированию необходимо создавать методы проверки тестовых сценариев. В данном случае это проверка использования правильной цветовой схемы для отображения цен. По возможности включайте различные тестовые сценарии. Различные подчиненные потоки определяют количество производимых тестовых сценариев. Альтернативные потоки также увеличивают количество тестовых сценариев. Одним из недостатков навигационных карт является то, что они не показывают готовые альтернативные потоки, так что легко упустить некоторые тестовые сценарии. Наш пример имеет два альтернативных потока. Обычно опытные специалисты по тестированию находят дополнительные альтернативные потоки при детализации тестовых сценариев или во время реального выполнения тестов, когда обнаруживаются новые варианты. Включайте наборы тестовых данных для всех определенных тестовых сценариев. Каждый из этих наборов тестовых данных, определенных ранее, будет кандидатом на различные тестовые сценарии и для дальнейшей разработки. Временами наборы тестовых данных также необходимо уточнять. Например, если пользователи имеют различные профили (как в первом приведенном ранее правиле), то тестовые данные должны отражать это для правильного тестирования механизма профилей. В таких случаях определите наилучший тестовый сценарий, а затем создайте дополнительные тестовые сценарии, которые будут отражать различные наборы тестовых данных. В представленном на рисунке 2 архиве эксплуатационных прецедентов для основного потока могут существовать различные тестовые сценарии. Например, специалист может решить протестировать основной поток с использованием нескольких профилей, или выбрать комбинацию экранных вводов, и т.д. Для соответствия каждому набору тестовых данных (каждому выбранному профилю) создается один тестовый сценарий. Альтернативный метод заключается в выполнении тестового сценария с использованием другого набора данных, но в данном случае важно явно отслеживать различные наборы тестовых данных. Я рекомендую использовать старый метод, поскольку существует прямая зависимость между набором данных и его тестовым сценарием. Предоставьте данные, помогающие проанализировать рабочую нагрузку. При обычном тестировании производительности важно определить, где в приложении будет высокий уровень обмена данными. Иногда моделирования всего обмена данными может быть невозможным, так что мы используем правило 80/20 для исключения какой-то части менее важного обмена данными. Другими словами, следует моделировать лишь 80% или более всего объема передаваемых данных, а моделирование оставшихся 20% можно не производить. В нашем примере первый подчиненный поток создает 95% потока данных. Этот объем и необходимо моделировать при тестировании производительности. Оставшиеся 5% претендуют на то, чтобы ими пренебрегли. Либо, в том случае, если уже был создан функциональный сценарий, его можно здесь повторно использовать в качестве замены. Если информация об объеме потока данных отсутствует, например, из-за недавнего создания системы, то возможно моделирование рабочей нагрузки с использованием широчайшего спектра нагрузок. По возможности изучите всех пользователей приложения и определите деловую активность, связанную с работой приложения. Эти действия используются для создания чернового варианта рабочей нагрузки. Сбор всего пользовательского в архив эксплуатационных прецедентов предоставляет целенаправленно выделенную важную информацию для выполнения работ по тестированию. Все эти правила помогают детализировать тестовые сценарии, как показано в таблице 1. Использование таблицы для сбора всей информации в одном месте позволяет специалистам по тестированию быстро справляться с требованиями к тестам и определять, какой объем работы потребуется для их выполнения. Позже специалисты могут обнаружить большее количество тестовых сценариев, но общее количество должно быть осуществимо по мере улучшения работы коллектива с тестовыми сценариями. Обычно специалисту по тестированию потребуется выполнить одну итерацию для оценки и понимания этого процесса тестирования. Чередование экранов В модели UX существуют и другие элементы. Например, чередование экранов, показанное на рисунке 3, является циклограммой, а сообщения между экранами являются действиями, которые может выполнить пользователь. На каждый архив эксплуатационных прецедентов существует обычно одна последовательность экранов. Следует заметить, что отдельные действия входят во временную последовательность и могут зависеть от ранее произведенных действий. Так что транзакции должны учитывать такие последовательности. Эта циклограмма позволяет конструктору тестов дополнительно уточнять тестовые сценарии. Однако, большая часть приведенной выше информации доступна в текстовом формате из архива эксплуатационных прецедентов, так что относительно чередования экранов мы не будем предоставлять дополнительную информацию и описание действий.  Рисунок 3: чередование экранов при покупке билетов в кино Заключение Управление тестами включает в себя различные действия: создание коллектива работников, разработку главного плана тестирования, который детализирует используемые для тестирования методы и цель тестирования с точки зрения организации, разработку тестового плана, относящегося к коллективу, работающему над проектом, и многое другое. Модель UX помогает коллективам начать успешное тестирование. Они могут произвести начальное планирование ресурсов с помощью навигационной карты, не затрачивая слишком много времени на подробности. Затем, по мере прогресса разработки и роста важности детализации тестовых сценариев, они смогут найти в архивах эксплуатационных прецедентов большинство необходимых сведений. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||