제목: 휴리스틱 테스트 오라클(Heuristic Test Oracles)
저자: Douglas Hoffman
문서유형: 저널 페이퍼(총 4페이지), 1999년
높은 비용과 복잡도라는 단점을 가진 트루 테스트 오라클의 대안이 될 수 있는 휴리스틱 오라클에 대해 설명한 자료
테스트 오라클(A Test Oracle)
- 성공적인 소프트웨어 테스팅을 위한 핵심 요소 중 하나가 그 ‘결과의 캡처 및 비교’이다. 예상 결과(Expected results)는 ‘테스트 오라클’이라는 메커니즘을 사용하여 생성된다.
- 오라클이라는 용어는 테스팅에서 아래의 여러 가지 의미로 사용될 수 있다
- 예상 결과를 생성하는 프로세스
- 예상 결과 그 자체
- 실제 결과가 우리가 예상한 결과와 동일한지 여부에 대한 답 - 이 기사에서 ‘오라클’이라는 용어는 예상 결과를 생성하는 데 사용되는 대체 프로그램이나 메커니즘을 의미한다.
오라클에 대한 다섯 가지 접근 방식(Five Approaches to Oracles)
아래 표는 자동화된 소프트웨어 테스트 검증을 위한 오라클에 대해 소프트웨어 업계가 사용해 온 다섯 가지 접근법을 설명하고 있다.
|
|
정의 |
장점 |
단점 |
|
트루 오라클(TRUE ORACLE) |
모든 예상 결과를 독립적으로 생성 |
모습을 드러낸 에러는 놓치지 않음 |
구현 비용이 높음 복잡하고 종종 실행에 오랜 시간이 걸림 |
|
휴리스틱 오라클(HEURISTIC ORACLE) |
몇몇 입력에 대해 정확한 결과를 제공, 나머지는 간단한 일관성(휴리스틱) 체크 |
트루 오라클보다 빠르고 쉬움 훨씬 적은 비용으로 생성 및 사용 가능 |
체계적인 에러를 놓칠 수 있음 |
|
샘플링 오라클(SAMPLING ORACLE) |
특정 입력 집합 또는 결과 집합을 선정 |
계산/인지하기 쉬운 결과를 선택할 수 있음 간단한 오라클만 가지고 수동으로 검증할 수 있음 |
체계적인 특정 에러를 놓칠 수 있음 종종 소프트웨어가 테스트를 통과하도록 훈련하는 역할을 함 |
|
일관성 오라클(CONSISTENT ORACLE) |
현재 실행 결과를 이전 실행 결과에 비추어 검증(회귀 테스트) |
오라클을 사용하는 가장 빠른 방법 검증이 복잡하지 않음(단순 비교) 많은 양의 데이터를 생성하고 검증할 수 있음 |
애초 실행(이전 실행 결과)이 미발견 에러를 포함하고 있을 수 있음 |
|
오라클 없음(NO ORACLE) |
결과의 정확성을 체크하지 않음(일부 결과만 생성됨) |
데이터 양의 제약 없이 실행 가능 |
아주 눈에 띄는 실패만 알아차리게 됨 |
휴리스틱 오라클의 예
아래 그림과 같은 사인 함수(sine function)의 구현을 테스트한다고 가정해보자. 이 구현에 쓰인 것과는 다른 계산 알고리즘을 사용하는 별도의 구현된 루틴을 가지고 해당 사인 함수를 테스트할 때, 이 별도의 루틴이 ‘트루 오라클(True Oracle)’이 된다. 트루 오라클은 테스트 대상 시스템(SUT)이 취할 수 있는 입력이라면 무엇이든 마찬가지로 받아들일 수 있으며, 오류를 찾아낼 가능성도 높다. 주의할 것은 트루 오라클이 반드시 모든 에러를 발견하는건 아니라는 점이다. 예를 들어, 어떤 하드웨어나 운영체제 오류가 SUT와 트루 오라클 양쪽 모두에 영향을 준다면(예, 펜티엄 버그), SUT와 오라클이 동일하게 잘못된 답을 생성하므로 에러를 알아차리지 못할 수 있다. 이런 독립적인 오라클은 생성 및 사용하는데 비용이 많이 드는 단점이 있다(종종 SUT를 개발하는 것과 동일하거나 또는 더 많은 비용과 머신 리소스가 소요됨). 또한 그 복잡성도 SUT에 필적하기 때문에 자체 오류를 가지고 있을 가능성도 높다.
[사인파(A sine wave)]
다른 극단적인 경우는 오라클을 전혀 갖지 않는 것이다. 실행 중에 수천 또는 수백만 개의 테스트 값을 SUT에 보내지만 “시스템 크래시가 발생하지 않았다(또는 테스터의 눈에 띄는 문제가 없었다)”는 것을 제외하면 딱히 확인하는게 없는 자동 테스트를 우리가 종종 목격할 수 있는데, 이 경우가 여기에 해당한다. 당연히 비용은 적게 들지만 유용성이 거의 없다(테스트 동안 SUT에서 오는 반응이 정확한지 여부를 판단하는데 아무런 도움이 되지 않음)
휴리스틱(경험적) 오라클은 느리고, 비싸고, 방대한 결과 생성의 트루 오라클과 검증되지 않은 SUT 결과(노 오라클) 사이의 합리적인 대안을 제공하며, 특히 SUT의 입력값과 결과값 사이에 예측 가능한 관계가 존재할 때 사용하기에 적절한 방법이다. 사인 함수의 경우 휴리스틱에 사용되는 예측 가능한 관계는 “함수가 0도에서 90도까지는 증가하고, 90도에서 270도까지는 감소하며, 이후 360도까지 다시 증가한다”는 사실이다. 즉, 34도의 정확한 사인 값은 예측하기 어렵지만 그것이 33도의 값보다 크고 35도의 값보다는 작다는 점은 쉽게 체크할 수 있다. 또한 일부 예측하기 쉬운 사인 값들도 존재한다. sin(0)=0, sin(90도)=1, sin(180도)=0, sin(270도)=-1의 4개 값을 정확하게 예측할 수 있으며, 따라서 이것들의 정확한 결과값을 테스트에서 체크할 수 있다.
휴리스틱 오라클은 트루 오라클에 비해 구현이 쉽고 훨씬 빠르게 실행된다. 사인 함수의 휴리스틱 오라클은 아래 그림이 나타내는 잘못 구현된 사인 함수를 식별할 수 있다.
하지만 휴리스틱이 적용하는 일반적인 규칙이 실제 문제를 발견하지 못할 수도 있음을 명심해야 한다. 예를 들어, 사인 예의 휴리스틱 오라클은 아래 그림 같은 함수가 테스트를 통과(pass)한 것으로 잘못 판단한다(네 개의 확인 지점의 값이 정확하고, 확인 영역에서 함수가 알맞게 증가하거나 감소하므로 휴리스틱 오라클이 오류를 잡아내지 못함). 중요한 포인트는 현실에서 프로그래머가 사인 함수를 이렇게 톱니 함수로 잘못 구현할 가능성이 낮다는 점이다.
휴리스틱 오라클의 또 다른 예
휴리스틱 오라클이 수학 함수(Math functions)에만 유용한 것은 아니며, 아래 소개하는 두 개의 데이터베이스 애플리케이션도 휴리스틱 오라클을 사용하여 자동화된 테스팅의 현실적인 제약을 극복하였다.
사례 1
상용 관계형 데이터베이스 시스템을 생산하는 한 소프트웨어 회사에서 엄청난 수의 트랜잭션을 가진 대규모 데이터베이스를 필요로 했고, 이 자동화된 테스트의 결과 검증을 위해서는 복잡한 상호연결성을 가진 많은 이진 파일을 꼼꼼히 살펴보고 모든 데이터 값과 상호연결의 정확성을 검증하는 일이 요구되었음. 이 작업은 수십 년이 걸릴 수도 있는 일이지만, 관계에 기반한 휴리스틱을 적용함으로써 대부분의 데이터베이스 결과를 자동 검증하는 오라클을 작성할 수 있었음. 예를 들어, 송장번호(Invoice Number) 같은 자동 생성 필드는 생성 날짜/시간에 상응하므로, 검색 결과가 날짜/시간별로 정렬될 때 오름차순(또는 내림차순) 송장번호가 나와야 함.
사례 2
또 다른 회사에서는 데이터베이스를 테스팅하는데 있어서 가장 큰 어려움으로 데이터셋의 방대한 크기와 동적 업데이트가 꼽혔다. 각각 5~30GB에 달하는 200개의 온라인 데이터 베이스에서 적당한 테스트셋을 복제(duplicate)하는 것이 현실적이지 않기 때문에 테스팅이 라이브 데이터 상에서 수행되어야만 했으며, 각 레코드 내의 데이터도 수천 자(characters)에서 수 메가 바이트까지 다양하여 완전한 레코드 비교가 비현실적이었다. 또한 라이브 데이터베이스의 데이터 콘텐츠가 매일같이 수정되므로 어떤 쿼리에 대해 얼마나 많은 응답이 있을지 미리 알기가 어려웠다.
하지만 구 레코드가 데이터베이스에서 삭제되는 일이 없다는 사실과 각 테스트의 작성 시점을 알고 있으므로 검색 결과를 테스트 이전의 레코드(알려진 레코드)와 이후의 레코드(테스트가 예측할 수 없는 레코드)의 두 집합으로 구분하였다. 첫 번째 집합은 그 크기가 올바른지(잘못하여 삭제된 레코드가 없음)와 각 레코드에 특정 값이 등장하는지를 체크하였다. 즉, 이 레코드에 대해 알고 있기 때문에 해당 레코드에 고유하고 신규 레코드에는 등장하지 않을만한 정보를 선택할 수 있었다. 두 번째 집합에 대해서는 검색 기준이 충족되었는지 같은 약한 휴리스틱만을 적용할 수 있었다. 그리고 양쪽 모두의 경우, 리턴된 레코드가 검색 기준에 부합하는지를 체크할 뿐이지 일치하는 모든 레코드(all matching records)가 반환되었는지 여부는 확인할 수 없었다.