Definisi tes penerimaan. Pengembangan dokumentasi, produksi dan pengujian prototipe. Set standar untuk sistem otomatis

Biasanya pengujian ini dilakukan oleh tim lain yang mengulangi banyak hal yang tercakup dalam pengujian penerimaan otomatis secara manual atau dengan alat lain. Ini mungkin dilakukan karena tes penerimaan tidak dapat dengan mudah dijalankan di lingkungan yang berbeda, atau tim pengembangan tidak dapat dengan mudah memahami apa yang dilakukan tes, dan data yang digunakan disembunyikan dalam kode, sehingga sulit untuk ditemukan atau diubah. Menyembunyikan maksud pengujian dalam kode membuat sulit untuk memahami apa yang coba dilakukan pengujian.

Ini juga berarti bahwa anggota tim non-teknis tidak dapat dengan mudah berkontribusi untuk pengujian, dan orang teknis menghabiskan lebih banyak waktu untuk kode pengujian otomatis. Saat pengujian perlu difaktorkan ulang, yang tidak dapat dihindari karena memisahkan maksud dari sarana implementasi, Anda dapat fokus pada pemfaktoran ulang implementasi pengujian daripada apa yang seharusnya dilakukan pengujian.

Pemisahan maksud, implementasi dan data

Di bawah ini adalah diagram yang menggambarkan ide untuk memisahkan maksud, implementasi, dan data. Lingkungan juga disertakan, karena penting untuk memahami lingkungan tempat pengujian akan dijalankan dan, jika perlu, mengubah data dan menjalankan pengujian. Membuat maksud dapat dilakukan oleh anggota tim non-teknis dalam bahasa yang tidak bergantung pada implementasi. Ini penting karena artinya implementasi dapat di-refactored tanpa harus mengubah maksud pengujian. Kebalikannya juga benar; dimungkinkan untuk mengubah maksud pengujian tanpa memengaruhi implementasi, asalkan ada implementasi yang memenuhi semua kata dalam paragraf maksud.

Jika, dalam kasus terburuk, Anda memutuskan untuk membuang seluruh implementasi dan memulai dari awal, Anda masih dapat mempertahankan maksud pengujian dan oleh karena itu tidak kehilangan bagian terpenting dari pengujian otomatis, pengujian apa yang coba dilakukan. Data juga harus dipisahkan menjadi maksud dan implementasi, dengan melakukan ini data dapat ditentukan dalam pengujian dengan abstraksi dan kemudian implementasi dihapus. Misalnya, pengujian mungkin menunjukkan "Klien Emas", saat klien diidentifikasi, bukan bagian dari pengujian, tetapi merupakan bagian dari lapisan data.

Pembuatan lapisan data dan abstraksi data bukanlah teknik baru; mereka biasanya digunakan untuk kode aplikasi dan harus diterapkan pada pengujian otomatis karena manfaatnya masih berlaku. Dalam kasus pengujian, lapisan data dipanggil untuk mengambil data dari sumber data untuk jenis klien yang sesuai.

Kasus pengujian kemudian mengulangi semua entri dalam daftar dan melakukan pengujian pada setiap entri pelanggan. Pengujian sistem sesuai dengan salah satu tingkat pengujian perangkat lunak yang dikombinasikan dengan berbagai pengujian seperti pemulihan, keamanan, ketahanan, kinerja, konektivitas, volume, tegangan, ketersediaan data, kemudahan penggunaan, pengoperasian, Lingkungan, penyimpanan, konfigurasi, instalasi, dan dokumentasi. Masing-masing memiliki tujuan yang berbeda dan memiliki tujuan bersama yang menunjukkan visi sistematis proyek. Pengujian penerimaan adalah jenis level lain yang dilengkapi dengan level pengujian perangkat lunak, pengujian ini sangat mendasar karena tes inilah yang akan memungkinkan kita untuk mendapatkan produk yang memenuhi standar yang disyaratkan dan yang secara bersamaan memenuhi persyaratan pengguna sesuai dengan persyaratan yang mereka angkat dari awal. Ini memaksa sistem untuk menguji proses pengujian vital, karena dalam hal produk, jumlah bug, dan tingkat keparahan bug tersebut, langkah dalam pengembangan biasanya rentan terhadap sebagian besar bug. Gambar 1: Verifikasi sistem berulang Pengujian sistem bukanlah proses untuk memverifikasi fungsionalitas sistem atau program lengkap, karena akan mubazir dengan proses uji fungsional. Pengujian sistem memiliki tujuan khusus: untuk membandingkan sistem atau program dengan tujuan aslinya. Untuk tujuan ini, dua nilai disajikan. Pengujian sistem tidak terbatas pada sistem. Jika produk adalah sebuah program, pengujian sistem adalah upaya untuk mendemonstrasikan bagaimana program sepenuhnya gagal memenuhi tujuan atau persyaratannya. Pengujian sistem, menurut definisi, tidak mungkin kecuali ada persyaratan tertulis yang dapat diukur untuk produk. Pengujian sistem adalah fase penelitian yang memastikan bahwa setiap komponen atau modul berinteraksi dengan komponen atau modul lain sebagaimana dimaksud. Pengujian sistem ditujukan untuk implementasi sistem yang mendalam, memeriksa integrasi sistem informasi di seluruh dunia, memeriksa fungsi antarmuka yang benar antara berbagai subsistem yang membentuknya dan dengan sistem informasi lain yang berkomunikasi dengannya. Masalah pengujian sistem klasik adalah "menunjuk jari". Ini terjadi ketika bug ditemukan dan pengembang setiap elemen sistem menyalahkan orang lain. Alih-alih jatuh ke dalam absurditas ini, insinyur perangkat lunak harus mengantisipasi kemungkinan masalah dengan antarmuka: jalur penanganan kesalahan desain yang memeriksa semua informasi yang berasal dari elemen lain dari sistem. Pengujian dan Pengujian Sistem 6 Menerapkan serangkaian pengujian yang mensimulasikan data buruk atau lainnya kemungkinan kesalahan dalam antarmuka perangkat lunak. Daftarkan hasil tes sebagai bukti jika bersalah. Berpartisipasi dalam perencanaan dan pengembangan pengujian sistem untuk memastikan bahwa perangkat lunak telah diuji dengan benar. Faktanya, pengujian sistem mencakup serangkaian pengujian yang berbeda, yang tujuan utamanya adalah untuk menghitung sistem secara mendalam saat dihitung. Meskipun setiap pengujian memiliki tujuan yang berbeda, semuanya bekerja untuk memastikan bahwa semua elemen sistem telah terintegrasi dengan baik dan menjalankan fungsi yang sesuai. 2 Tinjauan sistem pengujian. Ketika pengujian akan dilakukan, perlu untuk memelihara sistem, yaitu pendekatan integral untuk pengembangan perangkat lunak. Menerapkan konsep-konsep ini ke pengujian perangkat lunak menghasilkan seperangkat prinsip yang akan menjadi dasar pengujian: Anda harus memastikan bahwa Anda tahu persis tujuan perangkat lunak yang diuji, serta tingkat keberhasilan Anda. Elemen-elemen ini ditemukan dalam dokumen yang diperoleh selama fase pengumpulan persyaratan, serta dalam spesifikasi perangkat lunak. Informasi ini akan diperlukan untuk menyiapkan rencana pengujian dan akan menjadi dasar untuk memulai pengembangan kasus uji. Input dan output dari sistem yang disetujui harus didefinisikan. Aspek ini diperlukan dalam penyusunan test case, serta dalam pembuatan prosedur test, terutama test case yang berorientasi yang menunjukkan pemenuhan tujuan. Pertimbangkan sistem utama yang menjalankan perangkat lunak yang diuji. Biasanya lingkungan organisasi yang terdiri dari perangkat keras, perangkat lunak, dan orang-orang. Semua elemen ini memiliki pengaruh besar pada sistem dan terutama membantu dalam persiapan kasus uji situasi yang tidak diinginkan terkait dengan data yang tidak memadai, kurangnya elemen yang diperlukan dan terjadinya pengecualian. 3 Tinjauan Pengujian Sistem Proses pengujian sistem terdiri dari dua fase yang dapat sangat terpisah dari waktu ke waktu: persiapan pengujian dan aplikasi pengujian. Yang pertama terkait erat dengan persyaratan sehingga terjadi di awal proyek dan yang terakhir membutuhkan sistem penuh atau setidaknya satu integrasi karena produk parsial dikatakan belum dirilis untuk dapat menerapkan tes sehingga terjadi pada tahap lanjutan dari proyek. Situasi yang tepat dengan bagian-bagian ini tergantung pada model yang dipilih. lingkaran kehidupan. Untuk melakukan kegiatan kedua dan ketiga, diperlukan dokumen persyaratan. Tahap pertama pengujian memberikan umpan balik untuk menganalisis persyaratan, mengidentifikasi kesenjangan, ambiguitas, dan masalah lainnya. Ini juga memberikan saran berharga tentang desain dan implementasi sistem jika Anda hanya mengembangkannya. Fase aplikasi pengujian memerlukan rencana pengujian dan versi sistem yang dapat dieksekusi. Dalam hal ini, kasus uji yang telah disiapkan akan diterapkan, hasilnya akan dianalisis dan setiap cacat diidentifikasi. Langkah kedua ini memberikan umpan balik untuk implementasi dan desain, menunjukkan kemungkinan cacat yang perlu diperbaiki. Ini juga memberikan informasi yang akan berguna dalam merilis sistem, mengadopsinya, mengevaluasi keandalannya, dan memeliharanya. Gambar 1 menunjukkan proses pengujian sistem dan hubungannya dengan proses lainnya. Poin kedua penting karena terkadang pengujian sistem dikacaukan dengan pengujian antarmuka. Yang pertama memeriksa interaksi semua bagian, dan yang kedua menganalisis elemen antarmuka dan, mungkin, pemrosesan peristiwa terkait. Namun, alat yang membantu menguji antarmuka dapat digunakan untuk menjalankan pengujian sistem. Beberapa pertanyaan muncul: berapa banyak kasus yang akan cukup? Bagaimana cara menghasilkan sesedikit mungkin? Nilai-nilai apa yang sesuai? Pengujian dan Pengujian Sistem 9 1 Rencana Pengujian Rencana pengujian sangat dokumen penting selama pengujian perangkat lunak. Ini menjelaskan tujuan dan pendekatan untuk pengujian, rencana kerja, prosedur operasional, alat yang diperlukan dan tanggung jawab. Pengujian dan pengujian sistem 10 Dokumen persyaratan harus berisi daftar fungsi yang akan dilakukan oleh perangkat lunak, menjelaskan dan memprioritaskannya; itu juga harus mencakup persyaratan non-fungsional, yang mungkin mencakup aspek organisasi, operasional, dan lainnya. Dokumen persyaratan yang disiapkan dengan baik harus menyediakan cara untuk setiap persyaratan untuk memverifikasi bahwa itu terpenuhi. Dalam hal fitur, ini akan menjadi deskripsi, dan dalam kasus persyaratan non-fungsional, itu bisa menjadi spesifikasi yang sangat tepat seperti waktu respons. Untuk saat ini, kami akan fokus pada persyaratan fungsional, meninggalkan sisanya untuk bagian selanjutnya. Pengujian sistem penting karena faktor-faktor berikut:  Ini adalah sistem yang diuji secara keseluruhan dalam siklus hidup pengembangan sistem.  Sistem diperiksa untuk memenuhi fungsinya dan persyaratan teknis .  Sistem diuji dalam lingkungan yang sedekat mungkin dengan lingkungan produksi.  Pengujian sistem memungkinkan Anda menguji, memvalidasi, dan memvalidasi persyaratan bisnis dan arsitektur aplikasi. 6Jenis pengujian sistem Pengujian fungsional  Uji integrasi. - Di mana peralatan uji memiliki akses ke kode sumber sistem. Ketika masalah ditemukan, tim integrasi mencoba menemukan sumber masalah dan menentukan komponen yang perlu di-debug. Pengujian integrasi terutama berkaitan dengan menemukan cacat dalam sistem. Bukti pengiriman. Berikut adalah versi sistem yang dapat dikirimkan ke pengguna. Di sini, tim penguji prihatin dengan memverifikasi bahwa sistem memenuhi persyaratannya dan menjamin keandalan sistem. Tes pengiriman biasanya pengujian kotak hitam di mana peralatan uji hanya berkaitan dengan apakah sistem berfungsi dengan baik. Komponen yang dapat diintegrasikan dapat berupa komponen komersial, komponen yang dapat digunakan kembali yang disesuaikan dengan sistem tertentu, atau komponen yang baru dikembangkan. Untuk banyak sistem besar, mereka kemungkinan akan menggunakan ketiga jenis komponen. Tes integrasi memverifikasi bahwa komponen-komponen ini benar-benar bekerja bersama, dipanggil dengan benar, dan meneruskan data yang benar pada waktu yang tepat melalui antarmuka mereka. Integrasi sistem melibatkan pengidentifikasian kelompok komponen yang menyediakan beberapa fungsionalitas sistem dan mengintegrasikannya dengan menambahkan kode untuk bekerja bersama. Terkadang kerangka keseluruhan sistem dikembangkan terlebih dahulu, dan komponen ditambahkan. Ini disebut pasca integrasi. Ini adalah integrasi ke atas. Dalam praktiknya, untuk banyak sistem, strategi integrasi merupakan kombinasi keduanya, menambahkan komponen infrastruktur tambahan dan komponen fungsional. Kedua pendekatan integrasi memerlukan kode tambahan untuk memodelkan komponen lain dan memungkinkan sistem untuk memulai. Kesulitan utama yang dihadapi selama tes integrasi adalah lokasi bug. Ada interaksi kompleks antara komponen sistem, dan ketika output anomali terdeteksi, akan sulit untuk menentukan di mana kesalahan terjadi. Untuk mempermudah mengisolasi bug, Anda harus selalu menggunakan pendekatan inkremental untuk integrasi dan pengujian sistem. Tujuan utama dari proses ini adalah untuk meningkatkan kepercayaan pemasok bahwa sistem memenuhi persyaratannya. Jika demikian, dapat dikirimkan sebagai produk atau dikirimkan ke pelanggan. Untuk mendemonstrasikan bahwa suatu sistem memenuhi persyaratannya, harus ditunjukkan bahwa ia memberikan fungsionalitas, kinerja, dan keandalan yang ditentukan dan tidak gagal dalam penggunaan normal. Pengujian pengiriman biasanya merupakan proses pengujian kotak hitam di mana pengujian diturunkan dari spesifikasi sistem. Sistem dipandang sebagai kotak hitam yang perilakunya hanya ditentukan dengan memeriksa input dan output masing-masing. Nama lain untuk ini adalah pengujian fungsional karena penguji hanya tertarik pada fungsionalitas dan bukan implementasi perangkat lunak. Pada gambar berikut, kita akan melihat ilustrasi model sistem yang memungkinkan untuk validasi kotak hitam. Penguji menyajikan input ke komponen atau sistem dan mempertimbangkan input. Dalam beberapa kasus, sistem harus toleran terhadap kesalahan; yaitu, kegagalan pemrosesan tidak boleh menyebabkan kegagalan sistem secara keseluruhan. Uji Sistem dan Uji Penerimaan 14 Kegagalan sistem harus diperbaiki dalam jangka waktu tertentu atau akan menimbulkan kerusakan ekonomi yang serius. Tes pemulihan adalah tes sistem yang menyebabkan perangkat lunak gagal dalam beberapa cara dan memeriksa apakah pemulihan dilakukan dengan benar. Jika pemulihan terjadi secara otomatis, Anda perlu memeriksa apakah inisialisasi ulang, mekanisme pencadangan sistem, pemulihan data, dan reboot sudah benar. Jika pemulihan memerlukan intervensi manusia, waktu pemulihan rata-rata harus ditentukan untuk menentukan apakah masih dalam batas yang dapat diterima. Tujuannya adalah untuk menetapkan titik akhir di mana sistem mulai beroperasi di bawah persyaratan yang ditentukan. Ini tidak boleh disamakan dengan uji volume; tegangan tinggi adalah jumlah maksimum data atau aktivitas per waktu yang singkat. Analoginya adalah untuk mengevaluasi juru ketik. Tes volume akan ditentukan jika juru ketik dihadapkan dengan draft laporan besar; stress test akan menentukan apakah juru ketik dapat mengetik dengan indeks 50 kata per menit. Pelanggaran mencakup berbagai aktivitas: Seorang peretas yang mencoba masuk per game. Tes keamanan memverifikasi bahwa mekanisme keamanan yang dibangun ke dalam sistem benar-benar melindunginya dari gangguan yang tidak pantas. "Sistem harus diuji untuk keamanan sistem agar kebal terhadap serangan frontal, tetapi juga untuk mereka yang membuat sayap atau belakang." Selama uji keamanan, siapa pun yang menerapkannya memainkan peran sebagai orang yang ingin masuk. Semua ini sepadan! Anda harus mencoba mendapatkan kata sandi apa pun sarana eksternal; dapat menyerang sistem menggunakan perangkat lunak khusus yang dirancang untuk melewati arsitektur yang dilindungi; dia dapat memenuhi sistem, dengan demikian menolak layanan kepada orang lain; dapat menyebabkan kesalahan yang disengaja dalam sistem untuk mencoba mendapatkan akses selama pemulihan: Anda dapat melihat data tanpa perlindungan, dengan ide mencari kata sandi untuk sistem. Jika cukup waktu dan sumber daya diberikan, sistem pada akhirnya akan ujian yang bagus untuk keamanan. Peran perancang sistem adalah bahwa biaya interupsi lebih besar daripada biaya informasi yang diterima. Namun, analisis faktor manusia tetap menjadi masalah yang sangat subjektif. Kasus uji dimaksudkan untuk menunjukkan bahwa target penyimpanan ini tidak ditemukan. Seringkali jumlah konfigurasi yang mungkin terlalu besar untuk diuji masing-masing, tetapi jika memungkinkan, Anda harus menguji program dengan setiap jenis perangkat keras dan dengan konfigurasi minimum dan maksimum. Jika program itu sendiri dapat dikonfigurasi untuk melewati komponen, atau jika dapat dijalankan di banyak komputer, setiap konfigurasi harus diuji. Pengujian prosedur instalasi merupakan bagian penting dari proses pengujian sistem. Ini terutama berlaku untuk sistem instalasi otomatis disertakan dalam paket perangkat lunak. Penginstal yang tidak dijalankan dengan benar dapat mencegah pengguna mendapatkan pengalaman sukses dengan sistem. Pengalaman pertama pengguna adalah ketika dia menginstal aplikasi. Salah satu cara untuk mencapai ini adalah dengan menggunakan dokumentasi untuk mendefinisikan tampilan kasus uji sistem sebelumnya. Artinya, begitu Anda ingin mengembangkan kasus kelebihan beban, Anda harus menggunakan dokumentasi sebagai panduan untuk menulis kasus uji yang sebenarnya. Selain itu, dokumentasi pengguna harus diperiksa untuk akurasi dan kejelasan. Setiap contoh yang ditunjukkan dalam dokumentasi harus diuji dan ditambahkan ke daftar tugas dan disertakan dalam program. Pengujian dan Pengujian Sistem 17 sudut pandang operasi, setelah penerapan sistem di lingkungan aktual dan berdasarkan kepatuhan terhadap persyaratan non-fungsional yang ditentukan. Pengujian resistensi dirancang untuk melawan program dalam situasi abnormal. Intinya, orang yang melakukan tes resistensi akan bertanya. Seberapa jauh Anda membuatnya sebelum gagal? Tes resistansi melakukan sistem sedemikian rupa sehingga memerlukan jumlah, frekuensi, atau jumlah sumber daya yang tidak normal. Sebagai contoh: tes khusus telah dikembangkan yang menghasilkan 10 interupsi per detik ketika rata-rata cangkir adalah satu atau dua. Frekuensi input data ditingkatkan dengan jumlah yang memungkinkan respons terhadap fungsi input. Jalankan kasus uji yang membutuhkan memori maksimum atau sumber daya lainnya. Kasus uji dirancang untuk memecahkan masalah manajemen memori. Kasus uji dibuat yang menyebabkan pencarian disk berlebihan. Gambar tersebut adalah contoh uji resistansi. Tes kinerja diterapkan pada semua tahap proses pengujian. Bahkan di tingkat satuan. Kinerja modul individu harus dievaluasi selama pengujian. Namun, hanya setelah semua elemen sistem terintegrasi sepenuhnya, kinerja sistem yang sebenarnya dapat dicapai. Tes kinerja sering kali melibatkan pengujian resistensi dan seringkali memerlukan instruksi perangkat lunak dan perangkat keras. Artinya, seringkali perlu mengukur penggunaan sumber daya secara akurat. Dengan menggunakan alat eksternal, Anda dapat secara teratur memantau interval berjalan, peristiwa yang dicatat, dan status sampel perangkat keras. Pengujian ini dilakukan agar klien mengonfirmasi bahwa sistem tersebut valid untuknya. Perencanaan terperinci untuk pengujian ini harus dilakukan pada awal tahap pengembangan dengan tujuan menggunakan hasil sebagai indikasi validitasnya: jika pengujian terdokumentasi dilakukan untuk kepuasan pelanggan, produk dianggap benar dan oleh karena itu memadai untuk dimasukkan ke dalam produksi. 6 Tes penerimaan2 pada dasarnya adalah tes fungsional pada sistem yang lengkap dan bertujuan untuk memeriksa apakah persyaratan yang ditetapkan . Eksekusinya opsional untuk klien, dan jika tidak ditentukan secara eksplisit, mereka disertakan dalam pengujian sistem. Artinya, tes penerimaan sering kali menjadi tanggung jawab pengguna atau pelanggan, meskipun siapa pun yang terlibat dalam bisnis dapat melakukannya. Pengujian penerimaan memerlukan lingkungan pengujian yang mewakili lingkungan produksi. Fase atau level ini sebagai titik awal mendefinisikan dasar penerimaan produk yang telah ditetapkan dalam lingkungan sertifikasi. Pengujian dan Penerimaan Sistem 19 Gambar - Kontrol penerimaan. 1 Meneliti situasi saat ini dalam tes penerimaan. Sebagai bagian dari pengujian, kita harus memeriksa perangkat lunak, salah satu yang paling penting adalah pengujian penerimaan. Ini adalah tes yang dikembangkan oleh tim pengembangan itu sendiri berdasarkan persyaratan fungsional yang ditentukan dalam fase analisis untuk mencakup seluruh spektrum dan dilakukan oleh pengguna akhir, tetapi tidak semua tetapi beberapa pengguna memiliki hasil yang signifikan yang memberikan validitas dan kesesuaian dengan produk yang dikirimkan kepada mereka atas dasar apa yang awalnya disepakati. Tergantung pada kompleksitas sistem yang diuji, terlepas dari apakah itu dibagi menjadi modul, dll. pelaksanaan tes ini dilakukan secara berbeda. Jika aplikasi dibagi menjadi modul, ini akan dianggap sebagai subsistem dan akan cukup kompleks untuk ditangani secara berbeda, sesi uji penerimaan yang berbeda harus dilakukan. 2 Tujuan pengujian penerimaan Pengujian penerimaan bertujuan untuk memperoleh penerimaan pelanggan akhir sebelum pengiriman produk untuk masuk ke produksi. Ketika sebuah organisasi telah melakukan pengujian sistem dan memperbaiki sebagian besar cacatnya, sistem akan dikirimkan ke pengguna atau pelanggan untuk disetujui. Tujuan pengujian penerimaan adalah untuk memverifikasi bahwa sistem memenuhi kinerja yang diharapkan dan memungkinkan pengguna sistem itu untuk menentukan penerimaannya dalam hal fungsionalitas dan kinerjanya. Tes penerimaan ditentukan oleh pengguna sistem dan disiapkan oleh tim pengembangan, meskipun eksekusi akhir dan persetujuan terserah pengguna. Validasi sistem dicapai dengan menjalankan pengujian kotak hitam yang menunjukkan kepatuhan dan disertakan dalam rencana pengujian yang menentukan validasi yang akan dilakukan dan kasus pengujian terkait. Rencana ini dirancang untuk memastikan bahwa semua persyaratan fungsional yang ditentukan oleh pengguna terpenuhi, serta persyaratan non-fungsional yang terkait dengan kinerja, keamanan akses sistem, data dan proses, dan berbagai sumber daya sistem, 3 Generasi pengujian penerimaan. Sistem harus diterima oleh pengguna. Untuk alasan ini, berdasarkan spesifikasi sistem yang terstruktur, analis membuat serangkaian kasus uji yang harus lulus dengan memuaskan. Karena tes penerimaan dapat dikembangkan secara paralel dengan aktivitas desain dan praktik, aktivitas ini biasanya dimulai oleh analis segera setelah aktivitas Analisis Terstruktur selesai. 4 Strategi Pengujian Penerimaan Jika sistem dirancang untuk pasar massal, maka tidak akan praktis untuk mengujinya untuk pengguna individu atau pelanggan, dalam beberapa kasus tidak mungkin. Dalam kasus ini, umpan balik diperlukan sebelum produk disiapkan untuk dijual. Seringkali sistem seperti itu memiliki dua tahap pengujian penerimaan. Pengujian Alfa dan Beta Ketika perangkat lunak khusus dibuat untuk klien, serangkaian tes penerimaan dilakukan untuk memungkinkan klien menguji semua persyaratan. Dilakukan oleh klien di lokasi pengembangan. Perangkat lunak ini digunakan secara alami dengan pengembang sebagai pengamat pengguna, bersama dengan kesalahan pendaftaran dan masalah penggunaan. Tes alfa dilakukan di lingkungan yang terkendali. Anda bekerja di lingkungan yang terkendali dan klien selalu memiliki ahli untuk membantu Anda menggunakan sistem. Pengembang melacak bug yang ditemukan dan masalah penggunaan. Tes -beta dilakukan setelah tes -alpha dan dikembangkan di lingkungan klien. Dalam hal ini, klien dibiarkan sendiri dengan produk dan mencoba menemukan bug yang menginformasikan pengembang. Mereka dilakukan oleh pengguna akhir perangkat lunak di stasiun kerja pelanggan. Tidak seperti tes alfa, pengembang biasanya tidak hadir. Dengan demikian, pengujian beta adalah aplikasi langsung dari perangkat lunak di lingkungan yang tidak dapat dikendalikan oleh pengembang. Klien mencatat semua masalah yang terjadi selama pengujian beta dan melaporkan kembali ke pengembang secara berkala. 5 Input, output, tugas dan peran tes penerimaan. Spesifikasi persyaratan masuk. Tugas Mempersiapkan lingkungan pengujian. Kami merekomendasikan memiliki lingkungan pengujian khusus untuk jenis pengujian ini. Instalasi di lingkungan pengujian. Pengujian dan Pengujian Sistem 22 Identifikasi pengujian yang akan dilakukan. Kemungkinan dependensi yang ada di antara pengujian akan dibuat dan urutan atau urutan pengujian yang akan dijalankan akan ditetapkan berdasarkan dependensi ini. Menerima dan mencatat hasil. Memperbaiki bug dan bug. Ulangi tugas sampai Anda lulus semua tes. Menyiapkan laporan uji penerimaan. Tinjauan tentang eksekusi yang benar dan hasil dari semua tes yang diajukan. Pembuatan basis produksi. Penutupan kegiatan secara resmi. Hasil tes. Laporan penerimaan produk yang diterima. Manajer proyek. Fokus pada pengujian penerimaan terkait dengan upaya untuk memperkuat pendapat bahwa pengguna yang terintegrasi dalam tahap ini, pada tahap awal, akan membantu meningkatkan proses ini dalam tahap perencanaan dan desain pengujian, dengan perbaikan selanjutnya dalam banyak aspek kuantitatif dan yang diinginkan. , seperti: Peningkatan kualitas keamanan perangkat lunak yang terintegrasi. Minimisasi biaya. Peningkatan keandalan dalam hasil proyek. Saat menggunakan perangkat lunak dengan lebih sedikit kesalahan, ada peningkatan kepuasan pelanggan. Ini meningkatkan efisiensi proses pengembangan. 7 Kriteria untuk pengujian penerimaan. Penerimaan perangkat lunak dicapai melalui serangkaian tes yang menunjukkan bahwa mereka memenuhi persyaratan. Rencana pengujian menjelaskan jenis pengujian yang akan diterapkan dan prosedur pengujian mendefinisikan kasus pengujian tertentu, baik rencana maupun prosedur dirancang untuk memastikan bahwa mereka memenuhi semua persyaratan fungsional, bahwa semua karakteristik perilaku tercapai, semua persyaratan kinerja terpenuhi, dokumentasi benar dan mengikuti semua persyaratan untuk kemudahan penggunaan dan lainnya persyaratan yang ditentukan. 8 Alat untuk tes penerimaan. Ini memungkinkan pelanggan, penguji, dan pemrogram untuk mengetahui apa yang seharusnya dilakukan oleh perangkat lunak mereka dan secara otomatis membandingkan apa yang sebenarnya dilakukannya. Memungkinkan Anda menulis tes yang mudah dibaca dan mudah dirawat. Kegiatan ini dikenal dengan tes akhir atau tes penerimaan. Ini membutuhkan input data uji penerimaan dan sistem terintegrasi yang dibuat selama kegiatan ini. Pengujian akan dilakukan oleh beberapa anggota atau departemen pengguna, atau bahkan departemen kontrol kualitas independen. Penting untuk dicatat bahwa penting untuk melakukan kegiatan pengendalian kualitas di setiap kegiatan analitis, desain dan implementasi sebelumnya untuk memastikan bahwa kegiatan tersebut telah dilakukan pada tingkat kualitas yang sesuai. Ini memastikan bahwa analis menghasilkan spesifikasi kualitas, desainer menghasilkan desain berkualitas, dan programmer menghasilkan program pengkodean berkualitas. Dalam ilmu komputer, implementasi adalah spesifikasi teknis atau algoritma, seperti program, komponen perangkat lunak, atau sistem komputer lainnya. Banyak implementasi disediakan sesuai dengan spesifikasi atau standar. Kami merangkum pekerjaan penulis sebelumnya untuk mendapatkan tujuan pengujian, yang merupakan titik awal untuk mengembangkan pengujian otomatis. Dalam konteks pengujian sistem dari kasus penggunaan, tujuan pengujian dapat dinyatakan sebagai kasus penggunaan. Skenario ini akan terdiri dari urutan langkah tanpa alternatif yang memungkinkan dan serangkaian nilai pengujian, dan prasyarat dan pasca-konferensi terkait dengan skenario ini. Untuk menghasilkan skenario pengujian, pertama, diagram aktivitas dibangun dari urutan utama dan urutan kesalahan dan alternatif dari use case. Dalam diagram aktivitas, tindakan yang dilakukan oleh sistem dan tindakan yang dilakukan oleh peserta distereotipkan. Analisis jalur kemudian dilakukan dan setiap jalur diagram aktivitas akan menjadi skenario kasus penggunaan dan oleh karena itu menjadi target pengujian potensial. 2 Implementasi pengujian sistem. Arsitektur pengujian sistem. Arsitektur untuk mengeksekusi dan memvalidasi pengujian sistem secara otomatis ditunjukkan pada Gambar 7. Arsitektur ini mirip dengan arsitektur yang diperlukan untuk mengotomatisasi jenis pengujian lainnya, seperti pengujian unit. Perbedaan utama adalah bahwa dalam pengujian unit, pengujian itu sendiri memanggil kode yang dapat dieksekusi, sedangkan pengujian fungsional sistem pengujian dan penerimaan pengujian 27 memerlukan perantara yang mengetahui cara memanipulasi antarmuka eksternalnya. Implementasi kasus uji. Sebuah tes-tes adalah realisasi dari tujuan pengujian. Perilaku umum untuk kasus uji tercantum dalam tabel Perilaku Kasus Uji Umum. Setiap kasus penggunaan akan dikaitkan dengan rangkaian pengujian. Suite ini akan berisi pengujian untuk semua skenario kasus penggunaan yang disebutkan. Seperti dapat dilihat dari tujuan pengujian, setiap langkah harus ditentukan apakah itu dilakukan oleh aktor atau oleh sistem yang diuji. Informasi ini sangat relevan saat mengkode metode pengujian paket. Semua tindakan yang dilakukan oleh aktor mengubah kode kode uji menjadi interaksi antara kasus uji dan sistem. Pengujian Sistem dan Pengujian Penerimaan 29 Metodologi variabel operasional dan kategori akan diterapkan untuk menentukan nilai pengujian yang diperlukan. Tiga telah diidentifikasi berbagai jenis variabel operasional. Setiap jenis akan diimplementasikan secara berbeda dalam kasus uji. Tipe pertama terdiri dari variabel operasional yang menunjukkan transfer informasi ke sistem oleh entitas eksternal. Untuk setiap variabel jenis ini, kelas baru akan ditentukan, yang objeknya akan berisi nilai pengujian yang berbeda untuk variabel ini. Contoh variabel jenis pekerjaan ini ditunjukkan dalam studi kasus. Tipe kedua terdiri dari variabel-variabel operasional yang menunjukkan pilihan di antara beberapa opsi yang tersedia bagi aktor eksternal. Sebaliknya, pilihan seperti itu akan diimplementasikan secara langsung sebagai bagian dari kode yang mengimplementasikan interaksi antara aktor dan sistem. Tipe ketiga terdiri dari variabel operasi yang menunjukkan keadaan sistem. Untuk menerapkan metode penyiapan kasus uji, tulis kode yang diperlukan untuk menetapkan dengan benar nilai variabel operasional yang menjelaskan status sistem, atau untuk memverifikasi bahwa nilainya cocok. Demikian pula, metode break harus mengembalikan nilai-nilai ini ke keadaan semula. Selain itu, metode pelacakan harus mengecualikan, jika perlu, informasi yang dimasukkan oleh kasus uji ke dalam sistem selama pelaksanaan kasus uji. Beberapa contoh variabel operasional jenis ini ditunjukkan dalam studi kasus. Dalam hal ini, hal pertama yang harus dilakukan adalah menerapkan apa yang dilihat untuk mendapatkan kumpulan tujuan pengujian dari use case. Karakteristik dari test harness yang digunakan kemudian ditentukan. Akhirnya, kami menerapkan apa yang kami lihat di bagian sebelumnya untuk mengimplementasikan test case dari target test. Sistem yang sedang diuji artefak diidentifikasi pada bahasa Inggris, sejauh bahasa Spanyol tidak didukung oleh alat yang digunakan. Use case pada Tabel 2 menjelaskan pengenalan link baru dalam sistem. Sebagai tambahan, persyaratan untuk menyimpan informasi yang menjelaskan informasi yang ditangani oleh setiap tautan juga ditampilkan. Dari use case dan secara otomatis dihasilkan sekumpulan skenario yang akan menjadi target pengujian use case tersebut. Mempertimbangkan bahwa use case memiliki loop tak terbatas dengan jumlah pengulangan potensial yang tak terbatas, kriteria cakupan yang dipilih untuk memperoleh jalan adalah kriteria 01, yang memeriksa dan menguji pengujian sistem 30, terdiri dari perolehan semua jalur yang mungkin untuk tidak mengulangi satu atau satu kali jalan. masing-masing loop. Semua skrip yang diperoleh dengan menggunakan kriteria ini dan diterjemahkan ke dalam bahasa Spanyol tercantum dalam tabel. Untuk studi kasus ini, kami telah memilih Skenario 09, yang dirinci dalam Tabel 5 untuk implementasinya. Pengujian dan Pengujian dalam Pengujian 31 Tabel Persyaratan Informasi untuk referensi. Anda juga dapat menerapkan metode pemisahan kategori. Bagian untuk masing-masing variabel ini tercantum dalam tabel. Pengujian dan Pengujian Sistem 32 Tabel variabel yang ditentukan untuk use case. Pengujian dan Pengujian dalam Pengujian 33 Tabel kategori untuk variabel yang diidentifikasi. Seperti yang dijelaskan pada Gambar 7, uji harness dirancang untuk mensimulasikan perilaku pengguna dan menawarkan serangkaian pernyataan untuk mengevaluasi hasilnya. Terjemahan ini saat ini dilakukan secara manual dan ditampilkan dalam tabel. Pengujian dan Pengujian Transceiver 35 Gambar Implementasi kasus uji. Terjemahan ke kode yang dapat dieksekusi dari langkah-langkah yang dilakukan oleh pengguna dalam skenario utama. Yaitu, untuk memastikan bahwa kategori ada dan tidak ada keadaan yang menyebabkan kesalahan saat memulihkan kategori atau memasukkan tautan baru. Implementasi dari metode break adalah untuk mengembalikan kumpulan link asli yang tersimpan dalam sistem. 2 Pelaksanaan tes penerimaan. Tes penerimaan hanya bekerja dengan dukungan pelanggan, atau setidaknya proxy bagi pelanggan untuk menentukan kriteria. Tanpa kriteria penerimaan driver, menjadi sulit untuk memeriksa apakah Anda sedang membangun perangkat lunak yang tepat. Klien, bersama dengan semua anggota tim pengembangan, harus bersama-sama mendefinisikan sistem dalam rangkaian "skrip" yang menjelaskan apa yang harus dilakukan sistem dan bagaimana seharusnya melakukannya. Dengan membuat pengujian dengan persyaratan dan kriteria persetujuan yang jelas, perangkat lunak lebih mungkin memenuhi harapan pelanggan. Namun, ini berarti bahwa seseorang secara manual memeriksa apakah persyaratan terpenuhi dan aplikasi berfungsi seperti yang diharapkan. Di sinilah tes penerimaan otomatis masuk alih-alih persyaratan dalam dokumen lawas, persyaratan didefinisikan sebagai contoh dan skenario, dilindungi dalam kontrol sumber dengan artefak penerapan, dan dapat dijalankan kapan saja untuk memeriksa apakah memenuhi persyaratan dan berfungsi dengan benar. Anda dapat menggunakan pendekatan yang sama untuk menulis tes, tetapi alih-alih mengetiknya ke dalam perangkat lunak manajemen kasus pengujian atau spreadsheet, tulislah langsung ke dalam kode. Pengujian dan Pengujian Sistem 37 1 Pengujian penerimaan otomatis. Oleh karena itu, langkah pertama dalam penerapan fungsi baru apa pun adalah menggambarkan harapan Anda dengan sebuah tes. Lainnya tidak, dan menemukan diri mereka berjuang dengan kontrol proses dari waktu ke waktu, terutama sebagai bukti tumbuh dan fleksibilitas pengujian mulai memburuk. Pendekatan test-driven didasarkan pada tes mana yang harus memandu pengembangan produk perangkat lunak. Dalam produk perangkat lunak industri, ketika metode rekayasa persyaratan digunakan, sebagian besar didukung oleh bahasa alami, yang menimbulkan ketidaknyamanan ambiguitas yang terkenal. Namun, kebutuhan untuk validasi mungkin lebih besar daripada manfaat yang dapat ditawarkan oleh spesifikasi persyaratan yang lebih formal dan ketat. Klien harus dapat membaca dan memahami persyaratan agar dapat menyetujuinya. Metode paling populer untuk mendefinisikan persyaratan tercantum di bagian Kasus Penggunaan dan Cerita Pengguna. Untuk menentukan persyaratan adalah kunci untuk menarik pelanggan. Persyaratan - tujuan pencapaian, yaitu apa yang diharapkan klien dari produk perangkat lunak. Pengujian dan Pengujian Sistem 38 peran yang terkait dengan spesifikasi persyaratan dan validasi serta pengujian penerimaan. Konsep persyaratan menjadi Wadah Tes Penerimaan, dan inilah yang menjadi pusat perhatian sebagai spesifikasi setiap persyaratan. Pertimbangkan persyaratan "Tarik uang" dalam konteks ATM. Spesifikasi deskriptif yang khas mungkin sebagai berikut: Pelanggan harus dapat menarik uang tunai dari kasir dalam jumlah yang dipilih. Selalu dapatkan tanda terima jika kasir tidak memiliki kertas tersisa. Ketika datang ke Klien Pilihan, Anda dapat menarik uang lebih daripada yang Anda miliki di akun Anda, tetapi Anda harus diperingatkan bahwa Anda akan dikenakan biaya persentase. Klien harus dapat membatalkan kapan saja sebelum mengonfirmasi penarikan. Jumlah tersebut harus dapat dilayani oleh rekening yang dimiliki kasir pada saat itu, dan jumlah lainnya tidak boleh diterima. Gambar - Alternatif Spesifikasi Gambar 10 menunjukkan beberapa alternatif spesifikasi untuk kebutuhan ini. Ikon mencerminkan kenyamanan setiap spesifikasi. Mungkin menarik untuk mengembangkan diagram urutan untuk mendefinisikan setiap skenario untuk memenuhi persyaratan, namun, secara umum, ini tidak cocok karena jumlah yang besar diagram yang dihasilkan. Lebih menarik untuk mengidentifikasi skenario daripada menggambarkan masing-masing dalam diagram. Deskripsi naratif bukan hanya sekali, setidaknya untuk definisi singkat persyaratan, yang berfokus pada pendefinisian konsep yang terlibat. Namun, model penggunaan tidak cocok untuk menggambarkan struktur persyaratan rinci produk perangkat lunak dalam lingkungan pemeliharaan jangka panjang karena produk perangkat lunak rata-rata dapat memiliki ribuan persyaratan. Mekanisme yang lebih tepat diperlukan untuk memvisualisasikan dan mengelola banyak persyaratan. Template adalah salah satu alternatif yang paling umum digunakan untuk use case. Templatenya elegan dan memberikan kesan keteraturan pada spesifikasi. Namun, mereka umumnya kontra-produktif karena mereka cenderung menyediakan satu tingkat pemrosesan detail untuk semua persyaratan. Dalam kasus yang sangat sederhana ini, mereka menyertakan hal-hal yang jelas atau tidak relevan hanya untuk menutupi semua bagian template. Saat persyaratan menyertakan beberapa skrip, mencoba mensintesis semua skrip dalam template biasanya menghasilkan spesifikasi yang membingungkan. Dengan cara ini, persyaratan bertindak sebagai wadah bagi negara. Tergantung pada kebutuhan, bentuk spesifikasi tambahan lainnya mungkin berguna. Misalnya, diagram aktivitas jika perilaku yang terkait dengan persyaratan memiliki simbol algoritmik, atau diagram status jika perilaku mencakup tindakan yang mengaktifkan atau menonaktifkan menurut asersi sistem dan pengujian penerimaan sistem. Prasyarat penting adalah pragmatisme sehubungan dengan spesifikasi, yang tidak menghalangi berbagi alternatif spesifikasi, tetapi kriteria utama harus keinginan untuk menjadi menguntungkan dan berkontribusi pada pemeliharaan spesifikasi itu. Di sisi lain, dalam hal upaya untuk pemeliharaan, terutama dalam hal konsistensi, penting untuk tidak menggunakan duplikasi atau duplikasi spesifikasi secara berlebihan dalam cara yang berbeda perwakilan. Grafik berarah adalah representasi yang memadai untuk penyempurnaan level. Grafik ini memungkinkan Anda untuk memvisualisasikan hubungan dekomposisi dan ketergantungan antara persyaratan. Dengan demikian, setiap node adalah kebutuhan fungsional atau non-fungsional. Busur antara node membangun hubungan antara orang tua dan anak-anak, atau hubungan ketergantungan "node yang mempengaruhi node". Jadi, dalam contoh di atas, persyaratan "Tarik uang" dapat menjadi simpul dari struktur persyaratan. Kembali dengan jumlah yang dimasukkan oleh pelanggan. Tidak ada tiket yang tersedia. Tidak ada kertas untuk diterima. Waktu komunikasi dengan sistem pusat telah terlampaui. Pemberitahuan operasi internal kasir. Waktu habis untuk memulai tindakan. Ini mungkin terkait dengan persyaratan fungsional atau persyaratan non-fungsional. Ini opsional dan digunakan untuk mengatur prasyarat sebelum menerapkan langkah-langkah pengujian. Ini adalah tindakan interaksi aktor dengan sistem. Ketika mereka melakukan beberapa tindakan, mereka dapat ditempatkan pada daftar bernomor. Ini adalah efek dari interaksi aktor. Setiap tindakan dapat menyebabkan satu atau lebih hasil. Sangat penting bahwa ketika datang ke pesan ke pengguna, teks disertakan sebagai bagian dari output yang diharapkan, sehingga programmer sudah memiliki informasi ini diverifikasi dengan klien. Ini, seperti yang akan kami tunjukkan di bawah, akan membangun ketergantungan antara persyaratan. Kondisi Harus klien normal. Langkah Cobalah untuk mengembalikan uang pelanggan normal dan meminta jumlah yang melebihi saldo. Hasil yang diharapkan. Pengujian dan Penerimaan Sistem 42 Pesan "Jumlah yang diminta melebihi saldo Anda saat ini, masukkan kembali jumlahnya" ditampilkan dan kembali ke jendela untuk memasukkan jumlahnya. Pengujian penerimaan akan membantu mengonfirmasi bahwa Anda sedang membangun aplikasi yang diinginkan klien, sementara mengotomatiskan skrip ini memungkinkan Anda untuk terus menguji aplikasi selama proses pengembangan dan menggunakannya sebagai bagian dari rangkaian pengujian regresi untuk memastikan bahwa perubahan di masa mendatang tidak merusak saat ini yang. persyaratan. Namun, memiliki klien yang terkait dengan kompilasi bukti, terutama pengujian otomatis, menghadirkan sejumlah masalah potensial. Klien, pada umumnya, bersifat non-teknis dan cenderung menjauhkan diri dari pengembangan perangkat lunak itu sendiri. Klien dapat memberikan data dan contoh, sementara penguji atau pengembang dapat dengan cepat membuat kode skrip dan spesifikasi yang dapat dieksekusi. Tes Penerimaan Antarmuka Pengguna Dalam contoh, tes penerimaan berfokus pada logika bisnis dan objek domain untuk melihat apakah logika bekerja dengan sukses. Tapi bagaimana dengan bagaimana pengguna berinteraksi dengan aplikasi? Tes penerimaan ini harus ada untuk menguji kebenaran logika dari sudut pandang pengguna, dan sudut pandang pengguna adalah antarmuka pengguna. Jika aplikasi memiliki pemisahan yang baik dan pemisahan logika yang baik dari kode UI, hal ini akan mempermudah penerapan pengujian. Jika Anda menguji pada level ini, pengujian tidak akan berubah di antarmuka pengguna. Meskipun pengujian harus berfokus hanya pada logika, ini tidak berarti bahwa Anda tidak boleh lulus pengujian penerimaan di seluruh antarmuka pengguna. Saya suka memiliki serangkaian tes asap yang ditujukan untuk antarmuka pengguna dasar" jalan bahagia". Mereka fokus pada bagian aplikasi yang paling mungkin digunakan pengguna untuk mendapatkan hasil maksimal dari pengalaman mereka. kuantitas paling sedikit pengujian. Jika Anda mencoba untuk menutupi semuanya kemungkinan cara dan penggunaan UI, dan jika UI berubah, Anda harus mengubah semua pengujian. Misalnya, jika Anda menguji antarmuka pengguna untuk situs e-niaga, jalan akan dengan senang hati memilih item, menambahkannya ke troli, memeriksanya, dan melihat konfirmasi pembelian. Jika skenario ini gagal, Anda benar-benar ingin mencari tahu secepatnya. Untuk aplikasi tertentu, bergantung pada kompleksitas dan masa pakai, Anda mungkin ingin melakukan lebih banyak uji penerimaan di UI untuk memastikan Anda lebih percaya diri pada lapisan UI. Namun, pengujian UI yang berhasil adalah pertanyaan yang sulit dan saya tidak punya ruang untuk menutupinya. Pengujian dan penerimaan sistem 43 3Pengujian cerdas. Setelah Anda menceritakan cerita dan skrip dalam format yang jelas dan mudah dipahami, langkah selanjutnya adalah mengotomatiskan cerita dan skrip. Ini memungkinkan mereka untuk berjalan selama pengembangan untuk melacak kemajuan dan menangkap bug regresi. Kesimpulan dan rekomendasi. Di sisi lain, kami memiliki pengujian sistem yang bertanggung jawab untuk mengevaluasi operasi selama proses, untuk mendeteksi kesalahan yang mungkin terjadi untuk ini, perlu untuk mengembangkan strategi dengan pengujian dan pengembangan kode terpisah dari pengembangan antarmuka, sehingga yang terbaik adalah mengimplementasikan pengujian sistem. Implementasi kedua pengujian perangkat lunak ini harus dilakukan dengan pengujian ketat yang memenuhi standar tertentu dan dengan koordinasi pemangku kepentingan yang terlibat dalam pengembangan sistem. Pengujian dan Penerimaan Sistem 44 Daftar Pustaka 1. Isabelle Ramos Roman, José Javier Dolado Cosin. Metode manajemen kuantitatif dalam pengembangan perangkat lunak. Alonso Amo, Loic Martinez Normand. Pengantar pengembangan perangkat lunak. Pengujian Sistem dan Pengujian Penerimaan 45 8. -Jurusan Bahasa dan Sistem Komputer. Struktural analisa sistem. Metode identifikasi bakteri di laboratorium mikrobiologi.