6

자동 테스트는 실시간 프로젝트 상태를 반영해야합니다. 아이디어는 다음과 같습니다.자동 테스트를 빠르게 유지하는 방법은 무엇입니까?

  1. 리포지토리 자동화 빌드에 대한 커밋이 수행 된 후 가능한 빨리 수행됩니다.
  2. 빌드가 성공하면 자동 테스트가 시작됩니다. 반드시 빠르다.

변경 사항이 잘못되었는지 확인하는 가장 좋은 방법입니다.

처음에는 빌드를 빨리 만드는 것이 어려웠지만 100 초 정도 유지할 수있었습니다. 105 (!) 개의 프로젝트 (MSVS 2008 C#)의 솔루션입니다.

테스트가 그렇게 단순하지 않은 것처럼 보였습니다 (우리는 NUnit FW를 사용합니다). 단위 테스트는 큰 문제가 아닙니다. 우리를 죽이는 통합 테스트입니다. 그리고 그들이 더 느리다는 사실 (속도를 높이는 방법에 대한 아이디어는 많이 알려져 있습니다)이 아니라 환경이 훨씬 느리게 설정되어야한다는 사실 (atm ~ 1000 초)!

우리의 통합 테스트는 최신 변경 사항을 반영하기 위해 재배포해야하는 웹/윈 서비스 (지금까지 19 개)를 사용합니다. 여기에는 서비스 재시작 및 많은 HDD R/W 활동이 포함됩니다.

자동화 된 테스트 단계를 수행하기 위해 환경 및 작업 흐름을 구성/최적화 할 수있는 방법에 대한 경험을 공유 할 수 있습니까? "낮은 수준"의 병목 현상 및 해결 방법은 무엇입니까?

P. 책 및 광범위한 기사를 환영하지만 실제 작업 솔루션은 훨씬 더 높이 평가됩니다.

답변

5

테스트 처리량을 개선하기 위해 수행 할 수있는 최적화 전략에는 여러 가지가 있지만이 테스트의 목표가 무엇이며 빠른 속도가 필요한지 스스로에게 물어야합니다.

일부 테스트에는 시간이 걸립니다. 이것은 삶의 사실입니다. 통합 테스트는 일반적으로 시간이 걸리므로 일반적으로이를 수행 할 수 있도록 환경을 설정해야합니다. 환경을 설정하는 경우 가능한 한 최종 생산 환경에 가까운 환경을 원할 것입니다.

  1. 는 시험 또는 검사의 배치를 최적화 :

    당신은 두 가지 선택이있다.

  2. 자주 사용하지 마십시오.

필자의 경험에 따르면, 올바른 통합 환경을 가지고 버그를 찾아 최종 생산 환경을 적절히 대표하는 것이 좋습니다. 나는 보통 옵션 2 (1)를 선택합니다.

우리는 모든 것을 항상 테스트 할 것이지만, 현실적으로는 전략이 필요하다고 생각합니다.

(1) 단이 경우, 통합에서 발견 된 버그의 부하가있는 경우, 모든 것을 잊어 제외하고 내가 :-) 말했다

+0

통합 테스트에 너무 오래 걸리지는 않지만 상태를 유지하는 것이 주범입니다. 따라서 우리는 그 순간에 (1)을 시도합니다. – Dandikas

3

우리는 카테고리 (테스트에 지정할 수있는 속성)를 지원하는 .NET과 NUnit을 사용합니다. 그런 다음 장기 실행 테스트를 수행하고 NightlyCategory에 배치하여 야간 빌드 중에 만 실행되도록하고 빠르게 실행하려는 연속 빌드에서는 실행하지 않도록합니다.

+0

시간이 오래 걸리는 테스트를 실행하는 것을 피하는 데는 여러 가지 방법이 있습니다. 현재로서는 가능한 최적화를 수행하고 테스트를 지연하기 시작합니다. "내 변경 사항으로 인해 아무 것도하지 못했습니다."라는 답을 잃어 버리게됩니다. – Dandikas

+0

이것이 우리가하는 일입니다. 30 초 이상의 테스트 범주 (경험치)는 "NightBuildTest"범주에 속합니다. 기타는 항상 활동적입니다. –

0

Buildbot : http://buildbot.net/trac 지속적인 통합 (자동화 된 테스트)을 수행하는 경우 충분히 권장 할 수 없습니다. 빠른 구성으로 모든 단위 테스트는 커밋이있을 때마다 실행되며 더 긴 통합 테스트는 하루를 통해 주기적으로 실행됩니다 (마지막으로 확인한 시간은 3 번이지만 쉽게 변경할 수 있습니다).

+0

우리는 CC.net을 사용합니다. 그러나 buildbot을 살펴 보겠습니다. – Dandikas

1

Turbo-Charged Test Suites에 대한 프레젠테이션을 작성했습니다. 후반부는 Perl 개발자를 대상으로하지만 상반기는 유용 할 수 있습니다. 적절한 지 알고 싶으면 소프트웨어에 대해 충분히 알지 못합니다.

기본적으로 테스트 스위트에서 데이터베이스 사용을 가속화하고 단일 프로세스에서 테스트를 실행하여 라이브러리를 지속적으로 다시로드하지 않도록하는 기술을 다룹니다.

1
내가 테스트를 종료하는 몇 가지 높은 수준의 말단을 갖는 게 좋을 것

하고, 그 중 하나라도 실패하면 '고해상도'테스트를 실행하십시오. 전화로 기술 지원을하는

생각해

...

컴퓨터 작동합니까? 그렇다면 예. 아니요, 컴퓨터가 전혀 켜지지 않습니까? ...

내 단위 테스트의 경우 "컴퓨터가 작동합니까?"와 같은 몇 가지 빠른 테스트가 있습니다. 통과하면 나머지 스위트는 실행하지 않습니다. 이러한 테스트 중 하나라도 실패하면 해당 실패에 대한보다 높은 해상도의 뷰를 제공하는 관련 하위 수준 테스트를 실행합니다.

내 생각에 최상위 레벨 테스트를 실행하는 데는 0.5 초도 채 걸리지 않아야합니다.

이 접근법은 속도와 세부적인면에서 나에게 도움을줍니다.

+0

확실히 그 문제는 최상위 테스트가 테스트를 실패하게 만드는 몇 가지 조건을 놓친 경우입니다. "컴퓨터가 작동합니까?"- 마우스가 고장난 경우 - 테스트가 실패해야하지만 "컴퓨터가 작동합니다" – dbr

+0

동의합니다. 종단 간 테스트를 신중하게 선택하고 실행하십시오. 당신이자는 동안 모든 세부 테스트. 세부 테스트에서 엔드 투 엔드 테스트에서 발생하지 않는 버그가있는 경우 엔드 투 엔드 테스트를 개선 할 수있는 방법을 확인하십시오. 어딘가에서 시작해서 향상 시키십시오. – shapr

1

환경이 가 훨씬 느린 (기압 ~ 1000 초)인지를 설정해야한다는 사실!

글쎄, 적어도 집중해야 할 부분을 알고 있습니다 ... 그 시간이 어디에서 쓰 였는지 알고 있습니까?

분명히 모든 해결책은 여기에있는 특성에 달려 있습니다.

  1. 더 많은 기계를 사용 :

    나는 상황이 정렬에 사용 세 가지 솔루션을있다. 아마도 두 대의 컴퓨터에 서비스를 분할 할 수 있습니까? 셋업 시간을 1/2로 줄이겠 니?

  2. 더 빠른 기계를 사용하십니까? 필자가 알고있는 한 가지 상황에서, 하드웨어 (다중 CPU, 고속 RAID 스토리지, 더 많은 RAM, 작업)를 업그레이드하여 18 시간에서 1 시간으로 실행되는 통합 테스트를 줄였습니다. 물론 그것은 $ 10k 달러의 순서로 비용이 들지만 그만한 가치가있었습니다.

  3. 은 통합 테스트를 위해 메모리 데이터베이스를 사용합니다. 네, 실제 데이터베이스에 대한 테스트를 원할 것입니다. 그러나 빠른 피드백을 얻기 위해 메모리 버전에 대해 처음에는 테스트를 실행할 수 있습니다.

1

환경을 다시 설정하기 전에 환경의 고스트 이미지를 백업하고 이미지를 복원하는 것이 가장 좋은 해결책입니다. 이것은 지출되는 시간에 더 합리적인 것입니다.

관련 문제