ماتریس قابلیت ردیابی و آزمایش رگرسیون

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

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

بیایید بیشتر در مقاله درباره جزئیات بحث کنیم.

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

در اینجا سوالی پیش می آید که چگونه تیم QA تضمین می کند که تمام سناریوها/موارد ممکن در برنامه آزمون پوشش داده می شوند؟چگونه اطمینان حاصل کنیم که تمام شرایط مورد نیاز در چرخه آزمایش پوشش داده شده است؟یک راه حل ساده و آسان برای نقشه برداری از نیاز با سناریوهای آزمون مرتبط و موارد آزمایش مربوطه ، این نقشه را می توان "ماتریس ردیابی نیاز (RTM)" نامید.

فهرست مطالب

• 1 ماتریس ردیابی نیاز (RTM) چیست؟
• 2 ایجاد یک ماتریس قابلیت ردیابی برای الزامات
  • 2. 1 الزامات تجاری:
  • 2. 2 نیاز عملکردی:
  • 3. 1 قابلیت ردیابی رو به جلو
  • 3. 2 قابلیت ردیابی به عقب
  • 3. 3 قابلیت ردیابی دو جهته

  ماتریس ردیابی نیاز (RTM) چیست؟

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

  ایجاد یک ماتریس قابلیت ردیابی برای الزامات

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

  الزامات تجاری:

  در زیر برخی از نمونه های تجاری نمونه ، که تیم QA از مشتری دریافت کرده است.

  نیاز کسب و کار شماره 90: فرآیند ورود به یک برنامه نامه پستی

  نیاز تجارت شماره 91: ارسال نامه

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

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

  نیاز عملکردی #90. 1: مستقیماً با اعتبار موجود وارد شوید

  نیاز عملکردی #90. 1: ایجاد کاربر جدید و ورود به سیستم با اعتبار جدید

  نیاز عملکردی #91. 1: ایجاد یک ایمیل جدید و ارسال آن.

  نیاز عملکردی #91. 2: ارسال ایمیل از پیش نویس موارد

  نیاز عملکردی #91. 3: پاسخ به ایمیل صندوق ورودی

  نمونه RTM در زیر آورده شده است.

  

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

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

  انواع RTM

  قابلیت ردیابی رو به جلو

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

  قابلیت ردیابی عقب مانده

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

  قابلیت ردیابی دو جهته

  این ترکیبی از ماتریس ردیابی به جلو و عقب است.

  

  مزایای RTM

  1. پوشش تست 100 ٪ را تأیید می کند.

  2. هرگونه نیاز مفقود شده و ناسازگاری اسناد را برجسته می کند.

  3. وضعیت کامل "موارد ثبت شده" و "اجرای پرونده آزمایش" را ارائه می دهد.

  4- در صورت بروز هرگونه تغییر در الزام ، به تجزیه و تحلیل و تخمین آزمایش مجدد کمک می کند.

  آزمایش رگرسیون چیست؟

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

  RTM به یک تستر کمک می کند تا در مورد مناطق با تأثیر بالا که ممکن است به دلیل تغییر کد/افزودنیهای جدید در هنگام برنامه ریزی برای آزمایش رگرسیون ، تحت تأثیر قرار گیرد ، تصمیم بگیرد.

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

  چه موقع باید آزمایش رگرسیون را انجام دهیم و چگونه با RTM ارتباط دارد؟

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

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

  انواع آزمایش رگرسیون

  الف) آزمایش رگرسیون واحد

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

  ب) آزمایش رگرسیون انتخابی

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

  

  ج) آزمایش رگرسیون کامل

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

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

  ردیابی تغییرات بسیار ساده تر است اگر در زمان آزمایش رگرسیون یک ماتریس قابلیت ردیابی خوب داشته باشیم زیرا این امر همچنین باعث بهبود کیفیت یک فرآیند QA می شود.

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