Определение рамок тестирования интеграции системы
Определение рамок тестирования интеграции системы
Рамки тестирования интеграции системы определяются, исходя из проектирования бизнес-процессов и определения рамок областей бизнеса, проведенного на этапе Концептуального планирования. Как и задача по окончательной конфигурации системы, окончательное тестирование интеграции ориентируется на бизнес-процессы.
План тестирования охватывает следующие аспекты:
• Рамки тестирования
• Сценарии тестирования
• Процессы тестирования
• Ресурсы.
Сценарий теста (или группы процессов) полностью соответствует сценарию бизнес-процесса или другому четко определенному сценарию; сценарий теста можно разделить на тестовые процессы, чтобы упростить задачу пошагового подтверждения сценария. Сценарий процедуры контрольного примера представляет собой жизненно важный поток информации, ассоциированные с ними условия и исключения. Подход к выполнению этой задачи во многом аналогичен подходу к окончательной конфигурации и подтверждению рамок проекта.
Чтобы облегчить проведение тестирования, методология ASAP рекомендует сформировать совокупность циклов интеграционного тестирования, каждый из которых содержит набор бизнес-процессов, отсортированных по принципу приоритетности. Именно такие циклы интеграционного тестирования (L1 и L2) упоминались в разделе «Подготовка концептуального проекта» в главе 14. Циклы тестирования последовательно выполняются, пока не будут решены все проблемы и систему можно признать готовой для перехода к этапу окончательной подготовки перед запуском.
Каждый цикл представляет собой повторяющийся процесс, направленный на систематизацию окончательного тестирования, причем циклы определяются, исходя из следующих критериев:
• Цикл 1: настройка бизнес-процессов для основных данных и высокоприоритетных транзакций с последующим тестированием важнейших бизнес-процессов.
• Цикл 2: тестирование бизнес-процессов, в которых предусмотрены транзакции, отчеты, пользовательские профили, а также исключения из правил или условий выполнения процесса и т. д.
Процесс окончательной интеграции весьма схож с процессом окончательной конфигурации, за исключением того, что в BPML отбираются только те процессы, которые связаны циклами 1 и 2 интеграционного тестирования.
Если нет возможности запланировать тестирование абсолютно всей системы, то можно определить приоритеты, основываясь на следующих критериях:
• Частота процесса
• Эффект от сбоя в данном процессе, количество процессов, которые зависят от данного процесса
• Вероятность того, что сценарий тестирования может случиться в реальной работе.
В методологии ASAP предусмотрена формула для вычисления приоритетности тестирования сценариев; по мере возрастания важности того или иного теста важность его включения в интеграционное тестирование также возрастает.
Подготовка плана окончательного интеграционного тестирования
Подготовка подробного плана интеграционного тестирования должна охватывать все процессы и компоненты, в том числе:
• бизнес-процессы
• отчеты
• интерфейсы
• конвертацию данных
• усовершенствования
• принтеры и факсы.
Рамки такого тестирования определяются в соответствии с проектированием бизнес-процессов и областей бизнеса, заложенным на этапе концептуального планирования. План тестирования подтверждает отношения зависимости между бизнес-процессами и гарантирует проверку всего Концептуального плана предприятия. В этом случае в методологии ASAP также предусмотрены стандартные процедуры тестирования для минимизации затрат времени на эту задачу.
Транспортировка всех объектов в QA и «заморозка» системы
«Заморозка» системы подразумевает полную неизменность конфигурации и настроек системы до окончательного завершения полного цикла интеграционного тестирования, в том числе:
• параметров конфигурации
• настроек клиента
• данных приложений
• объектов Хранилища.
Проведение окончательного интеграционного тестирования
Окончательное интеграционное тестирование проводится на основе плана интеграционного тестирования, что подразумевает стандартные стадии: введение начальных параметров настройки, выполнение сценариев тестирования, запись полученных результатов и их сравнение с ожидавшимися результатами, оценка результатов, документирование и разрешение проблем, и, наконец, окончание тестирования. Интеграционное тестирование проводится теми сотрудниками, в чьи будущие обязанности входит работа с тестируемыми процессами, а также ключевыми пользователями.
Нельзя недооценивать важность интеграционного тестирования, ведь SAP — глубоко интегрированная система, и внесенные в различные модули изменения и настройки могут стать весьма запутанными, вследствие чего изменения в одной области системы могут привести к неожиданным результатам в других областях. Поэтому интеграционное тестирование должно быть тщательным, и охватывать все возможные сценарии работы бизнес-процессов.
Примечание
В методологии ASAP выполнение этой задачи является четвертым важнейшим рубежом проекта.
Получение одобрения результатов тестирования на интеграцию и окончательное оформление системы
На этом этапе необходимо решить все нерешенные вопросы, связанные с окончательным тестированием системы на интеграцию, чтобы еще до запуска убедиться в том, что система с данной конфигурацией полностью отвечает требованиям компании.
Более 800 000 книг и аудиокниг! 📚
Получи 2 месяца Литрес Подписки в подарок и наслаждайся неограниченным чтением
ПОЛУЧИТЬ ПОДАРОКЧитайте также
Параметры отступов и рамок
Параметры отступов и рамок Для задания отступов мы можем пользоваться атрибутами стиля, знакомыми нам по главе 11.— Для задания внутренних отступов между содержимым ячейки и ее границей — атрибутами стиля padding-left, padding-top, padding-right, padding-bottom и padding.— Для задания внешних
Параметры отступов и рамок
Параметры отступов и рамок Для задания отступов мы можем пользоваться атрибутами стиля, знакомыми нам по главе 11.— Для задания внутренних отступов между содержимым ячейки и ее границей — атрибутами стиля padding-left, padding-top, padding-right, padding-bottom и padding.— Для задания внешних
Определение пользовательской системы координат
Определение пользовательской системы координат Как было сказано выше, в AutoCAD существуют: мировая система координат World Coordinate System, WCS, и пользовательская система координат User Coordinate System, UCS. Ось X мировой системы координат направлена горизонтально, осьY– вертикально, а ось Z
14.9.5. Определение текущей платформы или операционной системы
14.9.5. Определение текущей платформы или операционной системы Если программа хочет знать, в какой операционной системе исполняется, то может опросить глобальную константу RUBY_PLATFORM. В ответ будет возвращена загадочная строка (что-то вроде i386-cygwin или sparc-solaris2.7), содержащая
1.6. Реализация инструмента для выбора временных рамок с помощью UISlider
1.6. Реализация инструмента для выбора временных рамок с помощью UISlider Постановка задачи Необходимо дать пользователям возможность указывать определенное значение из диапазона и предоставить для этого удобный в применении и интуитивно понятный пользовательский
Определение пользовательской системы координат
Определение пользовательской системы координат Как было сказано выше, в AutoCAD существуют: мировая система координат World Coordinate System, WCS и пользовательская система координат User Coordinate System, UCS. Ось X мировой системы координат направлена горизонтально, ось F– вертикально, а ось Z
Способы интеграции объектов
Способы интеграции объектов При создании сложных интерьеров (когда сложность определяется количеством непростых по форме объектов), бывает очень удобно использовать библиотечные модели, а не создавать каждый новый объект самостоятельно. Использование библиотечных
Определение пользовательской системы координат
Определение пользовательской системы координат Как было сказано выше, в AutoCAD существуют: мировая система координат World Coordinate System, WCS, и пользовательская система координат User Coordinate System, UCS. Ось X мировой системы координат направлена горизонтально, ось Y – вертикально, а ось Z
Обмен данными и проекты интеграции
Обмен данными и проекты интеграции Большое количество систем, стандартов и технологий, о которых мы говорили ранее, приводит к тому, что эффективно связать разные источники данных в одну систему не получается. Даже такие, казалось бы, однородные источники, как системы
7.5. Определение системы обозначения документов
7.5. Определение системы обозначения документов Стандартные обозначения документов необходимы для эффективного контроля документации. Обозначающая информация может включать в себя:заглавие документа;ссылочный номер документа;номер версии документа;дату выпуска и
Определение рамок проекта SAP
Определение рамок проекта SAP Одна из самых ответственных задач исполнительного и организационного комитетов — определение рамок проекта SAP. Для рассматриваемых в данной книге предприятий нового тысячелетия рекомендуется принять на вооружение внедрение по принципу
Проблемы интеграции PKI
Проблемы интеграции PKI Важным фактором адаптации PKI является решение проблем интеграции и обеспечения работы приложений. PKI может быть интегрирована несколькими способами:* с приложениями (например, клиентскими приложениями электронной почты);* с данными третьей