마이크로서비스를 위한 QA 테스트
저비용-고효율의 자동화된 Mock System을 만드는 팁
By Eddie Ying
본 포스트는 영문으로도 제공됩니다.
QA 테스트의 주요 목표는 소프트웨어 내 버그를 발견하여 성공적인 프로덕트 출시를 돕는 것입니다. 기능 테스트, 인터페이스 테스트, 성능 테스트 등 여러 종류의 테스트가 있지만 모든 테스트의 핵심은 하나, 바로 소프트웨어 품질 확보입니다. 테스트할 때는 모든 시나리오를 포괄할 수 있는 정확하고 연관성 있는 높은 품질의 데이터가 필요합니다. 이때 안정성과 동시에 데이터 생성 및 관리의 효율성을 고려한다면 실제 프로덕션 데이터보다는 테스트를 위해 만들어진 모의 데이터(Mock Data)를 사용해야 합니다. 여러가지 의존성(Dependency)과 다른 서비스와의 강한 결합도(Coupling)를 갖는 하이레벨 서비스의 경우에는 더욱 그러합니다. 하지만 이러한 상황은 마치 막다른 길을 향해 달려드는 것처럼 막막하게 느껴질 수도 있습니다.
금번 포스팅에서는 의존성이 높고 변경이 잦은 서비스에 대해 저비용-고효율의 모의 시스템을 만드는 방법에 대한 아이디어를 소개하고자 합니다.
마이크로서비스 환경 모형 만들기
오늘날 많은 기업들이 마이크로서비스 구조에 계약 테스트(Contract Test)를 도입하는데 이는 두 마이크로서비스가 합의된 계약 하에서 어떻게 상호작용 하는지 테스트 해보는 방식입니다. 먼저 주어진 계약 하에서 두 마이크로서비스를 각각 독립적으로 개발한 후 공동으로 디버깅하거나 또는 연동해봅니다. 이 과정에서 보통 서비스 모형을 만드는데, 제공자(Provider)와 소비자(Consumer)의 계약에 기반해 풍부한 데이터를 생산하고 이를 통해 코드의 모든 경우의 수를 커버하여 서비스 품질을 확보하기 위해서입니다.
이는 의존성이 낮은 로우레벨 서비스를 테스트할 때는 꽤나 쉽고 효율적인 테스트 방법입니다. 그러나 만일 하이레벨 서비스에 의존성을 지닌 10개 이상의 로우레벨 서비스가 존재하는 경우엔 어떻게 하는 것이 좋을까요? 이런 경우 10개 이상의 서비스에 대해 각각의 모형을 만들려면 엄청난 시간과 자원을 투자해야하고, 변경에 대응하는데도 엄청난 유지관리 비용이 들 것입니다. 결국 하이레벨 서비스를 위해 더욱 효과적인 테스트 방법이 필요합니다. 그 해결책 중 하나는 다른 인터페이스에 영향을 주지 않으면서 단일 서비스 인터페이스의 모형을 만드는 것입니다.
해답은 API 게이트웨이
API 게이트웨이는 리버스 프록시이며 모든 호출에 대한 단일 진입점입니다. API 게이트웨이를 통해 응답 및 호출을 포착하면 동적인 관리와 유연성 향상을 이루어 낼 수 있습니다.
이는 이론적으로는 그럴싸해 보이지만 실제 프로덕션 환경의 이미 성숙된 프레임워크에 도입하기에는 실용적이지 않습니다. 이미 테스트 및 검증된 기존 코드를 수정하는데 필요 이상으로 많은 비용과 리스크가 들기 때문입니다. 더 나은 해결책으로는 이 설계도의 구조에 작은 요소를 몇 개 더해보는 것입니다.
그림 3에서 보이듯 기존 테스트 설계에 장고(Django)와 같은 전담 게이트웨이를 더할 수 있습니다. API 게이트웨이가 라우팅되고 포워딩되는 요청 모두를 계속 처리할 수 있다면 요청과 응답을 도중에 가로채서 응답 값을 모의 데이터로 수정할 수 있습니다
모의 데이터 유형
생성 또는 수정을 고려할 만한 모의 데이터 유형은 다음과 같습니다.
● 완전 응답(Full Returns): 개발기간 동안 의존적 서비스를 위해 새로운 인터페이스가 필요합니다. 만일 인터페이스도 동시에 함께 개발되고 있다면 의존적 서비스의 전체 인터페이스 모형을 만드는 것이 좋은 선택일 수 있습니다.
● 인터페이스 이상 또는 응답 지연: 파괴시험(Destructive Testing) 및 인터페이스의 응답 지연 절차를 테스트할 때 사용할 수 있습니다.
● 인터페이스에 응답하는 여분의 필드값 추가: 의존적 인터페이스에 새로운 필드값을 추가할 때 사용됩니다.
● 인터페이스에서 응답하는 필드의 내용 수정: 요청받은 필드를 응답으로 내보낼 때 값을 수정하여 테스트 데이터 요건을 충족시킬 수 있습니다. 이런 부분 수정의 장점이 있다면, 인터페이스 전체의 모의 모형을 만드는 것과 비교할 때 모의 데이터를 매번 조정할 필요가 없다는 점입니다.
● 인터페이스의 응답에서 필드 삭제: 인터페이스의 특정 필드값을 검증하는 테스트에서 테스트 요건의 충족 여부를 빠르게 파악할 수 있습니다.
● 인터페이스 요청 바디 수정: 경우에 따라 테스트 요건의 충족을 위해 요청 바디의 내용을 동적으로 수정해야 할 수도 있습니다.
● 인터페이스 요청 헤더 수정: 요청 헤더를 동적으로 추가, 수정 또는 삭제합니다.
요청을 그룹으로 나누기
일반적인 기능 테스트와 자동화된 테스트가 동시에 수행되는 경우처럼, 여러 사용자가 동시에 테스트 서버에 여러 개의 요청을 보내는 경우도 존재할 수 있습니다. 어떤 요청의 모형을 만들지 결정하기 위해 요청 헤더에 사용자의 UID(User Identifier)를 활용하는 방식을 고려할 수 있습니다. 의존적 인터페이스를 호출하는 요청의 경우, 요청에 UID를 추가하여 UID를 기반으로 요청들을 그룹핑할 수 있습니다. 그리고 나서 요청된 URL, HTTP 메서드, 요청 파라미터, 바디 등을 사용하여 어떤 모의 인터페이스를 만들지 결정하며 됩니다.
마무리하며
본 포스팅을 통해 다양한 종류의 모의 시스템 도입 방법에 대한 여러가지 아이디어를 공유해보았습니다. 하이레벨 서비스 테스트 용 데이터를 만드는 시스템의 개발이 필요할 때, 여기에 공유된 아이디어들이 타임투마켓, 비용, 리스크 등과 같은 측면의 고려와 함께 시작점으로 활용되었으면 합니다.
쿠팡은 질문을 던지고, 규범에 도전하며, 열정이 넘치는 인재를 적극적으로 환영합니다. 지금 열려있는 다양한 직군의 포지션을 Coupang Careers에서 확인해 보세요!
