Тестови случаи на платежни шлюзове: Видове и контролен списък
Томас Хамилтън
⚡ Умно обобщение
Тестването на платежни шлюзове проверява дали всяка онлайн транзакция се обработва сигурно, точно и бързо. Тази страница обяснява типовете шлюзове, методите за тестване, контролния списък за подготовка и двадесет и един готови за употреба тестови сценария, които екипите за осигуряване на качеството прилагат към процесите на плащане в реално време.
Тестване на Payment Gateway
Тестване на Payment Gateway е тестване на Payment Gateway в система за онлайн покупки и транзакции от потребителите. Целта на тестването на шлюза за плащане е да се гарантира сигурността, надеждността и производителността на шлюза за плащане чрез криптиране и защита на данните за плащането между потребителя и търговеца, като същевременно се осигурява гладко плащане.
Системата за шлюз за плащане е услуга за приложения за електронна търговия който одобрява плащане с кредитна карта за онлайн покупки. Платежните шлюзове защитават данните за кредитната карта чрез криптиране на чувствителна информация като номера на кредитни карти, данни за титуляри на сметки и т.н. Тази информация се предава безопасно между клиента и търговеца и обратно. Съвременните шлюзове за плащане също сигурно одобряват плащания чрез дебитни карти, електронни банкови преводи, карти в брой, наградни точки и др.
Тъй като порталът се намира между купувача, търговеца и банката, един недостатък там спира приходите незабавно.
Присъединете се към нашия проект за тестване на шлюза за плащания на живо безплатно
Видове шлюзови системи за плащане
Шлюзовете се различават по това къде купувачът въвежда данните на картата, както е показано по-долу.
Хостван шлюз за плащане
Хостваната система за шлюз за плащане насочва клиента от сайт за електронна търговия към връзката за шлюз по време на процеса на плащане. След като плащането бъде извършено, то ще върне клиента обратно към сайт за електронна търговия. За такъв тип плащане не се нуждаете от идентификатор на търговец, пример за хостван шлюз за плащане са PayPal, Noche и WorldPay.
Споделен шлюз за плащане
В споделен шлюз за плащане, докато обработва плащането, клиентът се насочва към страницата за плащане и остава на сайта за електронна търговия. След като данните за плащането бъдат попълнени, процесът на плащане продължава. Тъй като не напуска сайта за електронна търговия, докато обработва плащане, този режим е лесен и по-предпочитан, пример за споделен шлюз за плащане е eWay, Stripe.
Самостоятелно хоствани, API-хоствани и мобилни портфейлни шлюзове са допълнителни варианти.
Защо е важно тестването на платежните шлюзове
Страницата за плащане е последната стъпка между купувача и приходите, така че всеки дефект там струва пари в момента, в който се появи. Систематичното тестване защитава тази стъпка, като открива проблеми, преди клиентите да се сблъскат с тях.
- Защитава приходите: Неуспешна или бавна транзакция тласка купувачите да изоставят количката, а изоставените колички рядко се връщат.
- Изгражда доверие: Маскираните полета на картата, криптираният трафик и ясните съобщения за потвърждение уверяват купувачите, че парите им се обработват правилно.
- Предотвратява загуби от измами: Проверката на CVV правилата, проверката на адреса и проверките на скоростта спират измамните поръчки, преди стоките да бъдат изпратени.
- Поддържа съответствието на търговеца с изискванията: Картовите схеми изискват силно удостоверяване на клиента, а тестването е доказателството, че тези контроли работят.
- Намалява разходите за поддръжка: Дублиращите се такси, липсващите касови бележки и блокираните възстановявания на суми генерират скъпи глоби и сторнирани плащания.
- Ранно открива дефекти: Поправянето на грешка в интеграцията в пясъчник струва много по-малко от поправянето ѝ след прекъсване на производството.
Тези предимства зависят от правилната комбинация от типове тестове, описана по-долу.
Тестване на типове за платежен домейн
Тестването за Payment Gateway трябва да включва
Функционално тестване: Това е актът на тестване на основната функционалност на шлюза за плащане. Целта е да се провери дали приложението се държи по същия начин, както се предполага, че обработва поръчки, изчисления, добавяне на ДДС според страната и т.н.
Integration: Тествайте интеграцията с услугата за вашата кредитна карта.
Изпълнение: Идентифицирайте различни показатели за ефективност като възможно най-голям брой потребители, преминаващи през шлюзове през определен ден и преобразувайки ги в едновременни потребители
Охрана: Трябва да извършите дълбока защита за Payment Gateway.
Добави тестване на локализацията за валута и език, тестване за съвместимост за устройства и регресионно тестване след всяка актуализация на API на доставчика.
Как да тествате Payment Gateway: Пълен контролен списък
Преди да започнете да тествате –
- Съберете подходящи тестови данни за номера на фиктивната кредитна карта за maestro, visa, master и др.
- Събирайте информация за платежния шлюз, като например Google Портфейл, PayPal или друго
- Съберете документ за платежен портал с кодове за грешки
- Разберете сесията и параметрите, преминали през приложението и шлюза за плащане
- Разберете и тествайте свързаната с количеството информация, предадена през низ на заявка, променлива или сесия
- Заедно с езика на платежния портал проверете езика на приложението
- Съгласно различните настройки на шлюза за плащане, като валутен формат, се събират данни за абонати.
Съвет: Съпоставете всеки очакван неуспех с документиран код за грешка на доставчика, така че един неясен дефект „плащането не е проработило“ да се превърне в възпроизводим билет.
Как да настроите тестова среда за платежен шлюз
Надеждните резултати започват със среда, която се държи като производствена, без да се движат реални пари. Почти всеки доставчик предлага пясъчна среда, която отразява активния API, но не урежда нищо, и тази пясъчна среда е мястото, където принадлежат повечето тестове на платежни шлюзове.
- Заявка за идентификационни данни за пясъчник. Вземете отделен търговски идентификатор, API ключ и секретен код и ги съхранявайте извън хранилището на изходния код.
- Насочете приложението към крайната точка на sandbox. Потвърдете от мрежовия лог, че до хоста на live gateway не достига заявка.
- Заредете официалните тестови карти. Всяка схема публикува числа, които налагат фиксиран резултат: одобрение, отказ, недостатъчни средства, изтекла карта или блокиране на изгубена карта.
- Никога не копирайте производствени данни. Съвет за стандарти за сигурност на PCI Правилата забраняват данните на картодържателите в реално време в тестови среди, така че маскирайте всеки запис.
- Активирайте тестовия режим на 3D Secure. Задействайте безпроблемния и предизвикателствения поток, така че да се упражнят пътища за пренасочване, изчакване и отмяна.
- Регистрирайте приемник на уеб кука. Статусът на плащането често пристига асинхронно, затова проверете дали известията за заснемане, възстановяване на суми и сторниране на плащане актуализират записа на поръчката.
- Симулирайте мрежови повреди. Отказ или забавяне на отговорите чрез прокси сървър и потвърждение, че не се появява дублирано плащане, когато купувачът опита отново.
- Нулиране на състоянието между изпълненията. Изчистете количките, сесиите и съхранените токени, така че една застояла сесия да не маскира дефект.
Поддържайте кратък наръчник с пясъчник URLs, номера на тестови карти и очаквани кодове за отговор. Това позволява на новите тестери да възпроизведат всеки сценарий незабавно и служи и като одиторско доказателство.
Внимание: Никога не насочвайте тестовия пакет към реални идентификационни данни. Еднократно случайно оторизиране на истинска карта е едновременно финансов инцидент и нарушение на съответствието.
Пример за тестови случаи на Payment Gateway
Следват важни тестови сценарии/случаи за проверка на Payment Gateway
| Sr# | Тестови Случаи |
|---|---|
| 1 | По време на процеса на плащане опитайте да промените езика на платежния портал |
| 2 | След успешно плащане, тествайте всички необходими компоненти, независимо дали е изтеглен или не |
| 3 | Проверете какво се случва, ако шлюзът за плащане спре да отговаря по време на плащане |
| 4 | По време на процеса на плащане проверете какво се случва, ако сесията приключи |
| 5 | По време на процеса на плащане проверете какво се случва в бекенда |
| 6 | Проверете какво се случва, ако процесът на плащане е неуспешен |
| 7 | Проверете записите в базата данни дали съхраняват данни за кредитна карта или не |
| 8 | По време на процеса на плащане проверете страниците за грешки и страниците за сигурност |
| 9 | Проверете настройките на блокирането на изскачащи прозорци и вижте какво се случва, ако блокирането на изскачащи прозорци е включено и изключено |
| 10 | Между шлюза за плащане и буферните страници за проверка на приложението |
| 11 | Проверка при успешно плащане, код за успех се изпраща на приложението и на потребителя се показва страница за потвърждение |
| 12 | Проверете дали транзакцията се обработва незабавно или обработката е в ръцете на вашата банка |
| 13 | След успешна транзакция проверете дали шлюзът за плащане се връща към вашето приложение |
| 14 | Проверете всички формати и съобщения при успешен процес на плащане |
| 15 | Освен ако нямате разписка за оторизация от портала за плащане, стоките не трябва да се изпращат |
| 16 | Информирайте собственика за всяка транзакция, обработена чрез електронна поща. Шифроване на съдържанието на пощата |
| 17 | Проверете формата на сумата с валутния формат |
| 18 | Проверете дали всяка от опциите за плащане може да бъде избрана |
| 19 | Проверете дали всяка изброена опция за плащане отваря съответната опция за плащане по спецификация |
| 20 | Проверете дали шлюзът за плащане по подразбиране е с желаната опция за дебитна/кредитна карта |
| 21 | Уверете се, че опцията по подразбиране за дебитна карта показва падащото меню за избор на карта |
Следващото решение е кой от тези сценарии заслужава сценарий.
Тестване на ръчни срещу автоматизирани платежни шлюзове
И двата подхода принадлежат към програма за плащане и полезният въпрос е кои случаи са подходящи за кой метод. Ръчната работа е най-силна при нови интеграции и всичко, което изисква човешка преценка. Автоматизацията печели своето място чрез стабилни, повтарящи се пътища, които трябва да се преминат при всяко изграждане.
| Аспект | Ръчно тестване | Автоматизирано тестване |
|---|---|---|
| Най-подходящ за | Проучвателни проверки, интеграции за първи път, визуален и текстуален преглед | Регресионни пакети и димни проверки за всяко внедряване |
| Скорост | Бавно; един тестер изпълнява по един сценарий наведнъж | Бързо; много сценарии се изпълняват паралелно |
| Профил на разходите | Ниски усилия за настройка, високи повтарящи се усилия | Високи усилия за настройка, ниски повтарящи се усилия |
| Типични инструменти | Инструменти за разработчици на браузъри и табла за управление на sandbox | Selenium, Appium, Postman за API проверки |
| Основна слабост | Трудно е да се мащабира за много видове карти или нива на натоварване | Сляп за проблеми с оформлението и използваемостта |
Практическото разделение е да се автоматизират успешните, отказаните и възстановените суми пътища за всеки тип карта и да се резервират ръчни сесии за нови версии на шлюзовете. Управлявайте профилите на натоварване отделно с JMeter.
Неща, които трябва да имате предвид, преди да закупите пакет Gateway
- Ако сте закупили магазинping пакет количка, разберете за неговата съвместимост
- Ако магазинътping пакетът с шлюз е изтекъл, попитайте доставчика на платежен шлюз за списък с поддържани приложения
- Шлюзът трябва да предлага защита на системата за проверка на адреса
- Разберете видовете защита на транзакциите, които се предлагат
- Проверете какви видове дебитни или кредитни карти се приемат от избрания от вас портал за плащане
- Проверете таксите за транзакции, налагани от платежен портал
- Проверете дали шлюзовете събират плащането директно във формуляра или насочват към друга страница, за да завършите покупката
