در پارت قبلی این پست، توضیح مختصری در مورد تست استاتیک و دلایل انجام اون رو گفتیم. در این پست چگونگی انجام این تست رو با مثال توضیح میدیم.
چگونه تست استاتیک رو انجام بدیم؟
روش های مختلفی برای انجام این تست وجود داره که عبارتند از:
- بازبینی Review: برای بازرسی کامل از طراحی سیستم ، بازبینی انجام میشه. بازبینی طی جلسات و فرآیندهایی انجام میشه که کلی داستان داره و نقش و …
- چک لیست: برای اطمینان از اینکه کلیه بازبینی ها به طور کامل پوشش داده شده ، از چک لیست استفاده میشه.
حال بازبینی یعنی چی؟
بازبینی روی تمامی اسناد نوشته شده به صورت دستی یا با ابزار مربوطه انجام می شه. ازچه اسنادی صحبت می کنیم؟
- کُد برنامه
- پروتوتایپ
- داکیومنت های موجود
اهمیت دیگه بازبینی این هست که تمام اعضای تیم از پیشرفت پروژه مطلع شن و گاهی اوقات به پیشنهادات عالی منجر میشه. مستندات مستقیما توسط افراد بررسی می شن ، نقایص معلوم و برطرف میشه.
مزایای بازبینی:
- شناسایی نقص های اولیه
- کاهش زمان توسعه و بهبود بهره وری
- کاهش هزینه و زمان تست
انواع نقص هایی که در تست استاتیک پیدا میشه عبارتند از:
- انحراف از استانداردهای تعیین شده
- کُد غیرقابل نگهداری
- باگ های طراحی
- نیازمندیهایی که دیده نشده
- مشخصات اینترفیس های ناسازگار
فعالیت های مختلفی برای انجام تست استاتیک انجام میشه که عبارتند از:
- استفاده از نیازمندیهای اعتبارسنجی در یوزکیس ها: اعتبارسنجی می کنه که کلیه اقدامات کاربرنهایی و همچنین هر ورودی و خروجی مرتبط با آنها مشخص شده یا نه؟ هر چه یوزکیس ها دقیقتر و کاملتر باشن ، تست کیس ها دقیقتر و کاملتر نوشته می شه.
- اعتبارسنجی نیازمندیهای فانکشنال: تضمین می کنه که نیازمندیهای فانکشنال، تمام عناصر لازم را شناسایی کنه. همچنین به فانکشنالیتی دیتابیس، لیست های اینترفیس، و سخت افزار، نرم افزار و نیازمندیهای شبکه می پردازه.
- بازبینی معماری : کلیه مراحل سطح کار مانند مکان های سرور، نمودارهای شبکه، تعاریف پروتکل، لود بالانسینگ، دسترسی پذیری دیتابیس، تجهیزات تست و …رو بررسی می کنه
- اعتبارسنجی پروتوتایپ / Mockup Screen: این مرحله شامل نیازمندی های مورد نیاز و یوزکیس هست.
- اعتبارسنجی فیلدهای دیکشنری: هر فیلدی در UI رو بررسی می کنه. یعنی محدودیت هایی که برای هر فیلد در نظر گرفته شده، رعایت شده یا نه؟ مثل اینکه بیشترین/ کمترین طول مقادیر وارد شده رعایت شده؟ نوع مقادیر؟ نمایش پیام
برخی نکات مفید برای انجام فرآیند تست استاتیک عبارتند از:
- فقط روی نکاتی تمرکز کنین که واقعا به حساب میان. لزومی نداره تمامی اسناد مورد تست قرار بگیرن. با توجه به اولویت و زمانبندی عمل کنین.
- به طور واضح فعالیت های بازبینی را برنامه ریزی و پیگیری کنین.
- مشکلات را حل کنین
- فرآیند را به عنوان پروژه رسمی نگهدارین.
- بهبود مداوم فرآیند رو درنظر داشته باشین
- با از بین بردن تاخیر در اجرای تست، هزینه تست و زمان آن کاسته میشه.
مثال:
یوزکیس لاگین مورد بازبینی قرار میگیره و نکات زیر بایستی داخل اون رعایت شه:
- بیشترین تعداد و کمترین تعداد کاراکتر فیلدهای نام کاربری و رمز عبور
- نوع ورودی کاراکترهای فیلدهای نام کاربری و رمز عبور
- چک کردن پیام های خطا در صورت ورود اشتباه اطلاعات
- بعد از چند بار وارد کردن اطلاعات اشتباه سیستم عکس العمل خاصی (مانند بلاک کردن و …) نشون بده
- و …
پس از بررسی های فوق، نقص های موجود رو اعلام کرده و پس از رفع آن مجدد بررسی کنین. روند فوق برای طراحی سیستم و بقیه مستندات متفاوت هست. یادتون باشه تست استاتیک برای پروژه های زیر بکار میره:
- سیستمی که هنوز کُد زدنش شروع نشده
- بخش های جدیدی به سیستم موجود داره اضافه میشه
- بازخوانی کُدی که قبلا نوشته شده
نتیجه:
- تست استاتیک برای یافتن باگ در اسرع وقت هست.
- تست استاتیک جایگزین تست داینامیک نیست بلکه هر دو، نوع های مختلفی از باگ را پیدا می کنن.
- بازبینی ها یک روش موثر برای تست استاتیک هست.
- بازبینی نه تنها به یافتن نقص کمک می کنه بلکه به درک نیازمندیهای فراموش شده، نقص در طراحی، کد غیر قابل نگهداری نیز کمک می کنه.
هرچی که عنوان شد طی تجربه در این زمینه بوده و خب کم و کاستی هم ممکنه داشته باشه. شما تجربه هاتون رو با کامنت به مشارکت بذارین. در خصوص تعاریف آکادمیک و استاندارد این تست ، همچنین اطلاعاتی مانند ابزارهای مربوطه به این لینک مراجعه کنین.