24DAY 백엔드 - 18DAY 테스팅

1. 단위 테스트

단위 테스트는 모듈이나 애플리케이션 안에 있는 개별적인 코드 단위가 예상대로 작동하는지 확인하는 반복적인 행위입니다. 이것은 보통 여러분의 코드를 테스트하는 코드의 형태를 취합니다. 테스트 코드를 테스트하는 코드를 작성할 필요는 없습니다.

단위 테스트의 중요한 특징 몇가지는 테스트들은 서로 분리되어 있고, 실행은 자동화되며 애플리케이션의 같은 부분을 테스트하는 테스트들은 그룹화되어 한 번에 처리된다는 것입니다.

 

테스트 코드들은 서로 분리되어 있고 테스트 되고 있는 코드와도 분리되어 있습니다. 이는 문제를 쉽게 찾고 해결하게 해줍니다. 

 

편의를 위해 단위테스트는 자동화된 경우에만 동작합니다. 보통 애플리케이션 코드보다 테스트 코드가 더 많으며 테스트를 수동으로 실행하는 것은 매우 좋지 않은 생각이기때문입니다. 모든 테스트를 한 명령어로 실행하는 것이 이상적입니다. 실제로 이 방법은 대부분의 테스트 라이브러리에서 함수나 모듈이 테스트 코도를 발견하고 실행하는 것을 통해 사용되고 있는 접근법입니다

 

특정 기준에 따라 그룹화된 테스트들은 개발자들이 필요할 때 전체 테스트 에서 특정 부분만 따로 테스트를 실행하는 것을 가능하게 해줍니다. 또한 쉽게 테스트를 찾아서 변경하고 추가할 수 있도록 합니다.

 

왜 단위 테스트를 하는가?

프로젝트에 단위 테스트를 적용하는 데에는 "내 코드가 제대로 동작하는지 확인하는 것" 이라는 명백한 이유 외에도 몇 가지 장정이 있습니다

 

단위 테스트는 코드를 "어떻게" 작성하는지 생각하는데 도움을 줍니다. 게다가"무엇"을 해야하는지에 있어서 구현 선택을 검토하는데 해가 되지 않고 그 선택들이 적절한지 아닌지 알아냅니다. 단위 테스트를 하고 잇는 코드들이 다르게 보이기 시작할것입니다. 테스트 하기 쉽게 만드며, 따라서 변화시키는 것 또한 쉽도록 합니다. 코드의 단위는 작을수록 좋습니다.

 

2. 통합 테스트

통합테스트는 모듈을 통합하는 단계에서 수행하는 테스트입니다. 단위 테스트를 우선 수행하며 모듈들이 각각 정상적으로 작동되는 것을 확인했다면 이제 이 모듈들을 연동하여 테스트를 수행하게 되는데 이것이 통합 테스트입니다.

 

단위 테스트에서 찾지 못하는 연동시 발생하는 버그 등을 찾을 수 있으며, 다른 모듈들과 동시 다발적으로 테스트를 수행해야 하기 때문에 단위 테스트와 다르게 일반적으로 테스트를 교육 받는 전문적인 테스터와 함계 수행하게 욉니다.

 

테스트 시 컴포넌트간의 I/F(인터페이스)를 테스트 하는 것은 물론이고, 운영체제, 파일 시스템, 하드웨어, 시스템간 인터페이스와 같은 시스템의 각기 다른 부부과 상호 연동하는 동작을 테스트하게 됩니다.

 

통합 테스트(Integration Test)의 개념

- 단위테스트 이후, 각 모듈들의 상호 작용이 제대로 이루어지는지 검증하는 테스트 활동

- 단위 테스트가 끝난 모듈을 통합하는 과정에서 발생할 수 있는 오류를 찾는 테스

 

통합 테스트의 유형

하향식(Top-Down)

• 가장 상부의 모듈부터 통합하며 테스트를 순차적으로 진행하는 방식
• 하향식 테스트를 위해 테스트 스텁(Test Stub)으로 I/F 테스트 진행
• 결함 격리가 쉬우며, 설계상의 결함을 빨리 발견할 수 있음
• 수정이 어려운 중요한 결함을 하부 구조에서 발견 될 수 있음

 

상향식(Bottom-Up)

• 최하위 모듈을 통합 후, 상부의 모듈을 순차적으로 추가 테스트
• 상향식 테스트를 위해 테스트 드라이버로 I/F 테스트 진행
• 결함 격리가 쉬우며, 하위 모듈을 충분히 테스트 수행
• 수정이 어려운 중요한 결함(설계상 결함)을 상부 구조에서 발견 될 수 있음

샌드위치 테스트

• 상향식과 하향식의 장점을 이용하는 방식(하향식 + 상향식)
• 하위 프로젝트가 있는 대규모 프로젝트에 사용하는 방식
• 병렬 테스트가 가능하고 시간 절약이 가능합니다
• 스텁과 드라이버의 필요성이 매우 높은 방식이며, 비용이 많이 들어감

 

빅뱅

• 시스템을 구성하는 모듈을 가각 따로 구현하고 전체시스템을 한번에 시험
• 테스트를 위한 드라이버와 스텁없이 실제 모듈들로 테스트 진행
• 단시간 테스트를 수행하나 결함의 격리가 어려운 방식

 

3. 기능 테스트

 

기능테스트: 사용자와 어플리케이션의 상호작용이 원활하게 이루어지는지 테스트 하는 것 입니다.

요구 사항에 따른 기능의 구현 여부 및 동작 여부에 대해 테스트를 진행합니다.

테스트 기준은 명세 따르며 명세를 기반으로 테스트 조건과 테스트 케이스를 도출합니다

 

기능 테스트 분류

• 단위 테스트
• 통합 테스트
• 인수 테스트
• 회귀 테스트

3.2  비기능 테스트

비기능 테스트는 고객의 성능적 요구사항을 중점적으로 테스트하는 것입니다.

비기능적인 측면인 성능, 신뢰성, 안정성, 유요성, 적합성 등을 확인합니다.

비기능적 테스트는 확인하고자 하는 트것ㅇ에 따라 환경 구성과 관련 도구가 필요할 수 있습니다.

 

비기능 테스트 분류

• 볼륨 테스트
• 확장성 테스트
• 사용성 테스트
• 성능 테스트

3.3 구조적 테스트

구조적 테스트는 화이트 박스 테스트라고도 하며 소프트웨어가 어떻게 구성되었는지 테스트하는 것입니다.

테스트 커버리지를 평가하여 보장성과 충분함을 측정합니다.

커버리지는 테스트 스위트에 의해 테스트된 정도를 의미하며 퍼센트 형식으로 표시합니다.

4. CI/Cd(지속적 통합/지속적 제공)

 

CI는 지속적 통합으로 모든 개발이 끝난 이후에 코드 품질을 관리하는 곤적 방식의 단점을 해소하기위해 나타난 개념입니다. 말그래도 개발을 하면서 '코드에대한 통합'을 '지속적'으로 진행함으로써 품질을 유지하자는 것입니다.

 

 

CD는 지속적 배포로써 소프트웨어가 항상 신뢰 가능한 수준에서 배포될 수 있도록 지속적으로 관리하자는 개념입니다.

 

CI의 연장선으로 생각하면 됩니다. 배포 이전에 테스트와 빌드는 필수적이기 때문에 사실상 CD가 되려면 항상 CI가 선행되어야 한다고 봐도 무방합니다.

 

즉, CI 프로세스를 통해 개발중에 지속적으로 빌드와 테스트를 진행하고,

이를 통과한 코드에 대하여 테스트서버와 운영서버에 곧바로 그 내용을 배포해 반영하는 것입니다.

이상적인 환경이라면 테스트와 빌드가 ‘지속적’으로 이루어지기 때문에,

배포 또한 자연스럽게 ‘지속적’으로 이루어지게 됩니다.

 

사실상,

CI = 빌드 및 테스트 자동화

CD = 배포 자동화

라고 기억해도 무방하다.

 

 

출처: https://needjarvis.tistory.com/443 [자비스가 필요해]

출처 : cjh5414.github.io/why-pytest/