Меню

Тестване за проверка на имейл: Как да тествате функционалността на електронната поща на приложение

  • Основен
  • Уеб Тестване
  • Тестване за проверка на имейл: Как да тествате функционалността на електронната поща на приложение

email validation testing

Опитайте Нашия Инструмент За Премахване На Проблемите

Днешният урок е свързан с тестване на функционалността на имейли на всяко приложение.

В повечето уеб и мобилни приложения валидирането на функцията за електронна поща се счита за една от най-важните части на тестването, за да се гарантира качеството на компонента за електронна поща, както и на другите компоненти на системата.

Имейлите, задействани при различни сценарии, се считат за валидирани чрез проверка за всички негови компоненти, което включва шаблон за имейл, връзки / бутони в полетата Имейл, От, До, Копия, Ск, Прикачени файлове, Съдържание по известие по имейл и др.

Проверка на имейл

Какво ще научите:

Защо се нуждаем от тестване по имейл?

Всеки компонент в системата (уеб / мобилни приложения) може да има различни цели за изпращане на имейли. Интеграция между компонентите и Имейлът играе жизненоважна роля за достигане до крайния потребител с подходящи известия. Всяка небрежност, когато валидираме тази функция, ще доведе до недоразумения, лошо име на клиентите, хакване и т.н.

Например , представете си ситуация, при която потребителят е получил имейл за нулиране на паролата. Какво ще стане, ако връзката / бутона за нулиране на паролата или URL адресът, предоставен за копиране на паста в браузър, не функционира? Единствената опция, която остава тук, е да се свържете с поддръжката на клиенти, което може да се превърне в досадно нещо или да си представите ситуация, при която потребителят продължава да получава имейл ежедневно относно датата на падежа за плащане на сметката от 10-15 дни по-рано или получава напомняне след като датата премина. - Дразнещо нали ??

Има много сценарии, при които имейлите са се превърнали в неразделна част от живота ни, тъй като са предназначени да поддържат потребителя в крак с точната информация.

Общи сценарии в реално време и точки за валидиране на имейли

Точките за проверка при тестване на имейли варират от тип до тип и отново от приложение до приложение. Обикновено всички имейли трябва да бъдат валидирани за шаблона (който включва лого на приложението, име на приложение, Адресиране на потребителя, Съдържание на долния колонтитул - Авторско право, Детайли за поддръжка на клиенти), дата и времеви клей за различни часови зони.

Тук ще обсъдим някои често срещани типове имейли, за които почти всеки е запознат (всички точки за валидиране, дадени по-долу, са основната проверка, която тестерът трябва да извърши, докато тества имейлите на приложението).

# 1) Имейли за активиране

Когато потребителят се регистрира за дадено приложение за първи път, той / тя трябва да активира акаунта, като щракне върху връзката за активиране, изпратена в имейл. Това също така проверява дали имейл адресът на потребителя е валиден и достъпен.

Точките за валидиране са както по-долу:

  • Връзка или бутон за активиране - Кликването върху нея трябва:
    • Заведете потребителя на страницата на съответното приложение с регистриран потребителски акаунт
    • Имейл акаунтът на потребителя трябва да бъде потвърден автоматично, ако страницата на приложението е достигната успешно чрез Имейл
  • Продължителност - Проверете за продължителността, в рамките на която връзката трябва да бъде щракната и потвърдена.
    • Проверете в рамките на определената продължителност
    • Опитайте се да потвърдите след като изтече продължителността - акаунтът не трябва да се активира и имейл трябва да остане непроверен

Имейл за активиране

# 2) Имейли за забравена парола

Когато потребителят забрави паролата, за да влезе в приложението, може да се извърши поток на забравена парола, за да получи имейл с връзка за нулиране на паролата (функцията варира в зависимост от приложението. Това е общото).

Точките за валидиране са както по-долу:

  • Връзка за нулиране на паролата:
    • Кликването върху него трябва да отведе потребителя до страницата на съответното приложение, за да нулира паролата
    • Някои приложения ще помолят потребителя да отговори на защитен въпрос, преди да покаже страницата за нулиране на паролата, а някои ще имат защитен въпрос, интегриран със самата страница за нулиране на паролата, а някои изобщо няма тази функция
    • Ако потребителят нулира успешно паролата, връзката в имейла за забравена парола, който е получен, трябва да се деактивира и да не функционира
    • Ако потребителят отмени потока за нулиране на паролата, връзката в получената парола за забравена парола трябва да остане активирана
  • Продължителност - Проверете продължителността, в която трябва да се щракне върху връзката за нулиране на паролата
    • Кликнете върху връзката и рестартирайте успешно паролата в рамките на определеното време
    • Опитайте се да кликнете върху връзката, след като изтече продължителността - Връзката трябва да бъде деактивирана и изтекла

Нулиране на парола по имейл

как да извърша ddos ​​атака на уебсайт

# 3) Известия за падеж

Това е да напомни на потребителя за действието, което трябва да предприеме за определен брой дни. Обикновено това са плащанията по сметки, предприемане на действия по изчакващи елементи (пример: приемане или отхвърляне на поканата за някакво събитие в определен брой дни, подаване на формуляри и др.).

Точките за валидиране са както по-долу:

  • Брой дни на падежа / дата на падежа
    • Ако имейл известява за брой дължими дни, тогава броят трябва да бъде нула или повече, нула дни, предназначени да бъдат текущата дата на дължимостта. Не трябва да е в отрицателни числа. Ако имейл известява за краен срок (дата на календара), тогава датата трябва да бъде или текущата, или бъдещата.
  • Вид на действието
    • Проверете какъв тип е необходимото действие. Той трябва много ясно да посочва какъв вид действия трябва да предприеме този потребител. Било то плащане на сметки, подаване, обратна връзка и т.н.

Имейл с краен срок

Известие по имейл на падежа

# 4) Просрочени известия

Това е да информира потребителя за изтекъл срок. Обикновено това е да информира потребителя, че той / тя не е предприел действия по артикулите в срок.

  • Брой просрочени дни
    • Проверете дали броят на просрочените дни трябва да бъде един или повече. Никога не трябва да са нула или отрицателни числа
  • Честота
    • Малко приложения ще имат възможност да персонализират просрочени имейли, които да се изпращат ежедневно / седмично / месечно, след като изтече датата на падежа, докато потребителят завърши действието. Малко приложения ще имат стандартното известие, което ще бъде изпратено само веднъж само след изтичане на датата.

# 5) Абонаменти

Това варира според изискванията на потребителя. Потребителят може да избере един от следните дневни, седмични, двумесечни или месечни абонаменти. Това обикновено е за бюлетини, актуализации, оферти и т.н.

  • Честота
    • Имейлите трябва да се изпращат според избора на потребител за абонамент. Ако Ежедневно, тогава имейл за абонамент трябва да се изпраща само веднъж на ден. Ако седмично, то веднъж на седмица. И продължава ...
  • Връзки
    • Всички връзки в имейла трябва да водят до съответната страница на приложението. Ако имейлът е за актуализации, тогава връзката трябва да пренасочи към страницата, на която трябва да се показват актуализациите. Ако имейлът е за оферти, тогава връзката трябва да пренасочи към страницата Оферти на приложението. Зависи от типа абонамент, който потребителят е избрал.

Имейл за абонамент

Екран за имейл за абонамент

# 6) Формуляри

Имейлите тук възнамеряват потребителят да предоставя обратна връзка чрез формуляри / връзка към формуляри. Точките за валидиране са както по-долу:

  • Връзки
    • Връзката в имейла трябва да пренасочи потребителя към страницата за подаване на формуляра на заявлението според типа формуляр, който потребителят трябва да изпрати
    • След като бъде изпратено, щракването върху връзката отново трябва да уведоми потребителя, че формулярът вече е изпратен. Той не трябва да позволява на потребителя да подаде отново формуляра

Имейл за проучване

Страница на проучването

# 7) Имейли за потвърждение

Имейлите тук трябва да уведомяват потребителя за потвърждението на предприетото действие. Това обикновено са потвърждения на резервации, потвърждения на поръчки, потвърждения на заявки и т.н.

Точките за валидиране са както по-долу:

  • Подробности за потвърждение:
    • Номерът на поръчката / номерът на резервацията трябва да е правилен и да съответства на номера, показан в потребителския интерфейс на приложението. Тъй като това е идентификаторът за проследяване на поръчките / резервациите, той трябва да бъде уникален (да бъде валидиран в бекенда - DB) в цялото приложение. Никакви поръчки / резервации не трябва да споделят един и същ идентификатор.
    • Заедно с номера, той също трябва да бъде валидиран за вида на поръчката, информация за потребителя, адрес за фактуриране, адрес за доставка и цена. Цялата информация трябва да бъде точно подобна на тази, която потребителят е предоставил в потребителския интерфейс на приложението.
  • Връзки:
    • Връзка в имейла трябва да отведе потребител до страницата с подробности за поръчката в потребителския интерфейс на приложението. Трябва да има точно съвпадение между информацията в имейл и потребителския интерфейс на приложението

Имейл за потвърждение

# 8) Препис от чат

Тук потребителят получава целия препис от чата като имейл. Това обикновено е след приключване на чата на живо с поддръжка на клиенти.

Точките за валидиране са както по-долу

  • Подробности
    • Проверете за името на лицето, което е предоставило онлайн поддръжка. Проверете дали целият чат присъства в имейла с подробности за подателя за всеки запис в чата (име на човек, дата и час на изпращане на съобщението в чата и т.н.,)

# 9) Имейли с прикачен файл

Потребителят получава имейли с прикачен файл. Прикачените файлове могат да бъдат защитени с парола / незащитени. Това обикновено са извлеченията от финансови домейни, Лицензионно споразумение за краен потребител за справка, Общи условия за справка и т.н., това отново варира от приложение до приложение.

Точките за валидиране са както по-долу:

шпионски софтуер за поставяне на мобилен телефон
  • Тип на прикачения файл
    • Валидните типове файлове трябва да се изпращат като прикачен файл. Всички отворени прикачени файлове трябва да бъдат сканирани на вируси преди изтегляне / отваряне. Това отново може да бъде персонализирано на ниво приложение в бекенда, като например сканиране на вируси, което да се извършва само при изтегляне, само при отваряне, както за изтегляне, така и за отваряне.
    • Защитените с парола прикачени файлове трябва да се изтеглят, без да се иска паролата. Но докато го отваряте от самия имейл или отваряте изтегленото копие, винаги трябва да питате за паролата. Неправилните въведени пароли тук ще бъдат неопределени, тъй като локалното копие не може да бъде проследено онлайн, за да заключите прикачения файл

Имейл с прикачен файл

Прикачен файл с парола

Видове имейли

Типът имейл може да бъде или HTML (цветен и привлекателен за потребителите, които интересуват потребителя да прочете имейлите изцяло) или обикновен текст (само текст).

HTML е най-предпочитаният и обикновено се задава по подразбиране в почти всички приложения в бекенда. Ако е необходимо, приложенията могат да изберат да изпращат имейли с обикновен текст на потребителите, което отново изисква промени в бекенда.

Точки за задействане на имейли:

безплатен конвертор на youtube в mp4 за mac

Имейлите могат да се изпращат незабавно или като резюме / партида. Незабавните имейли се задействат от действието на потребителя. Това обикновено са имейли за активиране, имейли за нулиране на пароли, транскрипции в чата, имейли за потвърждение и т.н., т.е. имейлите с обобщение / партида се задействат въз основа на настройките в бекенда на приложението.

Точките за задействане по имейл ще бъдат определени за задействане в конкретен момент от времето ( например 3rdден от всяка седмица в 00:00 ч.). Това обикновено ще бъдат извлеченията от финансови домейни (банкови извлечения), известия за падеж за сметки, просрочени известия, абонаменти и т.н.,

Отскоци:

Това е много често срещан сценарий, при който имейлите отскачат, когато са изпратени на невалиден имейл адрес. Обикновено имейл адресът, който е деактивиран / вече не се използва и изобщо не съществува - са кандидатите, които отскачат.

Сървърът обикновено се опитва за определен брой пъти да изпрати имейл до желания адрес. Когато не достигне предвидения имейл адрес, той се връща обратно и ще направи запис в сървъра за неговия отказ. Ще има различен сървър за поддържане на този тип дейности и обикновено се наричат ​​сървъри за възстановяване. Може да има няколко причини имейл да се провали, като се свърже с неговия потребител.

По-долу има няколко други точки за неуспех:

  • Имейл сървърът не работи дълго време
  • Алгоритъмът за намиране на кратък маршрут за достигане до потребителя не работи правилно и отнема много време, за да достигне до потребителя, по това време може би щеше да премине определеното време, зададено за достигане до потребителя. Това обикновено се нарича увеличен брой хмел
  • Имейл домейнът на потребителя не работи дълго време
  • Потребителският акаунт за приложението не е активиран за получаване на имейли

Локализация Обхват за тестване на имейли

Когато приложението поддържа множество езици, тогава поддръжката трябва да се разшири и за имейли.

Всички изпратени имейли трябва да бъдат на езика на потребителския профил. Ако даден потребител е задал английски като език на профила, тогава всички имейли, изпратени до него / нея, трябва да са на английски език. Ако езикът на потребителския профил е френски, тогава всички имейли, изпратени до него / нея, трябва да са на френски. Езикът на потребителския профил може да бъде еднократни настройки или може да се променя, когато и когато е необходимо, което зависи от настройките на приложението.

Имейлът трябва да бъде изпратен на езика, който потребителят има в момента, в който е задействан.

Общите точки за валидиране за тестване на локализация Имейлите са както по-долу:

  • Ред на тема
  • Основно съдържание на имейла
    • Съдържание - текст на тялото
    • Име на връзка / име на бутон
    • Информация за авторските права
    • Подробности за поддръжка на клиенти

Стандарт / Персонализиране на имейли

Имейлите могат да се персонализират в бекенда.

Например , няколко приложения поддържат потребителя да персонализира имейли, когато се изпращат. Потребителят може да промени тук темата и / или тялото на имейла на удобно или с цел лесно разпознаване. В този случай тестващият екип трябва да извърши щателно тестване, тъй като шансът за навлизане е голям.

Трябва да се извърши тестване за инжекции - изпращане на HTML код, Java код, SQL и др. Всичко това трябва да се провали, за да се повишат нивата на сигурност. Ако приложението не поддържа персонализиране на имейли, тогава всички изпратени имейли ще следват стандартната тема / тяло, както е зададено от приложението.

Заключение

Тестване на имейли е важна дейност, тъй като повечето компоненти на приложението са интегрирани с тази функционалност.

Трябва да бъде подкрепата и усилията на целия екип за пълно тестване на функционалността на имейла на приложението. Това трябва да бъде добре планирано много преди реалното тестване и трябва да върви ръка за ръка, докато тествате всеки компонент / асоцииран компонент.

Имейл тестването трябва да има отделни тестови случаи, написани за всеки тип имейл, обхващащи всички аспекти за тестване. Това трябва да се извърши при всички видове тестове Регресионно тестване, Adhoc тестване, тестване на локализация, UAT тестване и производствено тестване.

Всичко, което се обърка в имейл в реално време, ще остави лошо впечатление за приложението, клиентите и в крайна сметка ще пренесе на тестерите на това приложение. Така че проверката на имейл е много важна и много необходима дейност при тестване на софтуера.

За автора: Тази публикация е написана от авторката на STH Нандини К. Тя има 7+ години опит в тестването на софтуер, главно в тестването на уеб приложения.

Уведомете ни, ако имате въпроси / предложения.

Препоръчително четене

^