[ad_1]
این آزمون بسته به اینکه چه کسی آن را انجام می دهد و در چه مرحله ای انجام می شود می تواند چیزهای مختلفی داشته باشد. برنامه نویسان سرپرستان کاربران و مشاوران هنگام آزمایش چیز دیگری در ذهن دارند. آزمایشگر اختصاصی غالباً در تفسیرهای رقابتی احساس گمشده می کند. یک تستر برای موثر بودن به شرح وظایف خاصی نیاز دارد. این پنج هدف تست نرم افزار مبنای بسیار خوبی است.
تایید
هدف اصلی بیشترین سو تفاهم در مورد تست است. اگر فکر می کردید برای یافتن نقص اشتباه می کنید. همه کسانی که از این نرم افزار استفاده می کنند نقص ها را پیدا می کنند. آزمون اندازه گیری کنترل کیفیت است که برای تأیید عملکرد یک محصول مطابق هدف مورد استفاده قرار می گیرد. این آزمون گزارش وضعیت واقعی محصول را در مقایسه با الزامات (مکتوب و ضمنی) ارائه می دهد. در ساده ترین حالت این یک لیست عبور / عدم موفقیت از ویژگی های محصول است. جزئیات شامل ارقام اطمینان و پیش بینی میزان نقص در کل برنامه است.
این مهم است زیرا آزمایش کننده می تواند اشکالات را برای همیشه بگیرد اما نمی تواند تعیین کند که آیا یک محصول برای انتشار مناسب است یا خیر. اگر راهی برای ارزیابی آنها وجود نداشته باشد دریافت بسیاری از گزارش های نقص کاربرد چندانی ندارد. سیاست شرکت باید در مورد کیفیت محصول تعیین شود. وی باید شرایط لازم برای ویرایش برنامه را بیان کند. وظیفه آزمایشگاه این است که تعیین کند آیا نرم افزار از این شرایط برخوردار است یا خیر.
اولویت پوشش
همه چیز قابل آزمایش نیست. حتی یک زیر مجموعه مهم از همه چیز قابل آزمایش نیست. بنابراین آزمون باید معقولانه و دقیقاً اولویت بندی کند. این قرار نیست که یک موضوع ساده باشد. به طور کلی شما می خواهید هر ویژگی را حداقل با یک مورد ورودی معتبر بپوشانید. این حداقل یک ابزار اساسی برای خط پایه نرم افزار را تضمین می کند.
خارج از خط پایه باید جایگزینی ورودی بیشتری ورودی نادرست و الزامات غیر عملکردی بیشتری را آزمایش کنید. در هر حالت باید به استفاده واقعی از نرم افزار توجه شود. سناریوهای استفاده فعلی و تکراری باید پوشش بیشتری نسبت به سناریوهای نادر و تخصصی داشته باشند. به طور کلی این طیف گسترده ای از پوشش را هدف قرار می دهد عمیقاً در مناطق پرمصرف و دقیقاً طبق زمان مجاز.
ردیابی شده
دقیقاً اینکه چه چیزی آزمایش شده و چطور آزمایش شده است به عنوان بخشی از روند توسعه در حال انجام ضروری است. در بسیاری از تنظیمات این اثبات فعالیت به عنوان بخشی از تلاش برای صدور گواهینامه یا به سادگی به عنوان روشی برای از بین بردن تلاش آزمایشی مورد نیاز است. این به معنای مستندات اضافی نیست بلکه به معنای روشن نگه داشتن برنامه های آزمایشی شما برای خواندن و درک مجدد است.
شما باید با روش های احراز هویت موافقت کنید. هر عضو تیم نباید خودش را داشته باشد. همه ویژگی ها نباید یکسان باشند: چندین روش مختلف به احتمال زیاد مورد استفاده قرار می گیرد. متأسفانه اصول کلی مورد توافق در این زمینه وجود ندارد بنابراین شما نوعی خودتان هستید.
بی طرفانه
آزمون ها باید الزامات نوشته شده را با محدودیت های فنی واقع بینانه و انتظارات کاربر متعادل کنند. مهم نیست که از چه فرایند توسعه ای استفاده شود نیازهای نانوشته یا ضمنی زیادی وجود خواهد داشت. وظیفه آزمایشگاه است که در هنگام آزمایش نرم افزار تمام این نیازها را در نظر بگیرد. آزمایش کننده همچنین باید توجه داشته باشد که کاربر نرم افزار نیست بلکه بخشی از تیم توسعه دهنده است. نظرات شخصی آنها فقط یکی از ملاحظات بسیاری است. تعصب در تستر همیشه باعث ایجاد سوگیری در پوشش می شود.
بدیهی است که دیدگاه کاربر نهایی برای موفقیت نرم افزار حیاتی است اما همه مهم نیستند. اگر نیازهای مدیران برآورده نشود ممکن است نرم افزار قابل استفاده نباشد. اگر نیازهای تیم پشتیبانی برآورده نشود ممکن است پشتیبانی نشود. اگر نیازهای بازاریابی برآورده نشود ممکن است فروخته نشود. همچنین نمی توان برنامه نویسان را نادیده گرفت. اولویت باید با توجه به محدودیت های زمانی و محدودیت های فنی به هر نقص داده شود.
مصمم
تشخیص مسائل نباید تصادفی باشد. استانداردهای پوشش باید تمام نقایص مربوط به ماهیت و اولویت تعریف شده را فاش کند. بعلاوه نقصهای ظهور بعدی با توجه به اینکه کدام شاخه از پوشش رخ داده است و بنابراین می توان در آزمایشهای آینده هزینه خاصی در شناسایی چنین نقصهایی ارائه داد.
این هدف باید امتداد طبیعی آزمایش قابل ردیابی با پوشش اولویت باشد. او تکرار می کند که تیم آزمون نباید یک جعبه سیاه آشفته باشد. کنترل کیفیت یک فرایند کاملاً تنظیم شده قابل تکرار و قابل پیش بینی است. داشتن بینش در این فرآیند به مشاغل اجازه می دهد تا هزینه ها را بهتر اندازه بگیرند و توسعه کلی را بهتر راهنمایی کنند.
[ad_2]