راهنمای تست API و نکاتی برای مبتدیان (SOAP و REST) – به زبان ساده

تست کردن API که اختصاری برای عبارت «رابط برنامه‌نویسی اپلیکیشن» (application programming interface) است نوعی از تست نرم‌افزار است که در آن تأیید به طور مستقیم در سطح API صورت می‌گیرد. این تست بخشی از تست یکپارچگی است که به وسیله آن مشخص می‌شود API-ها انتظارهای تست‌کننده را در مورد کارکردها، پایداری، عملکرد و امنیت برآورده می‌سازند یا نه. برخلاف تست کردن UI، تست API در سطح پیام‌رسانی و بدون رابط کاربری گرافیکی (GUI) صورت می‌گیرد.

به طور کلی دو دسته از وب‌سرویس‌ها برای API وب وجود دارند که SOAP و REST نام دارند. SOAP که اختصاری برای عبارت «پروتکل دسترسی شیء ساده» (Simple Object Access Protocol) است یک پروتکل استاندارد محسوب می‌شود که به وسیله استانداردهای W3C برای ارسال و دریافت درخواست‌ها و پاسخ‌های سرویس‌های وب مورد استفاده قرار می‌گیرد. REST که اختصاری برای عبارت «انتقال حالت بازنمایانه» (REpresentational State Transfer) است یک معماری مبتنی بر استانداردهای وب برای استفاده از HTTP محسوب می‌شود. اما برخلاف وب‌سرویس‌های مبتنی بر SOAP، هیچ استاندارد رسمی برای API-های وب RESTful ارائه نشده است.

در این مقاله به 10 نکته که هنگام تست کردن API باید بدانید پرداخته‌ایم.

1. درک الزامات API

پیش از تست کردن API–ها باید به سؤالات زیر پاسخ دهید تا الزامات API را به طور کامل درک کنید:

فیلم آموزش پستمن Postman – ابزار تست ای پی آی API در فرادرس

کلیک کنید

مقصود از API چیست؟

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

گردش کار اپلیکیشن چگونه است و API در کجای این گردش کار قرار می‌گیرد؟

به طور کلی API-های یک اپلیکیشن برای دستکاری منابعش مورد استفاده قرار می‌گیرند. از این API–ها به منظور خواندن، ایجاد، و به‌روزرسانی استفاده می‌شود و از این رو دانستن مقصود از API باعث می‌شود که بتوانید به درستی مراحل ورودی و خروجی API را طراحی کنید. برای نمونه خروجی API به نام «Create user» ممکن است ورودی API دیگری به نام «Get user» برای تأیید باشد. خروجی API به نام «Get user» نیز می‌تواند به عنوان ورودی API به نام «Update user» استفاده شود و همین طور تا آخر.

2. تعیین وضعیت‌های خروجی API

متداول‌ترین خروجی API که باید در زمان تست کردن آن تأیید شود کد وضعیت پاسخ است.

فیلم آموزش REST API در وردپرس برای کار با داده های پایگاه داده در فرادرس

کلیک کنید

تأیید به این صورت که بر اساس بررسی کد پاسخ 200 نتیجه بگیریم تست موفق و در غیر این صورت ناموفق بوده است، یک کار آماتور محسوب می‌شود. گرچه این روش نادرست نیست؛ اما نمی‌تواند همه سناریوهای تست API را نشان دهد.

همه کدهای وضعیت پاسخ‌های API را در یک استاندارد جهانی، می‌توان به پنج دسته تقسیم کرد. رقم نخست کد وضعیت، دسته پاسخ را تعیین می‌کند. دو رقم آخر هیچ نقشی در دسته یا طبقه کد ندارند.

پنج مقدار برای رقم نخست وجود دارد:

• 1xx (اطلاع‌رسانی): درخواست دریافت شده و در حال پردازش است.
• 2xx (موفقیت): درخواست با موفقت دریافت، درک و پذیرفته شده است.
• 3xx (هدایت مجدد): برای تکمیل درخواست به کارهای دیگری نیاز داریم.
• 4xx (خطای کلاینت): درخواست شامل ساختار نادرست است یا نمی‌تواند برخی از الزامات را برآورده سازد.
• 5xx (خطای سرور): سرور نمی‌تواند به درخواستی که به ظاهر صحیح است پاسخ دهد.

با این حال کدهای واقعی وضعیت پاسخ یک API از سوی تیم توسعه که آن را می‌سازند تعیین می‌شوند. بنابراین یک تست‌کننده باید موارد زیر را تأیید کند:

• کد از دسته‌های استاندارد جهانی پیروی می‌کند.
• یا کد در الزامات API مورد اشاره قرار گرفته است.

3. تمرکز روی API-های کارکردی کوچک

در یک پروژه تست، همواره API-های ساده‌ای مانند API ورود (در اصطلاح Login API)، دریافت توکن، API بررسی سلامت و غیره وجود دارند که تنها یک یا دو ورودی دارند. با این وجود، این API –ها ضروری هستند و به عنوان یک دروازه (gate) برای وارد کردن API-های دیگر تلقی می‌شوند. تمرکز روی این API-ها پیش از API-های دیگر باعث می‌شود مطمئن شویم که در سرورهای API، محیط و احراز هویت به درستی کار می‌کند.

فیلم آموزش REST API در لاراول Laravel با بسته Passport در فرادرس

کلیک کنید

در هر مورد تست، باید از تست کردن بیش از یک API اجتناب کنید، چون در صورتی که خطایی رخ دهد، دیباگ کردن گردش داده منتهی به API-های متوالی کاری دشوار خواهد بود. بنابراین باید مراحل تست API را تا حد امکان ساده نگه دارید. برخی موارد وجود دارند که در آن باید یک سری از API-ها را تست کنیم تا به یک گردش تست سربه‌سر دست یابیم. با این وجود، این وظایف باید پس از آن که همه API-ها به طور منفرد تست شدند، اجرا شوند.

4. سازماندهی نقاط انتهایی API

یک پروژه تست می‌تواند چند مورد معدود یا صدها API برای تست داشته باشد. در هر صورت باید حتماً همه این API-ها در دسته‌هایی سازماندهی شوند تا بتوان آن‌ها را به صورت صحیحی مدیریت کرد. این کار یک گام دیگر به مراحل تست می‌افزاید؛ اما کمک زیادی برای ایجاد سناریوهای تست با پوشش و انسجام بالا می‌کند. برای نمونه API جیرا (JIRA) را در نظر بگیرید:

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

5. بهره‌گیری از قابلیت اتوماسیون برای تست کردن API

شما باید تا حد امکان از ظرفیت اتوماسیون برای تست API استفاده کنید. در ادامه برخی از مزیت‌های اتوماتیک ساختن تست‌های API را برشمرده‌ایم:

فیلم آموزش فریم ورک جنگو در پایتون – ساخت Web APIs با Django Rest در فرادرس

کلیک کنید

• داده‌های تست و سابقه اجرا را می‌توان همراه با نقاط انتهایی API ذخیره ساخت. این امر موجب می‌شود که بتوانیم تست‌ها را بعداً راحت‌تر به صورت مجدد اجرا کنیم.
• تست‌های API پایدار می‌شوند و با دقت تغییر می‌یابند. یک API نشان‌دهنده یک قاعده تجاری برای سیستم است. هر تغییری در API نیازمند الزامات مشخصی است. از این رو تست‌کننده‌ها می‌توانند همواره در مورد هر نوع تغییری در API و تعدیل به موقع آن‌ها هوشیار بمانند.
• اجرای تست در مقایسه با تست UI وب بسیار سریع‌تر می‌شود.
• تست کردن API معمولاً فرایندی است که به صورت جعبه سیاه نگریسته می‌شود که در طی آن کاربران ورودی را می‌فرستند و یک خروجی برای تأیید می‌گیرند. اتوماسیون با رویکرد مبتنی بر داده یعنی به‌کارگیری مجموعه داده‌های مختلف در یک سناریوی تست واحد می‌تواند به افزایش پوشش تست API کمک کند.
• ورود و خروج داده از قالب‌ها و مدل‌های مشخصی پیروی می‌کند، به طوری که می‌توان اسکریپت‌های تست را تنها یک بار ایجاد کرد و این اسکریپت‌های تست می‌توانند بارها در سراسر پروژه تست مورد استفاده مجدد قرار گیرند.
• تست‌های API را می‌توان در مراحل اولیه چرخه توسعه نرم‌افزار اجرا کرد. رویکرد اتوماسیون با شبیه‌سازی تکنیک‌های مورد استفاده می‌تواند به منظور کمک به تأیید API و یکپارچه‌سازی آن پیش از توسعه API واقعی مورد استفاده قرار گیرد. از این رو سطح وابستگی درون تیم کاهش می‌یابد.

6. انتخاب ابزار مناسب برای اتوماسیون

یک گام دیگر برای بهره‌گیری از ظرفیت اتوماسیون جهت تست کردن API، انتخاب مناسب‌ترین ابزار یا مجموعه‌ای از مناسب‌ترین ابزارها از میان صدها گزینه موجود در بازار است. در ادامه چند معیار که باید هنگام انتخاب ابزار تست خودکار API در نظر داشت را معرفی کرده‌ایم:

آیا ابزار از تست انواع سرویس API/Web که AUT (اپلیکیشن تحت تست) شما استفاده کرده، پشتیبانی می‌کند یا نه؟ در صورتی که ابزار منتخب از تست سرویس‌های RESTful پشتیبانی می‌کند، در حالی که اپلیکیشن تست شما از سرویس‌های SOAP بهره گرفته است، استفاده از این ابزار بی‌معنی خواهد بود.

آیا ابزار منتخب از متدهای احراز هویت که سرویس اپلیکیشن تحت تست شما نیاز دارد، پشتیانی می‌کند؟ در ادامه برخی از متدهای احراز هویت که API می‌تواند استفاده کند را فهرست کرده‌ایم:

• No Auth
• Bearer Token
• Basic auth
• Digest Auth
• NTLM Authentication
• OAuth 1.0
• OAuth 2.0
• Hawk Authentication
• AWS Signature

این یک بحث ضروری است، زیرا بدون احراز هویت نمی‌توان شروع به تست یک API کرد.

• آیا ابزار شما از ایمپورت نقاط انتهایی سرویس API/Web با خصوصیات WSDL, Swagger, WADL و دیگر مشخصات سرویس پشتیبانی می‌کند؟ این یک خصوصیت اختیاری است ولی در صورتی که بخواهید صدها API را تست بکنید بهتر است آن را داشته باشید، چون صرفه‌جویی زمانی زیادی ایجاد می‌کند.
• آیا ابزار منتخب از متدهای داده محور (data-driven) پشتیبانی می‌کند؟ این خصوصیت نیز اختیاری است؛ اما پوشش تست در صورت پشتیانی ابزار به میزان زیادی افزایش می‌یابد.
• به عنوان آخرین نکته که حائز اهمیت کمی هم نیست، باید ببینید که علاوه بر تست کردن API به اجرای انواع دیگری از تست مانند WebUI یا منابع داده هم نیاز دارید یا نه؟ تست کردن API در لایه تجاری بین منابع داده و UI صورت می‌گیرد. معمولاً همه این لایه‌ها با همدیگر تست می‌شوند. از این رو ابزاری که بتواند همه این انواع تست را اجرا کند، بسیار مناسب خواهد بود، زیرا شیءهای تست و اسکریپت‌های تست را می‌توان بین همه لایه‌ها به اشتراک گذاشت.

7. انتخاب متدهای مناسب برای تأیید

با این که کد وضعیت پاسخ، وضعیت فعلی پاسخ را مشخص می‌سازد؛ اما محتوای متنیِ پاسخ، آن چیزی است که API بر مبنای ورودی کاربر بازمی‌گرداند. محتوای پاسخ یک API از نظر نوع و اندازه کاملاً متغیر است. پاسخ‌ها می‌توانند به صورت متن ساده، ساختمان داده JSON، SML، سند، و یا موارد دیگر باشند. پاسخ می‌تواند چند کلمه ساده (و یا حتی خالی) و یا یک فایل JSON یا XML با صدها صفحه محتوا باشد. از این رو انتخاب روش تأیید مناسب برای هر API مفروض بسیار حائز اهمیت است. به طور کلی برخی روش‌های مقدماتی برای تأیید محتوای متنی پاسخ یک API وجود دارند:

مقایسه کل محتوای متنی پاسخ با اطلاعات مورد انتظار

این روش برای یک پاسخ ساده با محتوای استاتیک مناسب است. اطلاعات دینامیک مانند زمان –تاریخ، ID افزایشی و غیره در این مورد موجب بروز مشکل می‌شوند.

مقایسه هر یک از مقادیر خصوصیت در پاسخ

برای آن دسته از پاسخ‌هایی که در قالب JSON یا XML ارائه می‌شوند، می‌توان به سادگی مقدار یک کلید یا خصوصیت مفروض را به دست آورد. از این رو این متد زمانی مفید است که بخواهیم محتوای دینامیک یا مقدار منفرد را به جای کل محتوا تأیید کنیم.

مقایسه تطبیق با عبارت‌های منظم (Regular Expression)

این روش همراه با تأیید مقادیر خصوصیت منفرد برای تأیید پاسخ‌های داده با الگوی خاص برای مدیریت داده‌های دینامیک پیچیده استفاده می‌شود.

هر روش تأیید، مزایا و معایب خاص خود را دارد و یک گزینه همه‌کاره وجود ندارد. شما باید راه‌حلی که برای پروژه تست شما مناسب‌تر است را انتخاب کنید.

8. ایجاد تست‌های مثبت و منفی

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

فیلم آموزش پستمن Postman – ابزار تست ای پی آی API در فرادرس

کلیک کنید

تست مثبت

• این که API ورودی را می‌گیرد و خروجی مورد انتظار را چنان که در الزامات تعیین شده است بازمی‌گرداند، تأیید شود.
• تأیید شود که کد وضعیت آن چنان که در الزامات API تعیین شده است بازگشت می‌یابد و این شامل بازگشت کدهای موفقیت 2xx یا کدهای بروز خطا می‌شود.
• ورودی دارای کمترین فیلدهای الزامی و دارای بیشترین فیلدها مشخص شوند.

تست منفی

• تأیید شود که API پاسخ‌های مناسبی را هنگام عدم وجود خروجی مورد انتظار بازمی‌گرداند.
• تست تأیید ورودی اجرا شود.
• تأیید شود که رفتارهای API بر اساس سطوح مختلف احراز هویت، متناسب است.

9. فرایند تست کردن به صورت زنده (Live Testing)

زمان‌بندی اجرای تست API به صورت هر روزه در حالی که فرایند تست زنده است کاملاً توصیه می‌شود. از آنجا که اجرای تست API سریع و به اندازه کافی کوچک است، افزودن تست‌های بیشتر به فرایند تست جاری با کمترین ریسک آسان خواهد بود. این حالت تنها در مورد ابزارهای تست خودکار API که ویژگی‌های زیر را داشته باشند، میسر خواهد بود:

• زمان‌بندی تست با دستورهای تست داخلی (built-in)
• یکپارچه‌سازی با ابزارهای مدیریت تست و ابزارهای ردگیری نقص
• ادغام مداوم با ابزارهای CI مختلف
• ایجاد گزارش‌های log بصری

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

10. تست خودکار API را دست‌کم نگیرید

گردش کار تست API بسیار ساده است و می‌توان آن را در سه گام عمده خلاصه کرد:

• ارسال درخواست با داده‌های ورودی مورد نیاز
• دریافت پاسخ‌هایی که دارای داده‌های خروجی هستند.
• تأیید این که پاسخ بازگشتی با الزامات مورد انتظار مطابقت دارد.

فیلم آموزش REST API در لاراول Laravel با بسته Passport در فرادرس

کلیک کنید

دشوارترین بخش‌های تست کردن API قسمت‌های ارسال درخواست یا دریافت پاسخ نیستند؛ بلکه بخش‌های مدیریت داده تست و تأیید هستند. معمولاً تست کردن برخی API–های اولیه مانند login، کوئری منابع و غیره کاملاً ساده است؛ اما با حرکت رو به جلو و رسیدن به API-های پیچیده‌تر به مرور این وظیفه دشوارتر می‌شود. از این رو وظیفه تست کردن API به راحتی ممکن است دست‌کم گرفته شود. بدین ترتیب ممکن است زمانی فرا برسد که خود را در مقام انتخاب رویکرد مناسب برای تست داده‌ها و روش تأیید بیابید. دلیل این مسئله آن است که داده‌ها بازگشتی ساختارهای مشابهی دارند؛ اما این موضوع در مورد یک پروژه تست صدق نمی‌کند. تصمیم‌گیری در مورد این که باید داده‌های JSON/XML به صوت کلید به کلید تأیید شوند یا از نگاشت شیء برای کمک گرفتن از قدرت زبان برنامه‌نویسی استفاده کرد، امری دشوار محسوب می‌شود.

استفاده از تست خودکار API برای یک پروژه واقعی در حال توسعه کاملاً پیشنهاد می‌شود. این فرایند باید طوری سازماندهی شود که قابل بسط، قابل استفاده مجدد و قابل نگهداری باشد.

اگر این مطلب برایتان مفید بوده است، آموزش‌های زیر نیز به شما پیشنهاد می‌شوند:

• مجموعه آموزش‌های برنامه‌نویسی
• API چیست و API های باز چگونه اینترنت را تغییر می‌دهند؟
• مجموعه آموزش‌های طراحی و برنامه نویسی وب
• OpenStreetMap — بارگذاری داده‌ها به کمک پایتون و Overpass API
• آموزش REST API در وردپرس برای کار با داده های پایگاه داده
• ساخت API امن با Spring Boot و Angular 6 — از صفر تا صد
• وب سرویس SOAP چیست ؟ — به زبان ساده

==