Стратегия регрессионного тестирования и развертывания

Question

Мне нужен совет по стратегии развертывания.Если команда разработчиков создает обширную среду, и ее используют многие (20-30) приложений, и компания хотела бы, чтобы обновления приложений по крайней мере каждые 30 дней, какова лучшая стратегия развертывания?

Причина, по которой я спрашиваюзаключается в том, что использование гибкого подхода к развертыванию изменений ежемесячно, если не изменяются 90% приложений, приводит к большим потерям (и риску).Под этим я подразумеваю, что фреймворк может меняться в течение месяца, как и некоторые приложения.Поскольку структура изменилась, все приложения должны быть проверены на предмет регрессии.Если, скажем, 10 приложений вообще не меняются в течение года, то эти 10 приложений проверяются регрессионным методом КАЖДЫЙ МЕСЯЦ, когда в них не было никаких изменений функций или исправлений.Их нужно было проверять просто потому, что бизнес выпускает обновления каждый месяц.

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

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

Эти приложения используют одну и ту же базу данных, что требует постоянной проверки.Я знаю о TDD и автоматических тестах, но в данный момент их нет.

Любой совет?

Answer 1

Идея фреймворка заключается в том, что он должен быть «медленно движущимся кодом».Вы не должны менять каркас так часто, как приложения, которые он поддерживает.Попробуйте установить фреймворк на более медленный цикл разработки: возможно, релиз не чаще, чем каждые три или шесть месяцев.

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

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

Answer 2

Я бы не назвал это гибким подходом, если у вас нет (юнит) тестового покрытия. Одним из ключевых принципов Agile является то, что у вас есть надежные модульные тесты, которые обеспечивают сеть безопасности для частого рефакторинга и разработки новых функций. В вашем сценарии много рисков. Развертывание от двадцати до тридцати приложений в месяц, когда 1) большинство из них не добавляет никакой новой коммерческой ценности своим пользователям; и 2) нет тестов на месте, которые не будут рассматриваться как хорошая идея в моей книге. И я твердо верю в Agile. Но вы не можете выбирать только те части, которые вам удобны.

Если бизнес-приложение не изменилось, я бы не выпустил его просто для компиляции в новом фреймворке. Представьте, что каждое приложение .NET необходимо переиздавать при каждом изменении фреймворка. Читая ваш вопрос, я задаюсь вопросом, движет ли общая база данных необходимостью для этого. Если ваша структура изолирует схему, и вы обнаружите, что вам нужно перестраивать приложения всякий раз, когда схема меняется, то вам сначала нужно решить эту проблему. Проверьте Рефакторинг баз данных , Скотт Амблер для некоторых советов.

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

Answer 3

Регрессионное тестирование - это образ жизни. Вам нужно будет регрессировать каждое приложение перед его выпуском. Однако, поскольку время и деньги обычно не бесконечны, вы должны сосредоточить свое тестирование на областях с наибольшим количеством изменений. Быстрый и грязный способ идентифицировать эти области - подсчитать строки кода, измененные в данной бизнес-сфере; скажем «бухгалтерский учет» или «управление пользователями». Сначала они должны пройти наибольшее количество испытаний вместе со всеми областями, которые вы определили как «критически важные».

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

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

Я считаю полезным разделить проект на 3 отдельных потока кода; Разработка, обеспечение качества и производство. Разработка открыта для всех изменений, QA заблокирован, а Production заблокирован кодом (ну, в любом случае, заблокирован). Если вы выпускаете в производство ежемесячно, вы, вероятно, захотите ветвить сборку QA из кода разработки по крайней мере за 1 месяц до выпуска. Затем вы проводите этот приемочный тестирование новых изменений и регрессионное тестирование всего, что можете. Вам, вероятно, придется завершить тестирование изменений примерно за неделю до релиза, чтобы приложение можно было запустить, и вы могли несколько раз запустить установку. Вы не сможете пройти регрессионное тестирование, поэтому подготовьте стратегию выпуска патчей для Production. Не забудьте также объединить эти патчи с потоками кода QA и Development.

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

Answer 4

Вот несколько советов, которые я могу придумать: 1. Разбейте фреймворк на независимые части, чтобы замена одной части требовала выполнения лишь небольшой части тестовых случаев 2. Использовать метод определения приоритетов в тестовом случае. Таким образом, вы перезапускаете только небольшую часть пулов тестов приложений, выбранных какой-либо стратегией. Дополнительная ветвь и ART имеют лучшую производительность, чем другие обычно. Им необходимо знать информацию о ветвлении покрытия каждого теста. 3. Обновляйте фреймворк реже. Если приложение не нуждается в изменении, это значит, что не стоит его менять. Так что я думаю, что для этих приложений нормально использовать старую версию фреймворка. Вы можете обновлять структуру для этих приложений, скажем, каждые 3 месяца.