테스트 레벨 별 네거티브 테스트케이스 작성 방식 (API TC)

한번쯤은 다시 정리해 볼 필요가 있었던 주제인 네거티브 테스트 작성 방식에 대해 정리해 보는 포스팅입니다.

업무를 진행하면서 생각했던 것들을 작성하고, 여러 자료도 참고한 내용으로 글을 작성해보겠습니다.

 

"통합 테스트의 기준으로 테스트 케이스를 작성한다면 어떻게 작성될까요?"

 

 

순간 당황 했습니다. 테스트 레벨의 기준도 알고 있었지만 단위, 통합테스트 기준을 구분해서 TC를 작성한 적이 있었나..?

 

매뉴얼 테스트를 많이 하다보니, 단위 테스트와 통합 테스트 케이스의 경계를 애매모호하게 관리했다고 생각됐습니다.

 

그래서 한 번은 정리해보고 싶었던 내용으로, 테스트 레벨 별 TC 작성 방식에 대해 정리해보고 싶었고, API TC와 매뉴얼 TC를 구분해서 작성해보고 싶었습니다.

 

이번 포스팅에는 API TC를 대상으로 한번 작성해 보겠습니다.

그전에! TC를 작성할 때 네거티브 테스트는 어떻게 작성하고 있을까요?

이것부터 한번 정리해 봐야겠습니다.

 

---

테스트 레벨 별 네거티브 테스트의 비중은?

 

예전 글에서 TC를 어떻게 작성하는지에 대한 글을 작성한 적이 있습니다.

 

[QA/업무 방식] - TC(Test Case)는 어떤 기준으로 작성하나요?

TC(Test Case)는 어떤 기준으로 작성하나요?

 

 

개인적인 생각들을 정리해 본 글을 다시 보면서 느낀 건 결국 정상동작과 비정상동작 두 가지로 구분되며, 테스트 레벨에 따라 다르게 적용하는 방식이었다는 것을 생각하게 되었습니다.

 

 

테스트 레벨에 따라 오류 상황을 잘 대응하는지가 중요한 단위 테스트가 있을 것이고,

통합 테스트에서는 플랫폼이나 API 간 연동에서 정상적으로 잘 진행이 되는지, 연동이 실패했을 때 대비가 되는지 확인할 것이며,

시나리오 테스트에서는 전체적인 시나리오가 잘 정상 동작하는지를 주로 확인할 것 같았습니다.

 

 

그럼 당연하게도, 테스트 레벨 별 네거티브 TC 작성 비중도 다르다고 생각되어, 정리를 해보겠습니다.

아래는 AI의견과 여러 레퍼런스를 참고하고, 저의 의견을 덧붙여본 내용입니다.

 

작성한 내용은 정답이 아니라 개인적인 생각을 정리해 보는 것이라는 것을 다시 한번 강조..!

 

 

단위 테스트(Unit Test)는 70% 정도가 네거티브 테스트로 구성되는 것이 좋은 것 같습니다.

이유는 TC를 작성해 본다면 바로 생각 날 수 있는데, 단위 TC를 생각해 보면 대부분 안 되는 것을 잘 방어하고 있는가?를 위주로 작성했습니다.

 

개발한 기능이나 API 잘 동작해? 그럼 입력을 잘못 넣거나, 동작을 잘못했을 때는 어떻게 반응해? 이것들을 우선적으로 확인했으니까요.

 

 

통합 테스트(Integration Test) 비율은 50% 반반 정도 되는 것이 좋은 것 같습니다.

API 간 연동이 잘 되는지, 특정 동작을 함에 따라 다른 값이 정상적으로 변해서 표시되는지도 확인해야 하며, 

외부 API 연결 응답이 어렵거나, DB 연결, 트랜잭션 롤백 시나리오 등 비정상 요소도 확인해 줘야 해서 반반 정도로 나뉠 것 같고, 조금 더 높다면 네거티브 TC가 살짝 더 높다고 생각됩니다.

 

 

시나리오 테스트(E2E) 비율은 20% 정도로 생각됩니다.

사실 시나리오 테스트에서 네거티브는 기능 동작을 검토하는 것이 아니라 주로 성능적인 측면, 비즈니스 로직 관련 부분을 확인해야 하기 때문에 시나리오 테스트는 주로 정상 동작이 잘 되는지를 확인하는 것 같습니다.

 

 

QA를 진행하면서 자주 보는 그래프인데, 단위 테스트 부분에서 많은 결함을 확인해야 비용 감소가 커지는 것 처럼, 네거티브 테스트의 비중도 앞 부분에서 다양한 관점으로 많이 해야 전체적인 비용 감소에 효과를 줄 수 있다고 생각합니다.

 

이처럼 테스트 레벨에 따라 네거티브 테스트의 비중은 다르게 둬야 하는 것은 알겠고, 어떤 방식으로 작성하는지 예시를 공유해 보겠습니다.

시나리오 테스트는 기준이 환경에 따라 다를 수 있기에, 단위 테스트와 통합 테스트 레벨에서 예시만 작성해 보겠습니다.

---

단위 테스트 레벨에서의 네거티브 테스트케이스

 

API 테스트를 구성하는 중 단위 테스트를 작성한다면 어떻게 작성할까요?

예제 자료가 필요할 것 같아서 가짜 데이터를 제공해 주는 사이트를 공유드리겠습니다.

https://fakestoreapi.com/

Fake Store API

 

위에 보이는 화면처럼 상품에 대한 API 테스트 예제를 확인할 수 있습니다.

보통 파라미터 없이 GET만 호출하는 경우는 정상적인 케이스만 작성하고, 파라미터를 함께 사용해서 호출해야 하는 경우 네거티브 테스트를 많이 작성하게 됩니다.

 

기본적으로 위 이미지처럼 POST 방식에서 요구하는 파라미터가 누락되는 경우에 대한 TC

파라미터 값의 제한 요소가 있는 경우 비정상 데이터를 입력했을 때 응답값 확인하는 TC

이런 것들을 생각해 볼 수 있는데, 어떤 것들을 확인해야 하는지 정해두면 보다 빠르게 생각할 수 있겠죠?

 

API 단위 테스트의 기본적인 네거티브 TC 체크리스트

1. 입력 데이터 검증 -> 필수 파라미터의 누락 검증 -> 잘못된 데이터 타입, 파라미터명 검증 -> 최소, 최대 길이를 초과하거나 미달한 데이터 검증 -> 특수문자, 공백 값이나 Null 값 검증 2. 인증/권한 검증 -> 토큰의 누락이나 만료, 변조 검증 -> 권한 없는 사용자가 호출했을 때 검증 -> API Key값이 잘못되었을 때 검증

 

항상 확인해야하는 기본적인 테스트 케이스 작성 기준을 정리한 것이라서, "중복 상품 등록 시 응답 확인"처럼 기능의 비즈니스 로직에 해당하는 테스트 케이스는 상황에 맞게 추가해야 합니다.

 

 

---

통합 테스트 레벨에서의 네거티브 테스트 케이스

 

통합 테스트 레벨에서는 API 간 연계가 정상적으로 동작하는지, 외부 시스템과 연동이 잘 되는지를 주로 확인합니다.

그래서 단위 테스트 수준과는 조금 다른 느낌의 네거티브 테스트 케이스를 작성해야 하고 외부요인 즉, DB나 네트워크나 외부서비스 장애에 대한 케이스를 작성해서 관리해야 합니다.

 

예를 들면, 상품 등록 -> 상품 수정 -> 상품 조회 순서대로 진행하여 새로운 상품이 정상적으로 등록되어 있는지 확인하는 테스트 케이스를 작성해 봅니다.

 

등록, 수정, 조회 부분은 단위 테스트를 통해 검증되었을 테니, 기능 동작에 대한 오류는 없다고 치면 확인해야 할 부분은 어떤 것이 있을까요?

 

상품 등록하는데 10초가 걸리는 이슈가 있어서 다음 상품 수정 API를 호출했는데, 등록된 상품이 없다고 나오는 경우처럼 정상적으로 동작은 하지만 응답 지연과 같은 부분을 확인할 필요성이 있습니다.

 

다른 방식으로는 상품을 삭제했는데 DB가 아닌 캐시에서 처리하는 GET API인 경우 호출에 정상 응답할 수 있는 상황도 있기에, 단순히 하나의 API 동작이 정상 수행되는 것이 아니라, 다음 과정에서도 정상 처리되었는지 확인할 필요가 있죠.

 

 

API 통합 테스트의 기본적인 네거티브 TC 체크리스트

1. API 간 연계 검증 -> 외부 API 응답 지연, 타임아웃 검증 -> 연계된 API에서 에러 응답 시 검증(4xx, 5xx) 2. 데이터베이스 검증 -> DB 연결 실패 시 검증 -> 트랜잭션 중단 시 롤백 기능 검증 -> 동시성 이슈 검증

 

이처럼 통합테스트 레벨에서는 단순히 기능이 잘 동작해?를 보는 것보다 잘 동작한 것이 잘 보여? 잘 없어졌어? 처럼 기능 동작 후 다음 과정에서 잘 적용 되었는지를 확인하는 케이스가 필요하다고 생각됩니다.

 

---

 

정리한 내용이 부족한 부분이 있지만.. 테스트 레벨에서 다른 기준의 TC 작성을 해야 하는 것을 다시 한번 알게 되었습니다.

다음 포스팅에는 매뉴얼(UI) 테스트 기준으로 네거티브 테스트 케이스의 체크리스트를 한번 작성해 보겠습니다 :)