تست سیستم چیست؟ راهنمای System Testing با مثال

ممکن است همهٔ سرویس‌ها جداگانه سبز باشند، اما مشتری هنوز نتواند خریدش را کامل کند. سبد خرید تخفیف را می‌پذیرد، درگاه پرداخت موفق پاسخ می‌دهد و انبار هم موجودی دارد؛ بااین‌حال ترکیب این رفتارها سفارش را در وضعیت اشتباه می‌گذارد. این همان فاصله‌ای است که تست سیستم (System Testing) باید آشکار کند: آیا کل محصول، در محدوده‌ای که «سیستم» نامیده‌ایم، رفتار و قابلیت مورد انتظار را ارائه می‌کند؟

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

تست سیستم چیست؟

بر اساس ISTQB CTFL 4.0.1، تست سیستم بر رفتار کلی و قابلیت‌های یک سیستم یا محصول کامل تمرکز دارد. این سطح معمولاً هم وظایف کارکردی سرتاسری درون سیستم و هم ویژگی‌های غیرکارکردی مرتبط را بررسی می‌کند. مبنای آزمون می‌تواند مشخصات سیستم، نیازمندی‌ها، جریان‌های کاربر، مدل‌ها، معماری و ریسک‌های محصول باشد.

سه واژه در این تعریف تعیین‌کننده‌اند:

• کل سیستم: نه یک تابع یا تعامل دو ماژول، بلکه Test Object کاملی که مرزش روشن شده است.
• رفتار و قابلیت: هم «چه کاری انجام می‌دهد» و هم «با چه سطحی از کیفیت انجام می‌دهد».
• محدودهٔ تعریف‌شده: کل سیستم الزاماً همهٔ اکوسیستم نیست؛ ممکن است درگاه، پیامک یا ERP بیرون مرز سیستم باشند.

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

سطح، نوع و تکنیک را با هم قاطی نکنیم

بخش بزرگی از سردرگمی دربارهٔ System Testing از ترکیب سه محور متفاوت می‌آید:

محور	سؤال	نمونه
سطح تست	شیء آزمون در چه مقیاسی است؟	Component، Component Integration، System، System Integration، Acceptance
نوع تست	کدام ویژگی کیفیت را ارزیابی می‌کنیم؟	Functional، Performance، Security، Usability، Reliability
تکنیک تست	چگونه مورد آزمون را استخراج می‌کنیم؟	تقسیم‌بندی هم‌ارزی، مقدار مرزی، جدول تصمیم، انتقال حالت، اکتشافی

بنابراین «تست عملکرد» رقیب تست سیستم نیست؛ Performance Testing می‌تواند در سطح سیستم انجام شود. «جعبه‌سیاه» نیز مترادف System Testing نیست. تکنیک‌های مبتنی بر مشخصات در این سطح رایج‌اند، اما تیم می‌تواند برای پوشش جریان داده، معماری یا مشاهده‌پذیری از اطلاعات ساختاری هم استفاده کند. ISTQB تصریح می‌کند انواع Functional، Non-functional، Black-box و White-box در همهٔ سطح‌ها قابل‌اعمال‌اند؛ تمرکزشان متفاوت است.

تفاوت System Testing با Integration، E2E و UAT

تست Component Integration

تمرکز بر رابط و تعامل میان اجزای داخل محصول است؛ برای مثال قرارداد میان سرویس سفارش و سرویس موجودی. این سطح ممکن است با Stub، پایگاه دادهٔ موقت یا Harness تخصصی اجرا شود. راهنمای تست یکپارچه‌سازی این مرزها، Contract و خطاهای تعامل را عمیق‌تر توضیح می‌دهد.

تست سیستم

رفتار و قابلیت کل Test Object را می‌سنجد. اگر «سیستم» ما محصول فروشگاهی شامل وب، API، سفارش و انبار باشد، سناریوی جست‌وجو تا ثبت سفارش داخل همین مرز بررسی می‌شود. برای برخی وابستگی‌های بیرونی می‌توان Simulation داشت؛ اما محدودیت حاصل باید در گزارش نوشته شود.

تست System Integration

تمرکز بر رابط سیستم تحت آزمون با سیستم‌ها و سرویس‌های بیرونی است؛ مثل درگاه پرداخت، سرویس پیامک، حسابداری یا سامانهٔ هویت سازمانی. در مدل پنج‌سطحی فعلی ISTQB این سطح از Component Integration جداست و به محیطی ترجیحاً شبیه عملیات نیاز دارد.

تست End-to-End

E2E نام رایجی برای دنبال‌کردن یک سفر کسب‌وکار از نقطهٔ آغاز تا پایان است. بسته به مرزی که طی می‌کند، ممکن است بخشی از System Testing، System Integration Testing یا حتی Acceptance باشد. هر System Test الزاماً E2E نیست و هر E2E نیز الزاماً داخل یک سیستم نمی‌ماند. نام سناریو جای تعیین Test Object و هدف را نمی‌گیرد.

تست Acceptance و UAT

Acceptance Testing روی اعتبارسنجی نیاز کسب‌وکار و نشان‌دادن آمادگی برای استقرار تمرکز دارد. UAT یکی از شکل‌های آن است؛ در کنار Operational، Contractual، Regulatory، Alpha و Beta. UAT نباید محل کشف نخستین شکست‌های پایه‌ای سیستم باشد. مقالهٔ تست پذیرش کاربر پس از بازبینی اختصاصی این خوشه، جزئیات نقش کاربران و معیار پذیرش را پوشش می‌دهد.

آیا تست سیستم همیشه مرحله‌ای پایانی است؟

در مدل ترتیبی، معمولاً خروج یک سطح ورودی سطح بعدی می‌شود؛ اما در Agile، DevOps و توسعهٔ تکرارشونده، سطح‌ها می‌توانند هم‌پوشانی زمانی داشته باشند. هر Increment ممکن است تست Component، Integration و System خود را بگیرد و مجموعهٔ رگرسیون سیستم در Pipeline بارها اجرا شود.

دو نتیجهٔ عملی:

• طراحی تست سیستم را تا «تمام‌شدن توسعه» عقب نیندازید؛ مرز، ریسک، داده و Oracle باید همراه Refinement و طراحی روشن شوند.
• سبزشدن Pipeline به‌تنهایی پایان System Testing نیست؛ آزمون اکتشافی، ویژگی‌های غیرکارکردی و سناریوهای پرریسک ممکن است Lane یا محیط دیگری بخواهند.

مبنای تست سیستم را از کجا می‌گیریم؟

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

• نیازمندی‌های سیستم، User Story و Acceptance Criteria؛
• Use Case، Event Storming، BPMN یا نمودار حالت؛
• قرارداد API، Schema، قواعد داده و پیام‌های Event؛
• معماری، Context Diagram و مرزهای اعتماد؛
• الزام‌های حقوقی، قراردادی و عملیاتی؛
• SLO، نیازمندی‌های امنیت، دسترس‌پذیری و بازیابی؛
• دادهٔ رخدادها، خطاهای Production و تغییرات اخیر؛
• ریسک‌های محصول و دانش دامنهٔ تیم.

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

چه چیزهایی را در سطح سیستم تست می‌کنیم؟

قابلیت‌های کارکردی

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

ویژگی‌های غیرکارکردی

مدل ISO/IEC 25010:2023 برای محصول ICT نه ویژگی اصلی کیفیت تعریف می‌کند و می‌تواند برای کامل‌کردن اهداف آزمون به‌کار رود. همهٔ آن‌ها در هر انتشار لازم نیستند؛ ریسک و الزام تعیین می‌کند کدام ویژگی با چه معیار قابل‌اندازه‌گیری پوشش داده شود.

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

برای ساخت NFR قابل‌سنجش، راهنمای تست غیرکارکردی را ببینید. عبارت‌هایی مانند «سیستم سریع باشد» یا «امن باشد» Oracle قابل‌آزمون نمی‌سازند.

Regression و Confirmation

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

مثال عملی تست سیستم برای فروشگاه ایرانی

فرض کنید مرز سیستم شامل وب‌اپ، API Gateway، سرویس‌های Catalog، Cart، Order و Inventory و پایگاه دادهٔ آن‌هاست. درگاه پرداخت و پیامک بیرون مرز قرار دارند و در System Test با Simulator کنترل‌شده جایگزین می‌شوند؛ صحت اتصال واقعی آن‌ها در System Integration جداگانه سنجیده خواهد شد.

ریسک‌های محصول

ریسک	اثر	شرایط تست نمونه	شاهد
قیمت یا تخفیف نادرست	زیان مالی و اختلاف با مشتری	ترکیب کالا، فروشنده، کوپن، سقف و تاریخ	ریز محاسبه و Rule نسخه‌دار
Oversell	لغو سفارش و نارضایتی	دو خرید هم‌زمان آخرین موجودی	وضعیت موجودی و Trace درخواست‌ها
سفارش دوگانه	اثر مالی و عملیاتی	تکرار درخواست ثبت سفارش	شناسه Idempotency و تعداد Order
دسترسی بین کاربران	افشای داده	مشاهده سفارش حساب دیگر	پاسخ و Audit log حذف‌شده از داده حساس
حالت نامعتبر	ارسال یا حسابداری غلط	لغو پس از ارسال یا پرداخت دیرهنگام	تاریخچه حالت و Eventها

سناریوی اصلی و Oracle چندلایه

1. کاربر کالای موجود را جست‌وجو و به سبد اضافه می‌کند.
2. کوپن معتبر طبق قواعد اعمال می‌شود.
3. آدرس و روش ارسال انتخاب می‌شود.
4. Simulator پرداخت پاسخ موفق و شناسهٔ یکتا برمی‌گرداند.
5. سیستم یک سفارش می‌سازد، موجودی را یک‌بار کم می‌کند و اعلان را Queue می‌کند.
6. کاربر فقط سفارش خودش را در وضعیت درست می‌بیند.

Oracle فقط «پیام موفقیت نمایش داده شد» نیست. باید مبلغ، رکورد سفارش، وضعیت، موجودی، اثر جانبی، مجوز، Log و قابلیت تکرار امن درخواست را بررسی کنید. اگر تنها UI را Assert کنید، ممکن است زیر صفحه دادهٔ ناسازگار باقی مانده باشد.

سناریوهای منفی و استثنایی

• کوپن منقضی، مخصوص فروشندهٔ دیگر یا فراتر از سقف؛
• تغییر قیمت یا موجودی میان افزودن به سبد و ثبت سفارش؛
• دو Tab، Double-click یا Retry شبکه؛
• پاسخ نامشخص، Timeout و پاسخ دیرهنگام Simulator پرداخت؛
• نشست منقضی یا نقش فاقد مجوز در میانهٔ جریان؛
• متن فارسی، نیم‌فاصله، اعداد فارسی/لاتین و آدرس طولانی؛
• تقویم، منطقهٔ زمانی، ریال/تومان و Round کردن مبلغ؛
• قطع Worker اعلان بدون تأثیر غلط بر موفقیت سفارش.

فرآیند تست سیستم؛ از مرز تا تصمیم انتشار

۱. Test Object و مرز سیستم را تعریف کنید

نام سرویس‌ها کافی نیست. یک Context Diagram ساده بسازید: داخل مرز، بیرون مرز، کاربران، داده‌های ورودی/خروجی و وابستگی‌ها. مشخص کنید کدام سرویس واقعی، کدام Sandbox و کدام Simulator است. این تصمیم روی اعتبار هر نتیجه اثر دارد.

۲. هدف و ریسک را اولویت‌بندی کنید

ریسک را از ترکیب احتمال و اثر تحلیل کنید. جریان‌های پولی، دسترسی مدیریتی، دادهٔ شخصی، مسیر پرتکرار و تغییرات معماری معمولاً عمق بیشتری می‌خواهند. «همه‌چیز P1» عملاً هیچ اولویتی نمی‌سازد.

۳. Test Basis و Traceability را آماده کنید

هر Test Condition باید به منبع و ریسک متصل باشد. یک ماتریس سبک «ریسک/نیازمندی → شرایط تست → Test Case/Charter → نتیجه → نقص» برای تصمیم کافی است؛ هدف تولید سند حجیم نیست.

۴. رویکرد، تکنیک و Oracle را انتخاب کنید

• تقسیم‌بندی هم‌ارزی و مقدار مرزی برای ورودی‌ها و سقف‌ها؛
• جدول تصمیم برای تخفیف، مجوز و ترکیب قواعد؛
• انتقال حالت برای سفارش، پرداخت و بازگشت وجه؛
• Use Case برای سفرهای کسب‌وکار؛
• Exploratory Testing برای ریسک‌های ناشناخته و تعامل‌های پیچیده؛
• Structural coverage برای جریان‌ها یا معماری حساس، در صورت نیاز.

برای نوشتن مورد آزمون با پیش‌شرط، داده و نتیجهٔ قابل‌مشاهده از راهنمای نوشتن تست‌کیس استفاده کنید. موارد شناخته‌شده را Scripted نگه دارید و برای ناشناخته‌ها Charter بسازید؛ تست اکتشافی ساختاریافته مکمل Suite است.

۵. محیط و داده را قابل‌اعتماد کنید

نسخهٔ Build، Flagها، Migration، پیکربندی، Clock، Queue و دادهٔ Seed باید معلوم باشند. محیط نماینده به معنای کپی کامل Production نیست؛ باید تفاوت‌هایی که نتیجه را منحرف می‌کنند شناسایی و کنترل شوند. از دادهٔ شخصی واقعی استفاده نکنید؛ دادهٔ مصنوعیِ رابطه‌مند بسازید.

۶. اجرا را لایه‌بندی کنید

1. Deployment verification: نسخه، Migration و سلامت وابستگی‌های داخل مرز.
2. Smoke: چند قابلیت حیاتی برای تشخیص Build غیرقابل‌آزمون.
3. Critical journeys: جریان‌های درآمدی، داده‌ای و مجوزی پرریسک.
4. Feature coverage: قواعد مثبت، منفی، مرزی و حالت‌ها.
5. Non-functional sessions: در محیط و زمان مناسب هر ویژگی.
6. Regression و Exploratory: اثر تغییر و ریسک ناشناخته.

نتیجهٔ Blocked را Fail ننامید و هر Fail را فوراً Defect محصول فرض نکنید. داده، محیط، تست و محصول باید Triage شوند. مقالهٔ اجرای تست در STLC قرارداد وضعیت و شواهد را توضیح می‌دهد.

۷. نقص را تحلیل و اصلاح را دوباره بررسی کنید

گزارش شامل Build، محیط، نقش، داده، مراحل، Expected/Actual و شاهد باشد. پس از Fix، همان شکست را Confirmation و ناحیهٔ اثر را Regression کنید. بسته‌شدن Ticket جای اجرای دوباره نیست.

۸. خروج را با ریسک باقیمانده گزارش کنید

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

چک‌لیست آمادگی محیط تست سیستم

• Artifact یا Image دقیق و تغییرناپذیر شناسایی شده است.
• نسخهٔ Schema و Migration با Build سازگار است.
• Feature Flag و پیکربندی حساس با Baseline مقایسه شده است.
• وابستگی‌های داخل مرز سالم و وابستگی‌های بیرونی مشخصاً Sandbox/Simulator هستند.
• حساب‌های نقش‌محور و Tenantهای مستقل ساخته شده‌اند.
• دادهٔ Seed، حالت اولیه، Reset و مالک پاک‌سازی تعریف شده است.
• Log، Metric، Trace و Correlation ID قابل‌دسترسی‌اند.
• زمان، منطقهٔ زمانی، Locale فارسی و واحد پول معلوم‌اند.
• محدودیت ظرفیت و تفاوت با Production مستند است.
• مسیر گزارش رخداد و توقف آزمون‌های پرخطر روشن است.

اتوماسیون تست سیستم؛ چه چیزی را کجا خودکار کنیم؟

Suite سیستم معمولاً گران‌تر و کندتر از Component/Integration است. هدف، بیشترین تعداد تست UI نیست؛ هدف بازخورد قابل‌اعتماد در لایهٔ مناسب است.

• قواعد محاسبه و حالت‌ها را تا جای ممکن در سطح پایین‌تر سریع پوشش دهید.
• در سطح سیستم، تعداد محدودتری از سفرهای حیاتی، قراردادهای کل محصول و رگرسیون‌های ارزشمند را نگه دارید.
• UI را برای چیزی استفاده کنید که واقعاً نیازمند UI است؛ Setup داده را از API یا Fixture پایدار انجام دهید.
• Clock، پرداخت و پیامک را با Test Double کنترل‌پذیر کنید و سناریوی اتصال واقعی را در System Integration جدا نگه دارید.
• هر تست باید مالک، دادهٔ مستقل، Cleanup، Timeout و Diagnostic قابل‌فهم داشته باشد.
• تست Flaky را بدون سیاست Quarantine رها نکنید؛ سبز کاذب و Retry پنهان اعتماد Suite را از بین می‌برد.

یک Lane سریع می‌تواند روی هر تغییر Smoke و چند Critical journey اجرا کند؛ Suite گسترده‌تر زمان‌بندی‌شده یا پیش از انتشار اجرا شود. طراحی این Laneها بخشی از برنامه‌ریزی تست است.

معیار ورود و خروج مناسب چیست؟

نمونهٔ معیار ورود

• Build قابل‌استقرار و نسخه‌گذاری‌شده در محیط هدف قرار دارد.
• Smoke سطح‌های پایین‌تر و قراردادهای حیاتی وضعیت قابل‌قبول دارند.
• Test Basis، ریسک‌ها و تغییرات Release قابل‌دسترسی‌اند.
• محیط، داده، ابزار و مشاهده‌پذیری آماده‌اند.
• نقص مسدودکنندهٔ شناخته‌شده برای هدف آزمون وجود ندارد یا تصمیمش ثبت شده است.

نمونهٔ معیار خروج

• سناریوهای حیاتی برنامه‌ریزی‌شده اجرا شده و نتیجهٔ معتبر دارند.
• پوشش ریسک‌های بالا و نیازمندی‌های حیاتی قابل‌ردیابی است.
• نقص‌های باز بر اساس شدت، احتمال، اثر و Workaround ارزیابی شده‌اند.
• ویژگی‌های غیرکارکردی موردنیاز معیار پذیرش خود را دارند.
• Regression مرتبط و Confirmation اصلاح‌ها انجام شده است.
• محدودیت‌ها و ریسک باقیمانده با مالک تصمیم به ذی‌نفعان گزارش شده‌اند.

«صفر باگ» معیار واقع‌بینانه‌ای نیست و «صددرصد Pass» نیز اگر موارد Blocked یا پوشش ناقص پنهان شده باشند، نشانهٔ آمادگی نیست. خروج یک تصمیم زمینه‌محور دربارهٔ ریسک است.

متریک‌های مفید برای تست سیستم

متریک	پرسش تصمیم	هشدار تفسیر
پوشش ریسک/نیازمندی	کدام ریسک حیاتی هنوز شاهد ندارد؟	تعداد Test Case معادل عمق پوشش نیست.
نتیجه به تفکیک Criticality	آیا جریان‌های حیاتی قابل‌اتکا هستند؟	Pass Rate کل، تست‌های کم‌اهمیت و مهم را مخلوط می‌کند.
نقص باز به سن و اثر	چه ریسک شناخته‌شده‌ای وارد Release می‌شود؟	تعداد خام Defect کیفیت را اندازه نمی‌گیرد.
Blocked و Invalid	چقدر از بازخورد به محیط/داده گیر کرده؟	تبدیل آن‌ها به Fail علت عملیاتی را پنهان می‌کند.
Flaky rate	آیا می‌توان به سیگنال اتوماسیون اعتماد کرد؟	Retry خودکار می‌تواند خرابی را مخفی کند.
زمان بازخورد Critical path	پس از تغییر، چه زمانی ریسک حیاتی روشن می‌شود؟	صرفاً کوتاه‌کردن زمان با حذف پوشش موفقیت نیست.

اشتباه‌های رایج در System Testing

• نامشخص‌گذاشتن مرز سیستم: معلوم نیست شکست متعلق به System است یا System Integration.
• فرض «همیشه جعبه‌سیاه»: اطلاعات معماری و Trace که تشخیص را بهتر می‌کند کنار گذاشته می‌شود.
• یکی‌دانستن E2E و System: Test Object و هدف پشت یک برچسب مبهم پنهان می‌شوند.
• تکرار همهٔ تست‌های سطح پایین در UI: Suite کند، شکننده و دیرتشخیص می‌شود.
• تکیه بر Happy path: Retry، هم‌زمانی، حالت نامعتبر و شکست جزئی پوشش نمی‌گیرند.
• استفاده از Production data: حریم خصوصی و قابلیت تکرار آزمون آسیب می‌بیند.
• محیط غیرنماینده بدون اعلام محدودیت: نتیجه با اطمینانی بیشتر از شواهد گزارش می‌شود.
• فشار همهٔ NFRها در یک محیط: Performance، Security و Usability نیاز محیط و مهارت یکسان ندارند.
• دروازه‌کردن QA در پایان: بازخورد دیر می‌رسد و کیفیت از مسئولیت تیمی خارج می‌شود.
• خروج بر اساس درصد Pass: ریسک‌های پوشش‌نداده و نقص‌های باز بی‌زمینه می‌مانند.

چک‌لیست نهایی تست سیستم

• Test Object، مرز داخل/خارج و وابستگی‌ها روشن است.
• هدف System با System Integration، E2E و Acceptance تفکیک شده است.
• ریسک‌ها و Test Basis به شرایط آزمون قابل‌ردیابی‌اند.
• Functional و Non-functional مرتبط بر اساس ریسک انتخاب شده‌اند.
• Oracle فقط به پیام UI محدود نیست و داده و اثر جانبی را می‌بیند.
• مسیر اصلی، جایگزین، منفی، مرزی، حالت و شرایط استثنایی پوشش دارند.
• محیط، Build، پیکربندی، داده و Test Doubleها نسخه‌پذیرند.
• تست‌های خودکار در لایهٔ مناسب و با Diagnostic کافی قرار دارند.
• Fail، Blocked و مشکل Testware در Triage از هم جدا می‌شوند.
• Confirmation، Regression و گزارش ریسک باقیمانده انجام شده است.

سوالات متداول درباره تست سیستم

تست سیستم به زبان ساده چیست؟

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

آیا System Testing همان End-to-End Testing است؟

خیر. E2E یک سفر را از ابتدا تا انتها دنبال می‌کند و ممکن است از چند سیستم بیرونی عبور کند. System Testing به مرز یک سیستم/محصول مشخص وابسته است و می‌تواند تست‌های کوچک‌تر از یک سفر کامل نیز داشته باشد.

تفاوت System Testing و Integration Testing چیست؟

Component Integration تعامل اجزای داخل محصول را می‌سنجد؛ System رفتار کل محصول را؛ و System Integration رابط محصول با سیستم‌ها و سرویس‌های بیرونی را. یک سناریو ممکن است در چند سطح شاهد متفاوت بخواهد.

آیا تست سیستم فقط دستی است؟

خیر. Smoke، سفرهای حیاتی و رگرسیون‌های پایدار می‌توانند خودکار شوند؛ آزمون اکتشافی، کاربردپذیری و برخی ارزیابی‌های زمینه‌ای به قضاوت انسانی نیاز دارند. انتخاب بر پایهٔ ارزش بازخورد و هزینهٔ نگهداری است.

چه کسی مسئول تست سیستم است؟

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

منابع و یادداشت بازبینی

مرز سطح‌ها و انواع تست در این مقاله با ISTQB CTFL ۴.۰.۱ تطبیق داده شده و مدل ویژگی‌های کیفیت به ISO/IEC ۲۵۰۱۰:۲۰۲۳ ارجاع دارد. آخرین بازبینی محتوایی: ۱۵ مرداد ۱۴۰۵. برای هر پروژه، تعریف «سیستم»، ریسک، محیط و معیارهای قراردادی خود همان پروژه بر مثال‌های عمومی مقدم است.

جمع‌بندی: تست سیستم زمانی ارزش دارد که «کل سیستم» فقط یک عبارت مبهم نباشد. مرز را بکشید، ریسک را به سناریو وصل کنید، Oracle چندلایه بسازید، محیط و داده را کنترل کنید و خروج را با ریسک باقیمانده گزارش دهید. در این صورت System Testing نه تکرار تست‌های قبلی، بلکه شواهدی منسجم دربارهٔ رفتار محصول کامل خواهد بود.