소프트웨어 테스팅 노트

출처: 책 Software Testing: Testing Across the Entire Software Development Life Cycle, by G. D. Everett and R. McLeod, Jr., 2007년

7장 Functional Testing, 110~112, 117~119페이지

테스터의 경험으로 알게 된, 문제가 생기기 쉬운 소프트웨어 측면에 대해 설명한다.

7.5.6 직관과 경험 – 화이트박스 테스팅에서

이 섹션은 숙련된 테스터가 보기에 코딩에서 골치 아픈 영역이자 공식적인 디버깅 및 테스팅 기술이 놓치기 쉬운 소프트웨어 측면을 논한다.

7.5.6.1 날짜(Dates)

날짜 데이터는 개발자에게 유효 포맷(valid formats), 정렬 순서(sort sequence), 계산(calculations)이라는 세 가지 고유한 문제를 제기한다. 날짜 포맷 mm/dd/yyyy은 yyyy(연도)에 따라 각 mm(월)에 대해 dd(일)의 특정 범위의 값이 있기 때문에 문제의 소지가 있다(윤년 같은 경우). 컴퓨터 시스템이 세기 경계를 넘으면서 mm 대 dd 대 yyyy의 검증이 여전히 복잡하고 더욱 증가하였다(악명 높은 Y2K 문제). 인터넷의 글로벌 특성으로 인해 소프트웨어는 다양한 날짜 입력 포맷을 지원하게 되었다. 예를 들어 미국 날짜 표준은 mm/dd/yyyy인 반면 영국 날짜 표준은 dd/mm/yyyy이다. mm으로 표시되는 월의 철자 또는 약어까지 고려하면 날짜 입력 포맷이 상당히 도전적인 코딩 과제가 된다.

날짜 정렬 순서도 중요한 애플리케이션 문제가 될 수 있다. 애플리케이션이 레코드를 날짜 순서(오름차순 또는 내림차순)로 유지하려는 경우, 애플리케이션은 연도가 1차 정렬 키, 월이 2차 정렬 키, 일이 3차 정렬 키가 되도록 입력 날짜를 yyyy/mm/dd 정렬 포맷으로 변환해야 한다.

정렬 포맷과 보고서 포맷 간에 날짜를 왔다 갔다 변환하는 또 다른 방법은 과거의 어떤 날짜를 "기준일(anchor date)"로 잡고 그 이후 경과된 일 수를 계산하는 것이다. 만약 데이터가 역사적으로 오래된 것이라면 시스템은 그레고리력과 윤년의 도래인 1582년 10월 15일과 같은 아주 오래된 기준일을 선택한다. 데이터가 한두 세기에 걸쳐 있는 경우에는 1800년 1월 1일이 적절한 기준일이 될 수 있다. 그런 다음 모든 날짜는 디스플레이 포맷과 기준일 이후 경과된 일 수라는 두 가지 포맷으로 정렬된다. 경과 일 수는 관리하기 훨씬 간단한 정렬 키가 된다(즉, 양의 정수). 이러한 경과 일 수 계산 및 저장의 두 번째 장점은 "날짜 + x일", "날짜 - y일" 또는 요일(월요일, 화요일 등)을 쉽게 계산할 수 있는 데이터 구조를 갖는다는 것이다.

이러한 날짜 계산은 모두 날짜 프로세싱 오류/실패의 원인이 될 수 있다. 테스터는 소프트웨어 입출력 설계, 파일 설계, 데이터베이스 설계에 날짜 및 날짜 계산이 포함된 위치를 식별하고 이해하기 위해 개발자와 협력하여 대부분의 날짜 테스트를 계획하고 실행할 수 있다.

7.5.6.2 길이가 0인 모든 것(Zero Length Anything)

제로 데이터, 개수, 또는 처리 단계를 생성할 수 있는 여러 프로그래밍 상황이 있다. 예를 들면 다음과 같은 것들이다.

• 배열(arrays)
• 빈 입력(blank inputs)
• 0으로 나누기(divide by zero)
• 루프(loops)
• 포인터(pointers)
• 레코드 길이(record lengths)
• 레코드(빈 파일)
• 정렬(sorts)

이러한 제로 항목 중 상당수는 데이터를 제공하지 않은 채 "전송(send)" 키를 눌러 강제할 수 있다. 또한 계산이 존재하는 곳에서 입력 값의 일부 또는 전체에 대해 공백(blank)이나 0을 입력하면 이러한 동작이 강제로 수행된다. 보다 구체적인 테스트에서는 제로의 원인이 되는 소프트웨어의 다른 잠재적인 영역을 식별하기 위해 개발자와의 협력이 필요할 수 있다.

7.5.6.3 버퍼 오버플로(Buffer Overflow)

버퍼 오버플로는 소프트웨어가 비교적 사용량이 많아질 때까지 그 존재를 드러내지 않기 때문에 특히나 음험한 프로그래밍 문제이다. 이 문제는 사용자 입력, 보고서 출력, 데이터베이스 레코드, 인터넷 패킷과 같은 임시 데이터(transient data)를 관리하기 위해 ‘버퍼’라고 불리는 메모리 영역을 별도로 확보할 때 발생한다. 해당 버퍼 영역이 데이터로 가득 차면 버퍼의 일부를 비워서 더 많은 데이터를 수용할 수 있는 작업이 발생한다. 일부 리필 전략에서는 더 많은 데이터를 수용하기 전에 가득 찬 버퍼를 완전히 비워야 한다고 규정한다. 다른 리필 전략은 버퍼 주위에 데이터를 래핑하여 포함된 데이터를 비우는 동시에 더 많은 데이터를 수용한다. 따라서 버퍼가 그 영역을 초과할 때 다양한 방식으로 버퍼를 채우고 비울 수 있다. 이는 버퍼 오버플로 에러를 반복하는 것을 매우 어렵게 만든다.

버퍼 오버플로의 증상은 그 이벤트 자체만큼 음험한 데, 버퍼가 오버플로되면 컴퓨터 메모리의 인접 영역을 덮어쓰기 때문이다. 해당 인접 영역에 데이터가 포함되어 있으면 뚜렷한 이유 없이 이 데이터가 손상된다. 인접한 영역에 인스트럭션(instructions)이 포함되어 있으면 정상적인 조건에서는 완벽하게 올바른 코드였던 소프트웨어가 이상 동작을 시작할 수 있다. 많은 컴퓨터 바이러스가 소프트웨어 인스트럭션에 버퍼 오버플로를 강제하여 유입된다는 사실을 깨달으면 버퍼 오버플로 문제는 더 높은 수준의 테스트 중요성을 띄게 된다.

버퍼 오버플로를 테스트하는 가장 효과적인 방법 중 하나는 대량의 입력 데이터로 소프트웨어를 구동하고, 대량의 내부 파일 프로세싱 또는 데이터베이스 프로세싱을 강제하고, 특정 버퍼 영역에 대해 대량의 출력을 강제하는 것이다. 날짜 계산 상황에서와 마찬가지로 테스트해야 하는 특정 버퍼에 의존하는 특정 입력, 출력, 파일 프로세싱, 데이터베이스 프로세싱을 식별하기 위해서 테스터는 개발자와 협력해야 한다. 오버플로를 유발하는 데 필요한 버퍼 트래픽의 양을 얻기 위해 버퍼 오버플로 화이트박스 테스팅 중 일부를 9장에 설명하는 성능 블랙박스 테스팅과 결합하는 것이 합리적일 수 있다.

7.6.4 직관과 경험 – 블랙박스 테스팅에서

이 섹션에서는 테스터가 반복적인 경험을 통해 발견한, 공식적인 동적 테스팅에서 놓치기 쉬운 고질적인 소프트웨어 측면에 대해 다룬다.

7.6.4.1 에러 핸들링(Error Handling)

에러 핸들링은 단연코 개발하기 복잡하고 부담스러운 프로그래밍이다. 에러 핸들링은 예상치 못한 상황에 대해 예상하고 자연스럽게 에러 이전 상태로 복구해야 한다. 에러 핸들링에서 프로그래머는 먼저 데이터 또는 프로세싱 에러가 발생했음을 감지해야 한다. 이어서 프로그래머는 최종 사용자에게 상황을 올바르게 경고해야 한다. 마지막으로 프로그래머는 에러로부터 데이터와 프로세싱을 모두 올바르게 복구하고 최종 사용자가 오류 없이 작업을 계속할 수 있도록 해야 한다.

에러 복구 코드가 얼마나 풍족한지는 프로그래머가 유사한 종류의 애플리케이션이나 지원 기술의 최종 사용자를 얼마나 접해 본 경험이 있는지에 일부 달려 있다. 에러 복구 테스팅이 얼마나 풍족하지는 테스터가 (애플리케이션이나 지원 기술에 관계없이) 잘 작동하지 않는 에러 복구 기법을 얼마나 접해본 경험이 있는지에 일부 달려 있다.

이상적인 개발 프로젝트에서는 프로그래머가 최종 사용자가 마주할 수 있는 단일의 에러 목록을 유지관리한다. 이 목록에는 다음과 같은 항목이 포함된다.

애플리케이션 X의 메시지 목록 내용

• 고유한 에러 코드/ID
• 에러 메시지 텍스트
• 에러 설명
• 에러 조건을 감지하는 코드 모듈
• 발생한 에러의 심각도(I: 정보 제공, W: 경고, A: 현재 활동을 중단하고 에러 이전 작업으로 복구를 시도)
• 요구되는 사용자 액션
• 요구되는 애플리케이션 액션
• 데이터 손실 가능성

이러한 목록은 100% 에러 핸들링 확인(validation)을 계획하기 위한 기초가 된다. 테스팅의 과제는 필요할 때마다 이러한 에러를 반복적으로 발생시켜야 하는 것이다.

슬픈 현실은 많은 개발 프로젝트에서 프로그래머가 에러 메시지 정보의 대부분을 소스 코드에 박아 넣는 것이 허용된다는 점이다. 에러 핸들링 정보를 소스 코드 전반에 걸쳐 분산시키는 관행이 인터넷 애플리케이션에서 매우 만연하다 보니, 소프트웨어 공급업체들이 애플리케이션의 모든 에러 메시지를 찾고 목록을 작성하는 역공학(reverse engineering) 도구를 제공하는 틈새 시장을 발견했을 정도이다. 테스팅의 과제는 역공학에 의해 식별된 에러 메시지 각각이 어떤 상황에서 나타날 수 있는지를 확인하는 것이다.

7.6.4.2 데이터 타입 전환(Data Type Conversions)

사용자 입력이 한 데이터 타입에서 다른 데이터 타입으로 전환될 때마다(예: 알파벳에서 숫자로) 전환이 잘못되거나 실패할 가능성이 있다. 새 애플리케이션 개발에 사용된 프로그래밍 언어에 따라 전환 실패가 무해한 리턴 코드(애플리케이션이 가로채서 해석할 수 있는 코드)부터 악성적인 실행 중단(execution halts)까지 다양한 실행 응답을 발생시킬 수 있다. 실패한 전환의 당연한 귀결은 잘못된 전환(예, 엄밀한 숫자 필드에 알파벳)이 시도되기 전에 이를 식별할 수 있는 애플리케이션의 능력이다.

테스터의 과제는 데이터 타입에 민감한 입력 및 출력 필드를 식별하고 그 정확성과 견고성을 검증하기 위한 실행 테스트를 설계하는 것이다. 이러한 테스트 계획의 주요 소스는 모든 입력 필드 데이터 타입에 대한 제한을 설명하도록 되어 있는 사용자 가이드이다.

7.6.4.3 날짜(Dates)

위 화이트박스 테스팅 섹션에서 날짜 포맷과 날짜 계산의 복잡성에 대해 논의했다. 날짜가 블랙박스 테스팅 토론에서 다시 등장하는 데, 사용자가 관찰할 수 있고 테스터가 소스 코드 없이도 테스트할 수 있는 날짜 동작(date behavior)이 존재하기 때문이다. 이러한 날짜는 통상적으로 데이터 입력 화면, 정보 검색 기준, 보고서 등에 나타난다. 사용자 가이드는 사용자가 직접 제어하고 눈으로 보는 날짜 관련 예상 동작에 대해 알 수 있는 최고의 소스이다. 테스터가 사용자 프로필 같은 곳에서 날짜 포맷 선택(예: mm/dd/yyyy, dd/mm/yyyy, Month, yyyyy 등)을 알아내는 상황이 될 수도 있다. 따라서 테스터는 소프트웨어에서 날짜가 사용되는 모든 위치에서 디폴트 날짜 포맷과 선택 가능한 다른 모든 날짜 포맷을 테스트해야 한다.

위 항목들과 관련된 실제 결함 사례(아래 링크 클릭)

날짜 관련 버그

• 2012년 2월 호주 의료 지불 시스템의 윤일 버그
• 2010년 애플 아이폰 알람 버그
• 2010년 호주 퀸즈랜드 은행의 EFTPOS 단말기 Y2.01k 버그
• 2010년 독일 은행 카드 Y2.01K 버그
• 미공군 F-22 Raptor의 소프트웨어 문제 관련 사고

제로(0) 관련 버그

• 1997년 미해군 전함 USS Yorktown의 ‘0으로 나누기’ 에러

버퍼 오버플로 관련 버그

• 1995년 독일 철도 Hamburg-Altona 역의 철로 스위치 시스템 장애

에러(또는 예외) 핸들링 관련 버그

• 2014년 12월 영국 항공 교통 관제 시스템 장애

데이터 타입 전환 관련 버그

• 1991년 미육군 MIM-104 패트리어트 미사일 소프트웨어의 숫자 전환 라운드오프 에러
• 1996년 숫자 전환 버그로 인한 Ariane 5 로켓 폭발 사고
• 2009년 7월 미국 VISA 카드의 17-자리수 사용 금액 에러