Test Data چیست؟ راهنمای داده‌های تست در تست نرم‌افزار

فرض کنید قرار است قابلیت ورود کاربران به یک سامانه را تست کنیم. تست‌کیس‌ها آماده‌اند و محیط تست هم در دسترس است؛ اما هنوز یک سؤال مهم وجود دارد: با چه داده‌ای این تست‌ها را اجرا کنیم؟

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

این داده‌های موردنیاز برای اجرای تست، Test Data یا داده تست نام دارند.

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

به همین دلیل، تهیه و مدیریت Test Data یکی از بخش‌های مهم فرایند تست نرم‌افزار است؛ به‌خصوص در تست اتوماتیک، تست API، تست پایگاه داده و سیستم‌های پیچیده‌ای مانند Microservices.

Table of Contents

Test Data چیست؟

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

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

برای مثال، در تست یک فروشگاه اینترنتی ممکن است Test Data شامل موارد زیر باشد:

اطلاعات یک کاربر
اطلاعات محصول
شناسه سفارش
مبلغ سفارش
کد تخفیف
وضعیت پرداخت
وضعیت سفارش
تاریخ ثبت سفارش

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

یک مثال ساده از Test Data

فرض کنید Test Case زیر را داریم:

Test Case: کاربر بتواند یک سفارش پرداخت‌شده را لغو کند.

برای اجرای این Test Case، احتمالاً به داده‌هایی مانند موارد زیر نیاز داریم:

Test Data	نمونه مقدار
User	کاربر فعال
Order ID	10025
Order Status	Paid
Payment Status	Successful
Cancellation	Allowed
Product	موجود

در این مثال، اگر سفارش در وضعیت Cancelled یا Delivered باشد، دیگر Test Case موردنظر شرایط لازم برای اجرا را ندارد.

پس Test Data صرفاً «ورودی» نیست؛ بلکه می‌تواند شرایط لازم برای اجرای یک تست را نیز ایجاد کند.

تفاوت Test Data با Test Case و Test Scenario

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

Test Scenario مشخص می‌کند چه قابلیت یا موقعیتی را بررسی کنیم.
Test Case مشخص می‌کند تست را با چه مراحل و شرایطی اجرا کنیم و نتیجه مورد انتظار چیست.
Test Data داده و وضعیت موردنیاز برای اجرای آن Test Case را فراهم می‌کند.

برای مثال:

Test Scenario: بررسی لغو سفارش

Test Case: کاربر یک سفارش پرداخت‌شده را لغو می‌کند و سیستم باید وضعیت سفارش را به Cancelled تغییر دهد.

Test Data: کاربر فعال + سفارش پرداخت‌شده + Order ID معتبر + محصول موجود

در نتیجه، می‌توان گفت Test Case مشخص می‌کند چه چیزی و چگونه تست شود، در حالی که Test Data مشخص می‌کند این تست با چه داده و شرایطی اجرا شود.

چرا Test Data در تست نرم‌افزار اهمیت دارد؟

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

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

بنابراین، انتخاب Test Data مناسب به تستر کمک می‌کند سناریوهای مختلف سیستم را در شرایط متفاوت بررسی کند.

پوشش سناریوهای مختلف

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

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

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

هرکدام از این سناریوها به Test Data مناسب خود نیاز دارند.

شناسایی خطاهایی که با داده‌های عادی دیده نمی‌شوند

گاهی سیستم در شرایط معمول کاملاً درست کار می‌کند، اما هنگام دریافت داده‌های خاص دچار مشکل می‌شود.

برای مثال، ممکن است یک فیلد تا ۱۰۰ کاراکتر را قبول کند، اما مشخص نباشد در مقدار ۱۰۱ کاراکتری چه اتفاقی می‌افتد. یا ممکن است سیستم با مبلغ‌های معمول درست کار کند، اما در برابر مقدار صفر، مقدار منفی یا یک عدد بسیار بزرگ رفتار نادرستی داشته باشد.

به همین دلیل، Test Data می‌تواند برای بررسی Boundary Value، داده‌های نامعتبر و شرایط استثنایی نقش مهمی داشته باشد.

افزایش قابلیت اعتماد به نتایج تست

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

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

بنابراین Test Data باید با شرایط موردنیاز Test Case هماهنگ باشد.

اهمیت Test Data در تست اتوماتیک

اهمیت Test Data در Automation Testing حتی بیشتر می‌شود. وقتی یک تست به‌صورت دستی اجرا می‌شود، تستر می‌تواند قبل از اجرا داده موردنیاز را ایجاد یا اصلاح کند. اما در تست اتوماتیک، تست باید بتواند داده موردنیاز خود را به‌شکل قابل تکرار دریافت کند.

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

به همین دلیل، در تست‌های اتوماتیک موضوعاتی مانند ایجاد Test Data، آماده‌سازی داده، Reset کردن داده و پاک‌سازی داده‌ها اهمیت پیدا می‌کنند.

در نتیجه، Test Data را نباید یک موضوع فرعی در تست نرم‌افزار در نظر گرفت. داده مناسب می‌تواند محدوده و کیفیت تست را تغییر دهد و داده نامناسب می‌تواند حتی یک Test Case درست را به تستی غیرقابل اعتماد تبدیل کند.

انواع Test Data چیست؟

Test Data را می‌توان بر اساس هدف و شرایطی که قرار است با استفاده از آن‌ها بررسی شود، به انواع مختلفی تقسیم کرد. این دسته‌بندی‌ها کاملاً مستقل از یکدیگر نیستند؛ برای مثال، یک داده می‌تواند هم‌زمان Invalid و Boundary باشد.

مهم‌ترین انواع Test Data عبارت‌اند از:

Valid Test Data

Valid Test Data داده‌ای است که مطابق قوانین و محدودیت‌های تعریف‌شده برای سیستم باشد و انتظار داریم سیستم آن را به‌درستی پردازش کند.

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

[user@example.com](mailto:user@example.com)

می‌تواند یک Valid Test Data باشد.

با استفاده از این نوع داده معمولاً سناریوهای Positive Testing بررسی می‌شوند.

Invalid Test Data

Invalid Test Data داده‌ای است که یک یا چند قانون یا محدودیت مورد انتظار سیستم را رعایت نمی‌کند.

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

ABC123

یا اگر سیستم فرمت مشخصی برای ایمیل انتظار داشته باشد:

user@

با استفاده از Invalid Test Data می‌توان بررسی کرد که سیستم در برابر ورودی‌های نامعتبر چه واکنشی نشان می‌دهد و آیا خطای مناسب را نمایش می‌دهد یا خیر.

Boundary Test Data

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

Boundary Test Data برای بررسی همین نقاط استفاده می‌شود.

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

۰
۱
۲
۹۹
۱۰۰
۱۰۱

در این مثال، 1 و 100 مرزهای معتبر و 0 و 101 مقادیر خارج از محدوده هستند.

Boundary Test Data معمولاً در کنار تکنیک Boundary Value Analysis مورد استفاده قرار می‌گیرد.

Positive Test Data

Positive Test Data برای بررسی رفتار مورد انتظار سیستم در شرایط معتبر استفاده می‌شود.

برای مثال، در یک فرم ثبت‌نام:

نام معتبر
ایمیل معتبر
شماره موبایل معتبر
رمز عبور مطابق قوانین سیستم

می‌توانند مجموعه‌ای از Positive Test Data باشند.

هدف این است که بررسی کنیم سیستم در شرایطی که داده‌ها مطابق انتظار هستند، رفتار صحیحی دارد.

Negative Test Data

Negative Test Data برای بررسی رفتار سیستم در شرایط غیرعادی، نامعتبر یا نامطلوب استفاده می‌شود.

برای مثال:

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

هدف Negative Testing صرفاً ایجاد خطا نیست؛ بلکه بررسی این است که سیستم در مواجهه با شرایط نامعتبر، رفتار کنترل‌شده و مورد انتظار داشته باشد.

Empty و Null Test Data

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

برای مثال:

فیلد نام خالی باشد.
مقدار یک فیلد null باشد.
یک پارامتر از Request حذف شود.

این موارد در تست فرم‌ها و به‌خصوص API Testing اهمیت زیادی دارند، زیرا «رشته خالی»، null و «ارسال نشدن فیلد» لزوماً یک وضعیت یکسان نیستند.

Duplicate Test Data

Duplicate Test Data برای بررسی رفتار سیستم در برابر داده‌های تکراری استفاده می‌شود.

برای مثال، اگر شماره موبایل باید برای هر کاربر یکتا باشد، می‌توان تلاش کرد کاربر دوم را با همان شماره موبایل ایجاد کرد.

یا در یک فروشگاه اینترنتی، می‌توان بررسی کرد سیستم در برابر ثبت مجدد یک Order ID یا یک درخواست تکراری چه رفتاری دارد.

این نوع داده برای بررسی Unique Constraint، Duplicate Request و Idempotency نیز می‌تواند اهمیت داشته باشد.

Large Volume Test Data

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

در این شرایط از Large Volume Test Data استفاده می‌کنیم.

برای مثال:

میلیون‌ها رکورد در Database
هزاران کاربر
تعداد زیادی سفارش
فایل بسیار بزرگ برای Upload
حجم زیادی از درخواست‌های API

این داده‌ها می‌توانند در Performance Testing، Scalability Testing و Database Testing مورد استفاده قرار گیرند.

نکته مهم این است که Large Volume Test Data با Performance Test یکی نیست؛ این داده‌ها می‌توانند برای ایجاد شرایط لازم جهت بررسی رفتار سیستم در حجم بالا استفاده شوند.

Production-like Test Data

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

به چنین داده‌هایی معمولاً Production-like Test Data گفته می‌شود.

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

Production-like بودن به معنی استفاده مستقیم از Production Data نیست. می‌توان چنین داده‌ای را با استفاده از Synthetic Data یا داده‌های واقعیِ محافظت‌شده و Mask شده ایجاد کرد.

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

Test Data را چگونه تهیه کنیم؟

بعد از مشخص کردن Test Data موردنیاز، سؤال مهم بعدی این است که این داده‌ها را از کجا و چگونه تهیه کنیم؟

روش تهیه Test Data به نوع سیستم، هدف تست، پیچیدگی داده‌ها و میزان حساسیت اطلاعات بستگی دارد. در یک پروژه کوچک ممکن است تستر بتواند داده‌ها را به‌صورت دستی ایجاد کند، اما در یک سیستم بزرگ با میلیون‌ها رکورد یا داده‌های حساس، معمولاً به روش‌های ساختاریافته‌تری مانند تولید داده مصنوعی، Masking یا ایجاد خودکار داده نیاز است.

مهم‌ترین روش‌های تهیه Test Data عبارت‌اند از:

ایجاد دستی Test Data

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

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

Name: Ali Ahmadi
Email: [ali.test@example.com](mailto:ali.test@example.com)
Mobile: 09120000000
Password: Test@123

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

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

استفاده از Production Data

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

مزیت اصلی این روش، واقع‌گرایی داده‌ها است. داده Production معمولاً شامل روابط، وضعیت‌ها و الگوهایی است که ایجاد دستی آن‌ها ممکن است بسیار دشوار باشد.

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

چندین سفارش
سفارش‌های لغوشده
پرداخت‌های موفق و ناموفق
کدهای تخفیف
سابقه خرید
اطلاعات ارسال

باشد.

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

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

استفاده از Masked Data

یکی از روش‌های کاهش ریسک استفاده از داده‌های واقعی، Data Masking است.

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

برای مثال:

Production:
Ali Ahmadi
09121234567

Masked:
Reza Karimi
09129876543

هدف این نیست که فقط چند مقدار را به‌صورت تصادفی تغییر دهیم؛ بلکه باید مطمئن شویم داده Mask شده همچنان برای سناریوی تست قابل استفاده است.

برای مثال، اگر یک سیستم به ارتباط بین Customer ID، Order ID و Payment ID وابسته باشد، تغییر تصادفی این مقادیر می‌تواند ارتباط بین داده‌ها را از بین ببرد.

بنابراین Masking در سیستم‌های پیچیده باید با توجه به ارتباط بین داده‌ها و قوانین کسب‌وکار انجام شود.

تولید Synthetic Test Data

Synthetic Data داده‌ای است که به‌صورت مصنوعی و با استفاده از قواعد، الگوریتم‌ها یا ابزارهای تولید داده ایجاد می‌شود و لزوماً از اطلاعات واقعی کاربران گرفته نشده است.

برای مثال می‌توان مجموعه‌ای از کاربران مصنوعی ایجاد کرد:

User 1 → Active → 5 Orders
User 2 → Inactive → 0 Orders
User 3 → Active → 25 Orders
User 4 → Locked → 3 Orders

مزیت مهم Synthetic Data این است که می‌توان داده را دقیقاً متناسب با نیاز تست ایجاد کرد.

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

Synthetic Data همچنین می‌تواند برای ایجاد سناریوهایی مفید باشد که در داده واقعی به‌ندرت اتفاق می‌افتند؛ مانند:

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

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

استفاده از Test Data Generator

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

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

نام
ایمیل
شماره تلفن
تاریخ
عدد
آدرس
شناسه
داده‌های ساختاریافته

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

بااین‌حال، یک نکته مهم وجود دارد:

داده تصادفی لزوماً Test Data مناسب نیست.

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

بنابراین در سیستم‌های واقعی، Test Data Generation باید علاوه بر Format داده، به Business Rules و روابط بین داده‌ها نیز توجه کند.

ایجاد Test Data از طریق API یا Database

در پروژه‌های مدرن، به‌خصوص در تست اتوماتیک، می‌توان Test Data را مستقیماً از طریق API یا Database ایجاد و آماده کرد.

برای مثال، یک تست API ممکن است ابتدا با ارسال یک Request یک کاربر ایجاد کند:

Create User
     ↓
Create Product
     ↓
Create Order
     ↓
Execute Test
     ↓
Verify Result
     ↓
Cleanup

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

البته ایجاد مستقیم داده در Database همیشه بهترین گزینه نیست. در بسیاری از پروژه‌ها بهتر است تا حد امکان از API یا روش‌های رسمی سیستم برای ایجاد State موردنیاز استفاده شود، زیرا تغییر مستقیم Database ممکن است Business Ruleهای سیستم را دور بزند.

انتخاب روش مناسب برای تهیه Test Data

هیچ روش واحدی برای تمام پروژه‌ها بهترین نیست.

ممکن است یک تیم برای تست‌های ساده از داده دستی استفاده کند، برای سناریوهای پیچیده از Synthetic Data کمک بگیرد و برای برخی تست‌ها از داده‌های واقعیِ Mask شده استفاده کند.

بنابراین هنگام انتخاب روش تهیه Test Data باید مواردی مانند این‌ها را در نظر گرفت:

نوع تست
حجم داده موردنیاز
پیچیدگی روابط بین داده‌ها
حساسیت اطلاعات
نیاز به تکرارپذیری تست
سرعت ایجاد داده
نیاز به Automation
الزامات امنیتی و حریم خصوصی

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

Test Data واقعی یا Synthetic Data؛ کدام بهتر است؟

یکی از تصمیم‌های مهم در تهیه Test Data این است که آیا از داده‌های واقعی سیستم استفاده کنیم یا داده‌های مصنوعی ایجاد کنیم.

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

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

Production Data چه زمانی می‌تواند مفید باشد؟

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

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

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

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

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

Synthetic Data چه زمانی مناسب‌تر است؟

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

برای مثال، فرض کنید می‌خواهیم تمام حالت‌های ممکن برای یک فیلد را تست کنیم. ممکن است در داده واقعی فقط تعداد کمی از این حالت‌ها وجود داشته باشد، اما با Synthetic Data می‌توانیم دقیقاً داده موردنیاز را تولید کنیم.

برای مثال:

Age = 0
Age = 1
Age = 18
Age = 65
Age = 100
Age = 101

یا می‌توانیم مجموعه‌ای از کاربران با وضعیت‌های مشخص ایجاد کنیم:

Active User
Inactive User
Locked User
New User
User with expired subscription
User with multiple orders

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

مقایسه Production Data و Synthetic Data

ویژگی	Production Data	Synthetic Data
شباهت به دنیای واقعی	بسیار بالا	قابل تنظیم
کنترل روی داده	محدودتر	بالا
ایجاد سناریوهای خاص	دشوارتر	آسان‌تر
ریسک اطلاعات حساس	بیشتر	معمولاً کمتر
ایجاد حجم زیاد داده	در صورت وجود داده مناسب، قابل استفاده	بسیار مناسب
مناسب برای Automation	با آماده‌سازی مناسب	بسیار مناسب
بازسازی داده‌های تاریخی	مناسب	می‌تواند دشوار باشد
وابستگی به داده واقعی	دارد	ندارد

آیا Synthetic Data همیشه جایگزین Production Data است؟

خیر.

Synthetic Data می‌تواند بسیاری از نیازهای تست را برطرف کند، اما در برخی پروژه‌ها داده واقعی دارای ویژگی‌ها و روابطی است که بازسازی آن‌ها دشوار است.

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

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

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

انتخاب Test Data باید بر اساس هدف تست باشد

بهتر است به‌جای اینکه بپرسیم:

«داده واقعی بهتر است یا Synthetic Data؟»

بپرسیم:

«برای این Test Case چه نوع داده‌ای بیشترین ارزش تستی را ایجاد می‌کند؟»

اگر هدف، بازسازی شرایط واقعی سیستم باشد، داده Production-like می‌تواند مناسب باشد. اگر هدف، بررسی دقیق مرزها، خطاها یا سناریوهای خاص باشد، Synthetic Data معمولاً کنترل بیشتری ایجاد می‌کند.

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

Test Data خوب چه ویژگی‌هایی دارد؟

هر داده‌ای که بتوان از آن در یک Test Case استفاده کرد، لزوماً Test Data مناسبی نیست. داده تست باید با هدف تست، شرایط موردنیاز سناریو و رفتار مورد انتظار سیستم هماهنگ باشد.

برای مثال، اگر قرار است امکان لغو یک سفارش پرداخت‌شده را بررسی کنیم، داشتن یک Order ID معتبر به‌تنهایی کافی نیست. سفارش باید وضعیت مناسبی داشته باشد تا قابلیت موردنظر قابل آزمایش باشد.

یک Test Data مناسب معمولاً ویژگی‌های زیر را دارد.

مرتبط با سناریوی تست باشد

Test Data باید مستقیماً با چیزی که قرار است تست شود ارتباط داشته باشد.

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

بنابراین قبل از ایجاد داده باید مشخص کنیم:

این Test Case برای اجرا به چه داده و چه وضعیت اولیه‌ای نیاز دارد؟

معتبر و مطابق قوانین سیستم باشد

اگر هدف تست یک سناریوی مثبت است، داده باید قوانین مورد انتظار سیستم را رعایت کند.

برای مثال، اگر سیستم برای ثبت‌نام شرایط زیر را داشته باشد:

شماره موبایل باید معتبر باشد.
ایمیل باید فرمت صحیح داشته باشد.
رمز عبور باید حداقل ۸ کاراکتر باشد.

داده مورد استفاده در Positive Test باید این شرایط را داشته باشد.

البته در Negative Testing عمداً از داده‌هایی استفاده می‌کنیم که یک یا چند قانون را نقض می‌کنند. بنابراین «معتبر بودن» همیشه به معنی معتبر بودن از دید قوانین سیستم نیست؛ بلکه داده باید متناسب با هدف Test Case باشد.

واقع‌گرایانه باشد

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

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

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

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

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

قابل تکرار باشد

یکی از ویژگی‌های مهم Test Data، Repeatability است.

اگر یک Test Case امروز با موفقیت اجرا شود، بهتر است بتوانیم در شرایط مشابه دوباره همان تست را اجرا کنیم.

برای مثال، اگر تست به کاربری با User ID = 10025 وابسته باشد و این کاربر بعد از هر اجرای تست حذف یا تغییر کند، اجرای مجدد Test Case ممکن است نتیجه متفاوتی ایجاد کند.

به همین دلیل، در تست اتوماتیک معمولاً باید برای ایجاد، Reset یا Refresh کردن داده‌ها راهکار مشخصی وجود داشته باشد.

قابل کنترل باشد

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

مثلاً اگر Test Case مربوط به سفارش‌های بیشتر از یک میلیون تومان است، بهتر است بتوانیم دقیقاً سفارش‌هایی با مبالغ مشخص ایجاد کنیم:

999,999
1,000,000
1,000,001

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

روابط بین داده‌ها حفظ شده باشد

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

User
  ↓
Order
  ↓
Payment
  ↓
Shipment

اگر Test Data فقط شامل یک User و یک Order باشد ولی ارتباط Order با Payment از بین رفته باشد، ممکن است Test Case قابل اجرا نباشد.

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

امن باشد

Test Data نباید بدون کنترل شامل اطلاعات حساس کاربران واقعی باشد.

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

اطلاعات هویتی
اطلاعات مالی
شماره تلفن
آدرس
اطلاعات حساب
اطلاعات احراز هویت

به همین دلیل، استفاده از Masked Data یا Synthetic Data می‌تواند در بسیاری از شرایط گزینه مناسب‌تری نسبت به انتقال مستقیم داده‌های Production به محیط تست باشد.

قابل پاک‌سازی باشد

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

اگر این داده‌ها بدون کنترل در محیط تست باقی بمانند، به‌مرور محیط را شلوغ می‌کنند و حتی ممکن است روی نتایج تست‌های بعدی تأثیر بگذارند.

برای همین در بسیاری از تست‌ها باید مشخص باشد:

Setup → Execute → Verify → Cleanup

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

متناسب با نوع تست باشد

یک Test Data ممکن است برای یک نوع تست مناسب باشد ولی برای نوع دیگری کافی نباشد.

برای مثال، داده‌ای که برای بررسی عملکرد یک API در یک درخواست معمولی مناسب است، لزوماً برای Performance Testing کافی نیست.

در Performance Testing ممکن است به حجم بسیار بیشتری از داده نیاز داشته باشیم تا سیستم در شرایط نزدیک به بار موردنظر بررسی شود.

بنابراین Test Data باید با هدف و نوع تست هماهنگ باشد.

جمع‌بندی ویژگی‌های Test Data مناسب

در یک نگاه، Test Data مناسب باید:

با سناریوی تست مرتبط باشد.
متناسب با هدف Test Case معتبر یا عمداً نامعتبر باشد.
در صورت نیاز واقع‌گرایانه باشد.
قابل تکرار باشد.
قابل کنترل و تغییر باشد.
روابط بین داده‌ها را به‌درستی حفظ کند.
از اطلاعات حساس محافظت کند.
در صورت نیاز قابل پاک‌سازی یا Reset باشد.
با نوع و هدف تست تناسب داشته باشد.

در پروژه‌های کوچک ممکن است توجه به چند مورد از این ویژگی‌ها کافی باشد، اما هرچه سیستم پیچیده‌تر و تست‌ها بیشتر و خودکارتر شوند، کیفیت و مدیریت Test Data به یک مسئله مستقل در فرایند تست تبدیل می‌شود.

چالش‌های مدیریت Test Data چیست؟

ایجاد چند رکورد برای اجرای یک Test Case معمولاً کار دشواری نیست. چالش اصلی زمانی شروع می‌شود که تعداد Test Caseها، تسترها، محیط‌های تست و حجم داده‌ها افزایش پیدا کند.

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

این مجموعه مسائل معمولاً تحت مفهوم Test Data Management (TDM) قرار می‌گیرد.

دسترسی به داده مناسب

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

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

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

ممکن است در محیط تست هیچ سفارشی با این وضعیت وجود نداشته باشد.

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

وابستگی بین داده‌ها

در سیستم‌های ساده ممکن است هر Test Case فقط به چند مقدار مستقل نیاز داشته باشد، اما در سیستم‌های واقعی داده‌ها اغلب به یکدیگر وابسته‌اند.

Customer
   ↓
Order
   ↓
Payment
   ↓
Shipment

برای تست یک قابلیت مربوط به سفارش، ممکن است وجود Customer، Order و Payment با وضعیت‌های مشخص ضروری باشد.

اگر یکی از این روابط وجود نداشته باشد یا وضعیت یکی از داده‌ها تغییر کرده باشد، Test Case ممکن است قابل اجرا نباشد.

این مشکل در سیستم‌های پیچیده و به‌خصوص Microservices می‌تواند بیشتر شود، زیرا داده و State موردنیاز یک سناریو ممکن است بین چند سرویس توزیع شده باشد.

تغییر داده‌ها در طول اجرای تست

Test Caseها معمولاً داده‌های سیستم را تغییر می‌دهند.

Pending → Paid

Active → Inactive

اگر تست بعدی انتظار داشته باشد داده همچنان در وضعیت اولیه باشد، نتیجه آن ممکن است به اجرای تست قبلی وابسته شود.

این مسئله یکی از دلایل مهم نیاز به Test Data Reset و ایجاد داده‌های مستقل برای تست‌هاست.

هم‌زمانی تست‌ها

در تیم‌هایی که چند تستر یا چند Test Suite به‌صورت هم‌زمان کار می‌کنند، ممکن است چند تست به یک داده مشترک دسترسی داشته باشند.

برای مثال، Test Case A سفارش شماره 10025 را به حالت Cancelled تغییر می‌دهد، در حالی که Test Case B انتظار دارد همان سفارش در وضعیت Paid باشد.

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

به همین دلیل، در تست‌های اتوماتیک معمولاً باید تا حد امکان از Shared Test Data غیرضروری جلوگیری کرد.

حجم زیاد Test Data

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

برای مثال:

تست جست‌وجو در یک Database بزرگ
Performance Testing
بررسی Pagination
تست گزارش‌گیری
تست پردازش Batch
بررسی رفتار سیستم در حجم بالای سفارش‌ها

ایجاد و نگهداری چنین داده‌ای به‌صورت دستی تقریباً غیرعملی است و معمولاً نیاز به روش‌های خودکار برای Data Generation و Data Provisioning دارد.

داده‌های حساس و محرمانه

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

کپی کردن داده Production به محیط تست ممکن است ساده به نظر برسد، اما اگر این داده‌ها شامل اطلاعات واقعی کاربران باشند، نگهداری و دسترسی به آن‌ها می‌تواند ریسک امنیتی و محرمانگی ایجاد کند.

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

Data Masking
Data Anonymization
Synthetic Data
Data Subsetting

تفاوت داده بین محیط‌های مختلف

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

Development
      ↓
Testing
      ↓
Staging
      ↓
Production

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

برای مثال، Test Case در محیط QA به یک Product ID مشخص وابسته است، اما پس از Refresh شدن Database آن Product حذف شده یا شناسه آن تغییر کرده است.

بنابراین باید مشخص باشد که Test Data در هر محیط چگونه ایجاد، به‌روزرسانی و مدیریت می‌شود.

پاک‌سازی و Reset کردن داده‌ها

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

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

برای مثال، اگر هر بار اجرای Test Suite صد کاربر جدید ایجاد کند، بعد از صدها اجرای تست ممکن است هزاران رکورد غیرضروری در Database باقی بماند.

به همین دلیل باید برای داده‌های موقت، سیاست مشخصی برای Cleanup، Reset یا Refresh وجود داشته باشد.

دشواری ایجاد داده‌های واقع‌گرایانه

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

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

Customer
   ↓
Insurance Policy
   ↓
Payment History
   ↓
Claim History
   ↓
Policy Status

هرچه روابط و تاریخچه سیستم پیچیده‌تر باشد، ایجاد Synthetic Test Data واقع‌گرایانه دشوارتر می‌شود.

در نتیجه، یکی از چالش‌های اصلی Test Data این است که داده‌ای ایجاد کنیم که نه‌تنها از نظر ساختار معتبر باشد، بلکه شرایط واقعی موردنیاز سناریوی تست را نیز بازسازی کند.

چرا Test Data Management اهمیت پیدا می‌کند؟

وقتی تعداد تست‌ها و پیچیدگی سیستم افزایش پیدا می‌کند، مدیریت Test Data نمی‌تواند صرفاً به چند فایل Excel یا چند رکورد که تسترها به‌صورت دستی ایجاد کرده‌اند وابسته باشد.

تیم تست باید بتواند مشخص کند:

چه داده‌ای موردنیاز است؟
این داده کجا قرار دارد؟
چه کسی می‌تواند به آن دسترسی داشته باشد؟
چگونه ایجاد یا Refresh می‌شود؟
چگونه بین تست‌ها به اشتراک گذاشته می‌شود؟
چگونه به وضعیت اولیه برمی‌گردد؟
چه زمانی باید حذف شود؟

پاسخ به این مسائل، ما را به مفهوم Test Data Management می‌رساند که در پروژه‌های بزرگ می‌تواند به یک فرایند و قابلیت مستقل تبدیل شود.

چالش‌های Test Data در پروژه‌های نرم‌افزاری ایران

بخش زیادی از چالش‌های Test Data در ایران با پروژه‌های نرم‌افزاری سایر کشورها مشترک است؛ برای مثال، حفاظت از اطلاعات حساس، دسترسی به داده مناسب، ایجاد داده‌های واقع‌گرایانه و مدیریت داده در محیط‌های تست.

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

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

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

برای مثال، Test Data می‌تواند شامل موارد زیر باشد:

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

در این شرایط، تستر نباید فقط بررسی کند که داده از نظر Format معتبر است. نحوه نمایش، جست‌وجو، مرتب‌سازی و ذخیره‌سازی داده‌های فارسی نیز ممکن است نیاز به تست داشته باشد.

برای مثال، وجود فاصله، نیم‌فاصله، تفاوت حروف «ی» و «ک» فارسی و عربی یا ترکیب اعداد فارسی و انگلیسی می‌تواند سناریوهای متفاوتی ایجاد کند.

تاریخ شمسی و تفاوت تقویم‌ها

تاریخ یکی دیگر از حوزه‌هایی است که در بسیاری از نرم‌افزارهای ایرانی اهمیت ویژه‌ای دارد.

اگر یک سیستم از تقویم شمسی در رابط کاربری استفاده کند ولی در Backend یا Database تاریخ را به شکل دیگری ذخیره کند، Test Data باید بتواند تبدیل و ارتباط بین این تاریخ‌ها را نیز پوشش دهد.

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

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

بنابراین در چنین سیستم‌هایی، Test Data مربوط به تاریخ فقط یک مقدار مثل 1405/01/01 نیست؛ بلکه باید شرایط مختلفی را که سیستم با تاریخ سروکار دارد پوشش دهد.

داده‌های بانکی و پرداخت

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

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

Payment Pending
Payment Successful
Payment Failed
Payment Cancelled
Refunded

در اینجا صرفاً داشتن یک شماره کارت یا یک مبلغ کافی نیست؛ تستر باید بتواند State و وضعیت تراکنش موردنیاز سناریو را نیز ایجاد کند.

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

داده‌های هویتی و اطلاعات حساس

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

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

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

داده‌های تاریخی و سیستم‌های Legacy

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

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

Customer
   ↓
Historical Records
   ↓
Previous Contracts
   ↓
Payments
   ↓
Current Status

در چنین شرایطی، ایجاد یک رکورد جدید در Database نمی‌تواند تمام شرایط موردنیاز تست را بازسازی کند.

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

تفاوت بین داده واقعی و داده‌ای که برای تست مناسب است

یکی از اشتباهات رایج این است که تصور کنیم هرچه Test Data به داده Production نزدیک‌تر باشد، حتماً بهتر است.

در عمل، داده مناسب باید شرایط موردنیاز Test Case را ایجاد کند.

برای مثال، اگر می‌خواهیم قابلیت بازگشت وجه را تست کنیم، یک تراکنش واقعی لزوماً بهترین داده برای تست نیست. ممکن است یک داده مصنوعی که دقیقاً وضعیت موردنیاز تراکنش را ایجاد می‌کند، برای Test Case مناسب‌تر باشد.

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

واقع‌گرایی + کنترل‌پذیری + امنیت + قابلیت تکرار

آیا چالش Test Data در ایران با سایر کشورها متفاوت است؟

پاسخ کوتاه این است: هم بله و هم خیر.

مسائل بنیادی مانند Data Masking، Synthetic Data، Test Data Refresh، Data Cleanup و وابستگی بین داده‌ها، چالش‌های عمومی Test Data هستند و به کشور خاصی محدود نمی‌شوند.

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

بنابراین رویکرد درست این نیست که برای Test Data در هر کشور یک روش کاملاً جدا تعریف کنیم؛ بلکه باید روش مدیریت Test Data را متناسب با نیاز پروژه طراحی کنیم و داده و Business Ruleهای بازار هدف را در آن لحاظ کنیم.

Test Data در تست اتوماتیک

در تست دستی، تستر می‌تواند قبل از اجرای تست، داده موردنیاز را به‌صورت دستی ایجاد یا از داده‌های موجود استفاده کند. اما در تست اتوماتیک (Automation Testing)، Test Data باید به شکلی آماده شود که تست بتواند بدون وابستگی غیرضروری به دخالت دستی اجرا شود.

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

اگر این داده‌ها از قبل به‌صورت دستی در سیستم ایجاد شده باشند، تست به وضعیت فعلی محیط وابسته می‌شود. ممکن است سفارش قبلاً لغو شده باشد، کاربر حذف شده باشد یا داده توسط تست دیگری تغییر کرده باشد. در نتیجه، تست به‌جای بررسی قابلیت لغو سفارش، به دلیل مشکل در Test Data شکست می‌خورد.

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

Test Data در UI Testing

در تست‌های UI، داده‌ها معمولاً از طریق رابط کاربری وارد می‌شوند؛ برای مثال تستر اتوماتیک یک فرم ثبت‌نام را با نام، ایمیل و شماره موبایل مشخص پر می‌کند.

اما همیشه لازم نیست تمام داده‌های موردنیاز از طریق UI ایجاد شوند.

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

این روش معمولاً باعث می‌شود تست‌ها سریع‌تر شوند و وابستگی آن‌ها به مراحل غیرضروری UI کاهش پیدا کند.

Test Data در API Testing

در API Testing، آماده‌سازی Test Data معمولاً ساده‌تر و سریع‌تر از UI است. برای مثال، تست می‌تواند ابتدا یک Customer و یک Order ایجاد کند و سپس API مربوط به لغو سفارش را آزمایش کند.

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

ایجاد کاربر از طریق API
ایجاد سفارش برای کاربر
ایجاد یا آماده‌سازی وضعیت موردنیاز سفارش
ارسال درخواست لغو سفارش
بررسی Response و وضعیت سفارش

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

Test Data در Database Testing

در برخی تست‌ها لازم است داده مستقیماً در Database ایجاد، بررسی یا پاک‌سازی شود. برای مثال، ممکن است تستر بخواهد بررسی کند که پس از اجرای یک API، رکورد مربوط به سفارش به شکل صحیح در Database ذخیره شده است.

با این حال، ایجاد داده با تغییر مستقیم Database همیشه بهترین روش نیست. اگر داده مستقیماً در Database ایجاد شود، ممکن است برخی Business Ruleهای سیستم اجرا نشوند.

برای مثال، ایجاد مستقیم یک Order در Database ممکن است بدون بررسی موجود بودن محصول، وضعیت Customer یا قوانین مربوط به Payment انجام شود.

بنابراین استفاده از Database برای Test Data باید با توجه به هدف تست انجام شود. در برخی تست‌ها استفاده از Database بسیار مفید است، اما در برخی دیگر بهتر است داده از طریق API یا خود سیستم ایجاد شود تا Business Logic مرتبط نیز درگیر شود.

Test Data در CI/CD

یکی از مهم‌ترین چالش‌های Test Data در CI/CD این است که تست‌ها باید بتوانند در هر اجرای Pipeline، در محیطی قابل پیش‌بینی اجرا شوند.

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

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

ایجاد Test Data در ابتدای اجرای تست
استفاده از Fixtures برای آماده‌سازی داده و وضعیت اولیه
استفاده از داده‌های منحصر‌به‌فرد برای هر Test Run
پاک‌سازی داده‌ها پس از اجرای تست در صورت نیاز
Reset کردن محیط یا داده‌ها در شرایط مناسب
جلوگیری از وابستگی تست‌ها به یکدیگر
استفاده از داده‌های قابل پیش‌بینی و Repeatable

هدف این نیست که در همه پروژه‌ها تمام داده‌ها قبل از هر تست از ابتدا ساخته شوند؛ بلکه باید مشخص باشد هر تست به چه داده‌ای وابسته است و چگونه می‌توان آن وضعیت را به‌صورت قابل اعتماد ایجاد کرد.

در تست اتوماتیک، مفاهیمی مانند Setup، Fixture، Data Provisioning و Teardown نیز به همین موضوع مربوط هستند. Setup یا Provisioning برای آماده‌سازی وضعیت و داده موردنیاز تست استفاده می‌شود و Teardown می‌تواند برای پاک‌سازی داده‌ها یا برگرداندن محیط به وضعیت مناسب پس از اجرای تست استفاده شود.

Test Data در Microservices

در معماری Microservices، هر سرویس معمولاً مسئول بخشی از قابلیت‌های سیستم است و ممکن است Database یا منبع داده مستقل خود را داشته باشد. به همین دلیل، آماده‌سازی Test Data در Microservices می‌تواند پیچیده‌تر از یک نرم‌افزار یکپارچه (Monolithic) باشد.

برای مثال، فرض کنید یک فروشگاه آنلاین از سرویس‌های جداگانه‌ای برای Customer، Product، Order و Payment استفاده می‌کند.

برای تست ایجاد یک سفارش ممکن است فقط به داده Order نیاز نداشته باشیم. این سفارش می‌تواند به یک Customer معتبر، یک Product موجود و در بعضی سناریوها یک Payment معتبر وابسته باشد.

در نتیجه، Test Data در یک سرویس ممکن است به وضعیت داده در سرویس‌های دیگر وابسته باشد.

وابستگی بین سرویس‌ها

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

Customer
   ↓
Order
   ↓
Payment
   ↓
Shipment

اگر Customer وجود نداشته باشد، ایجاد Order ممکن است امکان‌پذیر نباشد. اگر Order در وضعیت مناسب نباشد، Payment نمی‌تواند سناریوی موردنظر را ایجاد کند و در ادامه ممکن است Shipment نیز قابل ایجاد نباشد.

بنابراین تستر باید علاوه بر خود Test Data، Relationship و State داده‌ها را نیز در نظر بگیرد.

ایجاد Test Data در Microservices

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

داده را از طریق API هر سرویس ایجاد کرد.
از Test Fixture یا Data Factory استفاده کرد.
داده‌های اولیه را در محیط تست Seed کرد.
در تست‌های مشخص از Database استفاده کرد.
برای سرویس‌های وابسته از Mock یا Stub استفاده کرد.

انتخاب روش مناسب به نوع تست بستگی دارد. برای مثال، در یک Integration Test ممکن است بخواهیم ارتباط واقعی بین چند سرویس را بررسی کنیم؛ بنابراین حذف همه وابستگی‌ها با Mock کردن آن‌ها می‌تواند هدف تست را تغییر دهد.

State داده‌ها در Microservices

در Microservices فقط وجود یک رکورد اهمیت ندارد؛ وضعیت (State) آن نیز اهمیت دارد.

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

Created
Paid
Cancelled
Shipped
Refunded

تغییر وضعیت نیز ممکن است توسط سرویس دیگری انجام شود و حتی به‌صورت Asynchronous اتفاق بیفتد.

در چنین شرایطی، Test Data باید علاوه بر مقدار داده، وضعیت موردنیاز سیستم و نحوه رسیدن به آن وضعیت را نیز در نظر بگیرد.

Test Data و تست‌های Integration

در تست‌های Integration، داده‌ها معمولاً اهمیت بیشتری پیدا می‌کنند؛ زیرا هدف تست می‌تواند بررسی ارتباط واقعی بین چند سرویس باشد.

برای مثال:

Create Order
      ↓
Order Service
      ↓
Payment Service
      ↓
Payment Successful
      ↓
Order = Paid

در این سناریو، Test Data فقط اطلاعات Order نیست. داده‌ها و وضعیت موردنیاز Payment نیز بخشی از شرایط اجرای تست هستند.

به همین دلیل، در Microservices بهتر است هنگام طراحی Test Data مشخص شود:

کدام سرویس مالک داده است؟
داده موردنیاز در کدام سرویس قرار دارد؟
سرویس‌های دیگر به چه داده یا وضعیتی وابسته‌اند؟
داده چگونه ایجاد یا آماده می‌شود؟
وضعیت موردنیاز چگونه ایجاد می‌شود؟
آیا تست به داده واقعی سرویس‌های دیگر نیاز دارد یا می‌توان از Mock/Stub استفاده کرد؟

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

Test Data Management چیست؟

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

مجموعه فعالیت‌ها و روش‌هایی که برای مدیریت Test Data در طول فرایند تست انجام می‌شود، با عنوان Test Data Management (TDM) شناخته می‌شود.

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

Test Data Management چه فعالیت‌هایی را شامل می‌شود؟

TDM می‌تواند فعالیت‌های مختلفی را شامل شود، از جمله:

شناسایی داده موردنیاز برای Test Caseها
ایجاد Test Data
تهیه داده از منابع مختلف
استفاده از Production Data در صورت نیاز و با کنترل‌های مناسب
Mask کردن داده‌های حساس
تولید Synthetic Data
نگهداری و سازمان‌دهی داده‌ها
کنترل دسترسی به داده
ایجاد وضعیت‌های مختلف داده
پاک‌سازی یا Reset کردن داده
آماده‌سازی داده برای محیط‌های مختلف
ایجاد داده به‌صورت خودکار برای تست‌های Automation

بنابراین، Test Data Management فقط یک ابزار یا یک Database نیست؛ بلکه مجموعه‌ای از فرایندها، روش‌ها و گاهی ابزارهایی است که چرخه عمر Test Data را مدیریت می‌کنند.

چرا Test Data Management اهمیت دارد؟

فرض کنید یک تیم تست صدها Test Case دارد و بسیاری از آن‌ها به داده‌های مشترکی مانند Customer، Product، Order و Payment وابسته هستند.

اگر مدیریت مشخصی برای این داده‌ها وجود نداشته باشد، ممکن است:

یک تست داده موردنیاز تست دیگری را تغییر دهد.
تست‌ها به داده‌های قدیمی یا منقضی وابسته شوند.
ایجاد داده برای هر Test Case زمان زیادی ببرد.
تست‌ها در محیط‌های مختلف رفتار متفاوتی داشته باشند.
داده‌های حساس بدون کنترل مناسب در محیط تست قرار بگیرند.
اجرای تست‌ها قابل تکرار نباشد.

TDM تلاش می‌کند این مشکلات را کاهش دهد و دسترسی به Test Data را به بخشی قابل برنامه‌ریزی و قابل کنترل از فرایند تست تبدیل کند.

آیا Test Data Management فقط برای پروژه‌های بزرگ است؟

خیر. در پروژه‌های کوچک نیز ممکن است مدیریت Test Data اهمیت داشته باشد؛ اما با افزایش تعداد Test Caseها، محیط‌ها، تست‌های اتوماتیک و وابستگی بین سرویس‌ها، نیاز به TDM بیشتر می‌شود.

برای یک پروژه کوچک ممکن است یک مجموعه ساده از داده‌های تست و چند Script برای ایجاد و پاک‌سازی داده کافی باشد. در پروژه‌های بزرگ‌تر، ممکن است تیم به فرایندها و ابزارهای تخصصی برای تهیه، Mask، Provision و مدیریت Test Data نیاز داشته باشد.

در واقع، سطح پیچیدگی Test Data Management باید متناسب با پیچیدگی پروژه و نیازهای تست باشد.

بهترین روش‌های مدیریت Test Data

مدیریت Test Data زمانی مؤثر است که داده‌ها فقط برای یک اجرای خاص آماده نشوند، بلکه بتوان آن‌ها را به‌صورت قابل کنترل، قابل تکرار و متناسب با هدف تست استفاده کرد.

برای این کار، چند روش مهم وجود دارد.

Test Data را از Test Case جدا نگه دارید

Test Case مشخص می‌کند چه چیزی باید تست شود و Test Data داده و شرایطی است که برای اجرای آن تست موردنیاز است.

بهتر است داده‌ها به شکلی مدیریت شوند که در صورت تغییر Test Data، مجبور نباشیم ساختار تمام Test Caseها را تغییر دهیم.

برای مثال، به‌جای اینکه اطلاعات یک Customer در بخش‌های مختلف Automation Test تکرار شود، می‌توان آن را در یک Fixture یا Data Factory متمرکز کرد.

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

Test Data را تا حد امکان قابل تکرار کنید

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

بنابراین بهتر است Test Data موردنیاز تست بتواند در صورت نیاز دوباره ایجاد شود.

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

از داده مشترک با احتیاط استفاده کنید

استفاده چند Test Case از یک رکورد مشترک می‌تواند باعث ایجاد وابستگی بین تست‌ها شود.

برای مثال، اگر چند تست از یک Order با شناسه 10025 استفاده کنند و یکی از تست‌ها آن را Cancel کند، تست دیگری ممکن است به دلیل تغییر وضعیت Order شکست بخورد.

در صورت امکان، بهتر است تست‌ها داده مستقل داشته باشند یا داده مشترک به شکلی مدیریت شود که تغییر یک تست روی تست‌های دیگر اثر نگذارد.

داده را متناسب با هدف تست انتخاب کنید

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

تست Validation به Invalid و Boundary Data نیاز دارد.
تست Login به Credentialهای مناسب نیاز دارد.
تست Performance ممکن است به حجم بسیار زیادی از داده نیاز داشته باشد.
تست Security ممکن است به داده‌های خاص و ورودی‌های غیرمعمول نیاز داشته باشد.
تست گزارش‌گیری ممکن است به داده‌های تاریخی و روابط پیچیده بین رکوردها نیاز داشته باشد.

بنابراین نباید صرفاً یک مجموعه ثابت از Test Data را برای تمام Test Caseها استفاده کرد.

داده‌های حساس را کنترل کنید

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

در چنین شرایطی می‌توان از روش‌هایی مانند Data Masking، Synthetic Data یا ایجاد داده‌های مصنوعی استفاده کرد.

همچنین دسترسی به Test Data باید متناسب با نیاز افراد و محیط تست کنترل شود.

ایجاد Test Data را تا حد امکان خودکار کنید

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

می‌توان ایجاد داده را از طریق مواردی مانند موارد زیر خودکار کرد:

API
Database Scripts
Test Fixtures
Data Factories
Test Data Generators

برای مثال، یک تست می‌تواند قبل از اجرا یک Customer جدید ایجاد کند و پس از پایان تست، داده ایجادشده را پاک‌سازی کند یا آن را برای اجرای بعدی در وضعیت مناسب قرار دهد.

برای داده‌ها Cleanup و Reset در نظر بگیرید

بعضی Test Caseها داده را تغییر می‌دهند. بنابراین باید مشخص باشد پس از اجرای تست چه اتفاقی برای داده رخ می‌دهد.

ممکن است لازم باشد داده:

حذف شود.
به وضعیت اولیه برگردد.
با داده جدید جایگزین شود.
یا برای تست بعدی دوباره ایجاد شود.

روش مناسب به نوع تست و معماری سیستم بستگی دارد.

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

در سیستم‌های پیچیده، یک Test Data ممکن است به داده‌های دیگری وابسته باشد.

Customer
   ↓
Order
   ↓
Payment
   ↓
Shipment

اگر Test Case به یک Order خاص نیاز داشته باشد، ممکن است وجود Customer، Payment یا Shipment با وضعیت مشخص نیز ضروری باشد.

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

Test Data را برای محیط‌های مختلف بررسی کنید

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

برای مثال، داده‌ای که در Development وجود دارد ممکن است در Test یا Staging وجود نداشته باشد. همچنین ممکن است ساختار، حجم یا Configuration محیط‌ها متفاوت باشد.

به همین دلیل، بهتر است مشخص باشد هر محیط چه داده‌هایی دارد و Test Data چگونه در آن محیط Provision یا Reset می‌شود.

یک اصل مهم: Test Data نباید خودش به عامل غیرقابل اعتماد تست تبدیل شود

هدف Test Data این است که شرایط لازم برای اجرای تست را فراهم کند، نه اینکه خودش منبع اصلی شکست‌های تصادفی باشد.

اگر تست به داده‌ای وابسته باشد که ممکن است بدون اطلاع تستر تغییر کند، داده منقضی شود یا توسط Test Case دیگری تغییر داده شود، نتیجه تست دیگر قابل اعتماد نخواهد بود.

به همین دلیل، در مدیریت Test Data باید بین واقع‌گرایی، کنترل‌پذیری، امنیت و قابلیت تکرار تعادل ایجاد کرد.

نمونه Test Data برای یک Test Case

برای درک بهتر Test Data، یک سناریوی ساده را در نظر بگیریم. فرض کنید در یک فروشگاه اینترنتی، کاربر می‌تواند سفارش پرداخت‌شده خود را لغو کند.

Test Scenario

لغو سفارش پرداخت‌شده توسط کاربر

در این سناریو، Test Case باید بررسی کند که کاربر می‌تواند سفارشی را که شرایط لازم برای لغو دارد، با موفقیت Cancel کند.

Test Case

مورد	مقدار
Test Case ID	TC-ORD-015
Test Case	لغو سفارش پرداخت‌شده
Precondition	کاربر وارد سیستم شده و سفارش در وضعیت قابل لغو است
Steps	ورود به سفارش → انتخاب لغو سفارش → تأیید لغو
Expected Result	سفارش با موفقیت لغو شده و وضعیت آن به `Cancelled` تغییر می‌کند

اما برای اجرای این Test Case، فقط Stepهای بالا کافی نیستند و به Test Data نیز نیاز داریم.

Test Data موردنیاز

داده	مقدار نمونه
Customer ID	CUST-1025
Customer Status	Active
Order ID	ORD-45821
Order Status	Paid
Order Amount	2,500,000 تومان
Payment Status	Successful
Cancellation Allowed	Yes
Product Stock	Available

در این مثال، Order ID، Customer ID و اطلاعات مربوط به وضعیت سفارش و پرداخت بخشی از شرایط و داده موردنیاز برای اجرای تست هستند.

اگر Order موردنظر قبلاً Cancel شده باشد، Test Case دیگر نمی‌تواند همان سناریوی موردنظر را بررسی کند. بنابراین فقط مقدار داده اهمیت ندارد؛ State داده نیز بخشی از Test Data موردنیاز تست است.

Test Data برای سناریوهای مختلف

حالا فرض کنیم بخواهیم چند حالت مختلف را برای قابلیت لغو سفارش تست کنیم.

سناریو	Order Status	Payment Status	Cancellation Allowed	نتیجه مورد انتظار
سفارش قابل لغو	Paid	Successful	Yes	لغو موفق
سفارش قبلاً لغو شده	Cancelled	Successful	No	لغو مجدد انجام نشود
سفارش ارسال شده	Shipped	Successful	No	لغو انجام نشود
پرداخت ناموفق	Created	Failed	No	لغو طبق Business Rule سیستم
سفارش Refund شده	Refunded	Refunded	No	لغو مجدد انجام نشود

این مثال نشان می‌دهد که Test Data فقط شامل مقادیر ورودی یک فرم نیست. گاهی ترکیب چند داده و وضعیت مرتبط با یکدیگر است که شرایط اجرای یک Test Case را ایجاد می‌کند.

یک نکته مهم درباره Test Data

ممکن است یک داده در یک Test Case مناسب باشد و در Test Case دیگری مناسب نباشد.

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

بنابراین مناسب بودن Test Data همیشه به هدف و شرایط Test Case بستگی دارد.

به همین دلیل، هنگام طراحی Test Case بهتر است علاوه بر مشخص کردن Steps و Expected Result، داده و وضعیت موردنیاز برای اجرای تست نیز به‌طور واضح مشخص شود.

رابطه Test Data با Test Environment

Test Data و Test Environment دو مفهوم جدا از یکدیگر هستند، اما در بسیاری از تست‌ها ارتباط مستقیمی با هم دارند.

Test Data مشخص می‌کند با چه داده‌ای تست را اجرا می‌کنیم، در حالی که Test Environment مشخص می‌کند تست در چه محیط و شرایط فنی اجرا می‌شود.

برای مثال، ممکن است یک Test Case به یک Customer، یک Order و یک Payment مشخص نیاز داشته باشد. این داده‌ها باید در محیطی قرار داشته باشند که نسخه مناسب نرم‌افزار، Database، سرویس‌های وابسته و Configuration موردنیاز تست را در اختیار داشته باشد.

چرا محیط تست روی Test Data تأثیر می‌گذارد؟

یک Test Data مشخص ممکن است در یک محیط قابل استفاده باشد، اما در محیط دیگر وجود نداشته باشد یا رفتار متفاوتی ایجاد کند.

یک Customer در محیط Test وجود دارد اما در Staging وجود ندارد.
داده‌های Payment در محیط Test به یک سرویس Mock متصل هستند.
Database محیط جدید با داده‌های قبلی Reset شده است.
یک سرویس خارجی در محیط تست فعال نیست.
Configuration محیط باعث می‌شود یک Order در وضعیت متفاوتی قرار بگیرد.

بنابراین وقتی یک Test Case شکست می‌خورد، نباید همیشه فرض کرد مشکل از خود نرم‌افزار است. Test Data و Test Environment نیز باید به‌عنوان بخشی از شرایط اجرای تست بررسی شوند.

Test Data باید با Environment سازگار باشد

فرض کنید یک تست به یک Payment موفق نیاز دارد. اگر در محیط Test، Payment Gateway واقعی استفاده نمی‌شود و به‌جای آن یک Mock یا Sandbox وجود دارد، Test Data و روش ایجاد Payment باید متناسب با همان محیط باشد.

Test Case
    ↓
Test Data
    ↓
Test Environment
    ↓
Application + Database + Services

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

تفاوت Test Data و Test Environment

مورد	Test Data	Test Environment
مفهوم	داده و وضعیت موردنیاز برای تست	محیط و زیرساخت اجرای تست
مثال	Customer، Order، Payment	Application، Database، Server
هدف	ایجاد شرایط لازم برای اجرای Test Case	فراهم کردن شرایط فنی اجرای نرم‌افزار
تغییرپذیری	ممکن است در طول تست تغییر کند	معمولاً نسبت به داده پایدارتر است
ارتباط	باید متناسب با محیط باشد	باید بتواند Test Data موردنیاز را پشتیبانی کند

یک مثال ساده

فرض کنید Test Case این است:

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

برای اجرای آن به Test Data زیر نیاز داریم:

Customer = Active
Order = Paid
Payment = Successful
Cancellation = Allowed

اما این داده‌ها باید در یک Test Environment مناسب قرار داشته باشند:

Application
Database
Order Service
Payment Service
Test Configuration

اگر Order در Database وجود داشته باشد اما Payment Service در محیط تست در دسترس نباشد، Test Data به‌تنهایی برای اجرای موفق تست کافی نیست.

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

چه داده‌ای برای اجرای تست لازم است؟

چه محیطی برای اجرای صحیح تست لازم است؟

این تفکیک کمک می‌کند مشکلات مربوط به Test Data با مشکلات مربوط به Test Environment اشتباه گرفته نشوند.

Test Data و Test Case چه ارتباطی دارند؟

Test Case مشخص می‌کند چه چیزی و چگونه باید تست شود، در حالی که Test Data داده و شرایطی را فراهم می‌کند که اجرای Test Case بر اساس آن انجام می‌شود.

به بیان ساده، بسیاری از Test Caseها برای اجرا به Test Data نیاز دارند، اما میزان و نوع این وابستگی به نوع تست و سناریوی موردنظر بستگی دارد.

Test Data بخشی از شرایط اجرای Test Case است

فرض کنید Test Case مربوط به ورود کاربر به سیستم است:

Test Case:
بررسی ورود موفق کاربر

Test Data:
Username = ali.test
Password = Test@123

در اینجا Test Case مشخص می‌کند که قرار است Login بررسی شود و Test Data اطلاعاتی را فراهم می‌کند که برای اجرای این سناریو لازم است.

اما برای بررسی حالت‌های مختلف، داده نیز تغییر می‌کند:

سناریو	Username	Password	نتیجه مورد انتظار
ورود موفق	معتبر	معتبر	Login موفق
رمز عبور اشتباه	معتبر	نامعتبر	نمایش خطا
کاربر ناموجود	ناموجود	هر مقدار	نمایش خطا
Username خالی	خالی	معتبر	Validation Error
Password خالی	معتبر	خالی	Validation Error

در این مثال، تغییر Test Data باعث می‌شود شرایط متفاوتی از قابلیت Login بررسی شود.

یک Test Case می‌تواند چند Test Data داشته باشد

گاهی یک Test Case با چند مجموعه داده اجرا می‌شود.

برای مثال، اگر محدودیت یک فیلد این باشد که مقدار آن باید بین 1 تا 100 باشد، می‌توان Test Dataهای مختلفی برای بررسی Boundaryها تعریف کرد:

در این حالت، هدف Test Case یکسان است، اما Test Data تغییر می‌کند تا رفتار سیستم در نقاط مختلف بررسی شود.

این روش به‌خصوص در Data-Driven Testing اهمیت دارد؛ جایی که یک Test Case با مجموعه‌ای از داده‌های مختلف اجرا می‌شود.

تغییر Test Data همیشه به معنی تغییر Test Case نیست

فرض کنید یک Test Case می‌گوید:

بررسی ورود موفق کاربر با اطلاعات معتبر.

اگر Username و Password را از یک کاربر معتبر به کاربر معتبر دیگری تغییر دهیم، ممکن است Test Case همان Test Case باقی بماند و فقط Test Data تغییر کرده باشد.

اما اگر هدف تست تغییر کند، مثلاً بخواهیم ورود کاربر مسدودشده را بررسی کنیم، دیگر فقط تغییر یک مقدار داده مطرح نیست؛ بلکه شرایط و هدف تست نیز تغییر کرده است.

بنابراین باید بین تغییر داده و تغییر هدف تست تفاوت قائل شد.

Test Data و پوشش تست

یکی از دلایلی که Test Data اهمیت زیادی دارد، تأثیر آن بر Test Coverage است.

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

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

نام معتبر
ایمیل معتبر
شماره موبایل معتبر

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

مقدار خالی
مقدار Null
حداقل طول مجاز
حداکثر طول مجاز
بیشتر از طول مجاز
فرمت نامعتبر
داده تکراری
کاراکترهای خاص

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

در نتیجه، هنگام طراحی Test Case بهتر است فقط به Steps و Expected Result توجه نشود؛ بلکه مشخص شود برای اجرای این تست چه داده و چه وضعیت‌هایی لازم است و آیا داده انتخاب‌شده واقعاً سناریوی موردنظر را پوشش می‌دهد یا خیر.

جمع‌بندی

Test Data یکی از اجزای مهم فرایند تست نرم‌افزار است که شرایط لازم برای اجرای Test Caseها و بررسی رفتار سیستم را فراهم می‌کند. Test Data فقط به مقادیر واردشده در فرم‌ها محدود نمی‌شود و می‌تواند شامل داده‌ها، روابط بین داده‌ها و وضعیت‌های موردنیاز سیستم نیز باشد.

در طول مقاله دیدیم که Test Data می‌تواند انواع مختلفی داشته باشد؛ از Valid و Invalid Data گرفته تا Boundary، Empty/Null، Duplicate و Large Volume Data. همچنین روش‌های مختلفی برای تهیه آن وجود دارد، مانند ایجاد دستی، استفاده از Production Data، Masked Data، Synthetic Data و تولید خودکار داده.

در پروژه‌های واقعی، مسئله فقط ایجاد داده نیست. داده باید مناسب، قابل کنترل، قابل تکرار، امن و متناسب با هدف تست باشد. به همین دلیل، با افزایش پیچیدگی پروژه، موضوع Test Data Management (TDM) اهمیت بیشتری پیدا می‌کند.

در تست اتوماتیک نیز Test Data باید تا حد امکان به‌صورت قابل تکرار و مستقل آماده شود. استفاده از Fixture، API، Data Factory و روش‌های مناسب برای Setup و Cleanup می‌تواند وابستگی تست‌ها به داده‌های دستی و تغییرپذیر را کاهش دهد.

در معماری‌هایی مانند Microservices، وابستگی بین سرویس‌ها و وضعیت داده‌ها، مدیریت Test Data را پیچیده‌تر می‌کند. همچنین Test Data باید با Test Environment سازگار باشد؛ زیرا داده مناسب بدون محیط مناسب لزوماً نمی‌تواند شرایط صحیح اجرای تست را فراهم کند.

در نهایت، Test Data را نباید یک موضوع فرعی در کنار Test Case در نظر گرفت. انتخاب و مدیریت صحیح داده می‌تواند روی قابلیت اطمینان نتایج تست، پوشش سناریوها، پایداری تست‌های اتوماتیک و سرعت اجرای فرایند تست تأثیر مستقیم داشته باشد.

به همین دلیل، هنگام طراحی و اجرای تست بهتر است همیشه این سؤال را در نظر داشته باشیم:

آیا Test Data انتخاب‌شده واقعاً شرایطی را ایجاد می‌کند که Test Case قرار است آن را بررسی کند؟

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

منابع

سؤالات متداول درباره Test Data

Test Data چیست؟

Test Data به داده‌هایی گفته می‌شود که برای طراحی، اجرا و ارزیابی تست‌های نرم‌افزار استفاده می‌شوند. این داده‌ها می‌توانند ورودی مستقیم سیستم یا داده و وضعیت موردنیاز برای ایجاد شرایط اجرای یک Test Case باشند.

تفاوت Test Data و Test Case چیست؟

Test Case مشخص می‌کند چه چیزی و چگونه باید تست شود، در حالی که Test Data داده و شرایط لازم برای اجرای آن Test Case را فراهم می‌کند. یک Test Case می‌تواند با چند مجموعه Test Data اجرا شود.

انواع Test Data چیست؟

از انواع رایج Test Data می‌توان به Valid، Invalid، Boundary، Positive، Negative، Empty/Null، Duplicate، Large Volume و Production-like Data اشاره کرد. این دسته‌ها الزاماً از یکدیگر مستقل نیستند و یک داده می‌تواند هم‌زمان در چند دسته قرار بگیرد.

Test Data چگونه تهیه می‌شود؟

Test Data می‌تواند به‌صورت دستی ایجاد شود یا از Production Data، Masked Data، Synthetic Data، Test Data Generator، API و Database تهیه شود. روش مناسب به هدف تست، امنیت داده و شرایط پروژه بستگی دارد.

آیا استفاده از Production Data برای تست مناسب است؟

Production Data معمولاً واقع‌گرایی بالایی دارد، اما ممکن است شامل اطلاعات حساس باشد و کنترل و مدیریت آن دشوارتر باشد. در صورت نیاز می‌توان از داده‌های Masked یا Synthetic استفاده کرد تا بین واقع‌گرایی، کنترل‌پذیری و امنیت تعادل ایجاد شود.

Test Data در تست اتوماتیک چه اهمیتی دارد؟

در تست اتوماتیک، Test Data باید تا حد امکان قابل تکرار و قابل کنترل باشد. استفاده از Fixture، API، Data Factory و روش‌های مناسب برای Setup و Cleanup می‌تواند وابستگی تست‌ها به داده‌های دستی و تغییرپذیر را کاهش دهد.

Test Data Management یا TDM چیست؟

Test Data Management (TDM) مجموعه فعالیت‌ها و روش‌هایی برای ایجاد، تهیه، نگهداری، کنترل، ایمن‌سازی، Provision و پاک‌سازی Test Data است تا تیم تست بتواند به داده مناسب و قابل تکرار دسترسی داشته باشد.

تفاوت Test Data و Test Environment چیست؟

Test Data به داده و وضعیت موردنیاز برای اجرای تست اشاره دارد، در حالی که Test Environment محیط فنی اجرای نرم‌افزار مانند Application، Database، Server و سرویس‌های وابسته را شامل می‌شود. این دو مفهوم جدا هستند، اما برای اجرای صحیح تست باید با یکدیگر سازگار باشند.

آیا Test Data در Microservices متفاوت است؟

مفهوم Test Data تغییر نمی‌کند، اما مدیریت آن در Microservices می‌تواند پیچیده‌تر باشد؛ زیرا داده‌ها ممکن است بین چند سرویس و Database وابستگی داشته باشند و وضعیت یک سرویس بر سرویس‌های دیگر تأثیر بگذارد.

طبقه بندی شده در:

دسته‌بندی نشده,

اخرین بروزرسانی: مهر 1, 1405

ESC را فشار دهید تا بسته شود

Test Data چیست؟

یک مثال ساده از Test Data

تفاوت Test Data با Test Case و Test Scenario

چرا Test Data در تست نرم‌افزار اهمیت دارد؟

پوشش سناریوهای مختلف

شناسایی خطاهایی که با داده‌های عادی دیده نمی‌شوند

افزایش قابلیت اعتماد به نتایج تست

اهمیت Test Data در تست اتوماتیک

انواع Test Data چیست؟

Valid Test Data

Invalid Test Data

Boundary Test Data

Positive Test Data

Negative Test Data

Empty و Null Test Data

Duplicate Test Data

Large Volume Test Data

Production-like Test Data

Test Data را چگونه تهیه کنیم؟

ایجاد دستی Test Data

استفاده از Production Data

استفاده از Masked Data

تولید Synthetic Test Data

استفاده از Test Data Generator

ایجاد Test Data از طریق API یا Database

انتخاب روش مناسب برای تهیه Test Data

Test Data واقعی یا Synthetic Data؛ کدام بهتر است؟

Production Data چه زمانی می‌تواند مفید باشد؟

Synthetic Data چه زمانی مناسب‌تر است؟

مقایسه Production Data و Synthetic Data

آیا Synthetic Data همیشه جایگزین Production Data است؟

انتخاب Test Data باید بر اساس هدف تست باشد

Test Data خوب چه ویژگی‌هایی دارد؟

مرتبط با سناریوی تست باشد

معتبر و مطابق قوانین سیستم باشد

واقع‌گرایانه باشد

قابل تکرار باشد

قابل کنترل باشد

روابط بین داده‌ها حفظ شده باشد

امن باشد

قابل پاک‌سازی باشد

متناسب با نوع تست باشد

جمع‌بندی ویژگی‌های Test Data مناسب

چالش‌های مدیریت Test Data چیست؟

دسترسی به داده مناسب

وابستگی بین داده‌ها

تغییر داده‌ها در طول اجرای تست

هم‌زمانی تست‌ها

حجم زیاد Test Data

داده‌های حساس و محرمانه

تفاوت داده بین محیط‌های مختلف

پاک‌سازی و Reset کردن داده‌ها

دشواری ایجاد داده‌های واقع‌گرایانه

چرا Test Data Management اهمیت پیدا می‌کند؟

چالش‌های Test Data در پروژه‌های نرم‌افزاری ایران

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

تاریخ شمسی و تفاوت تقویم‌ها

داده‌های بانکی و پرداخت

داده‌های هویتی و اطلاعات حساس

داده‌های تاریخی و سیستم‌های Legacy

تفاوت بین داده واقعی و داده‌ای که برای تست مناسب است

آیا چالش Test Data در ایران با سایر کشورها متفاوت است؟

Test Data در تست اتوماتیک

Test Data در UI Testing

Test Data در API Testing

Test Data در Database Testing

Test Data در CI/CD

Test Data در Microservices

وابستگی بین سرویس‌ها

ایجاد Test Data در Microservices

State داده‌ها در Microservices

Test Data و تست‌های Integration

Test Data Management چیست؟

Test Data Management چه فعالیت‌هایی را شامل می‌شود؟

چرا Test Data Management اهمیت دارد؟

آیا Test Data Management فقط برای پروژه‌های بزرگ است؟

بهترین روش‌های مدیریت Test Data

Test Data را از Test Case جدا نگه دارید

Test Data را تا حد امکان قابل تکرار کنید