문서요약 - 웹 애플리케이션 테스팅 by Lucca

제목: 웹 애플리케이션 테스팅(Web Application Testing)

저자: Giuseppe A. Di Lucca 외 1인, 이탈리아

문서유형: 도서(Web Engineering, Mendes & Mosley 편집, 2006년)의 제 7장(총 42페이지)

 

웹 애플리케이션과 전통적인 소프트웨어 시스템 간의 테스팅 측면의 차이를 기술한 자료

---

웹 애플리케이션의 특징

웹 애플리케이션은 클라이언트서버 또는 멀티티어 아키텍쳐의 분산 시스템이며 아래 특징들을 가진다.

• 전세계에 퍼져 있는 많은 수의 사용자가 동시에 접근할 수 있다.
• 여러 다른 하드웨어, 네트워크 커넥션, 운영체제, 웹 서버, 웹 브라우저로 구성된 복잡하고 이질적인 실행 환경에서 실행된다.
• 시스템에 포함된 많은 수의 소프트웨어 컴포넌트에 의존하므로 높은 이질성을 가진다. 즉, 컴포넌트들의 성격(맨 처음부터 개발된 신규 컴포넌트, 레가시 컴포넌트, 하이퍼미디어 컴포넌트, COTS 등)이나 구현 기술(프로그래밍 언어와 모델)이 다양함
• 소프트웨어 컴포넌트가 런타임 동안에 사용자 입력과 서버 상태에 따라 생성될 수 있다.

웹 애플리케이션 테스팅의 이슈

• 많은 수의 사용자가 동시에 접속할 때 웹 애플리케이션의 동작을 검증하기 위한 효과적인 성능 및 가용성 테스팅 솔루션이 요구됨
• 사용자 브라우저의 웹 콘텐츠 표현(rendering) 능력이 다를 수 있으므로 여러 다른 웹브라우저, 운영체제, 미들웨어를 사용했을 때 웹 애플리케이션이 예상대로 동작하는지 테스트 해야 함
• 웹 애플리케이션의 보안과 인가되지 않은 접근(unauthorised access)으로부터의 보호 능력도 구체적으로 테스트 되어야 함
• 웹 애플리케이션 컴포넌트를 구현하는데 사용된 다양한 기술이 각 컴포넌트를 테스트 하는데 필요한 테스트 환경 수립의 복잡성과 비용에 영향을 줌. 또한 분산 컴포넌트를 통합하는데 사용된 메커니즘도 다양한 수준의 결합도(coupling)와 컴포넌트간 데이터 흐름(inter-component data flow)을 생성하여 테스트 비용에 영향을 미침
• 동적으로 생성된 소프트웨어 컴포넌트의 존재와 관련해서는 해당 컴포넌트를 생성했을 때와 동일한 조건을 생성하고 재실행 해야 하는 어려움을 극복해야 함
• 웹 애플리케이션의 컴포넌트가 대개 하이퍼텍스트 링크로 구현된 네비게이션 메커니즘에 의해 접근되는 점을 고려했을 때 링크 완전성(link integrity)을 체크하기 위한 특별한 검증 활동이 고안될 필요가 있음. 즉, 접근불가능한 컴포넌트(unreachable components)나 미정/파손 링크(pending/broken links)가 애플리케이션에 포함되지 않았음을 보장

웹 애플리케이션의 비기능 요구사항(Non-functional Requirements) 테스팅

1. 성능 테스팅(Performance Testing)

• 명세된 시스템 성능(예, 반응 시간, 서비스 가용성)을 검증하기 위해 수행. 대개 일정 시간 간격 동안 수백, 수천의 동시 사용자 접근을 시뮬레이션하며, 접근(accesses)에 대한 정보를 기록 및 분석하여 시스템 리소스를 소진하는 부하 수준(load levels)을 추정
• 웹 애플리케이션에서 성능 테스팅은 시스템을 적절하게 튜닝하기 위해 접근 로그 파일(access log files)의 데이터를 지속적으로 분석하는 활동으로 간주되어야 함
• 애플리케이션 레벨의 소프트웨어 컴포넌트가 비효율성을 초래 할 수도 있기는 하지만(예, 최적화되지 않은 알고리즘으로 비즈니스 규칙을 구현) 성능 테스팅에 의해 발견되는 실패는 주로 실행 환경의 결함(예, 부족한 리소스, 부적절하게 전개된 리소스) 때문이다.

2. 부하 테스팅(Load Testing)

• 종종 성능 테스팅과 동의어로 사용되지만 시스템 성능이 사전정의된 부하 수준으로 평가될 것을 요구한다는 점에서 성능 테스팅과 다름
• 사전정의된 조건 하에서 여러 태스크 및 기능을 수행하는데 필요한 시간을 측정하는 것을 목표로 함. 이 사전정의된 조건은 실행중인 애플리케이션의 최소 구성(minimum configuration)과 최대 활동 레벨(maximum activity levels)을 포함하며, 또한 다수의 동시 사용자 접근(simultaneous user accesses)이 시뮬레이션 된다.
• 테스팅 정보가 기록되고, 사전정의된 시간 한계 내에 태스크가 실행되지 않을 때 실패보고서(failure reports)가 생성된다.

3. 스트레스 테스팅(Stress Testing)

• 명세된 요구사항의 한계에 있는(또는 한계 이상에 있는) 시스템이나 EE컴포넌트를 평가하기 위해 수행됨
• 시스템 한계를 넘어설 수 있는 절정 활동에 대한 시스템의 반응을 평가하고, 혹시 시스템이 붕괴되는지 그리고 그런 조건으로부터 복구될 수 있는지를 검증함
• 성능과 부하 테스팅이 정상적인 사용자 활동을 시뮬레이션 하는 반면 스트레스 테스팅은 시스템을 한계점에서(또는 그 이상에서) 실행시킨다는 점에서 성능/부하 테스팅과 다름

4. 호환성 테스팅(Compatibility Testing)

• 다양한 하드웨어, 소프트웨어, 미들웨어가 조합된 실행 환경에서 애플리케이션이 예상대로 실행되는지 판단하기 위해 수행됨
• 웹 애플리케이션의 경우 호환성 테스팅은 여러 다른 웹 서버 플랫폼이나 클라이언트 브라우저(그리고 상응하는 릴리즈나 구성)의 사용으로 인한 실패를 발견할 수 있음
• 웹 애플리케이션 실행에 관련된 모든 컴포넌트의 모든 가능한 조합을 테스트 하는 것은 실현 불가능하므로 대개 가장 흔한 조합만을 고려함(결과적으로 가능한 호환성 실패의 부분 집합만이 발견됨)
• 호환성 실패(compatibility failures)를 피하기 위한 일반적인 규칙은 웹 애플리케이션 사용자에게 의도된 실행 환경 구성에 대한 적절한 정보를 제공하고 또한 발견되는 비호환성을 처리할 수 있는 적절한 진단 메시지를 제공하는 것이다.

5. 사용성 테스팅(Usability Testing)

• 애플리케이션이 어는 정도 사용하기 쉬운지를 검증하는데 목적이 있으며 주로 사용자 인터페이스를 테스팅 하는데 집중한다. 즉, 올바른 콘텐츠 표현과 관련된 이슈, 메시지/프롬프트/명령어의 명확성 등을 고려하여 검증함
• 웹 애플리케이션 사용성 테스팅이 수행될 때 애플리케이션 네비게이션의 완전성, 정확성, 간결성에 관련된 이슈들이 고려되고 검증된다.
• 이런 타입의 테스팅은 웹 애플리케이션의 사용성을 개선하기 위해 수행되는 지속적인 활동이어야 하며, 이 목표에 도달하기 위해 대개 사용자 프로파일링 기법이 사용된다.

6. 접근성 테스팅(Accessibility Testing)

• 접근성(또는 접근용이성) 테스팅은 특별한 타입의 사용성 테스팅으로 간주될 수 있음
• 클라이언트 측의 저하된 하드웨어와 소프트웨어 구성에서(예, 브라우저의 그래픽 표시나 스크립트 실행이 비활성화됨) 또는 장애를 가진 사용자에게도 애플리케이션 콘텐츠로의 접근이 허용되는지를 검증하는 것이 목표
• 웹 애플리케이션의 경우 ‘Web Content Accessibility Guidelines’에서 제공하는 접근성 규칙이 존재함. 접근성 테스팅은 애플리케이션이 이런 규칙을 준수하는지를 검증한다.

7. 보안 테스팅(Security Testing)

• 비인가 사용자의 의도되지 않은 접근에 대한 웹 애플리케이션 방어의 효과성, 부적절한 사용으로부터 시스템 리소스를 보존하는 능력, 인가된 서비스와 리소스로 인가된 사용자의 접근을 허용하는지를 검증한다.
• 애플리케이션 방어는 보안 위반에 의해 야기되는 피해보다 훨씬 적은 비용으로 침입으로 인한 피해를 막거나 줄일 수 있는 보호 메커니즘을 제공해야만 한다.
• 보안에 영향을 미치는 애플리케이션 취약성(vulnerabilities)은 애플리케이션 코드에 또는 여러 다른 하드웨어/소프트웨어/미들웨어 컴포넌트에 포함되어 있을 수 있다.
• 매우 많은 수의 잠재 사용자가 어디서든 접근할 수 있는 것에 더불어 웹 애플리케이션의 이질적인 구현/실행 기술은 전통적인 애플리케이션보다 웹 애플리케이션을 더 취약하게 만들며, 따라서 보안 테스팅 달성을 더 어렵게 만들 수 있다.

웹 애플리케이션의 기능 요구사항(Functional Requirements) 테스팅

• 기능 테스팅은 애플리케이션의 기능(features)과 운영 동작(operational behaviour)이 해당 명세에 일치하는지 검증하는 것을 목표로 한다. 즉, 애플리케이션의 실행 환경에 기인한 실패 보다는 기능 요구사항 구현에 있는 결함이 야기하는 애플리케이션 실패를 발견하는 책임을 지는 테스트이다.
• 전통적인 소프트웨어의 기능 요구사항을 테스트 하는데 사용되는 대부분의 방법과 전략이 웹 애플리케이션을 위해서도 사용될 수 있음
• 하지만 이런 유사성에도 불구하고 웹 애플리케이션은 나름의 구별되는 특징을 가짐. 예를 들면, 화이트박스 테스팅에서 전통적인 구조적 측면 뿐만 아니라 네비게이션을 표현하는 모델이 고려될 필요가 있으며, 커버리지 기준도 사용자 네비게이션을 허용하는 하이퍼링크와 애플리케이션 컴포넌트의 내부 항목(예, 코드 구문) 둘 다를 고려해야 함

웹 애플리케이션 표현 모델(Web Application Representation Models)

• 소프트웨어 테스팅에서는 필수 개념 및 테스트 되는 항목들간의 관계를 표현(문서화)한 모델이 필요함. 이 모델은 요구되는 동작을 표현하거나 또는 결함이 의심되는 애플리케이션 구조의 측면에 집중하도록 하는데 사용될 수 있으며, 따라서 효과적인 테스트 케이스 선정을 지원할 수 있다.
• 웹 애플리케이션에서도 그 동작과 구조를 표현하기 위한 모델이 여러 웹 애플리케이션 개발 방법론에서 제안됨(대개 웹 관련 소프트웨어 특징을 분명하게 표현하기 위해 전통적인 소프트웨어 모델을 확장한 것)
• 아래 그림은 UML 클래스 다이어그램을 사용하여 표현한 웹 애플리케이션의 메타모델임(즉, 여러 카테고리의 웹 애플리케이션 컴포넌트와 이들간의 관계를 표현함)

[웹 애플리케이션의 메타모델]

• 이 메타모델은 웹 애플리케이션이 Web Pages로 구성된다고 가정함. Web Pages는 웹 서버 상에 전개되는 페이지인 Server Pages와 웹 서버가 클라이언트 리퀘스트에 대한 응답으로 반송하는 페이지인 Client Pages로 그룹됨
• Client Pages는 그 콘텐츠가 고정이고 영구 저장되면 Static Pages, 콘텐츠가 시간 경과에 따라 변하고 Server Page에 의해 동적으로 생성되면 Client Built Pages로 분류될 수 있음
• Client Page는 HTML Tags로 구성됨. Client Page는 하나 또는 여러 Frames으로 구성된 Frameset을 포함할 수도 있음(각각의 Frame에 다른 Web Page가 로드 될 수 있음)
• Client Pages는 Client Scripts 같은 프로세싱 액션을 구현하는 세부 항목을 포함할 수도 있음
• Client Page는 타 Web Objects(예, Java Applets, 이미지와 멀티미디어 오브젝트, Flash Objects 등)를 포함할 수도 있음
• Client Script는 Client Modules를 포함할 수도 있음. Client Scripts와 Client Modules 둘 다 Client Functions 또는 Client Classes를 포함할 수도 있음
• Client Script는 다른 Web Page로 elaboration을 리디렉트(redirect) 할 수도 있음
• Client Page는 Web Page의 URL로의 하이퍼링크를 통해 다른 Web Page로 연결될 수도 있음(Client Page와 Web Page 간의 링크는 Client Page가 Web Page에게 제공하는 Parameter에 의해 특징지어질 수 있음)
• Client Page는 Downloadable File과 연관될 수도 있고, 여러 다른 타입의 Field(예, select, button, text-area fields)로 구성된 Form을 포함할 수도 있음
• Forms은 사용자 입력을 수집하고 이것을 elaboration을 책임진 Server Page로 submit 하기 위해 사용된다.
• Server Page는 Server Script로 구성될 수 있음. 이는 Server Class 또는 Server Function를 포함하여 프로세싱 액션을 구현하고, 리퀘스트를 다른 Web Page로 redirect 하거나 또는 Elaboration의 결과를 제공하는 Client Built Page를 동적으로 build 한다.
• Server Page는 다른 Server Pages를 포함할 수 있고, 다른 Interface Objects와 연관될 수 있다(이는 웹 애플리케이션을 DBMS, 파일서버, 메일서버, 또는 타 시스템으로 연결하는 것을 허용함).

웹 애플리케이션의 단위 테스팅(Unit Testing)

• 웹 애플리케이션의 단위 테스팅을 수립하기 위해서는 개별적으로 테스트되는 애플리케이션 컴포넌트를 선정하는 것이 중요함
• 위 웹 애플리케이션 메타모델에서 볼 수 있듯이 여러 다른 타입의 단위가 식별가능함(예, 웹 페이지, 스크립팅 모듈, forms, 애플렛, 서브렛). 하지만 실제로 테스트 될 수 있는 기본 단위는 Web page임. 따라서 클라이언트 페이지 테스팅과 서버 페이지 테스팅 간에 약간의 차이가 있다 할지라도 대개 페이지가 단위 테스팅의 ‘단위’로 여겨짐
• 단위 페이지 테스팅을 효과적으로 수행하기 위해서는 적절한 드라이버 페이지와 스터브 페이지가 생성되어야만 함. 일반적으로 ‘클라이언트 페이지의 드라이버’는 클라이언트 페이지가 실행되도록 브라우저로 로딩하는 책임을 진다. ‘서버 페이지의 드라이버’는 해당 페이지가 웹 서버 상에서 실행되도록 한다. ‘클라이언트 페이지의 스터브’는 테스트 대상 페이지로부터 하이퍼링크에 의해 다다를 수 있는 페이지의 동작을 시뮬레이션 한다(또는 웹 서버상의 실행이 테스트 대상 페이지에 의해 요구되는 페이지의 동작을 시뮬레이션 함). ‘서버 페이지의 스터브’는 그 실행이 테스트 대상 서버 페이지에 의해 요구되는 타 소프트웨어 컴포넌트의 동작을 시뮬레이션 한다.

1) 클라이언트 페이지 테스팅(Testing Client Pages)

• 클라이언트 페이지는 애플리케이션의 사용자 인터페이스를 구성함(텍스트 정보와 하이퍼링크를 사용자에게 보여주고, 사용자 입력을 받아들이고, 사용자 네비게이션을 허용함)
• 클라이언트 페이지가 간단한 기능(예, 입력 검증, 단순 계산)을 수행하는 스크립팅 코드 모듈을 포함할 수도 있음. 또한 클라이언트 페이지가 타 클라이언트 페이지를 보여주는 여러 프레임으로 나뉠 수도 있음

클라이언트 페이지(단순 HTML 코드도 포함) 테스팅에서는 아래 사항들이 검증된다.

• 페이지가 디스플레이 하는 콘텐츠가 사용자가 명세하고 기대하는 것과 일치하는지 여부(예, 텍스트 콘텐츠와 그 형식, 이미지, 타 웹 오브젝트가 브라우저 상에서 예상대로 보여지는지를 확인)
• 하이퍼링크가 가리키는 타겟 페이지의 정확성(즉, 링크가 선택되었을 때 올바른 페이지가 나타나는지 확인)
• 미정 링크의 존재(즉, 페이지로의 링크가 존재하지 않음) 
• 버튼이나 다른 액티브 오브젝트가 사용자에 의해 선택될 때 수행되는 액션의 정확성
• 프레임에 보여지는 콘텐츠의 정확성
• 클라이언트 페이지가 스크립팅 코드를 포함하면 스크립트로 인한 실패도 검증되어야 함

클라이언트 페이지의 단위 테스팅은 화이트박스, 블랙박스, 그레이박스 테스팅 기법을 사용하여 수행 가능하며, 아래 같은 여러 구현 기반 기준이 화이트박스 테스트 커버리지를 평가하는데 사용될 수 있다.

• HTML 구문 커버리지(HTML statement coverage)
• 웹 오브젝트 커버리지(Web object coverage): 각 이미지, 멀티미디어 컴포넌트, 애플릿 등이 적어도 한번은 테스트 되어야 한다.
• 스크립트 블록 커버리지(Script block coverage): 스크립팅 코드의 각 블록(예, 클라이언트 측 기능)이 적어도 한번은 실행되어야 한다.
• 각 스크립트 모듈에 대한 구문/브랜치/경로 커버리지(Statement/branch/path coverage)
• 링크 커버리지(Link coverage)

2) 서버 페이지 테스팅(Testing Server Pages)

• 서버 페이지의 주 목표는 애플리케이션의 비즈니스 로직을 구현하는 것임(즉, 비즈니스 규칙의 실행을 조율하고, 데이터베이스의 데이터 저장/복원을 관리함)
• 대개 서버 페이지는 여러 기술의 혼합으로 구현됨(HTML, VBS나 JSP 같은 스크립트 언어, Java servlets, COTS 등)
• 서버 페이지 실행의 전형적인 결과로는 데이터베이스로의 데이터 저장과 사용자 리쿼스트에 기반한 클라이언트 페이지 생성이 있다. 

서버 페이지 테스팅은 아래와 같은 여러 타입의 실패를 식별하는 것을 목표로 한다.

• 서브렛 또는 COTS 실행에 있어 실패
• 데이터베이스로 데이터가 저장되는데 있어 부정확한 실행
• 페이지간의 부정확한 링크가 존재함으로 인한 실패
• 동적으로 생성된 클라이언트 페이지에서의 결함(예, 클라이언트 페이지가 서버 페이지를 위해 명세된 출력과 불일치)

서버 페이지의 단위 테스팅도 화이트박스, 블랙박스, 그레이박스 기법을 사용하여 수행될 수 있으며, 화이트박스 커버리지 기준으로 아래와 같은 것들이 있다.

• 스크립트 모듈의 구문/브랜치/경로 커버리지(Statement/branch/path coverage)
• HTML 구문 커버리지(HTML statement coverage)
• 서브렛, COTS, 타 웹 오브젝트 커버리지
• 하이퍼링크 커버리지(Hyperlink coverage)
• 동적으로 생성된 페이지 커버리지(Coverage of dynamically generated pages)

통합 테스팅(Integration Testing)

• 웹 애플리케이션의 ‘통합된 페이지(combined pages)들’이 다 함께 잘 기능하는지를 평가하는 테스팅
• 통합되어 함께 테스트 될 페이지들을 선택하기 위해서 통합 기준이 필요하며, 페이지간의 관계를 보여주는 설계 문서가 통합 전략을 정의하기 위해 사용될 수 있음. 예를 들면, 각 유스케이스(또는 기능 요구사항)을 구현하는데 공동으로 협력하는 웹 페이지들을 통합 목적으로 고려한다.
• 통합된 페이지들(또는 ‘상호연결된 페이지들의 클러스터’라고도 불림)은 하이퍼링크 같은 직접적 관계(direct relationships)에 의해 연결되거나, 서버 페이지나 클라이언트 페이지에 포함된 redirect 또는 submit 구문을 통한 의존 관계(dependency relationships)에 의해 연결되거나, 또는 서버 페이지와 생성된 클라이언트 페이지 간의 빌드 관계(build relationships)에 의해 연결된다.
• 서버 페이지와 이 서버 페이지가 런타임에 생성하는 각 클라이언트 페이지를 테스트 할 하나의 단위로 간주하는 통합 기준도 존재할 수 있음. 이 경우 테스트 대상 단위 수가 급격히 증가하는 ‘클라이언트 페이지 폭발 문제(the problem of client page explosion)’는 동등 클래스 분할 기준(equivalence class partitioning criteria)을 적용해 해결할 수 있음

시스템 테스팅(System Testing)

• 전체 웹 애플리케이션과 관련된 결함 발견을 목표로 하는 테스팅
• 전통적인 소프트웨어 테스팅에서는 시스템 테스팅을 위해 대개 블랙박스 방법이 활용되고 외적으로 보이는 애플리케이션 동작에 있는 실패를 식별함. 웹 애플리케이션 경우는 동작에 더불어 애플리케이션 네비게이션 구조를 고려하는 그레이박스 기법을 테스트 케이스 설계에 활용하는 편이 페이지간의 부정확한 링크로 인한 실패를 찾는데 더 효과적일 수 있다.
• 적용된 테스팅 전략에 따라 시스템 테스팅을 위한 커버리지 기준은 아래를 포함한다
  - 사용자기능/유스케이스 커버리지: 블랙박스 방법이 사용된 경우
  - (클라이언트와 서버) 페이지 커버리지: 화이트박스나 그레이박스 방법이 사용된 경우
  - 링크 커버리지: 화이트박스나 그레이박스 방법이 사용된 경우

사용자 세션 기반 테스팅(User Session Based Testing)

• 사용자 세션에서 캡쳐된 데이터를 기반으로 하는 테스트 방법은 웹 서버와의 사용자 인터액션(user interactions)을 투명하게 수집하고 이를 주어진 전략에 따라 테스트 케이스로 변환한다.
• 웹 서버와의 사용자 인터액션에 대해 캡쳐되는 데이터는 URL과 이름-값 쌍(name value pairs)의 형태로 표현된 클라이언트 리퀘스트를 포함한다. 이 데이터는 웹 서버에 의해 저장되는 로그 파일로부터 얻어지거나 또는 리퀘스트된 서버 페이지에 스크립트 모듈을 추가하여 얻을 수 있다(이 모듈이 교환되는 패러미터의 이름-값 쌍을 캡쳐함). 캡쳐된 사용자 세션에 대한 데이터는 ‘HTTP 리퀘스트들의 집합(a set of HTTP requests)’으로 변환될 수 있다(이것의 각각이 별도의 테스트케이스를 제공함).
• 이 방법의 장점은 웹 애플리케이션의 내부 구조를 분석하지 않고 테스트케이스를 생성할 수 있다는 점이다(즉, 입력 값을 찾는 비용이 줄어듬). 또한 사용자 세션 데이터를 사용한 테스트케이스 생성은 웹 애플리케이션의 이질적이고 빠르게 변하는 기술에 덜 의존적이다(이점이 화이트박스 테스팅 기법 활용에 있어 주된 제약이 됨).
• 이 방법의 효과성은 수집된 사용자 세션 데이터 셋에 의존한다. 데이터 셋이 커질수록 결함 발견의 효과성도 커지지만 데이터를 수집/분석/저장하는데 드는 비용도 커짐. 즉, 테스트스위트(test suite) 크기와 결함 발견 능력 간에 상충관계(trade-off)가 존재함

웹 애플리케이션 테스팅을 위한 도구

• 테스팅 프로세스의 효과성은 해당 프로세스를 지원하는 도구에 크게 의존함. 테스팅 도구는 대개 프로세스에서 요구하는 일부 태스크를 자동화한다(예, 테스트 케이스 생성, 테스트 케이스 실행, 테스트 케이스 결과 평가). 또한 테스팅 도구는 유용한 테스팅 문서 생성과 그 형상 관리를 지원할 수도 있다.
• 웹 애플리케이션 테스팅을 위한 다양한 도구가 제안되었으며, 아래 6개 카테고리로 분류될 수 있다.
  a) 부하, 성능, 스트레스 테스트 도구(Load, performance and stress test tools)
  b) 웹 사이트 보안 테스트 도구(Web site security test tools)
  c) HTML/XML 확인기(HTML/XML validators)
  d) 링크 체커(Link checkers)
  e) 사용성과 접근성 테스트 도구(Usability and accessibility test tools)
  f) 웹 기능/회귀 테스트 도구(Web functional/regression test tools)
• 카테고리 a), b), e)에 속하는 도구는 비기능 요구사항 테스팅을 지원하는데 사용되고, 카테고리 c)와 d)의 도구는 웹 애플리케이션 코드가 신텍스 규칙을 준수하는지 또는 그 구조가 네비게이션 가능한지를 검증하는데 중점을 둔다. 카테고리 f)의 도구는 웹 애플리케이션의 기능 테스팅을 지원하며 capture and replay 도구를 포함한다.