통합 테스트를 어떻게 확장합니까?

현재 제품에 대해 점점 더 많은 통합 테스트를 확장하여 (인간적으로) 개발 및 CI 프로세스의 일부로 유지 될 수 있는 기술과 전략을 조사하고 있습니다 .

약 200 개 이상의 통합 테스트에서 우리는 이미 전체 테스트 실행 (데스크톱 개발 시스템에서)을 완료하기 위해 1 시간 안에 도달했으며, 이는 개발자가 일상적인 푸시 프로세스의 일부로 전체 제품군 실행을 허용하는 개발자의 능력에 부정적인 영향을 미칩니다. 그것들을 잘 만드는 것에 대한 훈련을받는 동기에 영향을 미칩니다. 우리는 핵심 시나리오 만 앞뒤로 통합 테스트하고 각 테스트 실행에서 처음부터 빌드되는 프로덕션을 미러링하는 환경을 사용합니다.

실행하는 데 시간이 걸리기 때문에 테스트 실행이 아무리 집중되어 있더라도 끔찍한 피드백 루프와 테스트 실행을 마치기 위해 기계를 기다리는 많은 낭비되는주기가 있습니다. 흐름과 진행, 건강 및 지속 가능성에 더 비싼 부정적인 영향을주지 마십시오.

이 제품의 속도가 느려지기 전에 10 배나 더 많은 통합 테스트가 필요할 것으로 예상됩니다 (실제로 생각하지는 않지만 아직 기능 측면에서 시작된 것 같지는 않습니다). 우리는 수백 또는 수천 개의 통합 테스트를 기대할 수 있어야한다고 생각합니다.

분명히, 이것이 단위 테스트와 통합 테스트에 대한 논의가되는 것을 막으려 고 노력하십시오. 이 제품에서 TDD를 사용한 단위 테스트와 통합 테스트를 모두 수행하고 있습니다. 실제로, 우리는 아키텍처 의 패턴을 다른 영역으로 변경할 때 주요 변경 사항을 도입 해야 하는지를 검증 해야하므로 서비스 아키텍처의 다양한 계층에서 통합 테스트를 수행 합니다. 체계. 

우리의 기술 스택에 대해 조금. 우리는 현재 (CPU 및 메모리 집약적) 에뮬레이션 환경에서 테스트하여 엔드 투 엔드 테스트를 수행하고 있습니다. noSql 백엔드 (ATS)를 향한 Azure REST 웹 서비스로 구성됩니다. Azure 데스크톱 에뮬레이터 + IISExpress에서 실행하여 프로덕션 환경을 시뮬레이션하고 있습니다. 우리는 dev 머신 당 하나의 에뮬레이터와 하나의 로컬 백엔드 저장소로 제한됩니다.

또한 동일한 에뮬레이션 환경에서 동일한 테스트를 실행하는 클라우드 기반 CI도 있으며 현재 CI 공급 업체와 함께 클라우드에서 테스트 실행 시간이 2 배 이상 (2 시간 이상) 소요됩니다. 하드웨어 성능 측면에서 클라우드 CI 제공 업체 SLA의 한계에 도달했으며 테스트 런타임에 대한 허용치를 초과했습니다. 그들에게 공평하게 말하면, 그들의 사양은 나쁘지 않지만 사내 그런지 데스크톱 컴퓨터의 절반은 명확합니다.

각 논리 테스트 그룹에 대해 데이터 저장소를 재구성하고 테스트 데이터를 사전로드하는 테스트 전략을 사용하고 있습니다. 데이터 무결성을 포괄적으로 보장하면서 각 테스트에 5-15 %의 영향을줍니다. 따라서 우리는 제품 개발에서이 시점에서 테스트 전략을 최적화 할 수있는 방법이 거의 없다고 생각합니다. 

우리는 각 테스트의 처리량을 최적화 할 수 있지만 (각각 30 % -50 %까지도) 수백 번의 테스트로 가까운 미래에도 효과적으로 확장 할 수는 없습니다. 1 시간이 지나도 여전히 인간이 견딜 수있는 수준을 넘어서고 있기 때문에 전체 프로세스를 지속 가능하게하려면 상당한 규모의 개선이 필요합니다.

테스트 시간을 대폭 단축하기 위해 사용할 수있는 기술과 전략을 조사하고 있습니다.

• 적은 테스트를 작성하는 것은 옵션이 아닙니다. 이 글에서 그 내용에 대해 토론하지 마십시오.
• 더 빠른 하드웨어를 사용하는 것은 매우 비싸지 만 선택 사항입니다.
• 병렬로 별도의 하드웨어에서 테스트 / 시나리오 그룹을 실행하는 것도 확실히 선호되는 옵션입니다.
• 개발중인 기능 및 시나리오를 중심으로 테스트 그룹을 작성하는 것은 그럴듯하지만 궁극적으로 시스템이 변경의 영향을받지 않는다는 전체 범위 또는 확신을 제공하는 데 신뢰할 수는 없습니다. 
• 데스크톱 에뮬레이터에서 실행하는 대신 클라우드 규모의 준비 환경에서 실행하는 것이 기술적으로 가능하지만 테스트 실행에 배포 시간을 추가하기 시작합니다 (테스트 실행 시작시 각각 ~ 20 분).
• 시스템 구성 요소를 독립적 인 로지스틱 조각으로 나누는 것은 어느 정도 그럴듯하지만, 구성 요소 간의 상호 작용이 시간이 지남에 따라 증가 할 것으로 예상되므로 마일리지가 제한적입니다. (즉, 시스템이 점진적으로 개발 될 때 종종 발생하는 것처럼 변경이 예상치 못한 방식으로 다른 사람에게 영향을 줄 수 있음)

나는이 분야에서 다른 사람들이 어떤 전략을 사용하고 있는지보고 싶었습니다.

(다른 사람들이 특정 기술 세트를 사용하면 이런 종류의 어려움을 겪고 있다고 생각해야합니다.)

[업데이트 : 12/16/2016 : 결과에 대한 논의를 위해 CI 병렬 테스트에 더 많은 투자를하게되었습니다. http://www.mindkin.co.nz/blog/2015/12/16/16-jobs]

통합 테스트를 실행하는 데 5 시간 (30 대의 컴퓨터에서)이 소요되는 장소에서 근무했습니다. 코드베이스를 리팩토링하고 새로운 것을 대신하여 단위 테스트를 수행했습니다. 단위 테스트는 1 초에 30 초가 걸렸습니다. 아, 그리고 버그도 무너졌습니다. 그리고 세분화 된 테스트로 무엇이 깨 졌는지 정확히 알기 때문에 개발 시간 .

짧은 이야기, 당신은하지 않습니다. 코드베이스가 커짐에 따라 전체 통합 테스트는 기하 급수적으로 증가합니다 (코드가 많을수록 테스트가 많고 코드가 많을수록 "통합"이 많을수록 모든 테스트를 실행하는 데 시간이 더 걸립니다). 피드백 루프가 없기 때문에 "시간"범위의 모든 항목이 지속적인 통합의 이점을 대부분 상실한다고 주장합니다. 규모의 개선만으로도 충분하지 않아 확장 할 수있는 곳이 없습니다.

따라서 통합 테스트를 가장 광범위하고 가장 중요한 연기 테스트로 줄이는 것이 좋습니다. 그런 다음 야간 또는 연속이 아닌 간격으로 실행될 수 있으므로 성능에 대한 요구가 크게 줄어 듭니다. 더 많은 코드를 추가함에 따라 선형으로 만 증가하는 단위 테스트 (테스트 당 런타임은 그렇지 않음)는 확장을 향한 길입니다.

통합 테스트는 실제 사용자를 모방해야하므로 항상 오래 실행됩니다. 이런 이유로 당신은 그것들을 모두 동시에 실행해서는 안됩니다!

이미 클라우드에서 작업을 수행하고 있다고 가정하면 여러 컴퓨터에서 테스트를 확장 할 수있는 최고의 위치에있는 것 같습니다.

극단적 인 경우 테스트 당 하나의 새로운 환경을 가동하여 동시에 실행하십시오. 그러면 통합 테스트는 가장 오래 실행되는 테스트만큼 오래 걸립니다.

테스트를 줄이거 나 최적화하는 것이 나에게 가장 좋은 아이디어 인 것처럼 보이지만 옵션이 아닌 경우 제안 할 대안이 있습니다 (그러나 간단한 독점 도구를 작성해야 함).

나는 비슷한 문제에 직면했지만 통합 테스트에서는 그렇지 않았습니다 (분들은 몇 분 만에 실행되었습니다). 대신 그것은 단지 우리의 빌드에있었습니다 : 대규모 C 코드베이스는 빌드하는데 몇 시간이 걸렸습니다.

내가 매우 낭비하는 것은 소스 파일이 몇 개만 변경 되어도 처음부터 전체 (약 20,000 개의 소스 파일 / 컴파일 단위)를 다시 빌드 했기 때문에 몇 초 또는 몇 분이 걸리는 변경에 몇 시간을 소비한다는 사실이었습니다. 아무리 나빠도.

따라서 빌드 서버에서 증분 링크를 시도했지만 신뢰할 수 없었습니다. 때로는 잘못된 부정을 내고 일부 커밋을 빌드하지 못하면 전체 재구성에서 성공합니다. 더 나쁜 것은 개발자가 깨진 빌드를 메인 브랜치로 병합하는 것만으로 오탐 (false positive)을 제공하고 빌드 성공을보고하는 것입니다. 그래서 개발자가 개인 지점에서 변경 사항을 푸시 할 때마다 모든 것을 다시 작성했습니다.

나는 이것을 너무 싫어했다. 비디오 게임을하는 개발자의 절반과 함께 회의실에 들어갔습니다. 빌드를 기다리는 동안 할 일이 거의 없었기 때문입니다. 빌드를 기다리는 동안 코드 작업을 할 수 있도록 멀티 태스킹하고 새로운 브랜치를 시작하여 생산성을 높이려고 노력했지만 테스트 또는 빌드가 실패하면 해당 지점을지나 변경 사항을 대기열에 추가하기가 너무 어려워졌습니다. 모든 것을 고치고 다시 꿰매십시오.

대기 중 사이드 프로젝트, 나중에 통합

그래서 대신 내가 한 것은 응용 프로그램의 골격 프레임 워크를 만드는 것입니다. 동일한 종류의 기본 UI와 SDK의 관련 부분이 완전히 별도의 프로젝트로 개발 될 수 있도록했습니다. 그런 다음 주 프로젝트 외부의 빌드를 기다리는 동안 독립 코드를 작성합니다. 적어도 어느 정도 생산성을 유지할 수 있도록 코딩 작업을 한 다음 제품 외부에서 완료 한 작업을 나중에 프로젝트에 통합하기 시작했습니다. 사이드 코드 조각입니다. 개발자들이 스스로 기다리고있는 것을 발견하면 이것이 하나의 전략입니다.

재 구축 / 재실행 대상을 파악하기 위해 소스 파일을 수동으로 구문 분석

그러나 나는 우리가 항상 모든 것을 재건 하는 데 많은 시간을 낭비하고있는 것을 싫어 했습니다. 그래서 몇 주 동안 실제로 변경 사항이 있는지 파일을 스캔하고 관련 프로젝트 만 다시 작성하는 코드를 작성하는 데 코드를 작성했습니다. 여전히 전체 재 구축, 증분 링크는 없지만 재 구축해야하는 프로젝트 만 ( 재귀 적으로 구문 분석 된 종속 파일이 변경됨). 그것은 완전히 신뢰할 수 있었고 철저히 시연하고 테스트 한 후에 그 솔루션을 사용할 수있었습니다. 필요한 프로젝트 만 다시 빌드했기 때문에 평균 빌드 시간이 몇 시간에서 몇 분으로 단축되었습니다 (중앙 SDK 변경은 여전히 ​​1 시간이 걸리지 만 현지화 된 변경보다 훨씬 덜 자주 수행했습니다).

통합 테스트에도 동일한 전략을 적용해야합니다. 소스 파일을 재귀 적으로 구문 분석하여 통합 테스트가 의존하는 파일을 찾으십시오 (예 : importJava,#include서버 측의 C 또는 C ++) 및 해당 파일에서 포함 / 가져 오기 된 파일 등으로 시스템에 대한 전체 포함 / 가져 오기 종속성 파일 그래프를 작성합니다. DAG를 구성하는 빌드 구문 분석과 달리 그래프는 간접적으로 실행될 수있는 코드가 포함 된 변경된 파일에 관심이 있으므로 방향이 지정되지 않아야합니다. * 관심있는 통합 테스트에 대한 그래프에서 해당 파일이 변경된 경우에만 통합 테스트를 다시 실행하십시오. 수백만 줄의 코드조차도 1 분 안에이 구문 분석을 쉽게 수행 할 수있었습니다. 컨텐츠 파일과 같이 통합 테스트에 영향을 줄 수있는 소스 코드 이외의 파일이있는 경우 소스 파일의 주석에 메타 데이터를 작성하여 통합 테스트에서 해당 종속성을 표시하여 외부 파일이 변경되는 경우에도 테스트 할 수 있습니다. 다시 실행하십시오.

_{예를 들어, test.c에 foo.c에 포함 된 foo.h가 포함 된 경우 test.c, foo.h 또는 foo.c로 변경하면 통합 테스트를 새로 실행해야한다고 표시해야합니다.}

특히 공식 환경에서 프로그래밍하고 테스트하는 데 하루나 이틀이 걸릴 수 있지만 통합 테스트에서도 작동해야하며 다른 선택이 없다면 빌드 시간 범위를 기다리는 것이 좋습니다. 완료 (건물 또는 테스트 또는 포장 과정 또는 기타 이유로 인해). 이로 인해 몇 달 만에 잃어버린 많은 인력으로 인해 이러한 독점 솔루션을 구축하는 데 걸리는 시간이 줄어들고 팀의 에너지가 죽고 더 큰 합병으로 인한 갈등으로 인한 스트레스가 줄어 듭니다. 모든 시간의 결과로 종종 대기 낭비. 팀원들이 대기 시간을 많이 소비 할 때 전체적으로 좋지 않습니다.모든 작은 변화에 대해 재건 / 재실행 / 재 포장 될 모든 것.

통합 테스트가 너무 많은 것 같습니다. 테스트 피라미드를 기억하십시오 . 통합 테스트는 중간에 속합니다.

예를 들어 set(key,object), 방법을 사용하여 리포지토리를 가져옵니다 get(key). 이 저장소는 코드 기반에서 광범위하게 사용됩니다. 이 저장소에 의존하는 모든 메소드는 가짜 저장소로 테스트됩니다. 이제 두 세트의 통합 테스트, 하나는 설정 및 하나만 필요합니다.

이러한 통합 테스트 중 일부는 아마도 단위 테스트로 변환 될 수 있습니다. 예를 들어 내 관점에서 종단 간 테스트는 사이트가 올바른 연결 문자열과 올바른 도메인으로 올바르게 구성되었는지 테스트해야합니다.

통합 테스트는 ORM, 저장소 및 큐 추상화가 올바른지 테스트해야합니다. 일반적으로 통합 테스트에는 도메인 코드가 필요 없으며 추상화 만 필요합니다.

거의 모든 것은 의존성을 위해 스터 빙 / mocked / faked / in-mem 구현으로 유닛 테스트 할 수 있습니다.

지속적인 전달 파이프 라인이 일반적인 Agile 또는 DevOps 환경에서의 경험에서 각 모듈이 완료 또는 조정될 때 통합 테스트를 수행해야합니다. 예를 들어, 많은 지속적인 전달 파이프 라인 환경에서 개발자 당 하루에 여러 코드 배포를하는 것은 드문 일이 아닙니다. 배포 전에 각 개발 단계가 끝날 때 빠른 통합 테스트를 실행하는 것이 이러한 유형의 환경에서 표준 관행이어야합니다. 자세한 내용은이 주제에 관한 독서에 포함시킬 훌륭한 eBook은 Katrina Clokie가 작성한 DevOps의 테스트 실무 가이드 입니다.

이러한 방식으로 효율적으로 테스트하려면 전용 테스트 환경에서 기존의 완성 된 모듈 또는 스텁 및 드라이버에 대해 새 구성 요소를 테스트해야합니다. 필요에 따라 일반적으로 각 응용 프로그램 모듈에 대한 스텁 및 드라이버 라이브러리를 폴더 또는 라이브러리에 보관하여 빠른 반복 통합 테스트 사용을 가능하게하는 것이 좋습니다. 스텁 및 드라이버를 이와 같이 구성하면 반복적 인 변경을 쉽게 수행 할 수 있으며 지속적인 테스트 요구를 충족하도록 업데이트 및 최적의 성능을 유지합니다.

고려해야 할 또 다른 옵션은 원래 서비스 가상화라고하는 2002 년경에 개발 된 솔루션입니다. 이는 복잡한 엔터프라이즈 DevOps 또는 Agile 환경에서 테스트 목적으로 기존 리소스와의 모듈 상호 작용을 시뮬레이션하는 가상 환경을 만듭니다.

이 기사는 엔터프라이즈에서 통합 테스트 를 수행하는 방법에 대한 자세한 내용을 이해하는 데 유용 할 수 있습니다.

시간이 어디에서 걸리는지보기 위해 각 테스트를 측정 했습니까? 그런 다음 특히 느린 비트가있는 경우 코드베이스의 성능을 측정했습니다. 전체 문제가 테스트 또는 배포 중 하나입니까, 아니면 둘 다입니까?

일반적으로 통합 테스트의 영향을 줄이려면 비교적 사소한 변경에서 실행을 최소화해야합니다. 그런 다음 지점이 다음 레벨로 승격 될 때 수행하는 'QA'실행에 대한 전체 테스트를 남길 수 있습니다. 따라서 개발자 분기에 대한 단위 테스트가 있고 병합시 축소 통합 테스트를 실행하고 릴리스 후보 분기에 병합되면 전체 통합 테스트를 실행합니다.

따라서 모든 커밋마다 모든 것을 다시 빌드하고 다시 패키지하고 재배치 할 필요가 없습니다. 개발 환경에서 설정을 구성하여 가능한 한 저렴하게 배포를 수행 할 수 있습니다. 전체 VM을 가동하고 전체 제품을 배포하는 대신 VM을 이전 버전으로 그대로두고 새 바이너리를 제자리에 복사합니다 (예 : 수행해야 할 작업에 따라 YMMV).

이 전체적인 낙관적 접근법에는 여전히 완전한 테스트가 필요하지만, 소요 시간이 덜 긴급한 경우 나중 단계에서 수행 될 수 있습니다. (예 : 개발자가 아침에 해결할 수있는 문제가있는 경우 밤 동안 한 번 전체 테스트를 실행할 수 있습니다). 또한 다음 날 테스트를 위해 통합 장비에서 제품을 새로 고칠 수 있다는 이점이 있습니다. 개발자가 변경 사항을 적용하면 1 일만 만료 될 수 있습니다.

보안 기반 정적 분석 도구를 실행하는 데 비슷한 문제가있었습니다. 전체 실행에는 오랜 시간이 걸리므로 개발자 커밋에서 통합 커밋으로 실행을 이동했습니다 (예 : 개발자가 완료했다고 말한 시스템이 있고 성능을 포함하여 더 많은 테스트가 수행 된 '레벨 2'브랜치로 병합되었습니다) 테스트가 완료되면 배포를 위해 QA 지점으로 병합되었습니다. 야간에 수행 된 실행에서 지속적으로 발생하는 정규 실행을 제거하는 것이 아이디어입니다. 개발자는 아침에 결과를 얻을 수 있으며 개발에 영향을 미치지 않습니다. 개발주기 후반까지 초점을 맞 춥니 다).

고가의 하드웨어에서도 전체 통합 테스트 세트를 완료하는 데 몇 시간이 걸릴 수 있습니다. 옵션 중 하나는 모든 커밋에 대해 대부분의 테스트를 실행하지 않고 매일 밤 또는 연속 배치 모드 (여러 커밋 당 한 번)로 실행하는 것입니다.

그러나 이로 인해 새로운 문제가 발생합니다. 개발자는 즉각적인 피드백을받지 못하고 손상된 빌드는 눈에 띄지 않을 수 있습니다. 이 문제를 해결하려면 항상 무언가가 손상되었음을 알고 있어야합니다. Catlight 또는 TeamCity의 트레이 알림 기와 같은 빌드 알림 도구는 매우 유용 할 수 있습니다.

그러나 또 다른 문제가있을 것입니다. 개발자가 빌드가 손상되었음을 알게 되더라도 서둘러 확인하지 않을 수 있습니다. 결국, 누군가 다른 사람이 이미 확인했을 수도 있습니다.

따라서이 두 도구에는 "빌드 조사"기능이 있습니다. 개발 팀의 누군가가 실제로 깨진 빌드를 확인하고 수정하는지 알려줍니다. 개발자는 자원 봉사를 통해 빌드를 확인할 수 있으며, 그럴 때까지 팀의 모든 사람은 시계 근처에 빨간색 아이콘이 표시됩니다.

코드 기반이 커지는 것처럼 들리며 일부 코드 관리가 도움이 될 것입니다. 우리는 Java를 사용하므로 이것을 가정하면 미리 사과드립니다.

• 큰 프로젝트는 라이브러리로 컴파일되는 더 작은 개별 프로젝트로 세분화해야합니다. 넥서스와 같은 자바 도구는 이것을 쉽게 만듭니다.
• 모든 라이브러리는 인터페이스를 구현해야합니다. 이것은 높은 수준의 테스트에서 라이브러리를 제거하는 데 도움이됩니다. 라이브러리가 데이터베이스 또는 외부 데이터 저장소 (예 : 메인 프레임)에 액세스하는 경우 특히 유용합니다. 이러한 경우 메인 프레임 또는 데이터베이스 데이터를 반복 가능한 상태로 만드는 것이 느리고 불가능할 수 있습니다.
• 각 라이브러리에 대한 통합 테스트는 포괄적 일 수 있지만 새 라이브러리 소스가 커밋 된 경우에만 실행하면됩니다.
• 더 높은 수준의 통합 테스트는 라이브러리를 호출하고 완벽하다고 가정해야합니다.

내가 작업하는 Java 상점은이 접근 방식을 사용하며 통합 테스트가 실행되기를 기다리는 경우는 거의 없습니다.

실행 시간이 길거나 제한적이고 비싼 리소스가 필요한 CI 파이프 라인 통합 테스트 (또는 빌드를 포함한 모든 종류의 검증)를 유지하는 또 다른 방법은 커밋 후 검증 (이는 사전 커밋 확인을 기반으로 정체에 취약 합니다.

변경 사항을 지점에 직접 커밋하지 않고 중앙 집중식 자동 검증 시스템에 변경 사항을 제출하여 검증을 수행합니다.

• 성공하면 자동으로 브랜치에 변경 사항을 커밋합니다.
• 실패하면 각 제출자에게 변경 사항을 다시 평가하도록 알립니다.

이러한 접근 방식을 통해 제출 된 여러 변경 사항을 결합하고 테스트하여 유효 CI 확인 속도를 여러 번 높일 수 있습니다.

이러한 예로는 OpenStack에서 사용 하는 Gerrit / Zuul 기반 게이팅 시스템이 있습니다.

또 다른 하나는 ApartCI입니다 ( 면책 조항 -나는 그것을 만든 회사의 창시자이자 창립자입니다).