성능 테스팅에서의 테스트 오라클

테스터 관련 직군 중 가장 고액의 연봉을 보장하는 직군 중 하나가 성능 테스팅입니다.

일반적으로 업계에서 성능 테스터라 하면 폭넓은 도메인 지식과 개발 지식, 프로그래밍 능력을 겸비한 로드런너의 스크립트를 아주 능수능란하게 작성할 수 있는 사람을 말합니다.

이런 사람은 솔직히 매우 드물며, 덕분에 고액의 연봉을 받는 직군 중 하나입니다.

성능 테스트는 모든 종류의 소프트웨어에서 가능합니다.

저는 이 성능 테스트를 크게 2가지로 구분해서 제시해 보겠습니다.

하나는 서버와 관련된 성능 테스팅이고 다른 하다는 스탠드 얼론형 제품의 성능 테스팅입니다.

로드런너와 연관된 많은 경우의 성능 테스팅은 서버와 연관된 성능 테스팅이고 이 성능 테스팅의 경우 인터넷이나 주변에서 아주 쉽게 테스트 오라클이나 테스트 방법에 대한 정보를 쉽게 구하고 접할 수 있습니다.

반면 스탠드 얼론형 제품은 최근에 있어서 점점 더 어려워지는 경향이 있습니다.

어떤 사람들은 스탠드 얼론형 제품(이하 설치형 제품)의 성능 테스팅이 왜 어려운가?에 대해 의아해 하는 분들도 있을 것입니다.

아래 제 의견을 보시고 다른 의견이 있으신 분은 먼댓글(트랙백)이나 댓글을 달아주시면 고맙겠습니다.

기존의 설치형 제품의 성능 테스팅은 대체로 메모리와 CPU의 점유율이 테스트 오라클의 주된 척도였습니다.

그다지 먼 과거도 아닌 불과 10년 전만 해도 컴퓨팅의 자원은 열악하기 이를 데 없었습니다.

조금 더 멀리 15년 전  DOS 시절을 기억하시는 분이 있다면 상위 메모리, 하이 메모리와 같은 용어들을 기억하실 겁니다.

그 당시에는 멀티 태스킹은 꿈과 같은 것이었습니다. 물론 가능하기도 했지만 멀티 태스킹은 컴퓨터가 느려지는 주범이었죠.

윈도우와 관련된 많은 팁들이 이러한 메모리 자원을 어떻게 하면 조금이라도 더 쥐어 짤 수 있는지에 초점이 맞춰져 있었습니다.

게임은 이러한 제약이 더욱 심한 분야 중 하나였습니다.

그런데 세월이 많이 흘렀습니다.

이제는 CPU에 적어도 2개 많게는 8개까지 코어가 들어가는 세상이 되었습니다.

메모리는 아무리 적어도 1기가에서 많게는 4기가까지 들어갑니다.

시간이 지날 수록 컴퓨팅의 자원에 대한 이슈는 점점 희석화되어 가고 있습니다.

즉, 기존의 CPU나 메모리의 점유율을 기준으로 하는 테스트 오라클의 의미가 점점 퇴색되어 가고 있다는 점입니다.

운영체제도 발전에 발전을 거듭하여 최근에는 메모리의 점유나 회수에 대한 이슈가 예전에 비해 그렇게 크지 않습니다.

이러한 상황에서 설치형 제품에 있어서 테스트 오라클은 무엇이 될 수 있을까요?

아래에 나열하는 몇가지 경우는 제가 겪어본 이슈들일 뿐, 절대적인 기준은 절대 아닙니다. 혹시라도 더 좋은 예제와 기준이 있다면 저에게 꼭 알려주시면 고맙겠습니다.

그리고 저는 개발자가 아닌 정말 단순한 테스터의 입장에서 바라본 성능 기준이므로 개발자의 입장에서는 분명 더 많은 기준과 고려해야할 사항이 있을 것이라고 믿습니다.

첫번째는 멀티 코어 CPU입니다.

CPU에 멀티 코어가 장착되면서 발생하는 성능 이슈 중 가장 재미있는 현상은 제품이 모든 CPU를 동일하게 점유하는 현상입니다.

즉 멀티 태스킹이 정상적으로 이루어지지 않는 경우가 의외로 많습니다.

두번째는 종속성에 따른 메모리 점유입니다.

일반적으로 성능 테스팅을 할 때 메모리를 테스트 대상 홀로 쓰는 경우는 절대 없습니다.

우선 기본적으로 운영체제의 서비스들이 일정 부분의 메모리를 사용합니다. 문제는 운영체제의 설정에 따라 이러한 부분이 천차만별이라는 것입니다.

거기에 백신과 멀웨어 소프트웨어, 메신저 등을 비롯해 사용자가 기본적으로 사용하는 무수한 제품들이 있습니다.

이러한 제품은 수천 아니 수만가지가 넘고 이 중 어느 제품과 메모리 충돌이 나는 경우가 없다고 절대 장담할 수 없다는 것입니다. 최근에는 이러한 메모리 충돌의 경우가 매우 적긴 하지만 그렇다고 절대 발생하지 않는다고도 말할 수 없기 때문에 테스팅은 해야하는데 이러한 기준을 잡기가 점점 더 힘들어지고 있습니다.

세번째는 사용성과 관련된 이슈입니다.

실제로 사용성은 성능 테스팅과 일견 관계가 거의 없어 보입니다.

하지만 사용자가 인식하는 성능은 사용성과 매우 밀접하게 연관이 되어 있습니다.

예를 들어 데스크탑의 사진을 검색하는 사진 관리 프로그램이나 음악 검색 프로그램과 같은 경우 기존의 파일을 검색해서 DB를 만드는 방식 또는 사용자의 요청이 있을 때마다 즉석에서 검색하는 방식, 주기적으로 DB를 갱신하는 방식 등 그 알고리즘의 종류만큼 각 작업시마다 점유하는 CPU나 메모리도 천차만별이지만 실제로 사용자는 이러한 제품이 얼마만큼의 CPU나 메모리를 점유하는지에 대해 그렇게 큰 관심이 없습니다.

가장 중요한 것은 요청에 대한 즉각적인 응답속도일 것입니다.

하지만 ISO/IEC 9126 등과 같은 품질 특성에서도 성능 테스팅 즉 효율성의 측정 항목들은 실제로 자원에 대한 효율성을 측정하는 항목은 있지만 이러한 사용자 측면의 성능 테스팅에 대한 이슈는 없습니다.

성능 테스팅은 쉬운 테스팅은 아닙니다.

그리고 모든 테스트가 그러하듯 성능 테스팅 역시 테스트 오라클을 선정하는 것 역시 매우 어렵습니다.

하지만 중요한 것은 환경이 변하면 성능 테스팅 역시 변해야 한다는 것입니다.

그리고 그 변화에는 고객에 대한 존중과 생각이 들어가 있어야 한다고 생각합니다.

고객에게 최대의 가치를 주기 위한 테스팅이 가장 좋은 테스팅이라고 생각합니다.