Evolusi Kerangka Otomasi Tes
Alat otomatisasi pengujian berbasis skrip telah ada sejak awal 1990-an. Sebenarnya Visual Test 1.0 dari Microsoft dirilis pada tahun 1992. Dan banyak alat yang kita miliki sekarang - memiliki asal usul pada era itu. Mulai dari QTP, Rational Functional Tester, Winrunner, dan banyak lainnya memanfaatkan jenis kerangka kerja untuk mengotomatiskan pengujian GUI. Kerangka kerja ini dalam dua dekade terakhir telah mengalami perubahan drastis. Mereka telah berevolusi dalam upaya untuk membuat otomatisasi pengujian menjadi lebih baik. Mereka telah matang untuk meminimalkan overhead pemeliharaan, menyediakan skrip pengujian yang sangat teruji dan andal, dan menawarkan cara yang lebih sederhana untuk mengembangkan otomatisasi pengujian. Dalam artikel ini kami akan membatasi ruang lingkup kami pada kerangka kerja ini dan meninjau kembali mengapa mereka memudar hingga terlupakan.
Rekam dan Putar:
Meskipun ini tidak melibatkan penulisan kode atau minimal, pengelolaan kode otomatisasi membuat Rekam/Pemutaran hanya dapat dilakukan dalam skala kecil. Masalah mendasar dari pendekatan ini secara harfiah adalah masalah skala. Jika kami menginginkan pengujian otomatis lainnya, kami akan merekam skrip lain yang pada akhirnya menghasilkan dua skrip untuk dipertahankan karena antarmuka AUT telah berubah seiring waktu. Semakin banyak pengujian yang kami rekam, semakin banyak kode otomatisasi yang perlu dipertahankan - yang akan menjadi terlalu membebani anggaran pengujian. Dalam merekam dan memutar ulang setiap kasus uji otomatis adalah urutan tindakan dengan data uji yang dikodekan secara keras ke dalamnya. Ini, pertama bukan pendekatan yang baik sesuai dengan prinsip-prinsip rekayasa perangkat lunak. Kedua, pengembalian otomatisasi dimulai saat kami memutar otomatisasi yang sama untuk menguji versi aplikasi berikutnya. Tetapi, dalam pendekatan ini setiap pengujian dijalankan sekali per rilis dan tidak digunakan berulang kali untuk meningkatkan cakupan pengujian. Oleh karena itu, untuk mengelola kode otomatisasi alwepo.com tersebut membuat pendekatan ini tidak praktis untuk otomatisasi skala besar. Oleh karena itu, hanya karena biaya pemeliharaan, otomatisasi pengujian telah melewati Rekam dan Pemutaran.
Berbasis Data:
Dibandingkan dengan Rekam dan Pemutaran, kerangka kerja Data Driven membahas dua masalah utama: rawatan dan cakupan pengujian. Data pengujian disimpan dalam file terpisah yang dibaca oleh skrip untuk digunakan sebagai input ke AUT. Setiap skrip diprogram dan dikelola oleh spesialis pengujian tetapi dapat digunakan berulang kali dengan kumpulan data yang berbeda untuk meningkatkan cakupan pengujian. Ini juga menanamkan kepercayaan pada keandalan skrip. Tapi, pengujian bukan hanya tentang memasukkan data. Ini tentang mensimulasikan skenario bisnis kehidupan nyata untuk menguji AUT secara menyeluruh. Oleh karena itu, penguji membutuhkan fasilitas untuk menentukan pengujian yang sebenarnya. Mereka membutuhkan pendekatan untuk menentukan data mana yang akan digunakan kapan dari file data mana.
Didorong Kata Kunci:
Ini membawa otomatisasi pengujian ke tingkat berikutnya. Bukan skrip sekarang yang mengarahkan pengujian tetapi data pengujian itu sendiri. Data uji dengan penggunaan kata kunci mengurutkan tindakan yang harus diikuti. Saat uji kasus otomatis berjalan, ia akan membaca data pengujian dan memanggil skrip relevan yang ditentukan oleh kata kunci, meneruskan AUT data untuk baris itu. Oleh karena itu, kata kunci adalah skrip yang ditulis oleh spesialis pengujian untuk melakukan semua tindakan yang diperlukan untuk menguji tugas bisnis/fungsional yang digunakan untuk menulis skrip ini. Dengan pendekatan ini, penguji memiliki kendali penuh atas apa yang harus dilakukan dan dalam urutan apa. Namun, pengembangan kode otomatisasi masih spesifik AUT. Tarif dan jumlah perubahan UI AUT, begitu juga dengan pemeliharaan skrip. Oleh karena itu, untuk otomatisasi pengujian skala besar,
Berbasis Peta Objek UI:
Dalam upaya untuk membuat otomatisasi pengujian lebih baik, kerangka kerja Peta Objek UI menyelesaikan ketiga tantangan otomatisasi pengujian. Ini menyelesaikan pemeliharaan, keandalan, dan kemudahan pengembangan skrip pengujian. Kerangka kerja ini mengambil instruksi dari data uji, mengenali kelas objek yang akan ditindaklanjuti, dan kemudian melakukan tindakan yang ditentukan pada objek itu dengan memanggil skrip untuk kelas objek tertentu itu, meneruskan tindakan dan data ke sana. Ini berarti skrip tidak lagi spesifik AUT tetapi spesifik kelas objek UI. Tidak ada skrip untuk instance objek tertentu tetapi untuk kelas objek. Setelah skrip untuk kelas objek UI ditulis, skrip tersebut dapat digunakan kembali dalam proyek otomatisasi tempat kelas objek UI ini digunakan. Melalui skrip kerangka kerja ini mengotomatiskan kelas objek UI. Dan setiap kali AUT mengalami perubahan, Anda hanya perlu mengubah peta objek dan data, bukan skrip untuk kelas objek UI. Satu-satunya waktu ini perlu diubah adalah ketika objek UI baru diperkenalkan atau ketika perilaku kelas objek UI yang ada berubah.
Rekam dan Putar:
Meskipun ini tidak melibatkan penulisan kode atau minimal, pengelolaan kode otomatisasi membuat Rekam/Pemutaran hanya dapat dilakukan dalam skala kecil. Masalah mendasar dari pendekatan ini secara harfiah adalah masalah skala. Jika kami menginginkan pengujian otomatis lainnya, kami akan merekam skrip lain yang pada akhirnya menghasilkan dua skrip untuk dipertahankan karena antarmuka AUT telah berubah seiring waktu. Semakin banyak pengujian yang kami rekam, semakin banyak kode otomatisasi yang perlu dipertahankan - yang akan menjadi terlalu membebani anggaran pengujian. Dalam merekam dan memutar ulang setiap kasus uji otomatis adalah urutan tindakan dengan data uji yang dikodekan secara keras ke dalamnya. Ini, pertama bukan pendekatan yang baik sesuai dengan prinsip-prinsip rekayasa perangkat lunak. Kedua, pengembalian otomatisasi dimulai saat kami memutar otomatisasi yang sama untuk menguji versi aplikasi berikutnya. Tetapi, dalam pendekatan ini setiap pengujian dijalankan sekali per rilis dan tidak digunakan berulang kali untuk meningkatkan cakupan pengujian. Oleh karena itu, untuk mengelola kode otomatisasi alwepo.com tersebut membuat pendekatan ini tidak praktis untuk otomatisasi skala besar. Oleh karena itu, hanya karena biaya pemeliharaan, otomatisasi pengujian telah melewati Rekam dan Pemutaran.
Berbasis Data:
Dibandingkan dengan Rekam dan Pemutaran, kerangka kerja Data Driven membahas dua masalah utama: rawatan dan cakupan pengujian. Data pengujian disimpan dalam file terpisah yang dibaca oleh skrip untuk digunakan sebagai input ke AUT. Setiap skrip diprogram dan dikelola oleh spesialis pengujian tetapi dapat digunakan berulang kali dengan kumpulan data yang berbeda untuk meningkatkan cakupan pengujian. Ini juga menanamkan kepercayaan pada keandalan skrip. Tapi, pengujian bukan hanya tentang memasukkan data. Ini tentang mensimulasikan skenario bisnis kehidupan nyata untuk menguji AUT secara menyeluruh. Oleh karena itu, penguji membutuhkan fasilitas untuk menentukan pengujian yang sebenarnya. Mereka membutuhkan pendekatan untuk menentukan data mana yang akan digunakan kapan dari file data mana.
Didorong Kata Kunci:
Ini membawa otomatisasi pengujian ke tingkat berikutnya. Bukan skrip sekarang yang mengarahkan pengujian tetapi data pengujian itu sendiri. Data uji dengan penggunaan kata kunci mengurutkan tindakan yang harus diikuti. Saat uji kasus otomatis berjalan, ia akan membaca data pengujian dan memanggil skrip relevan yang ditentukan oleh kata kunci, meneruskan AUT data untuk baris itu. Oleh karena itu, kata kunci adalah skrip yang ditulis oleh spesialis pengujian untuk melakukan semua tindakan yang diperlukan untuk menguji tugas bisnis/fungsional yang digunakan untuk menulis skrip ini. Dengan pendekatan ini, penguji memiliki kendali penuh atas apa yang harus dilakukan dan dalam urutan apa. Namun, pengembangan kode otomatisasi masih spesifik AUT. Tarif dan jumlah perubahan UI AUT, begitu juga dengan pemeliharaan skrip. Oleh karena itu, untuk otomatisasi pengujian skala besar,
Berbasis Peta Objek UI:
Dalam upaya untuk membuat otomatisasi pengujian lebih baik, kerangka kerja Peta Objek UI menyelesaikan ketiga tantangan otomatisasi pengujian. Ini menyelesaikan pemeliharaan, keandalan, dan kemudahan pengembangan skrip pengujian. Kerangka kerja ini mengambil instruksi dari data uji, mengenali kelas objek yang akan ditindaklanjuti, dan kemudian melakukan tindakan yang ditentukan pada objek itu dengan memanggil skrip untuk kelas objek tertentu itu, meneruskan tindakan dan data ke sana. Ini berarti skrip tidak lagi spesifik AUT tetapi spesifik kelas objek UI. Tidak ada skrip untuk instance objek tertentu tetapi untuk kelas objek. Setelah skrip untuk kelas objek UI ditulis, skrip tersebut dapat digunakan kembali dalam proyek otomatisasi tempat kelas objek UI ini digunakan. Melalui skrip kerangka kerja ini mengotomatiskan kelas objek UI. Dan setiap kali AUT mengalami perubahan, Anda hanya perlu mengubah peta objek dan data, bukan skrip untuk kelas objek UI. Satu-satunya waktu ini perlu diubah adalah ketika objek UI baru diperkenalkan atau ketika perilaku kelas objek UI yang ada berubah.
Komentar
Posting Komentar