هرم تست (Test Pyramid)

برای خودکارسازی تست نرم‌افزار می‌توان انواع متفاوتی از تست‌ را به کار گرفت. از تست‌های سطح پایین که برای تست قطعه کدهای نرم‌افزار نوشته می‌شوند، (Unit Test)؛ تا تست‌هایی سطح بالا که از واسط کاربری شروع می‌شوند و تست را به شکلی اجرا می‌کنند که گویا یک کاربر واقعی در حال کار با سیستم است. (End-To-End Test).

اما سوال کلیدی این است که وقت گذاشتن برای کدامیک از این انواع تست، نتیجه‌ی بهتری را عاید ما می‌کند؟ «هرم تست» پاسخی برای همین پرسش است.

همانطور که در شکل پیداست، بهتر این است که حجم تست‌های واحد (Unit Test) بسیار بیشتر از تست‌هایی باشد که از سطح UI اجرا می‌شوند.

تست‌های UI یا End-To-End Test

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

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

نکته دیگری که در مورد تستهای UI باید مورد توجه قرار داد این است که اجرای این تست‌ها معمولا تا رسیدن به یک Build موفق از سیستم به تاخیر می‌افتند و گاهی اوقات توسعه دهندگان برای اطمینان از عملکرد یک کد جدید باید منتظر بمانند تا دیگر اعضای تیم، کارشان را تا حد مناسبی پیش برده باشند. در این شرایط، رایج است که توسعه دهنده Back-End منتظر توسعه دهنده Front-End می‌ماند تا واسط کاربری پیاده‌سازی شود و پس از آن تست های UI اجرا شوند.

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

ببینیم در مورد تستهای واحد (Unit Test) وضعیت چطور است.

تستهای واحد (Unit Test)

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

تست‌های واحد، فیدبک سریعتری به توسعه دهنده می‌دهند. توسعه‌دهنده در کمتر از چندثانیه متوجه می‌شود که کد یا تغییرات جدید درست کار می‌کند یا نه.

نگهداری تست‌های واحد مشروط بر اینکه با رعایت بِه‌رَوشها نوشته شده باشند بسیار راحت‌تر است. اصلی‌ترین علت تغییر در اسکریپت‌های تست واحد زمانی است که کلاس یا کلاسهای مورد تست (Class Under Test) تغییر کنند. معمولا دامنه این تغییرات مربوط به چند کلاس محدود خواهد شد. این را مقایسه کنید با تست UI که حتی تغییر مکان یا نام یک Button می‌تواند کل سناریوی تست را بشکند.

مزیت دیگر تست واحد این است که در صورت شکست تست، تشخیص علت شکست به صورت دقیق و واضح امکان پذیر است. توسعه دهنده به راحتی می‌فهمد که کلاس یا متد خاصی (از بین هزاران کلاس یا متد) درست کار نمی‌کند و به همین دلیل، کمتر درگیر عملیات Debug خواهد شد.

 

جمع‌بندی:

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

 

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

https://evand.com/events/softwaretesting-2nd

تست خودکار نرم‌افزار؛ از آغاز تا انجام

🔸اپیزود اول:

وقتی مشتری درخواست جدیدی می‌دهد، دست و دل ما می‌لرزد که نکند انجام این تغییرات، به جاهای دیگر سیستم هم گند بزند! چون سیستم بزرگ و پیچیده‌ای داریم، می‌ترسیم اینجا را تغییر دهیم و جای دیگری خراب شود و نفهمیم که خراب شده! یا وقتی بفهمیم که خیلی دیر شده! تا می‌آییم یک باگ را رفع کنیم، ۱۰ باگ دیگر ایجاد می‌شود! روحیه و انرژی تیم پایین آمده و جرات تغییر و دست زدن به کدهای قدیمی را نداریم!

🔸اپیزود دوم:

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

🔸اپیزود سوم:

ما خیلی جدی و مصمم از همان اول شروع کردیم به نوشتن تست‌های خودکار. اوایل خیلی راضی بودیم و از نوشتن تست لذت می‌بردیم. الان که شش ماه از شروع پروژه گذشته، حس می‌کنیم تست‌های ما دارند به بلای جدیدی تبدیل می‌شوند. خوانا نیستند؛ نگهداری‌شان سخت شده و گاهی باید ربع ساعت فکر کنیم که اصلا چرا این تست را نوشتیم یا این تست برای پاس شدن باید چه تنظیماتی را رعایت می‌کرد. برای همین هم مجبوریم بعضی از آنها را غیرفعال کنیم. و حتی بدتر از این، نمی‌توانیم به نتیجه مثبت تست‌های‌مان خیلی اعتماد داشته باشیم! یاد روزهای اول به خیر!

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

💡مجموعه وبینارهای «تست خودکار نرم افزار، از آغاز تا انجام» با این هدف ارایه می‌شوند تا موضوع تست خودکار نه تنها به عنوان یک مهارت بلکه به عنوان یک هنر، در تیم‌ها جدی گرفته شود. تست نوشتن با تستِ خوب نوشتن، متفاوت است. در قسمت اول به موضوع Unit Test پرداخته می‌شود.

📌تاریخ برگزاری: جمعه، 21 اردیبهشت، ساعت 15

کسب اطلاعات بیشتر و ثبت نام:

🌐https://evand.com/events/softwaretesting