• FUNDAMENTAL TESTING
  • Building a Sustainable Testing Culture
  • Software Quality
  • Shift Left
• FRAMEWORK & STRATEGY
  • Manual Exploratory Testing Framework
    • Equivalence Class Partitioning
    • Boundary Value Analysis
    • State Transition
    • Decision Table
    • Cause-Effect Graphing
    • Pairwise Testing
    • Sampling
    • Error Guessing Method
  • Manual Exploratory Testing Strategy
    • Understand the Application
  • Automated Testing Framework
  • Automated Testing Strategy
    • Pact
    • Gherkin
    • AI/ML
    • Testing Anti-Patterns
  • Continuous Testing
  • Data Testing Strategy
  • Performance Testing Strategy
    • Performance Testing Steps
  • References

FUNDAMENTAL TESTING

소프트웨어 엔지니어링에 있어서 테스트는 AI 시대에 더욱 중요한 가치가 되었다.

테스트는 시스템 품질에 대한 지속 가능한 신뢰를 구축하는 소프트웨어 엔지니어링 활동이다.

AI 로 인해 코드 작성 비용은 줄어들고, AI 가 작성한 코드 구조와 품질, 의도를 이해하기 위한 이해 부채(Comprehension Debt) 를 해결하는 비용과 작성한 코드가 올바르게 동작하는지 검증(Verification & Validation) 하는 비용이 훨씬 커졌다.

Verification(e.g Unit Test, Integration Test, Contract Test) 은 설계 명세서, 요구사항, 스펙대로 구현이 되었는지를 내부적으로 검증하는 활동이고, Validation(e.g Beta Test, A/B Test 등) 은 최종 사용자의 실제 요구와 기대치를 충족하는지 평가하는 활동이다.

과거에는 많은 조직이 프로덕션 코드의 품질에 집중했다면, 오늘날에는 어떤 테스트 전략과 검증 체계를 팀에 적용할 것인지, 그리고 이를 지속 가능하게 운영하기 위한 테스트 전략과 테스트 아키텍처(Test Strategy & Testing Architecture)를 구축하는 것이 훨씬 중요해지고 있다.

특히, 새롭게 추가한 코드나 버그 픽스등의 작업이 회귀(Regression) 를 일으키진 않는지, 하위 호환성을 보장하는지는 필수로 검증되어야 한다.

Building a Sustainable Testing Culture

테스트 문화를 만들고 정착시키는 것은 정말 어렵다.

특히 조직의 인력난, 업무 일정 등을 고려하고 이해하다보면 테스트가 가장 먼저 희생된다. 따라서 조직의 상황에 맞는 테스트 전략, 아키텍처를 먼저 만든 다음 문화를 발전 시키는 것도 방법이다. 즉, 시스템을 먼저 강제하고 문화를 발전 시키는 것이 때로는 특정 조직에 있어서 올바른 방법일 수 있다.

예를 들어, 회사에 QA 엔지니어가 있는 팀이라면 SonarQube 등을 통한 단위 테스트 커버리지를 60% 이상으로 맞춰야 한다는 등의 정책이 전사적으로 내려올 수 있다. 이는 각 팀의 상황을 고려하지 않고 내려오는 경우가 있다. 이렇게 시스템을 먼저 강제하게 되면 자연스럽게 따라올 수 밖에 없는 상황이 된다.

하지만 이러한 접근은 부작용도 존재한다. 조직의 상황과 성숙도를 고려하지 않고 시스템을 먼저 강제하는 방법은 저품질 테스트와 다양한 Test Smell 을 만들어낸다. 테스트 전략 없이 AI 로 테스트를 대량 생성하다 보면 Mock 남발, 지나친 fixture 의존, 리팩토링을 방해하는 테스트, 단순 커버리지 채우기용 테스트 등이 증가하게 된다.

또한 조직 성숙도보다 앞선 프로세스는 반발을 만든다. 예를 들어 주니어 개발자 중심이고 빠른 MVP 를 만들어내야 하는 단계인데 E2E Test, contract test 의무화 등 좋아 보이는 다양한 테스트 전략을 강제화 하면 결과적으로 개발 속도 급감, 테스트에 대한 반발감 등이 생겨 조직에 악영향을 끼치게 된다.

테스트 문화를 정착시키고 싶어도 설계 품질(Testability) 이 좋지 않아서 테스트를 작성하기 힘든 상황이 있을 수 있다. 예를 들어 테스트하기 어려운 설계(e.g God Service, Infra Coupling, Hidden Side Effect 등) 가 적용된 경우이다. 이런 경우엔 테스트 가능한 구조(Testability) 를 먼저 만드는 것이 필요할 수 있다.

결국 지속 가능한 테스트 문화는 단순히 테스트를 많이 작성한다고 만들어지는 것이 아니라, 테스트 가능한 구조(Testability)를 설계할 수 있는 엔지니어링 역량 위에서 형성된다고 생각한다. 그리고 이러한 역량은 소프트웨어 엔지니어링 고전들을 통해 깊게 학습할 수 있다.

Software Quality

소프트웨어 엔지니어는 좋은 품질의 서비스를 제공해야하는 책임이 있다. 그리고 좋은 기업일수록 소프트웨어 품질을 높이기 위한 다양한 제도적 장치(e.g Security Review, Cloud Operability Review, 자주 검증, 테스트 커버리지, 성능 테스트 등)를 마련해 놓는다.

고객은 더 신뢰할 수 있는 제품으로 빠르게 이동하기 때문에, 품질에 신경쓰지 않으면 한 순간에 경쟁 업체에게 트래픽을 빼앗길 수 있다. 즉, 소프트웨어 품질은 타협할 수 없는 기준이다. 때로는 품질보다 출시일정을 고려해야하는 상황이 있을 수 있으며 이 경우 기술 부채가 생기게된다.

소프트웨어 품질은 사용자 관점에서는 사용성, 디자인, 보안성, 빠른 응답 속도, 장애 없는 서비스로 요약할 수 있다. 기업 관점에서는 투자 수익률, 실시간 분석이 가능한 환경, 무중단 서비스, 확장 가능한 인프라, 데이터 보안, 법률 규정 준수 등이 있다.

이 모든 것이 오늘날 좋은 소프트웨어를 만드는 중요한 요소다.

Shift Left

시프트 레프트(shift left) 는 소프트웨어 개발 초기에 테스트를 수행하는 것이다. 따라서 CI/CD 프로세스에 의존할 수 밖에 없다.

• 기획자는 User Story 를 정하고, 스토리 킥오프(story kickoff) 또는 기획 리뷰(plan review)를 기획자, 개발자, 테스터와 함께 진행하며 기능을 자세히 검토 한다.
• 기획자는 UX 디자이너와 협의하여 애플리케이션 설계를 검증하고 개선한다.
• 개발자는 구현을 하기 전에 각 User Story 및 기획을 바탕으로 테스트 시나리오를 작성한다. 여기서 테스트 시나리오는 BDD Style 로 작성할 수 있다.
• 테스트 시나리오는 팀 리뷰를 통해서 적절한 도메인 용어가 반영 되었는지, RESTFul 을 준수하였는지, 누락된 테스트 케이스는 없는지 등을 같이 검토한다.
• 테스트 시나리오 리뷰가 끝나면 개발자는 Unit Test 를 작성하고 CI 에 통합한다. 또한 정적 코드 분석을 위한 도구를 CI 에 통합하여 지속적인 피드백을 받는다.
• UI 테스트는 클라이언트 개발자 또는 테스터가 작성한다. 개발자가 작성하는 경우 CI 에 통합해야 한다.
• 첫 번째 피드백은 커밋을 하기 전 개발자의 로컬 환경에서 실행되는 자동화된 테스트를 통해 받는다.
• 두 번째 피드백은 커밋 후 CI 에서 실행되는 자동화된 테스트에서 받는다.
• 세 번째 피드백은 Devbox 테스트 를 통해 받는다.

Devbox 테스트란 개발자가 기능 구현 후 자신의 PC에서 실행, 에뮬레이터/실차/IVI 장비 연결 후 동작 확인, API 호출 직접 테스트, 모바일 앱에서 버튼 클릭 흐름 확인 등을 의미한다. 즉, 개발자나 테스터가 직접 수행한다.

시프트 레프트 테스트는 빠른 피드백(fast feedback)을 받는 것이 핵심이다. 테스트를 초기 단계로 이동시킴으로써 기능의 작동을 검증하는 것 외에도 다양한 품질 측면에서 사용자 스토리를 충분히 탐색할 기회를 얻는다. 또한 여러번의 피드백을 통해 결함을 초기에 발견할 수 있다는 장점이 있다.

익스트림 프로그래밍(eXtreme Programming, XP) 은 시프트 레프트 테스트를 통합한 애자일 소프트웨어 개발 프레임워크다.

시프트 레프트는 소프트웨어 개발의 모든 단계에서 다양한 역할의 구성원이 품질 검사에 참여하기 때문에 '품질은 팀 전체의 책임이다'를 강조한다.

FRAMEWORK & STRATEGY

Manual Exploratory Testing Framework

수동 탐색적 테스트는 요구 사항 문서나 사용자 스토리에 없는 다양한 상황에서 애플리케이션의 작동을 탐색하는 활동이다. 이 테스트를 통해서 분석, 개발 단계에서 예상하지 못한 새로운 user flow 혹은 버그를 발견하기도 한다.

이 테스트는 담당자의 예리한 분석/관찰 능력을 필요로 하기도 한다.

수동 탐색적 테스트는 애플리케이션이 배포된 테스트 환경에서 수행된다. 다양한 실시간 시나리오를 시뮬레이션 하고 애플리케이션의 작동을 관찰하기 위해서 DB, Service, Background Process 등을 자유롭게 조작한다.

탐색적 테스트에서 발견된 새로운 user story 나 testcase 는 이후에 포함되는 것이 좋다.

Equivalence Class Partitioning

동등 클래스 분할(Equivalence Class Partitioning) 프레임워크는 동일한 출력 값을 얻거나 유사한 처리를 수행하는 입력을 파티션 클래스로 분할하고 각 파티션에서 하나의 샘플 입력만 선택하여 전체 기능을 테스트한다.

예를 들어 회원 가입시 나이를 입력받는 기능이 있다고 가정하자.

1. 0~120세 > 정상
2. 0세 미만 > 오류
3. 120세 초과 > 오류

이 입력값을 동등 클래스로 나눠서 각 클래스에 있는 특정 구간 값을 하나 뽑는 것이다. 즉, 100, -1, 121 를 뽑아 테스트 하면 된다.

동등 클래스 분할 프레임워크는 유닛 테스트에서도 유용하게 활용된다.

Boundary Value Analysis

경곗값 분석(Boundary Value Analysis)은 각 클래스의 경계 조건을 명시적으로 확인하며 동등 클래스 분할 방법을 확장한다. 동등 클래스 분할은 그룹을 나누는 것이고, 경계값 분석(Boundary Value Analysis)은 경계 근처를 집중적으로 테스트하는 것이다.

예를 들어 나이 조건이 0~120 이면, 경계값 분석은 -1, 0, 1, 119, 120, 121 과 같이 구분하여 테스트를 진행한다.

State Transition

상태 전환(State Transition) 프레임워크는 입력 기록을 기반으로 애플리케이션의 작동이 변경되는 상황에서 테스트 케이스를 도출하는 데 유용하다.

예를 들어 비밀번호 오류 횟수에 대한 정책이 "비밀번호 5회 실패 시 계정 잠금" 이라고 가정하자. 이 경우 상태 정의는 다음과 같이 할 수 있다.

• S0 : 정상
• S1 : 1회 실패
• S2 : 2회 실패
• S3 : 3회 실패
• S4 : 4회 실패
• S5 : 계정 잠김

상태 전이는 다음과 같다.

S0 --실패--> S1
S1 --실패--> S2
S2 --실패--> S3
S3 --실패--> S4
S4 --실패--> S5(잠김)
S0~S4 --성공--> S0

상태 전환 테스트를 위해서는 보통 '상태 목록(State)', '이벤트(Event)', '상태 전이 표(State Transition Table)' 을 만든다.

상태 목록:

Idle
Logged In
Locked
Expired

이벤트:

Login Success
Login Failure
Logout
Timeout

상태 전이 표:

차량 인증, 디지털 키, OAuth, 결제 같은 워크플로우 중심 시스템에서는 상태 전환 테스트가 중요하다.

Decision Table

결정 테이블(Decision Table)을 사용하면 가능한 모든 입력 조합과 예상 출력을 미리 표에 표시하기 때문에 테스트 시간을 절약할 수 있다.

예를 들어 로그인 기능의 경우에 결정 테이블을 아래와 같이 만들 수 있다.

Cause-Effect Graphing

인과관계 그래프(Cause Effect Graph) 는 "입력 조건(Cause)과 출력 결과(Effect)의 논리적 관계를 그래프로 표현하는 기법" 이다. 즉, 조건과 결과 관계 분석을 위한 프레임워크이다. 인과관계 그래프 프레임워크를 사용하면 기능을 한눈에 파악할 수 있어 분석 단계에서 특히 도움이 된다.

Pairwise Testing

페어와이즈 테스트(Pairwise Testing) 는 여러 개의 독립적인 변수를 처리하는데 도움이 되는 프레임워크이다. 여러 입력 조건이 있을 때, 모든 조합을 테스트하는 대신 "모든 조건 쌍(pair)이 최소 한 번 이상 등장하도록" 테스트 케이스를 만드는 기법이다. 즉, 조합 폭발(Combinatorial Explosion)을 감소 시키기 위한 프레임워크이다. 이를 All-Pairs Testing 이라고도 부른다.

예를 들어 로그인 기능이 다음 조건을 가진다고 가정해보자.

총 조합수는 3x3x3 = 27 개 이다. 변수가 많아질 수록 폭발적으로 증가한다. 따라서 모든 조합을 테스트하는 대신 모든 변수 쌍이 한 번 이상 나타다도록 테스트한다.

모든 변수 쌍

• (Browser, OS)
• (Browser, Language)
• (OS, Language)

페어와이즈를 적용하게 되면 아래 표처럼 모든 변수 쌍이 최소 한 번 이상 등장하게 된다.

페어와이즈 테스트는 반복쌍을 식별하고 제거하기 위한 변수가 너무 많은 경우에는 적용하기 어렵다.

Sampling

샘플링(Sampling) 프레임워크는 대규모 데이터셋을 테스트할 때 유용하다. 특히 페어와이즈 테스트를 적용하기 어려운 경우 유용하다. 샘플링은 일반적으로 무작위 샘플링 또는 기준별 샘플링 중 하나를 선택하여 테스트에 사용할 하위 집합을 추출한다. 즉, 전체 데이터셋에서 일부 데이터 추출하여 테스트를 수행하는 기법이다.

예를 들어 사용자 데이터가 1억건인 경우 모든 데이터를 검증하기엔 시간,비용,테스트 환경 부하 등의 문제가 발생한다. 샘플링 테스트가 적합한 경우는 로그 검사, 히스토리 검사 등이 있다.

무작위 샘플링외에 기준별 샘플링 방법도 있다. 이 경우는 데이터를 그룹으로 나눈 후 샘플링을 진행하는 것이다. 예를 들어 차종별(e.g Genesis, Kia, Hyundai)로 샘플링을 하는 경우가 있다.

Error Guessing Method

오류 추측(Error Guessing Method)은 통합 실패, 입력 유효성 검사 실패, 경계 케이스 문제와 같이 일반적으로 발생할 수 있는 실패를 과거의 경험과 기술에 관한 이해를 기반으로 예측하는 것을 말한다.

• 데이터 유효성 검사 실패, 기술 및 비즈니스 오류에 대해 명확하지 않은 HTTP 상태 코드를 반환하는 경우
• 도메인, 데이터 유형, 상태 등에 따라 경계 조건이 처리되지 않은 경우
• 페이지 전환, 데이터 새로 고침 중 UI 문제가 발생하는 경우
• 등등

Manual Exploratory Testing Strategy

Understand the Application

그림에서 바깥쪽은 애플리케이션의 세부 사항을 이해하기 위해 집중해야하는 영역이다.

User Personas

• 페르소나(persona)는 애플리케이션 특성에 영향을 미친다. 예를 들어 Connected Service 를 만드는 경우 다양한 운전자, 동승자 페르소나를 생각할 수 있다. SNS 의 경우에는 화려한 사용자 경험을 기대하는 청년층과, 명확하고 쉬운 경험을 원하는 중년층이 있을 것이다.
• 테스트는 최종 사용자의 관점에서 진행해야 한다.
• 따라서 애플리케이션이 대상으로 하는 페르소나를 알아야 하고, 페르소나가 애플리케이션을 이해하고 상호 작용하는 방식을 탐색해야 한다.

Domain

• SNS, Connected Service, Health 등과 같은 도메인 각각을 이해하기 위해서는 해당 도메인에 맞는 Workflow, Process, 전문 용어을 알아야 한다.

Business Priorities

• 비지니스 우선순위에 따라서 탐색해야 한다.

Infrastructure and configuration

• 애플리케이션 구성 요소가 어디에 배포되고 어떻게 구성되는지 아는 것은 새로운 관점에서의 탐색적 테스트를 진행하는 데 큰 도움이 된다.
• 예를 들어 Rate Limiting 구성을 통해 일정 기간 내 요청에 대한 임곗값을 제한하고 이를 초과했을때 애플리케이션이 어떻게 동작하는지 관찰한다.
• 즉, 인프라 구성에 관한 정보를 수집하면 테스트 케이스를 파악하는데 도움이 된다.

Application Architecture

• 애플리케이션 아키텍처를 파악하면 다양한 경로를 통해 탐색적 테스트를 진행할 수 있다.
• 예를 들어 이벤트 스트림을 포함한다면 비동기 통신을 기반으로 한 테스트 케이스를 파악하는 것이 중요하다.

Automated Testing Framework

자동화된 테스트(Automated Testing)는 애플리케이션의 테스트 실행 및 검증을 사람 대신 도구가 수행하는 것을 의미한다.

새로운 기능을 추가할 때마다 기존 기능과의 통합을 테스트하고 기존 기능에서 변경 사항으로 인한 문제가 없는지 회귀 테스트(regression testing) 를 수행하여 확인해야 한다. 만약, 이러한 수동 테스트가 1시간 걸린다고 가정했을때, 기능 추가별로 시간을 더 늘어나게된다.

품질이 뛰어난 제품을 제공하기 위해서는 수동 테스트와 자동화된 테스트 둘 다 필요하며, 중요한 것은 균형을 유지하는 것이다.

Test Pyramid

• 단위 테스트(Unit Testing) 는 TDD 와 궁합이 좋다. TDD 방식을 따르면 코드에 원하지 않은 로직이나 테스트하지 않은 로직이 생기는 경우를 피할 수 있다.
• 통합 테스트(Integration Testing) 는 UI, DB, Cache, File System 등 네트워크와 인프라 경계를 넘어 모든 통합이 제대로 작동하는지 테스트하는 것이다. 통합테스트는 긍정적 통합과 부정적 통합 흐름을 검증해야 한다.
• 계약 테스트(Contract Testing) 는 여러 팀이 서로 다른 서비스를 독립적으로 개발하고 있고 A 서비스 B 서비스에 의존하는 상황에서 B 서비스가 준비가 안된 상태이더라도 B 서비스가 준비될 때까지 합의된 표준 계약 기반의 스텁으로 작업을 하는 것이다. 계약 테스트는 팀간의 지속적 피드백을 제공하기 위해 작성된다. 반환되는 데이터가 정확한지 확인하는 것이 아닌 계약 구조 자체에 초점을 맞춘다. Pact 와 같은 도구를 사용할 수 있다.
• E2E 테스트(End-to-End Testing) 는 다운스트림 시스템을 포함한 도메인 흐름 전체를 검증한다. E2E 테스트의 목적은 모든 구성 요소가 적절하게 통합되었는지 테스트 한다.

Automated Testing Strategy

이상적인 자동화 테스트 전략은 Test Pyramid 이다. 각 테스트 전략별로 팀에 알맞은 도구를 선택하여 자동화한다.

Pact

Pact 는 자바에서 계약 테스트를 작성할 때 자주 사용되는 도구다. 계약 테스트의 완전 자동화를 지원한다. 특히 소비자 주도 계약 테스트(consumer-driven contract testing)에 활용된다.

Gherkin

Karate, Cucumber 와 같은 BDD Framework 를 사용하면, 특정 기능을 실제로 구현하기 전에 Testcase, API Spec 등을 정리하는데 도움이 된다.

Feature: User Login
  As a registered user
  I want to log into the system
  So that I can access my dashboard

  Scenario: Successful login with valid credentials
    Given the user is on the login page
    When the user enters a valid username and password
    Then the user should be redirected to their dashboard

AI/ML

AI/ML 기술을 활용해 테스트 작성, 테스트 유지 관리, 테스트 보고서 분석, 테스트 거버넌스와 같은 일상적 테스트 작업을 지원할 수 있다.

Tools

• 테스트 작성에는 Test.ai, Functionize, Appvance, Testim, TestCraft 와 같은 도구가 있다. ML-backed 레코더를 사용하면 모든 단계에서 수행되는 요소와 작업을 식별하고 백그라운드에서 테스트를 생성할 수 있다. ML-backed 레코더의 장점은 로케이터뿐만 아니라 구조적, 시각적 측면에서 요소를 식별한다.
• 테스트 유지 관리에는 self-healing 이라 불리는 자동 수정 기능을 지원하는 Test.ai 및 Functionize 를 활용할 수 있다.
• 테스트 보고서 분석시에는 ReportPortal 을 사용할 수 있다.
• 테스트 거버넌스에는 SeaLights 와 같은 도구를 사용할 수 있다.

Testing Anti-Patterns

UI 테스트, 서비스 테스트, 유닛 테스트보다 수동 테스트에 들어가는 시간과 비중이 많은 경우는 개선이 필요하다는 시그널이다.

Continuous Testing

지속적 테스트(Continuous Testing, CT)는 애플리케이션 변경 시 수동 테스트와 자동 테스트를 통해 품질을 검증하는 프로세스 이다. 그리고 이 과정에서 품질 저하가 발생한 경우 알림을 줄 수 있다. 예를 들어 기능 변경으로 인해 성능 저하가 발생한 경우 실패 결과를 팀에게 전송할 수 있다.

CT 를 수행하기 위해 지속적 통합(Continuous Integration, CI) 에 의존하게되며, CI 도입을 통해 지속적 전달(Continuous Delivery, CD) 을 수행할 수 있다.

CT 를 통해서 얻을 수 있는 이점은 '공통 품질 목표', '조기 결함 감지', '배포 가능 상태 유지' 등이 있다.

• 빌드/테스트 시점에 컴파일 및 마이크로 테스트 수준에서 피드백을 얻을 수 있다.
• 정적 분석을 Pipeline 에 넣어서 피드백을 얻을 수 있다.
• Smoke Test 와 Nightly Regression Test 를 CT 에 포함할 수 있다.

Data Testing Strategy

데이터는 애플리케이션에서 가장 중요한 요소다. 데이터 정합성이 올바르지 않으면 고객의 신뢰가 빠르게 무너질 수 있으며 매출과 기업 이미지에도 타격을 줄 수 있다.

데이터 테스트를 하기 위해서는 먼저 데이터의 흐름을 파악하기 위해서 시스템 아키텍처를 그려보는 것이 좋다. 데이터가 어떤 서비스를 넘나들고, 이벤트 스트림을 사용하는지, 어떤 데이터베이스와 캐시 시스템에 저장되는지, 시스템이 일정 시간 후 일관된 상태에 도달하는 Eventual Consistency 모델을 사용하고 있는지 등을 파악해야 한다.

데이터 테스트는 정말 중요하기 때문에 발생 가능성이 낮을지라도 생길 수 있는 결함을 광범위하게 고려하여 테스트 환경에서 인위적인 상황을 만들어서 확인하는 것이 중요하다.

예를들어 API 별 호출 결과에 따른 데이터를 미리 구성해놓고 호출 결과에 따른 데이터가 일치하는지 검증할 수 있다.

데이터 테스트 전략에는 수동 탐색적 테스트, 자동화된 기능 테스트, 성능 테스트, 보안 및 개인 정보 보호를 위한 테스트가 포함되어야 한다.

Performance Testing Strategy

성능은 쉽게 말하면 동시에 다수의 사용자에게 서비스가 제공할 수 있는 애플리케이션의 능력이다. 성능 테스트(Performance Testing) 를 위해서는 목표를 명확히 해야하고 사전 성능 검증을 해야 한다.

• 실제 운영 환경과 유사한 부하를 재현하기 위해 가상의 사용자(Virtual User, VU) 수를 설정하고, 실제 사용 패턴을 반영한 시나리오 기반으로 부하를 구성해야 한다.
• API 의 특성에 따라 트래픽 비중을 다르게 할 수 있다.

성능 테스트를 위해서는 예상 피크 타임 사용자 수, 네트워크 사용량, 일일 데이터 저장량, 데이터 보관 주기, API 사용 패턴 등 다양한 요소들을 고려해야 한다.

• Little's Law
• SLI, SLO
• Test Types

성능에 영향을 미치는 요소

• 아키텍처 설계
• 기술 스택 선택
• 코드 복잡도
• 데이터 베이스 선택 및 설계
• 네트워크 지연 시간
• 지리적 위치
• 인프라
• 서드파티

핵심 성과 지표(Key Performance Indicator, KPI)

• 응답시간
• 동시성, 처리량
• 가용성

Performance Testing Steps

목표 KPI 정의:

• 첫 번째 단계는 비지니스 요구 사항에 따라 KPI 를 정의하는 것이다. 가장 좋은 방법은 먼저 정성적으로 생각한 다음 숫자로 변환하는 것이다.
  • e.g 애플리케이션은 새로운 국가로 서비스를 확장할 수 있어야 한다.
  • e.g 애플리케이션은 경쟁사 X 보다 성능이 더 좋아야 한다.
  • e.g 애플리케이션의 새로운 버전은 이전 버전보다 성능이 더 좋아야 한다.
• 실제로 목표 KPI 는 데이터를 기반으로 도출해야 한다.
  • 새로운 애플리케이션을 개발하는 경우에는 경쟁사 데이터를 요청하거나 참고한다.
  • 기존 애플리케이션의 경우에는 데이터를 분석해야 한다.

테스트 케이스 정의:

• 두 번째 단계는 부하 패턴, 성능 테스트 유형을 활용해 테스트 케이스를 작성하는 것이다.
• 가용성, 처리량, 응답 시간 측정을 반드시 포함해야 한다.

성능 테스트 환경 준비:

• 실제와 유사한 테스트 환경을 구성하기 위해 고려해야할 사항은 다음과 같다.
  • 각 계층/구성 요소는 상용 환경과 유사한 방식으로 배포되어야 한다.
  • 시스테 구성(CPU 수, 메모리 용량, OS 버전 등), 시스템간 네트워크 대역폭이 상용 환경과 유사해야 한다.
  • 레이트 리미팅 같은 애플리케이션 구성은 완전히 동일해야 한다.

나머지 단계는 테스트 데이터 준비, APM 도구 통합, 도구를 활용한 성능 테스트 스크립트 작성 및 실행 이다.

References

• Full Stack Testing / Gayathri Mohan