تست برای همه

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

قطعا همه مطالب دنیای تست رو پوشش نمیدیم و فقط یه بحث کوچیک درباره کلمات کلیدی دنیای تست هستش که برای تکمیل کردن مطالب باید حتما سرچ کنید :)))
اگه نکته ی دارید حتما کامنت کنید یا لایک کنید و به بقیه هم معرفی کنید تا همدیگه رو کامل و کامل تر کنیم :))) مرسیی

در این صفحه درباره چیا صحبت میکنیم
* مدل های تست
- Black-Box Testing.
- White-Box Testing
* هرم تست
-unit test
- integration test
-E2E

تست نرم افزار با روش های مختلفی انجام میشه ولی بطور کلی میتوان آن ها را به دو بخش تقسیم کرد

1: White-Box Testing

2:Black-Box Testing.

What is Black Box Testing?

تست های جعبه سیاه بطور کامل ساختار , دیزاین و نوع پیاده سازی را در نظر نمیگیرد و شامل تست های میشود که از عملکرد داخلی یک سیستم ناآگاه است (نیازی هم نداره)

در این نوع تست های , تستر ها ورودی های برای سیستم در نظر میگیرند منتظر پاسخ خواهند بود و باتوجه با پاسخ دریافت شده به موضوعاتی از قبیل : نوع پاسخ , زمان پاسخ و مسائل مربوط به قابلیت استفاده و قابلیت اطمینان بودن یک سیستم میتوانند نتیجه گیری کنند.

این نوع روش تکنیک قوی و پر استفاده ی هستش و درجهان توسعه نرم افزار قطعا بیشترین استفاده را ازاین نوع تست میکنند بخاطر اینکه یک سیستم رو تا انتهای یک روند تست خواهد شد(end-to-end) و دقیقا ماننده یک یوزر (که به نحوه پیاده سازی شده سیستم اهمیت نمیدهد) و انتظار دارد که پاسخ درستی به درخواستش داده شود.تستر دقیقا میتواند یک یوزر را شبیه سازی کند و در طول مسیر میتواند UI/UX , دیتابیس و سرور و انواع وابستگی ها را تست کند.پس بسیار کاربردی و قدرتمند است.

Black Box Testing Pros and Cons:

- فواید :

۱) نیازی به دانش تکنیکال و برنامه نویسی ندارد
۲) تستر نیازی به یادگیری نحوه پیاده سازی سیستم ندارد
۳) تست ها را میتواند به شرکت ثالث (برون سپاری) یا به جمعی از استفاده کننده ها(درون سپاری) سپرد 4) تست ها پیچیدگی کمتری دارند

- معایب:

1) سخت برای اتوماتیک کردن تست ها
2) اولویت بندی کردن که معمولا برای همه تست ها غیرممکن است
3) اگر آزمایشی با شکست مواجه شود, درک علت اصلی مشکل می تولند دشوار باشد

Types Of Black Box Testing: انواع تست های جعبه سیاه

1) Functional Testing :

در تست های جعبه سیاه میتوانیم یک فیچر یا فانکشن خاصی رو تست کنیم برای مثال تست ثبت سفارش یا ورود به سیستم یا ثبت نام

2) Non-Function Testing:

تست جعبه سیاه میتوانن جنبه های یک سیستم رو که فراتر عمکلرد سیستم یا فیچر هست رو هم بررسی کنه.درواقع تست جعبه سیاه , آیا یک سیستم میتواند یک عمل خاص را اجرا کند را بررسی نمیکند بلکه قابل درستی بودن و یا به راحتی برای کاربران قابل استفاده است را نیز بررسی میکند

به عنوان مثال: - ایا سیستم یا فیچر برای کاربر قابل فهم و راحت هستش؟ - میزان لود سیستم - تست روی سیستم عامل ها و سایز های مختلف - در معرض آسیب‌پذیری‌های امنیتی یا تهدیدات امنیتی رایج

Black Box Testing Techniques

Equivalence Partitioning

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

Boundary Value Analysis

آزمایش‌کنندگان می‌توانند تشخیص دهند که یک سیستم پاسخ خاصی حول یک مقدار مرزی خاص دارد. برای مثال، یک فیلد خاص ممکن است فقط مقادیر بین 0 و 99 را بپذیرد. آزمایش‌کنندگان می‌توانند روی مقادیر مرزی (1-، 0، 99 و 100) تمرکز کنند تا ببینند آیا سیستم ورودی‌ها را به درستی می‌پذیرد یا رد می‌کند.

Decision Table Testing

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

What is White Box Testing

تست جعبه سفید رویکردی است که به آزمایش‌کنندگان اجازه می‌دهد تا عملکرد داخلی یک سیستم نرم‌افزاری - کد، زیرساخت و ادغام آن با سیستم‌های خارجی را بررسی و تأیید کنند. تست جعبه سفید بخشی ضروری از فرآیندهای CI/CD هستش

White Box Testing Pros and Cons

فواید : -پوشش کامل کد -اسان برای CI/CD و خودکار کردن تست ها -موجب بهبود کدنویسی و تمیز تر شدن سورس کد

معایب:

- زحمت زیادی برای اتومیت کردن تست - به تغییرات کد حساس است و هزینه زیادی برای نگهداری و تغییرات دارد

Types of White Box Testing

• Unit testing

تست Unit Testing یک مرحله از تست نرم افزار است که در آن بخش‌های کوچک از یک برنامه (Units) یا کامپوننت‌های مختلف یک نرم افزار تست می‌شوند. برنامه نویسان از Unit Test استفاده می‌کنند تا ببیند بازدهی برنامه آنها چیزی است که انتظارش را داشتند یا خیر. به عبارتی Unit Testing به برنامه نویس نشان می‌دهد که چقدر به طراحی اولیه نزدیک شده و برنامه او مطابق استانداردهای طراحی اولیه نرم افزار عمل می‌کند یا خیر . منظور از Unit کوچک‌ترین بخش از برنامه است که قابل تست بوده و به طور معمول شامل چند ورودی و نهایت یک خروجی می‌شود. برای توضیح بیشتر سرچ کنید مطالب زیادی در ای باره نوشته شده است.

• Mutation testingدراین نوع تست ها درواقع برای تست ,تست های نوشته شده است.درواقع بطور مستقیم تغییر های در کد ایجاد میکند و سپس بلافاصله تست ها رو اجرا میکند.اگر تست ها شکست نخورد به این نتیجه میتوان رسید که تست های نوشته شده کل کد ها رو پوشش نداده است.
• Integration testing

تست های integration ماژول های نرم افزار رو باهم ترکیب میکنه و ان ها رو به عنوان یک گروه تست میکند.بررسی میکند که ایا ماژول ها و سرویس های که نرم افزار شما را تشکیل میدهند به خوبی باهم کار میکنند یا نه.به عنوان مثال در توسعه نرم افزار های تحت وب کد ها , دیتابیس , سرویس های api تست میشود و به عنوان یک گروه در نظر گرفته میشود

• White box penetration testing

خیلی مشخصه :) تست نفوذه

• Static code analysis

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

حالا که دید کلی داریم , بهتره یه نگاه به هرم تست بندازیم

What is the Testing Pyramid?

هرم توسط مایک کوهن در کتاب موفق با چابکSucceeding with Agile (2009) استعاره ای از تفکر درمورد آ زمایش نرم افزار است و خیلی پر طرفدارا هستش و تا الان مورد استقبال قرار گرفته

این هرم تلاش میکند تا به صورت بصری یک لاجیک (منطق) سازماندهی شده از استانداردهای آزمایش را نشان میدهد و سه لایه مجزا دارد

پایه این هرم یونیت تست ها هستند بالا تر توسعه کامل دادیم و نوعی از تست جعبه سیاه هستش که بخش های از کد رو ارزیابی میکند

یک سطح بالاتر، در وسط هرم، integration tests را پیدا می‌کنیم که در کتاب مایک به آن‌ها «service tests » می‌گویند. Integration در این زمینه به آزمایش نحوه کار اجزای مختلف سیستم با هم اشاره دارد. به عنوان مثال، اگر یک مدل در کد می تواند به درستی داده ها را با پایگاه داده مبادله کند یا اگر یک روش بتواند اطلاعات را از یک API بازیابی کند. هیچ تعامل UI مورد نیاز نیست، زیرا تست های یکپارچه سازی می توانند به طور مستقیم کد را در رابط ها فراخوانی کنند.
در بالای هرم ما تست های سرتاسری (E2E) را پیدا می کنیم. E2E که به عنوان تست‌های رابط کاربری نیز شناخته می‌شود، از برنامه استفاده کنید و ببینید آیا کار می‌کند یا خیر. اما به جای اینکه یک انسان آزمایش‌ها را انجام دهد، آزمایش‌های E2E کاملاً خودکار هستند. هر تعامل کاربر تقلید می شود. یک تست E2E می‌تواند روی دکمه‌ها کلیک کند، مقادیر را تایپ کند و آنچه را که UI نشان می‌دهد ارزیابی کند.

همانطور که می بینید، سه نوع تست دامنه بسیار متفاوتی دارند:

خب حالا سوال میشه که حالا چرا هرم ؟

برای درک چگونگی شکل گیری هرم، باید پیچیدگی های هر نوع آزمایش را درک کنیم.

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

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

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

امیدواریم اکنون متوجه شده باشید که چرا هرم شکل خود را دارد: عرض هر لایه نشان دهنده کمیت نسبی ایده آل برای هر نوع آزمایش است. به عبارت دیگر، هرم می گوید ما باید چندE2E ، مقدار مناسبی از integration tests ، و گروهی از تست های واحد داشته باشیم.

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

نوشتن تست های E2E زمانی که پروژه تازه شروع شده است چالش برانگیز است. مگر اینکه تیم توسعه چارچوبی مانند BDD را بپذیرد و از همان ابتدا acceptance test را بنویسد، اکثر تست های E2E فقط زمانی نوشته می شوند که یک نمونه اولیه یا حداقل محصول قابل اجرا وجود داشته باشد. تا آن زمان، توسعه دهندگان فرصت های زیادی برای نوشتن تست های واحد و integration خواهند داشت.

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

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

هرم تست معروف ترین فرمت طراحی تست های خودکار است. فقط همین فرمت رو داریم؟ قطعا نه.