این آموزش عمیق تست API همه چیز را در مورد تست API، خدمات وب و نحوه معرفی تست API در سازمان شما توضیح می دهد:
به همراه تست API بینشی عمیق به دست آورید مفهوم تست shift-left و خدمات وب از این آموزش مقدماتی.
مفاهیمی مانند Web API، نحوه عملکرد API (با مثال در دنیای واقعی) و تفاوت آن با خدمات وب با مثال هایی در این مقاله به خوبی توضیح داده شده است. آموزش
آموزش شماره 2: آموزش خدمات وب: اجزاء، معماری، انواع و amp; مثالها
آموزش شماره 3: 35 پرسش برتر مصاحبه ASP.Net و Web API با پاسخ
آموزش شماره 4: آموزش POSTMAN: تست API استفاده از POSTMAN
آموزش شماره 5: تست خدمات وب با استفاده از سرویس گیرنده Apache HTTP
مروری بر آموزش های این سری تست API
آموزش # | آنچه یاد خواهید گرفت | |||||||||||||||||||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
آموزش_#1: | آموزش تست API : راهنمای کامل برای مبتدیان این آموزش آزمایشی عمیق API همه چیز را در مورد تست API و خدمات وب به طور مفصل توضیح می دهد و همچنین به شما در مورد نحوه معرفی تست API در سازمان خود آموزش می دهد. | |||||||||||||||||||||||||||||||||||||||||||||
Tutorial_#2: | Web Services Tutorial: Components, Architecture, Types & مثالها این وبدرستی پاسخ های API برای پاسخ معتبر و نامعتبر در واقع بسیار مهم است. اگر کد وضعیت 200 (به معنی همه Okay) به عنوان پاسخ از API آزمایشی دریافت شود، اما اگر متن پاسخ بگوید خطایی رخ داده است، این یک نقص است. علاوه بر این، اگر پیام خطا وجود دارد خود نادرست است، پس می تواند برای مشتری نهایی که سعی در ادغام با این API دارد بسیار گمراه کننده باشد. در تصویر زیر، کاربر وزن نامعتبری را وارد کرده است که بیش از 2267 کیلوگرم قابل قبول است. API با کد وضعیت خطا و پیام خطا پاسخ می دهد. با این حال، پیام خطا به اشتباه واحدهای وزن را به جای KG به عنوان پوند ذکر می کند. این نقصی است که میتواند مشتری نهایی را گیج کند. (ii) تست بار و عملکردAPIها با طراحی مقیاس پذیر هستند. این به نوبه خود، تست بار و عملکرد را ضروری می کند، به خصوص اگر انتظار می رود سیستم در حال طراحی بسته به نیاز، هزاران درخواست را در دقیقه یا ساعت انجام دهد. انجام منظم تستهای بارگذاری و عملکرد در API میتواند به ارزیابی عملکرد، بارهای اوج و نقطه شکست کمک کند. این دادهها هنگام برنامهریزی برای افزایش مقیاس یک برنامه مفید است. داشتن این اطلاعات در دسترس به حمایت از تصمیم گیری ها و برنامه ریزی ها کمک می کند، به خصوص اگر سازمان در حال برنامه ریزی برای افزودن مشتریان بیشتر است که به معنای ورودی بیشتر است.درخواستها. نحوه معرفی تست API در سازمان شمافرآیند معرفی تست API در هر سازمانی مشابه فرآیندی است که برای پیادهسازی یا عرضه هر ابزار و چارچوب تست دیگری استفاده میشود. جدول زیر مراحل اصلی را به همراه نتیجه مورد انتظار هر مرحله خلاصه می کند.
چالشهای رایج و راههای کاهش آنهااجازه دهید برخی از چالشهای رایج تیمهای QA را مورد بحث قرار دهیم. هنگام تلاش برای پیادهسازی چارچوب تست API در یک سازمان، مواجه میشوید. #1) انتخاب ابزار مناسبانتخاب ابزار صحیح برای کار رایجترین چالش است. چندین ابزار تست API در بازار موجود است. ممکن است پیادهسازی جدیدترین و گرانترین ابزار موجود در بازار بسیار جذاب به نظر برسد- اما اگر نتایج دلخواه را به همراه نداشته باشد، آن ابزار هیچ فایده ای ندارد. بنابراین، همیشه ابزاری را انتخاب کنید که الزامات "باید" را بر اساس نیازهای سازمانی شما برطرف کند. در اینجا یک نمونه ماتریس ارزیابی ابزار برای ابزارهای API موجود
#2) مشخصات تست وجود نداردبه عنوان آزمایش کننده، ما باید بدانیم نتایج مورد انتظار برای آزمایش موثر یک برنامه این اغلب یک چالش است، زیرا برای دانستن نتایج مورد انتظار، باید الزامات دقیق و واضحی داشته باشیم – که اینطور نیست. برای مثال ، الزامات ارائه شده در زیر را در نظر بگیرید: "برنامه فقط باید تاریخ ارسال معتبری را بپذیرد و همه الزامات نامعتبر باید رد شوند" این الزامات جزئیات کلیدی را ندارند و بسیار مبهم هستند - چگونه یک تاریخ معتبر را تعریف می کنیم؟ در مورد فرمت چطور؟ آیا ما پیام رد را به کاربر نهایی و غیره برمی گردانیم؟ نمونه ای از الزامات پاکسازی: 1) برنامه فقط باید تاریخ ارسال معتبر را بپذیرید. تاریخ ارسال در صورتی معتبر تلقی می شوداست
2) کد وضعیت پاسخ = 200 پیام: OK 3) تاریخ ارسال که معیارهای بالا را ندارد باید نامعتبر تلقی شود. اگر مشتری تاریخ ارسال نامعتبر ارسال کند، باید با پیام(های) خطای زیر پاسخ دهد: 3.1 کد وضعیت پاسخ نه 200 خطا: تاریخ ارسال ارائه شده نامعتبر است. لطفاً مطمئن شوید که تاریخ در قالب DD/MM/YYYY باشد 3.2 کد وضعیت پاسخ 200 نیست خطا: تاریخ ارسال ارائه شده است گذشته #3) منحنی یادگیریهمانطور که قبلاً ذکر شد، رویکرد آزمایش API در مقایسه با رویکردی که هنگام آزمایش برنامه های مبتنی بر رابط کاربری گرافیکی دنبال می شود متفاوت است. اگر شما در حال استخدام متخصصان داخلی یا مشاورانی برای تست API هستند، پس منحنی یادگیری رویکرد تست API یا ابزار تست API ممکن است حداقل باشد. هر منحنی یادگیری، در این مورد، با کسب دانش محصول یا برنامه مرتبط است. اگر یکی از اعضای تیم موجود برای یادگیری تست API اختصاص داده شود، بسته به ابزار انتخابی، منحنی یادگیری ممکن است متوسط به بالا، همراه با تغییر روش آزمون. منحنی یادگیری برای خود محصول یا برنامه ممکن است بسته به اینکه آیا این تستر آزمایش کرده است یا نه متوسط باشدآن برنامه قبل یا نه. #4) مجموعه مهارت های موجوداین به طور مستقیم با نکته قبلی در مورد منحنی یادگیری مرتبط است. اگر آزمایش کننده در حال انتقال از تست مبتنی بر رابط کاربری گرافیکی، سپس تستر باید رویکرد تست را تغییر دهد و ابزار یا چارچوب جدید را در صورت نیاز یاد بگیرد. به عنوان مثال اگر API درخواستها را در قالب JSON بپذیرد، آزمایشکننده باید بداند JSON چیست تا بتواند آزمایشها را ایجاد کند. مطالعه موردیTask به منظور افزایش مقیاس یک برنامه موجود، یک شرکت می خواست محصولی را در API و همچنین یک برنامه رابط کاربری گرافیکی استاندارد ارائه دهد. از تیم QA خواسته شد تا یک طرح پوشش آزمایشی ارائه دهند تا اطمینان حاصل شود که آنها آماده پذیرش آزمایش API فراتر از آزمایشهای معمول مبتنی بر رابط کاربری گرافیکی هستند. چالشها
رویکردی که تیم برای کاهش خطرات و کار در اطراف چالش ها دنبال می کند
نتیجهبرنامه های مبتنی بر API در چند وقت اخیر محبوبیت پیدا کرده است. این برنامه ها بیشتر هستندمقیاسپذیر در مقایسه با برنامهها/نرمافزارهای سنتی و امکان ادغام آسانتر با سایر APIها یا برنامهها را فراهم میکند. این آموزش تست API همه چیز را در مورد تست API، تست Shift Left، خدمات وب، و Web API به تفصیل توضیح میدهد. ما همچنین تفاوتهای بین Web Services و Web API را با مثالهایی بررسی کردیم. در قسمت دوم آموزش، طیف کاملی از تست API، نحوه معرفی تست API در سازمان و برخی از چالشهای رایج در آن را مورد بحث قرار دادیم. این فرآیند همراه با راه حل هایی برای آنهاست. آموزش آینده ما را برای دانستن بیشتر در مورد خدمات وب همراه با مثال ها بررسی کنید!! آموزش بعدی آموزش خدمات معماری، انواع و amp; اجزای خدمات وب همراه با اصطلاحات مهم و تفاوت بین SOAP در مقابل REST 35 سوال برتر مصاحبه ASP.Net و Web API با پاسخشما می توانید لیستی از پرطرفدارترین سوالات مصاحبه ASP.Net و Web API را با پاسخ بررسی کنید & نمونه هایی برای مبتدیان و متخصصان با تجربه در این آموزش. | |||||||||||||||||||||||||||||||||||||||||||||
Tutorial_4: | POSTMAN Tutorial: API Testing Using POSTMAN این آموزش گام به گام تست API با استفاده از POSTMAN را به همراه اصول اولیه POSTMAN، اجزای آن و درخواست نمونه و amp; برای درک آسان شما به زبان ساده پاسخ دهید. | |||||||||||||||||||||||||||||||||||||||||||||
آموزش_5: | تست خدمات وب با استفاده از سرویس گیرنده Apache HTTP این آموزش API در مورد انجام عملیات های مختلف CRUD در سرویس های وب و آزمایش سرویس های وب با استفاده از Apache HTTP Client است |
آموزش تست API
این بخش به شما کمک می کند تا درک اولیه ای از Web Services و Web API بدست آورید، که به نوبه خود در درک مفاهیم اصلی در آموزش های آینده در این سری تست API مفید خواهد بود.
API ( Application Programming Interface) مجموعه ای از تمام رویه ها و توابع است که به ما امکان می دهد با دسترسی به داده ها یا ویژگی های برنامه یک برنامه کاربردی ایجاد کنیم.سیستم عامل یا پلتفرم ها تست چنین رویه هایی به نام تست API شناخته می شود.
تست Shift Left
یکی از انواع مهم تستی که امروزه در مصاحبه های تست API مطرح می شود، تست Shift Left است. این نوع تست تقریباً در تمام پروژههایی که از متدولوژی چابک پیروی میکنند، انجام میشود.
قبل از معرفی Shift Left Testing، تست نرمافزار تنها پس از تکمیل کدنویسی و تحویل کد به آزمایشکنندگان مطرح شد. این عمل منجر به شلوغی لحظه آخری برای رسیدن به مهلت مقرر شد و همچنین کیفیت محصول را تا حد زیادی با مشکل مواجه کرد.
علاوه بر آن، تلاش های انجام شده (زمانی که ایرادات در آخرین مرحله قبل از تولید گزارش شد) انجام شد. بسیار بزرگ است زیرا توسعه دهندگان باید هر دو مرحله طراحی و کدنویسی را دوباره پشت سر بگذارند.
چرخه حیات توسعه نرم افزار (SDLC) قبل از آزمایش Shift Left
جریان سنتی SDLC این بود: الزامات - > طراحی –> کدگذاری –> تست کردن.
معایب تست سنتی
- آزمایش در سمت راست است. زمانی که یک باگ در آخرین لحظه شناسایی میشود، هزینههای زیادی متحمل میشود.
- زمان صرف شده برای رفع اشکال و آزمایش مجدد آن قبل از ارتقاء آن به تولید بسیار زیاد است.
از این رو، یک ایده جدید برای انتقال مرحله آزمایش به چپ ظاهر شد که در نتیجه به تست Shift Left منجر شد.
خواندن پیشنهادی => تست Shift Left: Aمانترای مخفی برای موفقیت نرم افزار
مراحل تست شیفت چپ
تست شیفت چپ منجر به انتقال موفقیت آمیز از تشخیص نقص به پیشگیری از نقص شد. همچنین به نرمافزار کمک کرد تا سریع از کار بیفتد و تمام خرابیها را در اولین فرصت برطرف کند.
Web API
بهطور کلی، Web API را میتوان به عنوان چیزی تعریف کرد که درخواست را از یک کلاینت میگیرد. سیستم را به یک وب سرور می فرستد و پاسخ را از یک وب سرور به یک ماشین مشتری ارسال می کند.
API چگونه کار می کند؟
وقتی برای رزرو پرواز میروید، اطلاعاتی مانند تاریخ سفر/تاریخ بازگشت، کلاس و غیره را وارد میکنید و روی جستجو کلیک میکنید.با این کار قیمت خطوط هوایی متعدد و در دسترس بودن آنها به شما نشان داده میشود. در این مورد، برنامه با API های خطوط هوایی متعدد تعامل می کند و در نتیجه به داده های خطوط هوایی دسترسی می دهد.
مثال دیگر www.trivago.com است که قیمت، در دسترس بودن و غیره هتل های مختلف را مقایسه و فهرست می کند. از یک شهر خاص این وب سایت با API های چندین هتل برای دسترسی به پایگاه داده ارتباط برقرار می کند و قیمت ها و در دسترس بودن را از وب سایت آنها فهرست می کند.
بنابراین، Web API را می توان به عنوان "واسطی که ارتباط بین ماشین مشتری و مشتری را تسهیل می کند" تعریف کرد. راوب سرور".
خدمات وب
خدمات وب (مانند Web API) خدماتی هستند که از یک ماشین به ماشین دیگر خدمت می کنند. اما تفاوت عمده ای که بین API و وب سرویس ها ایجاد می شود این است که وب سرویس ها از یک شبکه استفاده می کنند.
به جرات می توان گفت که همه سرویس های وب Web API هستند اما همه API های وب سرویس های وب نیستند (توضیح داده شده در بخش آخر مقاله). بنابراین، خدمات وب زیر مجموعه ای از Web API هستند. برای اطلاعات بیشتر در مورد Web API و Web Services به نمودار زیر مراجعه کنید.
Web API در مقابل خدمات وب
Web Services vs Web API
هر دو Web API و Web Services برای تسهیل ارتباط بین مشتری و سرور استفاده می شوند. تفاوت عمده فقط در نحوه برقراری ارتباط آنها است.
هر یک از آنها به یک بدنه درخواستی نیاز دارند که در یک زبان خاص قابل قبول باشد، تفاوت آنها در ارائه یک اتصال امن، سرعت برقراری ارتباط با سرور و پاسخ دادن به آنها. به مشتری و غیره.
تفاوتهای بین سرویسهای وب و Web API برای مرجع شما در زیر فهرست شده است.
Web Service
- سرویسهای وب معمولاً از XML (زبان نشانهگذاری توسعهیافته) استفاده میکنند، به این معنی که امنتر هستند.
- خدمات وب امنتر هستند زیرا هم سرویسهای وب و هم APIها SSL (لایه سوکت امن) را در طول انتقال داده ارائه میکنند. ، اما WSS (امنیت خدمات وب) را نیز فراهم می کند.
- وب سرویس زیرمجموعه ای از Web API است. به عنوان مثال، خدمات وب فقط بر اساس سه سبک استفاده است، یعنی SOAP، REST و XML-RPC.
- خدمات وب همیشه برای کار کردن به یک شبکه نیاز دارند.
- خدمات وب از "برنامه های مختلف یک کد" پشتیبانی می کنند. این بدان معناست که یک کد عمومیتر در برنامههای مختلف نوشته میشود.
Web API
- یک API وب معمولاً از JSON (نمادگذاری شی جاوا اسکریپت) استفاده میکند. این بدان معناست که Web API سریعتر است.
- Web API سریعتر است زیرا JSON بر خلاف XML سبک وزن است.
- Web APIها ابرمجموعه خدمات وب هستند. به عنوان مثال، هر سه سبک وب سرویس ها در Web API نیز وجود دارند، اما جدای از آن، از سبک های دیگری مانند JSON – RPC استفاده می کند.
- Web API لزوماً نیازی ندارد یک شبکه برای کار کردن.
- Web API ممکن است بسته به ماهیت سیستم یا برنامه از قابلیت همکاری پشتیبانی کند یا نه.
معرفی تست API در سازمان شما
در زندگی روزمره، همه ما به تعامل با برنامهها با API عادت کردهایم و با این حال، حتی به فرآیندهای پشتیبان که عملکرد زیربنایی را هدایت میکنند، فکر نمیکنیم.
برای مثال. ، اجازه دهید در نظر بگیریم که شما در حال مرور محصولات در Amazon.com هستید و محصول/معامله ای را می بینید که واقعاً آن را دوست دارید و می خواهید آن را با شبکه فیس بوک خود به اشتراک بگذارید.
لحظه ای که کلیک می کنید روی نماد فیس بوک در قسمت اشتراک گذاری صفحه و وارد کنیداعتبار حساب فیس بوک برای اشتراک گذاری، شما در حال تعامل با یک API هستید که به طور یکپارچه وب سایت آمازون را به فیس بوک متصل می کند.
تمرکز بر روی تست API
قبل از بحث بیشتر در مورد آزمایش API، بیایید دلایل را مورد بحث قرار دهیم. که برای آنها برنامه های کاربردی مبتنی بر API در زمان های اخیر محبوبیت پیدا کرده اند.
چندین دلیل وجود دارد که سازمان ها در حال انتقال به محصولات و برنامه های مبتنی بر API هستند. و تعداد کمی از آنها در زیر برای مرجع شما فهرست شده اند.
#1) برنامه های کاربردی مبتنی بر API در مقایسه با برنامه ها/نرم افزارهای سنتی مقیاس پذیرتر هستند. سرعت توسعه کد سریعتر است و همان API میتواند درخواستهای بیشتری را بدون هیچ کد اصلی یا تغییرات زیرساختی ارائه دهد.
#2) تیمهای توسعه نیازی به شروع کدنویسی از ابتدا ندارند. زمانی که آنها شروع به کار روی توسعه یک ویژگی یا برنامه می کنند. APIها اغلب از توابع موجود، قابل تکرار، کتابخانهها، رویههای ذخیرهشده و غیره استفاده مجدد میکنند و از این رو این فرآیند میتواند آنها را در مجموع سازندهتر کند.
به عنوان مثال، اگر شما یک توسعهدهنده هستید که روی یک وب سایت تجارت الکترونیکی و می خواهید آمازون را به عنوان یک پردازشگر پرداخت اضافه کنید - پس لازم نیست کد را از ابتدا بنویسید.
تنها کاری که باید انجام دهید این است که با استفاده از API وب سایت خود و آمازون یکپارچه سازی کنید. کلیدهای یکپارچه سازی و تماس با API آمازون برای پردازش پرداخت ها در حین پرداخت.
#3) API ها اجازه می دهندادغام آسان با سیستم های دیگر هم برای برنامه های کاربردی مستقل پشتیبانی شده و هم با محصولات نرم افزاری مبتنی بر API.
به عنوان مثال ، اجازه دهید در نظر بگیریم که می خواهید یک محموله از تورنتو به نیویورک ارسال کنید. . آنلاین میشوید، به یک وبسایت باربری یا لجستیکی میروید و اطلاعات مورد نیاز را وارد میکنید.
پس از ارائه اطلاعات اجباری، وقتی روی دکمه دریافت نرخها کلیک میکنید - در انتهای صفحه، این وبسایت تدارکات ممکن است در حال اتصال باشد. با چندین API و برنامههای کاربردی شرکتکننده و ارائهدهنده خدمات برای دریافت نرخهای پویا برای ترکیب مبدا تا مقصد مکانها.
طیف کامل تست API
تست APIها به ارسال درخواست محدود نمیشود. به API و تجزیه و تحلیل پاسخ برای صحت به تنهایی. APIها باید برای عملکردشان تحت بارهای مختلف برای آسیبپذیریها آزمایش شوند.
بیایید در مورد این موضوع با جزئیات بحث کنیم.
(i) تست عملکردی
تست عملکردی به دلیل عدم وجود رابط کاربری گرافیکی می تواند یک کار چالش برانگیز باشد.
بیایید ببینیم که چگونه رویکرد تست عملکردی برای APIها با برنامه مبتنی بر رابط کاربری گرافیکی متفاوت است و همچنین چند نمونه در مورد آن را مورد بحث قرار خواهیم داد.
a) واضح ترین تفاوت این است که هیچ رابط کاربری گرافیکی برای تعامل وجود ندارد. آزمایشکنندگانی که معمولاً آزمایشهای عملکردی مبتنی بر رابط کاربری گرافیکی را انجام میدهند، انتقال به آزمایش برنامه کاربردی غیر GUI در مقایسه بافردی که قبلاً با آن آشنایی دارد.
در ابتدا، حتی قبل از شروع آزمایش API، باید خود فرآیند احراز هویت را آزمایش و تأیید کنید. روش احراز هویت از یک API به API دیگر متفاوت است و شامل نوعی کلید یا نشانه برای احراز هویت میشود.
اگر نمیتوانید با موفقیت به API متصل شوید، آزمایش بعدی نمیتواند ادامه یابد. این فرآیند را میتوان با احراز هویت کاربر در برنامههای استاندارد که برای ورود به برنامه و استفاده از آن به اعتبارنامههای معتبر نیاز دارید، مقایسه کرد. در طول تست API ها اگر یک رابط واقعی مبتنی بر فرم (GUI) در دسترس بود، میتوان اعتبارسنجی فیلد را در قسمت جلویی یا پشتی اجرا کرد، در نتیجه اطمینان حاصل شد که کاربر مجاز به وارد کردن مقادیر فیلد نامعتبر نیست.
به عنوان مثال، اگر یک برنامه نیاز به فرمت تاریخ دارد که DD/MM/YYYY باشد، میتوانیم این اعتبار را در فرم جمعآوری اطلاعات اعمال کنیم تا اطمینان حاصل کنیم که برنامه در حال دریافت و پردازش یک تاریخ معتبر است.
با این حال، این برای برنامه های API یکسان نیست. ما باید اطمینان حاصل کنیم که API به خوبی نوشته شده است و می تواند تمام این اعتبارسنجی ها را اعمال کند، بین داده های معتبر و نامعتبر تمایز قائل شود و کد وضعیت و پیام خطای اعتبارسنجی را از طریق یک پاسخ به کاربر نهایی بازگرداند.
ج) تست کردن