2010-06-14 5 views
1

개발자가 코드를 확인하는 최상의 프로세스는 무엇입니까? 설치 프로그램은 빌드 엔지니어가 만들고 QA로 릴리스하여 설치 프로그램을 테스트합니다.유닛 테스트 단위

Dev가 단위 테스트를하지 않고 설치 프로그램을 QA에 릴리스해야합니까? dev가 몇 가지 변경을하면 버그를보고하기 위해 QA까지 기다려야합니다. 설치 프로그램이 처음으로 유닛 테스트를 위해 dev에 제공하고 일단 사인을하면 QA에 릴리스해야합니다.

답변

1

개발자가 설치 프로그램과 통합해야합니까? 즉, 설치 프로그램의 새로운 릴리스가 dev에서 필요 변경을 할 가능성이 있습니까?

내 생각 엔 설치 프로그램과 코드간에 통합이 있으므로 통합 테스트가 필요합니다. Dev가 참여해야한다는 것이 합리적이라고 생각합니다.

그래서 : 통합 테스트에 대한 책임이 자리하고있는 곳

는 결정 : 빌드 엔지니어로, 다음 QA에에서 해제합니다. Dev와 함께라면 Dev에게 먼저주고 품질 보증을하십시오.

1

다음은 WiX 설치 프로그램의 사용자 지정 작업에 단위 테스트를 추가하는 새로운 프로젝트를 설명하는 블로그 항목에 대한 링크입니다. 이것은 매우 구체적인 구현이지만, 설치 프로그램에 단위 테스트를 추가 할 수있는 방법을 알려줍니다. 나는 당신이 당신의 설치 프로그램이 제품을 설치합니다 얼마나 많은 사람들의 함수해야 테스트 방법을 철저하게 말을 일반적인 지침으로

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

. 회사에서 내부 용 소프트웨어를 작성하고 있는데 예를 들어 10 대의 기계를 가지고 있다면 기본 작동이 테스트되었는지 확인해야합니다. 제품이 전세계에 출시되고 사용자가 수백 명이 될 것으로 예상되는 경우 프로세스의 가능한 모든 측면을 테스트하십시오. 이 시나리오의 설치 프로그램 버그는 큰 문제가됩니다.

+0

럭스에 관한 기사. Windows 설치 관리자를 쓸 때 그랬 으면 좋았을 텐데. –

+0

나는 Lux가 얼마나 자주 사용되는지 모르지만 wix 웹 사이트에 나타납니다. http://wix.sourceforge.net/manual-wix3/lux.htm. 사용자가 2011.10, http://www.mentby.com/Group/wix-users/lux-unit-test-does-not-call-my-ca.html에 대한 질문을 게시했습니다. 또한이 (지원되지 않는?) 코드에서 사용되는 샘플이있을 수 있습니다. http://scrumpeak.codeplex.com/wikipage?title=How%20to%20use%20ScrumPeak&referringTitle=Home. – AnneTheAgile

3

내가이 작업을 수행 한 시간은 빌드 엔지니어를 완전히 몰아내는 것이 었습니다. 필자는 빌드를 자동화하는 동일한 스크립트의 일부로 설치 프로그램을 빌드하는 것을 자동화했습니다. 빌드 엔지니어는 빌드를 자동화하고 작성 및 체크리스트를 준수해야합니다. 빌드 프로세스에 대한 체크리스트를 작성할 수 있다면 빌드 프로세스를 자동화 할 수 있습니다. 빌드 프로세스에 대한 체크리스트를 작성할 수 없으면 소프트웨어를 출시 할 수 없습니다.

개발자는 전체 개인 개발 환경에서의 릴리스 및 적합하다고 판단되는 테스트 (스냅 샷이있는 가상 컴퓨터 사용을 권장합니다). 개발자가 만족하면 코드를 SCM 저장소에 저장합니다. Continuous Integration 엔진 (Hudson, CruiseControl 등)은 저장소를 모니터링하고 통합 빌드를 시작합니다. 통합 빌드가 완료되면 테스트를 위해 QA로 보낼 준비가 된 것입니다. 빌드 할 때 특별한 라이센스 소프트웨어가 필요한 설치 프로그램을 사용하는 경우 각 개발자 용 라이센스 사본을 구입하는 대신 CI 서버에 대한 라이센스를 얻고 개발자가 빌드가 완료되면 CI 서버에서 설치 프로그램 빌드를 선택하게하십시오 .

더 많은 프로세스 (떨림)를 원한다면 개발자는 개발 분기에서 빌드를 생성하는 CI 서버가 모니터링하는 개발 분기에 커밋해야합니다. 개발자 만이 개발 지점에서 릴리스를 테스트합니다. 개발 팀이 결과에 만족하면 개발 지사의 변경 사항이 CI 서버가 모니터링하는 주 지점으로 승격 (병합)되어 QA 릴리스가 생성됩니다.

심지어 팀 개발 브랜치로 유입되는 (개인) 개발자 브랜치가있는 환경에서 작업했는데, 통합 브랜치로 유입되는 브랜치는 릴리스 브랜치로 유입되며 각 브랜치는 언제 출시 시점을 결정할 것인지를 결정합니다. 한 지점에서 다른 지점으로 변경 사항을 알립니다. 그것은 미친, IMHO 였지만 QA 직원은 QA 직원이 프로세스를 모니터링 할 수 있도록 영구 고용했습니다.