Я работал над крупной системой финансовых транзакций для банка, который заботился о пенсиях и инвестициях. После 15 лет изменений функций стоимость ручного регрессионного тестирования поднялась до 200 тыс. Долл. За выпуск. (10 миллионов LOC, 10 миллионов долларов США в день). Эта система также взаимодействует с 19 другими системами вокруг компании, перемещая большое количество данных. Эта система была реализована на Java.
Однако мы наблюдаем, что чем больше «повторного использования» мы делаем, тем больше растут затраты на регрессионное тестирование. (Причина в том, что вам нужно «протестировать код, к которому вы прикасаетесь» - и повторно используемый / совместно используемый код влияет на множество мест при прикосновении к нему. Поэтому, несмотря на «СУХОЙ - НЕ ПОВТОРЯЙТЕСЯ» - т.е. не копируйте и не вставляйте код - мы наблюдаем финансовый стимул для копирования и вставки кода. Это должно снизить затраты на регрессионное тестирование, потому что мы не хотим изменять код, который можно было бы использовать совместно, потому что это вызовет большое влияние регрессионного теста.)
Мой вопрос: существует ли принцип разработки программного обеспечения, который описывает взаимосвязь между повторным использованием и затратами на регрессионное тестирование?
Причина, по которой я бы задал этот вопрос, состоит в том, что, возможно, есть ценовая выгода в разложении системы на более мелкие части, которые будут тестироваться.
Предположения:
«Регрессивный тест» означает «приемочный тест», т. Е. Другая группа тратит время на написание новых и повторное использование старых тестов для системы от имени бизнеса, включая настройки среды и данных.
Я знаю, что реакция коленного рефлекса на большие затраты на регрессионное тестирование - это «более автоматизированные тесты». Это хороший принцип. В этой среде есть несколько проблем.
(a) Автоматизированные тесты менее полезны через границы системы, если только эта система также не имеет высокого охвата автоматизированных тестов. (Сфера влияния вызов).
(б) С культурной точки зрения трудно получить импульс от времени программистов или капиталовложений на высокий охват автоматизированных тестов, когда ваша система уже большая и сложная.
(c) Стоимость обслуживания автоматических тестов скрыта в проекте, и поэтому они легко отбрасываются на уровне проекта.
(г) Это просто культурная реальность работы в банке.
(д) Я работаю, чтобы решить эту проблему по-другому (разложение).