Несколько дней назад я занимался с одноклассником по Планете и говорил о контроле рисков. Этот одноклассник сказал, что сейчас они находятся в состоянии нехватки ресурсов, быстрого повторения требований, частых выпусков и хаотичного управления версиями, что часто вызывает проблемы в онлайн-системе. Он спросил меня, есть ли какой-нибудь краткосрочный эффективный метод. Он также перечислил несколько методов, которые, по его мнению, могут быть эффективными, а именно:

• Содействие внедрению автоматизированного тестирования для экономии трудовых и временных ресурсов;
• Разработать СОПы по управлению качеством и позволить всем командам, занимающимся производством, исследованиями и разработками, соблюдать их;
• Нанять профессионального менеджера проектов для контроля версий и управления проектами;
• Настроить качественный контроль доступа, установить стандарты входа и выхода для каждого звена и строго их выполнять;

Эффективны ли вышеуказанные методы для улучшения качества доставки? Ответ: да. Но можно ли решить частые проблемы с онлайн-системами в краткосрочной перспективе? Это тяжело. Причину понять нетрудно. Будь то автоматическое тестирование, контроль доступа к качеству, СОП управления качеством или специализированное управление версиями и управление проектами, для постепенного получения результатов требуется большое количество ресурсов и времени.

Самая большая дилемма, с которой мы сталкиваемся в краткосрочной перспективе, — это проблемы с онлайн-системой, и это приоритет, который необходимо рассмотреть и решить. Пообщавшись с ним по этим вопросам, у меня было к нему только одно предложение: контролировать риск изменений и внедрить механизм CheckList.

По неполной статистике, большинство причин проблем онлайн-системы вызваны изменениями. Этот процесс, особенно от среды UAT до онлайн-среды, требует большого количества операций изменений, таких как изменения структуры таблицы базы данных, изменения данных, изменения параметров конфигурации приложения, белые списки приложений, обновления кэша и обновления бизнес-конфигурации, связанные с итерациями версий. Все это может вызвать проблемы в онлайн-системе.

Однако контроль изменений часто подсознательно игнорируется внутри технической команды. Причина в том, что будь то среда разработки или среда тестирования, с одной стороны, процесс контроля изменений практически отсутствует. Если вы измените его по своему желанию, возникнут проблемы. в любом случае прямых потерь не принесет. С другой стороны, контроль и анализ изменений требуют определенного времени и усилий и не могут принести положительных результатов при наличии прямых четких данных. Если так будет продолжаться, просто позвольте этому быть.

С точки зрения разработки программного обеспечения, контроль изменений на самом деле является контролем рисков, который помогает улучшить качество программных продуктов. Студенты технических вузов более или менее это понимают. Но затягивать это дело на нет и хорошо его выполнять – порой неблагодарная работа. Даже внутри некоторых компаний и технических команд команды, отвечающие за качество и стабильность, часто становятся козлами отпущения, что весьма печально.

Что такое контрольный список? Воспринимайте это буквально,CheckList — это чек-лист, то есть перед каждым изменением перечисляются все элементы изменения и возможные риски, проводится целевая проверка и профилактика.。Изменения здесь можно применить к нескольким ссылкам.,Например, разработка и тестирование перед онлайн-выпуском.,Изменения можно перечислить,Проверьте и сравните один за другим,Подтвердите наличие рисков и уязвимостей.

Для студентов-тестировщиков контрольный список — это средство контроля рисков изменений. В реальной работе он может принимать различные формы, такие как интеллект-карты и таблицы Excel. На рисунке ниже представлена ​​интеллектуальная карта контрольного списка перед выпуском в Интернет:

Среди них каждый вторичный объект проверки также может быть подразделен, и между различными объектами проверки существуют зависимости и прогрессивные отношения. Например: механизм плана риска предназначен для контроля объема рисков, а механизм резервного копирования и восстановления можно рассматривать как часть механизма плана риска.

Если вы расширите CheckList, вы также сможете контролировать частоту выпуска, установив окно выпуска, и учащиеся-тестировщики возьмут на себя инициативу контролировать ход выполнения и версию проекта. Кроме того, проблемы в Интернете возникают часто, и необходимо улучшать и оптимизировать механизм проверки, постоянно выявлять существующие проблемы и постоянно решать проблемы.

В долгосрочной перспективе только путем предварительного контроля масштаба и воздействия рисков и их целенаправленного решения можно будет плавно продвигать последующие СОП по автоматизированному тестированию, управлению версиями, управлению проектами и управлению качеством.