Определение готовности приложений
Прежде чем развертывать обновление клиента Windows, вы должны знать, какие приложения будут работать без проблем, для которых требуются собственные обновления, а какие просто не будут работать и должны быть заменены. Если вы еще этого не сделали, стоит классифицировать приложения с учетом их важности в вашей организации.
Методы проверки
Для проверки приложений можно выбрать один из различных методов. То, какие именно из них следует использовать, зависит от особенностей вашей среды.
Метод проверки | Описание |
---|---|
Полная регрессия | Полный контроль качества. Сотрудники, которые хорошо знают приложение и могут проверить его основные функции, должны выполнить эту проверку. |
Тестирование дыма | Приложение проходит официальную проверку. То есть пользователь проверяет приложение, следуя подробному плану, в идеале с ограниченными знаниями о приложении, которое он проверяет. |
Автоматическое тестирование | Программное обеспечение выполняет тесты автоматически. Программное обеспечение позволяет узнать, прошли ли тесты или завершились сбоем, и автоматически предоставляет подробные отчеты. |
Тестирование в пилотном режиме | Вы предварительно выберите пользователей, которые должны быть в пилотной группе развертывания, и выполнять те же задачи, которые они выполняют ежедневно, чтобы проверить приложение. Обычно этот метод используется в дополнение к одному из других типов проверки. |
Реактивный ответ | Приложения проверяются в конце пилотного проекта, и конкретные пользователи не выбираются. Эти приложения обычно не устанавливаются на многих устройствах и не обрабатываются корпоративным распределением приложений. |
Объединение различных методов проверки с ранее установленными классификациями приложений может выглядеть следующим образом:
Метод проверки | Критические приложения | Важные приложения | Не важные приложения |
---|---|---|---|
Полная регрессия | x | ||
Тестирование дыма | x | ||
Автоматическое тестирование | x | x | x |
Тестирование в пилотном режиме | x | x | x |
Идентификация пользователей
Так как ваша организация, несомненно, имеет широкий спектр пользователей, каждый из которых имеет различные фоновые и обычные задачи, вы должны выбрать, какие пользователи лучше всего подходят для проверочного тестирования. Ниже приведены некоторые факторы, которые следует учитывать:
- Расположение. Если пользователи находятся в разных физических расположениях, можете ли вы поддержать их и получить отзывы о проверке из региона, в который они находятся?
- Знания о приложениях. Имеют ли пользователи соответствующие знания о том, как должно работать приложение?
- Технические возможности. Достаточно ли у пользователей технической компетенции для предоставления полезных отзывов из различных сценариев тестирования?
Вы можете найти добровольцев, которым нравится работать с новыми функциями, и включить их в пилотное развертывание. Вы можете избежать использования основных пользователей, таких как руководители отделов или руководители проектов. Текущие владельцы приложений, операционный персонал и разработчики могут помочь вам определить наиболее подходящих пилотных пользователей.
Определение и настройка устройств для проверки
Помимо пользователей, важно тщательно выбирать устройства для участия в проверке приложений. Например, в идеале выбранный вариант включает устройства, представляющие все модели оборудования в вашей среде.
Существует несколько способов выбора устройств для проверки приложений:
- Существующие пилотные устройства. Возможно, у вас уже есть список устройств, которые регулярно используются для тестирования обновлений в рамках циклов выпуска.
- Выбор вручную. Некоторые внутренние группы, такие как операции, обладают опытом, помогая вручную выбирать устройства на основе спецификаций, использования или записей о прошлых проблемах поддержки.
- Анализ на основе данных. С помощью соответствующих средств вы можете использовать диагностические данные с устройств для информирования о выборе.
Обратная связь
https://aka.ms/ContentUserFeedback.
Ожидается в ближайшее время: в течение 2024 года мы постепенно откажемся от GitHub Issues как механизма обратной связи для контента и заменим его новой системой обратной связи. Дополнительные сведения см. в разделе:Отправить и просмотреть отзыв по