یک API در اصل «مرد میانی» لایه‌ها و سیستم‌های یک برنامه یا نرم‌افزار است. تست API (رابط برنامه‌نویسی برنامه) در لایه پیام بدون رابط کاربری گرافیکی انجام می‌شود. این بخشی از تست یکپارچه‌سازی است که تعیین می‌کند آیا APIها انتظارات آزمایش‌کنندگان را در مورد عملکرد، قابلیت اطمینان، عملکرد و امنیت برآورده می‌کنند یا خیر. 

دو دسته وسیع از خدمات وب برای Web API وجود دارد: SOAP و REST. 

SOAP یک پروتکل استاندارد است که توسط استانداردهای W3C برای ارسال و دریافت درخواست‌ها و پاسخ‌های سرویس وب تعریف شده است. 

REST معماری مبتنی بر استانداردهای وب است که از HTTP استفاده می‌کند. برخلاف خدمات مبتنی بر SOAP، هیچ استاندارد رسمی برای RESTful Web API وجود ندارد. 

نکات اساسی در تست API ها

در اینجا ۱۰ نکته اساسی وجود دارد که باید برای تست API بدانید: 

۱- الزامات API را درک کنید

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

هدف API چیست؟ 

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

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

به طور کلی، APIهای یک برنامه کاربردی برای دستکاری منابع آن در خواندن (GET)، ایجاد (POST)، به‌روزرسانی (PUT) و حذف (DELETE) استفاده می‌شود. دانستن هدف API پایه محکمی برای شما ایجاد می‌کند تا به خوبی داده‌های تست API خود را برای ورودی و خروجی آماده کنید. 

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

به عنوان مثال، خروجی ای‌پی‌آیِ «create user» به عنوان خروجی ای‌پی‌آیِ «Get user» برای فرایند تایید استفاده می‌شود. خروجی ای‌پی‌آیِ «Get user» را می‌توان به عنوان ورودی ای‌پی‌آیِ «Update user» استفاده کرد. 

۲- وضعیت خروجی API را مشخص کنید

رایج‌ترین خروجی API که باید در تست API تایید کنید، کد وضعیت پاسخ است. در یادداشت «مدیریت خطای API: استراتژی‌هایی برای مدیریت و گزارش‌دهی موثر خطا» تمام نکاتی که باید در زمینه خطاهای API بدانید، بررسی کردیم. اما در اینجا هم چند نکته را به اختصار خواهیم گفت. 

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

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

پنج مقدار متداول برای وضعیت پاسخ‌ها وجود دارد که بر اساس رقم اول آن‌ها دسته‌بندی می‌شود: 

1xx (اطلاعاتی): درخواست دریافت شده و رسیدگی به آن ادامه دارد. 

2xx (موفق): درخواست با موفقیت دریافت، درک و پذیرفته شد. 

3xx (ریدایرکشن): برای تکمیل درخواست باید اقدامات بیشتری انجام شود. 

 4xx (خطای مشتری): درخواست حاوی سینتکس اشتباه است و یا قابل انجام نیست. 

5xx (خطای سرور): سرور یک درخواست ظاهرا معتبر را انجام نمی‌دهد. 

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

• کد از کلاس‌های استاندارد جهانی تبعیت می‌کند یا نه؟
• مد در الزامات مشخص شده است یا نه؟

۳- روی APIهای کاربردی کوچک تمرکز کنید

در یک پروژه آزمایشی، همیشه برخی از APIها وجود دارند که تنها با یک یا دو ورودی ساده هستند، مانند get token API، Login API، health check API و غیره. با این حال، این APIها ضروری هستند و به عنوان دروازه برای ورود در نظر گرفته می‌شوند. تمرکز بیشتر روی این APIها قبل از دیگران، باعث می‌شود این اطمینان به وجود آید که سرورهای API، محیط و احراز هویت به درستی کار می‌کنند. 

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

۴- نقاط پایانی API را سازماندهی کنید

یک پروژه آزمایشی ممکن است چند و یا حتی صدها API برای آزمایش داشته باشد. ما به شدت پیشنهاد می‌کنیم که آن‌ها را در دسته‌بندی‌ها برای مدیریت بهتر تست سازماندهی کنید. این یک مرحله اضافی است و ممکن است زمان شما را کمی تلف کند، اما به طور قابل توجهی به شما کمک می‌کند تا سناریوهای آزمایشی با پوشش و ادغام بالا ایجاد کنید. 

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

۵- از قابلیت اتوماسیون برای تست API استفاده کنید

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

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

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

۶- یک ابزار مناسب برای اتوماسیون انتخاب کنید

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

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

No Auth

Bearer Token 

Basic auth

Digest Auth

NTLM Authentication 

OAuth 1.0

OAuth 2.0 

Hawk Authentication 

AWS Signature

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

• آیا این ابزار از وارد کردن نقاط پایانی API یا وب‌سرویس از WSDL، Swagger و WADL  و سایر سرویس‌ها پشتیبانی می‌کند؟ این یک ویژگی اختیاری است. با این حال، اگر صدها API برای آزمایش داشته باشید، زمان‌بر خواهد بود. 
• آیا این ابزار از روش‌های داده‌محور پشتیبانی می‌کند؟ این نیز یک ویژگی اختیاری است. با این حال، اگر ابزار دارای این عملکرد باشد، پوشش تست شما به طور چشمگیری افزایش می‌یابد. 
• موضوع آخر و نه آخرین موضوع؛ علاوه‌بر تست API، آیا نیاز به انجام انواع دیگری از تست‌ها مانند WebUI یا منبع داده وجود دارد؟ تست API در لایه تجاری بین منابع داده و UI انجام می‌شود. طبیعی است که همه این لایه‌ها باید آزمایش شوند. ابزاری که از همه انواع تست پشتیبانی می‌کند، یک انتخاب ایده‌آل خواهد بود تا اشیا آزمایشی و اسکریپت‌های آزمایشی شما در تمام لایه‌ها به اشتراک گذاشته شوند. 

۷- روش‌های راستی آزمایی مناسب را انتخاب کنید

در حالی که کد وضعیت پاسخ به ما درباره‌ی وضعیت درخواست می‌گوید، محتوای بدنه پاسخ همان چیزی است که یک API با ورودی داده شده، بر می‌گرداند. 

محتوای پاسخ API بسته به نوع و اندازه داده‌ها متفاوت است. پاسخ‌ها می‌توانند به صورت متن ساده، داده‌های ساختار یافته JSON ، مستندات XML  و چیزهای دیگری باشند. آن‌ها می‌توانند یک رشته ساده چند کلمه‌ای (حتی خالی) یا یک فایل JSON/XML صد صفحه‌ای باشند. از این رو، انتخاب یک روش تایید مناسب برای یک API معین ضروری است. 

در حال حاضر Katalon Studio کتابخانه‌های غنی را برای تایید انواع داده‌های مختلف با استفاده از تطبیق، بیان منظم، JsonPath و XMLPath فراهم کرده است. 

به طور کلی، چند روش اساسی برای تایید محتوای بدنه پاسخ API وجود دارد: 

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

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

• هر مقدار ویژگی پاسخ را مقایسه کنید.

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

• تطبیق را با عبارت‌های منظم مقایسه کنید

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

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

۸- تست‌های مثبت و منفی ایجاد کنید

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

تست مثبت

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

تست منفی

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

۹- فرایند تست زنده (لایو)

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

• زمان‌بندی تست با دستورات تست داخلی 
• ادغام با ابزارهای مدیریت تست و ابزارهای ردیابی نقص
• ادغام مداوم با ابزارهای مختلف CI پیشرو 
• تولید گزارش‌های لاگ بصری

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

۱۰- تست اتوماسیون API را دست کم نگیرید

جریان تست API با سه مرحله اصلی بسیار ساده است: 

• درخواست را با داده‌های ورودی لازم ارسال کنید. 
• دریافت پاسخ با داده‌های خروجی 
• بررسی اینکه آیا پاسخ، الزامات مورد انتظار را رعایت کرده یا نه

مهم‌ترین بخش تست API، ارسال درخواست یا دریافت پاسخ نیست. این‌ها آزمونی برای مدیریت و تایید داده‌ها هستند. معمول این است که تست شامل چند آزمایش API ابتدایی مانند ورود به سیستم، جستجو در برخی منابع و … ساده باشند. 

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

در زمان‌هایی، شما خود را در میانه انتخاب یک رویکرد خوب برای داده‌های تست و روش‌های تایید خواهید دید. به این دلیل که داده‌های برگشتی ساختار مشابهی دارند، اما در یک پروژه آزمایشی یکسان نیستند. 

علاوه‌براین، در صورتی که کلید داده JSON/XML را با کلید تایید کنید، یا از مپ کردن اشیا برای به‌کارگیری از قدرت زبان برنامه‌نویسی استفاده کنید،  دشوار خواهد بود. 

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