تست فین‌تک؛ امنیت و تراکنش‌های حجیم

کاربر مبلغ را پرداخت می‌کند؛ PSP تراکنش را موفق ثبت می‌کند، اما callback دیر می‌رسد. اپ «ناموفق» نشان می‌دهد، کاربر دوباره می‌پردازد و چند دقیقه بعد دو اعتبار در کیف پول ثبت می‌شود. همه APIها در بیشتر زمان‌ها ۲۰۰ داده‌اند و TPS هم عالی بوده است؛ بااین‌حال سامانه مالی شکست خورده، چون واقعیت پول میان کانال، PSP، دفترکل و تسویه یکسان نمانده است.

تست فین‌تک باید فراتر از سه فهرست جداگانه انطباق، امنیت و تست بار باشد. واحد واقعی آزمون، چرخه عمر تراکنش مالی است: از شناسایی کاربر و ایجاد درخواست تا مجوز، ثبت در دفترکل، اعلام نتیجه، برگشت، تطبیق و گزارش. این راهنما نشان می‌دهد چگونه این چرخه را برای بازار ایران با شواهد قابل‌ممیزی، کنترل امنیتی و بار پرتراکنش آزمایش کنیم.

اصل راهنما: موفقیت پاسخ HTTP، موفقیت PSP، ثبت دفترکل، مانده قابل‌نمایش و تسویه بانکی پنج واقعیت جدا هستند. تست باید رابطه و اختلاف میان آن‌ها را بررسی کند؛ نه اینکه یکی را نماینده همه بداند.

تست فین‌تک چه دامنه‌ای دارد؟

فین‌تک می‌تواند پرداخت‌یار، کیف پول، بانکداری دیجیتال، اعتبار، سرمایه‌گذاری، بیمه یا زیرساخت مالی باشد. الزام‌ها و ریسک‌های یکسانی ندارند. پیش از نوشتن test case، نقشه سیستم و نقش حقوقی/قراردادی محصول را مشخص کنید:

کانال کاربر: وب، موبایل، API شریک یا مرکز تماس؛
هویت، ورود، بازیابی حساب و KYC/CDD؛
سرویس سفارش یا درخواست مالی؛
payment orchestration و اتصال به PSP/بانک/شبکه؛
دفترکل، مانده، کارمزد و رزرو وجه؛
تسویه، refund، reversal و reconciliation؛
ضدتقلب، AML و صف بررسی انسانی؛
اعلان، رسید، گزارش مالی و گزارش نظارتی؛
پشتیبانی، dispute و اصلاح عملیاتی؛
لاگ، audit، کلیدها، زیرساخت و بازیابی بحران.

این مقاله مالک راهبرد تست سامانه پرداخت و عملیات تراکنش پرتعداد است. بحث عمیق فرمول سود، قیمت‌گذاری دارایی، حسابداری و محاسبات مالی به خوشه «تست نرم‌افزار مالی» تعلق دارد. اینجا هرجا از دفترکل صحبت می‌کنیم، هدف اثبات یکپارچگی تراکنش و تسویه است.

سه نوع الزام را با هم مخلوط نکنید

الزام قانونی/رگولاتوری: از قانون، آیین‌نامه، بخشنامه یا مجوز قابل‌اعمال می‌آید.
الزام شبکه و قرارداد: از شاپرک، PSP، بانک، طرح کارت، شریک یا SLA می‌آید.
کنترل امنیتی و سیاست داخلی: از threat model، استاندارد منتخب و اشتهای ریسک سازمان می‌آید.

ممکن است هر سه به یک کنترل منتهی شوند، اما منبع، صاحب تفسیر، دوره نگهداری شواهد و پیامد عدم رعایت متفاوت است.

هفت invariant که باید همیشه برقرار بمانند

پیش از سناریوها، قواعدی بنویسید که هیچ ترتیب پیام، retry، خرابی یا بار نباید آن‌ها را نقض کند:

پول بدون واحد وجود ندارد: مبلغ با currency/unit صریح ذخیره می‌شود؛ ریال و تومان در مرز ورودی تبدیل و ثبت می‌شوند.
هر اثر مالی هویت یکتا دارد: business transaction ID و idempotency key از requestهای شبکه‌ای جدا هستند.
retry نباید پول جدید بسازد: درخواست تکراری همان نتیجه قابل‌ردیابی را می‌دهد یا تضاد را صریح رد می‌کند.
دفترکل متوازن و append-only است: اصلاح با ورودی جبرانی انجام می‌شود، نه ویرایش بی‌ردپای تاریخچه.
وضعیت نامعلوم، موفق یا ناموفق جعل نمی‌شود: Pending/Unknown یک حالت واقعی با مسیر تعیین تکلیف است.
هر مانده از رویدادهای مجاز قابل‌بازتولید است: مجموع ورودی‌ها، رزروها و خروجی‌ها با قواعد دامنه سازگار می‌ماند.
منبع بیرونی مستقل تطبیق می‌شود: اختلاف سامانه، PSP/بانک و فایل/گزارش تسویه کشف و حل می‌شود.

عبارت «exactly once» اغلب گمراه‌کننده است. شبکه و queue می‌توانند پیام را دوباره تحویل دهند یا نتیجه را گم کنند. راهنمای Google SRE درباره pipelineهای داده نیز توضیح می‌دهد وقتی work unit idempotent است، اجرای دوباره می‌تواند همان نتیجه را حفظ کند. در پرداخت، exactly-once باید یک خاصیت کسب‌وکاری قابل‌آزمون باشد که با idempotency، deduplication، دفترکل و reconciliation ساخته می‌شود؛ نه ادعای transport.

ماشین حالت تراکنش را مبنای تست قرار دهید

یک enum ساده Success/Failed برای پول کافی نیست. نام‌ها به دامنه بستگی دارند، اما مدل نمونه می‌تواند چنین باشد:

Created → Pending Authorization → Authorized → Ledger Posted → Settlement Pending → Settled

شاخه‌های جایگزین: Declined، Expired، Unknown، Reversed، Refund Pending، Partially Refunded، Refunded، Disputed. هر transition باید این قرارداد را داشته باشد:

رویداد محرک و منبع معتبر؛
پیش‌شرط و stateهای مجاز قبلی؛
تغییر دفترکل و side effectها؛
رفتار duplicate، late و out-of-order؛
پاسخ کاربر و پیام قابل‌نمایش؛
deadline، timeout و مسیر تعیین تکلیف؛
audit event و correlation ID؛
مالک اقدام در اختلاف.

ماتریس شکست پرداخت

شکست	انتظار محصول	شاهد ضروری
timeout پیش از commit در PSP	retry کنترل‌شده یا Pending؛ بدون بدهکارکردن قطعی	trace، query وضعیت و دفترکل
timeout پس از commit	عدم پرداخت دوباره؛ تعیین تکلیف با query/reconcile	idempotency، PSP reference و ledger
callback تکراری	یک transition و یک اثر مالی	dedupe decision و شمار ورودی دفترکل
callback دیر/خارج‌ترتیب	transition نامعتبر رد یا reconcile شود	event time، receive time و state history
امضا یا مبلغ callback غلط	رد، هشدار و بدون side effect	verification event با داده redacted
commit دفترکل و شکست اعلان	پول دوباره ثبت نشود؛ اعلان قابل retry باشد	outbox/queue و transaction ID
شکست بخشی از refund	مقدار دقیق Pending/Refunded؛ قابل‌تطبیق	original link، amount و compensating entry
خرابی reconcile job	backlog قابل‌مشاهده و اجرای مجدد idempotent	checkpoint، lag و mismatch inventory

برای قرارداد پاسخ و خطای سرویس‌ها از راهنمای تست API و برای مرز mock، component و محیط واقعی از تست یکپارچه‌سازی استفاده کنید.

تست انطباق: از متن الزام تا شاهد

QA نباید خودش نتیجه حقوقی بگیرد که «GDPR، PCI یا AML شامل ماست». تیم حقوقی/تطبیق و مالک کسب‌وکار، قلمرو، نوع مجوز و نقش سازمان را تعیین می‌کنند؛ QA عبارت مصوب را به رفتار قابل‌مشاهده و مدرک تکرارپذیر تبدیل می‌کند.

قالب Obligation Matrix

فیلد	نمونه پرسش
Source ID و لینک	کدام قانون، بخشنامه، قرارداد یا استاندارد؟
نسخه/تاریخ اجرا	از چه تاریخی و با کدام اصلاحیه؟
قلمرو و نقش	پرداخت‌یار، پذیرنده، PSP، بانک یا پردازشگر؟
مالک تفسیر	حقوقی، تطبیق، امنیت یا صاحب قرارداد؟
Testable statement	چه داده/عمل/مهلتی باید مشاهده شود؟
Control و test	کنترل پیشگیرانه و آزمون مثبت/منفی چیست؟
Evidence	کدام artifact، با چه دسترسی و retention؟
استثنا	چه کسی، تا چه تاریخ و با چه کنترل جبرانی؟

یک شناسه پایدار مانند IR-AML-CDD-017@2026-07 را به requirement، test، نتیجه و evidence متصل کنید. وقتی بخشنامه عوض شد، impact analysis نشان می‌دهد کدام کنترل و regression suite نیاز به بازبینی دارد.

منابع ایران را چگونه مدیریت کنیم؟

برای محصول ایرانی، کاتالوگ منبع می‌تواند—بسته به فعالیت—شامل قانون و آیین‌نامه مبارزه با پول‌شویی، مقررات و بخشنامه‌های بانک مرکزی، الزامات شاپرک و PSP، قراردادها، تجارت الکترونیکی، مالیات، بورس یا بیمه باشد. صفحه گردآوری‌شده آیین‌نامه اجرایی مقابله و پیشگیری از جرائم پول‌شویی و تأمین مالی تروریسم نمونه‌ای از متنی است که اصلاحات و ارجاعات را کنار هم نشان می‌دهد؛ اما نسخه لازم‌الاجرای سازمان باید از کانال رسمی تطبیق و با تاریخ اثر تأیید شود.

قانون تجارت الکترونیکی ایران در WIPO Lex نیز نمونه‌ای از منبع حقوقی قابل‌ردیابی است. وجود یک لینک در مقاله جای نظر حقوقی، متن فارسی رسمی یا بخشنامه قراردادی جدید را نمی‌گیرد.

PCI DSS؛ محدوده را پیش از test case تعیین کنید

کتابخانه رسمی PCI SSC، PCI DSS v4.0.1 را نسخه جاری فهرست می‌کند. این استاندارد برای داده حساب پرداخت و محیط مرتبط طراحی شده است، اما applicability دقیق، نوع اعتبارسنجی و مرز CDE باید با متخصص PCI و قراردادهای شما تعیین شود.

برای QA، پرسش‌های اصلی چنین‌اند:

داده کارت کجا وارد، عبور، ذخیره، log، backup یا export می‌شود؟
کدام سیستم می‌تواند بر امنیت CDE اثر بگذارد، حتی اگر PAN را ذخیره نکند؟
tokenization یا redirect چه چیزی را واقعاً از scope خارج کرده است؟
scriptهای صفحه پرداخت، تغییر و tamper چگونه کنترل و پایش می‌شوند؟
حساب‌های انسانی و ماشینی، MFA، دسترسی و key rotation چگونه آزموده می‌شوند؟
scan، penetration test، log review و evidence retention چه تناوب مصوبی دارند؟

قبولی ارزیابی PCI به معنای نبود تمام آسیب‌پذیری‌ها، سلامت منطق مالی یا انطباق با قوانین ایران نیست. استاندارد، یک ورودی به برنامه کنترل است.

KYC، احراز هویت و AML را به state machine تبدیل کنید

KYC یک فرم موفق/ناموفق نیست. journey ممکن است شامل ثبت ادعا، جمع‌آوری مدرک، اعتبارسنجی منبع، liveness در صورت کاربرد، تطبیق مالکیت، امتیاز ریسک، بررسی دستی، پذیرش، محدودیت، بازبینی دوره‌ای و خاتمه باشد.

سناریوهای KYC/CDD

کاربر جدید، کاربر بازگشتی و اطلاعات تغییریافته؛
ی/ی، ک/ک، فاصله و نیم‌فاصله در نام فارسی؛
اعداد فارسی/عربی/لاتین در شناسه و تاریخ؛
تفاوت صاحب موبایل/حساب/کیف پول بر اساس قاعده مصوب؛
پاسخ دیر، unavailable یا متناقض سرویس مرجع؛
مدرک منقضی، تکراری، دست‌کاری‌شده یا متعلق به شخص دیگر؛
صف بررسی انسانی، SLA، reason code و separation of duties؛
تغییر نسخه policy و بازبینی مشتریان تحت‌تأثیر؛
حذف/اصلاح داده در حدود مجاز و حفظ audit لازم.

راهنمای Digital Identity از FATF استفاده ریسک‌محور از هویت دیجیتال در customer due diligence را بررسی می‌کند. آن را چارچوب فنی/ریسکی بدانید، نه جایگزین الزام محلی یا موضع حقوقی سازمان.

تست AML و ضدتقلب بدون افشای منطق سوءاستفاده

برای هر rule یا model این موارد را نسخه‌بندی کنید: ورودی‌ها، پنجره زمانی، آستانه مصوب، reason code، outcome، اقدام پس از match و مسیر override. سپس روی داده مصنوعی کنترل‌شده، مرز آستانه، رخداد خارج‌ترتیب، data lag، duplicate، missing field و تغییر زمان را بسنجید.

فقط «درصد کشف» مهم نیست. false positive می‌تواند مشتری سالم و صف بررسی را آسیب بزند؛ false negative ریسک مالی/حقوقی دارد. precision/recall به تفکیک سناریوی مجاز، زمان تا alert، backlog، نرخ override، consistency تصمیم و قابلیت بازتولید نسخه مدل را با هم ببینید. جزئیات سناریوهای مهاجم را در گزارش عمومی منتشر نکنید.

تست امنیت فین‌تک: دارایی، مرز اعتماد، سوءاستفاده

فهرست ابزارهایی مانند SAST، DAST و penetration test راهبرد امنیت نیست. ابتدا دارایی‌ها—پول، هویت، token، کلید، مجوز، دفترکل و evidence—و مرزهای اعتماد را روی data-flow رسم کنید. سپس کنترل و آزمون را به threat متصل کنید.

OWASP ASVS 5.0.0 مبنایی نسخه‌دار برای کنترل‌های امنیتی قابل‌راستی‌آزمایی وب فراهم می‌کند. شناسه الزام را با نسخه، مثلاً v5.0.0-x.y.z، ثبت کنید تا تغییر نسخه مرجع، evidence را مبهم نکند.

هویت، session و recovery

ثبت‌نام و recovery نباید از login ضعیف‌تر باشند؛
OTP باید مصرف واحد، انقضا، محدودیت تلاش و binding به action/session داشته باشد؛
تغییر موبایل، دستگاه یا ذی‌نفع پرریسک باید step-up متناسب داشته باشد؛
logout، revoke، device loss و credential compromise باید sessionها را درست خاتمه دهند؛
پیام خطا نباید وجود حساب، مانده یا هویت را افشا کند؛
دسترسی اپراتور پشتیبانی باید حداقل، قابل‌ممیزی و دو مرحله‌ای برای اقدامات حساس باشد.

NIST SP 800-63B-4 نسخه نهایی جاری راهنمای احراز هویت و مدیریت authenticator است. این سند الزام رگولاتوری ایران نیست، اما منبع فنی معتبری برای طراحی و آزمون چرخه authenticator به شمار می‌رود.

API، callback و webhook

مجوز را برای Object، Property، Function و Tenant جداگانه بیازمایید؛
امضا، timestamp، nonce و replay window callback را تست کنید؛
amount، currency، merchant/order و PSP reference را با رکورد داخلی تطبیق دهید؛
input معتبر ولی از state نامجاز را رد کنید؛
rate limit را کنار جلوگیری از abuse جریان مالی بررسی کنید؛
اعتماد کور به پاسخ یا redirect سرویس ثالث را حذف کنید؛
schema evolution، unknown field و signature canonicalization را پوشش دهید.

OWASP API Security Top 10:2023 علاوه بر authorization، به مصرف ناامن API و دسترسی نامحدود به جریان حساس کسب‌وکار توجه می‌دهد. در فین‌تک، درخواست از نظر schema معتبر می‌تواند از نظر مبلغ، توالی، مجوز یا سرعت سوءاستفاده خطرناک باشد.

Race condition و سوءاستفاده از منطق

دو درخواست هم‌زمان برای خرج مانده، استفاده دوباره از کد تخفیف، تغییر ذی‌نفع بین preview و confirm، refund هم‌زمان و دور زدن limit با چند کانال را آزمایش کنید. تست باید درخواست‌ها را با barrier هم‌زمان آزاد کند و oracle آن دفترکل و مانده باشد، نه فقط پاسخ هر thread.

برای اپلیکیشن کاربر، ذخیره‌سازی، deep link، biometrics، screenshot، network security و release artifact را طبق راهنمای تست امنیت موبایل با OWASP MASVS جداگانه پوشش دهید.

تست تراکنش حجیم با مدل بار واقعی

«یک میلیون درخواست» مدل بار نیست. بار باید از journey و arrival pattern ساخته شود:

سهم ایجاد پرداخت، query وضعیت، callback، refund و گزارش؛
نسبت موفق، ردشده، timeout و retry؛
کاربر جدید در برابر session فعال؛
تعداد پذیرنده/حساب/partition و توزیع hot key؛
اندازه payload و history حساب؛
ساعت اوج، کمپین، پایان روز و cut-off تسویه؛
محدودیت واقعی PSP، بانک، KYC provider و پیامک؛
رشد backlog و ظرفیت catch-up پس از خرابی.

Open model یا Closed model؟

در closed model، کاربر مجازی تا پایان پاسخ منتظر می‌ماند و با کند شدن سیستم، نرخ ورود خودبه‌خود کم می‌شود؛ این می‌تواند overload را پنهان کند. در open model، arrival rate مستقل تعریف می‌شود و برای هجوم تراکنش یا callback واقع‌گرایانه‌تر است. انتخاب را در Workload Manifest بنویسید و نرخ را با فکر زمان و retry تفسیر کنید.

انواع آزمایش

Baseline: یک مسیر کنترل‌شده برای مقایسه نسخه‌ها؛
Load: بار عادی و اوج توافق‌شده؛
Spike: جهش کمپین، اعلان یا بازگشت وابستگی؛
Stress: عبور کنترل‌شده از ظرفیت برای کشف degradation و stop rule؛
Soak: چند چرخه زمانی برای leak، backlog و drift؛
Capacity: رابطه throughput با منابع و headroom؛
Failover: خرابی node/zone/dependency و تعیین RTO/RPO واقعی؛
Recovery: backlog replay، duplicate و reconciliation پس از بازگشت.

نحوه تعریف percentile، throughput، workload، warm-up و معیار پذیرش در راهنمای برنامه تست عملکرد آمده است. برای جریان‌های batch، stream، watermark، backpressure و skew نیز مقاله تست عملکرد Big Data مکمل مناسبی است.

در بار بالا، correctness را همراه latency بسنجید

گزارش خوب فقط p95 و TPS ندارد. در هر اجرای بار این اعداد باید بسته شوند:

تعداد requestهای تولیدشده، پذیرفته‌شده، ردشده و timeout؛
تعداد transaction ID یکتا و idempotency conflict؛
ورودی‌های دفترکل، duplicate و orphan؛
مانده ابتدا/انتها و invariant توازن؛
تعداد callback و event تکراری/دیر/خارج‌ترتیب؛
مغایرت با stub معتبر یا فایل مستقل settlement؛
queue lag، oldest message age و catch-up time؛
p50/p95/p99 در هر مرحله، نه فقط gateway؛
error budget به تفکیک خطای کسب‌وکاری و فنی؛
منابع، connection pool، lock، GC و hot partition.

ممکن است throughput بالا برود چون validation یا audit خاموش شده است. Guardrailهای correctness، امنیت و evidence باید در تست عملکرد فعال بمانند.

Reconciliation، oracle نهایی پول

تست پایان‌به‌پایان یک تراکنش در لحظه کافی نیست. تطبیق باید منابع مستقل را در یک بازه ببندد: سفارش/درخواست، orchestrator، دفترکل داخلی، گزارش PSP/بانک، settlement و refund.

کلاس‌های مغایرت

Missing داخلی یا بیرونی؛
Duplicate با reference یکسان یا متفاوت؛
Amount/currency/unit mismatch؛
Status mismatch و transition حل‌نشده؛
تاریخ تجاری، timezone یا cut-off متفاوت؛
کارمزد، سهم پذیرنده یا مالیات متفاوت؛
refund/reversal بدون پیوند به اصل؛
مغایرت حل‌شده بدون audit و approval.

تست کنید فایل ناقص، duplicate، دیررس، corrupt، با encoding متفاوت یا مربوط به روز تعطیل چگونه پردازش می‌شود. اجرای مجدد reconcile باید idempotent باشد. نتیجه باید inventory مغایرت، مبلغ در معرض ریسک، age، مالک و resolution trail داشته باشد.

داده تست مالی: واقع‌گرایی بدون خطر

داده تولید را به‌طور پیش‌فرض به محیط تست نبرید. یک Data Contract بنویسید که واحد پول، precision، حالت تراکنش، رابطه حساب‌ها، محدودیت‌ها، rare caseها، مقصدهای امن و expiry را تعریف کند.

سناریوهای داده

مبلغ صفر، حداقل، حداکثر و نزدیک overflow؛
ریال/تومان و تبدیل دقیق در یک مرز مشخص؛
کارمزد صفر، ثابت، درصدی، سقف‌دار و برگشت کارمزد؛
مانده ناکافی هم‌زمان با credit جدید؛
partial refundهای متعدد تا سقف اصل؛
شناسه‌های فارسی/لاتین، نام Unicode و نیم‌فاصله؛
تاریخ شمسی/میلادی و Asia/Tehran در cut-off؛
حساب بسته، محدود، frozen یا در بررسی؛
وابستگی sandbox با پاسخ‌های نامعمول و واقعی‌نما.

داده مصنوعی باید relation و invariant مالی داشته باشد؛ random string کافی نیست. شماره کارت/شبا/موبایل تولیدی باید به مقصد واقعی یا شبکه عملیاتی راه پیدا نکند. رویکرد کامل‌تر برای طبقه‌بندی Production، masked و synthetic در خوشه داده تست ثبت می‌شود؛ برای privacy gate فعلاً از تست حریم خصوصی داده استفاده کنید.

مشاهده‌پذیری و audit بدون نشت داده

برای هر business transaction، شناسه‌ای داشته باشید که در channel، API، queue، ledger، callback و reconcile قابل‌ردیابی باشد. اما PAN، CVV، OTP، token، مدرک هویتی و secret نباید به بهانه debugging وارد log شوند.

حداقل event contract:

event ID، transaction ID و causation/correlation ID؛
event type، schema version، event time و receive time؛
from/to state و reason code؛
amount/currency در صورت مجاز با masking مناسب؛
actor/service identity و authorization decision؛
model/rule/config version؛
نتیجه، retry count و dependency reference redacted؛
tamper-evident retention و دسترسی ممیزی‌شده.

دریاچه لاگ و داده تحلیلی هم جزو سطح حمله‌اند. دسترسی، lineage، retention و incident evidence آن‌ها را با راهنمای امنیت دریاچه داده بررسی کنید.

ماتریس CI/CD و محیط‌ها

Lane	شواهد	Gate نمونه
Commit	unit، property/invariant، schema، SAST و secret scan	شکست invariant مالی یا امنیت بحرانی
Pull Request	component، contract، migration و authorization matrix	transition یا مجوز ناقص
Nightly	integration، duplicate/out-of-order، KYC/fraud regression	مغایرت یا drift مدل
Performance	workload manifest، latency، correctness و resource	SLO یا توازن شکسته
Pre-release	mobile/web E2E، pen test scope، failover و restore	ریسک بحرانی/شاهد مفقود
Canary	نسخه محدود، mirror/reconcile و rollback trigger	افزایش mismatch یا false action
Production	SLO، fraud/AML queue، reconciliation و incident	alert، disable یا rollback سیاست‌محور

اگر سرویس‌ها با gRPC ارتباط دارند، deadline، retry، status، metadata و idempotency را طبق راهنمای تست gRPC با قرارداد کسب‌وکاری تراکنش همسو کنید؛ retry خودکار transport نباید retry منطق مالی را چندلایه و انفجاری کند.

مثال ایرانی: کمپین فروش با پرداخت و بازگشت وجه

یک بازارگاه ایرانی برای کمپین، پرداخت اینترنتی و بازگشت وجه کیف پول دارد. اعداد زیر صرفاً workload فرضی‌اند و باید با telemetry واقعی جایگزین شوند: ۲۰۰ ایجاد پرداخت در ثانیه در حالت عادی، جهش تا ۸۰۰، callback با burst پس از بازگشت PSP و query وضعیت توسط کاربران منتظر.

قرارداد و invariant

واحد canonical داخلی ریال است؛ UI تومان را فقط در مرز نمایش تبدیل می‌کند.
هر سفارش فقط یک پرداخت موفق فعال دارد؛ تلاش‌های بعدی به همان order مرتبط‌اند.
callback بدون امضا، با مبلغ/پذیرنده نامنطبق یا خارج replay window اثر مالی ندارد.
timeout پس از انتقال کاربر، وضعیت Unknown می‌سازد و query/reconcile آن را حل می‌کند.
اعتبار کیف پول فقط پس از event معتبر و یک بار ثبت می‌شود.
مجموع partial refund از مبلغ قابل‌برگشت بیشتر نمی‌شود.

آزمایش ترکیبی

callbackها را تکراری، دیر و خارج‌ترتیب تزریق کنید.
پس از commit PSP و پیش از دریافت پاسخ، ارتباط را قطع کنید.
دو درخواست refund را هم‌زمان روی یک مبلغ آزاد کنید.
queue callback را متوقف، backlog بسازید و سپس با burst آزاد کنید.
یک partition دفترکل را hot و replica را کند کنید.
فایل settlement را با Missing/Duplicate/Amount mismatch وارد reconcile کنید.
نسخه را روی درصد محدودی از پذیرندگان canary و اختلاف مالی را mirror کنید.

معیار قبولی

نه duplicate ledger entry، نه مانده منفی غیرمجاز و نه refund بیش از اصل؛ همه تراکنش‌های Unknown تا deadline مصوب تعیین تکلیف شوند؛ mismatch inventory و مبلغ آن قابل‌محاسبه باشد؛ p95/p99 مسیرها و زمان catch-up در بودجه بماند؛ هیچ داده کارت/OTP در log نباشد و trigger rollback قبل از گسترش canary عمل کند.

پرونده شواهد انتشار فین‌تک

Go/No-Go را به «QA تأیید کرد» تقلیل ندهید. یک Release Evidence Pack کوتاه بسازید:

شناسه artifact، config، schema و feature flag؛
دامنه، خارج از دامنه و obligation matrix نسخه‌دار؛
ریسک‌های بحرانی و invariantها؛
نتیجه functional/state/concurrency/reconcile؛
security control coverage و یافته‌های باز؛
workload manifest، نتیجه performance/failover/restore؛
privacy/data evidence و retention؛
مانیتورینگ، canary، rollback و on-call؛
ریسک باقی‌مانده، مالک پذیرش، دلیل و تاریخ انقضا.

QA کیفیت شواهد و شکاف را گزارش می‌کند؛ مالک مجاز کسب‌وکار/ریسک، انتشار با ریسک باقی‌مانده را می‌پذیرد. انطباق واقعی نیز با یک اجرای تست دائمی نمی‌شود: تغییر قانون، کنترل، dependency و threat نیاز به re-evaluation دارد.

برنامه ۳۰روزه برای یک تیم فین‌تک

هفته اول: نقشه و قواعد پول

یک journey بحرانی را از کاربر تا settlement رسم کنید.
state machine و هفت invariant را با محصول، مالی و مهندسی توافق کنید.
منابع الزام و مالک تفسیر را در obligation matrix ثبت کنید.

هفته دوم: failure matrix و داده

duplicate، late، timeout، partial commit و reconcile mismatch را بسازید.
Data Contract ریال/تومان، شناسه، زمان و مقصد امن را نسخه‌بندی کنید.
authorization و callback threat cases را به regression اضافه کنید.

هفته سوم: بار و مشاهده‌پذیری

Workload Manifest از telemetry واقعی تهیه کنید.
correlation از gateway تا ledger و reconcile را کامل کنید.
بار را همراه invariant checker و mismatch counter اجرا کنید.

هفته چهارم: خرابی و تصمیم انتشار

PSP timeout، queue backlog، failover و restore را تمرین کنید.
canary، rollback و on-call را با سناریوی فرضی اجرا کنید.
Evidence Pack و ریسک‌های دارای مالک/انقضا را در جلسه تصمیم مرور کنید.

ضدالگوهای رایج تست فین‌تک

Success مساوی HTTP ۲۰۰: settlement و دفترکل ممکن است خلاف آن باشند.
Success/Failed بدون Unknown: ابهام شبکه به نتیجه جعلی تبدیل می‌شود.
retry بدون idempotency: پایداری ظاهری، اثر مالی تکراری می‌سازد.
TPS بدون تطبیق: سیستم سریع‌تر پول اشتباه تولید می‌کند.
Compliance checklist بی‌نسخه: منبع، قلمرو و تاریخ اثر گم می‌شود.
PCI مساوی امنیت کامل: منطق مالی، API abuse و الزام محلی پوشش کامل ندارند.
Pen test بدون Rules of Engagement: خطر برای داده و سرویس واقعی ایجاد می‌کند.
داده تولید در تست: privacy، مقصد واقعی و retention کنترل نشده‌اند.
میانگین latency: tail، backlog و زمان بازیابی دیده نمی‌شود.
رفع مستقیم دفترکل: تاریخچه بدون compensating entry و approval مخدوش می‌شود.
QA به‌عنوان مفسر قانون: testable evidence جای تصمیم حقوقی را می‌گیرد.
AI به‌عنوان درمان: مدل بدون baseline، reason code و drift evidence ریسک تازه می‌سازد.

جمع‌بندی

تست فین‌تک بالغ، سه جریان را روی یک مدل واحد همگرا می‌کند: الزام به کنترل و شاهد؛ threat به آزمون امنیتی؛ و بار به صحت مالی و بازیابی. قلب این مدل، state machine تراکنش، invariantهای پول، idempotency و reconciliation است.

برای محصول ایرانی، ریال/تومان، ارقام و نام فارسی، تقویم و cut-off، کیفیت شبکه، callback PSP، محدودیت تأمین‌کننده و تغییرات مقرراتی جزئیات حاشیه‌ای نیستند. آن‌ها باید در قرارداد، داده، workload و evidence حضور داشته باشند. پرسش نهایی انتشار این نیست که «تست‌ها سبزند؟»؛ این است که «آیا برای هر ریال و هر تصمیم حساس، واقعیت قابل‌ردیابی و ریسک دارای مالک داریم؟»

سؤالات متداول

مهم‌ترین تست در سامانه پرداخت چیست؟

یک تست واحد کافی نیست. مهم‌ترین هسته، اثبات invariantهای مالی در timeout، duplicate، retry و out-of-order است و سپس تطبیق دفترکل با منبع مستقل. Happy path بدون این شکست‌ها اعتماد کاذب می‌دهد.

تفاوت تست بار فین‌تک با تست بار عادی چیست؟

علاوه بر latency، throughput و منابع، باید تعداد اثر مالی یکتا، توازن دفترکل، duplicate، وضعیت‌های Unknown، backlog، زمان catch-up و مغایرت settlement را ببندید. سرعت بدون correctness معیار قبولی نیست.

آیا PCI DSS برای هر فین‌تک اجباری است؟

Applicability به نقش، جریان داده کارت، قرارداد و محدوده محیط بستگی دارد و باید توسط صاحب تطبیق/متخصص PCI تعیین شود. اگر applicable باشد، نسخه جاری و روش اعتبارسنجی را ثبت کنید؛ اگر نباشد، امنیت و قوانین دیگر همچنان لازم‌اند.

QA چگونه تست انطباق بنویسد بدون اینکه حقوق‌دان باشد؟

متن و قلمرو مصوب را از حقوقی/تطبیق دریافت، آن را به testable statement، کنترل، scenario و evidence تبدیل و traceability را نگهداری کند. QA نباید خودش نتیجه دهد کدام قانون یا آستانه شامل شرکت است.

در timeout پرداخت چه وضعیتی به کاربر نشان دهیم؟

اگر commit بیرونی نامعلوم است، موفق یا ناموفق قطعی نسازید. یک وضعیت Pending/در حال بررسی با پیام روشن، جلوگیری از پرداخت تکراری، query وضعیت، deadline تعیین تکلیف و reconciliation لازم است. جزئیات UX و زمان به قرارداد محصول وابسته‌اند.

تست نرم افزار, سطوح تست

تست فین‌تک؛ انطباق، امنیت و تراکنش‌های حجیم