تعیین کنید چه چیزی را تست کنید، موارد آزمایشی خود را تعریف کنید و اولویت بندی کنید.
در پست قبلی ، با استراتژی‌های تست، تعداد تست‌های مورد نیاز برای آزمایش یک برنامه کاربردی، و نحوه یافتن بهترین مناسب برای به دست آوردن بیشترین اعتماد به نتایج و با در نظر گرفتن منابع خود آشنا شدید. با این حال، این فقط به ما ایده می دهد که چقدر باید آزمایش کنیم. شما هنوز باید دقیقاً تعیین کنید که چه چیزی را آزمایش کنید. سه معیار زیر می‌تواند برای درک آنچه در یک آزمون انتظار می‌رود و برای دیدن اینکه چه نوع آزمون و سطح جزئیات ممکن است مناسب‌تر باشد، مفید باشد:
- مواظب راه خوشت باش . این عمومی ترین یا اصلی ترین داستان کاربر برنامه شما است که کاربر شما خیلی سریع متوجه خطا می شود.
- در سطح جزئیات با دقت تصمیم بگیرید . اگر مورد استفاده شما آسیب پذیر است یا جایی که یک خطا باعث آسیب زیاد می شود، جزئیات بیشتری را وارد کنید.
- در صورت امکان ، تست‌های سطح پایین‌تر، مانند آزمون‌های واحد و یکپارچه‌سازی، را نسبت به آزمون‌های پایان به پایان سطح بالاتر اولویت دهید .
بقیه این مقاله به بررسی این معیارها و نحوه اعمال آنها با تعریف موارد آزمایشی می پردازد.
کیس آزمایشی چیست؟
در توسعه نرم‌افزار، یک مورد آزمایشی مجموعه‌ای از اقدامات یا شرایطی است که برای تأیید اثربخشی یک برنامه یا برنامه نرم‌افزاری طراحی می‌شوند. هدف آزمایشی این است که اطمینان حاصل شود که نرم افزار طبق برنامه عمل می کند و همه ویژگی ها و عملکردهای آن به درستی انجام می شود. آزمایش کنندگان یا توسعه دهندگان نرم افزار معمولاً این موارد تست را ایجاد می کنند تا تضمین کنند که نرم افزار با الزامات و مشخصات مشخص شده مطابقت دارد.
هنگامی که یک مورد آزمایشی اجرا می‌شود، نرم‌افزار یک سری بررسی‌ها را انجام می‌دهد تا مطمئن شود نتایج مورد نظر را تولید می‌کند. در حین انجام این کار، یک تست وظایف زیر را انجام می دهد:
- تایید . فرآیند بررسی کامل نرم افزار برای اطمینان از عملکرد بدون خطا. تعیین اینکه آیا محصول ایجاد شده تمام الزامات غیر کاربردی لازم را برآورده می کند و با موفقیت به هدف مورد نظر خود می رسد بسیار مهم است. سوالی که پاسخ می دهد این است: "آیا ما محصول را درست می سازیم؟"
- اعتبار سنجی . فرآیند حصول اطمینان از اینکه محصول نرم افزاری استانداردهای لازم یا الزامات سطح بالا را برآورده می کند. این شامل بررسی اینکه آیا محصول واقعی با محصول مورد انتظار مطابقت دارد یا خیر. در اصل، ما به این سوال پاسخ می دهیم: "آیا ما محصول مناسبی را برای نیازهای کاربر می سازیم؟"
فرض کنید برنامه نتواند نتیجه مورد انتظار را ارائه دهد. در آن صورت، مورد آزمایشی پیام رسان خواهد بود - بنابراین یک نتیجه ناموفق را گزارش می‌کند و توسعه‌دهنده یا آزمایش‌کننده باید مشکل را بررسی کرده و راه‌حلی بیابد. بررسی ها و اقدامات را به عنوان مسیرهایی که رایانه دنبال می کند، صرف نظر از نوع آزمایش در نظر بگیرید. گروه هایی از داده های ورودی یا شرایطی که برای بررسی استفاده می شوند، «کلاس های هم ارزی» نامیده می شوند. آنها باید رفتار یا نتایج مشابهی را از سیستم تحت آزمایش دریافت کنند. مسیرهای خاص اجرا شده در داخل یک آزمون ممکن است متفاوت باشد، اما باید با فعالیت ها و اظهارات انجام شده در آزمون شما مطابقت داشته باشد.
مسیرهای تست: انواع معمولی موارد آزمایشی
در توسعه نرم افزار، یک تست یک سناریوی اجرای کد است که از آن رفتار خاصی انتظار می رود و آزمایش می شود. به طور معمول، سه سناریو برای تشکیل موارد آزمایشی وجود دارد.
اولین مورد شناخته شده ترین است که احتمالاً قبلاً از آن استفاده می کنید. این مسیر شاد است که به عنوان "سناریوی روز شاد" یا "مسیر طلایی" نیز شناخته می شود. رایج‌ترین مورد استفاده از ویژگی، برنامه یا تغییر شما را تعریف می‌کند – راهی که باید برای مشتری انجام شود.
دومین مسیر مهم آزمایشی که باید در موارد آزمایشی شما پوشش داده شود، اغلب به دلیل ناراحتی - همانطور که از نام آن پیداست، کنار گذاشته می شود. این "مسیر ترسناک" یا، به عبارت دیگر، تست منفی است . این مسیر سناریوهایی را هدف قرار می‌دهد که باعث می‌شوند کد عملکرد نامناسبی داشته باشد یا وارد حالت خطا شود. آزمایش این سناریوها به ویژه در صورتی که موارد استفاده بسیار آسیب پذیری دارید که ریسک بالایی را بر ذینفعان یا کاربران تحمیل می کند، مهم است.
مسیرهای دیگری وجود دارد که ممکن است بخواهید در مورد آنها بدانید و در نظر داشته باشید که از آنها استفاده کنید، اما معمولاً آنها کمتر مورد استفاده قرار می گیرند. جدول زیر به طور خلاصه آنها را نشان می دهد:
| مسیر تست | توضیح |
|---|---|
| مسیر عصبانیت | این منجر به یک خطا، اما مورد انتظار می شود. به عنوان مثال، اگر می خواهید مطمئن شوید که مدیریت خطا به درستی کار می کند. |
| مسیر متخلف | این مسیر به تمام سناریوهای مرتبط با امنیت که برنامه شما نیاز به انجام آنها دارد، رسیدگی می کند. |
| مسیر متروک | مسیری که سناریو را در برنامه شما آزمایش می کند، داده های کافی برای عملکرد، به عنوان مثال، آزمایش مقادیر تهی را دریافت نمی کند. |
| مسیر فراموشی | آزمایش رفتار برنامه شما با منابع ناکافی، به عنوان مثال، راه اندازی از دست دادن داده. |
| مسیر بلاتکلیف | آزمایش با کاربری که سعی می‌کند اقداماتی انجام دهد یا داستان‌های کاربر را در برنامه شما دنبال کند، اما آن گردش‌های کاری را کامل نکرده است. به عنوان مثال، زمانی که کاربر جریان کاری خود را قطع می کند، ممکن است چنین باشد. |
| راه حریص | تلاش برای آزمایش با استفاده از مقادیر زیادی ورودی یا داده. |
| مسیر پر استرس | تلاش برای قرار دادن بار روی برنامه خود به هر وسیله ای که لازم است تا زمانی که دیگر کار نکند (شبیه به آزمایش بار). |
روش های مختلفی برای دسته بندی این مسیرها وجود دارد. دو رویکرد رایج عبارتند از:
- پارتیشن بندی معادل سازی . یک روش تست که موارد تست را به گروه ها یا پارتیشن ها دسته بندی می کند و در نتیجه به ایجاد کلاس های هم ارزی کمک می کند. این مبتنی بر این ایده است که اگر یک مورد آزمایشی در یک پارتیشن نقصی را کشف کند، سایر موارد آزمایشی در همان پارتیشن احتمالاً نقص‌های مشابهی را نشان خواهند داد. از آنجایی که همه ورودی‌های یک کلاس هم ارزی خاص باید رفتار یکسانی از خود نشان دهند، می‌توانید تعداد موارد تست را کاهش دهید. درباره پارتیشن بندی معادل سازی بیشتر بیاموزید .
- تجزیه و تحلیل حد . یک روش آزمایشی، همچنین به عنوان تجزیه و تحلیل ارزش مرزی شناخته می شود، که محدودیت ها یا حداکثر مقادیر ورودی را برای یافتن هر گونه مشکل یا خطای بالقوه ای که ممکن است در محدوده قابلیت ها یا محدودیت های سیستم ایجاد شود، بررسی می کند.
بهترین روش: نوشتن موارد تست
یک مورد آزمایشی کلاسیک که توسط یک آزمایش‌کننده نوشته شده است حاوی داده‌های خاصی است تا به شما در درک محتوای آزمونی که می‌خواهید انجام دهید و البته اجرای آزمون کمک کند. یک آزمایش کننده معمولی تلاش های آزمایشی خود را در یک جدول مستند می کند. دو الگو وجود دارد که می‌توانیم در این مرحله از آنها استفاده کنیم و به ما کمک می‌کنند تا موارد آزمایشی و بعداً خود آزمایش‌هایمان را نیز ساختار دهیم:
- ترتیب، عمل، ادعای الگو. الگوی آزمایشی «ترتیب، عمل، ادعا» (همچنین به عنوان «AAA» یا «سه‌تایی A» شناخته می‌شود) روشی برای سازمان‌دهی آزمون‌ها در سه مرحله مجزا است: ترتیب دادن آزمون، سپس انجام آزمون، و آخرین اما نه کم‌اهمیت، نتیجه گیری.
- با توجه به زمان، سپس الگو. این الگو شبیه الگوی AAA است اما ریشه در توسعه رفتار محور دارد.
به محض اینکه ساختار خود آزمون را پوشش دهیم، مقالات بعدی به جزئیات بیشتری در مورد این الگوها خواهند پرداخت. اگر می‌خواهید در این مرحله به این الگوها عمیق‌تر بروید، این دو مقاله را بررسی کنید: Arrange-Act-Assert: الگویی برای نوشتن تست‌های خوب و Given-When-Then .
با توجه به تمام آموخته های این مقاله، جدول زیر یک مثال کلاسیک را خلاصه می کند:
| اطلاعات | توضیح |
|---|---|
| پیش نیازها | هر کاری که باید قبل از نوشتن آزمون انجام شود. |
| شی مورد آزمایش | چه چیزی باید تایید شود؟ |
| داده های ورودی | متغیرها و مقادیر آنها |
| مراحلی که باید اجرا شوند | تمام کارهایی که برای زنده کردن آزمون خود انجام خواهید داد: همه اعمال یا تعاملاتی که در آزمون های خود انجام می دهید. |
| نتایج مورد انتظار | چه اتفاقی باید بیفتد و کدام انتظارات باید برآورده شود. |
| نتیجه واقعی | در واقع چه اتفاقی می افتد. |
در تست خودکار، نیازی نیست همه این موارد تست را به روشی که یک آزمایشگر نیاز دارد مستند کنید، حتی اگر انجام این کار بدون شک مفید است. اگر دقت کنید می توانید تمام این اطلاعات را در آزمون خود پیدا کنید. بنابراین بیایید این مورد آزمون کلاسیک را به یک تست خودکار ترجمه کنیم.
| اطلاعات | ترجمه به اتوماسیون تست |
|---|---|
| پیش نیازها | همه چیزهایی که نیاز دارید، ترتیب دادن آزمون، و فکر کردن در مورد آنچه برای انجام سناریوی آزمون شما داده شده است. |
| شی مورد آزمایش | این "شیء" می تواند چیزهای مختلفی باشد: یک برنامه کاربردی، جریان، واحد یا جزء تحت آزمایش. |
| داده های ورودی | مقادیر پارامتر |
| مراحلی که باید اجرا شوند | تمام اعمال و دستورات اجرا شده در تست شما، چیزهایی که بر اساس آنها عمل می کنید، و یافتن اینکه چه اتفاقی در هنگام انجام کارهای خاصی می افتد. |
| نتایج مورد انتظار | ادعایی که برای تأیید درخواست خود استفاده می کنید، مواردی که در برنامه خود بر آنها تأکید می کنید. |
| نتیجه واقعی | نتیجه تست خودکار شما. |