테스트와의 지속적인 통합은 "배송 가능"코드를 항상 확인하는 데 유용합니다.

그러나 포괄적 인 테스트 모음을 유지하는 것은 실제로 어렵고 종종 빌드가 버그가 될 것 같은 느낌이 듭니다.

CI 파이프 라인 테스트에 대해 얼마나 많은 테스트를 확신해야합니까? 테스트가 충분한시기를 결정하기 위해 일종의 메트릭을 사용합니까?

일반적으로

지속적인 통합 파이프 라인을 확신 할 수있는 충분한 자동 테스트는 언제입니까?

자신감을 갖고 싶은 것에 대해 생각하면 대답이 분명해질 것입니다. 궁극적으로 1-1을 매핑합니다. 모든 테스트는 테스트하는 한 가지에 대해 확신합니다.

• 단위 테스트는 클래스 (또는 모듈)가 테스트 된 작업을 수행한다는 확신을줍니다.
• 통합 테스트는 여러 장치가 테스트 된 방식으로 함께 작동한다는 확신을줍니다.
• 엔드-투-엔드 테스트는 전체 애플리케이션이 테스트에 설명 된 방식으로 특정 작업을 수행한다는 확신을줍니다.

당신이 당신의 질문을 공식화 한 방식에서, 당신은 아마도 다음과 같은 큰 비즈니스 감각으로 생각하고있을 것입니다 :

내 앱이 X 할 수 있다고 확신하고 싶습니다 .

따라서 X를 시도하고 올바르게 수행되는지 확인하는 엔드 투 엔드 테스트를 작성하십시오.

더 구체적인

그것은 모두 매우 자기 참조 적이지만, 그것이 그 이유가되기 때문입니다. 단순히이 아닌 그것보다.

예를 들어, 요리 레시피를 작성하는 앱을 작성한다고 가정하십시오. 한 가지 특징은 여러 종류의 치즈를 다른 양으로 첨가하면 온도와 시간이 정확하여 모두 녹을 수 있다는 것입니다.

따라서 CheeseMeltCalculator100g Gouda와 200g Emmental 치즈를 제공 하는 단위 테스트를 작성한 다음 온도와 시간이 올바르게 나타나는지 확인할 수 있습니다. 즉 CheeseMeltCalculator, 100g Gouda 및 200g 치즈에서 효과가 있다고 확신 할 수 있습니다 . 이제 200g 대신 300g Gouda로이 테스트를 반복하면 다른 값에 대해 올바르게 작동한다고 확신 할 수 있습니다 . 당신에 대한 테스트를 추가 할 수 있습니다 0, -1그리고 int.MaxValue고다의 g 코드가 트립되지 않는다는 것을 확신 할 (또는 의도 한대로 올바르게 여행) 이상 입력.

CheeseMeltCalculator전체 식품 온도 및 시간 계산 프로세스에 올바르게 통합되었는지 확인하기 위해 통합 테스트를 작성할 수 있습니다 . 이것이 잘못되었지만 CheeseMeltCalculator위 의 테스트에 문제가 없다면 버그가 다른 계산기에 있거나 다른 계산기의 데이터가 결합되는 방식에 있다고 확신 할 수 있습니다.

마지막으로 전체 레시피를 작성하기위한 엔드-투-엔드 테스트를 작성할 수 있으며 확인하는 것 중 하나는 결과 온도와 시간입니다. 이전의 두 가지 수준의 테스트는 문제가되지 않았지만 그 결과가 잘못되면 해당 부품이 정확하고 온도 계산이 애플리케이션에 통합되는 방식에 대한 실수라는 것을 다시 확신 할 수 있습니다. 예를 들어, 사용자 입력이 올바르게 전송되지 않았을 수 있습니다.

그리고 마지막으로 그 시험의 모든 좋은 경우에, 당신은 "확신 할 수 는 치즈의 여러 가지 다른 종류의 다른 양을 추가하면 그들은 모두 녹아 있도록, 그것은 당신에게 정확한 온도와 시간을 제공합니다 "

긴 이야기 짧은

요점은 테스트가 "올바로 작동"할 수 없다는 것입니다. "X를하면 Y가 발생합니다"만 테스트 할 수 있습니다.

그러나 이것은 프로젝트의 기술 사양에 맞는 것입니다. " 몇 가지 다른 종류의 치즈를 다른 양으로 첨가하면 정확한 온도와 시간을 제공하여 모두 녹을 수 있습니다 "라는 문구 는 고객에게 완제품이 무엇을하는지 분명하게 기대할 수있을뿐만 아니라 자동화 된 테스트에.

추가 정보

사용자 Richard는이 정보를 편집에 추가했습니다.

Martin Fowler는 자신의 웹 사이트에서 가장 일반적인 전략에 대해 매우 훌륭한 요약을 제공합니다. https://martinfowler.com/articles/microservice-testing/

나는 이것을 제거하고 싶지 않지만 이것을 말하고 싶다 :이 답변과 비교하여, 그것은 "요약"이 아니라 멋진 그래픽과 모든 것을 가진 훨씬 더 자세한 설명입니다.

나의 충고는 : 나의 대답을 읽은 후에 모든 것이 당신에게 의미가 있다면, 당신은 끝났습니다. 그래도 문제가 명확하지 않으면 약간의 시간을내어 관련 기사를 읽어보십시오.

찾고자하는 신뢰를 줄 수있는 측정 항목이 없습니다. 자신감은 무언가를 한 다음에 성공하거나 실패하고 배우는 것으로 만들어집니다.

테스트 범위에 대한 확신을주는 유일한 "메트릭"은 다음과 같습니다.

1. 생산에서 발견 된 결함 수
2. 코드베이스를 리팩터링하고 테스트 범위에 의존하여 회귀 결함을 포착 할 수 있습니까?

자동화 된 테스트는 은색 총알이 아닙니다. 각 릴리스주기 동안 발견 된 생산 결함 수를 추적해야합니다. 이 숫자가 줄어들면 더 나은 소프트웨어를 제공하는 것입니다. 자동화 된 테스트 및 지속적인 통합은 더 나은 소프트웨어를 제공하기 위해 사용하는 도구 일뿐 입니다.

실제로 측정 할 수있는 유일한 지표는 "더 나은 소프트웨어를 제공하고 있습니까?"입니다.

그럼에도 불구하고 주관적입니다.

지속적인 통합 파이프 라인을 확신 할 수있는 충분한 자동 테스트는 언제입니까?

대부분의 경제 환경에서는 충분한 신뢰를 구현할 예산이 없지만 (> 99 %) 제한된 예산을 관리해야합니다. 비용 / 이익 비율에 관한 것입니다.

• 일부 자동화 된 테스트는 구현하기에 비용이 적게 들고 일부는 매우 비용이 많이 듭니다.
• 실제 위험 관리 에 따라 일부 위험은 테스트로 다루어야하지만 다른 위험은 피해야합니다.

따라서 실제로 쉬운 / 저렴한 / 위험한 테스트는 구현되지만 고가의 / 거의 그렇지 않은 테스트는 구현하지 않습니다.

소프트웨어 개발의 한 가지 목표는 자동 매트 테스트를 저렴하게 유지하기 위해 테스트하기 쉽고 저렴한 아키텍처 ( Test-driven_development 를 적용하여 테스트 가능성을위한 디자인 )를 만드는 것입니다.

Pareto_principle 은 여기에서도 유지 관리 가능 / 테스트 가능한 소프트웨어에 적용 할 수 있다고 가정합니다. 추가로 20 % 더 많은 돈을 쓰면 80 %의 추가 혜택을 얻을 수 있습니다. 나머지 20 % 더 많은 혜택을 받으려면 80 %의 추가 비용이 필요합니다.

잠재적 인 테스트되지 않은 소스 코드를 표시하기 위해 코드 적용 범위 및 돌연변이 적용 범위 와 같은 테스트 메트릭을 적용 할 수 있습니다 .

그러나 100 % 적용 범위에서도 코드에 버그가 없다고 확신 할 수는 없습니다.

경영진은 코드 메트릭을 좋아합니다. "코드 적용 범위> = 80 %"가 경영진에 의해 시행되는 반면 개발자가 자동화 된 테스트를 지원 / 좋아하지 않으면 높은 보안 범위를 가진 테스트 코드를 작성하여 잘못된 보안 느낌을주는 것은 없습니다.

여기서 다루는 요령은 완전한 적용 범위에 대해 걱정하는 것이 아니라 변경 위험을 관리하는 것입니다.

파이프 라인을 사용하여 이미 프로덕션 환경과 동일한 버전을 배포한다고 가정 해 봅시다. 회귀 오류의 위험은 무엇입니까? 0 (변경이 없으므로)

이제 화면 중 하나에서 텍스트를 변경하고 싶다고 가정 해 봅시다. 텍스트가 올바르게 표시되는지 확인하기 위해 테스트를 추가했습니다 (논쟁을 위해 그것이 정말로 중요한 텍스트 조각이라고 가정합시다). 회귀 오류가 없는지 확인하기 위해 어떤 다른 테스트가 필요합니까? 현실적으로 ...

따라서 각 릴리스가 작동하는 데 필요한 자동 테스트 수는 응용 프로그램 크기가 아니라 변경 크기에 따라 다릅니다. 작고 낮은 위험 변경을 수행하는 경우 위험을 완화하기 위해 훨씬 적은 테스트가 필요합니다.

하지만 잠깐만 기다려주세요 ... CI와 CD의 요점에 잘 맞지 않습니까?

네! 모든 변경 사항과 델타를 매우 작게 유지하면 테스트가 아닌 프로세스를 통해 많은 회귀 위험을 완화 할 수 있습니다. 더욱이 문제는 실제로 자동화의 하나가되지 않습니다 (단지 우리가 사용할 도구 일뿐입니다). 이는 단순히 테스트와 위험에 대한 식욕의 문제입니다. 자동화를 잊어 버리십시오. 변경으로 인해 문제가 발생하지 않았는지 확인하기 위해 변경에 대해 어떤 테스트를 실행 하시겠습니까? 이 질문에 대한 대답은 수동 테스트 프로세스에서 CI 시스템으로 변경되지 않습니다. 유일한 장점은 이러한 회귀 테스트 중 많은 부분이 이전 기능에서 이전에 개발되었을 수 있으며 CI를 통해보다 작고 안전한 변경을 수행 할 수 있다는 것입니다.

TLDR

테스트는 변경 위험을 완화하기위한 것입니다. 델타가 0 인 배포에는 위험이 없으므로 위험이 없습니다. 변경 사항을 작게 유지하면 검증에 필요한 테스트를 훨씬 쉽게 식별 할 수 있습니다. 자동화의 재사용 성은 보너스입니다.

제품을 수동으로 테스트 할 때와 같은 메트릭입니다.

실제로 이러한 낮은 신뢰도의 영역을 쉽게 식별 할 수 있습니다. 제품을 배송한다고 가정 할 때 배송 가능하다는 확신을 높이는 파이프 라인 후 수동 단계가 있다고 가정합니다. 자동 프로세스 자체에 대한 신뢰도를 높이기 위해 자동화해야하는 영역이 있습니다.

자동화는 지속적인 노력입니다. 제품이 향상됨에 따라 성장하고 향상됩니다. 결함은 CI 재검토와 함께 코드를 재고해야하는 이유입니다. 그리고 여기서 햇볕이 잘 드는 부분은 제품 자체에 대한 신뢰가 달성 될 수 있다는 것입니다. 자동화에 대한 신뢰도 달성 할 수 있습니다.