책 요약정리 – 웹 애플리케이션의 테스팅 분석 사례 by Nguyen

출처: Testing Applications on the Web, 저자 Hung Q. Nguyen, 2001년

5장 웹 애플리케이션 컴포넌트(Web Application Components), 103~111 페이지

 

샘플 웹 애플리케이션(웹 기반 결함 추적 시스템)의 한 기능을 예로 들어 테스팅 계획/설계를 목적으로 테스터가 분석을 수행하는 사례를 보여준다.

---

보통 테스터는 워크쓰루 동안 개발자로부터 애플리케이션의 아키텍쳐에 대해 배우게 된다. 또 다른 접근법은 테스터가 컴포넌트 간 통신 트래픽을 추적하여 자체 분석을 수행하는 것인데, 테스터로써 어떤 유형의 오류를 찾아야 하고 어떤 질문을 던져야 하는지 알려면 일반적인 웹 기반 애플리케이션 아키텍처를 컴포넌트 수준에서 확실히 파악하고 있어야 한다.

 

샘플 웹 애플리케이션

샘플 웹 애플리케이션(웹 기반 결함 추적 시스템)에서 그래픽 차트 생성이 아래와 같은 트랜잭션 프로세스를 거친다.

• 사용자가 지난 5일간 일별 오픈/클로즈 버그 수를 비교한 추세도(trend chart)를 요청한다(리퀘스트 제출).
• 웹 서버가 trend.asp라는 이름의 파일을 요청한다.
• 프로세싱을 하기 위하여 trend.dll을 호출한다.
• trend.dll이 데이터베이스 서버와 연결하고, 요청된 데이터를 꺼내기 위하여 sp_trend라는 이름의 저장 프로시저(stored procedure)를 호출한다.
• trend.dll이 요청된 데이터를 받고 나면 plot.dll을 호출하여 데이터를 넘겨준다. plot.dll은 추세도 작성 준비를 위해 sp_trend가 반환한 원천(raw) 데이터를 계산 및 포맷팅하는 책임을 진다.
• 포맷화된 데이터는 쉼표 구분 형식(comma-delimited format)으로 data.tmp라는 이름의 파일에 쓰여진다.
• data.tmp 파일명으로 제3자 Java charting 컴포넌트를 요청하여 라인 차트를 작성한다.
• Java 애플릿(applet)이 클라이언트로 전송되고 data.tmp는 삭제된다.
• 사용자 브라우저에 Java 애플릿이 로드(load)되고 적절한 데이터를 담은 추세도가 작성된다.

 

테스트케이스 설계를 위한 분석

테스터는 프로그램 로직과 컴포넌트 아키텍쳐를 분석하여 잠재적인 문제/이슈들을 식별하고 이를 기반으로 테스트케이스를 설계한다(잠재적인 문제로 인해 가능한 결함/에러를 드러내려는 노력).

 

리퀘스트 제출

• 입력 데이터가 유효하지 않으면 어떻게 되나?
  만약 에러 핸들링 코드가 있다면, 이 에러 핸들링 로직을 테스트하는 테스트케이스를 고안해야 함. 또한 에러가 클라이언트쪽에서 처리되는지, 서버쪽에서 처리되는지, 아니면 양쪽 모두에서 처리되는지 파악하고, 에러 핸들링이 스크립트를 통해 수행되는지 아니면 임베디드 컴포넌트를 통해 되는지도 파악해야 함
• 지난 5일간의 데이터가 너무 많은 경우 어떻게 되나?
• 지난 5일간의 데이터가 하나도 없는 경우 어떻게 되나?
• 웹 서버 앞에 방화벽이 있는 경우 어떻게 되나?

 

trend.asp 요청

• 웹 서버 환경이 ASP 실행을 허용하도록 제대로 셋업되었는가?
  서버 환경이 시스템 관리자(administrator)에 의해 수동 셋업되거나 또는 설치 프로그램/셋업 유틸리티를 통해 자동 설치될 수도 있는데, 어떤 경우든 스크립트 실행이 허용되지 않는다면 trend.asp가 실패한다.
• ASP가 암호화 될 것인가? 만일 그렇다면 그게 암호 모드에서 테스트 되었는가?
  테스트 대상 애플리케이션이 ASP 파일 암호화를 위해 제3자 기술을 사용할 수도 있는데, 비호환성(incompatbility), 성능, 시간 관련 이슈, 기타 환경 관련 이슈 등이 기능(functionality)에 영향을 줄 수 있음

 

trend.dll 호출

• trend.dll이 표준 DLL인가 아니면 COM-기반 DLL인가? 만약 COM-기반 오브젝트라면 그게 어떻게 설치되고 등록되는가?
• trend.dll이 의존하는 DLL 내보내기 함수(exported functions)는 무엇인가? 이것들 모두가 로컬 호스트와 원격 호스트 상에서 가용한가?

 

sp_trend 호출

• 애플리케이션이 데이터베이스 저장 프로시저 sp_trend를 실행하기 전에 SQL 서버와 연결할 필요가 있는데, 이 연결을 실패하게 할 만한 이슈로 무엇이 있는가?
  예를 들어, 잘못된 ID, 패스워드, 데이터 소스명 등으로 인한 인증(authentication) 에러가 나면 연결에 실패한다.  
• 데이터베이스 연결 시도가 실패하면 이 에러 조건이 어떻게 사용자에게 피드백되는가? 사용자가 암호화된 에러 메시지를 받거나 또는 전혀 에러에 대한 피드백을 받지 못할 수도 있는데, 테스트 대상 애플리케이션이 수용하는 표준은 어떤 것인가?
• 데이터베이스에 저장 프로시저가 제대로 프리컴파일되어 저장되어 있는가?
  이게 보통 설치 프로세스에서 수행되는데, 모종의 이유로 저장 프로시저가 누락되거나 컴파일되지 않는다면 이를 사용할 수 없다.
• 저장 프로시저가 반환한 데이터 셋이 정확한 것인지를 어떻게 아는가?
  차트는 정확하게 그려졌지만 저장 프로시저가 반환한 데이터 자체가 정확하지 않았을 수도 있으므로 데이터 유효성을 확인(validate) 할 수 있어야 함

 

plot.dll 호출

• 데이터가 적절한 시간 간격(일별, 주별, 월별)으로 정확하게 뿌려지는가(plotted)?
  사용자 요청에 따라 데이터가 일별, 주별, 월별로 그룹화 되는데, 이 컴포넌트를 꼼꼼히 테스트 할 필요가 있다.
• 보고서를 적절한 기간에 맞춰 채우는 인텔리전스 로직이 plot.dll에 또는 sp_trend에 존재하는가?
  이 로직 일부가 저장 프로시저에 구현되었을 수도 있으며, 따라서 그에 맞게 테스트 되어야 한다.

 

data.tmp 파일에 데이터 쓰기

• 텍스트 파일 쓰기를 할 디렉토리가 쓰기금지(write-protected)라면 어떻게 되는가?
  이게 사용자 에러 때문인지 프로그램 에러 때문인지에 상관없이 data.tmp가 해당 디렉토리에 부재하면 그래프 작성 기능이 동작 못함
• plot.dll이 잘못하여 훼손된 형식의 쉼표 구분 파일을 생성하면 어떻게 되는가?
  데이터 포맷팅 로직이 철저하게 테스트 되어야 한다.
• 다수의 사용자가 추세도를 동시에(또는 연달아) 요청하면 어떻게 되는가?
  다중 사용자 접근은 웹 애플리케이션과 클라이언트-서버 아키텍쳐를 강력하게 만드는 특징이지만 에러의 주된 근원이 되기도 한다. 다중 사용자 접근을 겨냥한 테스트케이스가 설계될 필요가 있음

 

Java charting 프로그램 호출

• 차트 작성 프로그램이 발견되지 않으면 어떻게 되는가?
  Java 애플릿이 반드시 물리적으로 어딘가에 위치해야 하며, 코드에서 이 애플릿을 요청하는 경로명이 올바른 위치를 가리켜야 한다. 애플릿을 발견 못하면 차트 작성 기능이 동작 안함
• JAR에 누락된 클래스가 있으면 어떻게 되는가?  
  Jar 파일은 특정 Java 애플리케이션이 요구하는 자바 클래스들을 담고 있는데, 하나 또는 하나 이상의 요구 클래스가 누락되면 애플리케이션이 기능 못하게 됨

 

결과를 클라이언트로 보내기(Java 애플릿과 data.tmp의 데이터를 브라우저로 전송)

• 테스트 대상 애플리케이션이 지원하는 최소 대역폭 요구사항(bandwidth requirement)은 얼마인가? 애플릿 크기는 얼마인가? 최소 대역폭 구성에서 수용가능한 성능이 나오는가?
  최소 요구 구성에서 전반적인 성능(반응 시간)을 체크하며, 또한 이 테스트를 다수 사용자(concurrent users)가 존재하는 상황에서도 실행해야 함
• temp 파일이 서버에서 제대로 삭제되는가?
  각 차트 작성 리퀘스트마다 서버에 신규 파일을 만들게 되는데, 이게 불필요하게 공간을 차지한다.

 

클라이언트쪽 컴포넌트를 포맷팅하고 실행하기

• 애플릿이 모든 지원 브라우저 및 그것의 관련 버전들과 호환되는가?
  각 브라우저는 자신의 고유한 샌드박스 버전 또는 JVM을 가지고 있으며, 반드시 다른 브라우저들과 호환되는 것은 아니다. 이 비호환성이 애플릿에 영향을 미칠 수 있다.
• 보안 세팅이, 브라우저 측에서든 또는 네트워크 방화벽에서든, 애플릿이 다운로드 되는걸 막으면 어떻게 되는가? 사용자에게 어떤 식으로든 이를 알리는가?

 

테스트 파티셔닝(Test Partitioninig)

웹 시스템 아키텍쳐의 분산된 특성을 고려할 때 테스트 파티셔닝(분할) 구현이 필수적이다. 예를 들어, 구성 및 호환성 레벨에서 테스트 대상 애플리케이션이 마이크로소프트 IIS 3.0, 4.0, 5.0과 MS-SQL 6.5, 7.0을 요구한다면 구성 관련 아래와 같은 테스트 매트릭스가 나올 수 있다.

성능 관련해서는 테스터가 SQL 6.5를 SQL 7.0과 비교하고자 한다면 테스트 매트릭스가 아래와 같이 구성된다.

 

아래와 같이 개념적 레벨에 따른 테스팅 분할도 가능하다.

• 상위 레벨 파티셔닝: 테스트의 목표가 서버 측 응답 시간을 측정하는 것이라면 인터넷, 방화벽, 프록시 서버 등을 통해 데이터를 실행할 필요가 없다. 부하 테스트 도구 사용 시 부하 생성기를 웹 서버와 직접 연결해 성능 데이터를 수집하도록 설정할 수 있다.
• 물리적 서버 파티셔닝: 테스트의 목표가 박스(머신) 별 성능을 측정하는 것이라면 각 물리적 서버를 독립적으로 부하 생성기와 연결해 성능 데이터를 수집 할 수 있다.
• 서비스 기반 파티셔닝: 테스트의 목표가 데이터 애플리케이션의 기능과 애플리케이션에 서비스를 제공하는 데이터베이스 서버의 전반적 성능을 테스트하는 것이라면, 테스트가 데이터베이스 서버에 집중된다.
• 애플리케이션/컴포넌트 기반 파티셔닝: 이러한 테스트의 초점은 위 차트 작성 예에서 설명한대로 컴포넌트 레벨에 있다.

 

테스팅 고려사항

• 테스트 대상 시스템의 서버 하드웨어 요구사항을 파악한다. 지원하는 구성에 대한 매트릭스를 생성하고 이 구성들이 반드시 테스트 되도록 한다.
• 서버의 소프트웨어 컴포넌트 요구사항(예, 웹 서버, 데이터베이스 서버, 검색 서버, 프록시 서버, 통신 서버, 애플리케이션 서버, 이커머스 서버, 멀티미디어 서버)을 파악하고, 에러를 찾기 위한 상호운용성 테스트(interoperability tests)를 설계한다.
• 서버 소프트웨어 컴포넌트가 어떻게 분산되어 있는지 파악하고, 에러를 찾기 위한 상호운용성 테스트를 설계한다.
• 서버 소프트웨어 컴포넌트가 어떻게 서로 상호작용하는지 파악하고, 에러를 찾기 위한 상호운용성 테스트를 설계한다.
• 웹과 데이터베이스 간의 연결(Web-to-database connectivity)이 어떻게 구현되었는지 파악하고(예, CGI, NSAPI/ISAPI, ASP, 또는 기타 기술), 에러를 찾기 위한 상호운용성 테스트를 설계한다.
• 하드웨어/소프트웨어 호환성(compatibility) 이슈를 식별하고 이러한 에러 클래스를 겨냥한 테스트를 한다.
• 프로세싱이 클라이언트와 서버 간 어떻게 분배되었는지 파악한다(thin 클라이언트 대 thick 클라이언트).
• 테스트 파티셔닝은 시스템 조각들을 개별적으로 또는 조합하여 테스트하는 방식인데, 특히 커뮤니케이션 이슈가 있는 웹 시스템 테스팅에서 적절하다. 웹 시스템이 여러 컴포넌트를 포함하기 때문에 이것들 전체를 한꺼번에 테스트하는 일은 쉽지도 않고 일찍 버그를 발견하는데 효과적이지도 않다.
• 웹 애플리케이션의 클라이언트 측을 구성하는 컴포넌트(예, 브라우저 컴포넌트, 정적 HTML 요소, 동적 HTML 요소, 스크립팅 기술, 컴포넌트 기술, 플러그인 등)를 중심으로 테스트케이스를 설계한다.
• 통합 테스팅과 테스트 파티셔닝을 평가하는 한 가지 방법은 애플리케이션 컴포넌트가 어디에 상주하고 실행되는지를 확인하는 것이다. 컴포넌트가 클라이언트 컴퓨터 상에 위치할 수도 있고 또는 하나 이상의 서버 컴퓨터에 올라가 있을 수도 있다.