180 개 이상의 웹 애플리케이션 테스트 예제 테스트 케이스 (샘플 체크리스트)

180 web application testing example test cases

웹 애플리케이션 테스트 예제 테스트 사례 : 이것은 웹 기반 및 데스크톱 애플리케이션 모두에 대한 완전한 테스트 체크리스트입니다.

이것은 웹 애플리케이션 테스트 예제 테스트 케이스 / 시나리오의 매우 포괄적 인 목록입니다. 우리의 목표는 지금까지 작성된 가장 포괄적 인 테스트 체크리스트 중 하나를 공유하는 것이며 아직 완료되지 않았습니다.

앞으로도 더 많은 테스트 사례와 시나리오를 통해이 게시물을 계속 업데이트 할 예정입니다. 지금 읽을 시간이 없으시다면 언제든지 친구들과 공유하고 나중을 위해 북마크 해주세요.

테스트 케이스 작성 프로세스의 필수 부분으로 테스트 체크리스트를 작성하십시오. 이 체크리스트를 사용하면 수백 개의 테스트 케이스 웹 또는 데스크탑 애플리케이션 테스트 용.

이들은 모두 일반적인 테스트 케이스이며 거의 모든 종류의 애플리케이션에 적용 할 수 있습니다. 프로젝트에 대한 테스트 케이스를 작성하는 동안이 테스트를 참조하면 대부분의 테스트 유형 SRS 문서에 제공된 애플리케이션 별 비즈니스 규칙은 제외됩니다.

이것은 일반적인 체크리스트이지만 애플리케이션 별 테스트 외에도 아래 테스트 케이스를 사용하여 특정 요구에 맞는 표준 테스트 체크리스트를 준비하는 것이 좋습니다.

권장 도구 :

테스트 케이스 작성 프로세스를 계속하기 전에이 테스트 케이스 관리 도구를 다운로드하는 것이 좋습니다. 이렇게하면이 자습서에서 언급 한 테스트 계획 및 테스트 사례 작성 프로세스가 쉬워집니다.

=> TestRail 테스트 케이스 관리 도구 다운로드

테스트를위한 체크리스트 사용의 중요성

#1) 애플리케이션에 대한 재사용 가능한 테스트 케이스의 표준 저장소를 유지하면 가장 일반적인 버그를 더 빨리 포착 할 수 있습니다.
#두) 체크리스트는 애플리케이션의 새 버전에 대한 테스트 케이스 작성을 신속하게 완료하는 데 도움이됩니다.
#삼) 테스트 케이스를 재사용하면 반복적 인 테스트를 작성하기위한 리소스 비용을 절약 할 수 있습니다.
# 4) 중요한 테스트 케이스는 항상 다루어 지므로 잊는 것이 거의 불가능합니다.
# 5) 개발자는 테스트 체크리스트를 참조하여 가장 일반적인 문제가 개발 단계 자체에서 수정되었는지 확인할 수 있습니다.

노트:

• 다른 사용자 역할로 이러한 시나리오를 실행하십시오. 관리자, 게스트 사용자 등
• 웹 애플리케이션의 경우 다음 시나리오 여러 브라우저에서 테스트해야합니다. IE, FF, Chrome 및 Safari와 같이 클라이언트에서 승인 한 버전이 있습니다.
• 1024 x 768, 1280 x 1024 등과 같은 다양한 화면 해상도로 테스트하십시오.
• 애플리케이션은 LCD, CRT, 노트북, 태블릿 및 휴대폰과 같은 다양한 디스플레이에서 테스트해야합니다.
• Windows, Mac, Linux 운영 체제 등과 같은 다양한 플랫폼에서 애플리케이션을 테스트합니다.

학습 내용 :

• 180 개 이상의 웹 애플리케이션 테스트 예제 테스트 케이스
  • 일반 테스트 시나리오
  • GUI 및 사용성 테스트 시나리오
    • 필터 기준에 대한 테스트 시나리오
    • 결과 그리드에 대한 테스트 시나리오
    • 창에 대한 테스트 시나리오
  • 데이터베이스 테스트 테스트 시나리오
    • 이미지 업로드 기능에 대한 테스트 시나리오
    • 이메일 전송을위한 테스트 시나리오
    • Excel 내보내기 기능에 대한 테스트 시나리오
  • 성능 테스트 테스트 시나리오
  • 보안 테스트 테스트 시나리오
• 100 개 이상의 즉시 실행 가능한 테스트 케이스 (체크리스트)
  • AUT의 가장 일반적인 구성 요소에 대한 전체 체크리스트 (테스트 케이스)
    • 체크리스트 # 1 : 모바일 테스트 체크리스트
    • 체크리스트 # 2 : 양식 / 화면 테스트 체크리스트
    • 체크리스트 # 3 : 텍스트 상자 필드 테스트 체크리스트
    • 체크리스트 # 4 : 목록 상자 또는 드롭 다운 목록 테스트 체크리스트
    • 체크리스트 # 5 : 체크 박스 필드 테스트 체크리스트
    • 체크리스트 # 6 : 라디오 버튼 테스트 체크리스트
    • 체크리스트 # 7 : 날짜 필드 테스트 시나리오
    • 체크리스트 # 8 : 저장 버튼 테스트 시나리오
    • 체크리스트 # 9 : 취소 버튼 테스트 시나리오
    • 체크리스트 # 10 : 버튼 테스트 포인트 삭제
    • 체크리스트 # 11 : 저장 또는 업데이트 후 영향을받는 영역 확인
    • 체크리스트 # 12 : 데이터 그리드 테스트 목록
  • 추천 도서

180 개 이상의 웹 애플리케이션 테스트 예제 테스트 케이스

가정 : 애플리케이션이 다음 기능을 지원한다고 가정합니다.

• 다양한 분야의 양식
• 자식 창
• 응용 프로그램은 데이터베이스와 상호 작용합니다.
• 다양한 검색 필터 기준 및 표시 결과
• 이미지 업로드
• 이메일 보내기 기능
• 데이터 내보내기 기능

일반 테스트 시나리오

1. 모든 필수 필드의 유효성을 검사하고 별표 (*) 기호로 표시해야합니다.
2. 유효성 검사 오류 메시지는 올바른 위치에 올바르게 표시되어야합니다.
3. 모든 오류 메시지는 동일한 CSS 스타일 ( 예를 들어 붉은 색 사용)
4. 일반 확인 메시지는 오류 메시지 스타일 ( 예를 들어 녹색 사용)
5. 도구 설명 텍스트는 의미가 있어야합니다.
6. 드롭 다운 필드에는 첫 번째 항목이 비어 있거나‘선택’과 같은 텍스트가 있어야합니다.
7. 페이지의 모든 레코드에 대한 '삭제 기능'은 확인을 요청해야합니다.
8. 페이지가 레코드 추가 / 삭제 / 업데이트 기능을 지원하는 경우 모든 레코드 선택 / 선택 해제 옵션을 제공해야합니다.
9. 금액 값은 올바른 통화 기호로 표시되어야합니다.
10. 기본 페이지 정렬이 제공되어야합니다.
11. 재설정 버튼 기능은 모든 필드의 기본값을 설정해야합니다.
12. 모든 숫자 값은 올바른 형식이어야합니다.
13. 입력 필드에서 최대 필드 값을 확인해야합니다. 지정된 최대 제한보다 큰 입력 값은 허용되거나 데이터베이스에 저장되지 않아야합니다.
14. 모든 입력 필드에서 특수 문자를 확인하십시오.
15. 필드 레이블은 표준이어야합니다. 사용자의 이름을 입력하는 필드는 '이름'으로 올바르게 표시되어야합니다.
16. 모든 레코드에 대한 추가 / 편집 / 삭제 작업 후 페이지 정렬 기능을 확인합니다.
17. 시간 초과 기능을 확인합니다. 제한 시간 값은 구성 가능해야합니다. 작업 시간 초과 후 응용 프로그램 동작을 확인하십시오.
18. 애플리케이션에서 사용되는 쿠키를 확인합니다.
19. 다운로드 가능한 파일이 올바른 파일 경로를 가리키는 지 확인합니다.
20. 모든 리소스 키는 하드 코딩 대신 구성 파일 또는 데이터베이스에서 구성 할 수 있어야합니다.
21. 리소스 키의 이름을 지정하려면 표준 규칙을 따라야합니다.
22. 모든 웹 페이지의 마크 업을 확인 (구문 오류에 대한 HTML 및 CSS 확인)하여 표준을 준수하는지 확인합니다.
23. 응용 프로그램 충돌 또는 사용할 수없는 페이지는 오류 페이지로 리디렉션되어야합니다.
24. 모든 페이지의 텍스트에서 맞춤법 및 문법 오류를 확인하십시오.
25. 문자 입력 값으로 숫자 입력 필드를 확인합니다. 적절한 유효성 검사 메시지가 나타납니다.
26. 숫자 필드에 허용되는 경우 음수를 확인합니다.
27. 십진수 값이있는 필드 수를 확인합니다.
28. 모든 페이지에서 사용 가능한 버튼의 기능을 확인합니다.
29. 사용자는 제출 버튼을 빠르게 연속적으로 눌러 페이지를 두 번 제출할 수 없어야합니다.
30. 0으로 나누기 오류는 모든 계산에 대해 처리되어야합니다.
31. 첫 번째와 마지막 위치가 공백 인 입력 데이터는 올바르게 처리되어야합니다.

PC 용 최고의 무료 유튜브 다운로더

GUI 및 사용성 테스트 시나리오

1. 페이지의 모든 필드 ( 예를 들어 텍스트 상자, 라디오 옵션, 드롭 다운 목록)이 올바르게 정렬되어야합니다.
2. 숫자 값은 달리 명시되지 않는 한 정확하게 정당화되어야합니다.
3. 필드 레이블, 열, 행, 오류 메시지 등 사이에 충분한 공간을 제공해야합니다.
4. 스크롤바는 필요한 경우에만 활성화되어야합니다.
5. 헤드 라인, 설명 텍스트, 레이블, 내야 데이터 및 그리드 정보의 글꼴 크기, 스타일 및 색상은 SRS에 지정된대로 표준이어야합니다.
6. 설명 텍스트 상자는 여러 줄로 표시되어야합니다.
7. 비활성화 된 필드는 회색으로 표시되어야하며 사용자는 이러한 필드에 포커스를 설정할 수 없어야합니다.
8. 입력 텍스트 필드를 클릭하면 마우스 화살표 포인터가 커서로 변경됩니다.
9. 사용자가 드롭 다운 선택 목록을 입력 할 수 없어야합니다.
10. 사용자가 입력 한 정보는 페이지 제출에 오류 메시지가있을 때 그대로 유지되어야합니다. 사용자는 오류를 수정하여 양식을 다시 제출할 수 있어야합니다.
11. 오류 메시지에 적절한 필드 레이블이 사용되었는지 확인합니다.
12. 드롭 다운 필드 값은 정의 된 정렬 순서로 표시되어야합니다.
13. Tab 및 Shift + Tab 순서가 제대로 작동해야합니다.
14. 기본 라디오 옵션은 페이지로드시 미리 선택되어야합니다.
15. 필드 별 및 페이지 수준 도움말 메시지를 사용할 수 있어야합니다.
16. 오류가 발생한 경우 올바른 필드가 강조 표시되었는지 확인합니다.
17. 드롭 다운 목록 옵션을 읽을 수 있고 필드 크기 제한으로 인해 잘리지 않는지 확인합니다.
18. 페이지의 모든 버튼은 키보드 단축키로 액세스 할 수 있어야하며 사용자는 키보드를 사용하여 모든 작업을 수행 할 수 있어야합니다.
19. 모든 페이지에 깨진 이미지가 있는지 확인하십시오.
20. 모든 페이지에 끊어진 링크가 있는지 확인합니다.
21. 모든 페이지에는 제목이 있어야합니다.
22. 업데이트 또는 삭제 작업을 수행하기 전에 확인 메시지가 표시되어야합니다.
23. 응용 프로그램이 사용 중일 때 모래 시계가 표시되어야합니다.
24. 페이지 텍스트는 왼쪽 정렬되어야합니다.
25. 사용자는 하나의 라디오 옵션과 확인란 조합 만 선택할 수 있어야합니다.

필터 기준에 대한 테스트 시나리오

1. 사용자는 페이지의 모든 매개 변수를 사용하여 결과를 필터링 할 수 있어야합니다.
2. 상세 검색 기능은 사용자가 선택한 모든 검색 매개 변수와 함께 검색 페이지를로드해야합니다.
3. 검색 작업을 수행하는 데 필요한 필터 기준이 하나 이상있는 경우 사용자가 필터 기준을 선택하지 않고 페이지를 제출할 때 적절한 오류 메시지가 표시되는지 확인합니다.
4. 하나 이상의 필터 기준 선택이 필수가 아닌 경우 사용자는 페이지를 제출할 수 있어야하며 기본 검색 기준을 사용하여 결과를 쿼리해야합니다.
5. 필터 기준에 대한 모든 유효하지 않은 값에 대해 적절한 유효성 검사 메시지가 표시되어야합니다.

결과 그리드에 대한 테스트 시나리오

1. 결과 페이지를로드하는 데 기본 시간보다 오래 걸리는 경우 페이지로드 기호가 표시되어야합니다.
2. 모든 검색 매개 변수가 결과 그리드에 표시된 데이터를 가져 오는 데 사용되는지 확인합니다.
3. 총 결과 수가 결과 표에 표시되어야합니다.
4. 검색에 사용 된 검색 기준이 결과 그리드에 표시되어야합니다.
5. 결과 그리드 값은 기본 열로 정렬되어야합니다.
6. 정렬 된 열은 정렬 아이콘과 함께 표시되어야합니다.
7. 결과 그리드에는 올바른 값을 가진 지정된 모든 열이 포함되어야합니다.
8. 오름차순 및 내림차순 정렬 기능은 데이터 정렬이 지원하는 열에 대해 작동해야합니다.
9. 결과 그리드는 적절한 열과 행 간격으로 표시되어야합니다.
10. 페이지 당 기본 결과 수보다 많은 결과가있을 때 페이지 매김을 활성화해야합니다.
11. 다음, 이전, 첫 번째 및 마지막 페이지 페이지 매김 기능을 확인합니다.
12. 중복 레코드는 결과 그리드에 표시되지 않아야합니다.
13. 모든 열이 표시되고 필요한 경우 수평 스크롤바가 활성화되어 있는지 확인합니다.
14. 동적 열 (다른 열 값을 기반으로 동적으로 계산되는 값이있는 열)의 데이터를 확인합니다.
15. 보고서를 표시하는 결과 그리드의 경우 '합계'행을 확인하고 모든 열의 합계를 확인합니다.
16. 보고서를 표시하는 결과 그리드의 경우 페이지 매김이 활성화되고 사용자가 다음 페이지로 이동할 때 '합계'행 데이터를 확인합니다.
17. 열 값을 표시하는 데 적절한 기호가 사용되었는지 확인합니다. 백분율 계산을 위해 % 기호가 표시되어야합니다.
18. 결과 그리드 데이터를 확인하여 날짜 범위가 활성화되었는지 확인합니다.

창에 대한 테스트 시나리오

1. 기본 창 크기가 올바른지 확인합니다.
2. 자식 창 크기가 올바른지 확인합니다.
3. 페이지에 기본 포커스가있는 필드가 있는지 확인합니다 (일반적으로 포커스는 화면의 첫 번째 입력 필드에 설정되어야 함).
4. 부모 / 열기 창을 닫을 때 자식 창이 닫히는 지 확인합니다.
5. 하위 창이 열리면 사용자는 배경 또는 상위 창에서 필드를 사용하거나 업데이트 할 수 없어야합니다.
6. 창 최소화, 최대화 및 닫기 기능을 확인합니다.
7. 창 크기를 조정할 수 있는지 확인합니다.
8. 부모 및 자식 창에 대한 스크롤 막대 기능을 확인합니다.
9. 자식 창의 취소 버튼 기능을 확인합니다.

데이터베이스 테스트 테스트 시나리오

1. 성공적인 페이지 제출시 데이터베이스에 올바른 데이터가 저장되고 있는지 확인합니다.
2. null 값을 허용하지 않는 열의 값을 확인합니다.
3. 데이터 무결성을 확인합니다. 데이터는 설계에 따라 단일 또는 다중 테이블에 저장되어야합니다.
4. 인덱스 이름은 표준에 따라 제공되어야합니다. IND__
5. 테이블에는 기본 키 열이 있어야합니다.
6. 테이블 열에는 사용 가능한 설명 정보가 있어야합니다 (만든 날짜, 만든 사람 등과 같은 감사 열 제외).
7. 모든 데이터베이스에 대해 추가 / 업데이트 작업 로그를 추가해야합니다.
8. 필요한 테이블 인덱스를 만들어야합니다.
9. 작업이 성공적으로 완료된 경우에만 데이터가 데이터베이스에 커밋되었는지 확인합니다.
10. 트랜잭션 실패시 데이터를 롤백해야합니다.
11. 데이터베이스 이름은 애플리케이션 유형 (예 : 테스트, UAT, 샌드 박스, 라이브)에 따라 제공되어야합니다 (표준은 아니지만 데이터베이스 유지 관리에 도움이 됨).
12. 데이터베이스 논리적 이름은 데이터베이스 이름에 따라 지정해야합니다 (다시 말하지만 이는 표준이 아니지만 DB 유지 관리에 유용합니다).
13. 저장 프로시 저는 접두사 'sp_'로 이름을 지정하면 안됩니다.
14. 테이블 감사 열의 값 (예 : 만든 날짜, 만든 사람, 업데이트 한 사람, 업데이트 한 사람, 삭제, 삭제 된 데이터, 삭제 한 사람 등)이 제대로 채워져 있는지 확인합니다.
15. 저장 중 입력 데이터가 잘리지 않았는지 확인합니다. 페이지와 데이터베이스 스키마에서 사용자에게 표시되는 필드 길이는 동일해야합니다.
16. 최소, 최대 및 부동 값이있는 숫자 필드를 확인합니다.
17. 음수 값이있는 숫자 필드를 확인합니다 (승인 및 비 승인 모두).
18. 라디오 버튼과 드롭 다운 목록 옵션이 데이터베이스에 올바르게 저장되었는지 확인합니다.
19. 데이터베이스 필드가 올바른 데이터 유형 및 데이터 길이로 디자인되었는지 확인하십시오.
20. 기본 키, 외래 키 등과 같은 모든 테이블 제약 조건이 올바르게 구현되었는지 확인합니다.
21. 샘플 입력 데이터로 저장 프로 시저 및 트리거를 테스트합니다.
22. 데이터를 데이터베이스에 커밋하기 전에 입력 필드 앞뒤 공백을 잘라야합니다.
23. 기본 키 열에는 널 값이 허용되지 않아야합니다.

이미지 업로드 기능에 대한 테스트 시나리오

(다른 파일 업로드 기능에도 적용 가능)
1. 업로드 된 이미지 경로를 확인합니다.
2. 이미지 업로드 및 변경 기능을 확인합니다.
3. 확장자가 다른 이미지 파일 ( 예를 들어 JPEG, PNG, BMP 등)
4. 파일 이름에 공백이나 기타 허용 된 특수 문자가있는 이미지로 이미지 업로드 기능을 확인합니다.
5. 중복 이름 이미지 업로드를 확인합니다.
6. 허용되는 최대 크기보다 큰 이미지 크기로 이미지 업로드를 확인합니다. 적절한 오류 메시지가 표시되어야합니다.
7. 이미지 이외의 파일 형식 ( 예를 들어 txt, doc, pdf, exe 등). 적절한 오류 메시지가 표시되어야합니다.
8. 지정된 높이와 너비 (정의 된 경우)의 이미지가 허용되는지 확인합니다. 그렇지 않으면 거부됩니다.
9. 큰 이미지의 경우 이미지 업로드 진행률 표시 줄이 나타납니다.
10. 업로드 프로세스 사이에 취소 버튼 기능이 작동하는지 확인합니다.
11. 파일 선택 대화 상자에 지원되는 파일 만 나열되어 있는지 확인합니다.
12. 여러 이미지 업로드 기능을 확인합니다.
13. 업로드 후 이미지 품질을 확인합니다. 업로드 후 이미지 품질을 변경하면 안됩니다.
14. 사용자가 업로드 된 이미지를 사용 / 볼 수 있는지 확인합니다.

이메일 전송을위한 테스트 시나리오

(이메일 작성 또는 검증을위한 테스트 사례는 여기에 포함되지 않습니다.)
(이메일 관련 테스트를 실행하기 전에 더미 이메일 주소를 사용하십시오)
1. 이메일 템플릿은 모든 이메일에 표준 CSS를 사용해야합니다.
2. 이메일을 보내기 전에 이메일 주소를 확인해야합니다.
3. 이메일 본문 템플릿의 특수 문자는 올바르게 처리되어야합니다.
4. 언어 별 문자 ( 예를 들어 러시아어, 중국어 또는 독일어 문자)는 이메일 본문 템플릿에서 올바르게 처리되어야합니다.
5. 이메일 제목은 비워 둘 수 없습니다.
6. 이메일 템플릿에 사용 된 자리 표시 자 필드는 실제 값으로 바꿔야합니다. {이름} {성}은 모든 수신자에 대해 개인의 성과 이름으로 적절하게 대체되어야합니다.
7. 동적 값이있는 보고서가 이메일 본문에 포함되어 있고 보고서 데이터가 올바르게 계산되어야하는 경우.
8. 이메일 발신자 이름은 비워 둘 수 없습니다.
9. 이메일은 Outlook, Gmail, Hotmail, Yahoo!와 같은 다른 이메일 클라이언트에서 확인해야합니다. 메일 등
10. TO, CC 및 BCC 필드를 사용하여 이메일 기능을 보내려면 선택합니다.
11. 일반 텍스트 이메일을 확인합니다.
12. HTML 형식 이메일을 확인합니다.
13. 이메일 머리글과 바닥 글에서 회사 로고, 개인 정보 보호 정책 및 기타 링크를 확인하십시오.
14. 첨부 파일이있는 이메일을 확인합니다.
15. 이메일 기능을 단일, 다중 또는 배포 목록 수신자에게 보내려면 선택합니다.
16. 이메일 주소에 대한 회신이 올바른지 확인하십시오.
17. 대량의 이메일을 보내려면 선택합니다.

Excel 내보내기 기능에 대한 테스트 시나리오

1. 파일은 적절한 파일 확장자로 내 보내야합니다.
2. 내 보낸 Excel 파일의 파일 이름은 표준에 따라야합니다. 예를 들어 파일 이름이 타임 스탬프를 사용하는 경우 파일을 내보낼 때 실제 타임 스탬프로 올바르게 대체되어야합니다.
3. 내 보낸 Excel 파일에 날짜 열이 포함되어 있으면 날짜 형식을 확인합니다.
4. 숫자 또는 통화 값에 대한 숫자 형식을 확인합니다. 형식은 페이지에 표시된 것과 동일해야합니다.
5. 내 보낸 파일에는 적절한 열 이름이있는 열이 있어야합니다.
6. 기본 페이지 정렬은 내 보낸 파일에서도 수행되어야합니다.
7. Excel 파일 데이터는 모든 페이지에 대한 머리글 및 바닥 글 텍스트, 날짜, 페이지 번호 등의 값으로 적절하게 형식화되어야합니다.
8. 페이지에 표시된 데이터와 내 보낸 Excel 파일이 동일한 지 확인합니다.
9. 페이지 매김이 활성화 된 경우 내보내기 기능을 확인합니다.
10. 내보내기 버튼이 내 보낸 파일 유형에 따라 적절한 아이콘이 표시되는지 확인하고, 예를 들어 xls 파일의 Excel 파일 아이콘
11. 매우 큰 파일의 내보내기 기능을 확인합니다.
12. 특수 문자가 포함 된 페이지의 내보내기 기능을 확인합니다. 이러한 특수 문자가 Excel 파일에서 제대로 내보내 졌는지 확인하십시오.

성능 테스트 테스트 시나리오

1. 페이지로드 시간이 허용 범위 내에 있는지 확인하십시오.
2. 느린 연결에서 페이지로드를 확인합니다.
3. 경부 하, 정상, 보통 및 고부하 조건에서 조치에 대한 응답 시간을 확인하십시오.
4. 데이터베이스 저장 프로 시저 및 트리거의 성능을 확인합니다.
5. 데이터베이스 쿼리 실행 시간을 확인합니다.
6. 애플리케이션의 부하 테스트를 확인합니다.
7. 응용 프로그램의 스트레스 테스트를 확인합니다.
8. 최대 부하 조건에서 CPU 및 메모리 사용량을 확인합니다.

보안 테스트 테스트 시나리오

1. SQL 주입 공격을 확인합니다.
2. 보안 페이지는 HTTPS 프로토콜을 사용해야합니다.
3. 페이지 크래시가 애플리케이션 또는 서버 정보를 나타내지 않아야합니다. 이에 대한 오류 페이지가 표시되어야합니다.
4. 입력에서 특수 문자를 이스케이프하십시오.
5. 오류 메시지에 민감한 정보가 드러나서는 안됩니다.
6. 모든 자격 증명은 암호화 된 채널을 통해 전송되어야합니다.
7. 암호 보안 및 암호 정책 시행을 테스트합니다.
8. 응용 프로그램 로그 아웃 기능을 확인합니다.
9. 무차별 대입 공격을 확인합니다.
10. 쿠키 정보는 암호화 된 형식으로 만 저장되어야합니다.
11. 타임 아웃 또는 로그 아웃 후 세션 쿠키 기간 및 세션 종료를 확인합니다.
11. 세션 토큰은 보안 채널을 통해 전송되어야합니다.
13. 비밀번호는 쿠키에 저장되어서는 안됩니다.
14. 서비스 거부 공격 테스트.
15. 메모리 누수를 테스트합니다.
16. 브라우저 주소 표시 줄에서 변수 값을 조작하여 무단 애플리케이션 액세스를 테스트합니다.
17. exe 파일이 서버에 업로드 및 실행되지 않도록 파일 확장자 처리를 테스트합니다.
18. 암호 및 신용 카드 정보와 같은 민감한 필드는 자동 완성 기능을 활성화 할 필요가 없습니다.
19. 파일 업로드 기능은 파일 유형 제한을 사용해야하며 업로드 된 파일을 검사하기 위해 바이러스 백신도 사용해야합니다.
20. 디렉토리 목록이 금지되어 있는지 확인하십시오.
21. 입력하는 동안 암호 및 기타 민감한 필드를 가려야합니다.
22. 비밀번호 분실 기능이 지정된 시간 이후 임시 비밀번호 만료와 같은 기능으로 보안이되어 있는지 확인하고 비밀번호를 변경하거나 새 비밀번호를 요청하기 전에 보안 질문을합니다.
23. CAPTCHA 기능을 확인합니다.
24. 중요한 이벤트가 로그 파일에 기록되어 있는지 확인합니다.
25. 액세스 권한이 올바르게 구현되었는지 확인합니다.

침투 테스트 테스트 케이스 – 침투 테스트에 대한 약 41 개의 테스트 케이스를 나열했습니다. 이 페이지 .

정말 감사합니다 데 반슈 라바 니야 (I-link Infosoft에서 근무하는 선임 QA 엔지니어)이 포괄적 인 테스트 체크리스트를 준비하는 데 도움을 주셨습니다.

웹 및 데스크톱 응용 프로그램 기능에 대한 거의 모든 표준 테스트 시나리오를 다루려고 노력했습니다. 그러나 여전히 이것이 완전한 체크리스트가 아니라는 것을 알고 있습니다. 다른 프로젝트의 테스터는 자신의 경험을 기반으로 한 자체 테스트 체크리스트를 가지고 있습니다.

업데이트 :

100 개 이상의 즉시 실행 가능한 테스트 케이스 (체크리스트)

이 목록을 사용하여 AUT의 가장 일반적인 구성 요소를 테스트 할 수 있습니다.

AUT의 가장 일반적인 구성 요소를 매번 효과적으로 테스트하는 방법은 무엇입니까?

이 기사는 AUT의 가장 널리 발견되는 요소에 대한 일반적인 검증 목록입니다. 테스터의 편의를 위해 정리했습니다 (특히 단기 릴리스가 자주 발생하는 민첩한 환경에서).

모든 AUT (Application Under Test)는 고유하며 매우 구체적인 비즈니스 목적을 가지고 있습니다. AUT의 개별 측면 (모듈)은 AUT가 지원하는 비즈니스의 성공에 중요한 여러 작업 / 작업을 충족합니다.

각 AUT는 다르게 설계되었지만 대부분의 페이지 / 화면 / 애플리케이션에서 접하는 개별 구성 요소 / 필드는 다소 유사한 동작으로 동일합니다.

AUT의 몇 가지 공통 구성 요소 :

• 저장, 업데이트, 삭제, 재설정, 취소, 확인 – 링크 / 단추 – 개체의 레이블이 나타내는 기능입니다.
• 항상 동일한 방식으로 작동하는 텍스트 상자, 드롭 다운, 체크 박스, 라디오 버튼, 날짜 제어 필드.
• 보고서를 용이하게하기위한 데이터 그리드, 영향을받는 영역 등.

이러한 개별 요소가 애플리케이션의 전체 기능에 기여하는 방식은 다를 수 있지만 유효성을 검사하는 단계는 항상 동일합니다.

다음에 대한 가장 일반적인 유효성 검사 목록을 계속 진행하겠습니다. 웹 또는 데스크탑 애플리케이션 페이지 / 양식.

노트 : 일반적으로 테스트 케이스의 일부인 실제 결과, 예상 결과, 테스트 데이터 및 기타 매개 변수는 단순성을 위해 생략됩니다. 일반적인 체크리스트 접근 방식이 사용됩니다.

허용 기준이있는 사용자 스토리 예

이 포괄적 인 체크리스트의 목적 :

이러한 체크리스트 (또는 테스트 사례)의 주요 목적은 너무 많은 시간을 소비하지 않고 동시에 테스트 품질을 손상시키지 않으면 서 현장 수준 검증에서 최대 테스트 범위를 보장하는 것입니다.

결국 제품에 대한 신뢰는 모든 단일 요소를 가능한 한 최대한 테스트해야만 얻을 수 있습니다.

AUT의 가장 일반적인 구성 요소에 대한 전체 체크리스트 (테스트 케이스)

노트 :이 체크리스트는 Microsoft Excel 형식으로 사용할 수 있습니다 (문서 끝 부분에 다운로드 제공). 통과 / 실패 결과 및 상태와 함께 동일한 파일에서 테스트 실행을 추적 할 수도 있습니다.

이것은 QA 팀이 AUT의 가장 일반적인 구성 요소를 테스트하고 추적하는 올인원 리소스가 될 수 있습니다.애플리케이션에 특정한 테스트 케이스를 추가하거나 업데이트 할 수 있습니다.더 포괄적 인 목록으로 만드세요.

체크리스트 # 1 : 모바일 테스트 체크리스트

체크리스트 # 2 : 양식 / 화면 테스트 체크리스트

체크리스트 # 3 : 텍스트 상자 필드 테스트 체크리스트

텍스트 상자 :

텍스트 상자의 BVA (크기) :

최소->-> 통과
최소 -1 —> —> 실패
최소 + 1->-> 통과
Max-1 —> —> 통과
Max + 1 —> —> 실패
최대 —> —> 통과

텍스트 상자 용 ECP :

체크리스트 # 4 : 목록 상자 또는 드롭 다운 목록 테스트 체크리스트

목록 상자 / 드롭 다운 :

체크리스트 # 5 : 체크 박스 필드 테스트 체크리스트

체크 박스 :

체크리스트 # 6 : 라디오 버튼 테스트 체크리스트

라디오 버튼:

체크리스트 # 7 : 날짜 필드 테스트 시나리오

날짜 필드 :

체크리스트 # 8 : 저장 버튼 테스트 시나리오

저장 / 업데이트 :

체크리스트 # 9 : 취소 버튼 테스트 시나리오

취소:

체크리스트 # 10 : 버튼 테스트 포인트 삭제

지우다:

체크리스트 # 11 : 저장 또는 업데이트 후 영향을받는 영역 확인

저장 / 업데이트 후 :

체크리스트 # 12 : 데이터 그리드 테스트 목록

데이터 그리드 :

링크 기능 편집

이 목록이 완전하지는 않지만 실제로 광범위합니다.

다운로드==>이 모든 체크리스트를 MS Excel 형식으로 다운로드 할 수 있습니다. Excel 형식으로 다운로드

참고 사항 :

1. 필요에 따라 각 범주 / 각 필드에 대한 추가 테스트를 추가하거나 기존 필드를 제거 할 수 있습니다. 즉, 이러한 목록은 완전히 사용자 지정할 수 있습니다.
2. 테스트 스위트에 필드 수준 유효성 검사를 포함해야하는 경우 해당 목록을 선택하여 테스트하려는 화면 / 페이지에 사용하기 만하면됩니다.
3. 합격 / 불합격 상태를 업데이트하여 기능을 나열하고 검증하고 테스트 결과를 기록하는 원 스톱 상점이되도록 체크리스트를 유지합니다.

아래 댓글 섹션에 더 많은 테스트 케이스 / 시나리오 또는 부정적인 테스트 케이스를 추가하여 이것을 완전한 체크리스트로 만드십시오.

또한 이것을 친구들과 공유해 주시면 감사하겠습니다!

이전 튜토리얼 | NEXT 튜토리얼

추천 도서

• 테스트 케이스 작성 방법 : 예제가 포함 된 궁극적 인 가이드
• 웹 응용 프로그램 쿠키 테스트를위한 웹 사이트 쿠키 테스트 및 테스트 사례
• 테스트 케이스 예제가 포함 된 샘플 테스트 케이스 템플릿 (다운로드)
• 최고의 소프트웨어 테스트 도구 2021 (QA 테스트 자동화 도구)
• 웹 애플리케이션 보안 테스트 가이드
• 응용 프로그램 테스트 – 소프트웨어 테스트의 기초로!
• 장치에 애플리케이션 설치 및 Eclipse에서 테스트 시작
• TDD 대 BDD-예제를 통해 차이점 분석