Тестирование. Как Избежать Нестабильности, Вызванной Непрерывной Интеграцией, В Тестовых Средах?

Предположим, вы используете процессы непрерывной интеграции, которые часто обновляют некоторые целевые среды, так что каждый раз, когда происходят какие-то изменения, «вы» можете сразу же протестировать свои изменения. Это часть целей CI, не так ли?

Но также предположим, что в вашем цикле тестирования участвуют и другие люди, например. менеджеры или клиенты. Имеет смысл привлечь других людей к рассмотрению (отмене?) ваших предстоящих изменений, не так ли?

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

• you могут тратить свое время на сообщение о проблемах, которые к моменту сохранения (подробного) отчета они больше не могут даже воспроизвести проблему сами (например, потому что случайно вы также столкнулись с той же проблемой и уже исправили ее в своей среде).
• they возможно, не смогут воспроизвести проблемы, о которых они сообщили, поскольку среды, в которых они столкнулись с какой-либо проблемой, больше не идентичны (вы (!!!) могли наложить их среду).

Итак, что вы можете сделать (как что-то настроить?), чтобы избежать таких (неприятных) ситуаций?

#непрерывная интеграция #тестирование

Я поделюсь своим опытом по этому поводу, главным образом потому, что он показывает, почему некоторые ответы не всегда применимы.

Некоторый контекст для начала:

• У нас есть 7 сред для размещения примерно 80 приложений, большинство из которых зависят друг от друга через веб-службы или общие таблицы в db2-iSeries.
• Хорошо это или плохо, но iSeries является нашей эталонной системой баз данных.
• Этот последний пункт делает недействительной любую идею размещения приложения с его зависимостями в изолированной среде, поскольку создание AS400 для каждого из них будет стоить слишком дорого, и у нас все равно не будет оборудования для его запуска.

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

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

Основная идея состоит в том, чтобы разрешить обновления, когда это не повлияет на кого-либо; если тесты не запланированы, они должны вытекать из предыдущей среды (и мы стремимся удалить запланированные выпуски в 5 первых средах в среднесрочной перспективе, теперь у нас есть утвердили эту систему методов «по требованию»).
Короткая версия заключается в том, чтобы иметь систему «семафоров» вокруг приложений в среде, команда должна иметь возможность заблокировать свое целевое приложение с его зависимостями (и транзитивными зависимостями) на время ручных тестов.

Реализация этого семафора сильно зависит от вашей системы автоматизации, поэтому я не буду на этом распространяться.

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

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

повторно инициализируется для каждого выполнения теста. Это делает такой тест ненадежным. Аналогично, с точки зрения надежности, и с ручным тестированием, если хотите. ИМХО, вам не следует использовать такое тестирование. внутри pass result obtained is not accidental (due to false positives) will erode your testing's confidence level. False negatives are not credibility damaging, but they are also undesired because of the unnecessary "noise" they create.

цели вашей квалификации CI/CD, поскольку это фактически аннулирует ваш процесс квалификации (по крайней мере, в этой области). Утверждение, что программное обеспечение проходит тест X, без фактического выполнения теста X для каждой поставленной версии программного обеспечения или без уверенности в том, что Это нормально для выполнения такого тестирования снаружи

ваш процесс квалификации CI/CD. Но вы будете относиться к неудачному результату такого тестирования так же, как к ошибке, обнаруженной клиентом: вам нужно будет надежно воспроизвести проблему, чтобы иметь возможность разработать для нее исправление и подтвердить, что исправление работает. И вы не сможете этого сделать, если тестирование ненадежно.

Если вы планируете решить проблему, в идеале вам следует сначала разработать автоматизированный надежный тестовый пример для воспроизведения проблемы. Который вы будете использовать для разработки исправления и подтверждения его эффективности (результат теста должен перейти от FAIL к PASS). Вы можете (должны?) также поместить этот тестовый пример в свой процесс квалификации CI/CD, чтобы предотвратить повторение в будущем, если это необходимо, и повысить общий уровень качества выпуска программного обеспечения.

Обычный подход заключается в создании различных сред:

РАЗРАБОТКА — это то место, где команда разработчиков все портит. Здесь создаются все изменения настроек, развертывание новой версии и так далее. Здесь CI полностью интегрирован.

PREPROD/QA — это место, где команда QA/test/validation проводит тесты. Эта среда обычно зависает во время тестов. Интеграция CI с этой средой заключается только в предоставлении новой версии продукта, конфигураций и т.д.

ПРОИЗВОДСТВО - это надо объяснять :)?

Если вы используете CI/CD, это означает, что перед развертыванием (CD) проводятся некоторые автоматические тесты (CI). Если вы обнаруживаете множество проблем в своей тестовой среде, это означает, что они не обнаруживаются тестами, выполняемыми до развертывания; это указывает на недостаточное автоматизированное тестирование. Если у разработчиков возникают проблемы, связанные с появлением дефектов в тестовой среде, им необходимо улучшить свои наборы автоматизированных тестов, чтобы предотвратить это. Это также повысит качество и надежность в целом на всех этапах производства.

Другой вариант — иметь очень четко определенные серверы, на которых работают приложения, отдельно от остальной инфраструктуры, составляющей вашу среду. Т.е. Все механизмы управления средой или обеспечения ее работы размещаются на отдельных долгоживущих серверах. Затем вы подключаете новые недолговечные серверы на основе известного образа для тестирования приложения, и, если в базовый образ вносятся какие-либо изменения, вам необходимо применить эти изменения. повсюду для каждого нового компонента. Это означает тестирование изменений на фоне всего.

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