Archive for the ‘테스트’ tag
소프트웨어 공학의 사실과 오해 6 – 테스트
http://www.yes24.com/24/goods/1418676
테스트
연구에 따르면, 프로그래머가 모든 코드를 완전히 테스트했다고 말할 때, 보통 55~60%의 로직 경로만이 실제로 테스트된 것이라 한다. 이는 소프트웨어 제품의 복잡성을 반증하는 것이기도 하고, 소프트웨어를 작성한 사람조차도 그들이 작성한 것에 대해 완전히 이해하지 못함을 보이는 것이기도 하다.
p.172
여기서 알 수 있는 것은, 수많은 종류의 테스트 방법이 존재하지만 소프트웨어 제품의 복잡성 때문에 완벽한 테스트는 불가능하다는 것이다. 이 때문에 (1)테스트를 수행하는 데 있어 타협할 수 밖에 없고, 적절히 선택해 타협하는 것이 매우 중요하며, (2)대부분의 주요 소프트웨어 제품이 오류를 포함한 채 출시되는 것 또한 놀랄만한 일이 아니다(순진한 사람들만이 오류 없는 소프트웨어를 기대한다).
p.173
많은 소프트웨어 전문가들이 오류 없는 소프트웨어를 만드는 것이 가능하다고 주장하며 이를 달성하지 못한 회사나 조직을 비난하지만, 이번 사실에서 명확히 알 수 있듯이 그 영광된 목표는 단지 아주 작은 규모의 소프트웨어 프로젝트에서나 가능할 것이다. 이제, 오류 없는 소프트웨어란 불가능한 목표는 포기하고, 매우 심각한 오류가 없는 소프트웨어 제작과 같은, 좀더 현실적이고 실현 가능한 목표에 집중하는 것이 중요하다.
p.174
어느 정도 규모가 있는 C++ 프로젝트에 유닛테스트를 적용해본 것은 작년이 처음이었는데, 왜 55~60%의 로직 경로만이 테스트 되는지 이해할 수 있을 것 같다. 제품 수준의 코드에는 인자의 유효성 체크, 상태의 유효성 체크, 실패에 대한 체크 등으로 엄청나게 많은 분기가 발생하는데 이런 예외 상황을 완벽하게 테스트하는 것은 비용대비 효율이 떨어지기 때문이다. 높은 테스트 커버리지는 반드시 달성해야만 하는 목표라기 보다는, 프로젝트의 여러 목표 중에 하나가 되어서 우선도를 따져보는 것이 맞는 것 같다. 적당한 테스트 커버리지에 대해서는 지난 번 포스팅 어느 정도의 테스트 커버리지가 필요할까를 참조.
100%의 테스트 커버리지가 가능하다 하더라도, 이는 충분한 테스트 기준이 아니다. 대략 소프트웨어 결함의 35%는 누락된 로직 경로에서, 40%는 로직 경로의 특정 조합을 실행할 때 나타난다. 이런 것들은 100% 커버리지로도 잡히지 않을 것이다.
p.176
100%의 구조적 커버리지가 발견할 수 있는 것은 단지 25%의 오류라는 의미다. 저자가 가진 오류 데이타베이스로부터 산출한 비율이라는 점도 감안하자.
소프트웨어 테스트 도구가 널리 사용되지 않는 데는 세 가지 주요 요인이 있다. 1. 소프트웨어 분야의 경영진과 학계는 모두 앞쪽 단계를 훨씬 더 중요하게 보이도록 만들었다. -중략- 2. 뒤쪽 단계의 작업은 기술적으로 너저분하다. -중략- 3. 생명주기의 뒤쪽 단계에는 일정 압박이 심하다. -중략-
p.181, 182
소프트웨어 업계는 요구분석, 설계, 구현을 지나서 테스트에 대한 관심이 높아지고 있는 것 같다. 앞쪽의 단계에서 은 탄환Siver Bullet을 찾지 못해서 자꾸만 뒤쪽 단계에서 기회를 찾으려 이동한다는 얘기도 있지만, 소프트웨어 분야의 모든 행위에 대해서 한 번씩 조명을 하고, 쓸데없는 미신이나 착각, 오해를 없앨 수 있었으면 하는 바램이다.