email validation testing
오늘의 튜토리얼은 모든 애플리케이션의 이메일 기능 테스트에 관한 것입니다.
대부분의 웹 및 모바일 애플리케이션에서 이메일 기능의 유효성 검사는 시스템의 다른 구성 요소와 함께 이메일 구성 요소의 품질을 보장하기 위해 테스트의 가장 중요한 부분 중 하나로 간주됩니다.
다른 시나리오에서 트리거 된 이메일은 이메일 템플릿, 이메일의 링크 / 단추, 보낸 사람,받는 사람, 참조, 숨은 참조 필드, 첨부 파일, 이메일 알림에 따른 콘텐츠 등을 포함하는 모든 구성 요소를 확인하여 유효성을 검사하는 것으로 간주됩니다.
학습 내용 :
이메일 테스트가 필요한 이유는 무엇입니까?
시스템의 각 구성 요소 (웹 / 모바일 응용 프로그램)는 이메일을 보내는 용도가 다를 수 있습니다. 구성 요소 간의 통합 이메일은 적절한 알림을 통해 최종 사용자에게 도달하는 데 중요한 역할을합니다. 이 기능의 유효성을 검사 할 때 과실로 인해 오해, 고객에 대한 나쁜 이름, 해킹 등이 발생할 수 있습니다.
예를 들면 , 사용자가 비밀번호를 재설정하라는 이메일을받은 상황을 상상해보십시오. 비밀번호 재설정 링크 / 버튼 또는 브라우저에서 복사 붙여 넣기를 위해 제공된 URL이 작동하지 않으면 어떻게됩니까? 여기에 남은 유일한 옵션은 지루한 일이 될 수있는 고객 지원팀에 문의하는 것입니다. 사용자가 10-15 일 전부터 청구서 지불 기한에 대한 이메일을 매일 계속 수신하거나 기한이 지난 후 알림을받는 상황을 상상해보십시오. 통과했습니다. -짜증나 지 않나요 ??
이메일은 정확한 정보로 사용자를 최신 상태로 유지하기위한 것이므로 우리 삶의 필수적인 부분이 된 많은 시나리오가 있습니다.
이메일에 대한 일반적인 실시간 시나리오 및 검증 포인트
이메일 테스트의 유효성 검사 지점은 유형마다, 그리고 애플리케이션마다 다릅니다. 일반적으로 모든 이메일은 템플릿 (애플리케이션 로고, 애플리케이션 이름, 사용자 주소 지정, 바닥 글 내용 – 저작권, 고객 지원 세부 정보 포함), 다른 시간대의 날짜 및 타임 스탬프에 대해 유효성을 검사해야합니다.
여기에서는 거의 모든 사람이 알고있는 몇 가지 일반적인 유형의 이메일에 대해 설명합니다 (아래에 제공된 모든 유효성 검사 포인트는 테스터가 애플리케이션의 이메일을 테스트하는 동안 수행해야하는 기본 검사입니다).
# 1) 활성화 이메일
사용자가 애플리케이션에 처음 등록 할 때 이메일로 전송 된 활성화 링크를 클릭하여 계정을 활성화해야합니다. 또한 사용자의 지정된 이메일 주소가 유효하고 액세스 가능한지 확인합니다.
검증 포인트는 다음과 같습니다.
- 활성화 링크 또는 버튼 – 클릭하면 다음을 수행해야합니다.
- 로그인 한 사용자 계정으로 사용자를 각 애플리케이션의 페이지로 이동
- 이메일을 통해 신청 페이지에 성공적으로 도달하면 사용자의 이메일 계정이 자동으로 확인되어야합니다.
- 기간 – 링크를 클릭하고 확인해야하는 기간을 확인합니다.
- 지정된 기간 내에 확인
- 기간이 지난 후 확인을 시도하십시오. 계정이 활성화되지 않아야하며 이메일이 확인되지 않은 상태로 유지되어야합니다
# 2) 비밀번호 분실
사용자가 애플리케이션에 로그인하기 위해 비밀번호를 잊어 버린 경우 비밀번호를 잊어 버림 흐름을 수행하여 비밀번호 재설정 링크가 포함 된 이메일을받을 수 있습니다 (기능은 애플리케이션마다 다르며 일반적인 것입니다).
검증 포인트는 다음과 같습니다.
- 비밀번호 재설정 링크 :
- 이를 클릭하면 사용자가 각 애플리케이션의 페이지로 이동하여 비밀번호를 재설정 할 수 있습니다.
- 일부 애플리케이션은 비밀번호 재설정 페이지를 표시하기 전에 사용자에게 보안 질문에 답하도록 요청하고 일부 애플리케이션에는 비밀번호 재설정 페이지 자체와 통합 된 보안 질문이 있으며 일부 애플리케이션에는이 기능이 전혀 없습니다.
- 사용자가 비밀번호를 성공적으로 재설정하면 수신 된 비밀번호 분실 이메일의 링크가 비활성화되고 작동하지 않습니다.
- 사용자가 비밀번호 재설정 흐름을 취소하면 수신 된 비밀번호 분실 이메일의 링크가 활성화 된 상태로 유지되어야합니다.
- 기간 – 비밀번호 재설정을 위해 링크를 클릭해야하는 기간을 확인합니다.
- 링크를 클릭하고 지정된 기간 내에 성공적으로 비밀번호를 재설정하십시오.
- 기간이 지난 후 링크를 클릭하십시오. 링크는 비활성화되고 만료되어야합니다.
# 3) 마감일 알림
특정 일수 동안 취해야 할 조치를 사용자에게 상기시키기위한 것입니다. 이것은 일반적으로 청구서 지불이며 보류중인 항목에 대한 조치를 취합니다 (예 : 특정 날짜에 특정 이벤트에 대한 초대 수락 또는 거부, 양식 제출 등).
검증 포인트는 다음과 같습니다.
- 기한 / 기한
- 이메일에서 마감일 수에 대해 알리는 경우 숫자는 0 이상이어야하며 0 일은 현재 마감일을 의미합니다. 음수가 아니어야합니다. 이메일에서 기한 (달력 날짜)에 대해 알리는 경우 날짜는 현재 날짜이거나 미래 날짜 여야합니다.
- 행동 유형
- 필요한 조치 유형을 확인하십시오. 사용자가 취해야하는 조치의 종류를 매우 명확하게 설명해야합니다. 청구서 지불, 제출, 피드백 등이 되십시오.
# 4) 연체 알림
이는 사용자에게 기한이 지났음을 알리기위한 것입니다. 이는 일반적으로 사용자에게 기한 내에 항목에 대한 조치를 취하지 않았 음을 알리기위한 것입니다.
- 연체 일수
- 연체 일수가 1 일 이상이어야합니다. 0 또는 음수가 아니어야합니다.
- 회수
- 기한이 지나면 사용자가 작업을 완료 할 때까지 기한이 지난 이메일을 매일 / 매주 / 매월 전송하도록 사용자 정의 할 수있는 애플리케이션은 거의 없습니다. 기한이 지난 후 한 번만 표준 알림이 전송되는 응용 프로그램은 거의 없습니다.
# 5) 구독
이는 사용자 요구 사항에 따라 다릅니다. 사용자는 일일, 주간, 격월 또는 월간 구독 중 하나를 선택할 수 있습니다. 일반적으로 뉴스 레터, 업데이트, 제안 등을위한 것입니다.
- 회수
- 구독에 대한 사용자 선택에 따라 이메일을 보내야합니다. Daily 인 경우 구독 이메일은 하루에 한 번만 전송되어야합니다. 매주이면 일주일에 한 번. 그리고 계속…
- 연결
- 이메일의 모든 링크는 애플리케이션의 각 페이지로 이동해야합니다. 이메일이 업데이트 용인 경우 링크는 업데이트가 표시 될 페이지로 리디렉션되어야합니다. 이메일이 오퍼 용인 경우 링크는 애플리케이션의 오퍼 페이지로 리디렉션되어야합니다. 사용자가 선택한 구독 유형에 따라 다릅니다.
# 6) 양식
여기의 이메일은 사용자가 양식 / 양식 링크를 통해 피드백을 제공하기위한 것입니다. 검증 포인트는 다음과 같습니다.
- 연결
- 이메일의 링크는 사용자가 제출해야하는 양식 유형에 따라 애플리케이션의 양식 제출 페이지로 사용자를 리디렉션해야합니다.
- 제출 된 후 링크를 다시 클릭하면 사용자에게 양식이 이미 제출되었음을 알립니다. 사용자가 양식을 다시 제출하는 것을 허용해서는 안됩니다.
# 7) 확인 이메일
여기에있는 이메일은 사용자에게 취해진 조치의 확인을 알리기위한 것입니다. 일반적으로 예약 확인, 주문 확인, 쿼리 확인 등입니다.
검증 포인트는 다음과 같습니다.
- 확인 세부 사항 :
- 주문 번호 / 예약 번호가 정확하고 애플리케이션 UI에 표시된 번호와 일치해야합니다. 주문 / 예약을 추적하는 식별자이므로 응용 프로그램 전체에서 고유해야합니다 (백엔드 – DB에서 확인). 주문 / 예약은 동일한 식별자를 공유해서는 안됩니다.
- 번호와 함께 주문 유형, 사용자 정보, 청구 지 주소, 배송지 주소 및 가격에 대해서도 확인해야합니다. 모든 정보는 사용자가 애플리케이션 UI에서 제공 한 정보와 정확히 유사해야합니다.
- 연결:
- 이메일의 링크는 사용자를 애플리케이션 UI의 주문 세부 정보 페이지로 연결해야합니다. 이메일의 정보와 애플리케이션 UI가 정확히 일치해야합니다.
# 8) 채팅 기록
여기서 사용자는 전체 채팅 내용을 이메일로받습니다. 일반적으로 고객 지원과의 실시간 채팅이 종료 된 경우입니다.
검증 포인트는 아래와 같습니다.
- 세부
- 온라인 지원을 제공 한 사람의 이름을 확인하십시오. 각 채팅 항목에 대한 발신자 세부 정보 (개인 이름, 채팅 메시지를 보낸 날짜 및 시간 등)와 함께 전체 채팅이 이메일에 있는지 확인합니다.
# 9) 첨부 파일이있는 이메일
사용자는 첨부 파일이있는 이메일을받습니다. 첨부 파일은 암호로 보호 / 보호되지 않을 수 있습니다. 이는 일반적으로 재무 도메인의 명세서, 참조 용 최종 사용자 라이센스 계약, 참조 용 약관 등이며, 이는 애플리케이션마다 다시 다릅니다.
검증 포인트는 다음과 같습니다.
- 첨부 파일 유형
- 유효한 파일 형식은 첨부 파일로 보내야합니다. 열려있는 모든 첨부 파일은 다운로드 / 열기 전에 바이러스 검사를 받아야합니다. 이것은 백엔드의 응용 프로그램 수준에서 다시 사용자 정의 할 수 있습니다. 예를 들어 다운로드 할 때만 바이러스 검사를 수행하고 열 때만 다운로드하고 열 때 모두 수행하도록합니다.
- 암호로 보호 된 첨부 파일은 암호를 묻지 않고 다운로드해야합니다. 그러나 이메일 자체에서 열거 나 다운로드 한 사본을 여는 동안 항상 암호를 요청해야합니다. 첨부 파일을 잠그기 위해 로컬 복사본을 온라인으로 추적 할 수 없으므로 여기에 잘못된 암호 입력은 무기한입니다.
이메일 유형
이메일 유형은 HTML (사용자에게 다채롭고 매력적이며 이메일 전체를 읽는 데 관심이있는 사용자) 또는 일반 텍스트 (텍스트 만) 일 수 있습니다.
HTML이 가장 선호되며 일반적으로 백엔드의 거의 모든 애플리케이션에서 기본값으로 설정됩니다. 필요한 경우 애플리케이션은 사용자에게 일반 텍스트 이메일을 보내도록 선택할 수 있습니다.이 경우에도 백엔드에서 변경해야합니다.
이메일 트리거 포인트 :
이메일은 즉시 또는 요약 / 배치로 보낼 수 있습니다. 즉각적인 이메일은 사용자의 작업에 의해 트리거됩니다. 일반적으로 활성화 이메일, 비밀번호 재설정 이메일, 채팅 텍스트 변환, 확인 이메일 등입니다. 즉, 요약 / 일괄 이메일은 애플리케이션의 백엔드 설정에 따라 트리거됩니다.
이메일 트리거 포인트는 특정 시점 ( 예를 들면 삼rd매일 오전 12시). 일반적으로 금융 도메인의 명세서 (은행 명세서), 청구서 기한 알림, 연체 알림, 구독 등입니다.
바운스 백 :
이메일이 유효하지 않은 이메일 주소로 전송 될 때 반송되는 매우 일반적인 시나리오입니다. 일반적으로 비활성화되거나 더 이상 사용되지 않고 전혀 존재하지 않는 이메일 주소가 반송되는 후보입니다.
서버는 일반적으로 원하는 주소로 이메일을 보내기 위해 지정된 횟수만큼 시도합니다. 의도 한 이메일 주소에 도달하지 못하면 반송되고 실패에 대한 항목을 서버에 입력합니다. 이러한 유형의 활동을 유지하기위한 다른 서버가 있으며 일반적으로 반송 서버라고합니다. 사용자에게 도달하여 이메일이 실패하는 데는 여러 가지 이유가있을 수 있습니다.
다음은 실패에 대한 몇 가지 다른 점입니다.
- 이메일 서버가 오랫동안 다운되었습니다.
- 사용자에게 도달하기위한 짧은 경로를 찾는 알고리즘이 올바르게 작동하지 않고 사용자에게 도달하는 데 매우 오랜 시간이 걸립니다. 그 시간이되면 사용자에게 도달하도록 설정된 지정된 시간을 초과했을 수 있습니다. 이를 일반적으로 증가 된 홉 수라고합니다.
- 사용자의 이메일 도메인이 오랫동안 다운되었습니다.
- 애플리케이션에 대한 사용자 계정이 이메일을 수신하도록 활성화되지 않았습니다.
이메일 테스트를위한 현지화 범위
애플리케이션이 여러 언어를 지원하는 경우 지원은 이메일에 대해서도 확장되어야합니다.
전송되는 모든 이메일은 사용자 프로필 언어로 작성되어야합니다. 사용자가 프로필 언어로 영어를 설정 한 경우 사용자에게 전송되는 모든 이메일은 영어로되어 있어야합니다. 사용자의 프로필 언어가 프랑스어 인 경우 사용자에게 전송되는 모든 이메일은 프랑스어로되어 있어야합니다. 사용자 프로필 언어는 일회성 설정이거나 필요할 때 변경할 수 있으며 응용 프로그램의 설정에 따라 다릅니다.
이메일은 트리거 된 시점에 사용자가 사용하는 언어로 전송되어야합니다.
이메일 현지화 테스트를위한 일반적인 유효성 검사 지점은 다음과 같습니다.
- 제목 줄
- 이메일 본문
- 내용 – 본문의 텍스트
- 링크 이름 / 버튼 이름
- 저작권 정보
- 고객 지원 세부 정보
이메일 표준 / 사용자 정의
백엔드에서 이메일을 사용자 정의 할 수 있습니다.
예를 들면 , 사용자가 이메일을 보낼 때 사용자 정의 할 수있는 애플리케이션은 거의 없습니다. 사용자는 여기에서 이메일의 제목 및 / 또는 본문을 편리하게 또는 쉽게 인식 할 수 있도록 변경할 수 있습니다. 이 경우 침입 가능성이 높기 때문에 테스트 팀에서 철저한 테스트를 수행해야합니다.
HTML 코드, Java 코드, SQL 등을 전송하기 위해 주입에 대한 테스트를 수행해야합니다. 보안 수준을 높이려면이 모든 것이 실패해야합니다. 애플리케이션이 이메일 맞춤 설정을 지원하지 않는 경우 전송되는 모든 이메일은 애플리케이션에서 설정 한 표준 제목 / 본문을 따릅니다.
결론
애플리케이션의 대부분의 구성 요소가이 기능과 통합되어 있으므로 이메일 테스트는 중요한 활동입니다.
애플리케이션의 이메일 기능을 완전히 테스트하는 것은 전체 팀의 지원과 노력이어야합니다. 이것은 실제 테스트가 시작되기 훨씬 전에 잘 계획되어야하며 각 구성 요소 / 관련 구성 요소를 테스트하는 동안 함께 진행되어야합니다.
이메일 테스트에는 테스트 할 모든 측면을 포함하는 각 이메일 유형에 대해 작성된 별도의 테스트 케이스가 있어야합니다. 이는 모든 유형의 테스트 회귀 테스트, 임시 테스트, 지역화 테스트, UAT 테스트 및 프로덕션 테스트에서 수행되어야합니다.
실시간으로 이메일에서 잘못되는 모든 것은 애플리케이션과 고객에게 나쁜 인상을 남기고 결국 해당 애플리케이션의 테스터에게 전달됩니다. 따라서 이메일 유효성 검사는 소프트웨어 테스트에서 매우 중요하고 필수적인 활동입니다.
Windows 10 기본 게이트웨이를 사용할 수 없습니다.
저자 정보 : 이 게시물은 STH 작성자 Nandini K가 작성했습니다. 그녀는 주로 웹 애플리케이션 테스트에서 소프트웨어 테스트에 7 년 이상의 경험을 가지고 있습니다.
질문 / 제안이 있으면 알려주십시오.
추천 도서
- 성공적인 다음 이메일 캠페인을위한 10 가지 최고의 이메일 테스트 도구
- 최고의 소프트웨어 테스트 도구 2021 (QA 테스트 자동화 도구)
- 데스크톱, 클라이언트 서버 테스트 및 웹 테스트의 차이점
- 웹 애플리케이션 보안 테스트 가이드
- 2021 년 상위 10 개 이메일 확인 및 유효성 검사 서비스
- 응용 프로그램 테스트 – 소프트웨어 테스트의 기초로!
- 장치에 애플리케이션 설치 및 Eclipse에서 테스트 시작
- 시험 입문서 eBook 다운로드