پس از تعریف سطوح تست، و به ویژه تست های سیستم، ذکر برخی از دام های بسیار رایج که تسترهای مبتدی به راحتی می توانند در آنها بیفتند، مهم به نظر می رسد. این مشکلات می توانند اثرات مختلفی داشته باشند، از کاهش کیفیت محصول تا بازگشت سرمایه کمتر در آزمایش. در هر صورت، این اقدامات می تواند به سرعت برای شرکت ها نتیجه معکوس داشته باشد.
1. وارد شدن به “جعبه سیاه”
گاهی اوقات ممکن است وسوسه انگیز باشد که بخواهید سیستم را بررسی کنید تا ببینید مثلاً یک آیتم درج شده است یا خیر، اما مراقب باشید! این “تداخل” در جعبه سیاه وابستگی به پیاده سازی سیستم ایجاد می کند و آن را در معرض افزایش پشتیبانی آزمایشی با تکامل سیستم قرار می دهد. فقط در مواقع ضروری و با وزن دادن به مزایا و معایب استفاده شود!
2. برای انجام آزمایشات به عملکرد مناسب خود سیستم تکیه کنید
این موردی است که می‌خواهیم از پیچیدگی گاه قابل توجه تنظیم زمینه آزمون (پیش‌شرط‌های اجرا، داده‌های آزمایش و غیره) اجتناب کنیم. سپس می‌توانیم انتخاب کنیم که از خود سیستم استفاده کنیم تا قبل از شروع آزمایش به شکلی درآییم. ما در خطر نادیده گرفتن یکی از اهداف آزمایش، یعنی ارائه اطلاعات در مورد عملکرد صحیح کل سیستم هستیم.
بیایید مثالی بزنیم:
ما می خواهیم یک ویژگی را برای حذف یک مورد در یک سیستم تأیید کنیم. برای اطمینان از تکرارپذیری تست، باید داده هایی برای حذف در هر اجرا داشته باشیم. سپس چندین گزینه در دسترس ما است، از جمله:
- قبل از اجرای تست درج داده، یک اسکریپت را پخش کنید (در بسیاری از موارد بهترین گزینه)
- نصب مجدد تمام داده های آزمایشی در هر استقرار سیستم و بنابراین استقرار مجدد سیستم قبل از هر اجرای آزمایشی
- داشتن داده های “کافی” برای اجرای چندین بار تست (این گزینه بدیهی است که بهترین نیست زیرا فقط مشکل را به تاخیر می اندازد!)
- داده ها را با استفاده از قابلیت افزودن داده های سیستم وارد کنید: این گزینه ای است که یک تله بزرگ را پنهان می کند!
خطر این است که اگر درج داده کار نکند، وضعیت همه عملکردهای سیستم را از دست بدهید.
اگر همه موارد آزمایشی با استفاده از سیستم درج داده آزمایشی شروع به کار کنند و این امکان پذیر نباشد، استخراج، اصلاحات و حذف داده ها دیگر قابل آزمایش نیستند.
اگر به منظور «صرفه‌جویی در زمان» برای اجرای زمینه‌های آزمایش، یک سناریوی «فوق‌العاده» بسازیم که در آن همه عملکردهایی که باید آزمایش شوند را به دقت به هم متصل کنیم تا کل آن را پوشش دهیم، همین پدیده را پیدا می‌کنیم: ما فقط می‌توانیم اولین مشکلی که رخ می دهد و ما نسبت به سایر مشکلات احتمالی که ممکن است بعداً در سناریوی آزمایشی کشف شوند کور خواهیم بود. سپس ما خود را در معرض آنچه من «اشکال‌های اثر زنجیره‌ای» می‌نامم قرار می‌دهیم: یک اشکال را برطرف می‌کنیم، اشکال بعدی را پیدا می‌کنیم، آن را برطرف می‌کنیم، دیگری را پیدا می‌کنیم و غیره. و ما مطلقاً نمی دانیم که چند ویژگی سیستم در یک زمان T تغییر می کند.
این امر تصمیم گیری و برنامه ریزی را بسیار دشوار می کند زیرا تلاش اصلاحی قابل تخمین نیست. این وابستگی به عملکرد صحیح برخی از عملکردهای سیستم برای تأیید اعتبار برخی دیگر اجتناب ناپذیر است، اما باید به دقت مورد بررسی قرار گیرد و مهم است که هرگز هدف آزمایش، که ارائه اطلاعات مداوم در مورد هر قانون عملکردی سیستم است، فراموش نشود.
3. بازتولید رفتار سیستم در تست ها
ممکن است وسوسه انگیز باشد که یک الگوریتم محاسباتی را بازتولید کنید، به عنوان مثال، برای تأیید مناسب بودن نتیجه بازگشتی توسط سیستم. اما این عمل بسیار مخاطره آمیز است و به هیچ وجه نمی توان تشخیص داد که آیا نتیجه صحیح محاسبه شده توسط سیستم تحت آزمایش است یا آنچه توسط ابزار تست محاسبه شده است. یک مثال متداول، تولید توکن‌های احراز هویت است: تلاش برای محاسبه یک نشانه معتبر در ابزار تست برای تأیید اعتبار موردی که توسط سیستم برگردانده شده است، خوب نیست. بهترین راه همچنان استفاده از رمز دریافتی برای تایید اعتبار آن است (مراقب باشید در خطای قبلی نیفتید!).
مراقب باشید که پیچیدگی سیستمی را که می‌خواهید آزمایش کنید در خود ابزار تست مجدداً پیاده‌سازی نکنید: ابزار تست باید یک ناظر «ساده» سیستمی باشد که آن را تأیید می‌کند، و این همه مشکل است!
4. انتظار “برای مدتی”
هنگامی که برخی از فرآیندهای سیستم “زمان” می گیرند یا ناهمزمان هستند، ممکن است بخواهید قبل از بررسی اطلاعات خاص “مدت زمان مشخصی” صبر کنید. اما چقدر طول خواهد کشید؟
- اگر خیلی کم صبر کنیم، زمانی که عملکرد به درستی کار می کند، آزمایش با شکست مواجه می شود.
- اگر بیش از حد منتظر بمانیم، زمانی که سیستم پردازش را تمام می‌کند، زمان اجرای آزمایش کاهش می‌یابد، و این می‌تواند تاثیر بسیار جدی در زمانی که صدها یا حتی هزاران آزمایش داشته باشیم، داشته باشد.
اغلب مشخص می شود که ما باید به تدریج این زمان انتظار را افزایش دهیم تا از مثبت کاذب جلوگیری کنیم و در نتیجه زمان زیادی را برای انجام تست ها تلف کنیم. در این شرایط است که می‌توانیم به خروجی‌های ثانویه سیستم نگاه کنیم: می‌توانیم ظاهر یک فایل ورودی یا انتشار یک اعلان خاص را برای راه‌اندازی مرحله بعدی آزمایش بررسی کنیم. سپس خود سیستم به ما می گوید که چه زمانی باید ادامه دهیم.
ما هنوز باید در مورد یک دوره انتظار معقول تصمیم بگیریم تا به این نتیجه برسیم که مشکلی رخ داده است، اما در صورت موفقیت آمیز بودن آزمایش، زمان انتظار را تا حد امکان محدود می کنیم.
5. از مقادیر مرجع پویا استفاده کنید
برای اجرای آزمایش‌ها، «داده‌های مورد انتظار» را تعریف می‌کنیم که برای اعتبارسنجی بازگشت‌های سیستم استفاده می‌شود. ما همیشه باید مراقب باشیم که این داده‌ها را بیش از حد پویا نکنیم: همیشه می‌توانیم داده‌های مربوط به تاریخ فعلی را پویا کنیم یا بر محدودیت‌های منحصربه‌فرد برخی اطلاعات (مثلاً راهنماهای تولید شده) در نتایجی که می‌خواهیم بررسی کنیم غلبه کنیم، اما باید مراقب باشید. داده های ثابت و کنترل شده به عنوان مقادیر مرجع در نظر گرفته شود. در غیر این صورت، ریسک این است که شکل یا ساختار داده ها را به خوبی اعتبار سنجی کنیم، اما حقیقت آن را نه، یعنی نه. ارتباط آنها با توجه به مجموعه داده های آزمون.
6. به روز رسانی داده های مرجع انبوه
این اغلب می تواند زمانی انجام شود که تغییرات قابل توجهی در خط پایه سیستم وجود داشته باشد یا زمانی که می خواهید اولین مجموعه داده های مرجع را برای یک سیستم موجود ایجاد کنید. باید مراقب این موضوع باشید زیرا ممکن است یک یا چند خطا پشت بازخورد فعلی پنهان شده باشد. در واقع، اگر به نظر می رسد همه چیز مربوط به اصلاحات فعلی در سیستم باشد، ممکن است یک یا چند رگرسیون همچنان در نتایج تازه به دست آمده پنهان باشد. از داده های اصلی برای مدت طولانی برای اطمینان از تحویل محصول استفاده می شود و جاسازی یک باگ می تواند بدون اینکه کسی متوجه شود تأثیر بسیار مهمی بر روی مشتریان داشته باشد.
داده های مرجع باید به صورت دستی و به صورت موردی تأیید شوند تا از بهترین مزیت آزمایش سیستم اطمینان حاصل شود.
7. اعمال رفتار آزمایشی خاص در سیستم
این همان “اگر تست” معروف در کد تولید است! اگر یک هدر خاص یا اطلاعات دیگری دریافت شود تا مشخص شود که این یک آزمایش در حال انجام است، رفتار خاصی فعال می شود. این امکان را فراهم می کند تا رفتار سیستم را زمانی که بخشی از آزمایشات است تأیید کرد، اما نه رفتار واقعی آن در تولید. باید اعتراف کنم که گاهی اوقات مجبور به استفاده از آن در موارد بسیار خاص شده ام که ضروری بوده است، اما باید با این عمل بسیار محتاطانه رفتار شود.
8. یک گزارش تست جهانی ایجاد کنید
بسته به ابزار تست مورد استفاده، موارد تست مختلف را می توان اجرا کرد و گزارش ها را به روش های مختلف تولید کرد. مهم است که در پایان تست ها گزارش وضعیت هر عملکرد سیستم را داشته باشید. ما باید از داشتن یک نشانگر وضعیت جهانی (که اغلب “قرمز” است) با نیاز به رفتن به کنسول یا یک فایل برای شناسایی مشکل یا مشکلات رخ داده اجتناب کنیم.
9. تست ها را فقط پس از اصلاح سیستم پخش کنید
اگرچه اجرای تست های سیستم بعد از هر استقرار پس از تغییر سیستم مهم است، اما کافی نیست. بسیار مهم است که به طور منظم از عملکرد سیستم در محیط خود اطمینان حاصل شود. محیط می تواند تکامل یابد و سیستمی که اغلب تغییر نمی کند می تواند به دلایل خارجی تغییر کند. بنابراین، توصیه می شود که تست های موجود را به طور منظم شروع کنید، حتی اگر هیچ تغییری در سیستم وجود نداشته باشد. در غیر این صورت، خطر پیدا کردن تعدادی شگفتی در تغییر بعدی در سیستم وجود دارد.
10. فقط موارد شلوغ را تست کنید
اگرچه تأیید عملکرد صحیح موارد عبور سیستم ضروری است، اما موارد خطا به همان اندازه مهم هستند و گاهی اوقات حتی مهم‌تر هستند، اگر به ویژگی‌های غیرعملکردی کیفیت سیستم مانند قابلیت استفاده یا ایمنی علاقه مند باشیم. برای مثال، اطلاع رسانی صحیح به کاربر در صورت سوء استفاده از سیستم، کیفیت تجربه او را بهبود می بخشد.
در خاتمه…
احتمالاً قبلاً با یک یا چند مورد از این مشکلات روبرو شده اید و همیشه تصمیم گیری متناسب با هر موقعیتی است. نکته مهم هنگام ارزیابی ریسک یا تصمیم گیری این است که تا حد امکان از تأثیری که ممکن است در بلندمدت داشته باشد، آگاه باشید.
در توسعه نرم افزار، مدیریت کیفیت تا حد زیادی در مورد مناسب بودن سرمایه گذاری های بلند مدت است. اگر گاهی مجبور هستید تصمیماتی بگیرید که بدهی فنی محصول شما را افزایش دهد، تا زمانی که فراموش نکنید که آن را به درستی مدیریت کنید در اسرع وقت مشکلی نیست. اما این می تواند موضوعی برای مقاله دیگری باشد…
عکس: مایکل پودگر