تیستن جامعه مهندسین تست نرم‌افزار ایران
نوشته های مرتبط
Integration Testing چیست؟
تست یکپارچه‌سازی یا Integration Testing به عنوان نوعی تست تعریف می‌شود که در آن ماژول‌های نرم‌افزاری به صورت Logical یکپارچه شده و به عنوان یک گروه تست می‌شوند.
یک پروژه نرم‌افزاری معمول شامل چندین ماژول نرم‌افزاریست که توسط برنامه‌نویسان مختلف کدنویسی شده است. Integration Testing بر روی بررسی ارتباط داده‌ها(Data Communication) در میان این ماژولها تمرکز می‌کند.
از این رو آن را با عناوین I & T-Integration and Testing، “تست رشته”(String Testing) و گاهی اوقات “Thread Testing” نیز می‌شناسند.
چرا Integration Testing را انجام می‌دهیم؟
اگر چه هر ماژول نرم‌افزاری تحت Unit Test قرار گرفته است، اما باز هم نواقص به دلایل مختلف وجود خواهند داشت:
- به طور کلی یک ماژول، توسط یک شخص که توسعه‌دهنده نرم‌افزار است طراحی شده است که ممکن است درک و منطق برنامه‌نویسی وی با دیگر برنامه‌نویسان متفاوت باشد. به همین دلیل تست یکپارچه‌سازی برای تایید ماژول‌های نرم‌افزاری برای کار در یک پیکر واحد ضروریست.
- در زمان توسعه ماژول، احتمال زیادی برای تغییر نیازمندی‌های مشتریان وجود دارد. این نیازمندی‌های جدید ممکن است تحت Unit Test قرار نگیرند و از این رو تست یکپارچه‌سازی سیستم ضروریست.
- ممکن است Interfaceهای ماژول‌های نرم‌افزاری با پایگاه داده اشتباه باشد.
- در صورت وجود Interfaceهای سخت‌افزاری خارجی، ممکن است آنها نیز اشتباه باشند.
- Exception Handling نادرست می‌تواند ایجاد مشکل نماید.
مثالِ Integration Test Case
Integration Test Caseها از دیگر Test Caseها متفاوت هستند، بدین معنی که این دست از Test Caseها به طور عمده بر روی Interfaceها و جریان داده/اطلاعات میان ماژولها تمرکز می‌کنند. در اینجا باید به جای Unit Functionهایی که قبلا تست شده‌اند، اولویت روی لینک‌های یکپارچه‌سازی قرار گیرد.
یک Integration Test Case را برای سناریو مثالی پیش رو ایجاد نمایید: اپلیکیشنی دارای سه ماژول به نام‌های”Login Page”، “Mailbox”، “Delete emails” و هر یک از آنها به صورت Logical یکپارچه شده‌اند.
در اینجا شما روی تست کردن صفحه لاگین تمرکز نمی‌کنید، چرا که پیش از این تحت Unit Test قرار گرفته است. اما باید چگونگی اتصال لاگین به صفحه Mail Box را بررسی کنید.
به همین شکل برای Mail Box هم باید یکپارچگی آنرا با ماژول Delete Mails بررسی کنید.
| Test Case ID | هدف Test Case | شرح Test Case | نتیجه مورد انتظار |
|---|---|---|---|
| 1 | بررسی Interface Link میان ماژول Login و Mailbox | ورود اطلاعات لاگین و کلیک روی دکمه لاگین | هدایت به سمت Mailbox |
| 2 | بررسی Interface Link میان ماژول Mailbox و Delete Mails | انتخاب ایمیل از روی Mailbox و کلیک دکمه Delete | ایمیل انتخابی باید در بخش Deleted/Trash نمایش داده شود |
رویکردها/متدولوژی‌ها/استراتژی‌های Integration Testing
مهندسی نرم‌افزار انواع استراتژی‌ها را برای اجرای تست Integration تعریف می‌کند:
- رویکرد Big Bang(انفجار بزرگ)
- رویکرد تدریجی(Incremental)، که خود به موارد زیر تقسیم می‌شود:
- رویکرد Top Down(بالا به پایین)
- رویکرد Bottom Up(پایین به بالا)
- رویکرد ساندویچ(ترکیب بالا به پایین و پایین به بالا)
در زیر استراتژی‌های مختلف، نحوه اجرا، محدودیت‌ها و نیز مزایای آنها ارائه شده است.
رویکرد Big Bang
در این رویکر تمام کامپوننت‌ها طی یک مرحله یکپارچه شده و سپس تست می‌شوند.
مزایا
- مناسب برای سیستم‌های کوچک
معایب
- محلی‌سازی عیوب(Fault Localization) سخت است
- با توجه به تعداد Interfaceهایی که باید در این رویکرد تحت تست قرار گیرند، ممکن است برخی از Interfaceهای لینک شده به سادگی از دست بروند.
- از آنجاییکه تست Integration تنها می‌تواند پس از اینکه “همه” ماژولها طراحی شدند، آغاز شود، لذا تیم تست زمان کمی برای اجرا در مرحله تست خواهد داشت.
- از آنجا که تمام ماژولها یک باره تست می‌شوند، ماژول‌های ضروریِ پرریسک ایزوله نشده و بر اساس اولویت تست نمی‌شوند. ماژول‌های محیطی که با UI ارتباط دارند نیز ایزوله نشده و طبق اولویت تست نمی‌شوند.
رویکرد تدریجی
در این روش، تست کردن بواسطه پیوستن دو یا چند ماژول که به لحاظ Logical مرتبط هستند انجام می‌شود. سپس ماژول‌های مرتبط دیگر اضافه شده و برای حصول اطمینان از کارکرد مناسب تست می‌شوند. این فرآیند ادامه می‌یابد تا تمام ماژولها با موفقیت به این مجموعه پیوسته و تست شوند.
رویکرد افزایشی به نوبه خود توسط دو روش مختلف انجام می شود:
- پایین به بالا(Bottom Up)
- بالا به پایین(Top Down)
Stub و Driver چیست؟
رویکرد تدریجی با استفاده از برنامه‌های ساختگی(Dummy) به نام Stub و Driver انجام می‌شود. Stubها و Driverها تمام منطق برنامه‌نویسی ماژول نرم‌افزاری را اجرا نمی‌کنند بلکه فقط ارتباط داده‌ای(Data Communication) با ماژولِ فراخوانی کننده را شبیه‌سازی می‌کنند.
- Stub: توسط ماژول تحت تست فراخوانی می‌شود.
- Driver: ماژولی که باید تست شود را فراخوانی می‌کند.
Bottom-up Integration
در استراتژی پایین به بالا، هر ماژول در سطوح پایین با ماژول‌های بالاتر تست می‌شود تا زمانیکه تمام ماژولها تست شوند. این رویکرد برای تست از Driverها کمک می‌گیرد.
نمای نموداری
مزایا
- محلی‌سازی عیوب(Fault Localization) آسانتر است.
- بر خلاف رویکرد Big Bang نیازی نیست برای توسعه تمام ماژولها منتظر بمانید
معایب
- ماژول‌های ضروری(در سطح بالای معماری نرم‌افزار) که جریان برنامه را کنترل می‌کنند، آخر از همه تست می‌شوند و ممکن است این قسمت‌ها مستعد خطاهای سنگینی باشند.
- رسیدن به یک Prototype زودهنگام در این رویکرد ممکن نیست.
Top-down Integration
در رویکرد Top-down، عملیات تست، Control Flow مربوط به سیستم نرم‌افزاری را از بالا به پایین دنبال می‌کند. این روش برای تست از Stubها کمک می‌گیرد.
نمای نموداری
مزایا
- محلی‌سازی عیوب(Fault Localization) آسانتر است.
- رسیدن به یک Prototype زودهنگام در این رویکرد مقدور است.
- ماژول‌های ضروری بر اساس اولویت تست می‌شوند؛ ایرادات عمده طراحی را می‌توان در ابتدای کار یافت و رفع نمود.
معایب
- نیاز به تعداد زیادی Stubs دارد.
- ماژول‌های سطح پایین به اندازه کافی تست نمی‌شوند.
Hybrid/Sandwich Integration
استراتژی ساندویچ/ترکیبی عبارتست از ترکیبی از رویکردهای Top Down و Bottom up. در این رویکر ماژول‌های سطح بالا با ماژول‌های سطح پایین تست شده و در همان لحظه ماژول‌های سطح پایین با ماژول‌های سطح بالا یکپارچه گشته و تست می‌شوند. در این استراتژی، هم از Driver و هم از Stub استفاده می‌شود.
نمای نموداری
Integration Testing را چگونه انجام دهیم
روش تست Integration بدون توجه به استراتژی‌های تست نرم‌افزار(که در بالا بیان شد):
- Integration Tests Plan را آماده کنید
- Test Scenarioها، Test Caseها، و Test Scriptها را طراحی کنید
- اجرای Test Caseها را به همراه گزارشگیری روی نواقص دنبال کنید
- نواقص(Defect) را Track کرده و مجددا تست نمایید
- مراحل ۳ و ۴ تا زمان اتمام موفقیت‌آمیز Integration تکرار شوند
شرح مختصری بر Integration Test Planها
Integration Test Plan شامل ویژگی‌های زیر است:
- متدها/رویکردها برای تست(همانطور که در بالا توضیح داده شد)
- تعیین آیتم‌های درون و برون دامنه Integration Testing
- نقش‌ها(Role) و مسئولیت‌ها(Responsibility)
- پیش‌نیازهای تست Integration
- محیط تست
- Risk Plan و Migration Plan
معیارهای ورود به/خروج از Integration Testing
معیار ورود و خروج به مرحله تست یکپارچگی در هر مدل توسعه نرم‌افزار:
معیار ورود
- روی ماژولها/کامپوننت‌ها تستِ یونیت اِعمال شده باشد
- تمام باگ‌های اولویت بالا رفع شده و وضعیت آنها بسته شود
- تمام ماژولها کدنویسی شده باشند و مرحله یکپارچه‌سازی را با موفقیت طی کرده باشند
- Test Scenarioها، Test Caseها، Integration Test Plan تائید و مستند شده باشند
- محیط تست مورد نیاز برای تست Integration ستاپ شده باشد
معیار خروج
- تست موفقیت آمیزِ اپلیکیشن یکپارچه شده
- مستند شدن Test Caseهای اجرا شده
- تمام باگ‌های اولویت بالا رفع شده و وضعیت آنها بسته شود
- مستندات فنی به همراه Release Note ارسال شده باشد
بهترین شیوه‌ها(Best Practice)/دستورالعمل‌ها برای Integration Testing
- ابتدا، استراتژی تست یکپارچه‌سازی را که می‌توانید اتخاذ نمایید، تعیین کنید و سپس Test Caseها را آماده کرده و Test Dataها را مطابق با آن آماده کنید.
- طراحی معماری اپلیکیشن را مطالعه کنید و ماژول‌های ضروری را شناسایی کنید. این ماژولها باید به ترتیب اولویت تست شوند.
- طراحی Interfaceها را از تیم معماری بدست آورده و Test Caseها را برای تائید Interfaceها به صورت دقیق ایجاد نمایید. Interfaceهای پایگاه داده/سخت‌افزار خارجی/اپلیکیشن نرم‌افزاری باید به صورت دقیق تست شود.
- پس از Test Caseها، این Test Data است که نقش حیاتی را بازی می‌کند.
- همواره پیش از اجرا، Mock Data تهیه کنید. Test Dataها را در حین اجرای Test Caseها انتخاب نکنید.
این مطلب بخشی از دوره آموزشی رایگان تست نرم‌افزار بود، که می‌توانید تمامی مطالب این دوره رایگان را در اینجا مشاهده نمایید.
