فرآیند تست فناوری چرا آزمایش لازم است

| برنامه ریزی درسی برای سال تحصیلی | مراحل اصلی مدل سازی

درس 2
مراحل اصلی مدل سازی

با مطالعه این مبحث یاد خواهید گرفت:

مدلینگ چیست؛
- چه چیزی می تواند به عنوان نمونه اولیه برای مدل سازی باشد.
- جایگاه الگوسازی در فعالیت های انسانی چیست؟
- مراحل اصلی مدل سازی چیست؟
- مدل کامپیوتری چیست
آزمایش کامپیوتری چیست؟

آزمایش کامپیوتری

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

در مدرسه، شما آزمایش هایی را در درس های زیست شناسی، شیمی، فیزیک، جغرافیا انجام می دهید.

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

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

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

طرح آزمایش

طرح آزمایش باید به وضوح توالی کار با مدل را منعکس کند. اولین قدم در چنین طرحی همیشه آزمایش مدل است.

تست فرآیند بررسی صحت مدل ساخته شده است.

تست - مجموعه ای از داده های اولیه که به شما امکان می دهد صحت ساخت مدل را تعیین کنید.

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

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

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

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

انجام تحقیقات

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

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

طرح آماده سازی و اجرای آزمایش کامپیوتری در شکل 11.7 نشان داده شده است.

برنج. 11.7. طرح یک آزمایش کامپیوتری

تجزیه و تحلیل نتایج شبیه سازی

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

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

نکته اصلی که باید به خاطر داشته باشید این است که خطای شناسایی شده نیز نتیجه است. همانطور که ضرب المثل می گوید، شما از اشتباهات خود درس می گیرید. شاعر بزرگ روسی A. S. Pushkin نیز در این باره نوشت:

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

سوالات و وظایف را کنترل کنید

1. دو نوع اصلی بیان مسئله مدل سازی چیست؟

2. در کتاب معروف «مسئله» اثر جی اوستر، مشکل زیر وجود دارد:

جادوگر شیطان صفت که خستگی ناپذیر کار می کند، روزانه 30 شاهزاده خانم را به کاترپیلار تبدیل می کند. چند روز طول می کشد تا او 810 شاهزاده خانم را به کاترپیلار تبدیل کند؟ چند پرنسس در روز باید تبدیل به کاترپیلار شوند تا کار را در 15 روز انجام دهند؟
کدام سوال را می توان به نوع "چه اتفاقی می افتد اگر ..." و کدام را به نوع "چگونه انجام داد که ..." نسبت داد؟

3. شناخته شده ترین اهداف مدلینگ را فهرست کنید.

4. مشکل بازیگوش را از "کتاب مشکل" G. Oster رسمی کنید:

از دو غرفه که در فاصله 27 کیلومتری از یکدیگر قرار داشتند، دو سگ خصمانه همزمان به سمت یکدیگر پریدند. اولی با سرعت 4 کیلومتر در ساعت و دومی - 5 کیلومتر در ساعت اجرا می شود.
دعوا تا کی شروع میشه؟

5. تا جایی که می توانید ویژگی های شی «جفت کفش» را نام ببرید. آرایش مدل اطلاعاتیشی برای اهداف مختلف:

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

6. چه ویژگی های یک نوجوان برای توصیه در انتخاب حرفه ضروری است؟

7. چرا کامپیوتر به طور گسترده در شبیه سازی استفاده می شود؟

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

9. آزمایش کامپیوتری چیست؟ مثال زدن.

10. تست مدل چیست؟

11. در فرآیند مدل سازی با چه خطاهایی مواجه می شویم؟ وقتی خطایی پیدا شد چه باید کرد؟

12. تجزیه و تحلیل نتایج شبیه سازی چیست؟ معمولاً چه نتایجی گرفته می شود؟

حاشیه نویسی: مفاهیم اولیه تست زنی مراحل و مراحل آزمایش. انواع تست توسعه آزمایش محور

معرفی

تست یکی از شناخته شده ترین راه هاست تضمین کیفیتتوسعه نرم افزار.

از نظر فنیاز این منظر، آزمایش شامل اجرای یک برنامه کاربردی بر روی مجموعه خاصی از داده های اولیه و مقایسه نتایج به دست آمده با نتایج شناخته شده قبلی (مرجع) به منظور ایجاد انطباق ویژگی ها و ویژگی های مختلف برنامه با ویژگی های سفارش شده است. به عنوان یکی از مراحل اصلی فرآیند توسعه محصول نرم افزاری (طراحی برنامه - توسعه کد - تست)، آزمایش با سهم نسبتاً زیادی در کل شدت کار توسعه محصول مشخص می شود. تخمین توزیع شدت کار بین مراحل ایجاد یک محصول نرم افزاری به طور گسترده ای شناخته شده است: 40٪ -20٪ -40٪.

از نظر ریاضیآزمایش را می توان به عنوان تفسیری از برخی فرمول ها و آزمایش صدق آن در برخی از مجموعه ها در نظر گرفت. در واقع، برنامه را می توان به صورت فرمول f = f1* f2* f3*... * fn نشان داد که در آن f1، f 2، ... fn عملگرهای زبان برنامه نویسی هستند و برهم نهی آنها یک برنامه است.

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

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

تست استاتیکبا استفاده از روش‌های تحلیل رسمی بدون اجرای برنامه تحت آزمایش، ساختارهای نادرست یا روابط نادرست بین اشیاء برنامه (خطاهای انتساب رسمی) را با استفاده از ابزارهای کنترل کد ویژه - CodeChecker تشخیص می‌دهد.

تست دینامیک(تست واقعی) خطاها را فقط در برنامه در حال اجرا با استفاده از ابزارهای خاص تشخیص می دهد تست اتوماسیون- تخت تست یا تست میز.

مبانی تست زنی

کلاس های معیار آزمون

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

• شرایط معیار تست فرمان (معیار C0) - مجموعه آزمایشات در مجموع باید اطمینان حاصل کند که هر دستور حداقل یک بار تصویب شده است.
• شرایط معیار آزمون انشعاب (معیار C1) - مجموعه آزمایشات در مجموع باید اطمینان حاصل کند که هر شاخه حداقل یک بار پاس شده است.
• شرایط معیار تست مسیر (معیار C2) - مجموعه آزمایشات در مجموع باید اطمینان حاصل کند که هر مسیر حداقل 1 بار گذرانده شده است.

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

انواع خاص زیر متمایز می شوند معیارهای عملکردی:

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

بررسی وجود ویژگی های مشخص شده در برنامه مورد آزمایش، با استفاده از آزمون برخی فرضیه های آماری. هنگام آزمایش سیستم های نرم افزاری پیچیده استفاده می شود - زمانی که مجموعه ای از تست های قطعی (X، Y) دارای قدرت عظیمی هستند.

معیارهای جهشبر بررسی ویژگی های یک محصول نرم افزاری بر اساس رویکرد مونت کارلو متمرکز شده است.

روش آزمایش جهش به این صورت است که جهش ها (خطاهای کوچک) به برنامه توسعه یافته P وارد می شوند، یعنی. به طور مصنوعی برنامه های جهش یافته P1, P2... را ایجاد کنید. سپس برنامه P و جهش یافته های آن روی همان مجموعه آزمایش (X, Y) آزمایش می شوند.

اگر درستی برنامه P در مجموعه (X, Y) تأیید شود و علاوه بر این، تمام خطاهای وارد شده به برنامه های جهش یافته آشکار شود، مجموعه آزمایشات (X, Y) معیار جهش را برآورده می کند و برنامه تست شده صحیح اعلام شده است. اگر برخی از جهش‌ها همه جهش‌ها را آشکار نکردند، لازم است مجموعه آزمایشی (X، Y) گسترش داده شود و آزمایش ادامه یابد.

مراحل تست

هنگام آزمایش، به عنوان یک قاعده، سه مرحله متمایز می شود: واحد، یکپارچه سازی و تست سیستم.

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

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

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

تست سیستم در کل پروژه با استفاده از روش "جعبه سیاه" انجام می شود. ساختار برنامه مهم نیست، فقط ورودی ها و خروجی ها برای آزمایش در دسترس هستند، برای کاربر قابل مشاهده است. کدها و اسناد کاربر در معرض آزمایش هستند.

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

مراحل تست

هر یک مرحله آزمایششامل مراحل زیر است:

1. تعیین اهداف(الزامات تست)، از جمله مشخصات زیر: چه قسمت هایی از سیستم تست می شود، چه جنبه هایی از کار آنها برای تست انتخاب می شود، کیفیت مطلوب چقدر است و غیره.
2. برنامه ریزی: ایجاد یک برنامه (برنامه) برای توسعه آزمایشات برای هر زیر سیستم آزمایش شده. ارزیابی منابع انسانی، نرم افزاری و سخت افزاری لازم؛ زمان بندی چرخه های آزمون توجه به این نکته ضروری است که برنامه آزمایشی باید لزوماً با برنامه توسعه سیستم در حال ایجاد سازگار باشد.
3. توسعه تست (کد تستبرای سیستم تحت آزمایش).
4. در حال اجرا تست ها: اجرای حلقه های تست .
5. تجزیه و تحلیل نتایج.

چرخه تستیک چرخه اجرای تست است که شامل مراحل 4 و 5 فرآیند تست می باشد. چرخه آزمایش شامل اجرای آزمایش‌های توسعه‌یافته بر روی برخی از بخش‌های تعریف‌شده منحصربه‌فرد سیستم (وضعیت کد سیستم در حال توسعه) است. معمولاً چنین برشی از سیستم نامیده می شود ساختن.

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

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

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

تمام اطلاعات مربوط به عیوب یافت شده در طول آزمایش (نوع، شرایط تشخیص، علت، شرایط اصلاح، زمان صرف شده برای اصلاح) در پایگاه داده عیوب وارد می شود.

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

انواع تست

طرح آزمون انواع مختلف را تعریف و مستند می کند انواع تست.

انواع تست بر اساس نوع زیرسیستم یا محصول به شرح زیر است:

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

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

1. تست عملکردی که بررسی می کند:
   • پوشش الزامات عملکردی؛
   • پوشش موارد استفاده
2. تست استرس، که حالت های شدید استفاده از محصول را بررسی می کند.
3. تست مقادیر مرزی
4. ازمایش عملکرد.
5. تست انطباق با استانداردها
6. تست سازگاری با سایر سیستم های نرم افزاری و سخت افزاری.
7. آزمایش کار با محیط.
8. آزمایش کار بر روی یک پلت فرم خاص.

توسعه آزمایش محور

روش آزمایشی را در نظر بگیرید که کمی با روش بالا متفاوت است. Test Driven Development (TDD) یک فرآیند توسعه نرم افزاری است که شامل نوشتن و خودکار کردن تست های واحد قبل از نوشتن کلاس ها یا ماژول های مربوطه است. این تضمین می کند که تمام مسئولیت های هر نرم افزار قبل از کدگذاری تعریف شده است.

TDD ترتیب مراحل برنامه نویسی زیر را مشخص می کند:

• قرمز - یک تست کوچک بنویسید که کار نمی کند، یا حتی ممکن است کامپایل نشود.
• سبز - بدون نگرانی در مورد طراحی صحیح و تمیزی کد، آزمایش را با بیشترین سرعت ممکن اجرا کنید. فقط به اندازه کافی کد بنویسید تا تست کار کند.
• Refactoring - هر گونه تکراری را از کدی که می نویسید حذف کنید.
• پس از تسلط بر TDD، توسعه دهندگان متوجه می شوند که به طور قابل توجهی تست های بیشتری نسبت به قبل می نویسند و در گام های کوچکی که ممکن است قبلاً بیهوده به نظر می رسید به جلو حرکت کنند.

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

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

نتایج

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

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

علاوه بر این، تحقیقات در زمینه آزمون های متمرکز در حال انجام است مدل خاصتوسعه (آبشار، مارپیچ) یا یک الگوی برنامه نویسی خاص. به عنوان مثال، آزمایش با استفاده از عامل ها برای آزمایش سیستم های جزء گرا پیشنهاد شده است. برای آزمایش اپلت های فعال جاوا، استفاده از شبکه های عصبی پیشنهاد شده است. برای آزمایش عواملی که در وب (روبات ها، عنکبوت ها) وجود دارند، پیشنهاد می شود از سیستم های مبتنی بر دانش استفاده شود.

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

اکثر بهترین راهارزیابی کنید که آیا محصول را به خوبی آزمایش کرده ایم یا خیر - عیوب از دست رفته را تجزیه و تحلیل کنید. کسانی که کاربران، مجریان، مشاغل ما با آنها روبرو هستند. شما می توانید از آنها بسیار ارزیابی کنید: آنچه را که ما به اندازه کافی بررسی نکردیم، به چه بخش هایی از محصول باید توجه بیشتری شود، درصد حذفیات به طور کلی چقدر است و پویایی تغییرات آن چقدر است. با این معیار (شاید رایج ترین مورد در آزمایش)، همه چیز خوب است، اما ... وقتی محصول را منتشر کردیم و از خطاهای از دست رفته مطلع شدیم، ممکن است خیلی دیر باشد: یک مقاله عصبانی درباره ما در Habré ظاهر شد، رقبا هستند با انتشار سریع انتقاد، مشتریان اعتماد خود را به ما از دست داده اند، مدیریت ناراضی است.

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

چرا ارزیابی؟

1. نقاط ضعف خود را پیدا کنیدبه طور طبیعی، ما به این نیاز داریم؟ نه فقط برای غصه خوردن، بلکه برای اینکه بدانیم کجا به بهبود نیاز است. کدام حوزه های عملکردی تحت پوشش آزمایش قرار نمی گیرند؟ چه چیزی را بررسی نکرده ایم؟ بزرگترین خطرات خطاهای از دست رفته کجاست؟
2. به ندرت بر اساس نتایج ارزیابی، پوشش 100 درصدی دریافت می کنیم. چه چیزی را بهتر کنیم؟ کجا بریم؟ الان چند درصده؟ چگونه می توانیم آن را با هر وظیفه ای افزایش دهیم؟ چقدر سریع می توانیم به 100 برسیم؟ همه این سؤالات شفافیت و شفافیت را در روند ما به ارمغان می آورد.، و پاسخ آنها توسط برآورد پوشش داده می شود.
3. تمرکز توجه.فرض کنید محصول ما حدود 50 ناحیه کاربردی مختلف دارد. یک نسخه جدید می آید و ما شروع به تست 1 آن می کنیم و اشتباهات تایپی را در آنجا پیدا می کنیم و دکمه هایی را که چند پیکسل جابجا کرده اند و موارد جزئی دیگر ... و اکنون زمان تست به پایان رسیده است و این قابلیت دارد با جزئیات بررسی شده است ... و 50 باقی مانده؟ ارزیابی پوشش به ما امکان می دهد وظایف را بر اساس واقعیت ها و ضرب الاجل های فعلی اولویت بندی کنیم.

چگونه ارزیابی کنیم؟

ارزیابی پوشش نیازمندی ها توسط آزمون ها

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

مشکل: الزامات اتمی نیستند.

بنابراین، داشتن یک آزمون الزامی هیچ تضمینی برای ما ندارد! آمار پوشش ما در این مورد به چه معناست؟ تقریبا هیچی! ما باید تصمیم بگیریم!

1. در این مورد، محاسبه خودکار پوشش الزامات توسط آزمایش ها را می توان حذف کرد - هنوز بار معنایی ندارد.
2. برای هر نیاز، با شروع با بالاترین اولویت، تست هایی را آماده می کنیم. هنگام آماده سازی، ما تجزیه و تحلیل می کنیم که چه آزمایش هایی برای این نیاز مورد نیاز است، چه تعداد کافی خواهد بود؟ ما یک تجزیه و تحلیل آزمایشی کامل انجام می دهیم، و "یک آزمایش وجود دارد، اما خوب" را کنار نمی گذاریم.
3. بسته به سیستم مورد استفاده، ما تست ها را در صورت تقاضا صادر می کنیم/ آپلود می کنیم و ... این تست ها را آزمایش می کنیم! آیا آنها کافی هستند؟ البته، در حالت ایده آل، چنین آزمایشی باید با یک تحلیلگر و یک توسعه دهنده این قابلیت انجام شود. تست ها را چاپ کنید، همکاران خود را در اتاق جلسه قفل کنید و تا زمانی که آنها نگویند "بله، این تست ها کافی است" را رها نکنید (این فقط با توافق کتبی اتفاق می افتد، زمانی که این کلمات برای لغو اشتراک گفته می شود، حتی بدون تجزیه و تحلیل تست ها). در طول یک بحث شفاهی، همکاران شما یک انتقاد از وان، تست های از دست رفته، نیازهای اشتباه درک شده و غیره را مطرح می کنند - این همیشه خوشایند نیست، اما برای آزمایش بسیار مفید است!)
4. پس از نهایی شدن تست‌های درخواستی و توافق بر سر کامل بودن آن‌ها، در سیستم می‌توان این الزام را با وضعیت "تحت پوشش تست" مشخص کرد. معنای این اطلاعات بسیار بیشتر از "حداقل 1 تست در اینجا وجود دارد."

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

مشکل: هیچ الزامی وجود ندارد.

1. یک لیست ویژگی ایجاد کنید. سامی! در قالب یک تبلت گوگل، در قالب PBI در TFS - هر کدام را انتخاب کنید، فقط نه قالب متن. ما هنوز نیاز به جمع آوری وضعیت داریم! ما تمام بخش‌های عملکردی محصول را در این لیست گنجانده‌ایم و سعی می‌کنیم یک سطح کلی از تجزیه را انتخاب کنیم (شما می‌توانید اشیاء نرم‌افزار، یا اسکریپت‌های کاربر، یا ماژول‌ها، یا صفحات وب، یا روش‌های API، یا فرم‌های صفحه نمایش را بنویسید. .) - اما نه همه اینها به یکباره! یک قالب تجزیه که باعث می شود چیزهای مهم را از دست ندهید، آسان تر و واضح تر می شود.
2. ما کامل بودن این لیست را با تحلیلگران، توسعه دهندگان، کسب و کار، در تیم خود هماهنگ می کنیم ... سعی کنید همه چیز را انجام دهید تا قسمت های مهم محصول را از دست ندهید! اینکه چقدر عمیق تحلیل کنید به خودتان بستگی دارد. در تمرین من، فقط چند محصول وجود داشت که برای آنها بیش از 100 صفحه در جدول ایجاد کردیم و اینها محصولات غول پیکر بودند. اغلب، 30-50 خط یک نتیجه قابل دستیابی برای پردازش دقیق بیشتر است. در یک تیم کوچک بدون تحلیلگران تست اختصاصی بیشترحفظ عناصر fichelista بسیار دشوار خواهد بود.
3. پس از آن، اولویت‌ها را مرور می‌کنیم و هر خط از fichelist را همانطور که در بخش الزامات توضیح داده شده در بالا پردازش می‌کنیم. تست می نویسیم، بحث می کنیم، در مورد کفایت توافق می کنیم. وضعیت‌ها را علامت‌گذاری می‌کنیم، که برای آن ویژگی تست‌های کافی وجود دارد. ما از طریق ارتباط با تیم، وضعیت، پیشرفت و گسترش تست ها را دریافت می کنیم. همه خوشحالند!

اما... اگر الزامات حفظ شود، اما در قالب قابل ردیابی نباشد، چه؟

مشکل: الزامات قابل ردیابی نیستند.

1. ما یک لیست ویژگی ایجاد می کنیم (به بالا مراجعه کنید)، اما بدون شرح دقیق الزامات.
2. برای هر ویژگی، پیوندهایی به مشخصات فنی، مشخصات، دستورالعمل‌ها و سایر اسناد را با هم جمع‌آوری می‌کنیم.
3. ما بر اساس اولویت ها پیش می رویم، تست ها را آماده می کنیم و در مورد کامل بودن آنها توافق می کنیم. همه چیز یکسان است، تنها به لطف ترکیب همه اسناد در یک صفحه، سهولت دسترسی به آنها، وضعیت شفاف و ثبات آزمایش ها را افزایش می دهیم. در نهایت همه چیز فوق العاده است و همه خوشحال هستند!

اما… مدت زیادی نیست… به نظر می رسد که در هفته گذشته، تحلیلگران 4 مشخصات مختلف را بر اساس درخواست مشتری به روز کرده اند!!!

مشکل: الزامات همیشه تغییر می کنند.

1. فرض کنید قبلاً پیوندهایی به TK و مشخصات را در قالب لیست ویژگی، PBI، الزامات، یادداشت های ویکی و غیره جمع آوری کرده اید. بیایید بگوییم شما قبلاً برای این الزامات آزمایشاتی دارید. و اکنون، نیاز در حال تغییر است! این می تواند به معنای تغییر در RMS یا یک کار در TMS (سیستم مدیریت وظایف)، یا نامه ای در نامه باشد. در هر صورت، به همان نتیجه منتهی می شود: آزمایشات شما قدیمی است! یا ممکن است بی ربط باشند. این بدان معنی است که آنها نیاز به به روز رسانی دارند (پوشش آزمایشی نسخه قدیمیمحصول به نوعی خیلی مورد توجه قرار نمی گیرد، درست است؟)
2. در لیست ویژگی‌ها، در RMS، در TMS (سیستم مدیریت تست - تست‌ها، سایتچکو و غیره) تست‌ها باید بلافاصله و بدون شکست به‌عنوان نامربوط علامت‌گذاری شوند! در HP QC یا MS TFS، هنگام به‌روزرسانی نیازمندی‌ها، می‌توان این کار را به‌طور خودکار انجام داد و در تبلت یا ویکی Google، باید قلم‌ها را کنار بگذارید. اما باید فوراً ببینید: آزمایشات بی ربط هستند! این بدان معنی است که ما منتظر یک مسیر مجدد کامل هستیم: به روز رسانی، تجزیه و تحلیل تست را دوباره اجرا کنید، تست ها را بازنویسی کنید، روی تغییرات توافق کنید، و تنها پس از آن ویژگی/نیاز را دوباره به عنوان "تست پوشانده شده" علامت گذاری کنید.

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

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

1. شما هنوز به الزامات کامل یا به عنوان لیست ویژگی نیاز دارید، بنابراین یکی از بخش های بالا، بسته به کار تحلیلگران در پروژه، همچنان ضروری خواهد بود. یک فهرست مورد نیاز/ویژگی دارید؟
2. ما یک استراتژی تست کوتاه را توصیف می کنیم و به صورت شفاهی با آن موافقت می کنیم، بدون مستندسازی آزمون های خاص! این استراتژی ممکن است در یک ستون جدول، در یک صفحه ویکی یا در یک الزام در RMS مشخص شود و دوباره باید با آن موافقت شود. در این استراتژی، آزمایش ها به روش های مختلف انجام می شود، اما می دانید: آخرین بار کی و با چه استراتژی آزمایش شده است؟ و این، می بینید، همچنین بد نیست! و همه خوشحال خواهند شد.

ولی… چه چیز دیگری "جز"؟ کدوم؟؟؟

بگویید، ما همه چیز را دور خواهیم زد و ممکن است محصولات با کیفیت بالا همراه ما باشند!

چرا آزمایش لازم است؟

در این بخش، ما بیشتر به بررسی خواهیم پرداخت مفاهیم اساسیو اصولی که در فرآیند تست استفاده می شود. ما متوجه خواهیم شد که در واقع آزمایش چیست، چرا به آن نیاز است و چه کسی آن را انجام می دهد. اهداف، اصول و مراحل اصلی آزمون را در نظر بگیرید. بیایید احساس کنیم که نگرش روانشناختی یک آزمایشگر واقعی چگونه باید باشد و در نهایت چند افسانه در مورد آزمایش را از بین ببریم. ما مطمئن هستیم که شما علاقه مند خواهید شد.
بیایید با چیستی "تست" شروع کنیم. برای شروع، اجازه دهید از تعاریف خشک دانشگاهی انتزاع بگیریم و به این مفهوم از نظر استفاده روزمره نگاه کنیم.
وقتی چیزی را آزمایش می کنیم، یک سوال ساده از خود می پرسیم: "آیا آنطور که ما انتظار داریم کار می کند؟" یا به عبارت دیگر: آیا رفتار واقعی جسم آزمایشی با انتظارات ما مطابقت دارد؟ اگر پاسخ مثبت است، عالی است، اگر نه، ما در انتظاراتمان فریب خورده ایم، یعنی چیزی باید اصلاح شود.
آزمایش لازم است زیرا همه ما اشتباه می کنیم. برخی از اینها ممکن است جزئی باشند، در حالی که برخی دیگر ممکن است مخرب ترین باشند. هر چیزی که توسط انسان تولید می شود می تواند حاوی خطا باشد (ما انسان ها اینگونه چیده شده ایم). به همین دلیل است که هر محصولی قبل از اینکه بتوان به طور موثر و ایمن از آن استفاده کرد نیاز به تأیید - آزمایش دارد.
همین امر در مورد نرم افزار (eng. Software) نیز صادق است.
نرم افزار (نرم افزار) - برنامه های کامپیوتری، توابع و اسناد و داده های همراه مربوط به عملکرد سیستم کامپیوتری.
فناوری های رایانه ای عمیق تر و عمیق تر به زندگی روزمره ما نفوذ می کنند. نرم افزار عملکرد بسیاری از چیزهای اطراف ما را کنترل می کند - از تلفن های همراهو کامپیوتر به ماشین های لباسشوییو کارت های اعتباری در هر صورت، همه ما با برخی یا خطاهای دیگری در برنامه‌ها مواجه شده‌ایم: ویرایشگر متنی که در حین کار بر روی یک پروژه فارغ‌التحصیلی مسدود می‌شود، خودپردازی که یک کارت را «خورد» یا فقط سایتی که به هیچ وجه بارگذاری نمی‌شود - همه اینها زندگی را برای ما آسان نمی کند.
با این حال، همه خطاها به یک اندازه خطرناک نیستند - برای برنامه های مختلفسطوح خطر ممکن است متفاوت باشد.
ریسک (ریسک):
- عاملی که می تواند منجر به عواقب منفی در آینده شود. به عنوان یک قاعده، بر حسب احتمال وقوع چنین پیامدهایی و تأثیر آنها بر سیستم بیان می شود.
- چیزی که هنوز اتفاق نیفتاده است و ممکن است اصلاً اتفاق نیفتد. مشکل بالقوه
علاوه بر این، سطح ریسک به احتمال وقوع پیامدهای منفی بستگی دارد.
برای مثال، همان خطای جزئی، مثلاً یک اشتباه تایپی، می‌تواند سطوح خطر کاملاً متفاوتی برای برنامه‌های مختلف داشته باشد:
- اشتباه تایپی در شرح علایق در یک صفحه شخصی در یک شبکه اجتماعی بعید است عواقب قابل توجهی داشته باشد، به جز اینکه باعث لبخند دوستان شما می شود.
- همان اشتباه تایپی ساده ای که در شرح فعالیت انجام شده است شرکت بزرگارسال شده در وب سایت آن در حال حاضر خطرناک است، زیرا به طور غیرمستقیم نشان دهنده غیرحرفه ای بودن کارمندان آن است.
- اشتباه تایپی در کد برنامه ای که سطوح نوردهی را در حین کار دستگاه اشعه ایکس محاسبه می کند (مثلاً 100 به جای 10) می تواند ناگوارترین عواقب را به همراه داشته باشد - آسیب به سلامت و ایمنی افراد منجر می شود. از دست دادن اعتماد به شرکت و دعاوی با صفرهای زیاد.

هدف شما مانند مدیر سیستم
اجرای استراتژی های موثر برای
به حداکثر رساندن منابع کامپیوتری خود

D. Gunter، S. Barnet، L. Gunter.
ادغام ویندوز NT و یونیکس

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

چه چیزی در حال آزمایش است و چرا

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

بنابراین، در چنین مواردی چه عواملی در نظر گرفته می شود، موضوع تحقیق چیست و چه نوع تست هایی محبوبیت بیشتری دارند؟

معیارهای آزمون معمولاً عبارتند از:

• عملکرد محصول؛
• سهولت توسعه؛
• سهولت نصب؛
• کیفیت اسناد و پشتیبانی؛
• کارایی؛
• برای تجهیزات، طراحی گاهی اوقات در نظر گرفته می شود.

معیارهای بسیار مبهم نیز وجود دارد. چندی پیش، مروری بر سرورهای وب «درجه بالایی از یکپارچگی با سیستم عامل» را به عنوان یک عامل مثبت در رتبه بندی کلی آن ذکر کرد. اما اگر خرابی برنامه باعث خرابی شود سیستم عامل(که احتمال آن متناسب با درجه یکپارچگی است) - آیا چنین مزیتی است؟

آیا صد خرگوش برابر با یک ببر است؟

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

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

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

در یک کلام - نتایج آزمون را مطابق با نیاز خود تجدید نظر کنید.

مشخصات تست سرور

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

به نظر ما یکی از الزامات اساسی سرورها قابلیت اطمینان است. البته عملکرد نیز مهم است، زیرا بر زمان پاسخگویی سیستم تأثیر می گذارد - مهمترین ویژگی از نظر کاربر، اما در دسترس بودن سرویس دقیقاً با قابلیت اطمینان تعیین می شود. به موقع بودن ارائه آن، ارتباط و یکپارچگی اطلاعات نیز به قابلیت اطمینان بستگی دارد.

علاوه بر این، باید در نظر داشت که سرورهای تخصصی، یعنی ارائه تنها یک سرویس، همچنان استثنا هستند تا قاعده. به طور معمول، یکی از این کامپیوترها تعدادی از عملکردها را ترکیب می کند - به عنوان مثال، یک سرور برنامه همچنین می تواند به عنوان یک سرور فایل، سرور چاپ، کنترل کننده خدمات خدمت کند. کپی رزرو کنیدو غیره برای سرورهای ارتباطی معمول است که با چندین پروتکل کار کنند سطح کاربردی، که هر کدام توسط "دیمون" خود سرو می شود.

و در نهایت ویژگی مشخصهعملکرد سرورها وجود بارهای اوج است. دلایل ظاهر آنها می تواند بسیار متفاوت باشد - از شروع روز کاری در یک سازمان بزرگ (مخصوصاً اگر همه کاربران به موقع سر کار بیایند) تا بازیابی یک اتصال "قطع شده" در یک ارائه دهنده خدمات اینترنت ، هنگام انباشت نامه و گروه های خبری روی سرورهای ارتباطی قرار می گیرند.

این عوامل، یعنی نیاز به افزایش قابلیت اطمینان تحت شرایط چندین سرویس و بارهای اوج، باید در تعیین ایدئولوژی تست سرور کلیدی باشند.

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

شرایط آزمون

بیایید با یک نظریه کوچک شروع کنیم. گلنفورد مایرز در اثر خود "قابلیت اطمینان نرم افزار" چندین "آزمایش بدیهیات" ارائه می دهد. بیایید سعی کنیم، با پیروی از آنها، در نظر بگیریم که چه چیزی و چگونه آزمایش کنیم.

هر از گاهی گزارش‌های تقریباً ورزشی در مطبوعات رایانه ظاهر می‌شود: محصول شرکت N در تست M رکوردی را نشان داد. آزمایش‌های انجام‌شده توسط تولیدکنندگان چقدر آموزنده است؟

نمی توان برنامه خود را آزمایش کرد

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

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

نویسنده هنگام تلاش برای راه اندازی وب سرور سازمانی Netscape برای Solaris (SPARC) با این پدیده روبرو شد. عملکرد سرور از طریق پروتکل http تقریباً 6 برابر (!) افزایش یافت (طبق آزمایش با MS InetLoad)، اما در یک آزمایش جامع، این افزایش سه برابر شد، در حالی که عملکرد سرور POP3 دو برابر شد، سرور News بدون تغییر باقی ماند و SMTP دو برابر بدتر از قبل از تغییر عمل کرد.

علاوه بر این، تولید کنندگان با دانستن ویژگی های یک مجموعه آزمایشی خاص، می توانند پارامترهای سیستم را برای آن بهینه کنند. نمونه ای از این صفحه وب Netscape است که راهنمایی در مورد نحوه راه اندازی Netscape Enterprise Server برای آزمایش با SPECweb96 ارائه می دهد.

آزمایش برای شناسایی خطاها انجام می شود

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

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

دو نکته در اینجا مرتبط است:

1. مدل رفتار کاربر.

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

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

2. سرویس با پردازش درخواست ها کنار آمده است: گزینه های ممکن.

از نظر شدت، چنین شکست هایی را می توان به 4 گروه تقسیم کرد:

• کاهش عملکرد - سرویس زمان لازم برای پردازش ندارد، اما به درستی پاسخ می دهد (کد خطای مناسب - "اتصالات زیاد" و غیره را برمی گرداند).
• خاتمه غیرعادی سرویس، که پیامدهای منفی برای سیستم ندارد: برنامه مربوطه کار خود را کامل کرده است، از حافظه تخلیه شده است، منابع سیستممنتشر شد؛
• خرابی یک سرویس که بر عملکرد سیستم تأثیر منفی می گذارد. این برنامه یا در لیست فرآیندها بدون انتشار منابع "آویزان" می شود، یا منابع اضافی را در فرآیند تکمیل می گیرد.
• فروپاشی سیستم بهترین موردبه دنبال آن راه اندازی مجدد، در بدترین حالت - با قطع کردن.

تست هایی را برای ورودی های صحیح و نادرست آماده کنید

این اصل اصل موضوع قبلی را از نظر جریان اطلاعات ورودی به تفصیل شرح می دهد.

واکنش سیستم به ارسال نامه ای با حجم چند ده مگابایت چگونه خواهد بود؟ آیا در صف گیر می کند و در نتیجه سیستم ایمیل شما را به طور نامحدود مسدود می کند (مخصوصاً اگر ارتباط با میزبان گیرنده مرتباً قطع شود) یا از بین می رود و به کاربر اطلاع داده می شود که چنین اقداماتی مجاز نیست؟

توصیه هایی که از همان کتاب توسط جی. مایرز گرفته شده است: "سعی کنید سیستم را با کاربر عصبانی نکنید، زیرا این می تواند منجر به موقعیت های غیرمنتظره در ورودی شود - قانون شماره 5 برای به حداقل رساندن خطاهای کاربر در سیستم های تعاملی. بدبین بودن باعث می شود. به این معنا نیست که آدم انسان‌دوستی باشی!»

و در مورد سرور اخبار - آیا در آنجا نصب شده است حداکثر اندازهمقالات؟

آیا کسی که مصمم است نیمی از سایت FTP شما را دانلود کند، می تواند سه دوجین جلسه ftp موازی را باز کند، و اگر چنین است، چگونه این روی کانال شما و کار دیگرانی که می خواهند از FTP بازدید کنند تأثیر می گذارد؟

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

از آزمایشات غیر قابل تکرار خودداری کنید

در مورد تست سرورها و نرم افزارهای سرور، این اصل به ویژه مرتبط است. ابتدا، برای آزمایش آنها، باید ژنراتورهای بار جدا شده با سخت افزار (Client-Side Load Generators، CSLG) داشته باشید - معمولاً اینها گروهی از ایستگاه های کاری هستند که بخش مشتری آزمایش را انجام می دهند و جریانی از درخواست ها را به سرور ارائه می دهند. ثانیاً، وضعیت شبکه اتصال سرور و CSLG می تواند بر نتایج تأثیر بگذارد. علاوه بر این، در بسیاری از موارد، عملکرد به سابقه تماس با سرور بستگی دارد. اکثر برنامه های سرور از کش استفاده می کنند. سرعت دسترسی به حافظه کش بسیار بیشتر از سرعت دسترسی به زیر سیستم دیسک است. حافظه پنهان برنامه ممکن است در نتیجه اجرای اولیه یا اشکال زدایی برنامه های آزمایشی پر شود - و نتایج ممکن است بر این اساس تغییر کند. علاوه بر این، آزمایش متقابل برنامه در طول آزمایش پیچیده امکان پذیر است - برای مثال، تعداد درخواست های پیچیده پردازش شده در واحد زمان به سرورهای POP3 یا IMAP به اندازه قرقره نامه بستگی دارد که می تواند با آزمایش SMTP قبلی افزایش یابد. در نهایت، تنظیمات سیستم عامل بر عملکرد تأثیر می گذارد.

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

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

• شما قصد دارید شبکه خود را گسترش دهید، که باعث افزایش بار سرورهای میزبانی شده در آن می شود.
• شما قصد دارید نرم افزار را به روز کنید (یا تغییر دهید).
• شما تصمیم می گیرید سرور (یا سرورهای) خود را به سرورهای سازنده تر تغییر دهید.
• در نهایت، شاید شما فقط تصمیم گرفتید "محدودیت های رشد" سیستم خود را بیابید.

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