پاسخ نهایی آزمونی
مسئله دربارهی تست یک جریان کامل سفارش در یک فروشگاه آنلاین ساده است؛ از ثبت کاربر تا افزودن کالا، ثبت سفارش، پرداخت و مشاهده وضعیت سفارش. نکتهی اصلی این است که APIها بهصورت stateful هستند، یعنی نتیجهی هر مرحله به داده و وضعیت مرحلهی قبل وابسته است. بنابراین در این سؤال نباید فقط endpointها را جداگانه تست کرد؛ باید کل جریان سفارش بهصورت زنجیرهای و با حفظ state بررسی شود.
نیازمندی کامل بیان نشده و قبل از تصمیم قطعی باید با تحلیلگر یا مالک محصول رفع ابهام شود؛ مخصوصاً دربارهی endpointها، ساختار request و response، وضعیتهای مجاز سفارش، قوانین reject، نحوهی authentication، رفتار payment تکراری و روش reset کردن state در Mockoon. با این حال، در نبود اطلاعات بیشتر، فرض میکنم سیستم شامل APIهایی برای ثبت کاربر، دریافت یا انتخاب کالا، افزودن کالا به سبد خرید، ایجاد سفارش، پرداخت و دریافت وضعیت سفارش است.
رویکرد درست این است که ابتدا جریان API را با Postman تست کنم، چون در Postman میتوانم دادهی خروجی هر مرحله مثل userId، cartId، orderId و paymentId را ذخیره کنم و در requestهای بعدی استفاده کنم. سپس جریان اصلی را از طریق UI با Playwright یا Selenium بررسی میکنم تا مطمئن شوم رابط کاربری هم درست با Mockoon و APIها کار میکند.
در Postman یک collection طراحی میکنم که ترتیب اجرای requestها به شکل زیر باشد:
1. ثبت کاربر جدید
2. انتخاب یا دریافت کالا
3. افزودن کالا به سبد خرید
4. ثبت سفارش
5. پرداخت سفارش
6. مشاهده وضعیت سفارش
در هر request فقط status code را بررسی نمیکنم؛ بلکه response body، schema، فیلدهای اجباری، پیام خطا یا موفقیت، و state بعد از عملیات را هم assert میکنم. برای مثال بعد از ثبت کاربر باید userId یا token دریافت شود. بعد از ایجاد سفارش باید orderId تولید شود و وضعیت سفارش مثلاً pending_payment باشد. بعد از پرداخت موفق، وضعیت سفارش باید به paid یا completed تغییر کند.
برای مسیر موفق، سناریوی اصلی این است که کاربر با داده معتبر ثبت شود، یک کالای معتبر به سبد اضافه کند، سفارش ایجاد شود، پرداخت موفق انجام شود و در نهایت وضعیت سفارش به حالت پرداختشده تغییر کند. در این سناریو باید بررسی شود که دادهها بین لایهها درست منتقل شدهاند و state سیستم در هر مرحله مطابق انتظار تغییر کرده است.
برای مسیرهای منفی و reject، سناریوهای زیر را بررسی میکنم:
ثبت کاربر با داده ناقص یا email تکراری
افزودن کالای نامعتبر به سبد خرید
افزودن کالا با تعداد صفر، منفی یا بیشتر از موجودی
ثبت سفارش با سبد خرید خالی
پرداخت سفارش نامعتبر
پرداخت قبل از ایجاد سفارش
پرداخت تکراری برای یک سفارش
مشاهده وضعیت سفارش با orderId نامعتبر
مشاهده سفارش کاربر دیگر با تغییر orderId
ارسال request بدون header یا token معتبر
ارسال request body ناقص یا با schema اشتباه
در هر کدام از این حالتها باید بررسی شود که سیستم فقط خطا برنمیگرداند، بلکه state را هم اشتباه تغییر نمیدهد. مثلاً اگر پرداخت با orderId نامعتبر انجام شد، نباید سفارش جدید ساخته شود یا وضعیت سفارش دیگری تغییر کند. اگر پرداخت تکراری ارسال شد، باید رفتار سیستم مشخص باشد؛ یا reject شود، یا بهصورت idempotent همان نتیجه قبلی را برگرداند. این مورد چون با پرداخت و ریسک مالی مرتبط است، بسیار حساس است.
برای تست UI با Playwright یا Selenium، همهی سناریوهای منفی را از UI اجرا نمیکنم، چون UI test کندتر و شکنندهتر است. تستهای عمیقتر و متنوعتر را در سطح API انجام میدهم و در UI تمرکز را روی مسیرهای مهم میگذارم؛ مثلاً:
ثبت کاربر از فرم UI
انتخاب کالا و افزودن به cart
ثبت سفارش
پرداخت
نمایش وضعیت نهایی سفارش
نمایش پیام خطای مناسب در یک یا دو سناریوی reject مهم
در UI automation باید از selectorهای پایدار استفاده شود، برای load شدن صفحه و پاسخ API انتظار مناسب گذاشته شود، و فقط به دیده شدن یک دکمه یا متن ساده اکتفا نشود. باید بررسی شود که پیام نهایی، وضعیت سفارش و دادههای نمایشدادهشده با response API هماهنگ هستند.
از نظر environment، باید قبل از اجرای تست مشخص شود Mockoon روی چه port و base URL اجرا میشود، داده اولیه محصولات چیست، state چگونه نگهداری میشود و آیا قبل از هر run امکان reset کردن state وجود دارد یا نه. اگر state بین اجراها پاک نشود، تستها ممکن است flaky شوند؛ یعنی یک بار pass شوند و بار بعد بدون تغییر کد fail شوند.
گزارش نهایی تست باید فقط شامل pass/fail نباشد. باید نشان دهد در هر مرحله چه دادهای تولید شده، چه دادهای به مرحله بعد منتقل شده، state از چه حالتی به چه حالتی تغییر کرده، کدام سناریوهای reject درست handle شدهاند، و چه ابهامها یا ریسکهایی باقی مانده است.
ریسکهای اصلی این سناریو عبارتاند از:
وابستگی شدید تستها به ترتیب اجرا
آلوده شدن state بین چند اجرای تست
ناقص بودن mock نسبت به backend واقعی
پرداخت تکراری و نبود idempotency مشخص
ضعف در authorization و احتمال idor
assert نکردن business rule و اکتفا به status code
flaky شدن تستهای UI به دلیل timing یا selector نامناسب
نبود correlation id یا trace id برای ردیابی خطاها
پس پاسخ حرفهای این است که این سؤال را بهعنوان یک تست ترکیبی API + integration + stateful workflow + UI/E2E ببینیم. ابتدا جریان را در سطح API با Postman و Mockoon دقیق و قابل تکرار تست میکنیم، بعد مسیر اصلی را از UI با Playwright یا Selenium تأیید میکنیم، و در نهایت گزارشی میدهیم که هم data flow و هم state transition و هم rejectهای منطقی را پوشش دهد.
نسخه کوتاهتر برای آزمون
این سؤال مربوط به تست جریان سفارش در فروشگاه آنلاین است؛ از ثبت کاربر تا افزودن کالا، ثبت سفارش، پرداخت و مشاهده وضعیت سفارش. چون APIها stateful هستند، ترتیب requestها و دادههای تولیدشده در هر مرحله اهمیت دارد و نمیتوان endpointها را کاملاً مستقل تست کرد.
نیازمندی کامل بیان نشده و قبل از تصمیم قطعی باید با تحلیلگر یا مالک محصول رفع ابهام شود؛ مخصوصاً درباره endpointها، request/response schema، stateهای سفارش، قوانین reject، authentication، idempotency پرداخت و reset شدن state در Mockoon.
در نبود اطلاعات بیشتر، فرض میکنم خروجی هر مرحله مثل userId، cartId، orderId و paymentId در مرحله بعد استفاده میشود. ابتدا با Postman یک collection میسازم که register، add to cart، create order، payment و check status را به ترتیب اجرا کند. در هر مرحله علاوه بر status code، response schema، business rule، دادههای برگشتی و تغییر state را بررسی میکنم.
مسیر موفق باید نشان دهد کاربر ثبت میشود، کالا به سبد اضافه میشود، سفارش ساخته میشود، پرداخت موفق انجام میشود و وضعیت سفارش به paid یا completed تغییر میکند. مسیرهای منفی شامل cart خالی، product نامعتبر، quantity نامعتبر، payment قبل از order، payment تکراری، orderId نامعتبر، request ناقص و دسترسی غیرمجاز به سفارش کاربر دیگر است.
بعد از API testing، مسیر اصلی را با Playwright یا Selenium از UI اجرا میکنم تا مطمئن شوم کاربر واقعی هم میتواند خرید را کامل کند و UI درست با API و Mockoon کار میکند. گزارش نهایی باید شامل data flow، state transition، سناریوهای pass/fail، rejectهای درست، ابهامها و ریسکهایی مثل state آلوده، duplicate payment، authorization issue و flaky UI test باشد.
کلیدواژهها:
api testing, integration testing, end-to-end testing, stateful workflow testing, state transition, data flow, postman, mockoon, mock server, playwright, selenium, test data, assertion, schema validation, business rule validation, negative testing, reject scenario, idempotency, authentication, authorization, idor, correlation id, trace id, flaky test, state reset, risk-based testing
