خانه › نصب و راه اندازی › تست محصول نرم افزاری چگونه می توان عملکرد تابعی را که از توابع دیگری در آن استفاده می کند بررسی کرد؟ تغییر تست های مرتبط

تست محصول نرم افزاری چگونه می توان عملکرد تابعی را که از توابع دیگری در آن استفاده می کند بررسی کرد؟ تغییر تست های مرتبط

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

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

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

و این ابزار نام دارد تست محصول نرم افزاری.

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

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

کی و کی؟

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

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

تست عملکردی
تست غیر عملکردی

تست عملکردی

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

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

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

به طور معمول، تست عملکرد در دو سطح انجام می شود:

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

تست غیر عملکردی

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

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

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

تست نرم افزار جاسازی شده و انطباق در عصر چابک

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

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

ازمایش عملکرد

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

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

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

مستندات برای آزمایش

همانطور که در بالا ذکر شد، آزمایش مطابق با برنامه آزمایش و روش انجام می شود که مطابق با GOST 34.603-92 در حال توسعه است.

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

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

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

در صورت منفی بودن نتیجه آزمایش، نواقص اصلاح شده و مجددا آزمایش می شوند.

آزمایش اکتشافی

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

تست استرس

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

1. تولید اسکریپت های تست

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

2. توسعه یک پیکربندی تست

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

3. انجام آزمون آزمایشی

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

تست اتوماسیون

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

تست قابلیت استفاده

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

تست پیکربندی

تست پیکربندی این اطمینان را ایجاد می کند که برنامه بر روی پلتفرم های مختلف کار می کند، که به معنای حداکثر تعداد کاربران است. برای برنامه های وب، معمولاً آزمایش سازگاری بین مرورگرها انتخاب می شود. برای برنامه های ویندوز - تست بر روی مختلف سیستم های عاملو بیتنس (x86, x64). یکی از اجزای مهم تست پیکربندی، زیرساخت تست است: برای آزمایش، باید به طور مداوم ناوگانی از ماشین های آزمایشی را نگهداری کنید. تعداد آنها از 5 تا چند ده متغیر است.

تست یکپارچه سازی

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

تست استرس

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

فرض کنید یک تابع get-data وجود دارد، که نقشه ای از اطلاعات مربوط به شناسه کاربری ارسال شده را برمی گرداند. اکنون این تابع از 3 تابع source-a، source-b و source-c برای دریافت سه نوع مختلف نقشه استفاده می کند. اکنون همه این نقشه ها را در یک نقشه ترکیب می کنیم و از get-data برمی گردیم.

وقتی دریافت داده را آزمایش می کنم، آیا وجود داده برای کلیدها را بررسی کنم؟ آیا منطقی است که اگر یکی از source-a، source-b، و source-c از کار بیفتد، این تابع در تست های واحد شکست بخورد؟ اگر وظیفه تابع thats پیوستن به داده‌ها است، و این کار را انجام می‌دهد، کافی است، درست است؟

2 پاسخ

فرض کنید یک تابع get-data وجود دارد که نقشه ای از اطلاعات مربوط به شناسه کاربر ارسال شده را برمی گرداند.

عالی. سپس شما باید آن را بررسی کنید. برای شناسه داده شده، آیا داده های صحیح را برمی گردانید؟

اکنون این تابع از 3 تابع source-a، source-b و source-c برای دریافت 3 نوع مختلف نقشه استفاده می کند.

چه جزئیات پیاده سازی را باید در یک تست نادیده بگیرید. تمام چیزی که در حال آزمایش هستید این است که واحد کار شما (این روش) کاری را که قرار است انجام دهد انجام می دهد (یک شناسه بگیرید و داده های XYZ را برای آن شناسه برگردانید). چگونهاین روش واقعاً مهم نیست - هرچه باشد، مزیت کلیدی این تست واحد این است که می‌توانید اجرای روش را مجدداً اصلاح کنید و آزمایش تأیید می‌کند که آن را درست انجام داده‌اید.

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

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

در تست واحد، فقط باید عملکرد یک کلاس را آزمایش کنید، اگر متدهای source-a، source-b و source-c شما کلاس‌های دیگر را فراخوانی می‌کنند، باید آنها را مسخره کنید (آنها باید در کلاس‌هایشان واحد تست شوند).

در تست یکپارچه سازی، شما رفتار چندین کلاس را که بین آنها تعامل دارند آزمایش می کنید، به این معنی که تابع دریافت داده شما باید بررسی کند که داده های بازیابی شده صحیح هستند (source-a، source-b، و source-c صحیح هستند. ، و داده ها به درستی به هم متصل می شوند).

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

و این ابزار نام دارد تست محصول نرم افزاری.

به عقیده خردمندان، تست یکی از راه‌های تثبیت شده برای اطمینان از کیفیت توسعه نرم‌افزار است و در مجموعه ابزارهای مؤثر یک سیستم تضمین کیفیت نرم‌افزار مدرن گنجانده شده است.

کی و کی؟

تست عملکردی
تست غیر عملکردی

تست عملکردی

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

به طور معمول، تست عملکرد در دو سطح انجام می شود:

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

تست غیر عملکردی

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

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

تست نرم افزار جاسازی شده و انطباق در عصر چابک

ازمایش عملکرد

مستندات برای آزمایش

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

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

در صورت منفی بودن نتیجه آزمایش، نواقص اصلاح شده و مجددا آزمایش می شوند.

آزمایش اکتشافی

تست استرس

1. تولید اسکریپت های تست

2. توسعه یک پیکربندی تست

3. انجام آزمون آزمایشی

تست اتوماسیون

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

تست قابلیت استفاده

تست پیکربندی

تست پیکربندی این اطمینان را ایجاد می کند که برنامه بر روی پلتفرم های مختلف کار می کند، که به معنای حداکثر تعداد کاربران است. برای برنامه های وب، معمولاً آزمایش سازگاری بین مرورگرها انتخاب می شود. برای برنامه های ویندوز - تست بر روی سیستم عامل های مختلف و بیت (x86، x64). یکی از اجزای مهم تست پیکربندی، زیرساخت تست است: برای آزمایش، باید به طور مداوم ناوگانی از ماشین های آزمایشی را نگهداری کنید. تعداد آنها از 5 تا چند ده متغیر است.

تست یکپارچه سازی

تست استرس

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

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

تست عملکردی: تلاش های اصلی را به کجا هدایت کنیم؟

برای تست واحد و سیستم؛

برای بررسی کادر "سفید" یا "سیاه"؛

برای تست دستی و اتوماسیون؛

برای آزمایش عملکرد جدید یا ;

در تست های "منفی" یا "مثبت".

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

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

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

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

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

تجزیه و تحلیل ارزش مرزی؛

پارتیشن معادل؛

حدس خطا؛

تجزیه و تحلیل روابط بین علت و معلول.

می توانید هر کدام را جداگانه در نظر بگیرید.

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

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

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

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

بیایید فرآیند آزمایش را بر اساس توصیه‌های استاندارد ISO/IEC 12207 در نظر بگیریم و انواع خطاهایی را که در هر فرآیند چرخه عمر یافت می‌شوند فهرست کنیم.

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

خطاهای معمول این فرآیند عبارتند از:

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

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

با تعریف رابط کاربری با محیط؛
با توصیف عملکردها (ناکافی بودن اهداف و اهداف اجزایی که هنگام بررسی مجموعه اجزاء شناسایی می شوند)؛
با تعریف فرآیند پردازش اطلاعات و تعامل بین فرآیندها (نتیجه تعریف نادرست روابط بین اجزا و فرآیندها)؛
با تخصیص نادرست داده ها و ساختار آنها در توصیف اجزای فردی و PS به عنوان یک کل؛
با توصیف نادرست الگوریتم های ماژول؛
با تعریف شرایط وقوع خطاهای احتمالی در برنامه؛
بر خلاف استانداردها و فناوری های اتخاذ شده برای پروژه.

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

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

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

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

تمام خطاهایی که در برنامه ها رخ می دهد معمولاً به کلاس های زیر تقسیم می شوند [7.12]:

خطاهای منطقی و عملکردی؛
خطاهای محاسبه و زمان اجرا؛
خطاهای I/O و دستکاری داده ها؛
خطاهای رابط؛
خطاهای حجم داده و غیره

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

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

خطاهای ورودی/خروجیو دستکاری داده ها نتیجه آماده سازی بی کیفیت داده ها برای اجرای برنامه، خرابی در هنگام ورود آنها به پایگاه داده یا هنگام بازیابی از آن است.

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

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

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

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

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

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

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

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

ما طبقه بندی زیر را از انواع خرابی ارائه می دهیم:

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

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

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

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

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

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

پرطرفدار در دسته بندی: