OperaПример традиционного приемочного тестирования (OAT)
Томас Гамильтон
⚡ Умное резюме
OperaНациональное приемочное тестирование оценивает, готова ли версия к запуску в соответствии со стандартами. OperaПроверка среды, резервное копирование, восстановление, оповещения, безопасность и документация перед передачей системы группам технической поддержки.
Что такое Operaциональное приемочное тестирование?
Operaциональное приемочное тестирование (OAT) Приемочное тестирование — это метод тестирования программного обеспечения, который оценивает готовность программного приложения к эксплуатации до его выпуска в производство. Цель приемочного тестирования — обеспечить соответствие системы и компонентов стандартам, а также бесперебойную работу системы. OperaОкружающая среда (SOE).
OperaПриемочные испытания также называются OperaНациональное тестирование готовности (ORT) или, если говорить короче, операционное тестирование. Все три названия описывают одну и ту же проверку: программное обеспечение может уже выполнять то, что запрашивала компания, но никто еще не доказал, что его можно установить, создать резервную копию, перезапустить, контролировать и восстановить силами тех, кто будет им пользоваться после запуска в эксплуатацию.
Это отличие прочно ставит OAT в один ряд с нефункциональное тестирование Типы. Вопрос заключается в том, как система ведет себя в реальных условиях эксплуатации, а не в том, возвращает ли функция правильный ответ.
Виды Operaциональное тестирование
OperaМеждународное тестирование — это всеобъемлющая деятельность. Каждый из перечисленных ниже пунктов представляет собой отдельную проверку со своими условиями допуска и подтверждающими документами, и полный цикл OAT обычно охватывает большинство из них.
- Тестирование установки — подтверждает возможность установки, обновления и отката сборки в целевой среде с использованием предоставленной документации.
- Тест нагрузки и производительности Operaпроизводство — проверяет, что система поддерживает ожидаемую пропускную способность и время отклика при объеме работы, аналогичном производственному. См. тестирование производительности и нагрузочное тестирование для базовых методов.
- Тестирование резервного копирования и восстановления — доказывает, что резервную копию действительно можно создать в запланированное время и восстановить до рабочего состояния, а не просто записать на диск.
- Тестирование безопасности — Проверяет средства контроля доступа, учетные данные, сертификаты и меры безопасности в операционной среде. См. тестирование безопасности Подробное описание метода приведено ниже.
- Code Анализ — Статический анализ предоставленного кода и конфигурации на предмет удобства сопровождения и выявления известных уязвимостей, прежде чем это станет проблемой для кого-либо в процессе эксплуатации.
- Отказоустойчивое тестирование — принудительно отключает узел, службу или сайт и отслеживает, возьмет ли на себя управление резервный узел в течение согласованного времени.
- Тестирование восстановления — измеряет, насколько полно и быстро система восстанавливается после сбоя. Тестирование восстановления Подробно рассматривает данную технику.
- Концы с концами Тестовая среда Operaциональное тестирование — управляет всей цепочкой серверов, сетей, задач и интерфейсов как единым операционным блоком.
- Operaционная документация RevМЭН — проверяет соответствие руководств по эксплуатации, схем обслуживания, приказов на перезапуск и путей эскалации фактической системе.
На приведенной ниже диаграмме эти проверки сгруппированы по этапам выпуска, при этом операционное тестирование показано как последний этап перед тем, как приложение попадет в рабочую среду.
Почему Operaциональное тестирование
OperaФункциональное тестирование существует потому, что релиз, удовлетворяющий всем функциональным требованиям, всё равно может оказаться неработоспособным.
- В ходе приемочного тестирования впервые происходит объединение конфигураций программного обеспечения и компонентов оперативной поддержки.
- Он проверяет реализацию функциональных или структурных изменений в программном обеспечении или сервисе в функциональной или нефункциональной среде.
- Данное тестирование определяет, может ли приложение быть развернуто в сети в соответствии со стандартами IT Infrastructure Library (ITIL).
- Это показывает, будет ли программное обеспечение работать так, как задумано, не нарушая бизнес-процессы.
- OAT фокусируется главным образом на следующих аспектах программного продукта:
- Упругость
- Восстановление способности
- Управляемость и поддерживаемость
- Integrity
Кто выступает? OperaНациональное тестирование и когда
Правила проведения теста OAT отличаются от правил всех предыдущих уровней тестирования, и это различие объясняет большинство его результатов. Проводят его те же люди, которым позвонят в три часа ночи.
- Системные администраторы и инженеры инфраструктуры — выполнить установку, переключение на резервный сервер и перезапуск процессов в целевой среде.
- Operaгруппы поддержки и команды поддержки — Проверить подлинность оповещений, пороговых значений, путей эскалации и документов по устранению неполадок, на которые ссылается каждое оповещение.
- Администраторы баз данных и резервного копирования — создавать и восстанавливать резервные копии, включая восстановление на второй сайт.
- Сотрудники службы безопасности и соблюдения нормативных требований — Подтвердить усиление безопасности, контроль доступа и ведение журналов аудита в среде, приближенной к реальной.
- менеджеры по тестированию — Соберите доказательства и внесите их в пакет документов для принятия решения о запуске системы.
В жизненный цикл тестирования программного обеспеченияЭксплуатационные испытания проводятся в самом конце. Тестирование системы Процесс OAT доказывает работоспособность собранного продукта, пользовательское приемочное тестирование доказывает, что бизнес его принимает, а затем OAT доказывает, что организация может его использовать. Поскольку для OAT необходима среда, максимально приближенная к производственной, его обычно планируют после того, как кандидат на релиз будет утвержден — любое изменение кода после этого момента возвращает цикл к началу.
Примеры тестовых случаев для Operaциональное тестирование или OAT
Ниже приведён удобный контрольный список для проведения OAT (Outdoor Approach). Каждая строка составлена таким образом, что результатом является простое «пройдено» или «не пройдено», что и необходимо для запуска платы в эксплуатацию.
- Резервные копии, созданные на одном сайте, могут быть восстановлены на том же сайте.
- Резервные копии, созданные на одном сайте, могут быть восстановлены на другом сайте.
- Внедрение любых новых функций в рабочую среду не оказывает негативного влияния на целостность существующих производственных сервисов.
- Процесс внедрения можно воспроизвести, используя достоверную документацию.
- Каждый компонент может быть успешно выключен и запущен в согласованные сроки.
- Для оповещений все критические оповещения должны направляться в TEC со ссылкой на соответствующий документ по устранению проблемы.
- Система оповещений настроена и выдается в случае превышения согласованных пороговых значений.
- Любая созданная или измененная документация по восстановлению, включая схемы обслуживания, является действительной. Ее следует передать в соответствующие подразделения поддержки.
- Для каждого компонента, затронутого сбоем, отображается рекомендуемый порядок перезапуска, время его выполнения и задействованные зависимости.
Практическое дополнение к списку — это отрицательный сценарий: намеренно нарушить одну зависимость, затем убедиться, что сработало оповещение, найден сценарий выполнения и описанный порядок перезапуска восстанавливает работу сервиса. Контрольный список, который всегда фиксирует только успешные случаи, вообще не проверяет работу системы.
OperaНациональное тестирование против пользовательского приемочного тестирования
Овсянка и приемочное тестирование пользователя Оба мероприятия являются формальными и проводятся с опозданием, поэтому их так часто путают. Они отвечают на разные вопросы и утверждаются разными людьми.
| Аспект | Operaциональное приемочное тестирование (OAT) | Пользовательское приемочное тестирование (UAT) |
| Ответ на вопрос | Способна ли организация управлять этой системой и оказывать ей поддержку? | Соответствует ли система согласованным бизнес-требованиям? |
| Выполняется | Operaинфраструктура и вспомогательный персонал | Конечные пользователи, заинтересованные стороны бизнеса и клиенты |
| Тип требования | В основном нефункциональные — восстановление, резервное копирование, оповещения, безопасность. | В основном функциональный — бизнес-процессы и правила. |
| Окружающая среда | Работает как в производственной среде, с реальными инструментами мониторинга и резервного копирования. | Стабильная тестовая среда с репрезентативными данными. |
| Типичные доказательства | Восстановление журналов, тайминги переключения на резервный сервер, снимки экрана оповещений, подписанные руководства по эксплуатации. | Реализованные бизнес-сценарии и утверждение пользователями. |
| Неудача выглядит так | Система работает, но её невозможно восстановить, контролировать или перезапустить. | Система работает, но не выполняет то, что запрашивала компания. |
Эти два подхода дополняют друг друга, а не являются альтернативами. Релиз, прошедший UAT и не прошедший OAT, будет корректно функционировать вплоть до первого сбоя.
Преимущества и проблемы Operaциональное тестирование
Команды, внедряющие OAT, обычно отмечают одни и те же преимущества и сталкиваются с одними и теми же препятствиями.
Преимущества
- Риск сбоев снижается, поскольку механизмы восстановления и переключения на резервный канал запускаются до того, как от них начнут зависеть клиенты.
- Группы поддержки получают в наследство документацию, проверенную на реальных условиях работы системы, а не написанную на основе проектных требований.
- Неожиданные моменты, связанные с развертыванием, проявляются в контролируемый период времени, а не в ночь запуска системы.
- Документы, подтверждающие соответствие требованиям и результаты аудита, формируются в качестве побочного продукта использования контрольного списка.
Задачи
- Создание среды, максимально приближенной к производственной, обходится дорого, а уменьшенная копия скрывает именно те недостатки, которые призвана выявлять система OAT.
- Этот цикл конкурирует за то же место в календаре, что и релиз, поэтому при переносе даты он сокращается в первую очередь.
- Для таких критических ситуаций, как переключение на резервный сервер и восстановление, требуются согласования, а также существуют периоды затишья, которые трудно получить.
- Результаты зависят от оперативного персонала, который одновременно управляет текущим работающим сервисом.
Обычно для решения проблемы начинают с малого: сначала автоматизируют резервное копирование, восстановление и перезапуск, поскольку они повторяются при каждом выпуске и дают наиболее четкий сигнал о прохождении или непрохождении проверки. Далее контрольный список может расширяться с каждым циклом, и любое изменение в руководствах по устранению неполадок становится кандидатом на проверку. регрессионное тестирование в следующем релизе.
