소프트웨어 테스트는 학술 활동이 아닙니다. • The Register

CChatGPT8
6 Min Read

[ad_1]

시스템 접근 방식 아마도 학문적 추구에서 오픈 소스 소프트웨어 개발로 초점을 옮긴 이후로 제가 인식하게 된 시스템 구축의 가장 큰 측면은 테스트 및 테스트 자동화의 중요성일 것입니다.

학계에서는 솔루션을 평가하기 위해 테스트 사례가 필요한 경우에만 학생들에게 테스트에 대해 가르치고, 대학원생에게 성능 벤치마크를 실행하여 연구 논문에 대한 정량적 데이터를 수집한다고 해도 과언이 아니지만 꽤 그렇습니다. 많이.

확실히 예외가 있습니다(예: 소프트웨어 엔지니어링 중심 커리큘럼). 그러나 내 경험에 따르면 학계에서 테스트에 부여되는 중요성은 실제로 중요성과 일치하지 않습니다.

나는 소프트웨어 테스팅의 역할을 높이 평가한다고 말했지만, 다른 사람에게 설명할 만큼 명확하고 깊이 있게 이해하고 있는지 확신할 수 없습니다. 시스템 접근 방식 사고방식의 특성과 마찬가지로 “이유”에 대해 더 잘 이해하고 싶지만 내가 보고 듣는 것은 대부분 단위 테스트, 스모크 테스트, 흡수 테스트, 회귀 테스트 등 많은 전문 용어입니다. 통합 테스트 등.

이 용어와 유사한 용어에 대한 문제는 그것이 규정적이라기보다 설명적이라는 것입니다. 확실히 통합 테스트(예를 들어)는 좋은 것이며 특정 테스트가 통합 테스트라고 합리적으로 주장할 수 있는 이유를 알 수 있지만 전체적인 계획에서 그것이 왜 필요하거나 충분한지 이해하지 못합니다. 것들. (해당 예가 너무 모호하다면 Reddit 사용자가 게시한 또 다른 예가 있습니다.)

예외는 코드 적용 범위가 정량화 가능한 측정 기준인 단위 테스트일 수 있지만, 그래도 내 경험에 따르면 품질 코드 생성에 대한 실제 기여보다 진행 상황을 측정하는 능력에 더 많은 가치가 부여됩니다.

그런 배경에서 나는 최근 Aether 프로젝트에서 지난 5년 동안 누적된 700개 이상의 QA 작업(상당한 월별 AWS 요금 발생)을 분류하려고 노력하고 있음을 발견했습니다.

저는 특정 기능이 특별히 중요하다고 생각하지 않습니다. Aether는 4개의 마이크로서비스 기반 하위 시스템으로 구성되어 있으며 각각은 엣지 클라우드에서 Kubernetes 워크로드로 배포됩니다. 자체 개발자 팀. 그러나 프로젝트는 공통 도구(예: Jenkins)를 공유하고 동일한 CI/CD 파이프라인에 공급되므로 여러 업스트림 소스를 통합하여 시스템을 구축하는 방식을 상당히 대표합니다.

내 “사례 연구”에서 분명한 것은 서로 다른 방향으로 향하는 경쟁 요구 사항과 관련하여 사소하지 않은 절충안이 있다는 것입니다. 하나는 기능 속도와 코드 품질 사이의 긴장이며 테스트 자동화가 중요한 역할을 하는 곳입니다. 즉, 엔지니어링 팀이 두 가지를 모두 제공할 수 있도록 지원하는 도구를 제공하는 것입니다.

Aether가 채택한 모범 사례는 소위 Shift Left 전략입니다. 즉, 개발 주기에서 가능한 한 빨리(즉, CI/CD 파이프라인의 “왼쪽” 끝 방향으로) 테스트를 도입합니다. 그러나 Shift Left는 테스트가 시간(테스트 실행을 기다리는 개발자)과 리소스(테스트를 실행하는 데 필요한 가상 및 물리적 시스템) 모두에서 비용이 들기 때문에 실제보다 이론적으로 더 쉽습니다.

실제로는 어떻게 되나요?

실제로 제가 본 것은 구성 요소 수준 기능 테스트를 수동으로 실행하는 개발자에 대한 의존도가 높다는 것입니다. 이는 대부분의 사람들이 테스트를 생각할 때(그리고 Reddit에 테스트에 대한 농담을 게시할 때) 생각하는 테스트입니다. 독립 QA 엔지니어는 개발자가 놓친 문제를 찾아 가치를 제공하지만 여전히 중요한 엣지 케이스를 예상하지 못합니다.

Aether의 경우 주요 기능 테스트 중 하나는 개발자가 3GPP 프로토콜 사양을 얼마나 잘 구현했는지 테스트합니다. 이 작업은 너무 복잡해서 일반적으로 타사 공급업체에서 테스트를 구매합니다. 자동화된 테스트의 경우 CI/CD 파이프라인은 패치를 코드 베이스에 병합하기 위한 관문으로 대부분 형식 테스트(예: 빌드 여부, 적절한 저작권 표시가 있는지, 개발자가 CLA에 서명했는지)를 수행합니다.

이는 병합 후 통합 테스트에 큰 부담을 줍니다. 여기서 핵심 문제는 충분한 “구성 적용 범위”를 보장하는 것입니다. 즉, 독립적으로 개발된 하위 시스템이 일관성 있는 전체로 배포되는 방식을 나타내는 방식으로 구성되었는지 검증하는 것입니다. . 단위 적용 범위는 간단합니다. 전체 시스템 적용 범위는 아닙니다.

나에게는 구성 관리와 테스트 효율성이 깊게 얽혀 있다는 인식이 핵심 통찰력입니다. (CI/CD 파이프라인 자동화가 중요한 이유이기도 합니다.)

이것을 좀 더 명확하게 만들기 위해 Aether의 구체적인 예를 사용하겠습니다(내 생각에는 독특하지 않습니다).

각각 무선 장치의 서로 다른 파티션(슬라이스)을 제공하는 여러 UPF(사용자 평면 기능)를 실행하는 기능과 같은 새로운 기능을 테스트하려면 (a) UPF를 구현하는 모바일 코어의 조합을 배포해야 합니다. , (b) 장치를 UPF 인스턴스에 바인딩하는 런타임 컨트롤러, 그리고 (c) 각 UPF를 통해 의미 있는 트래픽을 보내는 워크로드 생성기입니다.

세 가지 구성 요소 각각에는 통합 테스트가 엔드투엔드 결과를 생성하는 방식으로 정렬되어야 하는 자체 “구성 파일”이 함께 제공됩니다. Aether와 같이 느슨하게 결합된 클라우드 기반 시스템에서 통합은 조정된 구성과 동일합니다.

이제 도입되는 각각의 새로운 기능에 대해 이를 수행한다고 상상해 보세요. 고유한 구성 수가 폭발적으로 증가하거나 테스트할 조합과 테스트하지 않을 조합을 선택적으로 결정하여 적절한 기능 수렴을 얻는 방법을 알아냅니다.

이 작업을 수행하는 방법에 대한 좋은 대답은 없지만 내부 지식과 판단이 모두 필요하다는 것을 알고 있습니다. 또한 경험에 따르면 많은 버그는 사용을 통해서만 발견됩니다. 이는 출시 전 테스트와 출시 후 관찰 가능성이 밀접하게 관련되어 있음을 의미합니다. 릴리스 관리(단계적 배포 포함)를 테스트 전략의 또 다른 단계로 간주하는 것은 합리적이고 전체적인 접근 방식입니다.

시스템 렌즈를 통해 소프트웨어 테스팅을 이해하려고 처음 시작했던 곳으로 돌아가서 저는 개인적인 수용 기준을 충족하지 못했다고 생각합니다. 작업할 수 있는 몇 가지 디자인 원칙이 있지만 작업은 여전히 ​​예술과 엔지니어링이 동등한 것처럼 느껴집니다.

Aether QA 작업 세트에서 수행하려고 시작한 분류 작업에 관해서는 여전히 밀과 왕겨를 분리하는 데 어려움을 겪고 있습니다. 이는 구식 테스트를 비활성화하려는 명확한 계획 없이 진화하는 시스템의 자연스러운 결과입니다. 이는 여전히 진행 중인 작업이지만 한 가지 분명한 사실은 학생과 실무자 모두 소프트웨어 테스트에 대한 엄격한 기반을 갖추면 좋은 서비스를 받을 수 있다는 것입니다. ®

Share this Article
Leave a comment

답글 남기기

이메일 주소는 공개되지 않습니다. 필수 필드는 *로 표시됩니다