문서요약 - 웹사이트 테스팅 모범 사례 by Stout

제목: 웹사이트 테스팅 모범 사례(Testing a Website: Best Practices)

저자: Glenn A. Stout, 미국

문서유형: 기술 문서(총 14페이지), 2001년

 

웹사이트(또는 웹애플리케이션) 테스팅의 고유한 영역과 바람직한 관행을 기술한 자료

---

정적 테스팅(Static Testing)

변하지 않거나 트랜잭션 기반이 아닌 웹브라우저의 오브젝트를 테스팅하는 것을 의미하며, 이런 타입의 테스팅은 웹브라우저로 이미 로드된 웹페이지 상에서 수행된다. 아래와 같이 여러 타입의 정적 테스팅이 존재한다.

• 콘텐츠 체킹(Content Checking): 일단 웹페이지가 로드되면 이를 정확성(accuracy), 완전성(completeness), 일관성(consistency), 철자(spelling), 접근성(accessibility) 측면에서 테스트. 이는 방문자의 웹사이트에 대한 판단에 가장 먼저 영향을 주는 측면들임
• 브라우저 신택스 호환성(Browser Syntax Compatibility): 실제 콘텐츠 보다 한 단계 아래의 테스트. 텍스트, 그래픽, 다른 웹오브젝트로 구성된 콘텐츠의 표현 기술이 관심의 대상임. 테스트 대상 페이지가 다양한 브라우저(또는 버전)에서 작동되는지 여부를 결정하는 테스트. 즉, 지원하는 브라우저 각각에서 웹페이지가 테스트될 필요가 있음
• 가시적 브라우저 확인(Visual Browser Validation): 사용된 브라우저와 상관없이 콘텐츠가 동일하게 눈에 보이는지를 확인(애플리케이션이 단지 한 개의 브라우저와 버전만 지원한다면 필수적이지 않은 테스트). 동일 브라우저라도 하나 이상의 버전이 지원되면 테스트 대상 페이지를 각기 다른 버전에 로드하고 페이지 오브젝트들의 물리적 모습에 차이(예, 오브젝트의 센터링, 테이블 레이아웃 등)가 있는지 가시적으로 체크해야 함

시험 브라우징(Test Browsing)

• 웹페이지 네비게이션과 관련된 결함을 찾는 것인 목적인 테스트(링크된 페이지나 오브젝트의 가용성, 개별 페이지의 다운로드 속도를 포함)
• 올바른 컴포넌트가 올바른 페이지로부터 호출되는지를 확인하기 위해 웹페이지의 서버 기반 컴포넌트로의 통합도 테스트됨
• 링크(links)들을 탐색하거나 새 페이지를 열 때 매 페이지마다 아래 질문들을 던지고 어떤 것이라도 답이 부정적이면 결함으로 여김
  - 이 페이지가 다운로드 될 수 있고 디스플레이 될 수 있는가
  - 모든 오브젝트가 합당한(비즈니스 요구사항에 비추어 합당) 시간 내에 로드되는가
  - 사용자가 브라우져 옵션을 “images-load”에서 “off”로 변경해도 페이지가 여전히 동작하는가
  - 모든 텍스트 링크와 그래픽 링크가 동작하는가
• JavaScript나 Java가 비활성화(disabled)되거나 또는 특정 플러그인이 로드되지 않았을 때에도 사이트가 여전히 동작하는지도 확인해야 할 이슈

기능 테스팅(Functional Testing)

• 브라우저-페이지 테스트(Browser-Page Tests): 브라우저 내에서 실행되며 서버 기반 컴포넌트는 실행시키지 않는 오브젝트와 코드를 커버하는 테스트(예, 롤오버를 하는 HTML 내의 JavaScript나 VBScript 코드). 이 타입의 테스트는 HTML 레벨에서 수행되는 필드 확인(field validations)을 포함하고 또한 화면 기능(screen functionality)이나 그래픽한 출력을 구현한 Java applets도 포함한다.
• 트랜잭션 테스팅(Transaction Testing): 직접 및 간접 인터페이스가 정확하게 동작하는지 확인하기 위해 다양한 컴포넌트가 호출되도록 설계된 테스트. 이런 인터페이스로 컴포넌트간 콘트롤 전이, 컴포넌트간 데이터 전이(양방향), 여러 컴포넌트에 걸친 데이터 사용의 일관성이 있다. 테스트 케이스는 웹페이지 레벨에서 사용자에 의해 입력된 정보가 데이터베이스로 적절하게 들어가고 웹페이지로부터 데이터베이스 호출이 있을 때는 적절한 데이터가 사용자에게 반환되는지를 확인한다.

비기능 테스팅(Non-Functional Testing)

1. 구성 테스팅(Configuration Testing):

• 브라우저 확인(browser validation)을 넘어서 사용된 운영체제 플랫폼, 네트워크 연결 타입, 인터넷 서비스 제공자 타입, 브라우저(버전 포함)를 고려하는 테스트
• 이런 구성과 관련된 요구사항과 가정이 개발팀에 의해 이해되고 테스트 환경으로 설정되어 제대로 테스트 되는지가 중요

2. 사용성(Usability)

• 사용성에 대해서는 테스트가 주관적일 수 있지만 업계 전반에 거쳐 확립된 표준과 가이드라인이 존재함. 하지만 프로젝트가 HCI 표준과 가이드라인을 따랐다고 해서 사용자의 요구를 충족시키는 쓸만한 웹사이트가 자동으로 생성되는 것은 아님
• 설계 가이드라인을 확립하는 동시에 사용성에 대한 식별 및 측정이 가능한 요구사항을 정의해야 함. 예를 들면, 습득용이성(learnability), 이해용이성(understandability), 운영용이성(operability) 등의 의미를 테스트 가능한 형식으로 구체화하고 정량화 한다.

3. 성능(Performance)

• 시스템이 성능 요구사항을 충족하는지 확인하는 테스팅 예) 웹페이지가 8초 이내에 로드되는가, 웹페이지를 8초 이내에 로드하는 동시에 시스템이 분당 10,000건의 트랜잭션을 처리할 수 있는가 등
• 성능 테스팅을 위해서는 성능 요구사항이 구체적이고 검증가능한 형식으로 명시되어야 함. 예) 처리량(throughput), 사용자 수에 따른 응답시간(response time) 등으로 기술
• 성능 테스팅을 대비하여 서버 모니터링이 가능하게 만드는 것이 중요함(특히 웹페이지 생성을 책임지는 서버 상에서). 또한 테스트 데이터베이스가 적절한 양의 데이터를 가지도록 계획하는 것도 중요
• 성능 테스팅에서는 테스트 서버가 생산/운영 서버(production server)와 동일한지가 중요. 모든 컴포넌트(네트워크, 방화벽, 서버, 메인프레임)가 생산 장비와 매치되어야 함. 또한 테스트 머신과 생산 머신이 동일하거나 적어도 비슷한 수준의 데이터를 가지도록 해야 실제 조건에서 애플리케이션이 어떻게 동작하는지 테스터가 확인할 수 있다.
• 성능 테스팅은 브라우저의 “window”를 통해 수행되거나 또는 서버상에서 직접 수행될 수 있다. 서버상에서 수행되는 경우는 브라우저가 차지하는 일부 성능 시간이 포함되지 않음을 프로젝트 구성원과 사용자가 이해하고 있어야 한다.

성능 테스트 케이스를 생성하는 전형적인 단계가 아래와 같다.

• 시스템의 전반 성능에 직접적인 영향을 미치는 소프트웨어 프로세스를 식별한다.
• 식별된 프로세스 각각에 대해 시스템 성능에 영향을 미치는 필수 입력 패러미터만을 식별한다.
• 과거 사용에 기반하여 패러미터의 현실적인 값을 결정하고 사용 시나리오(usage scenarios)를 생성한다. 이 때 평균 부하 시나리오와 과부하 시나리오 둘 다를 포함하며, 관측창(window of observation)도 결정한다.
• 패러미터 값의 기반이 되어줄 과거 데이터가 없는 경우, 요구사항이나 이전 버전 또는 유사한 시스템에 기반한 추정치를 사용한다.
• 추정치들이 한 범위(range)를 형성하는 패러미터가 있다면 시스템의 성능에 대한 유용한 정보를 드러낼 가능성이 높은 값을 선정한다. 각각의 값이 별개의 테스트 케이스로 만들어져야 한다.

4. 확장성(Scalability)

• 확장성은 최종사용자에게 적절한 응답시간을 보장하면서 요구되는 동시사용자/동시트랜잭션의 수를 지원할 수 있는 웹애플리케이션의 능력으로 정의됨
• 확장성을 테스팅할 때 테스트 대상 서버의 구성(configuration)이 매우 중요함. 모든 로깅 레벨, 서버 타임아웃 등이 생산/운영 환경(production environment)과 동일하게 구성되어야 함. 이상적 상황에서는 글로벌 변수의 작은 변경만을 거쳐 모든 구성 파일(configuration files)이 테스트 환경으로부터 생산 환경으로 간단하게 복사된다.
• 확장성을 테스트 하기 위해서는 웹 트래픽 로드가 반드시 결정되어야 한다(확장성 임계치 요구사항을 알기 위한 목적). 이를 위해 기존 웹사이트가 있으면 기존 트래픽 레벨을 사용하거나, 아니면 사용자 로드(load)가 어떻게 시스템에 진입하는지 시뮬레이션 하는 대표적 알고리즘(예, exponential, constant, Poisson)을 선택하여 활용한다. 

5. 보안(Security)

보안 테스트는 e-commerce 웹사이트의 중요한 부분으로 아래와 같은 이슈가 존재한다.

• 데이터 수집(Data Collection): 웹사이트는 로그 파일에 있는 데이터와 사용자가 웹사이트 입력 양식을 통해 공급하는 데이터를 수집함. 웹서버는 사용자가 디렉토리를 둘러보고 파일명을 알게 되는 것이 불가능하도록 설정되어야 한다. 예를 들어, www.example.com/data가 해당 폴더에 있는 파일을 나열하지 않아야 함. 또한 데이터가 내적으로 보호되어 인가되지 않은 직원은 접근이 불가능 해야 한다.
• Get vs. Post: 사용자가 웹양식(web form)을 제출 시 웹페이지로부터 정보가 수집될 수 있는 방법으로 GET과 POST가 있음. GET은 URL(Uniform Resource Locator)에 있는 민감할 수도 있는 일부 정보를 보여주지만 POST는 그렇지 않음. 따라서 프로젝트 초기부터 개발자가 가능하면 POST 명령어를 사용하도록 장려해야 함. GET 명령어 사용 시에는 민감한 정보가 URL에 위치함으로 인한 “정보 누출”이 없음을 확실히 하기 위해 테스팅에서 URL을 체크 함
• Cookies: 쿠키는 사용자의 신분(identity)을 식별하는 웹사이트 방문자 시스템에 위치하는 텍스트 파일(사용자가 사이트를 나중에 다시 방문할 때 꺼내어 참고함). 아래 사항들을 체크할 필요가 있다
  - 사용자가 쿠키를 수락하지 않을 때 사이트가 여전히 동작하는가?
  - 쿠키가 필수적인가? 쿠키 사용 시 경고 메시지가 나오도록 브라우저가 설정될 수 있음. 사용자의 사이트 방문 시 분별 없이 많은 쿠키 사용으로 인해 화면에 경고 박스가 넘치게 되면 사용자가 해당 사이트를 다시 방문하는 것을 꺼리게 될 수 있음
  - 쿠키에 민감한 정보가 있는가? 여러 사람이 워크스테이션을 사용하는 경우 첫 번째 사용자의 방문 시 저장된 민감한 정보가 두 번째 사용자에게 노출 될 수 있음. 따라서 쿠키의 정보는 코드화 또는 암호화되어야 한다.

테스팅 환경(Testing Environments)

• 적절한 테스팅 환경 사용은 항상 중요한 테스팅 관심사이지만 웹테스팅에서는 특히 중요함
• 별도의 테스트 환경을 확보하는 것이 중요. 전체 프로젝트를 위해 최소 3개의 환경(개발팀을 위한 개발 서버, 신규 릴리즈로 주기적으로 업데이트 되는 테스트 서버, 생산 서버)이 제안됨. 이 경우 테스트 서버가 다운되어도 개발 환경과 생산 환경은 영향을 받지 않는다.
• 테스트 환경은 생산 환경과 동일하고 또한 생산 환경으로부터 완전히 독립적이어야 함

자동 테스팅(Automated Testing)

• 자동 테스트 스크립트 생성과 관련하여 개발팀과 협업을 고려할 수 있음(개발자가 자신의 테스트를 자동화하는 것을 돕고 테스트팀의 스크립트 자동화에 개발팀의 도움을 받는다). 동일한 도구가 사용된다면 일부 개발자 스크립트가 테스팅 팀으로 이전되어 회귀 테스트 셋으로 사용될 수 있음
• 링크 체킹을 자동화하기 위해 웹 대신에 파일 시스템을 통해 링크를 검증할 수 있는 링크 체커(link checker) 사용이 제안됨. 이 도구는 검증 프로세스 속도를 크게 향상 시킴
• 자동 도구는 링크된 페이지, 프레임 페이지, 네비게이션 버튼으로 사용되는 이미지, 폼핸들러(form handlers), 애플릿, 파일 등으로의 링크를 체크할 수 있어야 한다.
• 자동 테스트 도구 선택 시 GUI 테스팅 도구와 다른 HTTP 테스팅 도구를 사용할 것이 제안됨. 이는 전체 HTTP 반응이 향후 비교를 위해 캡쳐 될 수 있는 장점을 제공한다. 또한 이 테스트 결과들은 나중에 다른 브라우저 상에서도 볼 수 있으므로 테스트팀은 주어진 테스트가 다른 특정 브라우저에서 런 되었더라면 어떻게 보여질지 알 수 있다.

네비게이션 요구사항과 테스팅(Navigation Requirements and Testing)

• 요구사항을 수집하고 이 요구사항들을 테스팅하는 것이 프로젝트의 핵심 프로세스 흐름이지만 종종 네비게이션 타입의 요구사항이 수집되지 않고 테스트에서도 누락되는 문제가 발생함
• 이런 타입의 요구사항들은 “사용자가 한 스크린에서 다음으로 갔다가 다시 돌아오면 어떤 일이 발생하는가”에 기반한다. 예를 들면, 사용자가 다음 입력 양식으로 갔다가 다시 돌아왔을 때 입력 양식(form)에 입력되었던 데이터가 여전히 그 자리에 있을 것인가? 풀다운 데이터(pull-down data)는 사용자가 선택한 대로 그대로 선택되어 있을 것인가? 등
• 이런 문제가 사용자 승인 테스트 동안 발견되어 크게 이슈가 되는 경우가 있음. 이 네비게이션 관련 요구사항들이 프로젝트 초기에 결정되었더라면 테스팅 단계에서 결함으로 식별되어 수정되는 대신에 개발 프로세스에서 훨씬 적은 비용으로 해당 기능을 제공할 수 있음