گردش کار Specification-first

مدت زمان مطالعه: : 9 دقیقه

گردش کار Specification-first یک رویکرد اتوماسیون آزمایشی است که در آن تست‌کیس‌ها خود را در TestRail تعریف می کنید قبل از نوشتن اسکریپت های تست خودکار مربوطه برنامه ریزی آنچه باید آزمایش شود را از اجرای نحوه آزمایش آن جدا می کند.

این رویکرد به ویژه زمانی مفید است که:

تیم شما مستندات دقیقی را برای فرآیندهای QA نگهداری می کند
شما قبلاً یک مخزن از تست‌کیس‌ها در TestRail دارید
شما باید در نقش های فنی و غیر فنی همکاری کنید
شما می خواهید قابلیت ردیابی بین الزامات، تست های دستی و اسکریپت های خودکار را داشته باشید

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

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

🎓 سطح مهارت های تست خود را با آکادمی تست ریل!
دوره‌های رایگان و خودسرانه را کاوش کنید تا بیشترین بهره را از TestRail ببرید.

👉 همین الان شروع به یادگیری کنید

اگر در حال نوشتن تست‌کیس‌ها مستقیماً در پایگاه کد خود هستید و آن تست‌کیس‌ها را در TestRail مستند ندارید، ممکن است بخواهید درباره رویکرد اتوماسیون کد اول، که برای تکرار سریع و تیم های کوچکتر مناسب تر است.

در بسیاری از چارچوب‌های اتوماسیون، یک آزمایش خودکار واحد ممکن است چندین الزام را در یک گردش کار تأیید کند.

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

با استفاده از این روش، شما:

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

TestRail - CLI Workflow Images (Final) _5 Steps.png

مزایا و معاوضه #

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

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

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

نگاشت یک تست خودکار به چندین مورد TestRail #

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

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

منطق اعتبار سنجی مشترک
مراحل قابل استفاده مجدد
تست های پارامتری

در این شرایط، یک تست خودکار منفرد ممکن است چندین رفتار مرتبط با آن را تأیید کند چند تست‌کیس TestRail.

به عنوان مثال:

تست خودکار	موارد TestRail
`test_login_flow`	C101 – ورود معتبر
	C102 – جلسه ایجاد شد
	C103 – تغییر مسیر داشبورد

هنگامی که نتایج به TestRail وارد می شوند، هر مورد یک نتیجه فردی دریافت می کند، اطمینان از اینکه قابلیت ردیابی و گزارش دقیق باقی می ماند.

این به تیم ها اجازه می دهد:

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

گردش کار گام به گام #

پیش نیازها #

قبل از شروع، مطمئن شوید:

TestRail CLI است نصب شده است
شما یک پروژه TestRail با تست‌کیس‌ها از قبل مستند دارید
شناسه‌های تست TestRail را می‌شناسید (مانند C123، C2645)
شما از یک تست رانر پشتیبانی شده استفاده می کنید (به عنوان مثال، JUnit)

مرحله ۱: تست‌کیس‌ها خود را در کد اتوماسیون خود ترسیم کنید #

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

گزینه ۱: مطابقت با نام #

شناسه پرونده را در نام آزمایشی خود وارد کنید. مثال ها:

C123 login_valid_credentials
test_login [C123]
C123_test_login

مثال JUnit:

<!-- XML (JUnit) format -->
<testcase classname="tests.LoginTests" name="C123_test_login" time="650"/>

استفاده از این با --case-matcher "name" در CLI

گزینه ۲: مطابقت بر اساس ویژگی #

شناسه آزمون را به عنوان یک ویژگی JUnit جاسازی کنید:

<testsuites name="test suites root">
  <testsuite failures="0" errors="0" skipped="1" tests="1" time="0.05" name="tests.LoginTests">
    <properties>
      <property name="setting1" value="True"/>
    </properties>
    <testcase classname="tests.LoginTests" name="C2647_test_case_1" time="159">
      <skipped type="pytest.skip" message="Please skip">
        skipped by user
      </skipped>
    </testcase>
    <testcase classname="tests.LoginTests" name="C2645_test_case_2" time="650">
    </testcase>
    <testcase classname="tests.LoginTests" name="C2648_test_case_3" time="159">
      <failure type="pytest.failure" message="Fail due to...">
        failed due to…
      </failure>
    </testcase>
  </testsuite>
</testsuites>

استفاده از این با --case-matcher "property" در CLI

شناسه تست‌کیس که باید از آن استفاده کنید، همان شناسه ای است که در صفحه تست‌کیس‌ها با نشان داده می شود پیشوند C.

مرحله ۲: نتایج تست را بارگذاری کنید #

برای بارگذاری نتایج از CLI استفاده کنید. در اینجا یک دستور نمونه وجود دارد:

trcli -n \
  -h https://<INSTANCE>.testrail.io \
  --project "<PROJECT_NAME>" \
  --username <EMAIL> \
  --password <API_KEY> \
  parse_junit \
  --case-matcher "name" \
  --title "Automated Test Run" \
  -f results.xml

پرچم ها توضیح دادند:

-n: موارد جدید را به صورت خودکار ایجاد نکنید
--case-matcher: “name” یا “property” را به عنوان روش نگاشت انتخاب کنید
--title: نام برای اجرای تست
-f: مسیر فایل نتیجه JUnit شما

خروجی مورد انتظار:

Parsing JUnit report.
Processed 3 test cases in 1 sections.
Checking project. Done.
Creating test run. Run created: https://INSTANCE-NAME.testrail.io/index.php?/runs/view/123
Adding results: 3/3, Done.
Submitted 3 test results in 5.5 secs.

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

#

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

در بسیاری از گردش‌های کاری QA، اجرای تست از قبل توسط مدیران QA ایجاد می‌شود یا منجر به ردیابی پیشرفت در یک نقطه عطف، سرعت یا انتشار می‌شود. این اجراها اغلب شامل ترکیبی از تست های دستی و خودکار هستند. هنگامی که تست های خودکار بعداً اجرا می شوند، نتایج آنها را می توان در آن بارگذاری کرد موجود اجرای تست با استفاده از TestRail CLI – به جای ایجاد هر بار اجرای جدید.

این زمانی مفید است که:

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

مثال گام به گام #

فرض کنید یک اجرای تست از قبل در TestRail وجود دارد که تحت پروژه شما ایجاد شده است. اجرا شامل موارد زیر است:

C101 – دستی (تست دستی)
C102 – دستی (تست دستی)
C103 – خودکار (به روز رسانی توسط CLI)
C104 – خودکار (به روز رسانی توسط CLI)

مهندس اتوماسیون مجموعه آزمایشی را اجرا می کند و یک گزارش JUnit XML با نتایج برای موارد C103 و C104 تولید می کند. فایل گزارش نام دارد ./results.xml.

دستور CLI برای به روز رسانی که اجرا می شود #

trcli -n \
  -h https://<INSTANCE>.testrail.io \
  --project "<PROJECT_NAME>" \
  --username <EMAIL> \
  --password <API_KEY> \
  parse_junit \
  --case-matcher "property" \
  --title "Regression - Sprint 18" \
  --run-id 52 \
  -f ./results.xml

پارامترهای کلیدی #

--run-id 52: این به TestRail CLI می گوید که به جای ایجاد اجرای جدید، اجرای تست را با ID ۵۲ به روز کند.
--case-matcher "property": تست‌کیس‌ها توسط JUnit را مطابقت می دهد test_id دارایی
-n: اطمینان حاصل می کند که تست‌کیس‌ها جدید برای ورودی های بی همتا به صورت خودکار ایجاد نمی شوند.

دریافت Run ID #

برای پیدا کردن شناسه اجرا:

اجرای تست را در TestRail باز کنید.
به URL مرورگر نگاه کنید: https://yourcompany.testrail.io/index.php?/runs/view/52 – شماره 52 شناسه اجرا است.

بعد چه اتفاقی می افتد؟ #

TestRail CLI نتایج XML را می خواند
مطابقت دارد C103 و C104 با تست‌کیس‌ها در Run ID ۵۲
نتایج آزمون (گذر/شکست/پرش) را برای آن دو تست‌کیس آپلود می کند
نتایج دستی (C101، C102) دست نخورده باقی بماند

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

هر زمان که تست های خودکار را دوباره اجرا کردید، می توانید این مرحله را تکرار کنید. برای به‌روزرسانی نتایج بدون تکرار، فقط به همان Run ID اشاره کنید.

از کجا کمک بگیریم #

به‌روزرسانی شده در 1405-04-15

احساسات شما چیست؟

خوشحال
عادی
ناراحت

دیدگاهتان را بنویسید لغو پاسخ

برای نوشتن دیدگاه باید وارد بشوید.

Testrail

گردش کار Specification-first

مزایا و معاوضه #

نگاشت یک تست خودکار به چندین مورد TestRail #

گردش کار گام به گام #

پیش نیازها #

مرحله ۱: تست‌کیس‌ها خود را در کد اتوماسیون خود ترسیم کنید #

گزینه ۱: مطابقت با نام #

گزینه ۲: مطابقت بر اساس ویژگی #

مرحله ۲: نتایج تست را بارگذاری کنید #

#

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

مثال گام به گام #

دستور CLI برای به روز رسانی که اجرا می شود #

پارامترهای کلیدی #

دریافت Run ID #

بعد چه اتفاقی می افتد؟ #

از کجا کمک بگیریم #

دیدگاهتان را بنویسید لغو پاسخ

تست ریل

مطالب مفید

حساب کاربری ندارید؟

مزایا و معاوضه #

نگاشت یک تست خودکار به چندین مورد TestRail #

گردش کار گام به گام #

پیش نیازها #

مرحله ۱: تست‌کیس‌ها خود را در کد اتوماسیون خود ترسیم کنید #

گزینه ۱: مطابقت با نام #

گزینه ۲: مطابقت بر اساس ویژگی #

مرحله ۲: نتایج تست را بارگذاری کنید #

#

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

مثال گام به گام #

دستور CLI برای به روز رسانی که اجرا می شود #

پارامترهای کلیدی #

دریافت Run ID #

بعد چه اتفاقی می افتد؟ #

از کجا کمک بگیریم #

این مقاله را به اشتراک بگذارید:

دیدگاهتان را بنویسید لغو پاسخ

تست ریل

مطالب مفید

حساب کاربری ندارید؟

ورود