Google is committed to advancing racial equity for Black communities. See how.
Halaman ini diterjemahkan oleh Cloud Translation API.
Switch to English

Penanganan Opsi di Tradefed

Penanganan opsi merupakan inti dari pendekatan modular Federasi Perdagangan. Secara khusus, opsi adalah mekanisme di mana Pengembang, Integrator, dan Runner Pengujian dapat bekerja sama tanpa harus saling menduplikasi pekerjaan satu sama lain. Sederhananya, penerapan penanganan opsi kami memungkinkan Pengembang menandai anggota kelas Java sebagai dapat dikonfigurasi, di mana nilai anggota tersebut dapat ditambah atau diganti oleh Integrator, dan selanjutnya dapat ditambah atau diganti oleh Test Runner. Mekanisme ini bekerja untuk semua tipe intrinsik Java, serta untuk setiap Map atau Collection tipe intrinsik.

Catatan: Mekanisme pilihan penanganan hanya bekerja untuk kelas menerapkan salah satu antarmuka termasuk dalam Uji Siklus Hidup , dan hanya jika kelas yang dipakai oleh mesin siklus hidup.

Pengembang

Untuk memulai, pengembang menandai anggota dengan anotasi @Option . Mereka menentukan (minimal) name dan nilai description , yang menentukan nama argumen yang terkait dengan Opsi itu, dan deskripsi yang akan ditampilkan di konsol TF ketika perintah dijalankan dengan --help atau --help-all .

Sebagai contoh, katakanlah kita ingin membuat tes telepon fungsional yang akan menghubungi berbagai nomor telepon, dan berharap menerima urutan nada DTMF dari setiap nomor setelah tersambung.

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
    }

Hanya itu yang diperlukan Pengembang untuk menyiapkan dua titik konfigurasi untuk pengujian itu. Mereka kemudian dapat pergi dan menggunakan mWaitTime dan mCalls seperti biasa, tanpa terlalu memperhatikan fakta bahwa mereka dapat dikonfigurasi. Karena bidang @Option disetel setelah kelas dibuat, tetapi sebelum metode run dipanggil, itu menyediakan cara mudah bagi pelaksana untuk menyiapkan default atau melakukan beberapa jenis pemfilteran pada bidang Map dan Collection , yang jika tidak ditambahkan- hanya.

Integrator

Integrator bekerja di dunia Konfigurasi, yang ditulis dalam XML. Format konfigurasi memungkinkan Integrator untuk menyetel (atau menambahkan) nilai untuk setiap bidang @Option . Misalnya, Integrator ingin menentukan pengujian latensi rendah yang memanggil nomor default, serta pengujian yang berjalan lama yang memanggil berbagai nomor. Mereka dapat membuat sepasang konfigurasi yang mungkin terlihat seperti berikut:

<?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

Test Runner juga memiliki akses ke titik-titik konfigurasi ini melalui konsol Federasi Perdagangan. Pertama dan terpenting, mereka akan menjalankan Command (yaitu, config dan semua argumennya) dengan run command <name> instruksi (atau singkatnya run <name> ). Selain itu, mereka dapat menentukan daftar argumen apa pun yang merupakan bagian dari perintah, yang dapat menggantikan atau menambahkan bidang yang ditentukan oleh Objek Siklus Hidup dalam setiap konfigurasi.

Untuk menjalankan pengujian latensi rendah dengan many-numbers telepon, Test Runner dapat menjalankan:

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

Atau, untuk mendapatkan efek serupa dari arah yang berlawanan, Test Runner dapat mengurangi waktu tunggu untuk pengujian many-numbers :

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

Pengurutan Opsi

Anda mungkin memperhatikan bahwa opsi call mendasari implementasi adalah Map sehingga setelah diulang --call pada baris perintah, semuanya akan disimpan.

Batas timeout opsi, yang memiliki implementasi yang mendasari long , hanya dapat menyimpan satu nilai. Jadi hanya nilai terakhir yang ditentukan yang akan disimpan. --timeout 5 --timeout 10 akan menghasilkan timeout berisi 10.

Dalam kasus List atau Collection sebagai implementasi yang mendasari, semua nilai akan disimpan, dalam urutan yang ditentukan pada baris perintah.

Lihat juga

Meneruskan opsi ke suite dan modul