دسته‌ها را مشاهده کنید

گردش کار Specification-first

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

گردش کار Specification-first یک رویکرد test automation است که در آن test caseهای خود را در TestRail تعریف می‌کنید پیش از نوشتن test scriptهای خودکار مرتبط. این رویکرد، برنامه‌ریزی درباره اینکه چه چیزی باید تست شود را از پیاده‌سازی اینکه چگونه تست می‌شود جدا می‌کند.

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

  • تیم شما مستندات دقیقی برای فرآیندهای QA نگهداری می‌کند
  • از قبل مجموعه‌ای از test caseها را در TestRail دارید
  • باید بین نقش‌های فنی و غیرفنی همکاری ایجاد کنید
  • می‌خواهید بین requirements، تست‌های دستی و scriptهای خودکار traceability داشته باشید

برای مثال، یک QA lead ممکن است test caseها را در TestRail و با کمک business analystها یا testerها ایجاد و بررسی کند. سپس automation engineerها آن caseهای تأییدشده را با استفاده از case ID به scriptهای خودکار وصل می‌کنند.

با این کار، کل تیم درک مشترکی از این دارد که چه چیزی تست می‌شود و چرا. TestRail به single source of truth برای فعالیت‌های تست دستی و خودکار تبدیل می‌شود.

 

🎓 مهارت‌های تست خود را با TestRail Academy!
دوره‌های رایگان و self-paced را ببینید تا بیشترین استفاده را از TestRail ببرید.

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

1679917783_TestRail_Academy_Course_Banner_Image.png

 

اگر test caseها را مستقیماً در codebase خود می‌نویسید و آن‌ها را در TestRail مستند نکرده‌اید، بهتر است درباره رویکرد code-first automation بیشتر بخوانید؛ این رویکرد برای iteration سریع و تیم‌های کوچک‌تر مناسب‌تر است.

در بسیاری از automation frameworkها، یک تست خودکار می‌تواند چند requirement را در یک workflow واحد اعتبارسنجی کند.

به همین دلیل، TestRail از mapping پشتیبانی می‌کند: اتصال یک automated test به چند TestRail case ID. با این کار automation تمیز و قابل نگهداری می‌ماند و در عین حال traceability بین automated testها و caseهای TestRail حفظ می‌شود.

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

  1. test caseها را در TestRail طراحی و بررسی می‌کنید
  2. آن caseها را از طریق ID به کد automation خود وصل می‌کنید
  3. از TestRail CLI برای map کردن، match کردن و upload نتایج استفاده می‌کنید

 

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

مزایا و محدودیت‌ها #

رویکرد Specification-first چند مزیت مهم دارد، اما بسته به workflow، اندازه تیم و میزان بلوغ تست‌های شما، ممکن است محدودیت‌هایی هم داشته باشد.

مزایا معایب
mapping پایدار بین تست و کد: حتی اگر codebase شما تغییر کند، لینک‌های test caseها از طریق ID دست‌نخورده باقی می‌مانند. نیاز به کار دستی: باید ID هر test case را در کد خود annotate کنید یا به آن reference بدهید.
جلوگیری از تکرار تست: چون همه test caseها ابتدا در TestRail مستند می‌شوند، از بازسازی چندباره منطق تست یکسان جلوگیری می‌کنید. نیاز به برنامه‌ریزی اولیه: این روش زمانی بهترین نتیجه را می‌دهد که از قبل مستندات دقیق test case داشته باشید یا آماده باشید برای ایجاد آن وقت بگذارید.
شفافیت بیشتر در پوشش تست: مدیران QA می‌توانند ببینند چه چیزهایی automated شده‌اند و چه چیزهایی نه. ریسک ناهماهنگی: اگر test IDها اشتباه تایپ شوند یا حذف شوند، نتایج آپلود نمی‌شوند.
کمک به همکاری تیمی: تسترهای دستی و مهندسان اتوماسیون بر اساس یک منبع مرجع مشترک کار می‌کنند. اصلاح و تکرار سریع سخت‌تر می‌شود: در تیم‌هایی که سریع کار می‌کنند، اینکه قبل از نوشتن تست به یک TestRail case نیاز باشد، ممکن است روند کار را کندتر کند.
💡 پیشنهاد: برای test caseهای اصلی، با ارزش بالا یا regression از رویکرد specification-first استفاده کنید. برای تست‌های exploratory یا prototype، رویکرد code-first ممکن است سریع‌تر باشد.

 

نگاشت یک automated test به چند TestRail case #

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

بعضی تیم‌ها برای هر TestRail case یک automated test می‌سازند، اما این کار همیشه عملی نیست. بسیاری از فریم‌ورک‌های اتوماسیون مدرن از این موارد استفاده می‌کنند:

  • منطق validation مشترک
  • stepهای قابل استفاده مجدد
  • تست‌های parameterized

در این شرایط، یک automated test واحد می‌تواند چند رفتار را بررسی کند که به چند TestRail test case مرتبط هستند.

برای مثال:

Automated test TestRail caseها
test_login_flow C101 – ورود معتبر
  C102 – ایجاد session
  C103 – redirect به dashboard

وقتی نتایج وارد TestRail می‌شوند، برای هر test case یک نتیجه جداگانه ثبت می‌شود تا traceability و گزارش‌ها دقیق بمانند.

این کار به تیم‌ها کمک می‌کند:

  • کد اتوماسیون را ساده و قابل استفاده مجدد نگه دارند
  • traceability شفاف نیازمندی‌ها را حفظ کنند
  • از ساختن automated testهای تکراری فقط برای هماهنگ شدن با ساختار caseها خودداری کنند

گردش کار مرحله‌به‌مرحله #

پیش‌نیازها #

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

  • TestRail CLI باید نصب شده باشد
  • یک project در TestRail دارید که test caseهای آن از قبل مستند شده‌اند
  • IDهای test case در TestRail را می‌دانید (مثل C123 و C2645)
  • از یک test runner پشتیبانی‌شده استفاده می‌کنید (مثلاً JUnit)

 

مرحله ۱: test caseها را در کد automation خود map کنید #

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

گزینه ۱: Match بر اساس نام #

ID مربوط به case را در نام تست قرار دهید. مثال‌ها:

  • 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 استفاده کنید.

گزینه ۲: Match بر اساس property #

ID تست را به‌عنوان یک property در 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 استفاده کنید.

  • ID مربوط به test case که باید استفاده کنید، همان IDای است که در صفحه Test Cases با پیشوند C نمایش داده می‌شود.
Specification first workflow ss2.png

 

مرحله ۲: نتایج تست را آپلود کنید #

برای آپلود نتایج از 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

توضیح flagها:

  • -n: caseهای جدید را به‌صورت خودکار ایجاد نکن
  • --case-matcher: برای روش mapping، «name» یا «property» را انتخاب کنید
  • --title: نام test run
  • -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.

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

  #

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

در بسیاری از workflowهای QA، مدیران یا leadهای QA از قبل test runها را می‌سازند تا پیشرفت را نسبت به یک milestone، sprint یا release پیگیری کنند. این runها معمولاً ترکیبی از تست‌های manual و automated را شامل می‌شوند. وقتی تست‌های automated بعداً اجرا می‌شوند، نتایج آن‌ها را می‌توان در test run موجود با استفاده از TestRail CLI آپلود کرد؛ به‌جای اینکه هر بار یک run جدید ساخته شود.

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

  • می‌خواهید یک test run واحد داشته باشید که هم نتایج اجرای manual و هم automated را شامل شود
  • می‌خواهید تست‌های automated را دوباره اجرا کنید و فقط نتیجه آن‌ها را به‌روزرسانی کنید
  • روی یک test run بلندمدت کار می‌کنید که بین چند اجرا یا چند عضو تیم مشترک است

 

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

فرض کنید یک test run از قبل در TestRail و زیر project شما ساخته شده است. این run شامل test caseهای زیر است:

  • C101 – Manual (به‌صورت دستی تست شده است)
  • C102 – دستی (به‌صورت دستی تست می‌شود)
  • C103 – خودکار (با CLI به‌روزرسانی می‌شود)
  • C104 – خودکار (با CLI به‌روزرسانی می‌شود)

مهندس automation، test suite را اجرا می‌کند و یک گزارش JUnit XML شامل نتایج caseهای C103 و C104 می‌سازد. نام فایل گزارش ./results.xml است.

دستور CLI برای به‌روزرسانی این test run #

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 می‌گوید به‌جای ساختن یک run جدید، test run با ID ۵۲ را به‌روزرسانی کند.
  • --case-matcher "property": test caseها را بر اساس property JUnit به نام test_id مطابقت می‌دهد.
  • -n: مطمئن می‌شود برای ورودی‌هایی که match نمی‌شوند، test case جدید به‌صورت خودکار ساخته نشود.

 

دریافت Run ID #

برای پیدا کردن run ID:

  1. test run را در TestRail باز کنید.
  2. به URL مرورگر نگاه کنید: https://yourcompany.testrail.io/index.php?/runs/view/52 – عدد 52 همان run ID است.

 

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

  • TestRail CLI فایل XML نتایج را می‌خواند
  • test caseهای C103 و C104 را با test caseهای موجود در Run ID ۵۲ match می‌کند
  • نتایج تست (pass/fail/skip) را برای این دو test case آپلود می‌کند
  • نتایج دستی (C101 ، C102) بدون تغییر باقی می‌مانند

به این ترتیب، تیم یک نمای واحد و متمرکز از وضعیت اجرای تست‌ها دارد؛ چیزی که برای گزارش‌گیری، test signoff و audit بسیار کاربردی است.

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

 

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

به‌روزرسانی شده در ۱۴۰۵-۰۴-۱۷

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

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

دیدگاهتان را بنویسید