سوالات مصاحبه Mocking و Stubbing - 100 سوال کامل

سوالات تست واحد و ابزارهای تست

1. تفاوت بین Mocking و Stubbing چیست؟

پاسخ:

Mocking (ماک کردن) و Stubbing (استاب کردن) هر دو تکنیک‌هایی هستند که در تست واحد برای ایزوله کردن کد تحت تست از وابستگی‌های خارجی استفاده می‌شوند، اما هدف و کاربرد متفاوتی دارند:

Stubbing: یک Stub یک شیء جایگزین است که پاسخ‌های از پیش تعریف شده‌ای را به فراخوانی‌های متد خاص ارائه می‌دهد. هدف اصلی Stubbing کنترل رفتار وابستگی‌ها است تا بتوانیم سناریوهای مختلف را در تست شبیه‌سازی کنیم. Stub ها معمولاً هیچ انتظاری از نحوه فراخوانی خود ندارند و فقط داده‌ها را برمی‌گردانند یا یک عمل ساده را انجام می‌دهند.

مثال: فرض کنید تابعی دارید که نرخ ارز را از یک سرویس خارجی دریافت می‌کند. در تست واحد، نمی‌خواهید به سرویس واقعی متصل شوید. می‌توانید یک Stub برای سرویس نرخ ارز ایجاد کنید که همیشه یک مقدار ثابت (مثلاً 1 دلار = 42000 تومان) را برگرداند.

// Interface for currency service
public interface ICurrencyService
{
    decimal GetExchangeRate(string fromCurrency, string toCurrency);
}

// Stub implementation
public class CurrencyServiceStub : ICurrencyService
{
    public decimal GetExchangeRate(string fromCurrency, string toCurrency)
    {
        return 42000m; // Always return a fixed rate
    }
}

// Test using the stub
[Fact]
public void CalculatePriceInToman_ReturnsCorrectPrice()
{
    var currencyService = new CurrencyServiceStub();
    var product = new Product(100, "USD");
    var calculator = new PriceCalculator(currencyService);

    var priceInToman = calculator.CalculatePriceInToman(product);

    Assert.Equal(4200000m, priceInToman); // 100 * 42000
}

Mocking: یک Mock نیز یک شیء جایگزین است، اما علاوه بر ارائه پاسخ‌های از پیش تعریف شده، انتظاراتی را نیز در مورد نحوه فراخوانی خود (مانند تعداد دفعات فراخوانی، آرگومان‌های ارسال شده و ترتیب فراخوانی) ثبت می‌کند. Mock ها برای تأیید تعاملات بین کد تحت تست و وابستگی‌های آن استفاده می‌شوند.

مثال: فرض کنید می‌خواهید مطمئن شوید که وقتی یک سفارش ثبت می‌شود، متد SendConfirmationEmail در سرویس ایمیل فراخوانی می‌شود. می‌توانید یک Mock برای سرویس ایمیل ایجاد کنید و انتظار داشته باشید که این متد با آرگومان‌های خاصی فراخوانی شود.

// Interface for email service
public interface IEmailService
{
    void SendConfirmationEmail(string recipient, string subject, string body);
}

// Class under test
public class OrderProcessor
{
    private readonly IEmailService _emailService;

    public OrderProcessor(IEmailService emailService)
    {
        _emailService = emailService;
    }

    public void ProcessOrder(Order order)
    {
        // ... order processing logic ...
        _emailService.SendConfirmationEmail(order.CustomerEmail, "Order Confirmation", "Your order has been placed.");
    }
}

// Test using a mock (e.g., with Moq library)
[Fact]
public void ProcessOrder_SendsConfirmationEmail()
{
    var mockEmailService = new Mock();
    var orderProcessor = new OrderProcessor(mockEmailService.Object);
    var order = new Order { CustomerEmail = "[email protected]" };

    orderProcessor.ProcessOrder(order);

    // Verify that SendConfirmationEmail was called exactly once with specific arguments
    mockEmailService.Verify(x => x.SendConfirmationEmail(
        "[email protected]",
        "Order Confirmation",
        "Your order has been placed."), Times.Once);
}

خلاصه تفاوت‌ها:

ویژگی	Stubbing	Mocking
هدف	کنترل رفتار وابستگی‌ها (ورودی/خروجی)	تأیید تعاملات (فراخوانی متدها)
انتظارات	ندارد	دارد (در مورد نحوه فراخوانی)
حالت	معمولاً بدون حالت (stateless)	می‌تواند حالت‌دار (stateful) باشد
کاربرد	شبیه‌سازی داده‌ها یا نتایج ثابت	تأیید اینکه یک متد خاص فراخوانی شده است

به طور کلی، Stub ها برای کنترل ورودی‌ها به کد تحت تست استفاده می‌شوند، در حالی که Mock ها برای تأیید خروجی‌ها یا عوارض جانبی (side effects) کد تحت تست (مانند فراخوانی یک سرویس دیگر) استفاده می‌شوند.

2. NUnit چیست و چه کاربردی دارد؟

پاسخ:

NUnit یک فریم‌ورک تست واحد (Unit Testing Framework) متن‌باز و محبوب برای زبان‌های برنامه‌نویسی .NET است. این فریم‌ورک به توسعه‌دهندگان اجازه می‌دهد تا تست‌های واحد را برای کدهای خود بنویسند و اجرا کنند. هدف اصلی NUnit کمک به تضمین کیفیت کد، شناسایی زودهنگام باگ‌ها و تسهیل فرآیند توسعه نرم‌افزار است.

کاربردها و ویژگی‌های کلیدی NUnit:

نوشتن تست‌های واحد: NUnit یک ساختار ساده و شهودی برای نوشتن تست‌ها فراهم می‌کند. توسعه‌دهندگان می‌توانند با استفاده از Attributeهای خاص (مانند [Test], [SetUp], [TearDown]) متدهای تست را مشخص کرده و منطق تست خود را درون آن‌ها پیاده‌سازی کنند.
اجرای تست‌ها: NUnit ابزارهایی برای اجرای تست‌ها ارائه می‌دهد. این تست‌ها می‌توانند از طریق Visual Studio (با استفاده از Test Explorer), خط فرمان (Command Line) یا ابزارهای CI/CD (Continuous Integration/Continuous Delivery) اجرا شوند.
Assertionها: NUnit مجموعه‌ای غنی از Assertionها (مانند Assert.AreEqual, Assert.IsTrue, Assert.Throws) را فراهم می‌کند که برای تأیید نتایج تست‌ها استفاده می‌شوند. این Assertionها به شما کمک می‌کنند تا بررسی کنید که آیا خروجی کد شما مطابق انتظار است یا خیر.
Test Fixtures: قابلیت گروه‌بندی تست‌ها در کلاس‌ها (Test Fixtures) را فراهم می‌کند که به سازماندهی بهتر تست‌ها کمک می‌کند. متدهای [SetUp] و [TearDown] امکان اجرای کد قبل و بعد از هر تست یا هر Test Fixture را فراهم می‌کنند.
Data-Driven Tests: NUnit از تست‌های مبتنی بر داده (Data-Driven Tests) پشتیبانی می‌کند، که به شما امکان می‌دهد یک تست واحد را با مجموعه‌ای از داده‌های ورودی مختلف اجرا کنید. این کار با استفاده از Attributeهایی مانند [TestCase] یا [ValueSource] انجام می‌شود.
قابلیت توسعه‌پذیری: NUnit یک فریم‌ورک قابل توسعه است و به توسعه‌دهندگان اجازه می‌دهد تا Attributeهای سفارشی، Assertionهای جدید و افزونه‌های مختلف را برای نیازهای خاص خود ایجاد کنند.

مثال ساده استفاده از NUnit:

فرض کنید کلاسی برای انجام عملیات ریاضی ساده دارید:

public class Calculator
{
    public int Add(int a, int b)
    {
        return a + b;
    }

    public int Subtract(int a, int b)
    {
        return a - b;
    }
}

حالا می‌توانید تست‌های NUnit را برای این کلاس بنویسید:

using NUnit.Framework;

[TestFixture]
public class CalculatorTests
{
    private Calculator _calculator;

    [SetUp]
    public void Setup()
    {
        // This method runs before each test
        _calculator = new Calculator();
    }

    [Test]
    public void Add_TwoNumbers_ReturnsCorrectSum()
    {
        // Arrange
        int a = 5;
        int b = 3;

        // Act
        int result = _calculator.Add(a, b);

        // Assert
        Assert.AreEqual(8, result);
    }

    [Test]
    public void Subtract_TwoNumbers_ReturnsCorrectDifference()
    {
        // Arrange
        int a = 10;
        int b = 4;

        // Act
        int result = _calculator.Subtract(a, b);

        // Assert
        Assert.AreEqual(6, result);
    }

    [TestCase(1, 2, 3)]
    [TestCase(-1, -2, -3)]
    [TestCase(0, 0, 0)]
    public void Add_VariousNumbers_ReturnsCorrectSum(int a, int b, int expected)
    {
        // Arrange
        // _calculator is already initialized in Setup

        // Act
        int result = _calculator.Add(a, b);

        // Assert
        Assert.AreEqual(expected, result);
    }
}

در این مثال:

[TestFixture] کلاس CalculatorTests را به عنوان یک کلاس تست NUnit مشخص می‌کند.
[SetUp] متد Setup را مشخص می‌کند که قبل از هر تست اجرا می‌شود.
[Test] متدهای تست واحد را مشخص می‌کند.
Assert.AreEqual برای تأیید برابری مقادیر استفاده می‌شود.
[TestCase] برای اجرای یک تست با داده‌های مختلف استفاده می‌شود.

NUnit به طور گسترده در پروژه‌های .NET برای اطمینان از صحت و پایداری کد استفاده می‌شود و یکی از ابزارهای اساسی در توسعه نرم‌افزار مدرن است.

3. Black-box testing چیست؟

پاسخ:

Black-box testing (تست جعبه سیاه) یک روش تست نرم‌افزار است که در آن عملکرد داخلی سیستم یا کامپوننت مورد تست برای تستر ناشناخته است. تستر فقط به ورودی‌ها و خروجی‌های سیستم دسترسی دارد و بر اساس مشخصات و الزامات، صحت عملکرد سیستم را بررسی می‌کند. این روش تست بر روی رفتار خارجی سیستم تمرکز دارد و به ساختار کد، طراحی داخلی یا پیاده‌سازی توجهی نمی‌کند.

ویژگی‌های کلیدی Black-box testing:

عدم نیاز به دانش داخلی: تستر نیازی به دانش کد منبع، ساختار داخلی یا الگوریتم‌های پیاده‌سازی شده ندارد.
تمرکز بر الزامات: تست‌ها بر اساس مشخصات عملکردی و غیرعملکردی سیستم طراحی می‌شوند.
دیدگاه کاربر نهایی: این روش تست، سیستم را از دیدگاه کاربر نهایی بررسی می‌کند.
انواع تست: شامل تست عملکردی (Functional Testing)، تست غیرعملکردی (Non-Functional Testing) مانند تست کارایی (Performance Testing)، تست امنیتی (Security Testing) و تست قابلیت استفاده (Usability Testing) می‌شود.

تکنیک‌های طراحی تست برای Black-box testing:

Equivalence Partitioning (پارتیشن‌بندی هم‌ارزی): تقسیم ورودی‌ها به گروه‌هایی که انتظار می‌رود رفتار مشابهی داشته باشند.
Boundary Value Analysis (تحلیل مقادیر مرزی): تمرکز بر مقادیر در مرزهای پارتیشن‌های هم‌ارزی، زیرا خطاها اغلب در این نقاط رخ می‌دهند.
Decision Table Testing (تست جدول تصمیم): استفاده از جداول برای پوشش ترکیبات مختلف ورودی‌ها و شرایط.
State Transition Testing (تست انتقال حالت): بررسی رفتار سیستم در پاسخ به رویدادها و تغییرات حالت.
Use Case Testing (تست مورد استفاده): طراحی تست‌ها بر اساس سناریوهای واقعی استفاده از سیستم.

مزایای Black-box testing:

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

معایب Black-box testing:

پوشش کد نامشخص: بدون دسترسی به کد، نمی‌توان میزان پوشش کد را تضمین کرد.
کشف خطاهای منطقی دشوار: خطاهای مربوط به منطق داخلی یا ساختار کد ممکن است کشف نشوند.
طراحی تست‌های تکراری: ممکن است تست‌های تکراری طراحی شوند که کارایی را کاهش می‌دهد.

مثال:

فرض کنید یک تابع برای محاسبه تخفیف بر اساس مبلغ خرید دارید:

public decimal CalculateDiscount(decimal purchaseAmount)
{
    if (purchaseAmount >= 1000)
    {
        return purchaseAmount * 0.10m; // 10% discount
    }
    else if (purchaseAmount >= 500)
    {
        return purchaseAmount * 0.05m; // 5% discount
    }
    else
    {
        return 0m; // No discount
    }
}

در Black-box testing، تستر بدون دیدن کد بالا، فقط بر اساس الزامات (مثلاً تخفیف 10% برای خرید بالای 1000، 5% برای 500 تا 999.99 و بدون تخفیف برای کمتر از 500) تست‌ها را طراحی می‌کند:

تست بدون تخفیف: ورودی 400، انتظار خروجی 0.
تست 5% تخفیف: ورودی 750، انتظار خروجی 37.5.
تست 10% تخفیف: ورودی 1200، انتظار خروجی 120.
تست مقادیر مرزی: ورودی 499.99 (انتظار 0)، 500 (انتظار 25)، 999.99 (انتظار 49.9995)، 1000 (انتظار 100).

در این مثال, تستر فقط ورودی‌ها را فراهم می‌کند و خروجی‌ها را بررسی می‌کند، بدون اینکه بداند تابع CalculateDiscount چگونه پیاده‌سازی شده است.

4. White-box testing چیست؟

پاسخ:

White-box testing (تست جعبه سفید)، که به آن Clear-box testing، Glass-box testing یا Structural testing نیز گفته می‌شود، یک روش تست نرم‌افزار است که در آن تستر دانش کاملی از ساختار داخلی، طراحی و پیاده‌سازی سیستم یا کامپوننت مورد تست دارد. این دانش شامل کد منبع، ساختار داده‌ها، طراحی داخلی و الگوریتم‌های استفاده شده است. هدف اصلی White-box testing، بررسی مسیرهای داخلی کد، منطق برنامه و پوشش کد است.

ویژگی‌های کلیدی White-box testing:

نیاز به دانش داخلی: تستر باید دانش عمیقی از کد منبع، ساختار داخلی و منطق برنامه داشته باشد.
تمرکز بر ساختار داخلی: تست‌ها بر اساس ساختار داخلی کد (مانند مسیرهای اجرایی، حلقه‌ها، شرط‌ها) طراحی می‌شوند.
دیدگاه توسعه‌دهنده: این روش تست بیشتر از دیدگاه توسعه‌دهنده انجام می‌شود.
انواع تست: شامل تست مسیر (Path Testing)، تست حلقه (Loop Testing)، تست شرط (Condition Testing) و تست جریان داده (Data Flow Testing) می‌شود.

تکنیک‌های طراحی تست برای White-box testing:

Statement Coverage (پوشش دستورات): اطمینان از اینکه هر دستور در کد حداقل یک بار اجرا شود.
Branch Coverage (پوشش شاخه‌ها): اطمینان از اینکه هر شاخه (مانند if/else، switch) در کد حداقل یک بار در هر دو حالت True و False اجرا شود.
Path Coverage (پوشش مسیرها): اطمینان از اینکه تمام مسیرهای ممکن در کد حداقل یک بار اجرا شوند (این روش معمولاً بسیار پیچیده و زمان‌بر است).

Condition Coverage (پوشش شرط‌ها): اطمینان از اینکه هر شرط بولی در کد حداقل یک بار در هر دو حالت True و False ارزیابی شود.

مزایای White-box testing:

کشف خطاهای داخلی: برای کشف خطاهای منطقی، خطاهای مربوط به جریان داده و خطاهای مربوط به ساختار کد بسیار مؤثر است.

بهینه‌سازی کد: به شناسایی کدهای غیرقابل دسترس (dead code) و کدهای غیربهینه کمک می‌کند.

پوشش کد بالا: امکان دستیابی به پوشش کد بالا را فراهم می‌کند.

تضمین کیفیت: به تضمین کیفیت داخلی و پایداری کد کمک می‌کند.

معایب White-box testing:

نیاز به دانش برنامه‌نویسی: تستر باید مهارت‌های برنامه‌نویسی داشته باشد.

زمان‌بر و پیچیده: طراحی و اجرای تست‌های جعبه سفید می‌تواند زمان‌بر و پیچیده باشد، به خصوص برای سیستم‌های بزرگ.

عدم کشف خطاهای عملکردی: ممکن است خطاهای مربوط به الزامات و مشخصات سیستم (که Black-box testing در آن قوی‌تر است) را کشف نکند.

مثال:
همان تابع CalculateDiscount را در نظر بگیرید:

public decimal CalculateDiscount(decimal purchaseAmount) { if (purchaseAmount >= 1000) // Branch 1 { return purchaseAmount * 0.10m; } else if (purchaseAmount >= 500) // Branch 2 { return purchaseAmount * 0.05m; } else // Branch 3 { return 0m; } }

در White-box testing، تستر کد را بررسی می‌کند و تست‌هایی را برای پوشش تمام مسیرها و شاخه‌ها طراحی می‌کند:

تست برای پوشش Branch 1 (purchaseAmount >= 1000): ورودی 1200.

تست برای پوشش Branch 2 (purchaseAmount >= 500 و purchaseAmount < 1000): ورودی 750.

تست برای پوشش Branch 3 (purchaseAmount < 500): ورودی 400.

با این سه تست، تمام شاخه‌های if/else if/else پوشش داده می‌شوند. تستر می‌تواند همچنین تست‌هایی را برای اطمینان از اینکه هر شرط (مثلاً purchaseAmount >= 1000) هم در حالت True و هم در حالت False ارزیابی می‌شود، اضافه کند.

White-box testing معمولاً توسط توسعه‌دهندگان در مرحله تست واحد انجام می‌شود، زیرا آنها دانش عمیقی از کد دارند.

5. Gray-box testing چیست؟

پاسخ:

Gray-box testing (تست جعبه خاکستری) یک روش تست نرم‌افزار است که ترکیبی از Black-box testing و White-box testing است. در این روش، تستر دانش جزئی از ساختار داخلی سیستم (مانند دسترسی به معماری، ساختار داده‌ها یا الگوریتم‌ها) دارد، اما نه به اندازه White-box testing. این دانش جزئی به تستر کمک می‌کند تا تست‌های مؤثرتری را طراحی کند، بدون اینکه نیاز به بررسی کامل کد منبع داشته باشد.

ویژگی‌های کلیدی Gray-box testing:

دانش جزئی داخلی: تستر دانش محدودی از ساختار داخلی سیستم دارد، معمولاً در سطح طراحی یا معماری، نه در سطح کد منبع.

ترکیب دیدگاه‌ها: از دیدگاه کاربر نهایی (مانند Black-box) و دیدگاه توسعه‌دهنده (مانند White-box) بهره می‌برد.

تمرکز بر لایه‌ها: اغلب برای تست لایه‌های میانی سیستم، مانند لایه پایگاه داده یا لایه سرویس، استفاده می‌شود.

تکنیک‌های طراحی تست برای Gray-box testing:

Matrix Testing: تحلیل ماتریس ریسک برای شناسایی مناطق پرخطر و طراحی تست‌های متمرکز.

Regression Testing: استفاده از دانش داخلی برای انتخاب تست‌های رگرسیون مرتبط و مؤثر.

Pattern Testing: شناسایی الگوهای رایج خطا در سیستم و طراحی تست‌ها بر اساس آن‌ها.

Orthogonal Array Testing: استفاده از آرایه‌های متعامد برای پوشش ترکیبات مختلف ورودی‌ها با حداقل تعداد تست.

مزایای Gray-box testing:

کارایی بالاتر: با داشتن دانش جزئی از داخلی سیستم، تستر می‌تواند تست‌های هوشمندانه‌تر و مؤثرتری را طراحی کند که احتمال کشف خطاها را افزایش می‌دهد.

پوشش بهتر: نسبت به Black-box testing پوشش بهتری از سیستم را فراهم می‌کند.

کشف خطاهای عمیق‌تر: می‌تواند خطاهایی را کشف کند که ممکن است در Black-box testing نادیده گرفته شوند.

عدم نیاز به دسترسی کامل به کد: نیازی به دسترسی کامل به کد منبع نیست، که این امر برای تست‌کنندگانی که برنامه‌نویس نیستند، مناسب است.

معایب Gray-box testing:

پوشش محدود: پوشش کد به اندازه White-box testing کامل نیست.

وابستگی به دانش داخلی: نیاز به حداقل دانش داخلی برای طراحی تست‌های مؤثر دارد.

پیچیدگی: می‌تواند پیچیده‌تر از Black-box testing باشد.

مثال:
فرض کنید در حال تست یک برنامه وب هستید که از یک پایگاه داده استفاده می‌کند. در Gray-box testing، شما ممکن است به طرحواره پایگاه داده (Database Schema) دسترسی داشته باشید، اما نه به کد منبع کامل برنامه. با استفاده از این دانش، می‌توانید تست‌هایی را طراحی کنید که بررسی کنند آیا داده‌ها به درستی در پایگاه داده ذخیره می‌شوند یا خیر، یا آیا کوئری‌های پایگاه داده بهینه هستند یا خیر.

به عنوان مثال، می‌توانید یک ورودی را از طریق رابط کاربری (Black-box) وارد کنید و سپس مستقیماً پایگاه داده را بررسی کنید (با استفاده از دانش جزئی از ساختار پایگاه داده) تا مطمئن شوید که داده‌ها به درستی ذخیره شده‌اند. این ترکیب، تست را کارآمدتر می‌کند.

6. تست واحد (Unit Testing) چیست؟

پاسخ:

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

ویژگی‌های کلیدی تست واحد:

ایزوله‌سازی: هر واحد کد به صورت ایزوله تست می‌شود تا اطمینان حاصل شود که فقط آن واحد خاص به درستی کار می‌کند و مشکلات از وابستگی‌های خارجی نیستند.

خودکارسازی: تست‌های واحد معمولاً خودکار هستند و می‌توانند به سرعت و به طور مکرر اجرا شوند.

سرعت: به دلیل ایزوله‌سازی و خودکارسازی، تست‌های واحد بسیار سریع اجرا می‌شوند.

تمرکز بر کوچکترین واحد: تمرکز بر روی کوچکترین بخش قابل تست کد است.

مزایای تست واحد:

شناسایی زودهنگام باگ‌ها: باگ‌ها در مراحل اولیه توسعه شناسایی و رفع می‌شوند.

افزایش کیفیت کد: به بهبود طراحی کد، کاهش پیچیدگی و افزایش قابلیت نگهداری کمک می‌کند.

تسهیل رگرسیون: اطمینان می‌دهد که تغییرات جدید در کد، عملکرد موجود را خراب نمی‌کنند.

مستندسازی: تست‌های واحد می‌توانند به عنوان مستنداتی برای نحوه عملکرد هر واحد کد عمل کنند.

تسهیل Refactoring: با اطمینان از وجود تست‌های واحد، توسعه‌دهندگان می‌توانند با اطمینان بیشتری کد را Refactor کنند.

معایب تست واحد:

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

زمان‌بر بودن نوشتن تست‌ها: نوشتن تست‌های واحد برای تمام واحدها می‌تواند زمان‌بر باشد.

مثال:
فرض کنید کلاسی برای مدیریت موجودی محصولات دارید:

public class ProductInventory { private int _stock; public ProductInventory(int initialStock) { _stock = initialStock; } public void AddStock(int quantity) { if (quantity < 0) throw new ArgumentOutOfRangeException(nameof(quantity), "Quantity cannot be negative."); _stock += quantity; } public void RemoveStock(int quantity) { if (quantity < 0) throw new ArgumentOutOfRangeException(nameof(quantity), "Quantity cannot be negative."); if (_stock < quantity) throw new InvalidOperationException("Not enough stock."); _stock -= quantity; } public int GetCurrentStock() { return _stock; } }

تست‌های واحد برای این کلاس می‌توانند شامل موارد زیر باشند:

تست متد AddStock با مقادیر مثبت.

تست متد AddStock با مقادیر منفی (انتظار خطا).

تست متد RemoveStock با مقادیر مثبت و موجودی کافی.

تست متد RemoveStock با مقادیر منفی (انتظار خطا).

تست متد RemoveStock زمانی که موجودی کافی نیست (انتظار خطا).

تست متد GetCurrentStock.

هر یک از این تست‌ها به صورت جداگانه و مستقل اجرا می‌شوند تا اطمینان حاصل شود که هر متد به درستی کار می‌کند.

7. تست یکپارچه‌سازی (Integration Testing) چیست؟

پاسخ:

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

ویژگی‌های کلیدی تست یکپارچه‌سازی:

ترکیب ماژول‌ها: ماژول‌های تست شده واحد با هم ترکیب می‌شوند.

تمرکز بر رابط‌ها: تمرکز اصلی بر روی نحوه ارتباط و تبادل داده بین ماژول‌ها است.

روش‌های مختلف: می‌تواند به روش‌های مختلفی مانند رویکرد بالا به پایین (Top-Down)، پایین به بالا (Bottom-Up) یا ساندویچی (Sandwich) انجام شود.

مزایای تست یکپارچه‌سازی:

کشف خطاهای رابط: خطاهای مربوط به ناسازگاری داده‌ها، پروتکل‌های ارتباطی یا سوءتفاهم در رابط‌های بین ماژول‌ها را شناسایی می‌کند.

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

اعتماد به سیستم: با تأیید اینکه ماژول‌ها با هم کار می‌کنند، اعتماد به سیستم افزایش می‌یابد.

معایب تست یکپارچه‌سازی:

پیچیدگی بیشتر: نسبت به تست واحد پیچیده‌تر است و ممکن است زمان بیشتری برای طراحی و اجرا نیاز داشته باشد.

نیاز به محیط تست: ممکن است نیاز به محیط تست خاصی داشته باشد که شامل پایگاه داده، سرویس‌های خارجی و غیره باشد.

مثال:
فرض کنید یک سیستم تجارت الکترونیک دارید که شامل ماژول‌های زیر است:

ماژول کاربر (User Module): مدیریت ثبت‌نام، ورود و پروفایل کاربر.

ماژول محصول (Product Module): مدیریت اطلاعات محصولات و موجودی.

ماژول سفارش (Order Module): مدیریت فرآیند ثبت سفارش و پرداخت.

در تست یکپارچه‌سازی، شما ممکن است سناریوهایی را تست کنید که شامل تعامل بین این ماژول‌ها باشد:

تست ثبت سفارش: بررسی کنید که آیا پس از ثبت سفارش توسط کاربر (تعامل User Module و Order Module)، موجودی محصول به درستی کاهش می‌یابد (تعامل Order Module و Product Module).

تست به‌روزرسانی پروفایل: بررسی کنید که آیا پس از به‌روزرسانی اطلاعات کاربر در User Module، این تغییرات به درستی در سایر ماژول‌هایی که از اطلاعات کاربر استفاده می‌کنند (مانند Order Module برای نمایش تاریخچه سفارش)، منعکس می‌شود.

این تست‌ها اطمینان حاصل می‌کنند که ماژول‌ها به درستی با یکدیگر یکپارچه شده‌اند و به عنوان یک سیستم واحد کار می‌کنند.

8. تست سیستم (System Testing) چیست؟

پاسخ:

تست سیستم (System Testing) یک سطح از تست نرم‌افزار است که در آن کل سیستم نرم‌افزاری به صورت کامل و یکپارچه تست می‌شود. این تست پس از تست یکپارچه‌سازی انجام می‌شود و هدف آن ارزیابی انطباق سیستم با الزامات عملکردی و غیرعملکردی مشخص شده است. تست سیستم، سیستم را به عنوان یک کل واحد در محیطی شبیه به محیط تولید (Production Environment) آزمایش می‌کند.

ویژگی‌های کلیدی تست سیستم:

تست End-to-End: کل سیستم از ابتدا تا انتها تست می‌شود.

محیط شبیه به تولید: تست در محیطی انجام می‌شود که تا حد امکان به محیط واقعی تولید نزدیک باشد.

تمرکز بر الزامات: تأیید می‌کند که سیستم تمام الزامات مشخص شده را برآورده می‌کند.

انواع تست: شامل تست عملکردی، تست رگرسیون، تست امنیتی، تست کارایی، تست قابلیت استفاده، تست بازیابی (Recovery Testing) و تست نصب (Installation Testing) می‌شود.

مزایای تست سیستم:

کشف خطاهای سیستمی: خطاهایی را کشف می‌کند که ممکن است در سطوح پایین‌تر تست (واحد و یکپارچه‌سازی) نادیده گرفته شوند، مانند مشکلات پیکربندی، تعاملات بین زیرسیستم‌ها یا مشکلات محیطی.

اعتماد به سیستم: با تأیید عملکرد کلی سیستم، اعتماد به آن افزایش می‌یابد.

تأیید الزامات: اطمینان حاصل می‌کند که سیستم تمام الزامات کاربر و کسب‌وکار را برآورده می‌کند.

معایب تست سیستم:

زمان‌بر و پرهزینه: به دلیل پیچیدگی و گستردگی، تست سیستم می‌تواند زمان‌بر و پرهزینه باشد.

اشکال‌زدایی دشوار: شناسایی ریشه مشکلات در این سطح می‌تواند دشوار باشد، زیرا خطا ممکن است در هر یک از ماژول‌های زیرین یا در تعاملات آنها باشد.

مثال:
در همان سیستم تجارت الکترونیک، تست سیستم شامل سناریوهای کامل کاربر نهایی خواهد بود:

سناریوی خرید کامل: کاربر ثبت‌نام می‌کند، وارد می‌شود، محصولات را به سبد خرید اضافه می‌کند، پرداخت را انجام می‌دهد، سفارش را نهایی می‌کند و ایمیل تأیید دریافت می‌کند. در این سناریو، تمام ماژول‌ها (کاربر، محصول، سفارش، پرداخت، ایمیل) و زیرسیستم‌ها (پایگاه داده، سرویس‌های خارجی) با هم کار می‌کنند.

تست کارایی: بررسی می‌شود که سیستم تحت بار ترافیکی بالا چگونه عمل می‌کند (مثلاً 1000 کاربر همزمان).

تست امنیتی: آسیب‌پذیری‌های امنیتی مانند حملات SQL Injection یا XSS بررسی می‌شوند.

تست بازیابی: بررسی می‌شود که سیستم پس از یک خرابی (مثلاً قطع برق) چگونه بازیابی می‌شود و داده‌ها از بین نمی‌روند.

تست سیستم اطمینان حاصل می‌کند که محصول نهایی آماده تحویل به مشتری است.

9. تست پذیرش کاربر (User Acceptance Testing - UAT) چیست؟

پاسخ:

تست پذیرش کاربر (User Acceptance Testing - UAT)، که به آن تست بتا (Beta Testing) یا تست کاربر نهایی (End-User Testing) نیز گفته می‌شود، آخرین مرحله از فرآیند تست نرم‌افزار قبل از انتشار نهایی محصول است. در این مرحله، کاربران نهایی واقعی یا مشتریان، سیستم را در محیطی شبیه به محیط تولید آزمایش می‌کنند تا تأیید کنند که سیستم الزامات کسب‌وکار را برآورده می‌کند و برای استفاده در دنیای واقعی مناسب است.

ویژگی‌های کلیدی UAT:

توسط کاربران نهایی: تست توسط افرادی انجام می‌شود که قرار است از سیستم استفاده کنند.

تمرکز بر الزامات کسب‌وکار: هدف اصلی تأیید این است که سیستم مشکلات کسب‌وکار را حل می‌کند و نیازهای کاربران را برآورده می‌سازد.

سناریوهای واقعی: تست‌ها بر اساس سناریوهای واقعی کسب‌وکار و جریان‌های کاری روزمره طراحی می‌شوند.

محیط شبیه به تولید: UAT در محیطی انجام می‌شود که تا حد امکان به محیط واقعی تولید نزدیک باشد.

انواع UAT:

Alpha Testing: معمولاً توسط تیم داخلی (توسعه‌دهندگان یا تست‌کنندگان) در محیط توسعه انجام می‌شود، اما از دیدگاه کاربر نهایی.

Beta Testing: توسط گروه کوچکی از کاربران واقعی در محیط واقعی آنها انجام می‌شود. بازخوردها جمع‌آوری و برای بهبود محصول استفاده می‌شود.

Operational Acceptance Testing (OAT): تأیید می‌کند که سیستم برای عملیات روزانه آماده است (مانند پشتیبان‌گیری، بازیابی، امنیت).

Contract Acceptance Testing: تأیید می‌کند که سیستم الزامات مشخص شده در قرارداد را برآورده می‌کند.

Regulation Acceptance Testing: تأیید می‌کند که سیستم با قوانین و مقررات مربوطه مطابقت دارد.

مزایای UAT:

تأیید نیازهای کسب‌وکار: اطمینان حاصل می‌کند که محصول نهایی واقعاً نیازهای کسب‌وکار را برآورده می‌کند.

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

کشف خطاهای نادیده گرفته شده: ممکن است خطاهایی را کشف کند که در مراحل قبلی تست نادیده گرفته شده‌اند، به خصوص خطاهای مربوط به جریان‌های کاری پیچیده یا سناریوهای غیرمنتظره.

کاهش ریسک انتشار: با تأیید نهایی توسط کاربران، ریسک انتشار محصول با باگ‌های حیاتی کاهش می‌یابد.

معایب UAT:

زمان‌بر و پرهزینه: نیاز به مشارکت کاربران واقعی دارد که ممکن است زمان‌بر و پرهزینه باشد.

نیاز به برنامه‌ریزی دقیق: نیازمند برنامه‌ریزی دقیق و مدیریت بازخوردها است.

مثال:
در سیستم تجارت الکترونیک، UAT شامل موارد زیر خواهد بود:

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

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

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

تیم توسعه بر اساس این بازخوردها، اصلاحات لازم را انجام می‌دهد تا زمانی که کاربران محصول را برای انتشار نهایی تأیید کنند.

UAT یک مرحله حیاتی برای اطمینان از رضایت مشتری و موفقیت محصول در بازار است.

10. تست رگرسیون (Regression Testing) چیست؟

پاسخ:

تست رگرسیون (Regression Testing) یک نوع تست نرم‌افزار است که برای اطمینان از این انجام می‌شود که تغییرات جدید در کد (مانند افزودن ویژگی‌های جدید، رفع باگ‌ها، یا بهینه‌سازی کد) باعث ایجاد باگ‌های جدید در بخش‌های موجود و قبلاً کارآمد سیستم نشده‌اند. هدف اصلی تست رگرسیون، تأیید این است که عملکرد موجود سیستم پس از تغییرات، همچنان صحیح و پایدار است.

ویژگی‌های کلیدی تست رگرسیون:

اجرای مجدد تست‌ها: تست‌های قبلی (که قبلاً با موفقیت اجرا شده‌اند) مجدداً اجرا می‌شوند.

خودکارسازی: به دلیل ماهیت تکراری، تست رگرسیون اغلب خودکار می‌شود.

پس از هر تغییر: معمولاً پس از هر تغییر مهم در کد یا پس از هر بیلد جدید اجرا می‌شود.

چه زمانی تست رگرسیون انجام می‌شود؟

پس از افزودن ویژگی‌های جدید.

پس از رفع باگ‌ها.

پس از تغییرات در پیکربندی سیستم.

پس از بهینه‌سازی عملکرد.

پس از به‌روزرسانی‌های محیطی (مانند سیستم عامل یا پایگاه داده).

تکنیک‌های تست رگرسیون:

Re-test All: اجرای مجدد تمام تست‌های موجود. این روش جامع است اما زمان‌بر و پرهزینه.

Selection of Regression Tests: انتخاب زیرمجموعه‌ای از تست‌های موجود که احتمالاً تحت تأثیر تغییرات قرار گرفته‌اند. این روش کارآمدتر است.

Prioritization of Regression Tests: اولویت‌بندی تست‌های انتخاب شده بر اساس ریسک و اهمیت.

مزایای تست رگرسیون:

تضمین پایداری: اطمینان حاصل می‌کند که تغییرات جدید، عملکرد موجود را خراب نمی‌کنند.

افزایش اعتماد: به توسعه‌دهندگان و تیم QA اعتماد بیشتری به کد می‌دهد.

کاهش ریسک: ریسک معرفی باگ‌های جدید در نسخه‌های بعدی را کاهش می‌دهد.

معایب تست رگرسیون:

زمان‌بر بودن: اگر خودکار نباشد، می‌تواند بسیار زمان‌بر باشد.

هزینه: نیاز به نگهداری مجموعه تست‌های رگرسیون دارد.

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

باگ اصلی واقعاً رفع شده است.

رفع این باگ، باعث ایجاد مشکل در سایر بخش‌های مربوط به مالیات (مثلاً محاسبه مالیات برای محصولات مختلف یا در مناطق جغرافیایی متفاوت) نشده است.

سایر عملکردهای سیستم (مانند ثبت سفارش، پرداخت) همچنان به درستی کار می‌کنند.

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

11. تست عملکردی (Functional Testing) چیست؟

پاسخ:

تست عملکردی (Functional Testing) یک نوع تست نرم‌افزار است که بر روی بررسی عملکرد سیستم بر اساس الزامات و مشخصات عملکردی تمرکز دارد. هدف اصلی این تست، تأیید این است که هر ویژگی و عملکرد سیستم مطابق با آنچه در مستندات طراحی و الزامات ذکر شده است، کار می‌کند. این تست بدون توجه به ساختار داخلی کد (مانند Black-box testing) انجام می‌شود.

ویژگی‌های کلیدی تست عملکردی:

تمرکز بر الزامات: تأیید می‌کند که سیستم تمام الزامات عملکردی را برآورده می‌کند.

تست Black-box: معمولاً به عنوان یک نوع تست جعبه سیاه انجام می‌شود، به این معنی که تستر نیازی به دانش داخلی کد ندارد.

سناریوهای کاربر: تست‌ها بر اساس سناریوهای واقعی استفاده از سیستم توسط کاربر طراحی می‌شوند.

انواع تست عملکردی:

تست واحد (Unit Testing): تست کوچکترین واحدهای کد.

تست یکپارچه‌سازی (Integration Testing): تست تعاملات بین ماژول‌ها.

تست سیستم (System Testing): تست کل سیستم به عنوان یک واحد.

تست پذیرش کاربر (User Acceptance Testing - UAT): تأیید سیستم توسط کاربران نهایی.

تست رگرسیون (Regression Testing): اطمینان از عدم ایجاد باگ‌های جدید پس از تغییرات.

مزایای تست عملکردی:

تأیید الزامات: اطمینان حاصل می‌کند که سیستم مطابق با نیازهای کسب‌وکار عمل می‌کند.

دیدگاه کاربر: سیستم را از دیدگاه کاربر نهایی تست می‌کند.

کشف خطاهای عملکردی: برای کشف خطاهای مربوط به عملکرد سیستم بسیار مؤثر است.

معایب تست عملکردی:

عدم پوشش داخلی: به ساختار داخلی کد توجهی نمی‌کند، بنابراین ممکن است خطاهای مربوط به منطق داخلی را کشف نکند.

زمان‌بر بودن: طراحی و اجرای تست‌های عملکردی می‌تواند زمان‌بر باشد.

مثال:
در یک سیستم بانکداری آنلاین، تست عملکردی شامل موارد زیر خواهد بود:

تست قابلیت ورود به سیستم با نام کاربری و رمز عبور صحیح و غلط.

تست قابلیت انتقال وجه بین حساب‌ها.

تست قابلیت مشاهده تاریخچه تراکنش‌ها.

تست قابلیت پرداخت قبوض.

تست قابلیت ثبت‌نام کاربر جدید.

هر یک از این سناریوها بر اساس الزامات عملکردی سیستم طراحی و اجرا می‌شوند تا اطمینان حاصل شود که سیستم به درستی کار می‌کند.

12. تست غیرعملکردی (Non-Functional Testing) چیست؟

پاسخ:

تست غیرعملکردی (Non-Functional Testing) یک نوع تست نرم‌افزار است که بر روی بررسی جنبه‌های غیرعملکردی سیستم تمرکز دارد. این جنبه‌ها شامل نحوه عملکرد سیستم است، نه اینکه چه کاری انجام می‌دهد. هدف اصلی این تست، ارزیابی کیفیت سیستم از نظر کارایی، قابلیت اطمینان، قابلیت استفاده، امنیت، مقیاس‌پذیری و سایر ویژگی‌های غیرعملکردی است.

ویژگی‌های کلیدی تست غیرعملکردی:

تمرکز بر کیفیت: بر روی کیفیت سیستم و تجربه کاربر تمرکز دارد.

اندازه‌گیری عملکرد: شامل اندازه‌گیری معیارهایی مانند زمان پاسخ، توان عملیاتی و مصرف منابع است.

تست Black-box و White-box: می‌تواند با استفاده از هر دو رویکرد جعبه سیاه و جعبه سفید انجام شود.

انواع تست غیرعملکردی:

تست کارایی (Performance Testing): بررسی سرعت، پاسخگویی و پایداری سیستم تحت بار کاری خاص. شامل:

Load Testing: تست سیستم تحت بار کاری مورد انتظار.

Stress Testing: تست سیستم تحت بار کاری فراتر از حد انتظار برای یافتن نقطه شکست.

Scalability Testing: بررسی توانایی سیستم برای مقیاس‌پذیری (افزایش یا کاهش بار).

Volume Testing: تست سیستم با حجم زیادی از داده‌ها.

Endurance Testing (Soak Testing): تست سیستم برای مدت زمان طولانی تحت بار کاری مداوم.

تست امنیتی (Security Testing): شناسایی آسیب‌پذیری‌ها و نقاط ضعف امنیتی.

تست قابلیت استفاده (Usability Testing): بررسی سهولت استفاده از سیستم برای کاربران.

تست قابلیت اطمینان (Reliability Testing): بررسی توانایی سیستم برای انجام عملکرد مورد نظر بدون شکست برای مدت زمان مشخص.

تست قابلیت نگهداری (Maintainability Testing): بررسی سهولت اصلاح، به‌روزرسانی و نگهداری سیستم.

تست قابلیت حمل (Portability Testing): بررسی توانایی سیستم برای کار در محیط‌های مختلف.

تست سازگاری (Compatibility Testing): بررسی عملکرد سیستم در محیط‌های مختلف (مرورگرها، سیستم‌عامل‌ها، دستگاه‌ها).

تست بازیابی (Recovery Testing): بررسی توانایی سیستم برای بازیابی از خرابی‌ها.

مزایای تست غیرعملکردی:

بهبود تجربه کاربر: اطمینان حاصل می‌کند که سیستم سریع، امن و قابل استفاده است.

کاهش ریسک: ریسک‌های مربوط به عملکرد، امنیت و پایداری را کاهش می‌دهد.

افزایش رضایت مشتری: سیستم‌هایی که به خوبی از نظر غیرعملکردی تست شده‌اند، رضایت مشتری بیشتری را به همراه دارند.

معایب تست غیرعملکردی:

پیچیدگی: طراحی و اجرای این تست‌ها می‌تواند پیچیده و نیازمند ابزارهای تخصصی باشد.

زمان‌بر و پرهزینه: به خصوص برای سیستم‌های بزرگ، می‌تواند زمان‌بر و پرهزینه باشد.

مثال:
در یک وب‌سایت تجارت الکترونیک، تست غیرعملکردی شامل موارد زیر خواهد بود:

تست کارایی: بررسی زمان بارگذاری صفحات تحت بار 1000 کاربر همزمان.

تست امنیتی: تلاش برای تزریق SQL یا حملات XSS.

تست قابلیت استفاده: مشاهده کاربران در حین استفاده از وب‌سایت برای شناسایی نقاط دشوار.

تست سازگاری: بررسی عملکرد وب‌سایت در مرورگرهای مختلف (Chrome, Firefox, Edge) و دستگاه‌های مختلف (دسکتاپ، موبایل، تبلت).

این تست‌ها تضمین می‌کنند که سیستم نه تنها کار می‌کند، بلکه به خوبی و به طور ایمن کار می‌کند.

13. تست Smoke (Smoke Testing) چیست؟

پاسخ:

تست Smoke (Smoke Testing)، که به آن Build Verification Test (BVT) نیز گفته می‌شود، یک نوع تست اولیه و سریع است که پس از هر بیلد جدید نرم‌افزار انجام می‌شود. هدف اصلی آن، تأیید این است که بیلد جدید پایدار است و عملکردهای اصلی و حیاتی سیستم به درستی کار می‌کنند. این تست به سرعت تصمیم می‌گیرد که آیا بیلد به اندازه کافی پایدار است که بتواند برای تست‌های عمیق‌تر و جامع‌تر (مانند تست رگرسیون کامل) به تیم QA منتقل شود یا خیر.

نام Smoke از تست سخت‌افزار گرفته شده است، جایی که یک قطعه جدید سخت‌افزار پس از روشن شدن، برای دود نکردن (نشانه‌ای از خرابی) بررسی می‌شود.

ویژگی‌های کلیدی تست Smoke:

سریع و سطحی: تست‌ها به سرعت اجرا می‌شوند و فقط عملکردهای اصلی را پوشش می‌دهند.

پس از هر بیلد: معمولاً پس از هر بیلد جدید نرم‌افزار انجام می‌شود.

تأیید پایداری: هدف اصلی تأیید پایداری بیلد برای ادامه تست‌های عمیق‌تر است.

توسط توسعه‌دهندگان یا QA: می‌تواند توسط توسعه‌دهندگان (پس از کامپایل) یا تیم QA (پس از دریافت بیلد) انجام شود.

مزایای تست Smoke:

شناسایی زودهنگام باگ‌های حیاتی: باگ‌های مهم و مسدودکننده را در مراحل اولیه چرخه توسعه شناسایی می‌کند.

صرفه‌جویی در زمان و منابع: از هدر رفتن زمان و منابع برای تست بیلد‌های ناپایدار جلوگیری می‌کند.

افزایش کیفیت بیلد: اطمینان حاصل می‌کند که بیلد‌های تحویل داده شده به تیم QA از کیفیت اولیه مناسبی برخوردارند.

معایب تست Smoke:

پوشش محدود: فقط عملکردهای اصلی را پوشش می‌دهد و نمی‌تواند تمام باگ‌ها را پیدا کند.

نیاز به تست‌های عمیق‌تر: نمی‌تواند جایگزین تست‌های جامع‌تر مانند تست رگرسیون یا تست سیستم شود.

مثال:
در یک برنامه وب، تست Smoke شامل موارد زیر خواهد بود:

برنامه با موفقیت نصب و راه‌اندازی می‌شود.

صفحه ورود به سیستم بارگذاری می‌شود.

کاربر می‌تواند با موفقیت وارد سیستم شود.

صفحه اصلی برنامه بارگذاری می‌شود.

یک ویژگی کلیدی (مثلاً افزودن یک آیتم به سبد خرید در یک سایت تجارت الکترونیک) به درستی کار می‌کند.

کاربر می‌تواند با موفقیت از سیستم خارج شود.

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

14. تست Sanity (Sanity Testing) چیست؟

پاسخ:

تست Sanity (Sanity Testing) یک نوع تست سریع و سطحی است که پس از دریافت یک بیلد نرم‌افزار با تغییرات کوچک (مانند رفع یک باگ خاص یا افزودن یک ویژگی کوچک) انجام می‌شود. هدف اصلی آن، تأیید این است که تغییرات اعمال شده به درستی کار می‌کنند و هیچ عملکرد موجود و مرتبطی را خراب نکرده‌اند. تست Sanity معمولاً یک زیرمجموعه از تست رگرسیون است و بر روی منطق و عملکرد تغییرات جدید و مناطق مرتبط با آنها تمرکز دارد.

ویژگی‌های کلیدی تست Sanity:

سریع و متمرکز: تست‌ها به سرعت اجرا می‌شوند و بر روی تغییرات جدید و مناطق مرتبط تمرکز دارند.

پس از تغییرات کوچک: معمولاً پس از رفع باگ‌ها یا افزودن ویژگی‌های کوچک انجام می‌شود.

تأیید منطق: هدف اصلی تأیید منطق و عملکرد تغییرات جدید است.

توسط QA: معمولاً توسط تیم QA انجام می‌شود.

تفاوت با تست Smoke:

تست Smoke: تأیید می‌کند که بیلد پایدار است و عملکردهای اصلی کار می‌کنند. (Wide & Shallow)

تست Sanity: تأیید می‌کند که تغییرات جدید به درستی کار می‌کنند و هیچ عملکرد مرتبطی را خراب نکرده‌اند. (Narrow & Deep)

مزایای تست Sanity:

صرفه‌جویی در زمان: از اجرای کامل تست رگرسیون برای تغییرات کوچک جلوگیری می‌کند.

شناسایی سریع مشکلات: مشکلات مربوط به تغییرات جدید را به سرعت شناسایی می‌کند.

افزایش اطمینان: اطمینان می‌دهد که تغییرات اعمال شده به درستی کار می‌کنند و عوارض جانبی ناخواسته‌ای ندارند.

معایب تست Sanity:

پوشش محدود: فقط بر روی تغییرات و مناطق مرتبط تمرکز دارد و نمی‌تواند تمام باگ‌ها را پیدا کند.

نمی‌تواند جایگزین تست رگرسیون کامل شود: برای تغییرات بزرگ یا بیلد‌های اصلی، تست رگرسیون کامل ضروری است.

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

تست تابع محاسبه مالیات با سناریوهایی که قبلاً باگ داشتند تا مطمئن شوید باگ رفع شده است.

تست چند سناریوی کلیدی دیگر که به تابع مالیات وابسته هستند (مثلاً ثبت سفارش با مالیات) تا مطمئن شوید هیچ عملکرد مرتبطی خراب نشده است.

اگر این تست‌ها با موفقیت انجام شوند، بیلد برای تست‌های جامع‌تر (در صورت نیاز) آماده است.

15. تست رگرسیون چیست و چرا مهم است؟

پاسخ:

تست رگرسیون (Regression Testing) یک نوع تست نرم‌افزار است که برای اطمینان از این انجام می‌شود که تغییرات جدید در کد (مانند افزودن ویژگی‌های جدید، رفع باگ‌ها، یا بهینه‌سازی کد) باعث ایجاد باگ‌های جدید در بخش‌های موجود و قبلاً کارآمد سیستم نشده‌اند. هدف اصلی تست رگرسیون، تأیید این است که عملکرد موجود سیستم پس از تغییرات، همچنان صحیح و پایدار است.

چرا تست رگرسیون مهم است؟

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

افزایش اعتماد: به توسعه‌دهندگان و تیم QA اعتماد بیشتری به کد می‌دهد، زیرا می‌دانند که تغییرات جدید باعث ایجاد عوارض جانبی ناخواسته نمی‌شوند.

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

حفظ کیفیت محصول: به حفظ کیفیت کلی محصول در طول زمان کمک می‌کند، حتی با وجود تغییرات و به‌روزرسانی‌های مکرر.

پشتیبانی از توسعه چابک (Agile Development): در متدولوژی‌های چابک که تغییرات سریع و مکرر هستند، تست رگرسیون خودکار یک ابزار حیاتی برای حفظ سرعت توسعه و اطمینان از کیفیت است.

بدون تست رگرسیون، هر تغییر جدید می‌تواند مانند یک دومینو عمل کند و باعث شکست‌های غیرمنتظره در بخش‌های دیگر سیستم شود. این امر می‌تواند منجر به یک چرخه بی‌پایان از رفع باگ‌ها و ایجاد باگ‌های جدید شود که به آن “Regression Hell” می‌گویند. بنابراین، تست رگرسیون یک فعالیت ضروری برای حفظ سلامت و پایداری نرم‌افزار در طول چرخه عمر آن است.

16. تست پذیرش (Acceptance Testing) چیست؟

پاسخ:

تست پذیرش (Acceptance Testing) یک سطح از تست نرم‌افزار است که در آن سیستم برای تأیید اینکه الزامات کسب‌وکار را برآورده می‌کند و برای تحویل به کاربران نهایی یا مشتریان آماده است، ارزیابی می‌شود. این تست معمولاً پس از تست سیستم و قبل از انتشار نهایی محصول انجام می‌شود. هدف اصلی آن، تأیید این است که سیستم از دیدگاه کسب‌وکار و کاربر، انتظارات را برآورده می‌کند.

ویژگی‌های کلیدی تست پذیرش:

تمرکز بر الزامات کسب‌وکار: تأیید می‌کند که سیستم مشکلات کسب‌وکار را حل می‌کند و نیازهای کاربران را برآورده می‌سازد.

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

سناریوهای واقعی: تست‌ها بر اساس سناریوهای واقعی کسب‌وکار و جریان‌های کاری روزمره طراحی می‌شوند.

تأیید نهایی: آخرین مرحله تست قبل از تصمیم‌گیری برای انتشار محصول.

انواع تست پذیرش:

تست پذیرش کاربر (User Acceptance Testing - UAT): که قبلاً توضیح داده شد، توسط کاربران نهایی انجام می‌شود.

تست پذیرش عملیاتی (Operational Acceptance Testing - OAT): تأیید می‌کند که سیستم برای عملیات روزانه در محیط تولید آماده است (مانند پشتیبان‌گیری، بازیابی، امنیت، نگهداری).

تست پذیرش قراردادی (Contract Acceptance Testing): تأیید می‌کند که سیستم الزامات مشخص شده در قرارداد بین توسعه‌دهنده و مشتری را برآورده می‌کند.

تست پذیرش رگولاتوری (Regulation Acceptance Testing): تأیید می‌کند که سیستم با قوانین و مقررات صنعتی یا دولتی مطابقت دارد.

مزایای تست پذیرش:

تأیید نیازهای کسب‌وکار: اطمینان حاصل می‌کند که محصول نهایی واقعاً نیازهای کسب‌وکار را برآورده می‌کند.

افزایش اعتماد: به ذینفعان اعتماد بیشتری به محصول می‌دهد.

کشف خطاهای نادیده گرفته شده: ممکن است خطاهایی را کشف کند که در مراحل قبلی تست نادیده گرفته شده‌اند، به خصوص خطاهای مربوط به جریان‌های کاری پیچیده یا سناریوهای غیرمنتظره.

کاهش ریسک انتشار: با تأیید نهایی توسط ذینفعان، ریسک انتشار محصول با باگ‌های حیاتی کاهش می‌یابد.

معایب تست پذیرش:

زمان‌بر و پرهزینه: نیاز به مشارکت ذینفعان دارد که ممکن است زمان‌بر و پرهزینه باشد.

نیاز به برنامه‌ریزی دقیق: نیازمند برنامه‌ریزی دقیق و مدیریت بازخوردها است.

مثال:
در یک سیستم مدیریت پروژه، تست پذیرش شامل موارد زیر خواهد بود:

مدیران پروژه و اعضای تیم از سیستم برای ایجاد، تخصیص و پیگیری وظایف استفاده می‌کنند.

آنها گزارش‌های پیشرفت را تولید می‌کنند و بررسی می‌کنند که آیا داده‌ها دقیق و قابل اعتماد هستند.

آنها قابلیت‌های همکاری و ارتباطی را تست می‌کنند.

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

تست پذیرش یک مرحله حیاتی برای اطمینان از رضایت مشتری و موفقیت محصول در بازار است.

17. تست آلفا (Alpha Testing) چیست؟

پاسخ:

تست آلفا (Alpha Testing) یک نوع تست پذیرش است که معمولاً توسط تیم داخلی سازمان (توسعه‌دهندگان، تست‌کنندگان یا تیم QA) در محیط توسعه یا یک محیط کنترل شده انجام می‌شود. هدف اصلی تست آلفا، شناسایی هرچه بیشتر باگ‌ها و مشکلات قبل از انتشار محصول برای تست بتا یا کاربران نهایی است. این تست بر روی شبیه‌سازی رفتار کاربر نهایی تمرکز دارد.

ویژگی‌های کلیدی تست آلفا:

توسط تیم داخلی: معمولاً توسط کارمندان شرکت توسعه‌دهنده انجام می‌شود.

محیط کنترل شده: در محیط توسعه یا یک محیط تست داخلی انجام می‌شود.

هدف: شناسایی باگ‌ها، مشکلات عملکردی و قابلیت استفاده در مراحل اولیه.

قبل از تست بتا: پیش‌نیازی برای تست بتا است.

مزایای تست آلفا:

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

کنترل بیشتر: به دلیل انجام در محیط کنترل شده، تیم توسعه کنترل بیشتری بر فرآیند تست دارد.

بازخورد سریع: بازخوردها به سرعت به تیم توسعه منتقل می‌شوند.

بهبود کیفیت محصول: به بهبود کیفیت کلی محصول قبل از رسیدن به دست کاربران واقعی کمک می‌کند.

معایب تست آلفا:

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

نیاز به منابع داخلی: نیاز به تخصیص منابع داخلی برای انجام تست دارد.

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

ورود داده‌های حسابداری مختلف.

اجرای گزارش‌های مالی.

بررسی صحت محاسبات.

تست قابلیت‌های جدید اضافه شده.

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

18. تست بتا (Beta Testing) چیست؟

پاسخ:

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

ویژگی‌های کلیدی تست بتا:

توسط کاربران واقعی: انجام تست توسط گروهی از کاربران خارج از سازمان توسعه‌دهنده.

محیط واقعی: در محیط واقعی کاربران و با داده‌های واقعی آنها انجام می‌شود.

هدف: جمع‌آوری بازخورد، شناسایی باگ‌های جدید و تأیید آمادگی محصول برای انتشار.

پس از تست آلفا: معمولاً پس از تست آلفا و رفع باگ‌های حیاتی آن انجام می‌شود.

انواع تست بتا:

Open Beta: محصول به صورت عمومی در دسترس قرار می‌گیرد و هر کسی می‌تواند در تست شرکت کند.

Closed Beta: محصول فقط برای گروه محدودی از کاربران دعوت شده در دسترس قرار می‌گیرد.

مزایای تست بتا:

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

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

افزایش رضایت مشتری: کاربران با مشارکت در فرآیند توسعه، احساس مالکیت بیشتری نسبت به محصول پیدا می‌کنند.

کاهش ریسک انتشار: با تأیید محصول توسط کاربران واقعی، ریسک انتشار محصول با باگ‌های حیاتی کاهش می‌یابد.

معایب تست بتا:

کنترل کمتر: تیم توسعه کنترل کمتری بر فرآیند تست دارد.

مدیریت بازخورد: نیاز به مدیریت دقیق بازخوردها و اولویت‌بندی رفع باگ‌ها دارد.

ریسک انتشار باگ: اگر محصول به اندازه کافی پایدار نباشد، ممکن است تجربه بدی برای کاربران بتا ایجاد کند.

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

تست بتا یک مرحله حیاتی برای اطمینان از اینکه محصول نهایی نیازهای بازار را برآورده می‌کند و تجربه کاربری مثبتی را ارائه می‌دهد.

19. تست عملکرد (Performance Testing) چیست؟

پاسخ:

تست عملکرد (Performance Testing) یک نوع تست غیرعملکردی است که برای ارزیابی سرعت، پاسخگویی، پایداری و مقیاس‌پذیری یک سیستم نرم‌افزاری تحت بار کاری خاص انجام می‌شود. هدف اصلی آن، اطمینان از این است که سیستم می‌تواند انتظارات عملکردی را برآورده کند و در شرایط واقعی به خوبی کار کند.

ویژگی‌های کلیدی تست عملکرد:

تمرکز بر سرعت و پاسخگویی: اندازه‌گیری زمان پاسخ، توان عملیاتی و استفاده از منابع.

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

شناسایی گلوگاه‌ها: کمک به شناسایی نقاط ضعف و گلوگاه‌ها در سیستم.

انواع تست عملکرد:

Load Testing (تست بار): ارزیابی عملکرد سیستم تحت بار کاری مورد انتظار. هدف آن تأیید این است که سیستم می‌تواند تعداد مشخصی از کاربران یا تراکنش‌ها را بدون کاهش عملکرد مدیریت کند.

Stress Testing (تست استرس): ارزیابی عملکرد سیستم تحت بار کاری فراتر از حد انتظار یا در شرایط نامطلوب (مانند کمبود منابع). هدف آن یافتن نقطه شکست سیستم و نحوه بازیابی آن است.

Scalability Testing (تست مقیاس‌پذیری): ارزیابی توانایی سیستم برای مقیاس‌پذیری (افزایش یا کاهش بار) و مدیریت افزایش یا کاهش تعداد کاربران یا تراکنش‌ها.

Volume Testing (تست حجم): ارزیابی عملکرد سیستم با حجم زیادی از داده‌ها در پایگاه داده یا در ورودی/خروجی.

Endurance Testing (Soak Testing) (تست پایداری): ارزیابی عملکرد سیستم برای مدت زمان طولانی تحت بار کاری مداوم. هدف آن شناسایی نشت حافظه یا سایر مشکلات عملکردی که در طول زمان ظاهر می‌شوند.

مزایای تست عملکرد:

بهبود تجربه کاربر: اطمینان حاصل می‌کند که سیستم سریع و پاسخگو است.

شناسایی گلوگاه‌ها: کمک به شناسایی نقاط ضعف در معماری یا کد.

کاهش ریسک: ریسک‌های مربوط به عملکرد ضعیف در محیط تولید را کاهش می‌دهد.

تأیید SLA: اطمینان حاصل می‌کند که سیستم الزامات توافق‌نامه سطح خدمات (SLA) را برآورده می‌کند.

معایب تست عملکرد:

پیچیدگی: طراحی و اجرای آن می‌تواند پیچیده و نیازمند ابزارهای تخصصی باشد.

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

مثال:
در یک وب‌سایت تجارت الکترونیک، تست عملکرد شامل موارد زیر خواهد بود:

تست بار: شبیه‌سازی 1000 کاربر همزمان که در حال مرور محصولات، افزودن به سبد خرید و پرداخت هستند و اندازه‌گیری زمان پاسخگویی سیستم.

تست استرس: افزایش تعداد کاربران به 5000 نفر برای مشاهده اینکه سیستم در چه نقطه‌ای شروع به کند شدن یا از کار افتادن می‌کند.

تست پایداری: اجرای سیستم تحت بار متوسط برای 24 ساعت متوالی برای شناسایی نشت حافظه یا سایر مشکلات بلندمدت.

تست عملکرد برای اطمینان از اینکه سیستم می‌تواند حجم کاری مورد انتظار را به طور مؤثر و کارآمد مدیریت کند، حیاتی است.

20. تست امنیتی (Security Testing) چیست؟

پاسخ:

تست امنیتی (Security Testing) یک نوع تست غیرعملکردی است که برای شناسایی آسیب‌پذیری‌ها، نقاط ضعف و تهدیدات امنیتی در یک سیستم نرم‌افزاری انجام می‌شود. هدف اصلی آن، اطمینان از این است که سیستم در برابر حملات مخرب، دسترسی غیرمجاز، از دست دادن داده‌ها و سایر تهدیدات امنیتی مقاوم است.

ویژگی‌های کلیدی تست امنیتی:

شناسایی آسیب‌پذیری‌ها: یافتن نقاط ضعف در سیستم که می‌توانند مورد سوءاستفاده قرار گیرند.

حفاظت از داده‌ها: اطمینان از محرمانه بودن، یکپارچگی و در دسترس بودن داده‌ها.

انطباق با استانداردها: بررسی انطباق با استانداردهای امنیتی و مقررات مربوطه.

انواع تست امنیتی:

Vulnerability Scanning (اسکن آسیب‌پذیری): استفاده از ابزارهای خودکار برای اسکن سیستم و شناسایی آسیب‌پذیری‌های شناخته شده.

Security Scanning (اسکن امنیتی): اسکن سیستم برای شناسایی نقاط ضعف شبکه و سیستم.

Penetration Testing (تست نفوذ): شبیه‌سازی حملات واقعی توسط متخصصان امنیتی (هکرهای اخلاقی) برای یافتن آسیب‌پذیری‌ها.

Risk Assessment (ارزیابی ریسک): شناسایی، ارزیابی و اولویت‌بندی ریسک‌های امنیتی.

Security Auditing (ممیزی امنیتی): بررسی کد منبع، پیکربندی‌ها و لاگ‌ها برای شناسایی نقاط ضعف امنیتی.

Ethical Hacking (هک اخلاقی): استفاده از تکنیک‌های هک برای یافتن آسیب‌پذیری‌ها به صورت قانونی.

مزایای تست امنیتی:

حفاظت از داده‌ها: محافظت از اطلاعات حساس کاربران و کسب‌وکار.

کاهش ریسک: کاهش ریسک حملات سایبری، نقض داده‌ها و از دست دادن اعتبار.

انطباق با مقررات: کمک به رعایت قوانین و مقررات امنیتی (مانند GDPR, HIPAA).

افزایش اعتماد: افزایش اعتماد کاربران و مشتریان به سیستم.

معایب تست امنیتی:

پیچیدگی: می‌تواند بسیار پیچیده و نیازمند دانش تخصصی باشد.

هزینه: ممکن است پرهزینه باشد، به خصوص برای تست نفوذ.

تکامل تهدیدات: تهدیدات امنیتی دائماً در حال تکامل هستند، بنابراین تست امنیتی یک فرآیند مداوم است.

مثال:
در یک برنامه وب، تست امنیتی شامل موارد زیر خواهد بود:

تست تزریق SQL: تلاش برای تزریق کدهای SQL مخرب به فیلدهای ورودی برای دسترسی غیرمجاز به پایگاه داده.

تست XSS (Cross-Site Scripting): تلاش برای تزریق اسکریپت‌های مخرب به صفحات وب برای سرقت اطلاعات کاربر.

تست احراز هویت و مجوز: بررسی اینکه آیا کاربران می‌توانند به اطلاعات یا عملکردهایی که مجاز به دسترسی به آنها نیستند، دسترسی پیدا کنند.

تست مدیریت نشست: بررسی آسیب‌پذیری‌ها در نحوه مدیریت نشست‌های کاربر.

تست رمزنگاری: اطمینان از اینکه داده‌های حساس به درستی رمزنگاری شده‌اند.

تست امنیتی یک جزء حیاتی از فرآیند توسعه نرم‌افزار است تا اطمینان حاصل شود که سیستم در برابر تهدیدات سایبری محافظت می‌شود.

21. تست قابلیت استفاده (Usability Testing) چیست؟

پاسخ:

تست قابلیت استفاده (Usability Testing) یک نوع تست غیرعملکردی است که برای ارزیابی سهولت استفاده، یادگیری، کارایی و رضایت کاربر از یک سیستم نرم‌افزاری انجام می‌شود. هدف اصلی آن، اطمینان از این است که سیستم برای کاربران نهایی شهودی، کارآمد و دلپذیر است.

ویژگی‌های کلیدی تست قابلیت استفاده:

تمرکز بر تجربه کاربر: ارزیابی اینکه کاربران چقدر راحت می‌توانند وظایف خود را با سیستم انجام دهند.

با کاربران واقعی: معمولاً با مشارکت کاربران واقعی انجام می‌شود.

مشاهده رفتار کاربر: مشاهده و تحلیل نحوه تعامل کاربران با سیستم.

مزایای تست قابلیت استفاده:

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

افزایش رضایت مشتری: کاربران از محصولاتی که نیازهای آنها را به خوبی برآورده می‌کنند و استفاده از آنها آسان است، راضی‌تر هستند.

کاهش هزینه‌های پشتیبانی: سیستم‌های با قابلیت استفاده بالا نیاز به پشتیبانی کمتری دارند.

افزایش بهره‌وری: کاربران می‌توانند وظایف خود را سریع‌تر و با خطای کمتری انجام دهند.

معایب تست قابلیت استفاده:

زمان‌بر و پرهزینه: نیاز به برنامه‌ریزی دقیق، استخدام شرکت‌کنندگان و تحلیل داده‌ها دارد.

نیاز به تخصص: برای طراحی و اجرای مؤثر، نیاز به متخصصان UX/UI دارد.

مثال:
در یک برنامه موبایل برای سفارش غذا، تست قابلیت استفاده شامل موارد زیر خواهد بود:

مشاهده کاربران در حین تلاش برای یافتن یک رستوران خاص، افزودن غذا به سبد خرید و تکمیل فرآیند سفارش.

اندازه‌گیری زمان لازم برای انجام هر وظیفه.

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

شناسایی نقاطی که کاربران در آنها سردرگم می‌شوند یا با مشکل مواجه می‌شوند.

این تست به طراحان و توسعه‌دهندگان کمک می‌کند تا رابط کاربری را بهبود بخشند و تجربه کاربری را بهینه کنند.

22. تست قابلیت اطمینان (Reliability Testing) چیست؟

پاسخ:

تست قابلیت اطمینان (Reliability Testing) یک نوع تست غیرعملکردی است که برای ارزیابی توانایی یک سیستم نرم‌افزاری برای انجام عملکرد مورد نظر خود بدون شکست برای مدت زمان مشخص و تحت شرایط مشخص انجام می‌شود. هدف اصلی آن، اطمینان از این است که سیستم پایدار، قابل اعتماد و بدون خطا در طول زمان عمل می‌کند.

ویژگی‌های کلیدی تست قابلیت اطمینان:

تمرکز بر پایداری: ارزیابی اینکه سیستم چقدر می‌تواند بدون خطا کار کند.

تست بلندمدت: معمولاً برای مدت زمان طولانی انجام می‌شود.

شبیه‌سازی شرایط واقعی: سیستم تحت شرایط کاری واقعی یا شبیه‌سازی شده تست می‌شود.

معیارهای قابلیت اطمینان:

Mean Time Between Failures (MTBF): میانگین زمان بین دو شکست متوالی. هرچه MTBF بیشتر باشد، قابلیت اطمینان بالاتر است.

Mean Time To Repair (MTTR): میانگین زمان لازم برای تعمیر و بازیابی سیستم پس از یک شکست. هرچه MTTR کمتر باشد، قابلیت نگهداری بالاتر است.

Rate of Occurrence of Failures (ROCOF): نرخ وقوع شکست‌ها.

انواع تست قابلیت اطمینان:

Feature Testing: تست هر ویژگی به صورت جداگانه برای اطمینان از قابلیت اطمینان آن.

Regression Testing: اجرای مجدد تست‌ها پس از تغییرات برای اطمینان از عدم معرفی باگ‌های جدید.

Load Testing: تست سیستم تحت بار برای اطمینان از پایداری آن در شرایط بار بالا.

مزایای تست قابلیت اطمینان:

افزایش اعتماد: به کاربران و ذینفعان اعتماد بیشتری به پایداری سیستم می‌دهد.

کاهش خرابی‌ها: کمک به شناسایی و رفع نقاط ضعف که می‌توانند منجر به خرابی سیستم شوند.

بهبود تجربه کاربر: سیستم‌های قابل اعتماد تجربه کاربری بهتری را ارائه می‌دهند.

معایب تست قابلیت اطمینان:

زمان‌بر: نیاز به اجرای تست‌ها برای مدت زمان طولانی دارد.

پیچیدگی: طراحی سناریوهای تست واقعی و تحلیل نتایج می‌تواند پیچیده باشد.

مثال:
در یک سیستم نظارت تصویری (CCTV) که باید 24/7 کار کند، تست قابلیت اطمینان شامل موارد زیر خواهد بود:

اجرای سیستم به صورت مداوم برای چندین هفته یا ماه.

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

بررسی اینکه آیا سیستم به طور مداوم تصاویر را ضبط و ذخیره می‌کند.

اندازه‌گیری MTBF و MTTR برای شناسایی نقاط ضعف.

این تست اطمینان حاصل می‌کند که سیستم می‌تواند به طور مداوم و بدون خطا در طول زمان عمل کند.

23. تست سازگاری (Compatibility Testing) چیست؟

پاسخ:

تست سازگاری (Compatibility Testing) یک نوع تست غیرعملکردی است که برای ارزیابی عملکرد یک سیستم نرم‌افزاری در محیط‌های مختلف (مانند سیستم‌عامل‌ها، مرورگرها، دستگاه‌ها، پایگاه‌های داده، شبکه‌ها و نسخه‌های سخت‌افزاری) انجام می‌شود. هدف اصلی آن، اطمینان از این است که سیستم در تمام محیط‌های مورد نظر به درستی و بدون مشکل کار می‌کند.

ویژگی‌های کلیدی تست سازگاری:

تمرکز بر محیط‌ها: بررسی عملکرد سیستم در پلتفرم‌ها و پیکربندی‌های مختلف.

شناسایی ناسازگاری‌ها: یافتن مشکلاتی که فقط در محیط‌های خاصی ظاهر می‌شوند.

تست Black-box: معمولاً به عنوان یک نوع تست جعبه سیاه انجام می‌شود.

انواع تست سازگاری:

Backward Compatibility Testing: بررسی سازگاری با نسخه‌های قدیمی‌تر نرم‌افزار یا سخت‌افزار.

Forward Compatibility Testing: بررسی سازگاری با نسخه‌های جدیدتر نرم‌افزار یا سخت‌افزار.

Browser Compatibility Testing: تست عملکرد برنامه وب در مرورگرهای مختلف (Chrome, Firefox, Edge, Safari).

Operating System Compatibility Testing: تست عملکرد برنامه در سیستم‌عامل‌های مختلف (Windows, macOS, Linux, Android, iOS).

Device Compatibility Testing: تست عملکرد برنامه در دستگاه‌های مختلف (دسکتاپ، لپ‌تاپ، تبلت، موبایل) با اندازه‌های صفحه نمایش و رزولوشن‌های متفاوت.

Network Compatibility Testing: تست عملکرد برنامه در شرایط مختلف شبکه (سرعت بالا، سرعت پایین، Wi-Fi, 4G, 5G).

Database Compatibility Testing: تست سازگاری با نسخه‌های مختلف پایگاه داده (SQL Server, MySQL, PostgreSQL).

مزایای تست سازگاری:

افزایش دسترسی: اطمینان از اینکه محصول برای طیف وسیعی از کاربران و محیط‌ها قابل دسترسی است.

افزایش رضایت مشتری: کاربران می‌توانند از محصول در محیط دلخواه خود استفاده کنند.

کاهش ریسک: کاهش ریسک مشکلات پس از انتشار که ناشی از ناسازگاری محیطی هستند.

معایب تست سازگاری:

زمان‌بر و پرهزینه: نیاز به تست در محیط‌های متعدد دارد.

نیاز به منابع: ممکن است به سخت‌افزارها و نرم‌افزارهای مختلفی نیاز داشته باشد.

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

در ویندوز 10، ویندوز 11 و macOS.

با مرورگرهای Chrome، Firefox و Edge.

با پایگاه داده SQL Server 2019 و PostgreSQL 14.

در دستگاه‌های دسکتاپ و لپ‌تاپ با رزولوشن‌های مختلف.

این تست اطمینان حاصل می‌کند که نرم‌افزار در تمام این محیط‌ها به درستی کار می‌کند و تجربه کاربری یکسانی را ارائه می‌دهد.

24. تست قابلیت نگهداری (Maintainability Testing) چیست؟

پاسخ:

تست قابلیت نگهداری (Maintainability Testing) یک نوع تست غیرعملکردی است که برای ارزیابی سهولت اصلاح، به‌روزرسانی، گسترش و عیب‌یابی یک سیستم نرم‌افزاری انجام می‌شود. هدف اصلی آن، اطمینان از این است که کد و معماری سیستم به گونه‌ای طراحی شده‌اند که تغییرات آینده را به راحتی و با حداقل ریسک امکان‌پذیر سازند.

ویژگی‌های کلیدی تست قابلیت نگهداری:

تمرکز بر کد و معماری: ارزیابی کیفیت داخلی کد و طراحی سیستم.

توسط توسعه‌دهندگان و QA: معمولاً توسط توسعه‌دهندگان (در حین کدنویسی) و تیم QA (در حین بررسی) انجام می‌شود.

شناسایی پیچیدگی‌ها: یافتن بخش‌هایی از کد که نگهداری آنها دشوار است.

معیارهای قابلیت نگهداری:

Cyclomatic Complexity: اندازه‌گیری پیچیدگی منطقی یک برنامه.

Code Duplication: میزان تکرار کد.

Coupling and Cohesion: میزان وابستگی بین ماژول‌ها و میزان تمرکز وظایف یک ماژول.

Testability: سهولت نوشتن تست برای کد.

Readability: سهولت خواندن و درک کد.

مزایای تست قابلیت نگهداری:

کاهش هزینه‌های بلندمدت: سیستم‌های با قابلیت نگهداری بالا، هزینه‌های کمتری برای اصلاح و به‌روزرسانی در طول زمان دارند.

افزایش سرعت توسعه: تغییرات را می‌توان سریع‌تر و با ریسک کمتری اعمال کرد.

بهبود کیفیت کد: منجر به کدهای تمیزتر، ماژولارتر و قابل فهم‌تر می‌شود.

افزایش طول عمر سیستم: سیستم می‌تواند برای مدت زمان طولانی‌تری مورد استفاده قرار گیرد.

معایب تست قابلیت نگهداری:

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

زمان‌بر: تحلیل و بهبود قابلیت نگهداری می‌تواند زمان‌بر باشد.

مثال:
در یک پروژه توسعه نرم‌افزار، تست قابلیت نگهداری شامل موارد زیر خواهد بود:

بررسی کد منبع برای شناسایی متدهای طولانی، کلاس‌های بزرگ یا توابع با پیچیدگی سیکلوماتیک بالا.

استفاده از ابزارهای تحلیل کد استاتیک (مانند SonarQube) برای شناسایی بوی کد (Code Smells) و نقاط ضعف.

بررسی مستندات کد و معماری برای اطمینان از وضوح و کامل بودن آنها.

تلاش برای اعمال یک تغییر کوچک در یک بخش از کد و اندازه‌گیری زمان و تلاش لازم برای انجام آن.

این تست به تیم توسعه کمک می‌کند تا کدی بنویسند که نه تنها کار می‌کند، بلکه به راحتی قابل نگهداری و توسعه در آینده است.

25. تست قابلیت حمل (Portability Testing) چیست؟

پاسخ:

تست قابلیت حمل (Portability Testing) یک نوع تست غیرعملکردی است که برای ارزیابی سهولت انتقال یک سیستم نرم‌افزاری از یک محیط (سخت‌افزار، سیستم‌عامل، پلتفرم) به محیط دیگر انجام می‌شود. هدف اصلی آن، اطمینان از این است که سیستم می‌تواند بدون تغییرات عمده یا با حداقل تلاش، در محیط‌های مختلف عمل کند.

ویژگی‌های کلیدی تست قابلیت حمل:

تمرکز بر انتقال‌پذیری: ارزیابی اینکه سیستم چقدر مستقل از محیط است.

تست در محیط‌های مختلف: سیستم در پلتفرم‌ها و پیکربندی‌های مختلف تست می‌شود.

شناسایی وابستگی‌ها: یافتن وابستگی‌های خاص به یک محیط که مانع از انتقال می‌شوند.

مزایای تست قابلیت حمل:

افزایش بازار: محصول می‌تواند در بازارهای بیشتری با پلتفرم‌های مختلف عرضه شود.

کاهش هزینه‌ها: نیاز به توسعه مجدد برای هر پلتفرم جدید را کاهش می‌دهد.

افزایش انعطاف‌پذیری: سیستم می‌تواند به راحتی به محیط‌های جدید منتقل شود.

کاهش ریسک: ریسک‌های مربوط به وابستگی به یک پلتفرم خاص را کاهش می‌دهد.

معایب تست قابلیت حمل:

پیچیدگی: طراحی و اجرای آن می‌تواند پیچیده باشد، به خصوص برای سیستم‌های بزرگ.

زمان‌بر: نیاز به تست در محیط‌های متعدد دارد.

نیاز به منابع: ممکن است به سخت‌افزارها و نرم‌افزارهای مختلفی نیاز داشته باشد.

مثال:
یک شرکت توسعه‌دهنده بازی‌های ویدیویی، بازی خود را برای ویندوز، macOS و لینوکس منتشر می‌کند. تست قابلیت حمل شامل موارد زیر خواهد بود:

نصب و اجرای بازی در هر سه سیستم‌عامل.

بررسی عملکرد، گرافیک و صدا در هر محیط.

اطمینان از اینکه فایل‌های ذخیره شده بازی بین پلتفرم‌ها قابل انتقال هستند.

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

این تست اطمینان حاصل می‌کند که محصول می‌تواند به راحتی به محیط‌های مختلف منتقل شود و تجربه کاربری یکسانی را ارائه دهد.

26. تست نصب (Installation Testing) چیست؟

پاسخ:

تست نصب (Installation Testing) یک نوع تست غیرعملکردی است که برای ارزیابی موفقیت‌آمیز بودن نصب و راه‌اندازی یک سیستم نرم‌افزاری در محیط‌های مختلف انجام می‌شود. هدف اصلی آن، اطمینان از این است که فرآیند نصب بدون خطا انجام می‌شود و نرم‌افزار پس از نصب به درستی کار می‌کند.

ویژگی‌های کلیدی تست نصب:

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

تست در محیط‌های مختلف: سیستم در پلتفرم‌ها و پیکربندی‌های مختلف تست می‌شود.

تأیید عملکرد پس از نصب: اطمینان از اینکه نرم‌افزار پس از نصب به درستی کار می‌کند.

انواع تست نصب:

Full Installation: تست نصب کامل نرم‌افزار.

Partial Installation: تست نصب جزئی یا سفارشی.

Upgrade/Downgrade Installation: تست ارتقاء از نسخه قدیمی‌تر یا بازگشت به نسخه قدیمی‌تر.

Uninstallation Testing: تست فرآیند حذف نرم‌افزار و اطمینان از حذف کامل فایل‌ها و رجیستری.

مزایای تست نصب:

تجربه کاربری اولیه: اطمینان از اینکه اولین تجربه کاربر با محصول مثبت است.

کاهش هزینه‌های پشتیبانی: نصب آسان و بدون خطا نیاز به پشتیبانی کمتری دارد.

افزایش رضایت مشتری: کاربران از محصولاتی که به راحتی نصب می‌شوند، راضی‌تر هستند.

معایب تست نصب:

نیاز به محیط‌های مختلف: نیاز به تست در پیکربندی‌های سخت‌افزاری و نرم‌افزاری مختلف دارد.

زمان‌بر: ممکن است برای پوشش تمام سناریوهای نصب زمان‌بر باشد.

مثال:
یک شرکت توسعه‌دهنده نرم‌افزار دسکتاپ، فرآیند نصب نرم‌افزار خود را تست می‌کند:

نصب نرم‌افزار در ویندوز 10 و ویندوز 11.

تست نصب با گزینه‌های پیش‌فرض و سفارشی.

تست ارتقاء از نسخه قبلی نرم‌افزار.

تست حذف نرم‌افزار و اطمینان از اینکه هیچ فایل یا ورودی رجیستری باقی نمی‌ماند.

پس از هر نصب، نرم‌افزار را اجرا می‌کند تا مطمئن شود به درستی کار می‌کند.

این تست اطمینان حاصل می‌کند که کاربران می‌توانند به راحتی نرم‌افزار را نصب و راه‌اندازی کنند.

27. تست بازیابی (Recovery Testing) چیست؟

پاسخ:

تست بازیابی (Recovery Testing) یک نوع تست غیرعملکردی است که برای ارزیابی توانایی یک سیستم نرم‌افزاری برای بازیابی از خرابی‌ها، خطاها یا از دست دادن داده‌ها انجام می‌شود. هدف اصلی آن، اطمینان از این است که سیستم می‌تواند به طور مؤثر و کارآمد پس از یک رویداد نامطلوب به حالت عادی بازگردد و یکپارچگی داده‌ها حفظ شود.

ویژگی‌های کلیدی تست بازیابی:

تمرکز بر بازیابی: ارزیابی سرعت و کامل بودن فرآیند بازیابی.

شبیه‌سازی خرابی‌ها: ایجاد عمدی شرایط خرابی (مانند قطع برق، خرابی شبکه، خطای پایگاه داده).

تأیید یکپارچگی داده‌ها: اطمینان از اینکه داده‌ها پس از بازیابی از بین نرفته یا خراب نشده‌اند.

مزایای تست بازیابی:

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

کاهش از دست دادن داده‌ها: محافظت از اطلاعات حساس و حیاتی.

افزایش اعتماد: به کاربران و ذینفعان اعتماد بیشتری به قابلیت اطمینان سیستم می‌دهد.

کاهش زمان توقف (Downtime): کمک به کاهش زمان لازم برای بازگرداندن سیستم به حالت عملیاتی.

معایب تست بازیابی:

پیچیدگی: طراحی سناریوهای خرابی واقعی و شبیه‌سازی آنها می‌تواند پیچیده باشد.

ریسک: ایجاد عمدی خرابی در سیستم ممکن است ریسک‌هایی را به همراه داشته باشد.

زمان‌بر: فرآیند بازیابی و تأیید آن می‌تواند زمان‌بر باشد.

مثال:
در یک سیستم بانکداری آنلاین، تست بازیابی شامل موارد زیر خواهد بود:

شبیه‌سازی قطع برق ناگهانی در حین انجام تراکنش‌ها.

شبیه‌سازی خرابی پایگاه داده.

شبیه‌سازی قطع شبکه.

پس از هر خرابی، سیستم را بازیابی می‌کند و بررسی می‌کند که آیا تمام تراکنش‌ها به درستی ثبت شده‌اند و هیچ داده‌ای از بین نرفته است.

اندازه‌گیری زمان لازم برای بازیابی کامل سیستم.

این تست اطمینان حاصل می‌کند که سیستم می‌تواند به طور مؤثر از رویدادهای نامطلوب بازیابی شود و خدمات خود را به سرعت از سر بگیرد.

28. تست پیمایش (Exploratory Testing) چیست؟

پاسخ:

تست پیمایش (Exploratory Testing) یک رویکرد تست نرم‌افزار است که در آن طراحی تست و اجرای تست به صورت همزمان انجام می‌شود. به جای پیروی از یک برنامه تست از پیش تعریف شده، تستر به صورت پویا سیستم را کاوش می‌کند، طراحی تست‌ها را بر اساس یافته‌های خود تغییر می‌دهد و به دنبال کشف باگ‌ها و مشکلات جدید است. این روش بیشتر بر مهارت، تجربه و خلاقیت تستر تکیه دارد.

ویژگی‌های کلیدی تست پیمایش:

همزمانی طراحی و اجرا: تستر همزمان با تست، طراحی تست‌ها را نیز انجام می‌دهد.

تمرکز بر کشف: هدف اصلی کشف باگ‌ها و مشکلات جدید است.

انعطاف‌پذیری: تستر می‌تواند مسیر تست را بر اساس یافته‌های خود تغییر دهد.

نیاز به تخصص: نیاز به تستران با تجربه و خلاق دارد.

مزایای تست پیمایش:

کشف سریع باگ‌ها: می‌تواند باگ‌های مهم و غیرمنتظره را به سرعت کشف کند.

پوشش مناطق غیرمنتظره: می‌تواند مناطقی از سیستم را پوشش دهد که ممکن است در تست‌های سنتی نادیده گرفته شوند.

بازخورد سریع: بازخورد فوری در مورد کیفیت محصول ارائه می‌دهد.

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

معایب تست پیمایش:

عدم مستندسازی: ممکن است مستندسازی کافی از تست‌ها وجود نداشته باشد.

نیاز به تخصص: برای مؤثر بودن، نیاز به تستران با تجربه و مهارت بالا دارد.

پوشش نامشخص: تعیین میزان پوشش تست می‌تواند دشوار باشد.

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

تلاش برای باز کردن انواع مختلف فایل‌های تصویری.

اعمال فیلترها و افکت‌های مختلف به صورت تصادفی.

تغییر اندازه تصاویر به صورت غیرمعمول.

ذخیره تصاویر با فرمت‌های مختلف.

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

این تست به تستر اجازه می‌دهد تا به صورت آزادانه سیستم را کاوش کند و باگ‌هایی را پیدا کند که ممکن است در تست‌های ساختاریافته‌تر نادیده گرفته شوند.

29. تست مبتنی بر ریسک (Risk-Based Testing) چیست؟

پاسخ:

تست مبتنی بر ریسک (Risk-Based Testing - RBT) یک رویکرد تست نرم‌افزار است که در آن تلاش‌های تست بر اساس ریسک‌های مرتبط با هر ویژگی یا عملکرد سیستم اولویت‌بندی و متمرکز می‌شوند. هدف اصلی آن، بهینه‌سازی فرآیند تست با تمرکز بر مناطقی است که بیشترین احتمال وقوع خطا را دارند یا در صورت وقوع خطا، بیشترین تأثیر منفی را بر کسب‌وکار خواهند داشت.

ویژگی‌های کلیدی تست مبتنی بر ریسک:

اولویت‌بندی بر اساس ریسک: تست‌ها بر اساس سطح ریسک (احتمال وقوع خطا و تأثیر آن) اولویت‌بندی می‌شوند.

بهینه‌سازی منابع: منابع تست به صورت کارآمدتری به مناطق پرخطر اختصاص داده می‌شوند.

مشارکت ذینفعان: نیاز به مشارکت ذینفعان برای شناسایی و ارزیابی ریسک‌ها دارد.

مراحل تست مبتنی بر ریسک:

شناسایی ریسک: شناسایی تمام ریسک‌های احتمالی مرتبط با نرم‌افزار (مانند خطاهای عملکردی، امنیتی، کارایی).

تحلیل ریسک: ارزیابی احتمال وقوع هر ریسک و تأثیر آن بر کسب‌وکار.

اولویت‌بندی ریسک: رتبه‌بندی ریسک‌ها بر اساس سطح اهمیت.

طراحی و اجرای تست: طراحی و اجرای تست‌ها با تمرکز بر ریسک‌های با اولویت بالا.

نظارت و کنترل ریسک: نظارت مداوم بر ریسک‌ها و به‌روزرسانی برنامه تست.

مزایای تست مبتنی بر ریسک:

بهینه‌سازی تلاش تست: تمرکز بر مهم‌ترین مناطق سیستم، که منجر به کشف باگ‌های حیاتی‌تر می‌شود.

کاهش ریسک کلی پروژه: با مدیریت فعال ریسک‌ها، احتمال شکست پروژه کاهش می‌یابد.

افزایش کارایی: منابع تست به صورت مؤثرتری استفاده می‌شوند.

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

معایب تست مبتنی بر ریسک:

نیاز به تخصص: شناسایی و تحلیل ریسک‌ها نیاز به تجربه و دانش دارد.

زمان‌بر: فرآیند اولیه شناسایی و تحلیل ریسک می‌تواند زمان‌بر باشد.

پوشش محدود: ممکن است مناطق کم‌ریسک‌تر کمتر تست شوند.

مثال:
در یک سیستم بانکداری آنلاین، تیم تست از رویکرد مبتنی بر ریسک استفاده می‌کند:

ریسک بالا: تراکنش‌های مالی (انتقال وجه، پرداخت قبوض) - احتمال وقوع خطا در این بخش‌ها می‌تواند منجر به از دست دادن پول مشتری و آسیب جدی به اعتبار بانک شود. بنابراین، این بخش‌ها بیشترین تلاش تست را دریافت می‌کنند.

ریسک متوسط: مدیریت پروفایل کاربر (تغییر آدرس، به‌روزرسانی اطلاعات تماس) - خطاهای اینجا کمتر حیاتی هستند اما همچنان مهم.

ریسک پایین: صفحات اطلاعاتی (مانند صفحه درباره ما یا تماس با ما) - خطاهای اینجا تأثیر کمی بر کسب‌وکار دارند و کمتر تست می‌شوند.

این رویکرد تضمین می‌کند که مهم‌ترین بخش‌های سیستم به طور کامل تست می‌شوند و ریسک‌های حیاتی به حداقل می‌رسند.

30. تست مبتنی بر مدل (Model-Based Testing) چیست؟

پاسخ:

تست مبتنی بر مدل (Model-Based Testing - MBT) یک رویکرد تست نرم‌افزار است که در آن تست‌ها از یک مدل (نمایش انتزاعی) از رفتار سیستم تحت تست (SUT) تولید می‌شوند. این مدل می‌تواند رفتار عملکردی، ساختار، یا جنبه‌های دیگر سیستم را توصیف کند. هدف اصلی MBT، خودکارسازی طراحی تست و تولید موارد تست با کیفیت بالا از مدل‌ها است.

ویژگی‌های کلیدی تست مبتنی بر مدل:

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

خودکارسازی: فرآیند تولید تست می‌تواند به صورت خودکار انجام شود.

پوشش جامع: می‌تواند به پوشش جامع‌تری از رفتار سیستم منجر شود.

مراحل تست مبتنی بر مدل:

ساخت مدل: ایجاد یک مدل از رفتار سیستم با استفاده از ابزارهای مدل‌سازی (مانند UML State Machines, Finite State Machines, Petri Nets).

تولید تست: تولید موارد تست (Test Cases) از مدل با استفاده از الگوریتم‌ها و ابزارهای خاص.

اجرای تست: اجرای موارد تست تولید شده بر روی SUT.

تحلیل نتایج: مقایسه خروجی واقعی با خروجی مورد انتظار از مدل.

مزایای تست مبتنی بر مدل:

افزایش کارایی: خودکارسازی طراحی و تولید تست، زمان و تلاش را کاهش می‌دهد.

پوشش بهتر: می‌تواند به پوشش جامع‌تری از رفتار سیستم منجر شود.

کشف باگ‌های پیچیده: قادر به کشف باگ‌هایی است که در تست‌های دستی ممکن است نادیده گرفته شوند.

بهبود کیفیت مدل: فرآیند تست به بهبود کیفیت و دقت مدل نیز کمک می‌کند.

معایب تست مبتنی بر مدل:

نیاز به تخصص: ساخت مدل‌های با کیفیت نیاز به تخصص در مدل‌سازی و ابزارهای مربوطه دارد.

هزینه اولیه: سرمایه‌گذاری اولیه برای ابزارها و آموزش می‌تواند بالا باشد.

پیچیدگی: برای سیستم‌های بسیار پیچیده، ساخت مدل می‌تواند دشوار باشد.

مثال:
فرض کنید در حال تست یک دستگاه خودپرداز (ATM) هستید. می‌توانید یک مدل از رفتار ATM ایجاد کنید که شامل حالت‌های مختلف (مانند آماده به کار، وارد کردن کارت، وارد کردن رمز، انتخاب عملیات، برداشت وجه، نمایش موجودی) و انتقال بین آنها باشد. سپس، ابزارهای MBT می‌توانند سناریوهای تست را از این مدل تولید کنند، مانند:

وارد کردن کارت -> وارد کردن رمز صحیح -> انتخاب برداشت وجه -> وارد کردن مبلغ -> برداشت وجه.

وارد کردن کارت -> وارد کردن رمز اشتباه (سه بار) -> مسدود شدن کارت.

این رویکرد به تست‌کنندگان کمک می‌کند تا موارد تست جامع و متنوعی را تولید کنند و از پوشش مناسب اطمینان حاصل کنند.

31. تست جهش (Mutation Testing) چیست؟

پاسخ:

تست جهش (Mutation Testing) یک تکنیک تست نرم‌افزار است که برای ارزیابی کیفیت و اثربخشی مجموعه‌ای از تست‌های موجود (Test Suite) استفاده می‌شود. هدف اصلی آن، سنجش توانایی تست‌ها در شناسایی تغییرات کوچک و عمدی (جهش‌ها) در کد منبع است. این تکنیک فرض می‌کند که اگر تست‌ها بتوانند این تغییرات کوچک را شناسایی کنند، پس به احتمال زیاد قادر به شناسایی باگ‌های واقعی نیز خواهند بود.

ویژگی‌های کلیدی تست جهش:

ارزیابی کیفیت تست: به جای یافتن باگ در کد، کیفیت تست‌ها را ارزیابی می‌کند.

تغییرات کوچک در کد: جهش‌های کوچک و معنایی در کد منبع ایجاد می‌شود.

کشتن جهش‌ها: تست‌های خوب باید قادر به شناسایی (کشتن) این جهش‌ها باشند.

مراحل تست جهش:

ایجاد جهش‌ها: تغییرات کوچک و معنایی در کد منبع اصلی ایجاد می‌شود. این تغییرات می‌توانند شامل تغییر عملگرها (مثلاً + به -)، تغییر ثابت‌ها، حذف خطوط کد و غیره باشند. هر تغییر یک «جهش‌یافته» (Mutant) ایجاد می‌کند.
مثال:
int sum = a + b; // اصلی int sum = a - b; // جهش‌یافته

اجرای تست‌ها: مجموعه تست‌های موجود بر روی هر جهش‌یافته اجرا می‌شود.

کشتن جهش‌یافته: اگر یک تست در مجموعه تست، در برابر جهش‌یافته شکست بخورد (یعنی خروجی جهش‌یافته با خروجی اصلی متفاوت باشد)، آن جهش‌یافته «کشته» می‌شود. این نشان می‌دهد که تست به اندازه کافی قوی است تا این تغییر را شناسایی کند.

جهش‌یافته‌های زنده: اگر یک جهش‌یافته توسط هیچ تستی کشته نشود، به آن «جهش‌یافته زنده» (Live Mutant) گفته می‌شود. این نشان می‌دهد که مجموعه تست ضعیف است و باید تست‌های جدیدی اضافه شود تا این جهش‌یافته کشته شود.

محاسبه امتیاز جهش (Mutation Score): نسبت جهش‌یافته‌های کشته شده به کل جهش‌یافته‌ها. امتیاز بالاتر نشان‌دهنده کیفیت بهتر مجموعه تست است.

مزایای تست جهش:

ارزیابی دقیق کیفیت تست: دیدگاه عمیق‌تری نسبت به پوشش کد و اثربخشی تست‌ها ارائه می‌دهد.

شناسایی تست‌های ضعیف: به شناسایی تست‌هایی کمک می‌کند که قادر به کشف باگ‌های خاص نیستند.

بهبود مجموعه تست: به توسعه‌دهندگان کمک می‌کند تا تست‌های قوی‌تر و مؤثرتری بنویسند.

کشف باگ‌های واقعی: گاهی اوقات، جهش‌یافته‌های زنده می‌توانند به کشف باگ‌های واقعی در کد اصلی منجر شوند.

معایب تست جهش:

هزینه محاسباتی بالا: تولید و اجرای تست‌ها بر روی تعداد زیادی جهش‌یافته می‌تواند بسیار زمان‌بر و پرهزینه باشد.

نیاز به ابزارهای تخصصی: نیاز به ابزارهای خودکار برای تولید جهش‌ها و اجرای تست‌ها دارد.

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

مثال:
فرض کنید تابعی دارید که دو عدد را جمع می‌کند و یک تست برای آن نوشته‌اید:

// تابع اصلی public int Add(int a, int b) { return a + b; } // تست [Fact] public void Add_ReturnsCorrectSum() { Assert.Equal(5, Add(2, 3)); }

ابزار تست جهش ممکن است یک جهش‌یافته ایجاد کند که در آن + به - تغییر یابد:

// تابع جهش‌یافته public int Add(int a, int b) { return a - b; }

وقتی تست Add_ReturnsCorrectSum بر روی این جهش‌یافته اجرا شود، Add(2, 3) مقدار -1 را برمی‌گرداند که با 5 مورد انتظار متفاوت است. بنابراین، این جهش‌یافته «کشته» می‌شود، که نشان می‌دهد تست شما به اندازه کافی قوی است تا این نوع تغییر را شناسایی کند.

اگر تست شما فقط Assert.True(Add(2,3) > 0) بود، این جهش‌یافته کشته نمی‌شد و به عنوان یک جهش‌یافته زنده باقی می‌ماند، که نشان‌دهنده ضعف تست بود.

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

32. تست A/B (A/B Testing) چیست؟

پاسخ:

تست A/B (A/B Testing)، که به آن تست اسپلیت (Split Testing) نیز گفته می‌شود، یک روش تحقیق است که در آن دو یا چند نسخه از یک صفحه وب، اپلیکیشن، ایمیل یا هر عنصر دیگر با یکدیگر مقایسه می‌شوند تا مشخص شود کدام نسخه عملکرد بهتری دارد. هدف اصلی آن، بهینه‌سازی تجربه کاربری و افزایش نرخ تبدیل (Conversion Rate) با استفاده از داده‌های واقعی است.

ویژگی‌های کلیدی تست A/B:

مقایسه نسخه‌ها: دو یا چند نسخه (A و B) از یک عنصر با یکدیگر مقایسه می‌شوند.

ترافیک تقسیم شده: ترافیک کاربران به صورت تصادفی بین نسخه‌های مختلف تقسیم می‌شود.

اندازه‌گیری متریک‌ها: عملکرد هر نسخه بر اساس متریک‌های از پیش تعریف شده (مانند نرخ کلیک، نرخ تبدیل، زمان ماندگاری) اندازه‌گیری می‌شود.

تصمیم‌گیری مبتنی بر داده: تصمیمات بر اساس داده‌های آماری و نه حدس و گمان گرفته می‌شوند.

مراحل تست A/B:

شناسایی هدف: مشخص کردن متریکی که می‌خواهید بهبود دهید (مثلاً نرخ ثبت‌نام، نرخ خرید).

ایجاد فرضیه: فرموله کردن یک فرضیه در مورد اینکه کدام تغییر منجر به بهبود متریک هدف می‌شود.

طراحی نسخه‌ها: ایجاد نسخه A (کنترل) و نسخه B (با تغییر مورد نظر). تغییر می‌تواند شامل عنوان، دکمه فراخوان، تصویر، طرح‌بندی و غیره باشد.

تقسیم ترافیک: تقسیم ترافیک کاربران به صورت تصادفی بین نسخه‌ها.

جمع‌آوری داده‌ها: جمع‌آوری داده‌های عملکردی برای هر نسخه.

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

اعمال تغییر: اعمال نسخه برنده به تمام کاربران.

مزایای تست A/B:

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

تصمیم‌گیری مبتنی بر داده: حذف حدس و گمان از فرآیند تصمیم‌گیری.

کاهش ریسک: امکان تست تغییرات کوچک قبل از اعمال آنها به تمام کاربران.

بهبود تجربه کاربری: منجر به طراحی‌هایی می‌شود که کاربران بیشتر دوست دارند.

معایب تست A/B:

زمان‌بر: جمع‌آوری داده‌های کافی برای نتایج معنی‌دار می‌تواند زمان‌بر باشد.

نیاز به ترافیک بالا: برای نتایج معتبر، نیاز به حجم قابل توجهی از ترافیک دارد.

پیچیدگی: مدیریت چندین تست A/B به صورت همزمان می‌تواند پیچیده باشد.

مثال:
یک وب‌سایت تجارت الکترونیک می‌خواهد نرخ کلیک بر روی دکمه «افزودن به سبد خرید» را بهبود بخشد. آنها یک تست A/B راه‌اندازی می‌کنند:

نسخه A (کنترل): دکمه سبز رنگ با متن «افزودن به سبد خرید».

نسخه B (تغییر): دکمه نارنجی رنگ با متن «همین الان خرید کنید».

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

تست A/B یک ابزار قدرتمند برای بهینه‌سازی مداوم محصولات و خدمات دیجیتال است.

33. تست قابلیت دسترسی (Accessibility Testing) چیست؟

پاسخ:

تست قابلیت دسترسی (Accessibility Testing) یک نوع تست غیرعملکردی است که برای ارزیابی سهولت استفاده از یک سیستم نرم‌افزاری توسط افراد دارای معلولیت (مانند اختلالات بینایی، شنوایی، حرکتی یا شناختی) انجام می‌شود. هدف اصلی آن، اطمینان از این است که محصول برای همه کاربران، صرف نظر از توانایی‌هایشان، قابل دسترسی و قابل استفاده است.

ویژگی‌های کلیدی تست قابلیت دسترسی:

تمرکز بر فراگیری: اطمینان از اینکه محصول برای طیف وسیعی از کاربران قابل استفاده است.

رعایت استانداردها: بررسی انطباق با استانداردهای قابلیت دسترسی (مانند WCAG - Web Content Accessibility Guidelines).

استفاده از ابزارهای خاص: استفاده از ابزارهای کمکی (مانند صفحه‌خوان‌ها، بزرگ‌نماها) و ابزارهای تست خودکار.

مزایای تست قابلیت دسترسی:

فراگیری و برابری: اطمینان از اینکه همه افراد می‌توانند از محصول استفاده کنند.

افزایش بازار: دسترسی به بخش بزرگ‌تری از جمعیت.

رعایت قوانین: انطباق با قوانین و مقررات مربوط به قابلیت دسترسی (مانند ADA در ایالات متحده).

بهبود تجربه کاربری برای همه: طراحی‌های قابل دسترس اغلب برای همه کاربران مفید هستند.

معایب تست قابلیت دسترسی:

پیچیدگی: نیاز به درک عمیق از انواع معلولیت‌ها و نحوه تعامل آنها با فناوری.

زمان‌بر: تست دستی با ابزارهای کمکی می‌تواند زمان‌بر باشد.

نیاز به تخصص: نیاز به تستران با دانش و تجربه در زمینه قابلیت دسترسی.

مثال:
در یک وب‌سایت خبری، تست قابلیت دسترسی شامل موارد زیر خواهد بود:

استفاده از یک صفحه‌خوان (مانند NVDA یا JAWS) برای پیمایش در وب‌سایت و خواندن مقالات.

بررسی اینکه آیا تصاویر دارای متن جایگزین (alt text) مناسب هستند.

اطمینان از اینکه وب‌سایت با استفاده از صفحه کلید قابل پیمایش است (بدون نیاز به ماوس).

بررسی کنتراست رنگی متن و پس‌زمینه برای کاربران دارای اختلال بینایی.

تست فرم‌ها برای اطمینان از اینکه برچسب‌ها و دستورالعمل‌ها به وضوح قابل درک هستند.

این تست اطمینان حاصل می‌کند که وب‌سایت برای همه کاربران، از جمله افراد دارای معلولیت، قابل استفاده است.

34. تست بین‌المللی‌سازی (Internationalization Testing) چیست؟

پاسخ:

تست بین‌المللی‌سازی (Internationalization Testing - I18n Testing) یک نوع تست غیرعملکردی است که برای ارزیابی توانایی یک سیستم نرم‌افزاری برای پشتیبانی از زبان‌ها، فرهنگ‌ها و مناطق جغرافیایی مختلف انجام می‌شود. هدف اصلی آن، اطمینان از این است که محصول می‌تواند به راحتی برای بازارهای جهانی بومی‌سازی (Localized) شود بدون اینکه نیاز به تغییرات عمده در کد منبع باشد.

ویژگی‌های کلیدی تست بین‌المللی‌سازی:

تمرکز بر جهانی‌سازی: اطمینان از اینکه محصول برای بازارهای مختلف قابل انطباق است.

جداسازی محتوا از کد: بررسی اینکه آیا تمام رشته‌های متنی، پیام‌ها و عناصر رابط کاربری از کد جدا شده‌اند.

پشتیبانی از فرمت‌های مختلف: بررسی پشتیبانی از فرمت‌های تاریخ، زمان، ارز، اعداد و آدرس‌های مختلف.

مزایای تست بین‌المللی‌سازی:

گسترش بازار: امکان عرضه محصول در بازارهای جهانی.

کاهش هزینه‌ها: کاهش هزینه‌های بومی‌سازی و نگهداری نسخه‌های مختلف.

افزایش رضایت مشتری: ارائه تجربه کاربری بومی‌سازی شده به کاربران در سراسر جهان.

بهبود کیفیت کد: تشویق به جداسازی مناسب محتوا از منطق برنامه.

معایب تست بین‌المللی‌سازی:

پیچیدگی: نیاز به درک عمیق از تفاوت‌های فرهنگی و زبانی.

زمان‌بر: تست در زبان‌ها و مناطق مختلف می‌تواند زمان‌بر باشد.

نیاز به منابع: ممکن است به تستران بومی‌زبان نیاز داشته باشد.

مثال:
یک شرکت توسعه‌دهنده نرم‌افزار مدیریت پروژه، تست بین‌المللی‌سازی را انجام می‌دهد:

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

تست نمایش تاریخ‌ها و زمان‌ها در فرمت‌های مختلف (مثلاً MM/DD/YYYY در آمریکا و DD/MM/YYYY در اروپا).

تست نمایش ارزها با نمادهای مختلف (مثلاً $ برای دلار، € برای یورو).

بررسی اینکه آیا رابط کاربری به درستی در زبان‌هایی که از راست به چپ نوشته می‌شوند (مانند فارسی یا عربی) نمایش داده می‌شود.

تست پشتیبانی از کاراکترهای خاص و یونیکد.

این تست اطمینان حاصل می‌کند که محصول می‌تواند به راحتی برای بازارهای جهانی بومی‌سازی شود.

35. تست بومی‌سازی (Localization Testing) چیست؟

پاسخ:

تست بومی‌سازی (Localization Testing - L10n Testing) یک نوع تست غیرعملکردی است که برای ارزیابی کیفیت و صحت بومی‌سازی یک سیستم نرم‌افزاری برای یک زبان، فرهنگ و منطقه جغرافیایی خاص انجام می‌شود. این تست پس از فرآیند بین‌المللی‌سازی و بومی‌سازی انجام می‌شود و هدف اصلی آن، اطمینان از این است که محصول نه تنها از نظر فنی، بلکه از نظر فرهنگی و زبانی نیز برای بازار هدف مناسب است.

ویژگی‌های کلیدی تست بومی‌سازی:

تمرکز بر بازار هدف: ارزیابی محصول برای یک زبان و فرهنگ خاص.

توسط بومی‌زبانان: معمولاً توسط تستران بومی‌زبان و آشنا با فرهنگ منطقه انجام می‌شود.

بررسی صحت ترجمه: اطمینان از اینکه ترجمه‌ها دقیق، مناسب و بدون اشتباه هستند.

بررسی عناصر فرهنگی: بررسی فرمت‌های تاریخ، زمان، ارز، اعداد، آدرس‌ها، تصاویر و نمادها.

مزایای تست بومی‌سازی:

افزایش رضایت مشتری: ارائه تجربه کاربری کاملاً بومی‌سازی شده و طبیعی.

افزایش اعتبار: محصولی که به خوبی بومی‌سازی شده باشد، در بازار هدف اعتبار بیشتری کسب می‌کند.

کاهش مشکلات پس از انتشار: شناسایی و رفع مشکلات فرهنگی یا زبانی قبل از انتشار.

معایب تست بومی‌سازی:

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

زمان‌بر: تست برای هر زبان و منطقه می‌تواند زمان‌بر باشد.

هزینه: ممکن است پرهزینه باشد، به خصوص برای بازارهای متعدد.

مثال:
یک شرکت توسعه‌دهنده نرم‌افزار پیام‌رسان، نسخه فارسی نرم‌افزار خود را تست بومی‌سازی می‌کند:

بررسی صحت ترجمه تمام متون، دکمه‌ها و پیام‌ها به فارسی.

اطمینان از اینکه رابط کاربری به درستی از راست به چپ (RTL) نمایش داده می‌شود.

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

بررسی اینکه آیا نمادها و تصاویر از نظر فرهنگی در ایران مناسب هستند.

تست قابلیت ورود متن فارسی و جستجو.

این تست اطمینان حاصل می‌کند که محصول برای کاربران فارسی‌زبان در ایران کاملاً مناسب و قابل استفاده است.

36. تست Smoke و Sanity چه تفاوتی دارند؟

پاسخ:

تست Smoke و تست Sanity هر دو نوعی از تست‌های سریع و سطحی هستند که برای تأیید سلامت اولیه یک بیلد نرم‌افزار استفاده می‌شوند، اما در هدف، زمان اجرا و دامنه تمرکز تفاوت‌های کلیدی دارند:

ویژگی تست Smoke (Smoke Testing) تست Sanity (Sanity Testing)

هدف اصلی تأیید پایداری و عملکرد اصلی بیلد جدید. آیا بیلد به اندازه کافی پایدار است که بتوان تست‌های عمیق‌تر را روی آن انجام داد؟ تأیید اینکه تغییرات کوچک (رفع باگ یا ویژگی جدید) به درستی کار می‌کنند و هیچ عملکرد مرتبطی را خراب نکرده‌اند.

زمان اجرا معمولاً پس از هر بیلد جدید نرم‌افزار (روزانه یا پس از هر کامیت مهم). پس از دریافت یک بیلد با تغییرات کوچک (مانند رفع باگ یا افزودن ویژگی کوچک).

دامنه تمرکز عملکردهای اصلی سیستم را پوشش می‌دهد و تأیید می‌کند که بیلد پایدار است. (Wide & Shallow) بر روی تغییرات جدید و مناطق مرتبط تمرکز دارد و تأیید می‌کند که تغییرات به درستی کار می‌کنند و عملکرد موجود را خراب نکرده‌اند. (Narrow & Deep)

چه کسی انجام می‌دهد؟ توسعه‌دهندگان (پس از کامپایل) یا تیم QA (پس از دریافت بیلد). معمولاً توسط تیم QA.

هدف نهایی تصمیم‌گیری در مورد اینکه آیا بیلد برای تست‌های عمیق‌تر مناسب است یا خیر. تصمیم‌گیری در مورد اینکه آیا بیلد با تغییرات جدید برای انتشار یا تست‌های جامع‌تر مناسب است یا خیر.

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

به طور خلاصه، تست Smoke مانند یک چکاپ اولیه و عمومی است که مطمئن می‌شود ماشین روشن می‌شود و حرکت می‌کند، در حالی که تست Sanity مانند یک چکاپ متمرکز و سریع است که مطمئن می‌شود پس از تعمیر یک قطعه خاص، آن قطعه و اجزای مرتبط با آن به درستی کار می‌کنند و تعمیر باعث خرابی جای دیگری نشده است.

37. تست Functional و Non-Functional چه تفاوتی دارند؟

پاسخ:

تست Functional (عملکردی) و Non-Functional (غیرعملکردی) دو دسته اصلی تست نرم‌افزار هستند که جنبه‌های مختلف یک سیستم را ارزیابی می‌کنند:

ویژگی تست Functional (عملکردی) تست Non-Functional (غیرعملکردی)

هدف اصلی تأیید اینکه سیستم چه کاری انجام می‌دهد (What the system does). آیا سیستم الزامات عملکردی را برآورده می‌کند؟ تأیید اینکه سیستم چگونه کاری را انجام می‌دهد (How the system performs). آیا سیستم الزامات کیفی را برآورده می‌کند؟

تمرکز بر روی ویژگی‌ها و عملکردهای خاص سیستم (مثلاً ورود به سیستم، ثبت سفارش، جستجو). بر روی جنبه‌های کیفی سیستم مانند عملکرد (Performance)، امنیت (Security)، قابلیت استفاده (Usability)، قابلیت اطمینان (Reliability)، مقیاس‌پذیری (Scalability) و غیره.

مثال‌ها تست واحد (Unit Testing)، تست یکپارچه‌سازی (Integration Testing)، تست سیستم (System Testing)، تست پذیرش (Acceptance Testing)، تست رگرسیون (Regression Testing)، تست Smoke، تست Sanity. تست عملکرد (Performance Testing)، تست امنیت (Security Testing)، تست قابلیت استفاده (Usability Testing)، تست قابلیت اطمینان (Reliability Testing)، تست سازگاری (Compatibility Testing)، تست قابلیت نگهداری (Maintainability Testing)، تست قابلیت حمل (Portability Testing)، تست بین‌المللی‌سازی (Internationalization Testing)، تست بومی‌سازی (Localization Testing).

تکنیک‌ها تست جعبه سیاه (Black-box Testing)، تست جعبه سفید (White-box Testing)، تست جعبه خاکستری (Gray-box Testing). تست‌های مبتنی بر ابزار، تست‌های دستی، شبیه‌سازی بار، تحلیل آسیب‌پذیری.

سوال کلیدی آیا این ویژگی کار می‌کند؟ آیا خروجی صحیح است؟ آیا این ویژگی به اندازه کافی سریع است؟ آیا امن است؟ آیا استفاده از آن آسان است؟

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

38. تست Black-box، White-box و Gray-box چه تفاوتی دارند؟

پاسخ:

تست Black-box، White-box و Gray-box سه رویکرد اصلی در تست نرم‌افزار هستند که بر اساس میزان دانش تستر از ساختار داخلی، کد و طراحی سیستم تحت تست (SUT) تعریف می‌شوند:

ویژگی تست Black-box (جعبه سیاه) تست White-box (جعبه سفید) تست Gray-box (جعبه خاکستری)

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

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

چه کسی انجام می‌دهد؟ تیم QA، کاربران نهایی، تست‌کنندگان مستقل. توسعه‌دهندگان، تست‌کنندگان با دانش برنامه‌نویسی. تیم QA با دانش برنامه‌نویسی یا توسعه‌دهندگان.

تکنیک‌ها پارتیشن‌بندی هم‌ارزی (Equivalence Partitioning)، تحلیل مقدار مرزی (Boundary Value Analysis)، جدول تصمیم (Decision Table Testing)، تست حالت (State Transition Testing)، تست Use Case. پوشش دستور (Statement Coverage)، پوشش تصمیم (Decision Coverage)، پوشش مسیر (Path Coverage)، پوشش شرط (Condition Coverage)، تست حلقه (Loop Testing). تست ماتریس (Matrix Testing)، تست رگرسیون (Regression Testing)، تست الگو (Pattern Testing)، تست رگرسیون خودکار.

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

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

به طور خلاصه:

Black-box: مانند رانندگی با ماشین بدون دانستن نحوه کار موتور. فقط به ورودی‌ها و خروجی‌ها اهمیت می‌دهید.

White-box: مانند مکانیکی که تمام اجزای موتور را می‌شناسد و می‌تواند هر قسمت را تست کند.

Gray-box: مانند راننده‌ای که کمی از مکانیک ماشین سر در می‌آورد و می‌تواند برخی مشکلات را تشخیص دهد.

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

39. تست Static و Dynamic چه تفاوتی دارند؟

پاسخ:

تست Static (ایستا) و Dynamic (پویا) دو رویکرد متفاوت برای تست نرم‌افزار هستند که در زمان و نحوه انجام تست با یکدیگر تفاوت دارند:

ویژگی تست Static (ایستا) تست Dynamic (پویا)

زمان اجرا بدون اجرای کد. در مراحل اولیه چرخه توسعه (مانند فاز تحلیل و طراحی) یا بر روی کد منبع قبل از کامپایل و اجرا. با اجرای کد. پس از کامپایل و اجرای نرم‌افزار.

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

چه کسی انجام می‌دهد؟ توسعه‌دهندگان، تست‌کنندگان، تحلیلگران کسب‌وکار. تیم QA، کاربران نهایی.

تکنیک‌ها بازبینی‌ها (Reviews)، بازرسی‌ها (Inspections)، واک‌ثرو (Walkthroughs)، تحلیل استاتیک کد (Static Code Analysis) با استفاده از ابزارها. تست واحد (Unit Testing)، تست یکپارچه‌سازی (Integration Testing)، تست سیستم (System Testing)، تست عملکرد (Performance Testing)، تست امنیت (Security Testing) و غیره.

مزایا شناسایی زودهنگام باگ‌ها (که رفع آنها ارزان‌تر است)، بهبود کیفیت کد، کاهش نیاز به تست‌های پویا. تأیید رفتار واقعی سیستم، شناسایی باگ‌های زمان اجرا، ارزیابی عملکرد و امنیت.

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

به طور خلاصه:

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

تست Dynamic: مانند بازدید از ساختمان پس از اتمام ساخت و ساز برای بررسی اینکه آیا همه چیز به درستی کار می‌کند و ایمن است.

ترکیبی از هر دو رویکرد (Static و Dynamic) برای دستیابی به یک فرآیند تست جامع و مؤثر ضروری است.

40. تست مثبت (Positive Testing) و تست منفی (Negative Testing) چه تفاوتی دارند؟

پاسخ:

تست مثبت (Positive Testing) و تست منفی (Negative Testing) دو رویکرد مکمل در تست نرم‌افزار هستند که برای ارزیابی رفتار سیستم در شرایط مختلف ورودی استفاده می‌شوند:

ویژگی تست Positive (مثبت) تست Negative (منفی)

هدف اصلی تأیید اینکه سیستم به درستی کار می‌کند زمانی که ورودی‌های معتبر و مورد انتظار به آن داده می‌شود. تأیید اینکه سیستم به درستی خطاها را مدیریت می‌کند و در برابر ورودی‌های نامعتبر، غیرمنتظره یا مخرب مقاوم است.

تمرکز بر روی سناریوهای «موفقیت‌آمیز» (Happy Path). بر روی سناریوهای «خطا» (Error Path) و «مخرب» (Destructive Path).

مثال ورود به سیستم: وارد کردن نام کاربری و رمز عبور صحیح. ثبت‌نام: وارد کردن ایمیل معتبر و رمز عبور با فرمت صحیح. ورود به سیستم: وارد کردن نام کاربری یا رمز عبور اشتباه. ثبت‌نام: وارد کردن ایمیل نامعتبر، رمز عبور کوتاه، یا تلاش برای ثبت‌نام با ایمیل تکراری.

نتیجه مورد انتظار سیستم باید عملکرد مورد نظر را انجام دهد (مثلاً کاربر وارد سیستم شود). سیستم باید یک پیام خطای مناسب نمایش دهد، از کرش کردن جلوگیری کند و در حالت پایدار باقی بماند.

اهمیت تضمین می‌کند که سیستم عملکردهای اصلی خود را به درستی انجام می‌دهد. تضمین می‌کند که سیستم قوی، پایدار و امن است و می‌تواند در برابر ورودی‌های غیرمنتظره مقاومت کند.

به طور خلاصه:

تست Positive: بررسی اینکه سیستم کاری را که باید انجام دهد، انجام می‌دهد.

تست Negative: بررسی اینکه سیستم کاری را که نباید انجام دهد، انجام نمی‌دهد.

هر دو نوع تست برای اطمینان از کیفیت و پایداری نرم‌افزار ضروری هستند.

41. تست Ad-hoc چیست؟

پاسخ:

تست Ad-hoc یک نوع تست غیررسمی و بدون برنامه‌ریزی است که در آن تستر بدون پیروی از هیچ مستندات، موارد تست یا برنامه‌ریزی قبلی، سیستم را تست می‌کند. این روش کاملاً بر اساس شهود، تجربه و خلاقیت تستر است و هدف اصلی آن، کشف باگ‌های غیرمنتظره و غیرمعمول است.

ویژگی‌های کلیدی تست Ad-hoc:

بدون برنامه‌ریزی: هیچ برنامه‌ریزی یا مستندات قبلی وجود ندارد.

غیررسمی: به صورت کاملاً غیررسمی و بدون ساختار انجام می‌شود.

مبتنی بر شهود: تستر بر اساس شهود و تجربه خود عمل می‌کند.

هدف: کشف باگ‌های غیرمنتظره.

تفاوت با تست پیمایش (Exploratory Testing):

تست Ad-hoc و تست پیمایش هر دو غیررسمی هستند، اما تست پیمایش ساختار بیشتری دارد. در تست پیمایش، تستر ممکن است یک هدف کلی داشته باشد، یادداشت‌برداری کند و یافته‌های خود را برای طراحی تست‌های بعدی به کار گیرد. در حالی که تست Ad-hoc کاملاً تصادفی و بدون هیچ گونه مستندسازی است.

مزایای تست Ad-hoc:

کشف سریع باگ‌ها: می‌تواند باگ‌های مهم را به سرعت و با تلاش کم کشف کند.

انعطاف‌پذیری: به تستر اجازه می‌دهد تا به صورت آزادانه سیستم را کاوش کند.

نیاز به منابع کم: نیاز به برنامه‌ریزی و مستندسازی ندارد.

معایب تست Ad-hoc:

عدم تکرارپذیری: بازتولید باگ‌ها می‌تواند دشوار باشد، زیرا مراحل تست مستند نشده‌اند.

پوشش نامشخص: تعیین میزان پوشش تست غیرممکن است.

نیاز به تخصص: برای مؤثر بودن، نیاز به تستران با تجربه و دانش عمیق از سیستم دارد.

مثال:
یک تستر در حال تست یک برنامه ویرایش متن است. او به صورت تصادفی شروع به انجام کارهای زیر می‌کند:

کپی و پیست کردن حجم زیادی از متن.

باز و بسته کردن سریع پنجره‌ها.

کلیک کردن بر روی دکمه‌ها به صورت تصادفی.

تغییر فونت و اندازه متن به صورت مکرر.

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

تست Ad-hoc یک مکمل خوب برای تست‌های رسمی است و می‌تواند به کشف باگ‌هایی کمک کند که در غیر این صورت نادیده گرفته می‌شوند.

42. تست End-to-End (E2E) چیست؟

پاسخ:

تست End-to-End (E2E) یک نوع تست نرم‌افزار است که کل جریان کاری یک برنامه را از ابتدا تا انتها شبیه‌سازی می‌کند تا اطمینان حاصل شود که تمام اجزای سیستم (مانند رابط کاربری، APIها، پایگاه داده، شبکه‌ها و سرویس‌های خارجی) به درستی با یکدیگر کار می‌کنند و سیستم به عنوان یک کل، عملکرد مورد انتظار را دارد.

ویژگی‌های کلیدی تست End-to-End:

شبیه‌سازی سناریوهای واقعی: تست‌ها جریان‌های کاری واقعی کاربران را شبیه‌سازی می‌کنند.

پوشش کل سیستم: تمام لایه‌ها و اجزای سیستم را در بر می‌گیرد.

تست از دیدگاه کاربر: سیستم را از دیدگاه کاربر نهایی تست می‌کند.

تست Black-box: معمولاً به عنوان یک نوع تست جعبه سیاه انجام می‌شود.

مزایای تست End-to-End:

تأیید جریان کاری کامل: اطمینان حاصل می‌کند که کل جریان کاری به درستی کار می‌کند.

افزایش اعتماد: به تیم توسعه و ذینفعان اعتماد بیشتری به عملکرد کلی سیستم می‌دهد.

کشف باگ‌های یکپارچه‌سازی: می‌تواند باگ‌هایی را کشف کند که در تست‌های واحد یا یکپارچه‌سازی نادیده گرفته شده‌اند.

کاهش ریسک انتشار: با تأیید جریان‌های کاری حیاتی، ریسک انتشار محصول با باگ‌های مهم کاهش می‌یابد.

معایب تست End-to-End:

پیچیدگی: طراحی و نگهداری تست‌های E2E می‌تواند پیچیده باشد.

زمان‌بر: اجرای تست‌های E2E معمولاً زمان‌بر است.

شکنندگی (Flakiness): تست‌ها ممکن است به دلیل مشکلات محیطی (مانند مشکلات شبکه یا سرویس‌های خارجی) به صورت غیرقابل پیش‌بینی شکست بخورند.

دشواری در عیب‌یابی: یافتن علت اصلی یک شکست در تست E2E می‌تواند دشوار باشد.

مثال:
در یک وب‌سایت تجارت الکترونیک، یک تست End-to-End شامل موارد زیر خواهد بود:

کاربر وارد وب‌سایت می‌شود.

یک محصول را جستجو می‌کند.

محصول را به سبد خرید اضافه می‌کند.

به صفحه پرداخت می‌رود.

اطلاعات پرداخت و آدرس را وارد می‌کند.

سفارش را ثبت می‌کند.

یک ایمیل تأیید سفارش دریافت می‌کند.

سفارش در پایگاه داده ثبت می‌شود.

موجودی انبار به‌روزرسانی می‌شود.

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

43. تست مبتنی بر داده (Data-Driven Testing) چیست؟

پاسخ:

تست مبتنی بر داده (Data-Driven Testing - DDT) یک رویکرد تست خودکار است که در آن داده‌های تست (ورودی‌ها و خروجی‌های مورد انتظار) از منطق تست (اسکریپت تست) جدا می‌شوند. به جای اینکه داده‌ها به صورت ثابت در اسکریپت تست کدگذاری شوند، از یک منبع خارجی (مانند فایل‌های CSV، صفحات گسترده اکسل، پایگاه داده یا فایل‌های XML) خوانده می‌شوند. این رویکرد به تستر اجازه می‌دهد تا یک اسکریپت تست واحد را با مجموعه‌های مختلفی از داده‌ها اجرا کند.

ویژگی‌های کلیدی تست مبتنی بر داده:

جداسازی داده از منطق: داده‌های تست از اسکریپت تست جدا هستند.

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

اجرای مکرر با داده‌های مختلف: یک اسکریپت تست با چندین مجموعه داده اجرا می‌شود.

مزایای تست مبتنی بر داده:

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

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

قابلیت نگهداری بالا: تغییر داده‌های تست بدون نیاز به تغییر کد اسکریپت.

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

معایب تست مبتنی بر داده:

پیچیدگی اولیه: راه‌اندازی چارچوب تست مبتنی بر داده می‌تواند پیچیده باشد.

نیاز به مهارت: نیاز به مهارت در کار با فایل‌های داده و چارچوب‌های تست خودکار دارد.

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

ایجاد منبع داده: یک فایل CSV با ستون‌های Username، Password و ExpectedResult ایجاد می‌کنید:
Username,Password,ExpectedResult validuser,validpass,Success invaliduser,validpass,Failure validuser,invalidpass,Failure ,validpass,Failure validuser,,Failure

نوشتن اسکریپت تست: یک اسکریپت تست واحد می‌نویسید که داده‌ها را از فایل CSV می‌خواند و در یک حلقه، فرم ورود را با هر ردیف از داده‌ها تست می‌کند.

اجرای تست: اسکریپت تست به صورت خودکار برای هر ردیف از داده‌ها اجرا می‌شود و نتیجه واقعی را با ExpectedResult مقایسه می‌کند.

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

44. تست مبتنی بر کلمه کلیدی (Keyword-Driven Testing) چیست؟

پاسخ:

تست مبتنی بر کلمه کلیدی (Keyword-Driven Testing - KDT)، که به آن تست مبتنی بر جدول (Table-Driven Testing) نیز گفته می‌شود، یک رویکرد تست خودکار است که در آن منطق تست از جزئیات پیاده‌سازی جدا می‌شود. در این رویکرد، مجموعه‌ای از کلمات کلیدی (Keywords) تعریف می‌شوند که هر کدام نماینده یک عمل خاص در سیستم تحت تست (SUT) هستند (مانند login، clickButton، verifyText). سپس، موارد تست با استفاده از این کلمات کلیدی در یک جدول (معمولاً یک صفحه گسترده) ایجاد می‌شوند.

ویژگی‌های کلیدی تست مبتنی بر کلمه کلیدی:

جداسازی منطق از پیاده‌سازی: موارد تست از کد پیاده‌سازی کلمات کلیدی جدا هستند.

استفاده از کلمات کلیدی: موارد تست با استفاده از کلمات کلیدی قابل فهم برای انسان ایجاد می‌شوند.

قابلیت استفاده مجدد: کلمات کلیدی می‌توانند در موارد تست مختلف استفاده شوند.

مراحل تست مبتنی بر کلمه کلیدی:
شناسایی کلمات کلیدی: شناسایی و تعریف کلمات کلیدی برای اعمال مختلف در سیستم.

پیاده‌سازی کلمات کلیدی: نوشتن کد برای پیاده‌سازی هر کلمه کلیدی.

ایجاد موارد تست: ایجاد موارد تست در یک جدول با استفاده از کلمات کلیدی.

اجرای تست: یک چارچوب تست (Test Framework) جدول را می‌خواند، کلمات کلیدی را تفسیر می‌کند و کد مربوطه را اجرا می‌کند.

مزایای تست مبتنی بر کلمه کلیدی:

قابلیت نگهداری بالا: تغییرات در پیاده‌سازی سیستم فقط نیاز به به‌روزرسانی کد کلمات کلیدی دارد، نه موارد تست.

قابلیت استفاده مجدد: کلمات کلیدی می‌توانند در موارد تست مختلف استفاده شوند.

مشارکت افراد غیرفنی: افراد غیرفنی (مانند تحلیلگران کسب‌وکار) می‌توانند موارد تست را با استفاده از کلمات کلیدی قابل فهم ایجاد کنند.

استقلال از ابزار: موارد تست مستقل از ابزار تست خودکار هستند.

معایب تست مبتنی بر کلمه کلیدی:

پیچیدگی اولیه: راه‌اندازی چارچوب و پیاده‌سازی کلمات کلیدی می‌تواند پیچیده و زمان‌بر باشد.

نیاز به برنامه‌ریزی دقیق: نیاز به برنامه‌ریزی دقیق برای شناسایی و تعریف کلمات کلیدی دارد.

مثال:
برای تست یک فرم ورود به سیستم، می‌توانید کلمات کلیدی زیر را تعریف کنید:

openBrowser

navigateToURL

enterText

clickButton

verifyText

closeBrowser

سپس، یک مورد تست در یک صفحه گسترده به صورت زیر ایجاد می‌شود:

کلمه کلیدی پارامتر 1 پارامتر 2

openBrowser Chrome

navigateToURL http://example.com/login

enterText username_field validuser

enterText password_field validpass

clickButton login_button

verifyText welcome_message Welcome, validuser!

closeBrowser

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

45. تست مبتنی بر رفتار (Behavior-Driven Development - BDD) چیست؟

پاسخ:

تست مبتنی بر رفتار (Behavior-Driven Development - BDD) یک فرآیند توسعه نرم‌افزار چابک است که همکاری بین توسعه‌دهندگان، تست‌کنندگان و ذینفعان کسب‌وکار را تشویق می‌کند. BDD بر اساس تست مبتنی بر تست (Test-Driven Development - TDD) ساخته شده است و هدف آن، تعریف رفتار سیستم از دیدگاه کاربر با استفاده از یک زبان طبیعی و قابل فهم برای همه (مانند Gherkin) است.

ویژگی‌های کلیدی BDD:

همکاری: تمرکز بر همکاری و ارتباط بین تیم‌های فنی و غیرفنی.

زبان مشترک: استفاده از یک زبان مشترک (Ubiquitous Language) برای توصیف رفتار سیستم.

مثال‌های واقعی: تعریف رفتار سیستم با استفاده از مثال‌های واقعی و قابل فهم.

خودکارسازی: سناریوهای BDD می‌توانند به صورت خودکار اجرا شوند.

مراحل BDD:

کشف (Discovery): ذینفعان کسب‌وکار، توسعه‌دهندگان و تست‌کنندگان با هم همکاری می‌کنند تا رفتار مورد انتظار سیستم را با استفاده از مثال‌های واقعی تعریف کنند.

فرموله کردن (Formulation): مثال‌ها به صورت سناریوهای ساختاریافته با استفاده از زبان Gherkin (با کلمات کلیدی Given، When، Then) نوشته می‌شوند.

خودکارسازی (Automation): هر مرحله از سناریو به یک کد تست خودکار متصل می‌شود.

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

زبان Gherkin:

Gherkin یک زبان ساده و قابل فهم است که برای نوشتن سناریوهای BDD استفاده می‌شود:

Given (با توجه به): شرایط اولیه یا پیش‌نیازها.

When (هنگامی که): عمل یا رویدادی که توسط کاربر انجام می‌شود.

Then (آنگاه): نتیجه یا خروجی مورد انتظار.

And (و) / But (اما): برای افزودن شرایط بیشتر به هر مرحله.

مزایای BDD:
درک مشترک: ایجاد درک مشترک از الزامات بین تمام اعضای تیم.

کاهش ابهام: کاهش ابهام و سوءتفاهم در مورد الزامات.

تمرکز بر ارزش کسب‌وکار: اطمینان از اینکه توسعه بر روی ویژگی‌هایی متمرکز است که برای کسب‌وکار ارزش دارند.

مستندات زنده: سناریوهای BDD به عنوان مستندات زنده و قابل اجرای سیستم عمل می‌کنند.

معایب BDD:

نیاز به همکاری: برای موفقیت، نیاز به همکاری فعال بین تمام ذینفعان دارد.

پیچیدگی اولیه: راه‌اندازی چارچوب BDD و آموزش تیم می‌تواند زمان‌بر باشد.

مثال:
برای تست یک فرم ورود به سیستم، یک سناریوی BDD به صورت زیر نوشته می‌شود:

Feature: Login Scenario: Successful login with valid credentials Given I am on the login page When I enter "validuser" in the username field And I enter "validpass" in the password field And I click the "Login" button Then I should be redirected to the dashboard And I should see the welcome message "Welcome, validuser!"

این سناریو به وضوح رفتار مورد انتظار سیستم را توصیف می‌کند و می‌تواند به عنوان یک تست خودکار اجرا شود.

46. تست مبتنی بر تست (Test-Driven Development - TDD) چیست؟

پاسخ:

تست مبتنی بر تست (Test-Driven Development - TDD) یک فرآیند توسعه نرم‌افزار است که در آن توسعه‌دهندگان قبل از نوشتن کد اصلی، ابتدا یک تست خودکار برای یک عملکرد خاص می‌نویسند. این تست در ابتدا شکست می‌خورد (چون هنوز کدی برای آن نوشته نشده است). سپس، توسعه‌دهنده حداقل کد لازم را می‌نویسد تا تست پاس شود. در نهایت، کد را بازسازی (Refactor) می‌کند تا کیفیت آن بهبود یابد، در حالی که اطمینان حاصل می‌کند که تست همچنان پاس می‌شود.

ویژگی‌های کلیدی TDD:

تست اول: همیشه قبل از کد، تست نوشته می‌شود.

چرخه کوتاه: توسعه در چرخه‌های کوتاه و تکراری انجام می‌شود.

تمرکز بر طراحی: تشویق به طراحی ساده و ماژولار.

چرخه TDD (Red-Green-Refactor):

Red (قرمز): نوشتن یک تست خودکار که شکست می‌خورد. این مرحله تضمین می‌کند که تست به درستی کار می‌کند و کد جدیدی که قرار است نوشته شود، واقعاً مورد نیاز است.

Green (سبز): نوشتن حداقل کد لازم برای پاس شدن تست. در این مرحله، هدف فقط پاس شدن تست است، نه نوشتن کد کامل یا بهینه.

Refactor (بازسازی): بهبود کیفیت کد نوشته شده (مانند حذف تکرار، بهبود نام‌گذاری، ساده‌سازی منطق) بدون تغییر در عملکرد آن. پس از هر تغییر، تست‌ها دوباره اجرا می‌شوند تا اطمینان حاصل شود که هیچ چیزی خراب نشده است.

این چرخه برای هر عملکرد کوچک تکرار می‌شود.

مزایای TDD:

پوشش تست بالا: به طور طبیعی منجر به پوشش تست بالا می‌شود.

طراحی بهتر: تشویق به طراحی ماژولار، با وابستگی کم و قابل تست.

کاهش باگ‌ها: باگ‌ها در مراحل اولیه شناسایی و رفع می‌شوند.

اعتماد به کد: توسعه‌دهندگان اعتماد بیشتری به کد خود دارند و می‌توانند با اطمینان بیشتری آن را بازسازی کنند.

مستندات زنده: تست‌ها به عنوان مستندات قابل اجرای کد عمل می‌کنند.

معایب TDD:

یادگیری دشوار: نیاز به تغییر ذهنیت و یادگیری یک رویکرد جدید دارد.

زمان‌بر در ابتدا: ممکن است در ابتدا کندتر از روش‌های سنتی به نظر برسد.

نیاز به تخصص: برای نوشتن تست‌های خوب، نیاز به مهارت دارد.

مثال:
فرض کنید می‌خواهید یک تابع برای جمع دو عدد بنویسید:

Red: ابتدا یک تست می‌نویسید:
[Fact] public void Add_ReturnsCorrectSum() { var calculator = new Calculator(); Assert.Equal(5, calculator.Add(2, 3)); }
این تست شکست می‌خورد چون کلاس Calculator و متد Add هنوز وجود ندارند.

Green: حداقل کد لازم را برای پاس شدن تست می‌نویسید:
public class Calculator { public int Add(int a, int b) { return 5; // کد ساده برای پاس شدن تست } }
حالا تست پاس می‌شود.

Refactor: کد را بازسازی می‌کنید تا به درستی کار کند:
public class Calculator { public int Add(int a, int b) { return a + b; } }
تست را دوباره اجرا می‌کنید تا مطمئن شوید همچنان پاس می‌شود. سپس تست‌های دیگری برای سناریوهای دیگر (مانند اعداد منفی) اضافه می‌کنید و چرخه را تکرار می‌کنید.

TDD یک رویکرد قدرتمند برای نوشتن کدهای با کیفیت بالا و قابل نگهداری است.

47. تست مبتنی بر پذیرش (Acceptance Test-Driven Development - ATDD) چیست؟

پاسخ:

تست مبتنی بر پذیرش (Acceptance Test-Driven Development - ATDD) یک فرآیند توسعه نرم‌افزار است که در آن اعضای تیم (مشتری، توسعه‌دهنده و تستر) با هم همکاری می‌کنند تا تست‌های پذیرش را قبل از شروع توسعه بنویسند. این تست‌ها از دیدگاه کاربر و بر اساس الزامات کسب‌وکار نوشته می‌شوند و به عنوان معیاری برای تکمیل یک ویژگی عمل می‌کنند. ATDD بر روی درک مشترک از الزامات و اطمینان از اینکه محصول نهایی نیازهای کسب‌وکار را برآورده می‌کند، تمرکز دارد.

ویژگی‌های کلیدی ATDD:

همکاری: تمرکز بر همکاری بین مشتری، توسعه‌دهنده و تستر.

تست پذیرش اول: تست‌های پذیرش قبل از کدنویسی نوشته می‌شوند.

دیدگاه کاربر: تست‌ها از دیدگاه کاربر و بر اساس الزامات کسب‌وکار هستند.

درک مشترک: ایجاد درک مشترک از الزامات.

مراحل ATDD:

بحث (Discuss): مشتری، توسعه‌دهنده و تستر با هم در مورد یک ویژگی بحث می‌کنند تا به درک مشترکی از آن برسند.

تقطیر (Distill): تست‌های پذیرش به صورت قابل فهم برای همه (مانند جداول یا سناریوهای Gherkin) نوشته می‌شوند.

توسعه (Develop): توسعه‌دهنده کد را می‌نویسد تا تست‌های پذیرش پاس شوند.

نمایش (Demo): ویژگی تکمیل شده به مشتری نمایش داده می‌شود تا تأیید شود که الزامات را برآورده می‌کند.

تفاوت با TDD و BDD:

TDD: تمرکز بر روی طراحی و پیاده‌سازی صحیح کد از دیدگاه توسعه‌دهنده. تست‌ها معمولاً در سطح واحد (Unit) هستند.

ATDD: تمرکز بر روی برآورده کردن الزامات کسب‌وکار از دیدگاه کاربر. تست‌ها در سطح پذیرش (Acceptance) هستند.

BDD: یک تکامل از TDD و ATDD است که بر روی همکاری و زبان مشترک تأکید بیشتری دارد و از ابزارهایی مانند Gherkin برای تعریف رفتار سیستم استفاده می‌کند.

در واقع، ATDD و BDD بسیار به هم نزدیک هستند و اغلب به جای یکدیگر استفاده می‌شوند. هر دو بر روی همکاری و تعریف رفتار سیستم قبل از توسعه تمرکز دارند.

مزایای ATDD:

درک مشترک از الزامات: کاهش ابهام و سوءتفاهم.

تمرکز بر ارزش کسب‌وکار: اطمینان از اینکه توسعه بر روی نیازهای واقعی مشتری متمرکز است.

کاهش بازکاری: با تعریف دقیق الزامات در ابتدا، نیاز به بازکاری کاهش می‌یابد.

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

معایب ATDD:

نیاز به همکاری فعال: موفقیت آن به شدت به همکاری بین اعضای تیم وابسته است.

زمان‌بر در ابتدا: فرآیند بحث و تعریف تست‌های پذیرش می‌تواند زمان‌بر باشد.

مثال:
برای یک ویژگی انتقال وجه در یک برنامه بانکداری، تیم یک جلسه برگزار می‌کند:

مشتری: توضیح می‌دهد که کاربر باید بتواند از یک حساب به حساب دیگر پول منتقل کند.

تستر: سوالاتی در مورد سناریوهای خطا می‌پرسد (مانند موجودی ناکافی، شماره حساب نامعتبر).

توسعه‌دهنده: سوالاتی در مورد جزئیات فنی می‌پرسد.

سپس، آنها با هم یک تست پذیرش می‌نویسند:

سناریو: انتقال وجه موفق

با توجه به اینکه حساب A موجودی 1000 تومان دارد و حساب B موجودی 500 تومان دارد.

هنگامی که کاربر 200 تومان از حساب A به حساب B منتقل می‌کند.

آنگاه موجودی حساب A باید 800 تومان و موجودی حساب B باید 700 تومان باشد.

توسعه‌دهنده کد را می‌نویسد تا این تست پاس شود.

48. تست مبتنی بر جلسه (Session-Based Testing) چیست؟

پاسخ:

تست مبتنی بر جلسه (Session-Based Testing - SBT) یک رویکرد ساختاریافته برای تست پیمایش (Exploratory Testing) است که برای افزایش پاسخگویی، مستندسازی و مدیریت تست‌های غیررسمی طراحی شده است. در این روش، تست در جلسات (Sessions) با زمان محدود و بدون وقفه انجام می‌شود. هر جلسه یک مأموریت (Mission) یا هدف مشخص دارد و تستر در طول جلسه، یافته‌ها، باگ‌ها و یادداشت‌های خود را در یک گزارش جلسه (Session Report) ثبت می‌کند.

ویژگی‌های کلیدی تست مبتنی بر جلسه:

ساختارمند کردن تست پیمایش: به تست پیمایش ساختار و قابلیت مدیریت می‌بخشد.

جلسات با زمان محدود: تست در جلسات کوتاه و متمرکز (معمولاً 60 تا 120 دقیقه) انجام می‌شود.

مأموریت مشخص: هر جلسه یک هدف یا مأموریت مشخص دارد.

مستندسازی: یافته‌ها در یک گزارش جلسه ثبت می‌شوند.

اجزای یک جلسه تست:

مأموریت (Mission): هدف کلی جلسه تست (مثلاً تست عملکرد جستجوی پیشرفته).

منشور (Charter): یک توضیح کوتاه از اهداف و برنامه‌های جلسه.

گزارش جلسه (Session Report): یک گزارش دقیق از فعالیت‌های انجام شده در طول جلسه، شامل موارد زیر:

زمان شروع و پایان جلسه.

مناطق تست شده.

باگ‌های پیدا شده.

مشکلات و سوالات.

یادداشت‌ها و ایده‌ها برای تست‌های آینده.

بازبینی (Debriefing): یک جلسه کوتاه پس از هر جلسه تست بین تستر و مدیر تست برای بررسی گزارش جلسه و تصمیم‌گیری در مورد اقدامات بعدی.

مزایای تست مبتنی بر جلسه:

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

مستندسازی بهتر: یافته‌ها به صورت ساختاریافته ثبت می‌شوند.

تمرکز بیشتر: جلسات با زمان محدود به تستر کمک می‌کند تا متمرکز بماند.

ارتباط بهتر: جلسات بازبینی به بهبود ارتباط و همکاری کمک می‌کند.

معایب تست مبتنی بر جلسه:

نیاز به نظم: نیاز به نظم و انضباط برای پیروی از فرآیند دارد.

زمان‌بر بودن مستندسازی: مستندسازی می‌تواند زمان‌بر باشد.

مثال:
یک تستر یک جلسه 90 دقیقه‌ای را برای تست قابلیت آپلود فایل در یک برنامه مدیریت اسناد برنامه‌ریزی می‌کند.

منشور: «در این جلسه 90 دقیقه‌ای، من قابلیت آپلود فایل را با انواع مختلف فایل‌ها، اندازه‌های مختلف و در شرایط مختلف شبکه تست خواهم کرد تا باگ‌ها و مشکلات عملکردی را پیدا کنم.»

در طول جلسه: تستر فایل‌های PDF، Word، تصویر و ویدیو را با اندازه‌های مختلف آپلود می‌کند. او همچنین شرایط شبکه کند را شبیه‌سازی می‌کند. او تمام یافته‌های خود را در گزارش جلسه ثبت می‌کند، از جمله یک باگ که در آن برنامه هنگام آپلود یک فایل با نام بسیار طولانی کرش می‌کند.

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

این رویکرد به تیم کمک می‌کند تا از مزایای تست پیمایش بهره‌مند شوند، در حالی که کنترل و پاسخگویی را حفظ می‌کنند.

49. تست مبتنی بر سناریو (Scenario Testing) چیست؟

پاسخ:

تست مبتنی بر سناریو (Scenario Testing) یک نوع تست نرم‌افزار است که در آن موارد تست بر اساس سناریوهای واقعی و قابل تصور از نحوه استفاده کاربران از سیستم طراحی می‌شوند. به جای تست ویژگی‌ها به صورت جداگانه، این روش بر روی تست جریان‌های کاری کامل و پیچیده که چندین ویژگی را در بر می‌گیرند، تمرکز دارد. هدف اصلی آن، تأیید این است که سیستم می‌تواند سناریوهای واقعی کسب‌وکار را به درستی و به طور کامل پشتیبانی کند.

ویژگی‌های کلیدی تست مبتنی بر سناریو:

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

دیدگاه کاربر: سناریوها از دیدگاه کاربر و بر اساس اهداف آنها طراحی می‌شوند.

واقع‌گرایانه: سناریوها باید واقع‌گرایانه، قابل باور و قابل اجرا باشند.

پوشش چندین ویژگی: هر سناریو معمولاً چندین ویژگی و عملکرد را در بر می‌گیرد.

تفاوت با تست Use Case:

تست مبتنی بر سناریو و تست Use Case هر دو بر روی جریان‌های کاری تمرکز دارند، اما تفاوت‌های ظریفی دارند:

Use Case: معمولاً یک جریان کاری خاص و موفقیت‌آمیز را توصیف می‌کند (Happy Path).

Scenario: می‌تواند شامل چندین Use Case، شرایط خطا، و جریان‌های کاری جایگزین باشد. یک سناریو می‌تواند یک داستان کامل‌تر و پیچیده‌تر را روایت کند.

مزایای تست مبتنی بر سناریو:

پوشش بهتر جریان‌های کاری: اطمینان حاصل می‌کند که سیستم می‌تواند جریان‌های کاری پیچیده را مدیریت کند.

کشف باگ‌های یکپارچه‌سازی: می‌تواند باگ‌هایی را کشف کند که در تعامل بین ویژگی‌های مختلف رخ می‌دهند.

ارتباط بهتر: سناریوها به راحتی توسط ذینفعان کسب‌وکار قابل درک هستند.

بهینه‌سازی تلاش تست: با تمرکز بر سناریوهای مهم، می‌توان تلاش تست را بهینه‌سازی کرد.

معایب تست مبتنی بر سناریو:

پوشش محدود: ممکن است تمام ویژگی‌ها و عملکردهای سیستم را پوشش ندهد.

نیاز به دانش کسب‌وکار: طراحی سناریوهای خوب نیاز به درک عمیق از کسب‌وکار و نیازهای کاربران دارد.

مثال:
در یک وب‌سایت رزرو هتل، یک سناریو می‌تواند به صورت زیر باشد:

سناریو: یک خانواده برای تعطیلات خود یک هتل رزرو می‌کند.

کاربر وارد وب‌سایت می‌شود.

مقصد، تاریخ ورود و خروج، و تعداد مسافران را وارد می‌کند.

نتایج جستجو را بر اساس قیمت و امتیاز فیلتر می‌کند.

یک هتل را انتخاب می‌کند و جزئیات آن را مشاهده می‌کند.

یک اتاق خانوادگی را انتخاب می‌کند.

به صفحه پرداخت می‌رود و اطلاعات خود و کارت اعتباری را وارد می‌کند.

رزرو را تأیید می‌کند.

یک ایمیل تأیید رزرو دریافت می‌کند.

چند روز بعد، وارد حساب کاربری خود می‌شود و رزرو خود را لغو می‌کند.

یک ایمیل تأیید لغو رزرو دریافت می‌کند.

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

50. تست مبتنی بر خطا (Error Guessing) چیست؟

پاسخ:

تست مبتنی بر خطا (Error Guessing) یک تکنیک تست نرم‌افزار است که در آن تستر بر اساس تجربه، شهود و دانش خود از سیستم و خطاهای رایج برنامه‌نویسی، مناطقی از کد را که به احتمال زیاد دارای باگ هستند، حدس می‌زند و تست‌هایی را برای کشف این باگ‌ها طراحی می‌کند. این یک روش غیررسمی و بدون ساختار است که به شدت به مهارت و تجربه تستر بستگی دارد.

ویژگی‌های کلیدی تست مبتنی بر خطا:

مبتنی بر تجربه: بر اساس تجربه و دانش تستر از خطاهای رایج.

غیررسمی: بدون هیچ فرآیند یا مستندات رسمی.

تمرکز بر مناطق پرخطر: تمرکز بر مناطقی که به احتمال زیاد دارای باگ هستند.

مناطقی که معمولاً در تست مبتنی بر خطا مورد هدف قرار می‌گیرند:

ورودی‌های خالی یا نال: ارسال فرم‌ها با فیلدهای خالی.

مقادیر مرزی: تست با مقادیر حداقل، حداکثر، و نزدیک به آنها.

ورودی‌های نامعتبر: وارد کردن حروف در فیلدهای عددی، ایمیل‌های نامعتبر.

تزریق کد: تلاش برای تزریق کدهای SQL یا اسکریپت‌های مخرب.

مدیریت حافظه: بررسی نشت حافظه یا خطاهای مربوط به تخصیص حافظه.

شرایط رقابتی (Race Conditions): تست عملکردهایی که به صورت همزمان انجام می‌شوند.

مزایای تست مبتنی بر خطا:

کشف سریع باگ‌ها: می‌تواند باگ‌های مهم را به سرعت و با تلاش کم کشف کند.

مکمل تست‌های رسمی: می‌تواند باگ‌هایی را پیدا کند که در تست‌های رسمی نادیده گرفته شده‌اند.

نیاز به منابع کم: نیاز به برنامه‌ریزی و مستندسازی ندارد.

معایب تست مبتنی بر خطا:

بستگی به مهارت تستر: موفقیت آن به شدت به مهارت و تجربه تستر وابسته است.

پوشش نامشخص: تعیین میزان پوشش تست غیرممکن است.

عدم تکرارپذیری: ممکن است بازتولید باگ‌ها دشوار باشد.

مثال:
یک تستر با تجربه در حال تست یک فرم ثبت‌نام است. او بر اساس تجربه خود، موارد زیر را تست می‌کند:

فیلد نام را خالی می‌گذارد.

در فیلد سن، یک عدد منفی یا یک رشته متنی وارد می‌کند.

در فیلد ایمیل، یک آدرس بدون @ وارد می‌کند.

در فیلد رمز عبور، یک رمز عبور بسیار طولانی یا با کاراکترهای خاص وارد می‌کند.

بر روی دکمه ثبت‌نام چندین بار پشت سر هم کلیک می‌کند.

این تست‌ها بر اساس حدس و گمان تستر در مورد نقاط ضعف احتمالی سیستم طراحی شده‌اند.

51. تست مبتنی بر دامنه (Domain Testing) چیست؟

پاسخ:

تست مبتنی بر دامنه (Domain Testing) یک تکنیک تست نرم‌افزار است که در آن موارد تست بر اساس تحلیل دامنه (Domain) یا مجموعه مقادیر ورودی یک متغیر طراحی می‌شوند. این تکنیک بر اساس روش‌های پارتیشن‌بندی هم‌ارزی (Equivalence Partitioning) و تحلیل مقدار مرزی (Boundary Value Analysis) ساخته شده است و هدف آن، انتخاب تعداد کمی از مقادیر ورودی نماینده از هر دامنه برای تست کارآمد سیستم است.

ویژگی‌های کلیدی تست مبتنی بر دامنه:

تمرکز بر دامنه ورودی: تحلیل مجموعه مقادیر ورودی.

کاهش تعداد موارد تست: انتخاب موارد تست نماینده به جای تست تمام مقادیر ممکن.

ترکیبی از تکنیک‌ها: استفاده از پارتیشن‌بندی هم‌ارزی و تحلیل مقدار مرزی.

مراحل تست مبتنی بر دامنه:

شناسایی متغیرها: شناسایی تمام متغیرهای ورودی و خروجی.

شناسایی دامنه‌ها: تعیین دامنه مقادیر معتبر و نامعتبر برای هر متغیر.

پارتیشن‌بندی هم‌ارزی: تقسیم هر دامنه به کلاس‌های هم‌ارز (Equivalence Classes) که در آنها سیستم رفتار مشابهی دارد.

تحلیل مقدار مرزی: شناسایی مقادیر مرزی (حداقل، حداکثر، نزدیک به حداقل، نزدیک به حداکثر) برای هر کلاس هم‌ارز.

طراحی موارد تست: انتخاب یک مقدار از هر کلاس هم‌ارز و تمام مقادیر مرزی برای طراحی موارد تست.

مزایای تست مبتنی بر دامنه:

کارایی بالا: کاهش قابل توجه تعداد موارد تست بدون کاهش پوشش.

پوشش جامع: اطمینان از اینکه تمام کلاس‌های ورودی و مقادیر مرزی تست شده‌اند.

شناسایی باگ‌های مرزی: بسیار مؤثر در شناسایی باگ‌هایی که در مقادیر مرزی رخ می‌دهند.

معایب تست مبتنی بر دامنه:

وابستگی به تحلیل دقیق: نیاز به تحلیل دقیق دامنه‌ها و کلاس‌های هم‌ارز دارد.

پوشش محدود برای تعاملات: ممکن است تعاملات پیچیده بین متغیرهای ورودی را پوشش ندهد.

مثال:
فرض کنید در حال تست یک فیلد سن هستید که فقط اعداد بین 18 تا 60 را قبول می‌کند.

دامنه‌ها:

نامعتبر: سن < 18

معتبر: 18 <= سن <= 60

نامعتبر: سن > 60

نامعتبر: غیر عددی

پارتیشن‌بندی هم‌ارزی:

کلاس 1: {سن | سن < 18} -> انتخاب یک مقدار: 10

کلاس 2: {سن | 18 <= سن <= 60} -> انتخاب یک مقدار: 35

کلاس 3: {سن | سن > 60} -> انتخاب یک مقدار: 70

کلاس 4: {ورودی | غیر عددی} -> انتخاب یک مقدار: "abc"

تحلیل مقدار مرزی:

مرزهای کلاس 2: 17, 18, 19, 59, 60, 61

موارد تست نهایی: 10, 17, 18, 19, 35, 59, 60, 61, 70, "abc"

این رویکرد به شما اجازه می‌دهد تا با تعداد کمی از موارد تست، پوشش جامعی از دامنه ورودی داشته باشید.

52. تست مبتنی بر ریسک (Risk-Based Testing) چیست؟

پاسخ:

تست مبتنی بر ریسک (Risk-Based Testing - RBT) یک رویکرد تست نرم‌افزار است که در آن تلاش تست بر اساس ریسک‌های شناسایی شده در پروژه اولویت‌بندی می‌شود. به جای اینکه تمام ویژگی‌ها به یک اندازه تست شوند، این روش بر روی تست ویژگی‌هایی تمرکز می‌کند که بیشترین احتمال شکست را دارند یا در صورت شکست، بیشترین تأثیر منفی را بر کسب‌وکار می‌گذارند.

ویژگی‌های کلیدی تست مبتنی بر ریسک:

اولویت‌بندی بر اساس ریسک: تلاش تست بر اساس ریسک اولویت‌بندی می‌شود.

تمرکز بر مناطق پرخطر: تمرکز بر روی ویژگی‌های با ریسک بالا.

بهینه‌سازی منابع: بهینه‌سازی استفاده از منابع محدود تست (زمان، بودجه، نیروی انسانی).

مراحل تست مبتنی بر ریسک:
شناسایی ریسک (Risk Identification): شناسایی تمام ریسک‌های ممکن در پروژه (مانند ریسک‌های فنی، کسب‌وکار، امنیتی).

تحلیل ریسک (Risk Analysis): تحلیل هر ریسک بر اساس دو عامل:

احتمال (Probability/Likelihood): احتمال وقوع ریسک چقدر است؟

تأثیر (Impact): در صورت وقوع ریسک، تأثیر آن بر کسب‌وکار چقدر است؟

اولویت‌بندی ریسک (Risk Prioritization): اولویت‌بندی ریسک‌ها بر اساس حاصل‌ضرب احتمال و تأثیر. ریسک‌های با اولویت بالا، مناطق پرخطر را مشخص می‌کنند.

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

اجرای تست (Test Execution): اجرای تست‌ها بر اساس برنامه.

نظارت بر ریسک (Risk Monitoring): نظارت مداوم بر ریسک‌ها و به‌روزرسانی برنامه تست در صورت نیاز.

مزایای تست مبتنی بر ریسک:

بهینه‌سازی تلاش تست: اطمینان از اینکه منابع تست به صورت مؤثر استفاده می‌شوند.

کاهش ریسک پروژه: با تمرکز بر مناطق پرخطر، ریسک کلی پروژه کاهش می‌یابد.

تصمیم‌گیری بهتر: به مدیران کمک می‌کند تا تصمیمات آگاهانه‌تری در مورد انتشار محصول بگیرند.

افزایش کیفیت: با تمرکز بر ویژگی‌های مهم، کیفیت کلی محصول بهبود می‌یابد.

معایب تست مبتنی بر ریسک:

نیاز به تحلیل دقیق: نیاز به تحلیل دقیق و زمان‌بر ریسک‌ها دارد.

ذهنی بودن تحلیل: تحلیل ریسک می‌تواند تا حدی ذهنی باشد.

پوشش محدود برای مناطق کم‌خطر: ممکن است مناطق کم‌خطر به اندازه کافی تست نشوند.

مثال:
در یک وب‌سایت تجارت الکترونیک، تیم تست ریسک‌های زیر را شناسایی می‌کند:

ریسک 1 (بالا): خطای درگاه پرداخت (احتمال: کم، تأثیر: بسیار بالا).

ریسک 2 (متوسط): خطای عملکرد جستجو (احتمال: متوسط، تأثیر: متوسط).

ریسک 3 (پایین): خطای نمایش صفحه «درباره ما» (احتمال: کم، تأثیر: کم).

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

53. تست مبتنی بر مدل (Model-Based Testing) چیست؟

پاسخ:

تست مبتنی بر مدل (Model-Based Testing - MBT) یک رویکرد تست نرم‌افزار است که در آن موارد تست به صورت خودکار از یک مدل (Model) که رفتار مورد انتظار سیستم را توصیف می‌کند، تولید می‌شوند. این مدل معمولاً یک نمایش گرافیکی از رفتار سیستم است (مانند نمودارهای حالت، نمودارهای فعالیت یا نمودارهای جریان) و به عنوان یک منبع واحد برای درک و تست سیستم عمل می‌کند.

ویژگی‌های کلیدی تست مبتنی بر مدل:

تولید خودکار تست: موارد تست به صورت خودکار از مدل تولید می‌شوند.

استفاده از مدل: مدل به عنوان یک نمایش انتزاعی از رفتار سیستم عمل می‌کند.

پوشش جامع: امکان تولید تست‌هایی برای پوشش تمام مسیرها و حالت‌های ممکن در مدل.

مراحل تست مبتنی بر مدل:

مدل‌سازی سیستم (Modeling the System): ایجاد یک مدل از رفتار سیستم تحت تست (SUT).

تولید تست (Generating Tests): استفاده از یک ابزار MBT برای تولید خودکار موارد تست از مدل. این ابزار می‌تواند تست‌ها را بر اساس معیارهای مختلف پوشش (مانند پوشش حالت، پوشش انتقال) تولید کند.

اجرای تست (Executing Tests): اجرای تست‌های تولید شده بر روی سیستم.

مقایسه نتایج (Comparing Results): مقایسه نتایج واقعی با نتایج مورد انتظار که از مدل استخراج شده‌اند.

به‌روزرسانی مدل (Updating the Model): به‌روزرسانی مدل در صورت تغییر در الزامات یا رفتار سیستم.

مزایای تست مبتنی بر مدل:

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

پوشش بهتر: امکان تولید تست‌هایی برای پوشش سناریوهای پیچیده که ممکن است در تست دستی نادیده گرفته شوند.

شناسایی زودهنگام باگ‌ها: فرآیند مدل‌سازی می‌تواند به شناسایی ابهامات و ناسازگاری‌ها در الزامات کمک کند.

قابلیت نگهداری بالا: با تغییر سیستم، فقط نیاز به به‌روزرسانی مدل است و تست‌ها به صورت خودکار دوباره تولید می‌شوند.

معایب تست مبتنی بر مدل:

نیاز به مهارت مدل‌سازی: ایجاد مدل‌های دقیق و کامل نیاز به مهارت و تخصص دارد.

پیچیدگی ابزارها: ابزارهای MBT می‌توانند پیچیده و گران باشند.

یادگیری دشوار: نیاز به یادگیری یک رویکرد جدید و ابزارهای مرتبط دارد.

مثال:
برای تست یک دستگاه خودپرداز (ATM)، می‌توان یک مدل نمودار حالت ایجاد کرد که حالت‌های مختلف (مانند حالت آماده به کار، حالت انتظار برای پین، حالت انتخاب عملیات) و انتقال‌های بین آنها (مانند وارد کردن کارت، وارد کردن پین صحیح، انتخاب گزینه برداشت وجه) را نشان می‌دهد.

سپس، یک ابزار MBT می‌تواند از این مدل برای تولید خودکار موارد تست استفاده کند، مانند:

وارد کردن کارت -> وارد کردن پین صحیح -> انتخاب برداشت وجه -> وارد کردن مبلغ معتبر -> دریافت پول و کارت.

وارد کردن کارت -> وارد کردن پین اشتباه (3 بار) -> مسدود شدن کارت.

وارد کردن کارت -> انتخاب گزینه موجودی -> مشاهده موجودی -> خروج.

این رویکرد به شما اجازه می‌دهد تا به صورت سیستماتیک تمام مسیرهای ممکن در رفتار سیستم را تست کنید.

54. تست جهش (Mutation Testing) چیست؟

پاسخ:

تست جهش (Mutation Testing) یک تکنیک تست نرم‌افزار است که برای ارزیابی کیفیت مجموعه تست‌های موجود (Test Suite) استفاده می‌شود. در این روش، تغییرات کوچکی (جهش یا Mutation) به صورت عمدی در کد منبع ایجاد می‌شود تا نسخه‌های معیوب یا «جهش‌یافته» (Mutants) از برنامه ایجاد شوند. سپس، مجموعه تست بر روی این جهش‌یافته‌ها اجرا می‌شود. هدف این است که تست‌ها بتوانند این جهش‌ها را شناسایی کرده و شکست بخورند. اگر یک تست برای یک جهش‌یافته شکست بخورد، گفته می‌شود که آن جهش‌یافته «کشته شده» (Killed) است. اگر هیچ تستی برای یک جهش‌یافته شکست نخورد، آن جهش‌یافته «زنده مانده» (Survived) است.

ویژگی‌های کلیدی تست جهش:

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

ایجاد جهش: تغییرات کوچک و عمدی در کد منبع.

کشتن جهش‌یافته‌ها: هدف، کشتن هرچه بیشتر جهش‌یافته‌ها است.

مراحل تست جهش:

اجرای تست‌های اصلی: اجرای مجموعه تست بر روی کد اصلی برای اطمینان از اینکه همه تست‌ها پاس می‌شوند.

ایجاد جهش‌یافته‌ها: ایجاد نسخه‌های متعدد از کد منبع که هر کدام یک تغییر کوچک دارند (مثلاً تغییر + به -، تغییر > به <، حذف یک دستور).

اجرای تست‌ها بر روی جهش‌یافته‌ها: اجرای مجموعه تست بر روی هر جهش‌یافته.

تحلیل نتایج:

جهش‌یافته کشته شده (Killed Mutant): حداقل یک تست برای این جهش‌یافته شکست خورده است. این نتیجه مطلوب است و نشان می‌دهد که مجموعه تست به اندازه کافی قوی است تا این نوع خطا را تشخیص دهد.

جهش‌یافته زنده مانده (Survived Mutant): هیچ تستی برای این جهش‌یافته شکست نخورده است. این نشان‌دهنده یک ضعف در مجموعه تست است و باید یک تست جدید برای کشتن این جهش‌یافته نوشته شود.

جهش‌یافته معادل (Equivalent Mutant): جهش‌یافته‌ای که از نظر عملکردی با کد اصلی یکسان است و نمی‌توان آن را با هیچ تستی کشت. این جهش‌یافته‌ها باید به صورت دستی شناسایی و نادیده گرفته شوند.

محاسبه امتیاز جهش (Mutation Score):
امتیاز جهش = (تعداد جهش‌یافته‌های کشته شده / (تعداد کل جهش‌یافته‌ها - تعداد جهش‌یافته‌های معادل)) * 100

امتیاز جهش بالا نشان‌دهنده کیفیت بالای مجموعه تست است.

مزایای تست جهش:

ارزیابی دقیق کیفیت تست: یک معیار دقیق برای ارزیابی قدرت مجموعه تست فراهم می‌کند.

بهبود مجموعه تست: به شناسایی نقاط ضعف در مجموعه تست و بهبود آن کمک می‌کند.

افزایش اعتماد به تست‌ها: اطمینان حاصل می‌کند که تست‌ها واقعاً کد را به درستی بررسی می‌کنند.

معایب تست جهش:

بسیار زمان‌بر و پرهزینه: نیاز به اجرای مجموعه تست برای هر جهش‌یافته دارد که می‌تواند بسیار کند باشد.

پیچیدگی ابزارها: نیاز به ابزارهای تخصصی برای ایجاد و مدیریت جهش‌یافته‌ها دارد.

مشکل جهش‌یافته‌های معادل: شناسایی جهش‌یافته‌های معادل می‌تواند دشوار و زمان‌بر باشد.

مثال:
فرض کنید کد زیر را دارید:

public int Max(int a, int b) { if (a > b) return a; else return b; }

و تست زیر را برای آن نوشته‌اید:

[Fact] public void Max_ReturnsLargerValue() { Assert.Equal(5, Max(5, 3)); }

یک ابزار تست جهش، جهش‌یافته زیر را ایجاد می‌کند:

public int Max(int a, int b) { if (a >= b) // جهش: تغییر > به >= return a; else return b; }

تست شما همچنان برای این جهش‌یافته پاس می‌شود (چون 5 >= 3 نیز درست است). بنابراین، این جهش‌یافته زنده می‌ماند. این نشان می‌دهد که تست شما به اندازه کافی قوی نیست. برای کشتن این جهش‌یافته، باید یک تست جدید اضافه کنید که این دو حالت را از هم متمایز کند، مانند:

[Fact] public void Max_ReturnsCorrectValue_WhenInputsAreEqual() { Assert.Equal(5, Max(5, 5)); }

55. تست مبتنی بر ویژگی (Property-Based Testing) چیست؟

پاسخ:

تست مبتنی بر ویژگی (Property-Based Testing) یک تکنیک تست نرم‌افزار است که در آن به جای نوشتن تست برای هر ورودی و خروجی خاص، ویژگی‌ها (Properties) یا قوانین کلی که باید برای هر ورودی معتبری صادق باشند، تعریف و تست می‌شوند. سپس، یک چارچوب تست مبتنی بر ویژگی، تعداد زیادی از داده‌های ورودی تصادفی را تولید می‌کند و بررسی می‌کند که آیا این ویژگی‌ها برای تمام این داده‌ها برقرار هستند یا خیر. اگر یک مورد نقض‌کننده (Counter-example) پیدا شود، چارچوب آن را به عنوان یک تست شکست خورده گزارش می‌دهد و سعی می‌کند آن را به ساده‌ترین حالت ممکن کوچک کند (Shrinking).

ویژگی‌های کلیدی تست مبتنی بر ویژگی:

تمرکز بر ویژگی‌ها: تعریف قوانین کلی به جای تست موارد خاص.

تولید خودکار داده: تولید تعداد زیادی از داده‌های ورودی تصادفی.

کوچک‌سازی موارد نقض‌کننده: ساده‌سازی موارد شکست خورده برای عیب‌یابی آسان‌تر.

تفاوت با تست مبتنی بر مثال (Example-Based Testing):

تست مبتنی بر مثال (سنتی): شما ورودی و خروجی مورد انتظار را مشخص می‌کنید (مثلاً Assert.Equal(5, Add(2, 3))).

تست مبتنی بر ویژگی: شما یک ویژگی کلی را تعریف می‌کنید (مثلاً «جمع دو عدد خاصیت جابجایی دارد: a + b == b + a») و چارچوب تست، صدها مثال را برای شما تولید و بررسی می‌کند.

مزایای تست مبتنی بر ویژگی:

پوشش بهتر: می‌تواند موارد مرزی و غیرمنتظره‌ای را پیدا کند که ممکن است در تست دستی نادیده گرفته شوند.

کاهش تعداد تست‌ها: یک تست مبتنی بر ویژگی می‌تواند جایگزین ده‌ها تست مبتنی بر مثال شود.

افکار عمیق‌تر: شما را وادار می‌کند تا در مورد رفتار و قوانین کلی کد خود عمیق‌تر فکر کنید.

عیب‌یابی آسان‌تر: با کوچک‌سازی موارد نقض‌کننده، عیب‌یابی آسان‌تر می‌شود.

معایب تست مبتنی بر ویژگی:

یادگیری دشوار: نیاز به تغییر ذهنیت و یادگیری یک رویکرد جدید دارد.

دشواری در تعریف ویژگی‌ها: تعریف ویژگی‌های خوب و معنادار می‌تواند چالش‌برانگیز باشد.

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

ویژگی 1: اگر یک لیست را دو بار معکوس کنید، به لیست اصلی می‌رسید.
ForAll(list => Assert.Equal(list, Reverse(Reverse(list))))

ویژگی 2: طول لیست معکوس شده با طول لیست اصلی برابر است.
ForAll(list => Assert.Equal(list.Count, Reverse(list).Count))

ویژگی 3: اولین عنصر لیست معکوس شده، آخرین عنصر لیست اصلی است.
ForAll(list => list.Any() ? Assert.Equal(list.Last(), Reverse(list).First()) : true)

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

ویژگی	تست Smoke (Smoke Testing)	تست Sanity (Sanity Testing)
هدف اصلی	تأیید پایداری و عملکرد اصلی بیلد جدید. آیا بیلد به اندازه کافی پایدار است که بتوان تست‌های عمیق‌تر را روی آن انجام داد؟	تأیید اینکه تغییرات کوچک (رفع باگ یا ویژگی جدید) به درستی کار می‌کنند و هیچ عملکرد مرتبطی را خراب نکرده‌اند.
زمان اجرا	معمولاً پس از هر بیلد جدید نرم‌افزار (روزانه یا پس از هر کامیت مهم).	پس از دریافت یک بیلد با تغییرات کوچک (مانند رفع باگ یا افزودن ویژگی کوچک).
دامنه تمرکز	عملکردهای اصلی سیستم را پوشش می‌دهد و تأیید می‌کند که بیلد پایدار است. (Wide & Shallow)	بر روی تغییرات جدید و مناطق مرتبط تمرکز دارد و تأیید می‌کند که تغییرات به درستی کار می‌کنند و عملکرد موجود را خراب نکرده‌اند. (Narrow & Deep)
چه کسی انجام می‌دهد؟	توسعه‌دهندگان (پس از کامپایل) یا تیم QA (پس از دریافت بیلد).	معمولاً توسط تیم QA.
هدف نهایی	تصمیم‌گیری در مورد اینکه آیا بیلد برای تست‌های عمیق‌تر مناسب است یا خیر.	تصمیم‌گیری در مورد اینکه آیا بیلد با تغییرات جدید برای انتشار یا تست‌های جامع‌تر مناسب است یا خیر.
مثال	پس از هر بیلد جدید، تست می‌شود که آیا برنامه نصب می‌شود، اجرا می‌شود و صفحه اصلی بارگذاری می‌شود.	پس از رفع یک باگ در فرم ورود، تست می‌شود که آیا باگ رفع شده و فرم ورود همچنان به درستی کار می‌کند.

ویژگی	تست Functional (عملکردی)	تست Non-Functional (غیرعملکردی)
هدف اصلی	تأیید اینکه سیستم چه کاری انجام می‌دهد (What the system does). آیا سیستم الزامات عملکردی را برآورده می‌کند؟	تأیید اینکه سیستم چگونه کاری را انجام می‌دهد (How the system performs). آیا سیستم الزامات کیفی را برآورده می‌کند؟
تمرکز	بر روی ویژگی‌ها و عملکردهای خاص سیستم (مثلاً ورود به سیستم، ثبت سفارش، جستجو).	بر روی جنبه‌های کیفی سیستم مانند عملکرد (Performance)، امنیت (Security)، قابلیت استفاده (Usability)، قابلیت اطمینان (Reliability)، مقیاس‌پذیری (Scalability) و غیره.
مثال‌ها	تست واحد (Unit Testing)، تست یکپارچه‌سازی (Integration Testing)، تست سیستم (System Testing)، تست پذیرش (Acceptance Testing)، تست رگرسیون (Regression Testing)، تست Smoke، تست Sanity.	تست عملکرد (Performance Testing)، تست امنیت (Security Testing)، تست قابلیت استفاده (Usability Testing)، تست قابلیت اطمینان (Reliability Testing)، تست سازگاری (Compatibility Testing)، تست قابلیت نگهداری (Maintainability Testing)، تست قابلیت حمل (Portability Testing)، تست بین‌المللی‌سازی (Internationalization Testing)، تست بومی‌سازی (Localization Testing).
تکنیک‌ها	تست جعبه سیاه (Black-box Testing)، تست جعبه سفید (White-box Testing)، تست جعبه خاکستری (Gray-box Testing).	تست‌های مبتنی بر ابزار، تست‌های دستی، شبیه‌سازی بار، تحلیل آسیب‌پذیری.
سوال کلیدی	آیا این ویژگی کار می‌کند؟ آیا خروجی صحیح است؟	آیا این ویژگی به اندازه کافی سریع است؟ آیا امن است؟ آیا استفاده از آن آسان است؟

ویژگی	تست Black-box (جعبه سیاه)	تست White-box (جعبه سفید)	تست Gray-box (جعبه خاکستری)
دانش از ساختار داخلی	هیچ دانشی از ساختار داخلی، کد یا طراحی سیستم وجود ندارد. تستر فقط با رابط کاربری و ورودی/خروجی سیستم سروکار دارد.	دانش کامل از ساختار داخلی، کد، طراحی و پیاده‌سازی سیستم وجود دارد.	دانش جزئی از ساختار داخلی و کد وجود دارد، اما نه به اندازه تست جعبه سفید. تستر ممکن است به پایگاه داده، APIها یا اسناد طراحی دسترسی داشته باشد.
تمرکز	بر روی عملکردها و الزامات کاربر. آیا سیستم کاری را که قرار است انجام دهد، انجام می‌دهد؟	بر روی جریان کنترل، منطق و ساختار کد. آیا تمام مسیرهای کد تست شده‌اند؟ آیا باگ‌های داخلی وجود دارد؟	بر روی ترکیبی از عملکردها و ساختار داخلی. تست عملکردی با در نظر گرفتن دانش جزئی از پیاده‌سازی.
چه کسی انجام می‌دهد؟	تیم QA، کاربران نهایی، تست‌کنندگان مستقل.	توسعه‌دهندگان، تست‌کنندگان با دانش برنامه‌نویسی.	تیم QA با دانش برنامه‌نویسی یا توسعه‌دهندگان.
تکنیک‌ها	پارتیشن‌بندی هم‌ارزی (Equivalence Partitioning)، تحلیل مقدار مرزی (Boundary Value Analysis)، جدول تصمیم (Decision Table Testing)، تست حالت (State Transition Testing)، تست Use Case.	پوشش دستور (Statement Coverage)، پوشش تصمیم (Decision Coverage)، پوشش مسیر (Path Coverage)، پوشش شرط (Condition Coverage)، تست حلقه (Loop Testing).	تست ماتریس (Matrix Testing)، تست رگرسیون (Regression Testing)، تست الگو (Pattern Testing)، تست رگرسیون خودکار.
مزایا	دیدگاه کاربر نهایی، شناسایی باگ‌های رابط کاربری، عدم نیاز به دانش برنامه‌نویسی.	پوشش جامع کد، شناسایی باگ‌های داخلی، بهینه‌سازی کد.	ترکیبی از مزایای هر دو، پوشش بهتر باگ‌های عملکردی و داخلی، کارایی بیشتر.
معایب	پوشش محدود کد، ممکن است باگ‌های داخلی را نادیده بگیرد.	نیاز به دانش برنامه‌نویسی، زمان‌بر، ممکن است دیدگاه کاربر نهایی را نادیده بگیرد.	نیاز به دانش جزئی از کد، ممکن است به اندازه جعبه سفید جامع نباشد.

ویژگی	تست Static (ایستا)	تست Dynamic (پویا)
زمان اجرا	بدون اجرای کد. در مراحل اولیه چرخه توسعه (مانند فاز تحلیل و طراحی) یا بر روی کد منبع قبل از کامپایل و اجرا.	با اجرای کد. پس از کامپایل و اجرای نرم‌افزار.
هدف اصلی	شناسایی خطاها، نقص‌ها، ناسازگاری‌ها و مشکلات کیفیت در اسناد، طراحی و کد منبع در مراحل اولیه.	شناسایی خطاها، نقص‌ها و مشکلات در رفتار و عملکرد واقعی نرم‌افزار در زمان اجرا.
چه کسی انجام می‌دهد؟	توسعه‌دهندگان، تست‌کنندگان، تحلیلگران کسب‌وکار.	تیم QA، کاربران نهایی.
تکنیک‌ها	بازبینی‌ها (Reviews)، بازرسی‌ها (Inspections)، واک‌ثرو (Walkthroughs)، تحلیل استاتیک کد (Static Code Analysis) با استفاده از ابزارها.	تست واحد (Unit Testing)، تست یکپارچه‌سازی (Integration Testing)، تست سیستم (System Testing)، تست عملکرد (Performance Testing)، تست امنیت (Security Testing) و غیره.
مزایا	شناسایی زودهنگام باگ‌ها (که رفع آنها ارزان‌تر است)، بهبود کیفیت کد، کاهش نیاز به تست‌های پویا.	تأیید رفتار واقعی سیستم، شناسایی باگ‌های زمان اجرا، ارزیابی عملکرد و امنیت.
معایب	نمی‌تواند تمام باگ‌ها را پیدا کند (به خصوص باگ‌های زمان اجرا)، نیاز به دانش عمیق از کد و استانداردها.	باگ‌ها در مراحل بعدی چرخه توسعه شناسایی می‌شوند (که رفع آنها گران‌تر است)، نیاز به محیط تست.

ویژگی	تست Positive (مثبت)	تست Negative (منفی)
هدف اصلی	تأیید اینکه سیستم به درستی کار می‌کند زمانی که ورودی‌های معتبر و مورد انتظار به آن داده می‌شود.	تأیید اینکه سیستم به درستی خطاها را مدیریت می‌کند و در برابر ورودی‌های نامعتبر، غیرمنتظره یا مخرب مقاوم است.
تمرکز	بر روی سناریوهای «موفقیت‌آمیز» (Happy Path).	بر روی سناریوهای «خطا» (Error Path) و «مخرب» (Destructive Path).
مثال	ورود به سیستم: وارد کردن نام کاربری و رمز عبور صحیح. ثبت‌نام: وارد کردن ایمیل معتبر و رمز عبور با فرمت صحیح.	ورود به سیستم: وارد کردن نام کاربری یا رمز عبور اشتباه. ثبت‌نام: وارد کردن ایمیل نامعتبر، رمز عبور کوتاه، یا تلاش برای ثبت‌نام با ایمیل تکراری.
نتیجه مورد انتظار	سیستم باید عملکرد مورد نظر را انجام دهد (مثلاً کاربر وارد سیستم شود).	سیستم باید یک پیام خطای مناسب نمایش دهد، از کرش کردن جلوگیری کند و در حالت پایدار باقی بماند.
اهمیت	تضمین می‌کند که سیستم عملکردهای اصلی خود را به درستی انجام می‌دهد.	تضمین می‌کند که سیستم قوی، پایدار و امن است و می‌تواند در برابر ورودی‌های غیرمنتظره مقاومت کند.

کلمه کلیدی	پارامتر 1	پارامتر 2
openBrowser	Chrome
navigateToURL	http://example.com/login
enterText	username_field	validuser
enterText	password_field	validpass
clickButton	login_button
verifyText	welcome_message	Welcome, validuser!
closeBrowser

سوالات مصاحبه Mocking و Stubbing - 100 سوال کامل

سوالات تست واحد و ابزارهای تست

1. تفاوت بین Mocking و Stubbing چیست؟

2. NUnit چیست و چه کاربردی دارد؟

3. Black-box testing چیست؟

4. White-box testing چیست؟

5. Gray-box testing چیست؟

6. تست واحد (Unit Testing) چیست؟

7. تست یکپارچه‌سازی (Integration Testing) چیست؟

8. تست سیستم (System Testing) چیست؟

9. تست پذیرش کاربر (User Acceptance Testing - UAT) چیست؟

10. تست رگرسیون (Regression Testing) چیست؟

11. تست عملکردی (Functional Testing) چیست؟

12. تست غیرعملکردی (Non-Functional Testing) چیست؟

13. تست Smoke (Smoke Testing) چیست؟

14. تست Sanity (Sanity Testing) چیست؟

15. تست رگرسیون چیست و چرا مهم است؟

16. تست پذیرش (Acceptance Testing) چیست؟

17. تست آلفا (Alpha Testing) چیست؟

18. تست بتا (Beta Testing) چیست؟

19. تست عملکرد (Performance Testing) چیست؟

20. تست امنیتی (Security Testing) چیست؟

21. تست قابلیت استفاده (Usability Testing) چیست؟

22. تست قابلیت اطمینان (Reliability Testing) چیست؟

23. تست سازگاری (Compatibility Testing) چیست؟

24. تست قابلیت نگهداری (Maintainability Testing) چیست؟

25. تست قابلیت حمل (Portability Testing) چیست؟

26. تست نصب (Installation Testing) چیست؟

27. تست بازیابی (Recovery Testing) چیست؟

28. تست پیمایش (Exploratory Testing) چیست؟

29. تست مبتنی بر ریسک (Risk-Based Testing) چیست؟

30. تست مبتنی بر مدل (Model-Based Testing) چیست؟

31. تست جهش (Mutation Testing) چیست؟

32. تست A/B (A/B Testing) چیست؟

33. تست قابلیت دسترسی (Accessibility Testing) چیست؟

34. تست بین‌المللی‌سازی (Internationalization Testing) چیست؟

35. تست بومی‌سازی (Localization Testing) چیست؟

36. تست Smoke و Sanity چه تفاوتی دارند؟

37. تست Functional و Non-Functional چه تفاوتی دارند؟

38. تست Black-box، White-box و Gray-box چه تفاوتی دارند؟

39. تست Static و Dynamic چه تفاوتی دارند؟

40. تست مثبت (Positive Testing) و تست منفی (Negative Testing) چه تفاوتی دارند؟

41. تست Ad-hoc چیست؟

42. تست End-to-End (E2E) چیست؟

43. تست مبتنی بر داده (Data-Driven Testing) چیست؟

44. تست مبتنی بر کلمه کلیدی (Keyword-Driven Testing) چیست؟

45. تست مبتنی بر رفتار (Behavior-Driven Development - BDD) چیست؟

46. تست مبتنی بر تست (Test-Driven Development - TDD) چیست؟

47. تست مبتنی بر پذیرش (Acceptance Test-Driven Development - ATDD) چیست؟

48. تست مبتنی بر جلسه (Session-Based Testing) چیست؟

49. تست مبتنی بر سناریو (Scenario Testing) چیست؟

50. تست مبتنی بر خطا (Error Guessing) چیست؟

51. تست مبتنی بر دامنه (Domain Testing) چیست؟

52. تست مبتنی بر ریسک (Risk-Based Testing) چیست؟

53. تست مبتنی بر مدل (Model-Based Testing) چیست؟

54. تست جهش (Mutation Testing) چیست؟

55. تست مبتنی بر ویژگی (Property-Based Testing) چیست؟

56. تست اکتشافی (Exploratory Testing) چیست؟

57. تست پیمایش (Walkthrough) چیست؟

58. تست بازرسی (Inspection) چیست؟

59. تست همتا (Peer Review) چیست؟

60. تست قابلیت استفاده (Usability Testing) چیست؟

61. تست قابلیت اطمینان (Reliability Testing) چیست؟

62. تست عملکرد (Performance Testing) چیست؟

63. تست امنیت (Security Testing) چیست؟

64. تست سازگاری (Compatibility Testing) چیست؟

65. تست قابلیت نگهداری (Maintainability Testing) چیست؟

66. تست قابلیت نصب (Installability Testing) چیست؟

67. تست قابلیت بازیابی (Recovery Testing) چیست؟

68. تست قابلیت پیکربندی (Configuration Testing) چیست؟

69. تست قابلیت دسترسی (Accessibility Testing) چیست؟

70. تست بین‌المللی‌سازی (Internationalization Testing) چیست؟

71. تست بومی‌سازی (Localization Testing) چیست؟

72. تست رگرسیون (Regression Testing) چیست؟

73. تست smoke (Smoke Testing) چیست؟

74. تست sanity (Sanity Testing) چیست؟

75. تست پذیرش کاربر (User Acceptance Testing - UAT) چیست؟

76. تست آلفا (Alpha Testing) چیست؟

77. تست بتا (Beta Testing) چیست؟

78. تست عملکردی (Functional Testing) چیست؟