[QA]자동화 테스트

테스트 자동화

• 버튼 클릭, 로그인, 데이터 입력 등의 반복 작업 자동으로 수행,
• 더 빠르고 정확하게 테스트 가능

이로 인한 시간 절약, 정확성 향상, 비용 절감 효과 기대
but!!

• 초기 설정이 어려움 : 코드 작성하고 그런 시간이 걸림
• 유지보수가 필요함 : 프로그램 바뀌면 테스트도 업데이트해야 함
• 모든 테스트를 자동화할 수는 없음 : 사용자 기반 테스트들은 직접 해야 함

그럼에도

단위 테스트(Unit Test) : 코드 한 조각 작동 하는지..

• Mocking : 외부 의존성을 제거하고, 독립적인 테스트를 수행하는 기법… 이라곤 하지만 결국엔
  • 데이터베이스, API 요청 등을 목업 객체로 대체해 테스트 한다는 소리임
  • 이게 실제 DB나 API 없을 때도 테스트가 쌉 가능임, 테스트 속도를 빠르게 유지 가능
  • 자동화 최적화 가능,빠르고 효율적

통합 테스트(Integration Test) : 여러 기능이 함께 작동 하는지..

• 이게 단위 테스트는 통과했어도, 실제 연결됐을 시 문제가 발생할 수 있음

UI 테스트(UI Test) : 버튼, 입력 등 간단한 동작들이 작동 하는지..

• 자동화 가능하지만 유지 보수 비용이 높음

API 테스트 (API Test) : 서버와 데이터가 올바르게 주고받아지는지..

• 자동화 최적, 비즈니스 로직 검증에 필수임

대표적인 테스트 자동화 도구의 예

• Selenium - 웹 UI 테스트 자동화 (Python)
• Cypress - 프론트엔드 UI 테스트 자동화
• JUnit - 단위 테스트 자동화
• Postman - API 테스트 자동화
• JMeter - 성능 테스트 (대량의 트래픽 시뮬레이션 가능)
• K6 - 성능 테스트 도구 (JavaScript 코드 기반, 클라우드 환경에서 쉽게 실행)

테스트 자동화는!!

• 반복적인 작업 자동화로 인한 실수 방지
• 빠른 피드백으로 개발 생산성 향상
• 테스트 자동화를 거쳐 배포 후 심각한 오류 발생 가능성을 최소화할 수 있음!!

---

성능 테스트는 자동화가 쉽지 않다!!!

• 네트워크 상태와 서버 부하에 따라 결과가 달라질 수 있어 자동화하면 골치가 아파…
• 실제 트래픽을 완벽하게 재현하는 게 쉽지 않다~~ 이말이야

하.지.만.

• 부하 테스트 환경을 일정하게 유지하면 해결
  • 서버 상태와 네트워크 환경을 고정
  • 실제 트래픽 패턴을 반영한 부하 테스트 스크립트를 작성한다!!

---

UI 테스트는 자동화 시 유지보수가 문제가 되는데!!

• UI 요소가 변경되면 테스트 코드도 같이 수정해 줘야 하기 때문!!
• 화면 구조가 변경되니 테스트 제대로 안 될 가능성이 높지

하.지.만

• Page Object Model(POM) 적용 시

  UI 요소와 테스트 코드를 분리해 유지보수성을 높이는 설계 패턴임

  • UI 요소(버튼, 입력창 등..)를 별도 클래스(파일)에서 관리해 유지보수 비용이 절감됨
  • UI 변경이 되어도 테스트 코드 수정 없이 POM만 변경하면 된다!!
  • 그리고 유지보수도 쉬워진다는데….

BEFORE

driver.findElement(By.id("btn-login")).click();

AFTER

loginPage.clickLoginButton();

-> UI 요소를 별도의 파일에서 관리해 유지보수 용이

Page Object Model(POM)의 기본 구조

구성 요소	설명
Page Class	UI 요소(Web Elements)와 해당 요소의 동작을 정의
Test Code	Page Class의 메서드를 호출하여 UI 테스트를 실행
Driver Class	웹 드라이버 초기화 및 설정을 담당

---

### Login Test (예제임)

public class LoginTest {
    WebDriver driver = new ChromeDriver(); // 웹 드라이버 초기화
    LoginPage loginPage = new LoginPage(driver); // LoginPage 객체 생성

    @Test
    public void testLogin() {
        loginPage.login("testuser", "password123"); // 로그인 테스트 실행
    }
}

이게 적용을 하면..

public class LoginPage {
    private WebDriver driver;
    private By usernameField = By.id("username");  // 아이디 입력 필드
    private By passwordField = By.id("password");  // 비밀번호 입력 필드
    private By loginButton = By.id("login");       // 로그인 버튼

    // 생성자: WebDriver 객체를 받음
    public LoginPage(WebDriver driver) {
        this.driver = driver;
    }

    // 로그인 기능을 메서드로 정의
    public void login(String username, String password) {
        driver.findElement(usernameField).sendKeys(username); // 아이디 입력
        driver.findElement(passwordField).sendKeys(password); // 비밀번호 입력
        driver.findElement(loginButton).click(); // 로그인 버튼 클릭
    }
}

Page Object Model을 적용한 LoginPage 클래스

• WebDriver driver를 멤버 변수로 선언하여 웹 페이지를 제어
• By 객체를 활용하여 UI 요소를 정의 (By.id("username") 등)
• login() 메서드에서 로그인 기능을 캡슐화하여 재사용 가능

---

API 테스트는 자동화가 쉽지 않음!!

API 테스트 자동화의 어려움

• 외부 API 응답 변할 가능성 있음
• 네트워크 상태, 서버 상태에 따라 결과 달라질 수 있음
  = API 테스트 환경을 분리하면 된다!
  = Mock 서버 활용. 실제 API와 테스트 API 구분

API 테스트 환경에서 발생하는 문제

• 개발 환경과 운영 환경이 다르면, 테스트 결과가 달라질 수 있다
• 서버가 다운되거나 응답 시간이 길어질 경우 테스트 실패
  = 실제 API 호출 대신 샌드박스(Sandbox) 환경을 구성해 테스트 진행
  = 네트워크 상태에 관계없이 안정적인 API 테스트가 가능하다

API 테스트 데이터

• 운영 데이터와 테스트 데이터 혼합될 경우 오류 발생 가능성이 있음
• 실시간 데이터가 변할 경우, 테스트 결과 달라질 가능성 있다
  = 운영 데이터와 테스트 데이터를 별도 관리해 분리해야 함
  = 데이터 시나리오 정의해 예측 가능한 테스트 환경 유지

결론 => 테스트 자동화는!!

• 테스트 환경을 일정하게 유지
• 테스트 데이터를 관리해 예측 가능한 상태로 유지
• 테스트 실행 속도를 최적화해 지연 방지
• 테스트 실패 시 자동 로그 기록해 원인 분석 가능하도록 설정

but! 코드 변경이 잦다면???

• 기존 테스트 코드 깨질 가능성 높아지면 » 유지보수 비용 증가 » 테스트 결과가 일관되지 않을 수 있음
  = 테스트 코드와 UI/API 코드를 분리한다!!
  = 주기적으로 테스트 리팩토링, POM 사용 UI 테스트는 분리!!

자동화 테스트 도입 전 체크리스트!!

• 자동화할 테스트 유형이 명확함?? -> 단위,UI,API,성능이냐 등..
• 적절한 자동화 도구 픽함??? -> 프로젝트 요구사항과 도구 적합성 비교해서
• 테스트 환경 표준화 -> CI/CD와 연계할 계획이 있음?? (연계를 하면 배포 전 코드 품질 보장할 수 있음, 코드 변경 시 자동으로 테스트 실행 가능함)
• 자동화와 수동 테스트 구분이 명확함?!?!

---

테스트 환경 구축 전 최종 점검 항목

• 운영 환경과 테스트 환경이 유사함??
• 테스트 데이터는 동기화 됨?
• 테스트 자동화 실행이 원활함??
• 테스트 실행 속도는 최적화 되어 있는가??
• 테스트 실패 시 원인을 쉽게 분석할 수 있음??