مدیریت اختیار در Tradefed، مدیریت اختیار در Tradefed

مدیریت گزینه در قلب رویکرد مدولار فدراسیون تجارت قرار دارد. به طور خاص، گزینه‌ها مکانیزمی هستند که توسط آن توسعه‌دهنده، یکپارچه‌ساز و تست رانر می‌توانند بدون نیاز به تکرار کارهای یکدیگر با هم کار کنند. به زبان ساده، پیاده‌سازی مدیریت گزینه ما به توسعه‌دهنده اجازه می‌دهد تا یک عضو کلاس جاوا را به‌عنوان قابل تنظیم علامت‌گذاری کند، در این مرحله مقدار آن عضو می‌تواند توسط انتگرال‌کننده افزوده یا لغو شود، و متعاقباً می‌تواند توسط Test Runner افزوده یا لغو شود. این مکانیسم برای همه انواع ذاتی جاوا و همچنین برای هر نمونه Map یا Collection از انواع ذاتی کار می کند.

توجه: مکانیسم کنترل اختیار فقط برای کلاس‌هایی کار می‌کند که یکی از رابط‌های موجود در Test Lifecycle را پیاده‌سازی می‌کنند، و تنها زمانی که آن کلاس توسط ماشین‌های چرخه حیات نمونه‌سازی شده باشد.

توسعه دهنده

برای شروع، توسعه‌دهنده عضوی را با حاشیه‌نویسی @Option علامت‌گذاری می‌کند. آنها (حداقل) name و مقادیر description را مشخص می‌کنند، که نام آرگومان مرتبط با آن گزینه را مشخص می‌کند، و توضیحی که در کنسول TF هنگام اجرای دستور با --help یا --help-all نمایش داده می‌شود.

به عنوان مثال، فرض کنید می‌خواهیم یک تست تلفنی کاربردی بسازیم که شماره تلفن‌های مختلفی را شماره‌گیری می‌کند و انتظار دارد که پس از اتصال، دنباله‌ای از زنگ‌های DTMF را از هر شماره دریافت کند.

public class PhoneCallFuncTest extends IRemoteTest {
    @Option(name = "timeout", description = "How long to wait for connection, in millis")
    private long mWaitTime = 30 * 1000;  // 30 seconds

    @Option(name = "call", description = "Key: Phone number to attempt. " +
            "Value: DTMF to expect. May be repeated.")
    private Map<String, String> mCalls = new HashMap<String, String>;

    public PhoneCallFuncTest() {
        mCalls.add("123-456-7890", "01134");  // default
    }

این تمام چیزی است که توسعه دهنده برای تنظیم دو نقطه پیکربندی برای آن آزمایش لازم است. سپس می توانند خاموش شوند و از mWaitTime و mCalls به طور معمول استفاده کنند، بدون اینکه توجه زیادی به این واقعیت داشته باشند که آنها قابل تنظیم هستند. از آنجایی که فیلدهای @Option بعد از نمونه سازی کلاس تنظیم می شوند، اما قبل از فراخوانی متد run ، راه آسانی را برای پیاده سازان فراهم می کند تا پیش فرض هایی را برای یا انجام نوعی فیلتر در فیلدهای Map و Collection انجام دهند، که در غیر این صورت ضمیمه می شوند. فقط

یکپارچه ساز

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

<?xml version="1.0" encoding="utf-8"?>
<configuration description="low-latency default test; low-latency.xml">
    <test class="com.example.PhoneCallFuncTest">
        <option name="timeout" value="5000" />
    </test>
</configuration>
<?xml version="1.0" encoding="utf-8"?>
<configuration description="call a bunch of numbers; many-numbers.xml">
    <test class="com.example.PhoneCallFuncTest">
        <option name="call" key="111-111-1111" value="#*#*TEST1*#*#" />
        <option name="call" key="222-222-2222" value="#*#*TEST2*#*#" />
        <!-- ... -->
    </test>
</configuration>

دونده تست

Test Runner همچنین از طریق کنسول Trade Federation به این نقاط پیکربندی دسترسی دارد. اول از همه، آنها یک دستور (یعنی یک پیکربندی و همه آرگومان های آن) را با دستور run command <name> (یا به اختصار run <name> ) اجرا می کنند. فراتر از آن، آنها می توانند هر لیستی از آرگومان ها را مشخص کنند که بخشی از فرمان است، که می تواند جایگزین یا الحاق به فیلدهای مشخص شده توسط اشیاء چرخه حیات در هر پیکربندی شود.

برای اجرای تست تاخیر کم با شماره تلفن های many-numbers ، Test Runner می تواند موارد زیر را اجرا کند:

tf> run low-latency.xml --call 111-111-1111 #*#*TEST1*#*# --call 222-222-2222 #*#*TEST2*#*#

یا، برای به دست آوردن یک اثر مشابه از جهت مخالف، Test Runner می تواند زمان انتظار برای تست many-numbers را کاهش دهد:

tf> run many-numbers.xml --timeout 5000

سفارش گزینه

ممکن است متوجه شوید که گزینه call زیربنای پیاده سازی Map است، بنابراین با --call های مکرر در خط فرمان، همه آنها ذخیره می شوند.

timeout انتخاب، که دارای پیاده سازی اساسی long است، تنها می تواند یک مقدار را ذخیره کند. بنابراین فقط آخرین مقدار مشخص شده ذخیره می شود. --timeout 5 --timeout 10 منجر به timeout شامل 10 می شود.

در صورت وجود List یا Collection به عنوان پیاده سازی اساسی، تمام مقادیر به ترتیب مشخص شده در خط فرمان ذخیره می شوند.

گزینه های بولی

گزینه های نوع بولی زیربنایی را می توان با ارسال مستقیم نام گزینه روی true تنظیم کرد، به عنوان مثال، --[option-name] و می توان با استفاده از نحو --no-[option-name] روی false تنظیم کرد.

همچنین ببینید

گزینه‌ها را به مجموعه و ماژول‌ها منتقل کنید ،

مدیریت گزینه در قلب رویکرد مدولار فدراسیون تجارت قرار دارد. به طور خاص، گزینه‌ها مکانیزمی هستند که توسط آن توسعه‌دهنده، یکپارچه‌ساز و تست رانر می‌توانند بدون نیاز به تکرار کارهای یکدیگر با هم کار کنند. به زبان ساده، پیاده‌سازی مدیریت گزینه ما به توسعه‌دهنده اجازه می‌دهد تا یک عضو کلاس جاوا را به‌عنوان قابل تنظیم علامت‌گذاری کند، در این مرحله مقدار آن عضو می‌تواند توسط انتگرال‌کننده افزوده یا لغو شود، و متعاقباً می‌تواند توسط Test Runner افزوده یا لغو شود. این مکانیسم برای همه انواع ذاتی جاوا و همچنین برای هر نمونه Map یا Collection از انواع ذاتی کار می کند.

توجه: مکانیسم کنترل اختیار فقط برای کلاس‌هایی کار می‌کند که یکی از رابط‌های موجود در Test Lifecycle را پیاده‌سازی می‌کنند، و تنها زمانی که آن کلاس توسط ماشین‌های چرخه حیات نمونه‌سازی شده باشد.

توسعه دهنده

برای شروع، توسعه‌دهنده عضوی را با حاشیه‌نویسی @Option علامت‌گذاری می‌کند. آنها (حداقل) name و مقادیر description را مشخص می‌کنند، که نام آرگومان مرتبط با آن گزینه را مشخص می‌کند، و توضیحی که در کنسول TF هنگام اجرای دستور با --help یا --help-all نمایش داده می‌شود.

به عنوان مثال، فرض کنید می‌خواهیم یک تست تلفنی کاربردی بسازیم که شماره تلفن‌های مختلفی را شماره‌گیری می‌کند و انتظار دارد که پس از اتصال، دنباله‌ای از زنگ‌های DTMF را از هر شماره دریافت کند.

public class PhoneCallFuncTest extends IRemoteTest {
    @Option(name = "timeout", description = "How long to wait for connection, in millis")
    private long mWaitTime = 30 * 1000;  // 30 seconds

    @Option(name = "call", description = "Key: Phone number to attempt. " +
            "Value: DTMF to expect. May be repeated.")
    private Map<String, String> mCalls = new HashMap<String, String>;

    public PhoneCallFuncTest() {
        mCalls.add("123-456-7890", "01134");  // default
    }

این تمام چیزی است که توسعه دهنده برای تنظیم دو نقطه پیکربندی برای آن آزمایش لازم است. سپس می توانند خاموش شوند و از mWaitTime و mCalls به طور معمول استفاده کنند، بدون اینکه توجه زیادی به این واقعیت داشته باشند که آنها قابل تنظیم هستند. از آنجایی که فیلدهای @Option بعد از نمونه سازی کلاس تنظیم می شوند، اما قبل از فراخوانی متد run ، راه آسانی را برای پیاده سازان فراهم می کند تا پیش فرض هایی را برای یا انجام نوعی فیلتر در فیلدهای Map و Collection انجام دهند، که در غیر این صورت ضمیمه می شوند. فقط

یکپارچه ساز

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

<?xml version="1.0" encoding="utf-8"?>
<configuration description="low-latency default test; low-latency.xml">
    <test class="com.example.PhoneCallFuncTest">
        <option name="timeout" value="5000" />
    </test>
</configuration>
<?xml version="1.0" encoding="utf-8"?>
<configuration description="call a bunch of numbers; many-numbers.xml">
    <test class="com.example.PhoneCallFuncTest">
        <option name="call" key="111-111-1111" value="#*#*TEST1*#*#" />
        <option name="call" key="222-222-2222" value="#*#*TEST2*#*#" />
        <!-- ... -->
    </test>
</configuration>

دونده تست

Test Runner همچنین از طریق کنسول Trade Federation به این نقاط پیکربندی دسترسی دارد. اول از همه، آنها یک دستور (یعنی یک پیکربندی و همه آرگومان های آن) را با دستور run command <name> (یا به اختصار run <name> ) اجرا می کنند. فراتر از آن، آنها می توانند هر لیستی از آرگومان ها را مشخص کنند که بخشی از فرمان است، که می تواند جایگزین یا الحاق به فیلدهای مشخص شده توسط اشیاء چرخه حیات در هر پیکربندی شود.

برای اجرای تست تاخیر کم با شماره تلفن های many-numbers ، Test Runner می تواند موارد زیر را اجرا کند:

tf> run low-latency.xml --call 111-111-1111 #*#*TEST1*#*# --call 222-222-2222 #*#*TEST2*#*#

یا، برای به دست آوردن یک اثر مشابه از جهت مخالف، Test Runner می تواند زمان انتظار برای تست many-numbers را کاهش دهد:

tf> run many-numbers.xml --timeout 5000

سفارش گزینه

ممکن است متوجه شوید که گزینه call زیربنای پیاده سازی Map است، بنابراین با --call های مکرر در خط فرمان، همه آنها ذخیره می شوند.

timeout انتخاب، که دارای پیاده سازی اساسی long است، تنها می تواند یک مقدار را ذخیره کند. بنابراین فقط آخرین مقدار مشخص شده ذخیره می شود. --timeout 5 --timeout 10 منجر به timeout شامل 10 می شود.

در صورت وجود List یا Collection به عنوان پیاده سازی اساسی، تمام مقادیر به ترتیب مشخص شده در خط فرمان ذخیره می شوند.

گزینه های بولی

گزینه های نوع بولی زیربنایی را می توان با ارسال مستقیم نام گزینه روی true تنظیم کرد، به عنوان مثال، --[option-name] و می توان با استفاده از نحو --no-[option-name] روی false تنظیم کرد.

همچنین ببینید

گزینه ها را به مجموعه و ماژول ها منتقل کنید