модульное тестирование установщика

Question

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

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

Answer 1

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

Разработчики могут создавать полный выпуск в своей частной среде разработки и тестировать любым способом, который они считают подходящим (я рекомендую использовать виртуальную машину со снимками). Как только разработчики довольны, они помещают свой код в репозиторий SCM. Механизм непрерывной интеграции (Hudson, CruiseControl и т. Д.) Контролирует хранилище и запускает интеграционную сборку. После завершения сборки интеграции результат готов к отправке в QA для тестирования. Если вы зависите от установщика, для сборки которого требуется специальное лицензионное программное обеспечение, то вместо покупки лицензионной копии для каждого разработчика просто получите лицензию на сервер CI и попросите разработчиков забрать сборки установщика с сервера CI после завершения сборки. .

Если вы хотите иметь больше процессов (содрогание), попросите разработчиков выделить ветку разработки, за которой следит CI-сервер, который производит сборки из ветки разработки. Только разработчики тестируют релизы из ветки разработки. Как только команда разработчиков довольна результатом, изменения из ветви разработки переносятся (объединяются) в основную ветку, которая также контролируется CI-сервером, чтобы выпустить релиз для QA.

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

Answer 2

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

http://www.joyofsetup.com/2010/02/08/introducing-lux-declarative-unit-testing-for-custom-actions/

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

Answer 3

Нужно ли Dev интегрироваться с установщиком?То есть есть ли вероятность, что новая версия установщика внесет необходимые изменения в dev?

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

Итак:

Определить, где лежит ответственность за интеграционный тест: если с Build Engineer, то выпустить их из QA.Если с Dev, то сначала отдайте Dev, а затем QA.