دادهٔ تست: مسئلهای که همه دستکم میگیرند
تیمها استراتژی تست مینویسند، هرم تست را بحث میکنند، ابزار انتخاب میکنند — و بعد سؤال «این تستها با چه دادهای اجرا میشوند؟» بیجواب میماند.
جواب پیشفرض معمولاً یکی از این دوتاست: یک کپی از پایگاه دادهٔ تولید، یا چند رکورد دستی که یکی از توسعهدهندهها سه سال پیش ساخته.
هر دو مسئله دارند، و هر دو در جای متفاوتی هزینه میسازند.
چرا کپی از تولید بدترین گزینهای است که راحتترین به نظر میرسد
اول، حریم خصوصی. یک کپی کامل یعنی نام و شماره تلفن و کد ملی و آدرس مشتریان واقعی روی محیط آزمون، که تقریباً همیشه سطح دسترسی بازتری دارد، پشتیبانگیری کمتری دارد، و گاهی روی لپتاپ یک نفر است. این نشتی است که هنوز اتفاق نیفتاده.
دوم، تکرارپذیری. تستی که به دادهٔ تولید وابسته است، هفتهٔ بعد نتیجهٔ دیگری میدهد چون داده عوض شده. این منبع اصلی تستهای ناپایدار است — همان تستهایی که گاهی سبز و گاهی قرمزند و در نهایت تیم یاد میگیرد نادیدهشان بگیرد.
سوم، حجم. کپی کامل معمولاً بزرگ است، بازگردانیاش طول میکشد، و اجرای تست را کند میکند. مجموعهٔ تستی که چهل دقیقه طول بکشد، مجموعهای است که در هر تغییر اجرا نمیشود — و خط لولهٔ کند یعنی بازخورد دیر.
چهارم، و کمتر گفتهشده: دادهٔ تولید حالتهای مرزی را ندارد. مشتری با اعتبار منفی، سفارشی که در وضعیت نیمهکاره گیر کرده، نامی با نویسهٔ خاص، سبدی با دویست قلم — اینها دقیقاً چیزهایی هستند که باگ میسازند و در نمونهٔ تصادفی از تولید نیستند.
سه روش، برای سه لایهٔ تست
هیچ روشی برای همهجا درست نیست. تفکیک بر اساس لایه:
تست واحد: داده در خود تست
کوچک، صریح، و در همان فایل تست ساخته میشود. نه از پایگاه داده، نه از فایل بیرونی.
معیارش این است: کسی که تست را میخواند باید بدون رفتن به جای دیگری بفهمد ورودی چه بوده. تستی که به رکورد شمارهٔ ۴۲ در یک فایل مشترک ارجاع میدهد، تستی است که شش ماه بعد قابل فهم نیست — و وقتی شکست، کسی نمیداند چرا.
اینجا از سازنده با پیشفرض استفاده کنید: تابعی که یک مشتری معتبر میسازد و شما فقط همان یک فیلدی را که برای این تست مهم است تغییر میدهید. تستی که بیست فیلد را پر میکند تا یکیشان را بسنجد، تستی است که با هر تغییر مدل میشکند.
تست یکپارچگی: پایگاه دادهٔ کوچک و ساختهشده
مجموعهٔ کوچکی از داده که با اسکریپت ساخته میشود و در مخزن کد است، نه در جایی که کسی دستی نگهش میدارد.
سه ویژگی:
پیش از هر اجرا از نو ساخته میشود. تستی که به دادهای که تست قبلی ساخته وابسته باشد، به ترتیب اجرا وابسته است — و آن هم منبع دیگری از ناپایداری است.
کوچک است. پنجاه رکورد، نه پنجاه هزار. هدف درستی است، نه کارایی.
حالتهای مرزی را عمداً دارد. مقدار خالی، صفر، منفی، تاریخ در آینده، متن فارسی با اعداد فارسی، رشتهٔ خیلی بلند.
تست کارایی: داده به اندازهٔ واقعی
اینجا برعکس است: حجم مهمترین چیز است. پرسوجویی که بدون ایندکس روی پنج هزار رکورد سریع است، روی دو میلیون رکورد سامانه را میخواباند — دلیلش را در کارایی پایگاه داده نوشتهایم.
داده را با ابزار تولید کنید، نه با کپی، و توزیعش را واقعی نگه دارید: اگر در تولید نود درصد سفارشها زیر پنج قلم دارند و یک درصد بالای صد قلم، دادهٔ مصنوعی هم باید همین شکل باشد. دادهٔ یکنواخت، بدترین حالتها را پنهان میکند. اهمیتش در تست بار توضیح داده شده.
اگر واقعاً باید از تولید کپی بگیرید
گاهی لازم است — معمولاً برای بازتولید یک باگ که فقط با ترکیب واقعی داده رخ میدهد، یا برای تمرین مهاجرت داده.
در آن صورت، پوشاندن داده پیش از خروج از محیط تولید انجام میشود، نه بعد از آن. چند نکته که در عمل اهمیت دارند:
پوشاندن باید سازگار باشد. اگر شمارهٔ ملی یک مشتری در سه جدول هست، هر سه باید به یک مقدار جعلی تبدیل شوند، وگرنه اتصالها میشکنند و داده بیفایده میشود.
داده باید معتبر بماند. کد ملی جعلی باید ساختار درستی داشته باشد، وگرنه اعتبارسنجی سامانه ردش میکند و شما در حال تست چیز دیگری هستید.
پوشاندن با حذف یکی نیست. جای خالی، رفتار متفاوتی از مقدار جعلی تولید میکند.
فرایند خودکار باشد. پوشاندن دستی، همان کاری است که یک بار درست انجام میشود و بار سوم فراموش. چارچوبش در حاکمیت داده و سیاست دسترسی سازمان است.
چیزی که مکرراً از قلم میافتد: پاکسازی
محیط آزمونی که شش ماه پاک نشده، محیطی است که هزاران رکورد بیمعنا دارد، گزارشهایش دروغ میگویند، و کسی به دادهاش اعتماد ندارد.
یک زمانبندی برای بازنشانی بگذارید — هفتگی برای محیط تست خودکار، ماهانه برای محیطی که مشتری در آن تست پذیرش انجام میدهد. و مثل هر کار دورهای دیگری، مراحلش باید در دفترچهٔ اجرا نوشته شده باشد تا وابسته به حافظهٔ یک نفر نباشد.
علامتی که میگوید مسئله دارید
اگر این جمله را در تیم شنیدهاید، دادهٔ تست مسئلهٔ شماست:
«این تست گاهی قرمز میشود، دوباره اجرا کن.»
تستی که با اجرای دوباره سبز میشود، تستی است که چیزی را که ادعا میکند نمیسنجد. علتش تقریباً همیشه یکی از این سه است: دادهای که از اجرای قبلی مانده، وابستگی به ترتیب اجرا، یا وابستگی به زمان (تستی که فقط قبل از نیمهشب سبز است).
هر سه با دادهٔ تست ساختهشده و از نو ساختهشده حل میشوند — و هر سه، اگر حل نشوند، در نهایت به تستهایی که کسی جدیشان نمیگیرد ختم میشوند.