웹 애플리케이션에 대한 테스트 케이스 예(체크리스트)

⚡ 스마트 요약

웹 애플리케이션 테스트 체크리스트는 사용성, 기능, 호환성, 데이터베이스, API, 보안, 성능 및 접근성 검사를 모두 포괄합니다. 아래 각 섹션에서는 품질 보증 팀이 테스트 관리 도구에 바로 복사하여 사용할 수 있는 테스트 시나리오를 제공합니다.

  • ⚙️ 기능성 우선: 외관 검토를 시작하기 전에 필수 입력란, 경계 길이, 윤년, 0으로 나누기, 시간 초과 동작 등을 검증하십시오.
  • 🧭 사용성 신호: 처음 사용하는 사용자가 막히는 일이 없도록 정렬, 툴팁, 키보드 접근성, 스크롤 막대 및 오류 메시지 복구 기능을 확인하세요.
  • 🌐 호환성 매트릭스: 크롬에서 핵심 워크플로를 반복하세요. FirefoxEdge, Safari 및 모바일 브라우저의 레이아웃 및 스크립트 차이점을 보여줍니다.
  • 🗄️ 데이터베이스 무결성: 프런트엔드 값을 저장된 레코드와 대조하고, 양쪽 계층 모두에서 키, 트리거, 저장 프로시저 및 필드 길이를 검증합니다.
  • 🔌 API 계층: 브라우저와 별도로 상태 코드, 스키마, 인증, 속도 제한 및 하위 시스템 오류 처리를 검증하십시오.
  • 🔐 보안 기준선: HTTPS를 강제 적용하고, 저장된 비밀 정보를 암호화하고, 반복적인 실패 후 계정을 잠그고, SQL 인젝션 및 무차별 대입 공격을 탐지합니다.
  • 🚀 성능 및 접근성: 스크립트 로드 프로파일을 수동 작업 대신 자동화하여 WCAG 대비, 레이블 및 키보드 작동을 확인합니다.

웹 애플리케이션을 테스트하는 동안 아래에 언급된 템플릿을 고려해야 합니다. 아래에 언급된 체크리스트는 비즈니스 요구 사항에 따라 모든 유형의 웹 애플리케이션에 거의 적용 가능합니다.

위 템플릿은 체크리스트의 모든 영역에 대한 시나리오를 한 장의 시트에 담는 방법을 보여줍니다. 자세한 내용은 다음을 참조하세요. 웹 애플리케이션 테스트 개요.

이제 각 체크리스트를 자세히 살펴보겠습니다.

기능 테스트

기능 테스트란 무엇입니까?

  • 제품의 기능과 작동 방식을 테스트하여 사양에 부합하는지 확인합니다.
  • 시스템이나 구성 요소의 내부 메커니즘을 무시하고 선택된 입력 및 실행 조건에 응답하여 생성된 출력에만 초점을 맞추는 테스트입니다.

기능 테스트의 목적이나 목표는 무엇입니까?

  • 의 목표 기능 테스트 귀하의 제품이 개발 문서에 언급된 의도된 기능 사양을 충족하는지 확인하는 것입니다.

기능 테스트 시나리오 예시:

  • 모든 필수 필드를 테스트하여 검증해야 합니다.
  • 모든 필수 필드에 대해 별표 기호가 표시되어야 하는지 테스트합니다.
  • 시스템 테스트에서는 선택 필드에 대한 오류 메시지가 표시되지 않아야 합니다.
  • 윤년이 올바르게 검증되었으며 오류/오산이 발생하지 않는지 테스트합니다.
  • 숫자 필드를 테스트하면 알파벳이 허용되지 않아야 하며 적절한 오류 메시지가 표시되어야 합니다.
  • 숫자 필드에서 허용되는 경우 음수를 테스트합니다.
  • XNUMX으로 나누는 테스트는 계산을 위해 적절하게 처리되어야 합니다.
  • 데이터가 잘리지 않도록 모든 필드의 최대 길이를 테스트하세요.
  • 데이터가 필드의 최대 크기에 도달하면 팝업 메시지("이 필드는 500자로 제한됩니다")가 표시되어야 하는지 테스트합니다.
  • 업데이트 및 삭제 작업에 대한 확인 메시지가 표시되는지 테스트합니다.
  • 금액 값이 통화 형식으로 표시되는지 테스트합니다.
  • 특수 문자에 대한 모든 입력 필드를 테스트합니다.
  • 시간 초과 기능을 테스트합니다.
  • 정렬 기능을 테스트합니다.
  • 사용 가능한 버튼의 기능을 테스트하세요.
  • 개인 정보 보호 정책 및 FAQ를 테스트해 보십시오. 명확하게 정의되어 사용자에게 제공되어야 합니다.
  • 기능이 실패하면 사용자가 사용자 정의 오류 페이지로 리디렉션되는지 테스트합니다.
  • 업로드된 모든 문서가 제대로 열리는지 테스트합니다.
  • 사용자가 업로드된 파일을 다운로드할 수 있는지 테스트하세요.
  • 시스템의 이메일 기능을 테스트합니다.
  • 테스트 Java 스크립트가 다른 브라우저(IE, Firefox, 크롬, 사파리 및 Opera).
  • 사용자가 사이트에 있는 동안 쿠키를 삭제하면 어떤 일이 발생하는지 테스트해 보세요.
  • 사용자가 사이트를 방문한 후 쿠키를 삭제하면 어떤 일이 발생하는지 테스트해 보세요.
  • 콤보/목록 상자 내의 모든 데이터가 시간순으로 정렬되어 있는지 테스트합니다.

일단 기능들이 제대로 작동한다면, 다음 질문은 실제 사용자들이 도움 없이 그 기능들을 조작할 수 있는지 여부입니다.

사용성 테스트

사용성 테스트란 무엇입니까?

  • 사용성 테스트는 사용자 친화성 검사에 지나지 않습니다.
  • 사용성 테스트에서는 새로운 사용자가 애플리케이션을 쉽게 이해할 수 있도록 애플리케이션의 흐름을 테스트합니다.
  • 기본적으로 사용성 테스트에서는 시스템 탐색을 확인합니다.

유용성 테스트의 목적 또는 목표는 무엇입니까?

유용성 테스트는 표준 유용성 테스트 방식을 사용하여 제품의 사용 용이성과 효율성을 확립합니다.

사용성 테스트 사례의 예

  • 웹페이지 콘텐츠는 철자나 문법 오류 없이 정확해야 합니다.
  • 모든 글꼴은 요구 사항에 따라 동일해야 합니다.
  • 모든 텍스트가 올바르게 정렬되어야 합니다.
  • 모든 오류 메시지는 철자나 문법 오류 없이 정확해야 하며 오류 메시지는 필드 레이블과 일치해야 합니다.
  • 모든 필드에 도구 설명 텍스트가 있어야 합니다.
  • 모든 필드가 올바르게 정렬되어야 합니다.
  • 필드 레이블, 열, 행 및 오류 메시지 사이에 충분한 공간이 제공되어야 합니다.
  • 모든 버튼은 표준 형식과 크기여야 합니다.
  • 홈 링크는 모든 페이지에 있어야 합니다.
  • 비활성화된 필드는 회색으로 표시됩니다.
  • 깨진 링크와 이미지가 있는지 확인하세요.
  • 모든 종류의 업데이트 및 삭제 작업에는 확인 메시지가 표시되어야 합니다.
  • 다양한 해상도(640 x 480, 600×800 등?)로 사이트를 확인하세요.
  • 최종 사용자가 불만 없이 시스템을 실행할 수 있는지 확인하십시오.
  • 탭이 제대로 작동하는지 확인하세요.
  • 스크롤 막대는 필요한 경우에만 나타나야 합니다.
  • 제출 시 오류 메시지가 있는 경우 사용자가 입력한 정보가 있어야 합니다.
  • 제목은 각 웹페이지에 표시되어야 합니다.
  • 모든 필드(텍스트 상자, 드롭다운, 라디오 버튼 등)와 ​​버튼은 단축키를 통해 접근할 수 있어야 하며, 사용자는 키보드를 사용하여 모든 작업을 수행할 수 있어야 합니다.
  • 필드 크기 때문에 드롭다운 데이터가 잘리지 않는지 확인하세요. 또한, 해당 데이터가 하드코딩되어 있는지, 관리자를 통해 관리되고 있는지 확인하세요.

한 브라우저에서 잘 보이는 레이아웃도 다른 브라우저에서는 제대로 표시되지 않을 수 있으므로, 지원되는 모든 환경에서 동일한 화면을 재현해야 합니다.

호환성 테스트

호환성 테스트란 무엇입니까?

  • 호환성 테스트는 소프트웨어가 작동해야 하는 시스템의 다른 요소(예: 브라우저)와 호환되는지 확인하는 데 사용됩니다. Opera시스템 또는 하드웨어.

호환성 테스트의 목적이나 목표는 무엇입니까?

  • 호환성 테스트의 목적은 소프트웨어가 특정 브라우저에서 얼마나 잘 작동하는지 평가하는 것입니다. Opera시스템, 하드웨어 또는 소프트웨어.

샘플 호환성 테스트 시나리오:

  • 다양한 브라우저(IE, Firefox, Chrome, Safari 및 Opera) 웹사이트가 제대로 표시되는지 확인하세요.
  • 사용 중인 HTML 버전이 적절한 브라우저 버전과 호환되는지 테스트하십시오.
  • 다양한 브라우저에서 이미지가 올바르게 표시되는지 테스트합니다.
  • 다양한 브라우저에서 글꼴을 사용할 수 있는지 테스트하세요.
  • 다양한 브라우저에서 Java 스크립트 코드를 사용할 수 있는지 테스트해 보세요.
  • 다양한 브라우저에서 애니메이션 GIF를 테스트해 보세요.

일관된 렌더링은 화면 뒤에 있는 기록에 대해 아무것도 증명하지 못합니다. 크로스 브라우저 테스트 매트릭스는 이 영역을 관리하기 쉽게 해줍니다.

데이터베이스 테스트

데이터베이스 테스트란 무엇입니까?

  • In 데이터베이스 테스트 웹 또는 데스크톱 애플리케이션을 통해 삽입된 백엔드 레코드가 테스트됩니다. 웹 애플리케이션에 표시되는 데이터는 데이터베이스에 저장된 데이터와 일치해야 합니다.

데이터베이스 테스트를 수행하려면 테스터는 아래 언급된 사항을 알고 있어야 합니다.:

  • 테스터는 기능적 요구사항, 비즈니스 로직, 애플리케이션 흐름 및 데이터베이스 설계를 철저하게 이해해야 합니다.
  • 테스터는 애플리케이션에 사용되는 테이블, 트리거, 저장 프로시저, 뷰 및 커서를 파악해야 합니다.
  • 테스터는 생성된 트리거, 저장 프로시저, 뷰 및 커서의 논리를 이해해야 합니다.
  • 테스터는 웹이나 데스크톱 애플리케이션을 통해 삽입, 업데이트, 삭제(DML) 작업이 수행될 때 영향을 받는 테이블을 파악해야 합니다.

위에서 언급한 사항을 통해 테스터는 데이터베이스 테스트를 위한 테스트 시나리오를 쉽게 작성할 수 있습니다.

데이터베이스 테스트를 위한 테스트 사례 예:

  • 데이터베이스 이름을 확인하십시오. 데이터베이스 이름은 명시된 이름과 일치해야 합니다.
  • 테이블, 열, 열 유형 및 기본값을 확인합니다. 모든 것이 사양과 일치해야 합니다.
  • 열이 null을 허용하는지 여부를 확인하십시오.
  • 각 테이블의 기본 키와 외래 키를 확인합니다.
  • 저장 프로시저를 확인합니다.
  • 저장 프로시저가 설치되어 있는지 테스트합니다.
  • 저장 프로시저 이름 확인
  • 매개변수 이름, 유형, 매개변수 개수를 확인하세요.
  • 매개변수가 필요한지 여부를 테스트하십시오.
  • 일부 매개변수를 삭제하여 저장 프로시저 테스트
  • 출력이 XNUMX일 때 테스트하면 XNUMX 레코드가 영향을 받습니다.
  • 간단한 내용을 작성하여 저장 프로시저를 테스트하세요. SQL 검색어.
  • 저장 프로시저가 값을 반환하는지 테스트
  • 샘플 입력 데이터로 저장 프로시저를 테스트합니다.
  • 테이블에 있는 각 플래그의 동작을 확인합니다.
  • 각 페이지 제출 후 데이터가 데이터베이스에 제대로 저장되는지 확인하세요.
  • DML(업데이트, 삭제, 삽입) 작업이 수행되는 경우 데이터를 확인합니다.
  • 모든 필드의 길이를 확인하십시오. 백엔드와 프론트 엔드의 필드 길이는 동일해야 합니다.
  • QA, UAT, 프로덕션의 데이터베이스 이름을 확인합니다. 이름은 고유해야 합니다.
  • 데이터베이스의 암호화된 데이터를 확인합니다.
  • 데이터베이스 크기를 확인하십시오. 또한 실행된 각 쿼리의 응답 시간을 테스트합니다.
  • 프런트엔드에 표시되는 데이터를 확인하고 백엔드에서도 동일한지 확인하세요.
  • 데이터베이스에 유효하지 않은 데이터를 삽입하여 데이터 유효성을 확인하십시오.
  • 트리거를 확인합니다.

API 테스트 체크리스트

대부분의 비즈니스 규칙은 이제 REST 또는 GraphQL 엔드포인트 뒤에 숨겨져 있으므로 브라우저 검사만으로는 시스템이 제대로 작동하는지 확인할 수 없습니다. 엔드포인트를 직접 테스트하면 문제가 드러납니다.trac사용자 인터페이스보다 훨씬 더 일찍 권한 부여 관련 결함을 발견할 수 있습니다.

엔드포인트 승인 전에 다음 시나리오를 모두 검토하십시오.

API 테스트를 위한 샘플 테스트 시나리오:

  • 성공, 유효성 검사 실패, 무단 접근 및 서버 오류에 대한 기록된 상태 코드를 확인하십시오.
  • 응답 페이로드가 필드 이름과 데이터 유형을 포함하여 게시된 스키마와 일치하는지 확인하십시오.
  • 매개변수가 누락되었거나 형식이 잘못된 경우 스택 트레이스가 아닌 읽기 쉬운 메시지를 반환하는지 확인합니다. trace.
  • 인증 토큰이 만료되고, 올바르게 갱신되며, 로그아웃 후 다시 사용할 수 없는지 확인합니다.
  • 역할 기반 권한 부여를 검증하여 일반 계정이 식별자를 변경하여 관리자 엔드포인트에 접근할 수 없도록 합니다.
  • 빈 문자열 및 최대 길이를 포함하여 모든 매개변수의 경계값을 확인하십시오.
  • 속도 제한 기능이 오류 없이 실패하는 대신 올바른 속도 제한 응답을 반환하는지 확인합니다.
  • 타사 서비스 시간 초과 시 엔드포인트가 정상적으로 성능 저하되는지 확인합니다.
  • 응답이나 오류 메시지에 암호, 토큰 또는 내부 경로가 나타나지 않는지 확인하십시오.

스테이징 환경과 프로덕션 환경은 종종 서로 다른 권한 설정을 사용하므로, 모든 환경에서 이 목록을 실행하십시오. 자세한 내용은 다음을 참조하십시오. API 테스트 개요 및 REST API를 수동으로 테스트하기.

그러한 점검 사항 중 상당수는 보안 업무와 겹칩니다.

보안 테스트

보안 테스트 보안 관점에서 결함과 격차를 식별하는 테스트가 포함됩니다.

보안 테스트를 위한 샘플 테스트 시나리오:

  • 비밀번호, 신용카드 번호, 보안 질문에 대한 비밀 답변 등 중요한 데이터가 포함된 웹 페이지는 HTTPS(SSL)를 통해 제출해야 합니다.
  • 비밀번호, 신용카드 번호 등의 중요한 정보가 암호화된 형태로 표시되어야 합니다.
  • 등록, 비밀번호 찾기, 비밀번호 변경 등 모든 인증 페이지에 비밀번호 규칙이 구현되어 있는지 확인하세요.
  • 비밀번호가 변경되면 사용자가 이전 비밀번호로 로그인할 수 없는지 확인하십시오.
  • 오류 메시지에 중요한 정보가 표시되지 않는지 확인하십시오.
  • 사용자가 시스템에서 로그아웃되었거나 사용자 세션이 만료되었는지 확인하십시오. 사용자는 사이트를 탐색할 수 없습니다.
  • 보안 및 비보안 웹 페이지에 로그인 없이 바로 접속하려면 인증하세요.
  • "소스 코드 보기" 옵션이 비활성화되어 있고 사용자에게 표시되지 않는지 확인하세요.
  • 사용자가 잘못된 비밀번호를 여러 번 입력하면 사용자 계정이 잠기는지 확인하십시오.
  • 쿠키에 비밀번호가 저장되지 않는지 확인하세요.
  • 기능이 작동하지 않는 경우 시스템에 애플리케이션, 서버 또는 데이터베이스 정보가 표시되지 않는지 확인하십시오. 대신 사용자 정의 오류 페이지가 표시되어야 합니다.
  • SQL 주입 공격을 확인합니다.
  • 사용자 역할과 해당 권한을 확인하십시오. 예를 들어 요청자는 관리 페이지에 액세스할 수 없어야 합니다.
  • 중요 작업이 로그 파일에 기록되는지 확인하고, 해당 정보가 포함되어 있는지 확인해야 합니다. trac가능함.
  • 세션 값이 주소 표시줄에서 암호화된 형식인지 확인하세요.
  • 쿠키 정보가 암호화된 형식으로 저장되어 있는지 확인하세요.
  • 무차별 공격에 대한 애플리케이션 확인

하중을 받으면 휘어지는 강화된 응용 분야는 여전히 사용할 수 없으므로 다음 단계에서는 크기를 측정합니다.

성능 시험

성능 시험 지정된 성능 요구 사항에 대한 시스템 또는 구성 요소의 적합성을 평가하기 위해 수행됩니다.

일반 테스트 시나리오:

  • 다양한 로드 조건에서 애플리케이션의 성능, 안정성 및 확장성을 확인합니다.
  • 현재 아키텍처가 최대 사용자 수준에서 애플리케이션을 지원할 수 있는지 확인합니다.
  • 어떤 구성 크기가 최상의 성능 수준을 제공하는지 결정합니다.
  • 애플리케이션 및 인프라 병목 현상을 식별합니다.
  • 새 버전의 소프트웨어가 응답 시간에 부정적인 영향을 미쳤는지 확인합니다.
  • 제품 및/또는 하드웨어를 평가하여 예상 로드 볼륨을 처리할 수 있는지 확인합니다.

성능 테스트를 수행하는 방법은 무엇입니까? 수동 테스트 또는 자동화

실제로 다음과 같은 몇 가지 단점으로 인해 성능 테스트를 수동으로 수행하는 것은 불가능합니다.

  • 더 많은 리소스가 필요합니다.
  • 동시적인 작업은 불가능합니다.
  • 적절한 시스템 모니터링이 불가능합니다.
  • 반복적인 작업을 수행하기가 쉽지 않습니다.

따라서 위의 문제를 극복하려면 성능 테스트 도구를 사용해야 합니다. 다음은 널리 사용되는 테스트 도구 목록입니다.

아직 한 가지 대상층이 빠져 있습니다. 바로 보조 기술을 통해 이러한 화면에 접근하는 사용자들입니다.

접근성 테스트 체크리스트

접근성 테스트는 화면 낭독기, 키보드 전용 탐색 또는 확대 기능을 사용하는 사람들이 다른 모든 사람과 동일한 여정을 완료할 수 있음을 확인합니다. 또한 이는 기업 구매 시 필수 요건이기도 합니다.tracts는 일반적으로 참조됩니다. WCAG 2.2 레벨 AA이러한 결함은 구조적인 문제이므로 조기에 수정하면 비용이 훨씬 적게 듭니다.

접근성 테스트를 위한 샘플 테스트 시나리오:

  • 의미 있는 이미지에는 설명적인 대체 텍스트가 포함되어 있는지 확인하고, 장식용 이미지는 보조 기술에서 숨겨져 있는지 확인합니다.
  • 폼 컨트롤에 단순히 인접한 자리 표시자 텍스트가 아닌, 프로그램적으로 연결된 레이블이 모두 있는지 확인하십시오.
  • 페이지가 키보드만으로 정상적으로 작동하는지, 각 단계에서 포커스 표시기가 보이는지 확인하십시오.
  • 텍스트와 인터랙티브 요소가 배경과의 최소 대비율을 충족하는지 확인하십시오.
  • 제목들이 논리적인 순서를 따르고 건너뛰는 부분이 없는지 확인하여 화면 낭독기의 탐색 기능이 제대로 작동하는지 확인하십시오.
  • 보조 기술에 오류 메시지가 전달되는지 확인하고 오류가 발생한 영역을 식별합니다.
  • 페이지를 200% 확대했을 때 가로 스크롤 없이도 사용할 수 있는지 확인하십시오.
  • 모달, 탭, 아코디언과 같은 사용자 정의 위젯이 올바른 역할과 상태를 노출하는지 확인합니다.

자동 스캐너는 이러한 문제의 일부만 감지하므로 수동 키보드 및 화면 판독기 테스트를 추가해야 합니다. 접근성 테스트 참고 자료에는 공구에 대한 내용이 포함되어 있습니다.

자주 묻는 질문

테스트 계획은 릴리스에 대한 범위, 일정, 리소스, 위험 및 종료 기준을 다루는 공식 문서입니다. 체크리스트는 검증해야 할 조건을 나열한 간략한 점검 목록입니다. 계획은 프로젝트 전체를 관리하고, 체크리스트는 개별 테스트 세션을 관리합니다.

Rev주요 릴리스, 새로운 기능 통합 또는 운영상의 문제가 발생할 때마다 체크리스트를 검토하십시오. 발견된 결함이 있을 때마다 해당 항목에 한 줄씩 추가하여 동일한 오류가 반복되지 않도록 해야 합니다. 업데이트되지 않은 체크리스트는 애플리케이션의 실제 동작 방식을 제대로 반영하지 못하게 됩니다.

대부분의 팀은 보안 범위를 다음과 같이 중점적으로 다룹니다. OWASP 웹 보안 테스트 가이드WCAG 2.2 접근성 및 ISTQB의 전반적인 프로세스 용어 준수 등이 포함됩니다. 이러한 참조를 통해 체크리스트는 단순히 팀의 습관에 의존하는 것이 아니라 감사 가능한 형태로 유지됩니다.

네. 요구사항, 사용자 스토리 또는 API 사양을 대규모 언어 모델에 입력하면 탄탄한 시나리오 초안을 만들 수 있습니다. 하지만 테스터는 여전히 중복을 제거하고, 모델이 추론할 수 없는 비즈니스 규칙을 추가하고, 각 항목이 실제로 검증 가능한지 확인해야 합니다.

자가 복구 기능을 갖춘 로케이터는 마크업 변경 후에도 요소를 다시 식별하여 유지 관리 작업의 대부분을 차지하는 불안정한 오류를 줄입니다. 또한 AI는 중복 결함을 그룹화하고 어떤 테스트 스위트를 먼저 실행해야 하는지 순위를 매겨 체크리스트가 늘어나더라도 회귀 테스트 주기를 짧게 유지합니다.

이 게시물을 요약하면 다음과 같습니다.