[이펙티브 소프트웨어 테스팅] CHAPTER 1

 

이펙티브 소프트웨어 테스팅 책 스터디를 시작했다 🙌🏻

매주 한 챕터씩 읽으면서 내용 정리를 할 예정인데,

읽으면서 느낀 점들이랑 새롭게 알게된 개념들도 함께 정리해보려고 한다 ㅎ.ㅎ

그럼 1주차 시작-!

 

 

---

 

테스트가 왜 필요한가?

우리는 사람이기 때문에 실수를 할 수 있고,

형편없는 프로그래머라서가 아니라 복잡한 사항을 프로그래밍하고 있기 때문에 버그가 생길 수 있다.

 

직감을 따르는 몇몇 수동 테스트만 수행하는 것은 코너 케이스를 빼먹을 확률이 높고,

배포가 진행된 이후 다른 사람으로부터 오류를 보고받아 다시 고치게 될 확률이 높다.

 

따라서 우리는 (1) 체계적인 접근법을 사용해 테스트 케이스를 도출하고,

(2) 테스트 자동화를 적용해 시간을 절약할 수 있다.

 

효율적이고 체계적인 테스트

효율적: 올바른 테스트를 작성하는 데 집중해야 함을 의미한다.

체계적: 어떤 코드 조각에 대해 어느 개발자라도 같은 테스트 스위트를 만들어낸다는 것을 의미한다.

 

효율적이고 체계적인 테스트를 위해서 다음과 같은 테스트 기법을 수행할 수 있다.

 

단위테스트

• 도메인 테스트: 요구사항을 작은 부분으로 나누어 테스트 케이스를 도출한다.
• 예시 기반 테스트: 특정 값(=데이터 포인트)를 골라 테스트를 작성한다. (=경계 테스트?)
• 구조적 테스트: 코드에 초점을 맞추어 현재의 테스트 케이스가 충분한지 평가한다.
• 속성 기반 테스트: 데이터 포인트를 임의로 골라 테스트를 수행한다.

대규모 테스트

• 통합 테스트
• 시스템 테스트

지능형 테스트

• 돌연변이 테스트

 

소프트웨어 테스트 원칙

• 모든 테스트 케이스를 테스트하는 것은 불가능하기 때문에, 우선순위를 세워 효율적인 테스트를 해야 한다.
• 시간과 비용 대비 비효율적인 테스트가 되지 않도록 테스트를 그만둘 때를 파악해야 한다.
• 하나의 테스트 전략으로 모든 종류의 버그를 잡을 수는 없다. (살충제 역설)
• 버그는 다른 곳에 비해 많이 발생하는 지점이 있다. (결함 클러스터링)
• 테스트는 버그가 존재하는지를 보여주는 것이지 존재하지 않는다는 걸 보여주는 게 아니다. (Dijkstra)
• 맥락에 따라 테스트 케이스를 도출하는 방법은 다르다. (ex. 앱, 웹, 임베디드 등)
• Verification과 Validation은 다르다. (에러 부재의 오류)

이 중에 Dijkstra의 말이 특히 인상깊었다.

우리가 작성한 테스트가 모두 통과된다고 해서 이 프로그램에 버그가 100% 없다고 말할 수 없다는 것이다. 

우리는 단지 테스트를 통해 프로그램에 큰 영향을 미치는 버그를 방지하고,

영향력이 덜한 버그만 통과하도록 한다.

 

단위 테스트를 선호하는 이유

작은 단위에 대해 테스트하는 것은 작성하기 쉽고, 빠르다. 

따라서 책의 저자는 단위 테스트를 선호한다.

하지만 단위 테스트가 가진 단점도 있기 때문에,

통합 과정에서 문제 발생 소지가 있을 것 같은 부분에 대해서는 통합 테스트와 시스템 테스트를 사용한다.

 

이렇게 단위 테스트 > 통합 테스트 > 시스템 테스트 순으로 비중을 가져가는 방식을 테스트 피라미드라고 한다.

이것 외에 테스트 트로피, 테스트 허니콤이라는 개념도 있다. 

 

---

 

 

1장은 테스트를 해야하는 이유와, 테스트를 시작하려 할 때 필요한 기초 지식에 대해 다룬 느낌이다.

1장의 시작 부분에서 이런 저런 핑계로 테스트 작성을 미루는 사람들에 대해 언급이 있었는데,

ㅎㅎ.. 뼈를 맞아버렸다;

 

안그래도 요즘 개발하면서 업데이트 사항을 배포하고, 나중에 오류 보고를 받아 다시 고쳐서 배포하고.. 

이 과정을 반복하면서 테스트를 도입해야겠다는 생각을 하고 있었는데,

동기부여가 된다..😇

 

 

🔗 참고 링크

test honeycomb 관련해서 읽어본 글

마이크로서비스 테스트, Test Honeycomb 전략