TestRail - تنظیمات فردی برای پروژه

معرفی

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

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

طرح توجیهی (آنچه اجرا خواهد شد)

1. الزامات عمومی

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

   2. موارد باید تا زمانی که ممکن است مرتبط باقی بمانند

   3. موارد باید تا حد امکان عملکرد برنامه تلفن همراه را به طور کامل پوشش دهند تا جایی که با دو نکته اول مغایرت نداشته باشد.

2. تقسیم به TestCase و TestScenario

3. تولید سریع TestRun در انواع مختلف

   1. دود

   2. قهقرا رفتن

   3. تست ضربه و غیره

4. بهینه سازی پشتیبانی از پرونده

   1. رها کردن اسکرین شات های کدگذاری شده «مرده» و جابجایی به «داده های متحرک»

مورد نیاز

برای ویرایش فیلدها به دسترسی سرپرست نیاز دارید

انتخاب نوع پروژه

سه نوع پروژه برای انتخاب وجود دارد:

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

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

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

همچنین می توانید فیلدهای دیگری را اضافه کنید.

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

منوی تنظیمات را باز کنید:

ما به فیلدهای زیر نیاز خواهیم داشت:

فیلد "خلاصه" (سرصفحه مورد آزمایشی)

این زمینه از قبل وجود دارد، ما فقط استفاده از آن را سیستماتیک می کنیم. موارد را به TestCase و TestScenario تقسیم می کنیم. برای خوانایی بهتر فهرست بزرگی از موارد، بهتر است از قبل در مورد قوانین خلاصه نویسی توافق کنید.

سناریوی تست:

مثال: TestScenario - سناریوی اصلی برای استفاده از یک برنامه تلفن همراه

Test Case:

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

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

برچسب "StartScreen" (صفحه‌ای که TestScenario از آن شروع می‌شود؛ همچنین، بسیاری از موارد تست می‌توانند صفحه‌های مجاور را لمس کنند)

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

یک فیلد جدید ایجاد کنید:

اجزای فیلد جدید را پر کنید:

در این مورد، ما در حال ایجاد یک فیلد انتخابی از لیست مقادیر هستیم. مقادیر این فیلد را وارد کنید:

لطفاً توجه داشته باشید که مقادیر id با یک شروع نمی شوند و متوالی نیستند. چرا این کار انجام می شود؟ نکته این است که اگر موارد تست با شناسه وارد شده ثبت شده داشته باشیم،

و پس از آن باید یک صفحه سوم بین دو صفحه موجود ایجاد کنیم،

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

"Screen" را تگ کنید (نام صفحه ای که روی TestCase تاثیر می گذارد)

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

به عنوان مثال: صفحه اصلی، MapScreen، PayScreen و غیره.

فیلد "MovableData" (پیوند به یک پایگاه داده پراکسی با داده های آزمایشی قابل تغییر)

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

1. پیوندهایی به طرح‌بندی‌های فعلی (این بسیار بهتر از گرفتن اسکرین شات‌های مرده است)

2. مراحل معمولی برای رسیدن به صفحه نمایش با وضعیت آزمایش

3. نمایش داده شد SQL

4. پیوند به داده های خارجی و سایر داده ها

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

ما تمام این داده ها را در یک فایل خارجی بسته بندی می کنیم، که در دسترس همه افراد پروژه خواهد بود. به عنوان مثال، می توانید از Google Sheet یا Excel استفاده کنید و جستجوی درون فایل را تنظیم کنید. چرا این فروشندگان خاص؟ واقعیت این است که ما از این پارادایم شروع می کنیم که هر فردی در تیم باید بتواند بدون نیاز به نصب هیچ ابزاری، یک تست را باز کند و قبول کند.

برای صفحه Google می توانید از پرس و جوهای SQL استفاده کنید. مثال:

=query(DATA!A1:M1146;"
SELECT C,D
WHERE
C contains '"&SEARCH!A2&"'")

برای اکسل می توانید ماکروهای جستجوی فوری راحت را تنظیم کنید. (فیلتر کردن) مثال по ссылке.

در واقع، این ایده جدید نیست و در کتاب آزمایش کننده اول "Testing dot com" توضیح داده شده است. (نویسنده Savin Roman) ما فقط روش های پیشنهادی رومن ساوین را در TestRail ادغام می کنیم. برای انجام این کار، یک فیلد با پیوند به فایل ایجاد شده ایجاد کنید:

مقدار پیش فرض پیوند را پر کنید تا هر مورد آزمایشی جدید قبلاً یک پیوند داشته باشد:

اگر مکان فایل خارجی تغییر کند (ما برای هر فورس ماژور ارائه می دهیم)، می توانید به راحتی یک یا چند فیلد را به طور همزمان در همه موارد آزمایش تغییر دهید:

فیلد "توضیحات" (توضیح یا ایده یک مورد آزمایشی، دستورالعمل های استاندارد)

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

به عنوان مثال: تمام داده های آزمایشی (طرح بندی های فعلی، استفاده از ابزارها و سایر داده ها) از این مورد آزمایشی با پیوندهای {...} نشان داده شده و در فایل MovableData قرار دارند. پیوند به MovableData در قسمت مربوطه در بالا.

"کامپوننت" (جزء برنامه تلفن همراه) را تگ کنید

آنچه ممکن است برای آن مورد نیاز باشد: برای آزمایش ضربه. اگر یک اپلیکیشن موبایل را بتوان به اجزایی تقسیم کرد (که تا حد امکان بر یکدیگر تأثیر می‌گذارند)، تغییرات در یک مؤلفه کافی است (با برخی خطرات) در همان مؤلفه بررسی شود و دلیل کمتری برای انجام آن وجود خواهد داشت. رگرسیون های کلی همه چیز اگر اطلاعاتی وجود داشته باشد که یک مؤلفه می تواند بر دیگری تأثیر بگذارد، ماتریس تست ضربه کامپایل می شود.

اجزای مثال: GooglePay، سفارش، کاربران، نقشه، مجوز و غیره.

برچسب "TAG" (برچسب های دیگر برای فیلتر کردن)

برچسب گذاری یک مورد آزمایشی با برچسب هایی برای فیلتر دلخواه. 

بسیار مفید برای: 

1. کامپایل سریع TestRun برای کارهای معمولی مختلف: دود، رگرسیون و غیره.

2. آیا آزمایشات خودکار خواهند بود یا قبلاً خودکار؟

3. هر برچسب دیگر

مثال: Smoke، Automated، WhiteLabel، ForDelete و غیره.

تنظیم ترتیب نمایش فیلدها در مورد آزمایشی

ما فیلدهای جدید زیادی ایجاد کرده ایم، وقت آن است که آنها را به ترتیبی راحت مرتب کنیم:

ایجاد TestRun

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

سایر نکات مفید

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

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

3. حساب ها را می توان به اشتراک گذاشت. به عنوان مثال: یک مدیر، چند کاربر.

نتیجه

نمونه هایی که در بالا توضیح داده شد در چندین پروژه اجرا شده و اثربخشی خود را نشان داده است. من امیدوارم که آنها به بهبود درک شما از این ابزار کمک کنند و به شما در ایجاد "ذخیره های تست" موثر و راحت کمک کنند. اگر تجربه خود از استفاده از TestRail و نکات مفید را در نظرات توضیح دهید بسیار سپاسگزار خواهم بود.

لینک ها:

وب سایت فروشنده TestRail

کتاب: "Testing.COM" (نویسنده رومن ساوین)

از توجه شما بسیار سپاسگزارم!

منبع: www.habr.com