تست های سیستم: دیدگاهی عینی از محصول

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

سطوح آزمون

مطابق با توصیه های ISTQB (هیئت بین المللی صلاحیت تست نرم افزار)، آزمون های نرم افزار در سطوح مختلف طبقه بندی می شوند. در اینجا سطوح آزمون سنتی موجود در هرم آزمون کلاسیک آمده است:

• تست های واحد : هدف این تست ها اعتبارسنجی هر واحد کد با جداسازی آن (با استفاده از خرد، جعلی یا جعلی…) است.
• تست های یکپارچه سازی : این تست ها بر ارتباطات یا تبادل پیام بین واحدهای کد مختلف تمرکز دارند
• تست های سیستم : این تست ها تایید می کنند که جنبه های مختلف یک سیستم نرم افزاری کامل با مشخصات مطابقت دارد
• آزمون های پذیرش : هدف این تست ها جلب پذیرش کلی سیستم توسط مشتری، کاربر یا نماینده است.

در AT Internet، از آنجایی که راه حل نرم افزاری ما بسیار گسترده و پیچیده است، ما دو سطح تست را انتخاب کرده ایم:

• تست های یکپارچه سازی سیستم : این تست ها بر تبادل بین سیستم های مختلف که راه حل ما را تشکیل می دهند تمرکز می کنند
• تست های راه حل : این تست ها عملکرد صحیح را به عنوان یک کل راه حل ما که از سیستم های مختلف تشکیل شده است تأیید می کند

سیستم تست می کند

این تست های “سیستم” اولین سطح از تست های به اصطلاح “جعبه سیاه” هستند، یعنی. آنها بر اساس مشخصات محصول (قوانین کسب و کار، الزامات عملکرد و غیره) بدون دسترسی به کد منبع تعریف می شوند. از طرفی تست های به اصطلاح «جعبه سفید» بر اساس ساختار داخلی محصول (معماری، کد، بخش هایی از کد و …) تعریف می شوند.

این تست ها باید کاملا مستقل از ساختار داخلی سیستم (زبان و فناوری های مورد استفاده، جزئیات پیاده سازی و غیره) باشند. آنها فقط باید روی ورودی ها و خروجی های سیستم تمرکز کنند و آن را کاملاً عینی مشاهده کنند. این آنها را قدرتمند و مفید می کند: آنها سپس اعتبار حرفه یا رفتاری را که مستقیماً توسط مشتری درک می شود ممکن می سازند.

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

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

در حالی که تست های واحد و ادغام ضروری است و باید تا حد امکان ارائه شود، سرمایه گذاری در تست سطح سیستم برای اطمینان از تحویل کسب و کار مورد نظر به مشتری ضروری است.

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

تست های سیستم اولین تست هایی هستند که به طور مستقیم با معیارهای پذیرش مشتری در فرآیند تست مرتبط هستند. این تست‌ها، در صورت خودکار بودن، تشخیص رگرسیون‌های احتمالی را در اسرع وقت ممکن می‌سازند، در غیر این صورت خطر غافلگیری ناخوشایند در مراحل بعدی پروژه وجود دارد: زمانی که سیستم در راه‌حل کلی یکپارچه شود یا بدتر از آن، در مشتری. یا یکی از اماکن نمایندگان آنها (مثلاً صاحب محصول).

پس از آن، اصلاح مشکلات پیدا شده بسیار گران تر است و خطر تاخیر در تحویل پروژه بسیار بیشتر است.

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

تست مطمئناً بخشی از فعالیت های توسعه است و مسئولیت ارائه یک محصول کارآمد بر عهده کل تیم است، درست است؟

روش تست سیستم چیست؟

برای تست صحیح یک سیستم، ابتدا باید جنبه های مختلف سیستم ما را درک کنید:

سوابق سیستم

همه اینها محرک هایی برای رفتار سیستم هستند. ما اغلب به اقدامات کاربر به عنوان محرک‌های آشکار فکر می‌کنیم، اما می‌تواند بسیار بیشتر باشد. در اینجا چند نمونه آورده شده است:

• اقدام کاربر
• اعلان ها را دریافت کنید
• تغییر وضعیت سیستم
• گذر زمان (بله، می تواند اقداماتی را آغاز کند و حتی اغلب اتفاق می افتد: مکانیسم های همگام سازی، زمان بندی کار، و غیره)

سیستم نمایش داده می شود

در اینجا ما اغلب به پاسخ ارائه شده به کاربر فکر می کنیم، اما نتایج بسیار کلی دیگری وجود دارد که همیشه به آنها فکر نمی کنیم. به عنوان مثال:

• پاسخ کاربر
• مجلات نگارشی (ژورنال)
• داده ها را در پایگاه داده ذخیره کنید
• صدور اطلاعیه

رفتار مورد انتظار (یا قوانین تجاری)

اکنون می دانیم که چگونه سیستم را با بازی در ورودی های مختلف آن فعال کنیم. ما همچنین می دانیم که با نگاه کردن به گردش های مختلف چه چیزی را می توانیم مشاهده کنیم. در مرحله بعد، باید ارتباط بین ورودی و خروجی را بدانیم. این روابط به عنوان قوانین تجاری سیستمی توصیف می شوند و می توانند اشکال مختلفی داشته باشند: از معیارهای پذیرش داستان کاربر در Agility تا مشخصات دقیق تر در زمینه های دیگر.

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

زمینه های عملکردی

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

بیایید یک فراخوانی API را برای نوشتن اطلاعات جدید در سیستم مثال بزنیم. سپس دو مورد با رفتارهای ممکن متفاوت داریم:

• اطلاعات قبلاً در سیستم موجود است:
  • ما هر دو اطلاعات را ذخیره می کنیم
  • ما در حال به روز رسانی اطلاعات موجود هستیم
  • ما تاریخچه مقادیر اطلاعات را ذخیره می کنیم
• اطلاعات هنوز در دسترس نیست
  • اطلاعات دریافتی را ثبت می کنیم
  • ما هیچ درمانی انجام نمی دهیم

در هر دو موقعیت، زمینه اجرا تأثیر مستقیمی بر رفتار مورد انتظار سیستم دارد. اینجاست که مجموعه داده‌های تست اهمیت می‌یابد: ما قبل از هر آزمایش، زمینه‌ای را ایجاد می‌کنیم که می‌خواهیم در آن باشیم تا بتوانیم رفتارهای مختلف سیستم خود را تأیید کنیم. سپس ما چندین ترکیب از همه این عناصر داریم که موارد آزمایش ما را نشان می دهد:

• مجموعه ای از داده های آزمایشی
• یک یا چند ورودی “فعال”.
• رفتار مورد انتظار
• یک یا چند خروجی کنترل

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

بسته به مورد، این مکانیسم تست به طور مستقیم در ابزارهای موجود در بازار، بسته به سیستمی که می خواهیم آزمایش کنیم، موجود است:

• تست های API: SOAP UI، supertest، Postman و غیره.
• تست های رابط: سلنیوم، سرو، نایت واچ جی اس و غیره.

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

• در تم کافکا بخوانید/بنویسید
• ارسال/بازیابی اعلان ها
• درج داده ها در پایگاه های داده
• دریافت ایمیل
• و غیره

در اینجا مشاهده می شود که ابزار تست ارتباطی با فناوری استفاده شده در سیستم مورد آزمایش ندارد. اغلب بسیار متفاوت است و به نیازهای پردازش اطلاعات سیستم مربوط نمی شود، بلکه به محدودیت های اعمال شده بر مشتری (های) سیستم مربوط می شود.

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

تست API

بیایید مثال خاص یک API را به عنوان یک سیستم آزمایشی در نظر بگیریم. کلاسیک های اصلی اعتبارسنجی PLC به ترتیبی که سیستم باید آنها را بررسی کند عبارتند از:

• حقوق استفاده از این API
  • تماس غیرمجاز ممکن است بدون در نظر گرفتن اعتبار آن بلافاصله رد شود
• اعتبارسنجی پارامتر
  • عدم وجود پارامترهای اجباری
  • اعتبار ترکیب حاصل از پارامترها
    • برخی از پارامترها ممکن است گاهی اوقات ناسازگار باشند و نباید در همان فراخوانی ارسال شوند
  • فرمت هر پارامتر
    • نوع، مدل، مقادیر مجاز،…
  • سازگاری مقادیر به دست آمده برای پارامترهای مختلف
    • به عنوان مثال، دریافت یک درخواست مرتب سازی در یک فیلد ناخواسته گاهی اوقات می تواند رد شود
• ارتباط تجاری سیستم
  • این شامل تأیید قوانین تجاری خود سیستم است. به عنوان مثال، درخواست اطلاعات (GET) برای یک ویژگی غیرموجود ممکن است باعث خطا شود، درج داده‌ها در پایگاه داده از طریق API باعث دریافت شناسه آن در ازای بازگشت می‌شود.

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

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

به عنوان مثال، تست های عملکرد یا ایمنی را می توان با ابزارهای مختلفی مانند LOAD UI، Gatling، JMeter، Neoload بررسی کرد. در این نوع تست، تکنیک های شناخته شده ای مانند:

• تست های تزریقی
• آزمایش خزه
• در زدن
• به تدریج بار را افزایش دهید
• …

نتیجه گیری

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

با این روحیه، ما در اینترنت AT بر روی اجرای تست های سیستم خودکار، با توجه به نیازهای هر پروژه و با در نظر گرفتن زمینه هر تیم سرمایه گذاری می کنیم. ما سرمایه گذاری های خود را در راستای استراتژی آزمایش خود متمرکز می کنیم تا از بالاترین کیفیت محصولات خود به نفع مشتریان خود اطمینان حاصل کنیم.

در مقاله بعدی، 10 دامی را که باید هنگام تنظیم تست های سیستم از آن اجتناب کنید، بحث خواهم کرد.

اعتبار عکس های ویژه: مارکوس اسپیسکه