결론 : 테스트는 엔지니어들이 자신의 제품의 신뢰성을 향상시킬 수 있는 가장 적절한 투자 수단이다.
- 테스트의 종류는 굉장히 여러가지가 있는데, 신뢰성을 올리기 위해서 대략적으로 테스트의 종류와 중요도에 대해서 설명하고 있다.
- 테스트는 어떤 변경 사항이 일어났을 때 특정 부분에서 동일한 결과를 기대할 수 있다는 것을 보여주기 위한 메커니즘이다.
소프트웨어 테스트의 종류
전통적인 테스트
- 소프트웨어를 개발하는 동안 소프트웨어가 올바른 동작을 수행하는지 여부를 평가하는
테스트
Unit Test
- 클래스나 함수 등을 테스트하여 각 동작을 독립적으로 테스트하는 방법
- 주로
TDD
방법론과 함께 사용됨 - dependency 가 있을 때는 어떻게?
- → Dependency Injection 사용. Dagger 와 같은 툴을 사용해서 Mock 객체를 생성하여 수행
Integration Test
- 단위 테스트를 통과한 소프트웨어 컴포넌트는 그보다 더 큰 규모의 컴포넌트에 편입되는데, 이떄 수행하는 테스트가
통합 테스트
임
System Test
- 아직 배포가 완료되지 않은 시스템에 대해 엔지니어가 수행할 수 있는 가장 큰 규모의 테스트.
- Smoke Test
- 전자 회로 기판에 전원을 넣었을 때 기판에서 연기가 나는지 확인하는 테스트에서 유래됨. 즉, 안정성을 유지하기 위해서 주요 기능들이 제대로 작동하는지 확인
- 안정성 검사 (Sanity Test) 로 알려져 있으며, 약간의 장애 상황을 가정한 테스트를 포함해서 더 많은 부분을 테스트 함
- Performance Test
- 성능 테스트
- Regression Test
- 이미 알려진 버그들을 통해 시스템의 실패나 잘못된 결과가 나타나는 것을 유추하는 테스트.
프로덕션 테스트
- 실제 동작하는 웹 서비스에 대해 배포된 소프트웨어 시스템이 올바르게 동작 중인지를 판단하는 테스트
- Black Box 테스트라고도 부름
설정 테스트
- 실제 프로덕션 환경에서 동작하는 특정 바이너리가 실제로 어떻게 설정되어 있는지를 확인하고 해당 설정 파일과 일치하지 않는 부분을 찾아 보고 함
스트레스 테스트
- 시스템을 구성하는 컴포넌트들의 한계를 이해하기 위함.
- 예시
- DB 용량이 어느 정도에 다다르면 쓰기 작업에 실패하는가?
- 서버는 초당 몇 개의 쿼리까지 응답할 수 있는가?
카나리 테스트
- 서버의 일부만을 새로운 버전의 바이너리나 설정 파일로 업그레이드한 후, 일정 기간 동안 살펴보는 형태로 진행
테스트 및 빌드 환경 구성하기
- 일반적으로 초기 설계 부터 테스트 커버리지 100프로를 달성하면서 프로젝트를 수행하는 경우 (TDD) 는 잘 없음.
- 뿐만 아니라 SRE 엔지니어들은 대부분 프로젝트가 한창 진행 중일 때 합류하기 때문에, 어느 부분부터 테스트를 시작해야하는지 판단하는 부분이 중요함
- 고려해야할 점들
- 어떤 형태로든 중요도를 측정해서 컴포넌트들의 우선순위를 결정해야함
- 사활이 걸려있거나, 비지니스 관점에서 중요한 기능이나 클래스를 특정할 수 있는지?
- 다른 팀들이 통합해서 사용하는 API들이 있는지?
- → 가장 강력한 테스트 문화 수립 방법은 지금까지 보고된 모든 버그를 테스트 케이스의 형태로 문서화하고,
regression Test
에 포함시켜야함