Я видел, как некоторые студенты задавали вопросы о стандартах доступа к тестированию и выхода из него. Они сказали, что процесс тестирования НИОКР в их компании был хаотичным, и после онлайн-релиза возникло много проблем, и они не знали, как их оптимизировать и решить. На самом деле, эта проблема обычно возникает в новых компаниях или новых проектах, а направление и методы оптимизации относительно зрелы в отрасли. В этой статье речь пойдет о моем понимании входа и выхода.

С точки зрения разработки программного обеспечения программный продукт с нуля проходит следующие этапы:

Этап исследований и разработок в основном включает в себя реализацию кодирования, тестирование и проверку, а также выпуск для эксплуатации и обслуживания. Строго говоря, чтобы контролировать риски и гарантировать соответствие конечного поставляемого программного продукта ожидаемым стандартам качества, на каждом этапе всего жизненного цикла должны существовать соответствующие стандарты входа и выхода. В соответствии с процессом тестирования мы называем это контролем качества доступа. Лично я считаю, что в определении контроля качества есть два наиболее важных звена: тестирование релиза и проверка релиза.

Тестирование выпуска — это возможность перехода программного обеспечения от этапа реализации кодирования к этапу тестирования и проверки. Мы все слышали поговорку: качество проектируется и реализуется, а не тестируется. Точно так же то, насколько хорошо вы справитесь с этапом тестирования, окажет большое влияние на последующую работу по тестированию. Если этот контроль доступа не упомянут, весьма вероятно, что вы столкнетесь со многими проблемами в начале теста, такими как несинхронизация структуры таблицы, сбой запроса интерфейса и блокировка основного процесса, что влияет на общую производительность. прогресс и эффективность тестирования, что приведет к сверхурочной работе и множественным доработкам.

Стандарты приема на этап выпуска и тестирования обычно необходимо рассматривать со следующих точек зрения:

• реализована ли функция：Помимо этогоразвивать Кроме локального самотестирования,Очень важный момент — обзор вариантов использования теста. Пройти проверку варианта использования теста,Обе стороны развития и тестирования достигли соглашения о необходимых функциях и стандартах, которые будут реализованы в этой версии.
• Является ли процесс гладким?：Общий подходтест Предоставьте эту версиюP0тествариант использования(Основной процесс напрямую связан с)позволятьразвиватькуритьтест,Студенты несут ответственность за принятие теста,Если тест на дым не пройден,Затем перезвоните и повторите тест.
• Изменение завершено?：Изменения здесь главным образом касаются того, синхронизирована ли соответствующая структура таблицы стестсреда,Были ли выложены соответствующие контрольные данные?,Являются ли внутренние и внешние зависимости вызовов гладкими (если нет,Тогда рассмотрим Конфигурациюmock),А также элементы конфигурации, такие как новые развертывания Служить и белые списки.

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

• Модульное тестирование：Убедитесь, что каждый функциональный модуль полностью Модульное проверки, для выявления потенциальных дефектов (не обязательно).
• Совместный отладочный тест：Проводить сквозную совместную отладку каждого функционального модуля,Убедитесь, что вся система работает правильно (развивайте самоорганизацию).
• Подтверждение изменения：Прежде чем пройти тест,Уточните у разработчиков и продуктовой команды, изменились ли требования.,И внести изменения в соответствующие документы-требования (предложения).
• Документация интерфейса：убеждатьсяразвивать Команда подготовила полный Документация интерфейс, чтобы команда тестировщиков могла взаимодействовать с тестом (предложения).
• Тестовый полигон：развивать Нужно указать тестовую версию、Область применения и связанный список рисков,Убедитесь, что тестировщик понимает цель и потенциальные проблемы (последующие действия по тесту).
• Экологическая подготовка：существовать Прежде чем пройти тест,убеждатьсятест Экологическая подготовка готова и может быть запущена в обычном режиме (соответствует вышеуказанным изменениям).
• контроль версий：использоватьконтроль использовать систему (например, Git) для отслеживания изменений кода, чтобы гарантировать, что члены команды имеют доступ к последней версии кода.

Помимо этого, при прохождении теста вы также можете столкнуться со следующими проблемами:

• Автоматизировать ли вариант использования основного процесса: это будет решено в Чэнду на основе базовой технической конструкции и возможностей команды, а также изобилия ресурсов.
• Несколько ветвей и несколько сред,Как решить：Хорошо поработайте над управлением версиями кода.、Запросить маркировку и покраску、Экологическое управление.

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

Обзор релиза можно рассматривать как квази-выходной этап этапа тестирования. В процессе обзора релиза необходимо учитывать следующие аспекты:

• функциональная полнота：Все ли требования выполнены?,Есть ли упущения?
• Безопасность и совместимость：Есть ли уязвимости безопасности?,Совместимо ли оно с различными операционными системами и устройствами.
• Статус исправления дефекта：НайденныйBUGВсе ли они отремонтированы и проверены?,Достаточно ли резерва для нештатных сценариев.
• Производительность и масштабируемость：Соответствуют ли показатели эффективности стандартам,Можно ли расширить Служить по горизонтали?,Сможет ли он поддерживать нормальную работу онлайн-бизнеса.
• Документация полная и точная：Руководство пользователя、Подготовлено ли и точно ли руководство по эксплуатации и техническому обслуживанию и соответствующая техническая документация.
• Планы выпуска и планы рисков：Подробный план онлайн-релиза,Возможные проблемы и соответствующие стратегии решения,Были ли какие-то учения?

В плане выпуска необходимо указать время выпуска, каналы выпуска, методы выпуска и т. д. Ключевые факторы, которые следует учитывать:

• Приоритет выпуска：зависимости приложения,Какое приложение опубликовать первым,Какое приложение опубликовать позже.
• Связанные изменения конфигурации：Включая изменения в табличную структуру базы данных、Изменения данных、Добавлять ли белый список приложений.
• Подготовка данных и онлайн-проверка：Были ли кэшированные данные прогреты、Скрипт онлайн-проверки&вариант использования&тест Данные готовы?。
• Управление рисками и планы действий в чрезвычайных ситуациях：Стратегии решения проблем в издательском процессе,Откатывать ли назад, Ограничивать ли ток、Будь то оттенки серого или стратегии коммуникации и координации.

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