TIL - 20260705

juni·2026년 7월 5일

목록 보기

394/468

0705 백엔드 실무 심화 (12/N): 테스트 전략, QA와 배포 전 검증 기준

✅ 1. 테스트란 무엇인가?

테스트(Test)는 내가 만든 기능이 의도대로 동작하는지 확인하는 과정입니다.
백엔드 실무에서는 API가 정상 응답하는지, DB에 데이터가 정확히 저장되는지, 권한 검사가 되는지, 외부 API 실패 상황에서도 안전한지 확인해야 합니다.
테스트는 단순히 “에러가 안 나는지” 보는 것이 아니라, 운영에서 사고가 나지 않게 미리 검증하는 작업입니다.

기능 개발
  ↓
로컬 테스트
  ↓
API 테스트
  ↓
권한/예외 테스트
  ↓
배포 전 QA
  ↓
운영 반영

➕ 1-1. 테스트가 중요한 이유

장애 예방
- 배포 전에 오류를 발견할 수 있습니다.
데이터 정합성 보호
- 주문, 상담 신청, 상태 변경, 이력 저장이 꼬이지 않게 확인할 수 있습니다.
리팩토링 안정성 확보
- 코드를 고쳐도 기존 기능이 깨지지 않았는지 확인할 수 있습니다.
운영 신뢰도 향상
- 운영자가 쓰는 관리자 기능이 갑자기 안 되는 상황을 줄일 수 있습니다.
1인 개발자의 방어 장치
- 혼자 개발할수록 사람이 놓치는 부분이 많기 때문에 테스트 기준이 필요합니다.

✅ 2. 테스트와 QA의 차이

테스트와 QA는 비슷하게 쓰이지만 실무에서는 약간 다르게 볼 수 있습니다.

구분	의미	예시
테스트	기능이 기술적으로 맞게 동작하는지 확인	API 응답, DB 저장, 권한 검사
QA	사용자/운영자 관점에서 문제가 없는지 확인	화면 흐름, 버튼, 문구, 실제 업무 처리
검증	배포해도 되는 상태인지 종합 판단	체크리스트, 로그, 성능, 예외 확인

➕ 2-1. 실무 예시

상담 신청 기능 개발

테스트:
POST /api/consults 호출 시 DB에 저장되는지 확인

QA:
고객이 모바일에서 신청 모달을 열고 입력 후 완료 메시지를 볼 수 있는지 확인

배포 전 검증:
중복 신청, 알림톡 실패, 관리자 목록 노출, 유입코드 저장까지 확인

백엔드 테스트만 통과해도 화면에서 UX 문제가 생길 수 있습니다.
프론트 화면만 봐도 백엔드 권한/DB 정합성 문제가 숨어 있을 수 있습니다.
둘 다 봐야 합니다.

✅ 3. 테스트의 종류

➕ 3-1. 수동 테스트

개발자가 직접 브라우저, Postman, 관리자 페이지, DB를 확인하는 방식입니다.
초기 서비스나 1인 개발 환경에서는 수동 테스트 비중이 큽니다.

브라우저에서 신청
  ↓
Network 탭 확인
  ↓
DB 저장 확인
  ↓
관리자 페이지 노출 확인
  ↓
로그 확인

➕ 3-2. 자동 테스트

코드로 테스트 케이스를 작성해 반복 실행하는 방식입니다.
Jest, Supertest 같은 도구를 사용해 API 테스트를 자동화할 수 있습니다.

npm run test
  ↓
Service 테스트 실행
  ↓
Controller/API 테스트 실행
  ↓
성공/실패 결과 확인

자동 테스트는 처음 작성할 때 시간이 들지만, 기능이 늘어날수록 안정성을 크게 높여줍니다.

✅ 4. 테스트 피라미드

테스트는 보통 단위 테스트, 통합 테스트, E2E 테스트로 나눌 수 있습니다.

종류	설명	예시
단위 테스트	작은 함수/Service 단위 검증	상태 전이 함수, 마스킹 함수
통합 테스트	여러 계층이 함께 동작하는지 검증	Service + DB
E2E 테스트	실제 API 흐름 전체 검증	로그인 후 상담 신청 API 호출

➕ 4-1. 단위 테스트

검증 대상:
하나의 함수, 하나의 Service 메서드

예시:
canChangeStatus(PENDING, DONE) → true
canChangeStatus(DONE, PENDING) → false

빠르고 안정적입니다.
상태 전이, 권한 판단, 마스킹, 날짜 계산 같은 로직에 적합합니다.

➕ 4-2. 통합 테스트

검증 대상:
Service + Prisma + DB

예시:
상담 신청 생성 시 consult와 consultHistory가 함께 저장되는지 확인

실제 DB와 연결되기 때문에 단위 테스트보다 무겁습니다.
하지만 데이터 정합성 검증에 매우 중요합니다.

➕ 4-3. E2E 테스트

검증 대상:
HTTP 요청부터 응답까지 전체 흐름

예시:
POST /api/consults
  ↓
DB 저장
  ↓
응답 success=true

실제 사용 흐름과 가장 비슷합니다.
로그인, 권한, Guard, Pipe, Controller, Service가 함께 작동하는지 확인할 수 있습니다.

✅ 5. 1인 개발자 기준 현실적인 테스트 전략

처음부터 모든 테스트를 완벽하게 자동화하려고 하면 부담이 큽니다.
현실적으로는 “장애 나면 큰일 나는 핵심 기능”부터 테스트해야 합니다.

➕ 5-1. 우선순위가 높은 테스트 대상

1순위:
상담 신청
주문 생성
상태 변경
엑셀 다운로드
관리자 권한
외부 API 발송
Webhook 처리
결제/인증 관련 기능

2순위:
상품 목록
배너 목록
FAQ
공지사항
검색/필터링

3순위:
단순 UI 문구
정적 페이지
낮은 영향도의 부가 기능

모든 기능에 같은 수준의 테스트를 할 필요는 없습니다.
데이터 손실, 금전 영향, 개인정보, 운영 중단 가능성이 큰 기능부터 챙기는 것이 맞습니다.

✅ 6. 상담 신청 기능 테스트 기준

온라인 판매몰에서 상담 신청은 핵심 전환 데이터입니다.
신청 저장, 중복 방지, 유입 추적, 관리자 노출, 알림 발송까지 확인해야 합니다.

➕ 6-1. 정상 케이스

1. 이름, 전화번호, 상품명 입력
2. 상담 신청 API 호출
3. DB에 consult row 생성
4. status=PENDING 저장
5. source, visitorId, ipAddress 저장
6. consultHistory 생성
7. 관리자 페이지 목록에 노출
8. 신청 완료 응답 반환

➕ 6-2. 예외 케이스

전화번호 누락
잘못된 전화번호 형식
중복 전화번호
상품 정보 없음
유입 코드 없음
알림톡 API 실패
DB 저장 실패

➕ 6-3. 확인할 것

중복 신청이 막히는가?
DB unique 제약이 있는가?
알림톡 실패가 신청 저장 자체를 실패시키지 않는가?
관리자 페이지에서 신청 정보가 보이는가?
개인정보가 로그에 그대로 찍히지 않는가?

✅ 7. 관리자 권한 테스트 기준

관리자 기능은 반드시 권한 테스트가 필요합니다.
프론트에서 버튼을 숨기는 것만으로는 부족합니다.
API 직접 호출에도 권한이 막혀야 합니다.

➕ 7-1. 역할별 테스트 예시

기능	SUPER_ADMIN	ADMIN	MANAGER	VIEWER
상담 목록 조회	가능	가능	본인 담당만	가능
상담 상태 변경	가능	가능	본인 담당만	불가
엑셀 다운로드	가능	가능	제한	불가
상품 수정	가능	가능	불가	불가
관리자 생성	가능	불가	불가	불가

➕ 7-2. 테스트 케이스

VIEWER가 상담 상태 변경 API 호출
  ↓
403 Forbidden 반환

MANAGER가 타인 담당 상담 수정 요청
  ↓
403 Forbidden 반환

ADMIN이 엑셀 다운로드 요청
  ↓
ExportJob 생성

로그인 안 한 사용자가 관리자 API 호출
  ↓
401 Unauthorized 반환

401과 403을 정확히 구분해야 합니다.
인증 실패와 권한 부족이 섞이면 디버깅이 어려워집니다.

✅ 8. 상태 변경 테스트 기준

상태 변경은 데이터 정합성과 운영 이력에 직접 영향을 줍니다.
상태값 변경, 이력 저장, 권한, 날짜 필드를 함께 확인해야 합니다.

➕ 8-1. 정상 케이스

PENDING 상담
  ↓
MANAGER가 CALLING으로 변경
  ↓
consult.status = CALLING
  ↓
ConsultStatusHistory 생성
  ↓
fromStatus=PENDING
  ↓
toStatus=CALLING

➕ 8-2. 예외 케이스

DONE → PENDING 변경 시도
CANCELLED → CALLING 변경 시도
VIEWER가 상태 변경 시도
존재하지 않는 consultId
상태 변경 이력 저장 실패

➕ 8-3. 확인할 것

허용된 상태 전이만 가능한가?
상태 변경과 이력 저장이 트랜잭션으로 묶였는가?
완료 상태가 되면 completedAt이 저장되는가?
취소 상태가 되면 cancelledAt이 저장되는가?
변경한 관리자 ID가 이력에 남는가?

✅ 9. 외부 API 테스트 기준

외부 API는 실제 업체 서버에 의존하므로 성공 케이스만 보면 위험합니다.
timeout, 500 오류, 잘못된 요청, 인증키 오류, 중복 발송을 테스트해야 합니다.

➕ 9-1. 테스트해야 할 상황

외부 API 성공
외부 API timeout
외부 API 500 오류
외부 API 400 오류
외부 API 401 인증 오류
외부 API 응답 포맷 변경
중복 발송 방지
재시도 횟수 초과

➕ 9-2. Mock 사용

외부 API를 매번 실제 호출하면 비용과 속도 문제가 생깁니다.
테스트에서는 Mock Client를 만들어 성공/실패 응답을 가짜로 반환할 수 있습니다.

const mockSmsClient = {
  sendSms: jest.fn().mockResolvedValue({
    success: true,
    providerMessageId: 'msg_123',
  }),
};

외부 API Client를 별도 클래스로 분리해두면 Mock 테스트가 쉬워집니다.

✅ 10. Webhook 테스트 기준

Webhook은 외부 서비스가 우리 서버를 호출하는 구조입니다.
서명 검증, 중복 수신, 순서 뒤바뀜, 상태 전이 검증이 중요합니다.

➕ 10-1. 테스트 케이스

정상 서명 Webhook 수신
잘못된 서명 Webhook 수신
같은 eventId 중복 수신
존재하지 않는 orderId 수신
이미 취소된 주문에 결제 완료 이벤트 수신
결제 취소 이벤트가 결제 완료보다 먼저 도착
Webhook 처리 중 DB 오류 발생

➕ 10-2. 확인할 것

잘못된 서명은 401/403으로 막히는가?
eventId unique 제약으로 중복 처리가 되는가?
중복 이벤트에는 다시 상태 변경을 하지 않는가?
상태 변경과 이력 저장이 트랜잭션으로 처리되는가?
실패한 WebhookEvent가 관리자 확인 대상으로 남는가?

✅ 11. 엑셀 다운로드 테스트 기준

엑셀 다운로드는 개인정보와 대량 데이터가 함께 걸리는 기능입니다.
권한, 검색 조건, row 수, 파일 생성, S3 업로드, 다운로드 이력을 모두 확인해야 합니다.

➕ 11-1. 테스트 케이스

검색 조건 없는 다운로드
status/source/date 조건 포함 다운로드
VIEWER 다운로드 요청
MANAGER 본인 담당 데이터만 다운로드
10만 건 대용량 Export 요청
S3 업로드 실패
Presigned URL 만료
다운로드 이력 저장
개인정보 마스킹 적용

➕ 11-2. 확인할 것

목록에서 본 데이터와 엑셀 데이터 조건이 일치하는가?
권한 없는 사용자는 다운로드할 수 없는가?
개인정보 마스킹 기준이 적용되는가?
ExportJob 상태가 PENDING → PROCESSING → COMPLETED로 변경되는가?
실패 시 FAILED 상태와 errorMessage가 남는가?
파일이 public S3에 올라가지 않는가?

✅ 12. 배치 작업 테스트 기준

배치 작업은 사용자 요청 없이 자동 실행되므로 실패를 놓치기 쉽습니다.
실행 시간, 대상 날짜, 중복 실행, 재실행 가능성을 테스트해야 합니다.

➕ 12-1. 테스트 케이스

정해진 시간에 실행
Asia/Seoul 기준 전날 날짜 계산
같은 날짜 배치 재실행
동시 실행 시 Lock 동작
집계 결과 upsert
배치 실패 시 BatchJobLog FAILED 저장
실패 알림 발송
수동 재실행

➕ 12-2. 확인할 것

날짜 범위가 정확한가?
같은 배치를 두 번 실행해도 결과가 중복되지 않는가?
실행 이력이 남는가?
실패했을 때 운영자가 알 수 있는가?
무거운 작업이 API 서버 응답을 막지 않는가?

✅ 13. API 테스트 도구

➕ 13-1. Postman / Insomnia

API 요청을 직접 보내고 응답을 확인할 수 있습니다.
토큰, 헤더, Body, Query Parameter를 넣어 테스트하기 좋습니다.

테스트 대상:
로그인
상담 신청
관리자 상태 변경
엑셀 다운로드
Webhook 수신

➕ 13-2. Swagger

NestJS에서 Swagger를 붙이면 API 문서와 간단한 테스트를 같이 할 수 있습니다.
DTO, 응답 구조, 인증 여부를 문서화하는 데 도움이 됩니다.

➕ 13-3. curl

서버에서 빠르게 API 응답을 확인할 때 유용합니다.

curl -i https://api.example.com/health

curl -X POST https://api.example.com/api/consults \
  -H "Content-Type: application/json" \
  -d '{"name":"홍길동","phone":"01012345678","productName":"iPhone"}'

✅ 14. NestJS 자동 테스트 기본 구조

NestJS는 기본적으로 Jest 기반 테스트 구조를 제공합니다.
Service 단위 테스트와 E2E 테스트를 나눠서 작성할 수 있습니다.

➕ 14-1. 상태 전이 단위 테스트 예시

describe('canChangeStatus', () => {
  it('PENDING에서 DONE으로 변경할 수 있다', () => {
    expect(canChangeStatus('PENDING', 'DONE')).toBe(true);
  });

  it('DONE에서 PENDING으로 변경할 수 없다', () => {
    expect(canChangeStatus('DONE', 'PENDING')).toBe(false);
  });
});

이런 테스트는 빠르고 작성하기 쉽습니다.
상태 전이, 마스킹, 날짜 계산처럼 순수 함수에 적합합니다.

➕ 14-2. Service 테스트 예시

describe('ConsultService', () => {
  it('상담 신청 생성 시 consult와 history를 함께 저장한다', async () => {
    const result = await service.createConsult({
      name: '홍길동',
      phone: '01012345678',
      productName: 'iPhone',
    });

    expect(result.status).toBe('PENDING');

    const history = await prisma.consultStatusHistory.findFirst({
      where: {
        consultId: result.id,
      },
    });

    expect(history).toBeTruthy();
  });
});

실제 DB를 사용하는 테스트라면 테스트 DB를 분리해야 합니다.
운영 DB에 테스트를 절대 실행하면 안 됩니다.

✅ 15. 테스트 DB 관리

자동 테스트를 하려면 운영 DB와 분리된 테스트 DB가 필요합니다.

개발 DB:
local_dev

테스트 DB:
local_test

운영 DB:
prod

➕ 15-1. 테스트 DB 기준

운영 DB와 절대 분리한다.
테스트 실행 전 데이터를 초기화한다.
테스트용 seed 데이터를 만든다.
테스트 후 데이터를 정리한다.
.env.test를 별도로 사용한다.

DATABASE_URL=postgresql://user:password@localhost:5432/togethermall_test

테스트 환경변수와 운영 환경변수를 반드시 분리해야 합니다.
migrate reset 같은 명령어가 운영 DB를 향하면 치명적입니다.

✅ 16. 배포 전 QA 체크리스트

배포 전에는 기능별 체크리스트를 만들어 확인해야 합니다.
특히 1인 개발자는 머릿속으로만 확인하면 빠뜨리는 것이 많습니다.

➕ 16-1. 공통 체크리스트

1. 로컬에서 빌드 성공
2. TypeScript 에러 없음
3. ESLint 주요 오류 없음
4. Prisma migration 확인
5. 환경변수 추가 여부 확인
6. API 응답 구조 변경 확인
7. 기존 기능 회귀 테스트
8. 관리자 권한 테스트
9. 모바일 화면 확인
10. 로그에 민감정보 출력 여부 확인

➕ 16-2. DB 변경 체크리스트

1. migration 파일 확인
2. 운영에서 migrate deploy 사용
3. 컬럼 삭제/테이블 삭제 여부 확인
4. 기본값 없는 NOT NULL 컬럼 추가 여부 확인
5. 기존 데이터와 호환되는지 확인
6. 배포 전 RDS 스냅샷 필요 여부 판단
7. 롤백 가능 여부 확인

DB 변경은 배포 사고의 핵심 원인입니다.
특히 컬럼 삭제, unique 제약 추가, enum 변경은 신중해야 합니다.

✅ 17. 회귀 테스트

회귀 테스트(Regression Test)는 새 기능을 추가했을 때 기존 기능이 깨지지 않았는지 확인하는 테스트입니다.
실무에서 매우 중요합니다.

➕ 17-1. 예시

새 기능:
사전예약 신청 모달 추가

확인해야 할 기존 기능:
일반 상담 신청
상품 상세 페이지
관리자 상담 목록
엑셀 다운로드
유입 코드 저장
알림톡 발송

새 기능만 보면 안 됩니다.
같은 테이블, 같은 API, 같은 공통 컴포넌트를 사용하는 기존 기능도 확인해야 합니다.

✅ 18. 배포 후 확인

배포가 끝났다고 바로 끝이 아닙니다.
운영 배포 후 실제 서비스에서 정상 동작하는지 확인해야 합니다.

➕ 18-1. 배포 후 체크리스트

1. 사이트 접속 확인
2. API health check 확인
3. PM2 상태 확인
4. Nginx error.log 확인
5. 주요 API 200 응답 확인
6. 관리자 로그인 확인
7. 상담 신청 테스트
8. 관리자 목록 반영 확인
9. CloudWatch/Sentry 에러 확인
10. 외부 API 발송 실패 증가 여부 확인

➕ 18-2. 서버 확인 명령어 예시

pm2 list
pm2 logs api --lines 100
sudo tail -n 100 /var/log/nginx/error.log

배포 직후 10~30분 정도는 에러 로그를 확인하는 습관이 좋습니다.
배포 직후 장애는 빨리 발견할수록 피해가 작습니다.

✅ 19. 테스트 케이스 문서화

테스트한 내용을 문서로 남기면 나중에 배포 전 체크리스트로 재사용할 수 있습니다.
특히 반복되는 기능은 Notion이나 Markdown으로 정리해두는 것이 좋습니다.

➕ 19-1. 테스트 케이스 문서 예시

## 상담 신청 기능 테스트

### 정상 케이스
- [ ] 이름/전화번호/상품명 입력 시 신청 성공
- [ ] DB consult row 생성
- [ ] consultHistory 생성
- [ ] 관리자 목록 노출
- [ ] 신청 완료 메시지 표시

### 예외 케이스
- [ ] 전화번호 누락 시 400
- [ ] 중복 전화번호 신청 시 409
- [ ] 잘못된 상품 ID 요청 시 400 또는 404
- [ ] 알림톡 실패 시 신청은 유지되고 실패 이력 저장

### 권한/운영
- [ ] 관리자만 목록 조회 가능
- [ ] 개인정보 로그 미노출
- [ ] 유입 코드 저장

이런 문서는 경력기술서에도 좋습니다.
“기능 개발”보다 “배포 전 검증 체계와 운영 안정성 확보”가 더 실무적으로 보입니다.

✅ 20. 실무 체크리스트

➕ 20-1. 테스트 전략 체크리스트

핵심 기능부터 테스트 우선순위를 정했는가?
정상 케이스와 예외 케이스를 모두 확인하는가?
권한 테스트를 API 직접 호출 기준으로 하는가?
외부 API 실패 상황을 테스트하는가?
Webhook 중복 수신과 잘못된 서명을 테스트하는가?
상태 변경과 이력 저장을 함께 검증하는가?
배치 작업의 중복 실행과 재실행을 확인하는가?
테스트 DB와 운영 DB가 분리되어 있는가?

➕ 20-2. 배포 전 체크리스트

빌드가 성공하는가?
새 환경변수가 필요한가?
DB migration이 안전한가?
운영 데이터와 호환되는가?
기존 기능 회귀 테스트를 했는가?
관리자 권한과 개인정보 마스킹을 확인했는가?
외부 API/Queue/Batch 영향이 있는가?
배포 실패 시 롤백 기준이 있는가?

➕ 20-3. 배포 후 체크리스트

health check가 정상인가?
PM2 프로세스가 online인가?
Nginx error.log에 에러가 없는가?
주요 고객 화면이 정상인가?
관리자 주요 기능이 정상인가?
API 500 에러가 증가하지 않는가?
외부 API 실패가 증가하지 않는가?
배포 후 변경사항이 정상 반영되었는가?

✅ 21. AI를 활용해 테스트/QA 기준을 만들 때 질문법

AI에게 테스트를 요청할 때는 기능의 정상 흐름, 예외 케이스, 권한, DB 변경, 외부 API 여부를 같이 알려줘야 합니다.
단순히 “테스트 코드 짜줘”라고 하면 중요한 운영 케이스가 빠질 수 있습니다.

➕ 21-1. 좋은 질문 예시

NestJS + Prisma로 상담 신청 기능을 만들었고 배포 전 테스트 기준을 정리하고 싶어.

상황:
1. 고객은 이름, 전화번호, 상품명을 입력해 상담 신청함
2. 전화번호 기준 중복 신청을 막아야 함
3. 신청 저장 시 consultHistory도 함께 저장해야 함
4. 유입 코드, visitorId, ipAddress를 저장함
5. 신청 완료 알림톡은 Queue로 발송함
6. 알림톡 실패해도 상담 신청은 성공 처리되어야 함
7. 관리자 페이지에서 신청 목록을 조회함
8. MANAGER는 본인 담당 데이터만 볼 수 있음
9. 엑셀 다운로드에는 개인정보가 포함될 수 있음

요청:
- 정상 테스트 케이스
- 예외 테스트 케이스
- 권한 테스트 케이스
- DB 정합성 테스트
- Queue/외부 API 실패 테스트
- 배포 전 QA 체크리스트
- 배포 후 확인 체크리스트
를 실무 기준으로 정리해줘.

➕ 21-2. AI 답변 검증 기준

정상 케이스만 나열하지 않고 예외 케이스를 포함하는가?
권한 테스트를 프론트 버튼 숨김이 아니라 API 직접 호출 기준으로 보는가?
DB 저장과 이력 저장의 정합성을 확인하는가?
외부 API 실패가 핵심 기능을 망치지 않게 분리하는지 확인하는가?
테스트 DB와 운영 DB 분리를 언급하는가?
DB migration과 환경변수 변경을 배포 전 체크리스트에 포함하는가?
배포 후 로그/헬스체크 확인을 포함하는가?
회귀 테스트 개념을 포함하는가?

📌 요약

테스트는 기능이 의도대로 동작하는지 확인하는 과정이고, QA는 실제 사용자/운영자 관점에서 문제가 없는지 검증하는 과정입니다.
1인 개발자는 모든 테스트를 완벽히 자동화하기보다 상담 신청, 주문, 상태 변경, 권한, 외부 API, Webhook, 엑셀 다운로드 같은 핵심 기능부터 우선 테스트해야 합니다.
테스트는 정상 케이스뿐 아니라 중복 요청, 권한 없음, 외부 API 실패, DB 저장 실패, 잘못된 상태 변경 같은 예외 케이스가 중요합니다.
관리자 권한 테스트는 프론트엔드 버튼 숨김이 아니라 API 직접 호출 기준으로 401/403이 정확히 동작하는지 확인해야 합니다.
상태 변경 기능은 상태값 변경, 변경 이력 저장, 권한 검증, 날짜 필드 업데이트가 트랜잭션으로 안전하게 처리되는지 확인해야 합니다.
외부 API와 Webhook은 timeout, 재시도, 중복 수신, 잘못된 서명, 상태 전이 오류를 테스트해야 합니다.
배포 전에는 빌드, 환경변수, DB migration, 회귀 테스트, 권한, 개인정보 로그 노출 여부를 확인해야 합니다.
배포 후에는 health check, PM2, Nginx logs, 주요 API, 관리자 기능, 외부 API 실패 증가 여부를 반드시 확인해야 합니다.

juni

이전 포스트

TIL - 20260704

다음 포스트

TIL - 20260705

TIL

0705 백엔드 실무 심화 (12/N): 테스트 전략, QA와 배포 전 검증 기준

✅ 1. 테스트란 무엇인가?

➕ 1-1. 테스트가 중요한 이유

✅ 2. 테스트와 QA의 차이

➕ 2-1. 실무 예시

✅ 3. 테스트의 종류

➕ 3-1. 수동 테스트

➕ 3-2. 자동 테스트

✅ 4. 테스트 피라미드

➕ 4-1. 단위 테스트

➕ 4-2. 통합 테스트

➕ 4-3. E2E 테스트

✅ 5. 1인 개발자 기준 현실적인 테스트 전략

➕ 5-1. 우선순위가 높은 테스트 대상

✅ 6. 상담 신청 기능 테스트 기준

➕ 6-1. 정상 케이스

➕ 6-2. 예외 케이스

➕ 6-3. 확인할 것

✅ 7. 관리자 권한 테스트 기준

➕ 7-1. 역할별 테스트 예시

➕ 7-2. 테스트 케이스

✅ 8. 상태 변경 테스트 기준

➕ 8-1. 정상 케이스

➕ 8-2. 예외 케이스

➕ 8-3. 확인할 것

✅ 9. 외부 API 테스트 기준

➕ 9-1. 테스트해야 할 상황

➕ 9-2. Mock 사용

✅ 10. Webhook 테스트 기준

➕ 10-1. 테스트 케이스

➕ 10-2. 확인할 것

✅ 11. 엑셀 다운로드 테스트 기준

➕ 11-1. 테스트 케이스

➕ 11-2. 확인할 것

✅ 12. 배치 작업 테스트 기준

➕ 12-1. 테스트 케이스

➕ 12-2. 확인할 것

✅ 13. API 테스트 도구

➕ 13-1. Postman / Insomnia

➕ 13-2. Swagger

➕ 13-3. curl

✅ 14. NestJS 자동 테스트 기본 구조

➕ 14-1. 상태 전이 단위 테스트 예시

➕ 14-2. Service 테스트 예시

✅ 15. 테스트 DB 관리

➕ 15-1. 테스트 DB 기준

✅ 16. 배포 전 QA 체크리스트

➕ 16-1. 공통 체크리스트

➕ 16-2. DB 변경 체크리스트

✅ 17. 회귀 테스트

➕ 17-1. 예시

✅ 18. 배포 후 확인

➕ 18-1. 배포 후 체크리스트

➕ 18-2. 서버 확인 명령어 예시

✅ 19. 테스트 케이스 문서화

➕ 19-1. 테스트 케이스 문서 예시

✅ 20. 실무 체크리스트

➕ 20-1. 테스트 전략 체크리스트

➕ 20-2. 배포 전 체크리스트

➕ 20-3. 배포 후 체크리스트

✅ 21. AI를 활용해 테스트/QA 기준을 만들 때 질문법

➕ 21-1. 좋은 질문 예시

➕ 21-2. AI 답변 검증 기준

📌 요약

TIL - 20260704

TIL - 20260706

0개의 댓글