Postman Collection Runner

Collection Runner

여러 API 요청을 정해진 조건과 시나리오에 따라 한 번에 실행해 검증하는 도구

 

Collection Runner 실행

 

 

 

Functional
API 테스트를 어떻게 바라보고 있는지를 보여주는 구조

1. Run manually

Postman UI에서 직접 컬렉션을 실행하는 방식

 

사람의 판단과 해석이 필요한 단계에서 사용

신규 API 개발 직후 기능 검증

테스트 케이스나 Assertion 수정 후 즉시 확인

특정 버그 재현이 필요한 경우

요청/응답 구조를 분석하며 테스트해야 할 때

 

예를 들어,

응답 값이 맞긴 한데 이게 요구사항에 맞는지 애매할 때

에러 코드가 내려오는데, 이게 정상 에러인지 아닌지 판단해야 할 때

데이터 세팅을 바꿔가며 흐름을 확인해야 할 때

 

한계점

반복 실행에 부적합

실행 주체가 사람 → 누락 가능성

야간 테스트, 주기 테스트 불가

 

 

☑️ Run configuration

실행 조건과 설정

 

Iteration : 요청을 몇 번 반복 실행할지 결정

예를 들면,

회원 가입 API를 10개의 다른 계정으로 검증

주문 생성 API를 여러 상품 조합으로 테스트

경계값, 예외값을 데이터로 분리해 반복 검증

 

Delay : 각 요청 사이에 대기 시간 설정

서버 과부하 방지

비동기 처리 완료 대기

Rate Limit API 대응

실제 사용자 흐름과 유사하게 만들기

 

 

 

2. Schedule runs

Postman Cloud에서 컬렉션을 정해진 시간이나 주기에 자동으로 실행하는 기능

Schedule runs의 목적은 개발 검증이 아니라 운영 안정성 확인에 가깝다

 

예를 들면,

운영 환경 API 헬스 체크 (상태 정상 체크)

배포 이후 야간 회귀 테스트

외부 API 연동 상태 모니터링

장애를 빨리 감지하기 위한 정기 검증

 

한계점

사내망, VPN 내부 API 접근 불가

IP 제한이 있는 서버는 실행 실패 가능

복잡한 인증 구조에는 부적합

 

 

☑️ Schedule configuration

'자동 실행의 시간 규칙’ 정의

 

Schedule name : 예약 실행 이름 (구분하기 위한 식별자)

환경 + 목적 + 주기

예를 들면, payment-api-nightly

 

Run Frequency : 컬렉션을 얼마나 자주 실행할지를 결정하는 항목

너무 잦은 실행 → 불필요한 트래픽, 비용 증가

너무 드문 실행 → 장애 감지 지연

 

 

 

3. Automate runs via CLI

Postman 컬렉션을 CLI 환경에서 실행하는 방식

일반적으로 Newman(Postman CLI)을 사용하고 Jenkins, GitHub Actions 같은 CI 도구와 연동

 

PR(Pull Request) Merge 전에 API 테스트 자동 실행

배포 전에 테스트 실패 시 배포 차단

마이크로서비스 환경에서 서비스 간 API 검증

QA 자동화 체계를 구축한 조직

 

 

 

 

Performance
'여러 사용자가 동시에 API를 사용할 때의 상황'을 가정해 실행 조건을 설정

 

1. Load profile

부하를 어떤 패턴으로 줄 것인가

실제 서비스와 가까운 패턴 선택

 

Ramp-up (점진적 증가) → 사용자 수가 서서히 늘어나는 상황

Spike (급격한 증가) → 갑자기 트래픽이 폭증하는 상황

Steady (일정 유지) → 안정된 서비스 상태

 

 

2. Virtual users

동시에 API를 호출하는 가상의 사용자 수

Virtual users 100 → 사용자 100명 테스트다 (X) 같은 시점에 100개의 요청 흐름이 동시에 실행된다 (O)

 

로그인 API → 동시에 몇 명이 로그인할 수 있는가?

주문 생성 API → 같은 순간에 몇 건의 주문이 들어오는가?

검색 API → 피크 타임에 동시 검색 요청은 어느 정도인가?

 

 

3. Test duration

설정한 부하를 유지하는 시간

짧은 테스트 → 순간적인 처리 능력 확인

긴 테스트 → 메모리 누수, 누적 지연 확인

 

 

☑️ Data file

각 Virtual user가 사용할 요청 데이터 세트

CSV나 JSON 파일을 통해 요청 파라미터, 바디 값을 바꿔가며 실행한다

 

같은 데이터로만 성능 테스트를 하면

캐시 효과로 성능이 과대평가됨

실제 사용자 패턴과 괴리 발생

DB 부하가 현실적이지 않음

 

예를 들어,

사용자 ID를 다르게, 상품 ID를 다르게, 검색어를 다양하게

동시성 + 데이터 다양성이 합쳐져야 의미 있는 성능 테스트가 된다.

 

 

이 Load profile로, 이만큼의 Virtual users가
이 시간(Test duration) 동안 이런 데이터(Data file)로 요청을 보낸다

 

 

☑️ 그래프 해석

Requests / second (처리량)

서버가 초당 몇 개의 요청을 실제로 처리하고 있는지

 

Avg response time (평균 응답 시간)

사용자가 실제로 느끼는 응답 속도

 

Error rate

요청 실패 비율 (4xx / 5xx)

 

Virtual users

부하가 의도대로 들어갔는지 확인하는 기준선

 

 

Ramp-up

가상의 사용자 수(또는 요청량)를 시간에 따라 점진적으로 증가시키며

시스템이 부하를 어떻게 흡수하는지 확인하는 성능 테스트 방식

☑️ 목적

임계점 찾기, 성능 저하 패턴 파악, 현실적인 트래픽 재현

📊 테스트 조건

Virtual Users : 50명

Ramp-up : 9초

Test duration : 1분

Total requests sent(총 요청 수) : 1,819건

 

📈 결과 요약

Requests/second : 초당 약 27건 처리

Avg. response time : 평균 240ms

P90 / P95 : 대부분 요청이 300ms 이내

P99 : 일부 요청만 800ms대

Error rate : 0% (실패 없음)

→ 동시 사용자 50명 환경에서도 응답 시간은 안정적이며, 에러 없이 요청을 처리했다

 

Requests / second (처리량)

Ramp-up 이후 처리량이 안정 구간에 진입

처리량이 들쭉날쭉하지 않음

서버가 요청을 밀리지 않고 꾸준히 처리하고 있음

 

Avg response time (평균 응답 시간)

부하가 증가해도 서버가 여유 있게 대응

병목 지점이 아직 나타나지 않음

 

Error rate

모든 요청이 정상 처리됨

서버가 부하로 인해 오류를 내지 않음

기능 + 성능 모두 안정적

 

Virtual users

Ramp-up 구간에서 사용자 수 증가

이후 일정 수준 유지

테스트 종료 시 감소

 

Spike

짧은 시간 안에 사용자 수나 요청량을 급격히 증가시켜

시스템이 갑작스러운 트래픽 폭주를 어떻게 처리하는지 확인하는 성능 테스트 방식

☑️ 목적

갑작스러운 트래픽 폭주 대응 능력 확인, 시스템의 회복 능력 확인

📊 테스트 조건

Virtual Users : 100명

Test duration : 1분

Total requests sent(총 요청 수) : 578건

 

📈 결과 요약

Requests/second : 초당 약 9.42건 처리 (처리량 낮음)

Avg. response time : 평균 314ms

P90 : 611ms

P95 : 927ms

P99 : 1,668ms (극단적 지연 발생)

Error rate : 0% (실패 없음)

→ 에러는 없지만 응답 지연이 꽤 큰편

 

Requests / second (처리량)

순간적으로 요청량 급증, 곧바로 급락

서버가 요청을 받긴 했지만 동시에 처리하지 못하고 처리 큐가 쌓였을 가능성이 높음

 

Avg response time (평균 응답 시간)

Spike 직후 응답 시간 급상승, 이후 서서히 감소

갑작스런 부하에 즉각적인 지연 발생

 

Error rate

모든 요청이 정상 처리됨

서버가 부하로 인해 오류를 내지 않음

 

Virtual users

짧은 시간에 급격히 100 VU 근접

유지 구간 거의 없음, 빠르게 감소