ارزش API Testing: مصاحبه‌ای با هیو پرایس+فیلم

نوشته های مرتبط

یک استراتژی کیفی برای اپلیکیشن موبایل ایجاد کنید: مصاحبه‌ای با جِیسون آربون+فیلم

دی ۱۷, ۱۳۹۵

تست با رویکرد DevOps برای سیستم‌های Embedded و اینترنت اشیاء+فیلم

دی ۷, ۱۳۹۵

API Testing

– خبرنگار: ما با یک مصاحبه مجازی دیگه ازSTARWEST برگشتیم. با تشکر برای تنظیم این مصاحبه مجازی. من در اینجا با هیو هستم. هیو متشکریم که به ما پیوستی.

– پرایس: از اینکه اینجا هستم خوشحالم.

– خبرنگار: … امروز. شاید افرادی که خارج از جمع ما هستن، شما رو نشناسن. [به همین دلیل] اطلاعات کوتاهی از پس زمینه خودت ارائه بده، طوریکه دیگران از زمینه چیزی که می‌خوایم امروز درمورد اون صحبت کنیم و اینکه از کجا اومدی، مطلع بشن.

– پرایس: من مدیرعامل و همچنین بنیانگذار Grid Tools هستم، که به صورت تخصصی به حوزه Test Data می‌پردازه. فکر می‌کنم ما خیلی خوب بازار مدیریت داده‌های تست(Test Data Management) رو ایجاد کردیم. باید بگم ما در خط مقدم تفکر جدید در حوزه Test Data هستیم. به عنوان بخشی از این موضوع، ما به طراحی نوع درستی از Test Data برای تستِ سیستم‌ها وارد شدیم.

در حال حاضر، این یک موضوع بسیار علمیه، و ما رو به سمت دنیای مدلسازی هدایت می‌کنه، بطوریکه من باید یک تبدیل داده‌ایِ(Data Transform) خاص رو تست کنم. بنابراین الزام دارم چیزی رو مدل کنم که Transform هست. من باید این داده رو به شکلی ایجاد کنم، که بتونیم به سمت چیزیکه اون رو مدلسازی علت و معلول(Cause-Effect Modelling) می‌نامیم حرکت کنیم. مدلسازی علت و معلول برای یک مدت طولانی مورد استفاده بوده. از این[تکنیک] برای تست الکترونیک، تست‌های نظامی، و مواردی شبیه به موارد مذکور استفاده می‌شده.

در حال حاضر، مشکل اینه که در واقع استفاده از مدلسازی علت و معلول برای افراد بسیار سخته. [برای این کار] شما باید با عباراتی مثل X-Or و X-Nor و مواردی از این دست آشنا باشید.

– خبرنگار: ممکنه بعضی افراد این[دردسر] رو از سر باز کنن…

– پرایس: دقیقا…

– خبرنگار: … که با اون آشنا نیستن.

– پرایس: بنابراین کاری که من انجام دادم این بود که با مشتریان مورد علاقم که عاشق محصولات ما بودن بیرون رفتم و گفتم: “از این استفاده کنید، شما باید مدلسازی کنید.”، و همه اونها گفتند: “هیوِ بزرگ، این خیلی سخته”. شبیه به اینکه “اوه مرد، بی خیال مرد”. این مزایا خیلی زیاده…

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

– پرایس: اونا می‌خواستن ازش استفاده کنن.

– خبرنگار: آره، اما دچار این مانع بودن که: “مطمئن نیستم چه اتفاقی میفته.”

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

– خبرنگار: اوه، خیلی.

– پرایس: اگر شما به اکثر تیم‌های اسپرینت نگاه کنید، یک فلوچارت روی بورد می‌بینید. و این برای برقراری ارتباط ایده‌ها و اطلاعات، روش خوبیه. به همین خاطر ما فکر کردیم که اون رو شبیه فلوچارت بسازیم. اما مباحث سخت ریاضی رو پشت اون مخفی کردیم، طوریکه Agile Designer یا کسیکه به عنوان Agile Requirement Designer شناخته می‌شه از اون بیرون بیاد. این روش به شما اجازه می‌ده تا اون چیزی رو که قراره سیستم انجام بده، مدل کنید. بعد از اون ما می‌تونیم مجموعه‌ای کوچکتر از Test Caseها رو برای تستِ هر Node یا Logic Gate ایجاد کنیم. همونطور که این کار رو دستی انجام می‌دید.

به عبارت دیگه، کمی شبیه به بازی کامپیوتری شطرنج هست. شما می‌تونید به مدت نیم ساعت اینجا بشینید و یک حرکت انجام بدید، و یا می‌تونید روی یک تخته شطرنج برنامه‌ریزی کنید تا کامپیوتر اون رو برای شما در صفر ثانیه انجام بده. بنابراین ما یک ابزار بسیار قوی Test Case Optimizer درست کردیم که برای شما یک مجموعه بسیار کوچک از Test Case رو می‌سازه. اما گارانتی می‌کنه که تمام Functionalityها تست بشن. این نوع حرکت در مسیره که منجر به API Testing شد، که بدیهیه که یکی از موضوعات داغ حال حاضره.

– خبرنگار: بله، کاملا. حالا روی بخش‌بندی ابزار، انواع Making Toolها، همونطور که ما این هفته شنیدیم[، صحبت کنیم]. من با افراد زیادی مصاحبه کردم و اونها می‌گفتند: ابزارهای زیادی وجود دارن، نسل اول، نسل دوم، و همینطور ابزارهایی که افراد استفاده می‌کنن، بیشتر برای افراد فنی و یا حرفه‌ای طراحی شدن.

– پرایس: بله، دقیقا.

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

– پرایس: این، جاییه که همه در موردش حرف می‌زنن. جاناتن رایت(Jonathon Wright)[یکی از بازیکنان راگبی] درباره طراحی کردن ops صحبت می‌کنه. اساسا ops یعنی نشست و برخاست با کاربر، یا حتی کاربری که خود به خود کار رو انجام می‌ده، و بعدش می‌گه این سیستمیه که من می‌خواستم. بعدش IT میگه، اوه، بسیارخوب، خوبه. کاری که شما انجام می‌دید سرهم کردن و اصطلاحا اسمبل کردن ایده‌ها، اصلاحات Businessای، Business Objectها، Business Processها، و اسمبل کردن اونها در چیزیه که قصد داره به سرعت وارد بازار بشه و علاوه بر این می‌خواد که بسیار باکیفیت باشه. این همون جایی که بازار حضور داره. دیگه هزینه خیلی مهم نیست. اگر شما نتونید وارد بازار شید، از Business خارج هستید. و این چیزیه که Business رو به پیش می‌بره. به همین خاطر در حال حاضر این یک برهه هیجان‌آوره.

– خبرنگار: همینطوره. این چیزیه که من در این هفته خیلی راجع بهش فکر کردم. شنیدنِ برخی از تحولاتی که روی ابزارها رخ داده، دقیقا همون چیزیه که شما می‌گید، که چیزی رو به ارمغان میاره که به اونها کمک می‌کنه تا به زبانی صحبت کنن که اونها بفهمن. و اون فلوچارته. اونها چنین چیزی رو به دست میارن، که تکنیک علت و معلول رو دسترس‌پذیرتر می‌کنه. [فلوچارت] می‌تونه مسائل دشوار رو پنهان کنه. [بنابراین تکنیک علت و معلول] هنوز هم وجود داره اما حالا برای بیشتر افراد دسترس‌پذیره.

– پرایس: این یه جور دورنماست. حالا بعد از این، یکی از چیزهای کلیدی‌ای که سرعت رو متاثر می‌کنه کار کردنِ موازیِ افراده. البته راهکارش ایده “تسمه نقاله‌ای” هست، که من ازش متنفرم. من واقعا فکر می‌کنم که امروزه، اگر شما به واژه Agile نگاه کنید، اون رو به معنی همکاری می‌بینین. شما در تیم من هستید، ممکن شما مدل درست کنید، و یا برخی از تست‌ها رو انجام بدید، و یا برخی از تغییرات اتومات رو اجرا کنید، حتی ممکن کد بنویسید. من ممکنه کد بنویسم. هیچکدوم مهم نیست. اما اگر هممون به صورت موازی کار کنیم، اونوقت در پایان دوره زمانی، که می‌تونه Sprint و یا Waterfall باشه، ما واقعا کدی درست کردیم که کار می‌کنه. و من فکر می‌کنم این چیزیه که ما قادر به انجامش هستیم.

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

– خبرنگار: درسته، چرا که ما می‌بینیم Open APIها خیلی مهم هستن. متصل کردن تعداد زیادی از اشیاء مختلف. و نه حتی دونستن همه چیزهایی که شما باید به صورت بالقوه به اون متصل بشید.

– پرایس: بله. اما خوبه شما یه سر برید و ببینید FaceBook API چی می‌گه. به نظر می‌رسه که اون خیلی سادست، و شما به سادگی می‌تونید بهش متصل بشید. چیزی که در مورد FaceBook API هست، اینه که اونها فروشنده غالب هستن، و می‌تونن کاربران رو اجبار کنن. اونها فقط سه نسخه از این API رو پشتیبانی می‌کنن. اگر شما به این سه نسخه ارتقا پیدا نکنید، کارتون تمومه. خوب؟ اونها غالب هستن، بنابراین چیزی که ما فهمیدیم اینه که Version Compatibility یک مشکل بزرگه. بنابراین قبل از اینکه حتی شما با API خودتون شروع به کار کنید، باید در مورد اینکه چطور مدیریت نسخه API رو بسازید، فکر کنید. مشکل اینه که یک API می‌تونه بوسیله یک Rest Call فراخوانی بشه، میتونه بوسیله یک Sub Call هم فراخوانی بشه، و می‌توانه بوسیله API دیگه‌ای هم فراخوانی بشه.

حالا اگر شما این وابستگی‌ها رو تراک کنید، مسلما هیچ نظری نخواهید داشت. و زمانیکه تستتون رو برای انجام اون می‌سازید، باید درباره نیازمندی Non-Function که همون مدیریت نسخه هست، فکر کنید. من تصادفا نسخه دو را در نسخه چهار فراخوانی کردم. فکر کن چی شد؟ خیلی آرام Fail شد؟ آیا من Version Compatibility رو تشخیص دادم و گفتم “اوه، ببخشید”، یا اینکه فقط این کار رو کردم و شما تا پایان با هرج و مرج مواجه بودید. بنابراین شما با محدوده بزرگی طرف هستین. یک چیز دیگه درباره APIها اینه که افراد فکر می‌کنن، “اوه، عالیه، من این[دکمه] رو فشار می‌دم، و اون همه کارها رو انجام می‌ده”. مشکلی که هست اینه که API دیگه‌ای، برای انجام کارهایی که مربوط به API اول هست وجود داره.

– خبرنگار: بله ارتباط تنگاتنگ همه اونها.

– پرایس: کاملا. بنابراین شما ممکنه با چیزی کار رو پایان بدید، شبیه اینکه من می‌خوام یک API داشته باشم تا مشتری‌هام رو Create کنم. بنابراین من باید یک API برای Create کردن سفارشات داشته باشم. و همینطور باید یک API برای ایجاد iTunes داشته باشم. این شگفت‌آوره. مشتری میاد، Create میشه. سفارش میاد، iTunes ناتوان می‌مونه و Fail میشه. حالا من باید چی کار کنم؟ با این وضع، من مشکل دیگه‌ای که در تست دارم اینه که من باید نارسایی‌ها(Failure) رو هم تست کنم. بنابراین من باید تست کنم که پشت سیستم هم کار می‌کنه. اتفاقا در دوران قدیمِ Main Frameها، شما یک چیز فوق‌العاده به نام Roll Back داشتید. شما فقط پیش می‌رفتید، و اون Fail می‌شد.

– خبرنگار: Revert back(برگرداندن).

– پرایس: اجازه بدید من همه رو برگردونم. به اونها یک Message ارسال می‌کرد، و می‌گفت: “دوباره بعدا سعی کنید”.

– خبرنگار: بله. با عرض پوزش در مورد آن.

– پرایس: بله. دقیقا. و این خوبه. با این روش شما یک کار آرامش بخش منطقی دارید. حالا مشکل اینه که شما یک مرتبه با پیچیدگی API، یک کار آرامش بخش منطقی، واقعا برای انجام سخت میشه. بنابراین وقتی طراحی می‌کنید، افراد مختلف می‌گن: “اوه، ما فقط برنامه‌ها رو به کار تبدیل می‌کنیم و بعدش اونها رو به یک میکروسرویس تبدیل می‌کنیم”. منم یه چیزی مثل این می‌گم: “صبر کن. نه نه. نه نه نه نه”. شما باید روش رو به صورت بنیادی تغییر بدید… شما باید دقیقا چیزی رو مدل کنید که این API قصد انجام اونها رو داره. شما باید Roll Backها رو مدل کنید، و بعدش شما کاری رو انجام می‌دید که می‌تونید و بعد این Test Caseها رو به صورت اتوماتیک می‌سازید. علاوه بر این شما Build کردن در این مدل رو، بر اساس یک Logical Unit از کار با ارتباط متقابل اونها، مرتب می‌کنید.

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

اینها بیست API عالیِ من هستند، که می‌دونم خیلی باثبات هستن. گاهی اوقات که یک Functionality جدید معرفی می‌شه ممکنه من برخی Taskهای تکمیلی رو اضافه کنم. این خوبه. به طوریکه یکی از راه‌هاییه که مطمئن بشید اون API چیزی رو انجام می‌ده که باید انجام بده. معکوس اینم هست و اون اینه که کسی می‌خواد در مقابل API من تست کنه. ما براتون Create خواهیم کرد(چون ما مدل رو داریم)، ما برای شما یک نسخه مجازی از API می‌سازیم. پس ما می‌گیم خیلی خوب، اگر شما مثلا به سابقه اعتباری نگاه کنید، می‌بینید که من می‌خواستم به Dun and Bradstreet وصل بشم و سابقه اعتباریم رو بدست بیارم. این برمی‌گرده به یک ساختار XMLای و این اطلاعات رو خواهد داشت: اسم شما، آدرس شما، کی با شما ازدواج کرده، و کی از شما طلاق گرفته. حالا شما یک تغییر اسم داشتید. شما یک اعتبار پیشفرض داشتید. هفده بار هم نقل مکان کردید. ورشکسته هم شدید. تمام این چیزا مشخصات واقعیِ پاسخ از سمت API هست. اگر من بخوام تست کنم که اپلیکیشن من در مقابل API کار می‌کنه، فقط اسمم رو تایپ می‌کنم، و جوابی می‌گیرم و می‌گم ” اون کار کرد”. یک تست. چیزی که شما واقعا بهش نیاز دارید تا دربارش فکر کنید، چیزیه که به من ارائه شده…

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

در حال حاضر اگر شما در مورد APIها فکر می‌کنید، چیزی که باید در موردش اندیشه کنید، پلاگین‌هایی هستند که کار می‌کنند. برگردیم به مسائل اصلیِ کار برای زمانیکه درباره User و Business User، صحبت می‌کنید و اونهایی که فقط می‌خوان این چیزها رو اَسِمبِل کنند. باشه؟ حالا اگر اونها چیزهایی رو اسمبل می‌کنند که قبلا هرگز به این روش اسمبل نشده، اون باید کار کنه. اگر شما این پلاگ‌ها رو برای اینکه استاندارد بالایی رو کسب کنه نمی‌سازید، اون شروع می‌کنه به سقوط کردن و از هم پاشیدن. من فکر می‌کنم اینجا جاییکه شما باید خیلی جدی درباره ایجاد استراتژی‌های API خودتون فکر کنید. مدیریت نسخه هم در اینجاست. در واقع شما در اینجا وارد معیارهای ثبات شدید.

– خبرنگار: درسته. در این مورد که اونها بالا هستند، و این که شما چطور می‌تونید مطمئن بشید. درسته؟ چون شما ممکنه ثبات داشته باشید، اما اگر به افرادی Connect بشید که فاقد مدیریت نسخه و چیزهای دیگه هستند، ممکنه در این نقطه اون رو از دست بدید.

– پرایس: تنها یک چیزی نهایی شده، مسائل دیگه‌ای هم مثل Performance وجود داره. آمارهای بسیاری در این مورد وجود داره که اگر شما وارد یک اپلیکیشن بشید، و اون کار نکنه، اونوقت شما خیلی سریع از اون خارج می‌شید. شما چطور باید تست کنید، وقتی که من به سرور اصلیِ Starbucks متصل می‌شم، و اون طرف دو ثانیه به من جواب نمی‌ده. بنابراین مجبورم به سراغ سرور بعدی و بعدی برم و یا ممکنه یک Cash دریافت کنم. بنابراین اگر من اون رو تست نکنم که کدوم واقعا یک نیازمندی Functional بر اساس یک امکان Non-Functional هست، مشکل دار می‌شم. این چیزیه که شما باید اون رو گواهی کنید.

– خبرنگار: خوب. من فکر می‌کنم برای شما این مهمه که بدونید شما با این چیزهایی که ذکر کردید در کجای زنجیره غذایی قرار می‌گیرید. از نظر فیسبوک اگر آنها غالب هستند، بنابراین شما در این زنجیره غذایی مغلوب هستید. پس وقتی چیزی به سمت اشتباه می‌ره، فهمیدن اینکه کجا این موضوع مشخص شده، می‌تونه باعث بشه که شما یک Failure رو تشخیص بدید. به عنوان نمونه Netflix. اگر Netflix سقوط کنه اما آمازون پشت اون ماجرا باشه، کسی اهمیت نمی‌ده. چون نتفلیکس سقوط کرده نه آمازون. بنابراین شما به عنوان یک مشتری باید از آنچه اطراف سازمان شماست آگاه باشید. Failureهای بالقوه رو شما نمی‌تونید به صورت مستقیم کنترل کنید، اما باید به صورت غیرمستقیم از اونها آگاه باشید.

– پرایس: چیز دیگه‌ای که در این باره هست سرعته. اگر شما بتونید Failureها رو خیلی زود در چرخه توسعه یکپارچه‌سازی مداوم(Continuous Integration Development Cycle) تشخیص بدید، اونوقت امیدی برای رفع اونها وجود داره. چیزی که شما نمی‌تونید انجام بدید اینه که بگید: “اوه ما یک Failure داریم” و بعد از طریق Logها و چیزهایی شبیه به این بخواید اون رو یاد بگیرید. شما باید واقعا تمام موارد وظیفه‌ایتون رو آماده داشته باشید تا قادر باشید Failureها رو شناسایی کنید.

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

– پرایس: خب لینکدین. Huw Price که H-U-W هست. شاید دسترسی به من روی لینکدین ساده‌تر باشه. اگر شما قصد دارید یک تستر حرفه‌ای باشید، فکر می‌کنم درماه ژوئن آخرین ویرایش از مقاله من که که پژوهش جامعی در زمینه API Testing هست رو صرفا با انجام یک جستجو ساده می‌تونید به دست بیارید، که البته کمی بیشتر از مواردی که امروز در موردش اینجا صحبت کردیم رو پوشش می‌ده. اما به نظرم نقطه خوبی برای شروع هست.

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

– پرایس: از این جلسه لذت بردم. خیلی ازتون متشکرم.