연속적인 테스트는 배포를 관리할 때 더 나은 속도와 효율성을 지원하기 위해 소프트웨어 개발 수명 주기(SDLC)의 여러 단계에서 자동화된 피드백을 통합하는 프로세스입니다.

연속적인 테스트는 CI/CD(연속적인 통합/연속적인 배포) 프로세스의 효율성을 높이는 데 중요한 원동력이며, 코드 품질을 개선하고 비용이 많이 드는 병목 현상을 방지하며 DevOps 프로세스를 가속화하여 SDLC 일정에 속도를 더하는 데 중요한 역할을 합니다.

실용적인 DevOps 접근 방식을 개발하는 기본 원칙 중 하나는 신속한 소프트웨어 제공과 안정적인 사용자 경험 사이의 차이를 해소하는 것입니다. 그러나 소프트웨어의 각 개발 단계(예: 프로젝트 설계, 코딩, 테스트, 배포, 유지 보수)에서 수동으로 피드백을 받는 기존의 방식은 조직의 리소스를 불충분하고 비효율적으로 사용하는 결과를 가져와, 궁극적으로 통합 주기가 길어지고 제품 업데이트가 지연되었습니다.

연속적인 테스트는 수동 테스트 프로세스를 자동화하고 인적 오류를 최소화하는 동시에 SDLC 초기에 귀중한 피드백을 제공함으로써 DevOps 팀이 초기에 문제를 해결할 수 있게 지원하여 이러한 비효율성을 해결합니다.

연속적인 테스트는 생산의 모든 단계에서 사전 정의된 QA 스크립트를 로드하는 자동화된 툴을 사용해 이뤄집니다. 이러한 자동화된 스크립트를 사용하면 QA 테스트를 실행할 때 사람이 정기적으로 개입할 필요가 없으며, 소스 코드의 효율성을 순차적으로 검증하는 동시에, 이에 대한 피드백이 올바른 팀에 즉시 제공됩니다.

자동화된 테스트가 실패하면 해당 개발 단계에서 개발팀에 알림이 전송되므로 개발팀은 SDLC의 다른 단계에 있는 다른 팀에 영향을 미치기 전에 소스 코드를 조정할 수 있습니다. 자동화된 테스트가 검사를 통과하면 프로젝트가 SDLC의 다음 단계로 자동 전달되므로 조직은 생산성을 최대화하고 부서 간 조정을 개선하는 연속 가능한 제공 모델을 만들 수 있습니다.

에릭 미닉(Eric Minick)이 아래 동영상에서 이 주제에 대해 자세히 설명합니다.

DevOps 프로세스에 연속적인 테스트를 통합하면 성장하는 기업이 여러 가지 이점을 누릴 수 있습니다.

효율성 및 배포 품질 향상. 연속적인 테스트는 소프트웨어 개발 수명 주기(SDLC)의 각 단계에서 워크플로 간의 품질 보증 및 품질 상호 운용을 관리하는 자동화된 방법을 제공합니다. 사용자 및 단위 테스트 모듈에 연속적인 피드백 루프를 통합하면 코드가 배포되기 전에 코드의 호환성과 성능을 개선하는 데 필요한 실행 가능한 인사이트를 얻을 수 있습니다. 이러한 효율성은 여러 DevOps 팀 구성원 사이의 단절을 해결하고 소프트웨어 배포 일정을 가속화할 수 있도록 지원합니다.

분산 프로젝트를 위한 신속한 오류 발견 및 수정. 오늘날의 최신 개발 아키텍처는 다면적이고 다층적입니다. 연속적인 테스트를 통해 개발팀은 오류 발견 및 수정 일정을 대폭 개선하는 확장 가능하고 자동화된 테스트 솔루션을 통합하여 이러한 복잡성을 해소할 수 있습니다.

사용자 경험 개선. 고급 수준의 연속적인 테스트 방법을 사용하면 다양한 고유 사용 사례와 문제 해결 시나리오를 시뮬레이션하고 사용자가 어떻게 대응하는지 관찰할 수 있습니다. 개발자는 이러한 시뮬레이션을 통해 얻은 인사이트를 활용해 사용자 인터페이스의 비효율성을 조기에 제거하고 제품이 배포된 후에 원치 않는 돌발 상황이 생기지 않게 방지할 수 있습니다.

개발 관련 업무 중단으로 인한 비용 절감. 특히 서로 연결된 대규모 시스템에서는 애플리케이션의 모듈 하나만 오류가 발생하면 원치 않는 다운타임이 발생하여 생산성과 수익에 부정적인 영향을 줄 수 있습니다.

예를 들어, 클라우드 제공업체는 어느 한 곳에서 발생한 고장으로 인해 전체 지역이 마비되고 몇 시간 동안 중단이 지속되는 상황을 정기적으로 겪습니다. 이는 높은 서비스 가용성에 의존하는 조직에 특히 치명적일 수 있습니다. 세분화된 수준에서 연속적으로 테스트하면 다른 방식으로는 찾아낼 수 없는 대규모 소프트웨어 시스템 내의 오류를 식별하고 비즈니스 중단으로 인해 발생하는 비용을 방지할 수 있습니다.

연속 테스트에는 시스템 신뢰성, 보안, 운영 성능 및 사용성을 보장하는 다양한 테스트가 포함됩니다. 스펙트럼 테스트에는 다음이 포함됩니다.

• 초기 단계 테스트: 이 접근 방식은 소프트웨어 개발 수명 주기(SDLC) 초기에 소프트웨어 및 시스템 테스트를 우선적으로 수행하여 향후 중대한 디버깅 문제를 줄이거나 방지하는 데 도움을 줍니다.
  
  
• 후기 단계 테스트: 이 접근 방식은 SDLC가 끝날 무렵에 사용자 경험, 전반적인 성능, 고장 허용 오차 및 기능 향상에 초점을 두고 테스트를 실시합니다.
  
  
• 스모크 테스트: 수동 또는 자동으로 진행되는 이 테스트는 눈에 띄는 소프트웨어 결함에 대해 초기 선별 검사를 제공합니다. 스모크 테스트는 구조가 정교하지는 않지만, 소프트웨어의 중대한 오류를 제거하기 위한 빠르고 저렴한 솔루션입니다.
  
  
• 단위 테스트: 초기 개발 단계에서 성능 저하를 식별하기 위해 빌드 전반에 걸쳐 소규모 스트레스, 부하, 볼륨 또는 메모리 누수를 검사하는 데 적합한 테스트입니다.
  
  
• 통합 및 메시징 테스트: 소프트웨어 모듈이 서로 연동되어 작동할 때 오류가 있는지 확인합니다. 연속적인 테스트는 누락된 종속성을 가상화하므로 팀은 엔드 투 엔드 프로세스 및 시나리오가 종합적으로 얼마나 잘 수행되는지 테스트할 수 있습니다. 그런 다음 복합 코드를 컴파일하고 런타임에 실행하여 예상대로 수행되는지 테스트합니다.
  
  
• 성능 테스트: 애플리케이션 소프트웨어의 성능을 테스트하는 것만으로는 최종 프로덕션 환경의 하드웨어와 미들웨어를 고려하지 못할 수 있습니다. 솔루션의 전반적인 성능을 효과적으로 평가하려면 통합 시스템 테스트를 실시해야 합니다.
  
  
• 기능 테스트: 이 형태의 테스트는 사용자 환경이 기대치를 충족하는지, 소프트웨어 시스템 전반에서 기능 워크플로가 필요에 맞게 실행되는지를 확인합니다. 예를 들어, 공급망 소프트웨어는 배송 가능한 재고가 있을 때 트럭이 공장에 도착하도록 알림을 보낼 수 있어야 합니다. (반면 비기능 테스트는 원하는 고객 경험을 제공할 수 있는 소프트웨어의 준비 상태를 측정하기 위해 성능, 사용성, 안정성, 응답 시간, 부하 시간, 확장성 등에 중점을 둡니다.)
  
  
• 회귀 테스트: 이 테스트는 종속 소프트웨어에서 오류가 수정된 후 성능, 기능 또는 종속성에 변화가 없는지, 시스템이 이전과 똑같이 작동하는지 확인합니다.
  
  
• 사용자 승인 테스트: 애플리케이션 테스트 또는 최종 사용자 테스트라고도 하는 이 테스트는 의도된 사용자의 하위 집합이 실제 상황에서 애플리케이션을 테스트하는 경우입니다. 베타 테스트가 사용자 승인 테스트의 한 예입니다.

다음과 같은 특성은 IT 시스템 및 애플리케이션에 오류가 발생할 위험을 높입니다.

• 클라우드 컴퓨팅, IoT(사물인터넷), 소프트웨어 정의 네트워킹, 증강 현실(AR) 등과 같은 다양한 신기술이 점점 더 많이 통합되고 있습니다.
  
  
• 코어와 에지가 원활하게 상호 연결된 상태로 여러 지역에 분산되어 있는 경우가 점점 더 많아지고 있습니다. 스마트 시티, 자율주행 차량 및 스마트 유틸리티용 애플리케이션이 이러한 아키텍처의 수혜자입니다.

이러한 경우 한 장소 또는 한 회사에서 개발이 이루어지는 것이 아니기 때문에 연속적인 테스트를 실시하기가 어렵습니다. 원격 팀을 포함한 제삼자가 시스템의 요소 일부를 제공할 수 있습니다. 시스템이 애플리케이션 프로그래밍 인터페이스(API)와 통합될 수 있습니다. 각 개발팀이 기존 소프트웨어를 포함하여 서로 다른 IT 환경에서 운영됩니다. 연속적인 테스트를 위해 모든 팀의 물리적 환경을 재현하는 것이 불가능합니다.

다행히, 연속 테스트를 가상화하여 단일 인터페이스에서 전체 시스템을 가상으로 재현할 수 있는 테스트 환경을 만드는 방법이 있습니다. 가상화된 환경은 다른 IT 시스템 또는 오류를 수정하기 위해 변경된 시스템을 테스트용으로 쉽게 재구성할 수 있습니다.

DevOps 환경에서는 소프트웨어 개발 수명 주기(SDLC) 전반에 걸쳐 연속적인 테스트가 자동으로 수행되며, 애플리케이션에 통합된 모든 새 코드를 자동으로 검증하기 위해 연속적인 통합과 함께 작동합니다.

새 코드가 애플리케이션에 통합될 때마다 자동으로 실행되는 테스트 스크립트가 테스트 툴에 미리 로드되어 있습니다. 일반적으로 테스트는 통합 테스트로 시작하여 시스템 테스트, 회귀 테스트 및 사용자 승인 테스트 순서로 자동으로 이동합니다.

테스트는 각 애플리케이션 모듈에서 데이터 피드를 생성하고 피드를 분석하여 새로운 코드의 영향을 받는 모든 모듈이 예상대로 작동하는지 확인합니다. 테스트에 실패하면 코드가 개발팀으로 돌아가 수정을 거친 후 다시 통합되고 테스트 주기가 새로 시작됩니다.

애플리케이션 또는 프로젝트는 모든 테스트에 통과하면 SDLC의 다음 단계(일반적으로 연속적 배포)로 이동합니다.

이 주제에 대한 배경지식은 안드레아 크로퍼드(Andrea Crawford)가 제공하는 DevOps에 대한 설명을 참조하세요.

애플리케이션의 모듈, 커넥터(또는 API 및 컨테이너), 플랫폼, 인프라 및 요구 사항을 정의하는 시나리오 전반에서 일관성을 보장하려면 테스트 세트에 대한 연속적인 테스트 프레임워크가 필요합니다.

테스트 세트는 순차적일 수도 있고(예: 회귀 테스트가 단위 테스트를 따르는 경우) 동시적일 수도 있습니다(예: 모듈의 새로운 반복에는 해당 종속성에 대한 테스트가 포함되는 경우).

연속적인 테스트 프레임워크는 테스트를 일관되게 적용하고 자동화를 위한 방법을 준비할 수 있도록 랩퍼를 제공합니다. 개발자는 모듈에 대해 취하는 접근 방식이 관련 모듈에 적용되는 접근 방식과 다르지 않기를 바랍니다. 모듈이 발전하면 서로 관련된 소프트웨어에 대한 다양한 테스트도 함께 발전합니다.

프레임워크는 테스트를 위해 스크립트와 기능을 편리하게 수정할 수 있는 표준 방법을 제공합니다. 테스트의 불일치가 제거되면 자동화를 통해 이점을 누릴 수 있지만, 그렇지 않으면 오해의 소지가 있는 테스트 결과를 생성할 수 있습니다.