Apa itu tes unit, tes integrasi, tes asap, dan tes regresi?


732

Apa itu tes unit, tes integrasi, tes asap, dan tes regresi? Apa perbedaan di antara mereka dan alat apa yang dapat saya gunakan untuk masing-masing?

Sebagai contoh, saya menggunakan JUnit dan NUnit untuk pengujian unit dan pengujian integrasi . Apakah ada alat untuk dua tes terakhir, tes asap atau uji regresi ?



1
Yang lain sudah menjawab dengan baik, tetapi saya ingin menambahkan bahwa saya secara pribadi berpikir bahwa Tes Asap dan Uji Regresi berlebihan. Mereka melakukan hal yang sama: menguji untuk memastikan bahwa perubahan pada sistem tidak merusak apa pun.
Randolpho

15
Saya pikir mereka sangat berbeda dengan tes regresi. Saya pikir mereka dengan sengaja tes cepat 'ringan' yang dijalankan di awal untuk menghemat waktu karena jika salah satu dari ini gagal maka Anda tahu itu tidak layak repot dengan pengujian tambahan. mis. Bisakah klien terhubung ke database, apakah .net diinstal, adalah versi yang benar diinstal ... Anda mungkin juga memiliki pra-penempatan (kami meningkatkan dari v1 ke v1.1, jadi periksa apakah v1 diinstal) dan post- tes asap penyebaran.
AndyM

Tes asap seperti yang dijelaskan AndyM. Tetapi mereka juga merupakan jenis uji regresi.
kevin mcdonnell

Jawaban:


1044
  • Uji unit : Tentukan dan uji satu poin dari kontrak metode tunggal kelas. Ini harus memiliki cakupan yang sangat sempit dan terdefinisi dengan baik. Ketergantungan dan interaksi yang kompleks dengan dunia luar dihilangkan atau diejek .

  • Tes integrasi : Uji antar operasi yang benar dari beberapa subsistem. Ada seluruh spektrum di sana, dari pengujian integrasi antara dua kelas, hingga pengujian integrasi dengan lingkungan produksi.

  • Uji asap (alias pemeriksaan kewarasan ) : Tes integrasi sederhana di mana kami hanya memeriksa bahwa ketika sistem yang diuji dipanggil kembali normal dan tidak meledak.

    • Pengujian asap adalah analogi dengan elektronik, di mana tes pertama terjadi ketika menyalakan sebuah sirkuit (jika merokok, itu buruk!) ...
    • ... dan, tampaknya , dengan pipa ledeng , di mana sistem pipa secara harfiah diisi oleh asap dan kemudian diperiksa secara visual. Jika ada yang merokok, sistemnya bocor.
  • Tes regresi : Tes yang ditulis ketika bug diperbaiki. Ini memastikan bahwa bug khusus ini tidak akan muncul lagi. Nama lengkapnya adalah "tes non-regresi". Ini juga bisa menjadi tes yang dilakukan sebelum mengubah aplikasi untuk memastikan aplikasi memberikan hasil yang sama.

Untuk ini, saya akan menambahkan:

  • Tes penerimaan : Uji bahwa fitur atau use case diimplementasikan dengan benar. Ini mirip dengan tes integrasi, tetapi dengan fokus pada use case untuk menyediakan daripada pada komponen yang terlibat.

  • Sistem tes : Tes sistem sebagai kotak hitam. Ketergantungan pada sistem lain sering diejek atau dilumpuhkan selama pengujian (jika tidak akan lebih dari tes integrasi).

  • Pemeriksaan pra-penerbangan : Tes yang diulang dalam lingkungan seperti produksi, untuk mengurangi sindrom 'membangun di mesin saya'. Seringkali ini diwujudkan dengan melakukan tes penerimaan atau merokok di lingkungan seperti produksi.


250
Pengujian asap mendahului elektronik satu abad dan berasal dari pipa ledeng, ketika sistem pipa diisi oleh asap aktual dan kemudian diperiksa secara visual. Jika merokok, itu bocor.
SnakE

2
Tes regresi juga digunakan untuk perubahan fitur, bukan hanya perbaikan bug. Jawaban Nikita di bawah adalah definisi yang lebih komprehensif.
BobRodes

25
@AndyM Latar belakang 'Tes asap' tidak akurat. IIRC berasal dari pipa ledeng, tempat asap dipompa ke dalam sistem pipa setelah dibangun (dan sebelum dihubungkan ke sumber air). Jika ada asap yang keluar, pipa-pipa itu tidak ditutup dengan benar. Ini kurang merusak daripada benar-benar membiarkan air mengalir dan melihat apakah ada genangan air (mungkin merusak dinding / batu dalam proses tersebut). Ini perkiraan kasar bahwa sistem tidak akan gagal serempak. Proses dev mungkin: "Membangun" berlalu? => "Uji asap" lulus? => "Tes penerimaan" lulus => ke tim QA untuk pengujian terperinci.
Cristian Diaconescu

4
Saya percaya Anda membuat kesalahan dengan menyatakan bahwa "Tes Regresi" benar-benar singkatan dari "Tes Non-Regresi"? Saya skeptis, sebagian karena itu hanya tidak intuitif dan membingungkan (walaupun ada banyak istilah yang), tetapi juga Wikipedia memiliki dua artikel terpisah tentang Tes Regresi dan Non-Regresi. Artikel tentang pengujian Regresi bahkan mengatakan: Kontras dengan pengujian non-regresi ... yang bertujuan untuk memverifikasi apakah, setelah memperkenalkan atau memperbarui aplikasi perangkat lunak yang diberikan, perubahan tersebut memiliki efek yang diinginkan.
Brian C

2
@dada Sanity testing dan pengujian asap tidak sama. Pengujian kewarasan dilakukan setelah bangunan telah menghapus tes Asap dan telah diterima oleh tim QA untuk pengujian lebih lanjut, pengujian kewarasan memeriksa fungsi utama dengan rincian yang lebih baik.
Bharat

105
  • Uji unit : tes otomatis untuk menguji kerja internal suatu kelas. Itu harus menjadi tes yang berdiri sendiri yang tidak terkait dengan sumber daya lainnya.
  • Tes integrasi : tes otomatis yang dilakukan pada lingkungan, sangat mirip dengan tes unit tetapi dengan sumber daya eksternal (db, akses disk)
  • Uji regresi : setelah menerapkan fitur baru atau perbaikan bug, Anda menguji kembali skenario yang berfungsi di masa lalu. Di sini Anda membahas kemungkinan fitur baru Anda memecah fitur yang ada.
  • Pengujian asap : tes pertama yang dapat disimpulkan oleh penguji jika mereka akan melanjutkan pengujian.

2
Definisi uji regresi tidak benar-benar persis seperti itu. @dada mendefinisikannya dengan benar.
Robert Koritnik

Definisi Tes Integrasi jelas kabur. Misalnya pada jawaban di sini stackoverflow.com/a/4904533/32453 lebih didefinisikan sebagai pengujian beberapa interaksi kode Anda, tidak perlu membutuhkan DB nyata (sumber daya eksternal) ... meskipun beberapa orang mendefinisikannya dengan cara yang telah Anda jelaskan ... ahh terminologi. (Saya agak lebih suka definisi sebelumnya, FWIW, menguji beberapa interaksi.)
rogerdpack

Silakan lihat pertanyaan saya: stackoverflow.com/questions/61711739/…
milad salimi

Itu menjawab judul, tetapi bukan yang tentang alat untuk dua jenis tes terakhir, untuk pengujian asap atau pengujian regresi .
Peter Mortensen

90

Setiap orang akan memiliki definisi yang sedikit berbeda, dan seringkali ada area abu-abu. Namun:

  • Uji unit: apakah ini sedikit (selebar mungkin) bekerja?
  • Tes integrasi: apakah kedua komponen ini (atau lebih) bekerja bersama?
  • Uji asap: apakah seluruh sistem ini (sedekat mungkin dengan sistem produksi) saling menempel dengan cukup baik? (Yaitu apakah kita cukup yakin itu tidak akan membuat lubang hitam?)
  • Tes regresi: apakah kita secara tidak sengaja memperkenalkan kembali bug yang sebelumnya telah kita perbaiki?

Bagaimana Anda menempatkan tes integrasi Anda sehubungan dengan tes unit? Jika myprj direktori proyek utama, dan mypkgterletak di bawah myprj, saya memiliki unit test yang terletak di bawah myprj/tests/test_module1.py, dan paket saya berada di bawah myprj/mypkg. Ini berfungsi baik untuk pengujian unit, tetapi saya bertanya-tanya apakah ada konvensi, saya harus mengikuti di mana tes integrasi harus berada?
alpha_989

1
@ alpha_989: Saya tidak tahu seperti apa konvensi untuk Python. Di .NET saya saat ini memiliki kode produksi, pengujian unit, dan tes integrasi dalam tiga proyek terpisah, satu sama lain - tetapi ada banyak alternatif juga.
Jon Skeet

Ok terima kasih. Saya dapat menemukan rekomendasi standar selain melihat proyek python lain. tapi saya akan mengikuti Anda ..
alpha_989

Silakan lihat pertanyaan saya: stackoverflow.com/questions/61711739/…
milad salimi

@miladsalimi: Tolong jangan tambahkan komentar yang tidak terkait hanya untuk mendapatkan perhatian untuk pertanyaan lain. Saya melihat Anda telah melakukannya pada empat posting lain - tolong jangan.
Jon Skeet

51

Kategori tes baru yang baru saya sadari adalah tes kenari . Tes kenari adalah tes otomatis, non-destruktif yang dijalankan secara teratur di lingkungan hidup , sehingga jika pernah gagal, sesuatu yang sangat buruk telah terjadi.

Contohnya mungkin:

  • Apakah data yang seharusnya hanya tersedia dalam pengembangan / testy muncul langsung ?
  • Apakah proses latar belakang gagal dijalankan?
  • Bisakah seorang pengguna masuk?

2
Bisakah situs di-ping sama sekali - cukup sesuai, layanan yang disebut Binary Canary ada.
Dan Dascalescu

15
Nama ini berasal dari penambangan batubara: bawa kenari "down t'pit". Saat dihabisi, keluarlah dengan cepat. Burung kenari sangat sensitif terhadap konsentrasi kecil gas beracun dan akan mati sebelum tingkat konsentrasi menjadi beracun bagi manusia. Jika tes Canary gagal, perbaiki dengan cepat karena itu hanya masalah waktu sebelum LIVE gagal.
Robino

1
Cara kami menggunakan pengujian Canary di pekerjaan saya adalah pertama-tama menggeser beberapa pelanggan ke versi baru, daripada semuanya sekaligus. Jika beberapa pelanggan pertama bertahan, kami dapat menambahkan sisanya. Beberapa yang pertama adalah burung kenari.
00prometheus

2
@ 00prometheus, itu pengujian beta.
GregNash

1
@ HarveyLin, meskipun tes Canary selalu merupakan tes yang mencegah bencana, tentu saja itu tidak hanya digunakan dengan cara ini. Tetapi aturan praktisnya adalah "tes ini berfungsi karena itu IS kritis". Tentu saja, setiap tes memiliki tujuan yang hampir sama, tetapi konsepnya sangat spesifik. Dalam kasus Anda, saya tidak akan menghitung semua tes sebagai tes Canary.
Charles Roberto Canato

12

Jawaban dari salah satu situs web terbaik untuk teknik pengujian perangkat lunak:

Jenis pengujian perangkat lunak - daftar lengkap klik di sini

Masukkan deskripsi gambar di sini

Deskripsi yang cukup panjang, dan saya tidak akan menempelkannya di sini: tetapi mungkin bermanfaat bagi seseorang yang ingin mengetahui semua teknik pengujian.


10

Uji unit: Memverifikasi bahwa komponen tertentu (yaitu, kelas) membuat atau memodifikasi fungsi yang dirancang. Tes ini dapat dilakukan secara manual atau otomatis, tetapi tidak bergerak melampaui batas komponen.

Tes integrasi: Memverifikasi bahwa interaksi fungsi komponen tertentu seperti yang dirancang. Tes integrasi dapat dilakukan pada level unit atau level sistem. Tes ini dapat dilakukan secara manual atau otomatis.

Uji regresi: Memverifikasi bahwa cacat baru tidak dimasukkan ke dalam kode yang ada. Tes ini dapat dilakukan secara manual atau otomatis.

Tergantung pada SDLC Anda ( air terjun , RUP , lincah , dll) tes tertentu dapat dilakukan dalam 'fase' atau mungkin semua dilakukan, lebih atau kurang, pada saat yang sama. Misalnya, pengujian unit mungkin terbatas pada pengembang yang kemudian menyerahkan kode tersebut kepada penguji untuk pengujian integrasi dan regresi. Namun, pendekatan lain mungkin memiliki pengembang melakukan pengujian unit dan beberapa tingkat integrasi dan pengujian regresi (menggunakan pendekatan TDD bersama dengan integrasi berkesinambungan dan unit otomatis dan tes regresi).

Set alat akan sangat tergantung pada basis kode, tetapi ada banyak alat open source untuk pengujian unit (JUnit). HP (Mercury) QTP atau Borland's Silk Test keduanya merupakan alat untuk integrasi otomatis dan pengujian regresi.


Ini adalah salah satu dari sedikit jawaban yang mencakup sesuatu tentang alat.
Peter Mortensen

8

Uji unit : pengujian modul individu atau komponen independen dalam suatu aplikasi dikenal sebagai pengujian unit. Pengujian unit akan dilakukan oleh pengembang.

Tes integrasi : menggabungkan semua modul dan menguji aplikasi untuk memverifikasi komunikasi dan aliran data antara modul bekerja dengan baik atau tidak. Pengujian ini juga dilakukan oleh pengembang.

Tes asap Dalam tes asap mereka memeriksa aplikasi secara dangkal dan lebar. Dalam pengujian asap, mereka memeriksa fungsi utama aplikasi. Jika ada masalah pemblokir dalam aplikasi mereka akan melaporkan ke tim pengembang, dan tim pengembang akan memperbaikinya dan memperbaiki cacat, dan mengembalikannya ke tim pengujian. Sekarang tim pengujian akan memeriksa semua modul untuk memverifikasi bahwa perubahan yang dibuat dalam satu modul akan berdampak pada modul lainnya atau tidak. Dalam pengujian asap , kasus uji dituliskan.

Pengujian regresi yang menjalankan kasus pengujian yang sama berulang kali untuk memastikan bahwa modul yang tidak berubah tidak menyebabkan cacat. Pengujian regresi dilakukan di bawah pengujian fungsional


Itu menjawab judul, tetapi bukan yang tentang alat untuk dua jenis tes terakhir, untuk pengujian asap atau pengujian regresi. Itu juga mengulangi jawaban sebelumnya - itu bisa dibuat unik dengan menjawab pertanyaan tentang alat.
Peter Mortensen

7

PENGUJIAN REGRESI-

"Tes regresi menjalankan kembali tes sebelumnya terhadap perangkat lunak yang diubah untuk memastikan bahwa perubahan yang dibuat pada perangkat lunak saat ini tidak mempengaruhi fungsi perangkat lunak yang ada."


18
Anda mengutip dari mana?
Daryl

4
Menurut halaman ini , kutipan itu berasal dari artikel Wikipedia "Pengujian perangkat lunak" meskipun tampaknya bagian itu telah berubah di beberapa titik sejak 2010.
Zach Lysobey

Bagaimanapun, WP bukan sumber yang valid. Sumber yang dirujuk mungkin ada yang valid. Tidak ada sumber valid yang dirujuk dalam WP, baik di artikel maupun di halaman diskusi, yang akan mendukung klaim bahwa "non-" membuat perbedaan. Saya membandingkan cuplikan teks dalam daftar hasil dari pencarian di Google Buku untuk keduanya "regression test"dan "non-regression test". Itu sama.
Rainald62

Itu menjawab (bagian dari) judul, tetapi bukan yang tentang alat untuk dua jenis tes terakhir, untuk pengujian asap atau pengujian regresi. Itu juga mengulangi jawaban sebelumnya - itu bisa dibuat unik dengan menjawab pertanyaan tentang alat.
Peter Mortensen

7

Saya hanya ingin menambahkan dan memberikan lebih banyak konteks tentang mengapa kita memiliki tingkat tes ini, apa yang sebenarnya mereka maksud dengan contoh

Mike Cohn dalam bukunya "Succeeding with Agile" muncul dengan "Testing Pyramid" sebagai cara untuk mendekati tes otomatis dalam proyek. Ada berbagai interpretasi dari model ini. Model ini menjelaskan jenis tes otomatis apa yang perlu dibuat, seberapa cepat mereka dapat memberikan umpan balik pada aplikasi yang sedang diuji dan siapa yang menulis tes ini. Pada dasarnya ada 3 level pengujian otomatis yang diperlukan untuk setiap proyek dan mereka adalah sebagai berikut.

Unit Tests - Ini menguji komponen terkecil dari aplikasi perangkat lunak Anda. Ini benar-benar bisa menjadi satu fungsi dalam kode yang menghitung nilai berdasarkan pada beberapa input. Fungsi ini adalah bagian dari beberapa fungsi lain dari basis kode perangkat keras / lunak yang menyusun aplikasi.

Misalnya - Mari kita ambil aplikasi kalkulator berbasis web. Komponen terkecil dari aplikasi ini yang perlu diuji unit dapat berupa fungsi yang melakukan penambahan, komponen lain yang melakukan pengurangan dan seterusnya. Semua fungsi kecil ini disatukan membuat aplikasi kalkulator.

Secara historis pengembang menulis tes ini karena biasanya ditulis dalam bahasa pemrograman yang sama dengan aplikasi perangkat lunak. Kerangka kerja pengujian unit seperti JUnit dan NUnit (untuk java), MSTest (untuk C # dan .NET) dan Jasmine / Mocha (untuk JavaScript) digunakan untuk tujuan ini.

Keuntungan terbesar dari unit test adalah, mereka berjalan sangat cepat di bawah UI dan kami bisa mendapatkan umpan balik cepat tentang aplikasi. Ini harus terdiri lebih dari 50% dari tes otomatis Anda.

API / Tes Integrasi - Ini menguji berbagai komponen sistem perangkat lunak secara bersamaan. Komponen-komponen tersebut dapat mencakup pengujian basis data, API (Application Programming Interface), alat dan layanan pihak ke-3 bersama dengan aplikasi.

Misalnya - Dalam contoh kalkulator kami di atas, aplikasi web dapat menggunakan database untuk menyimpan nilai, menggunakan API untuk melakukan beberapa validasi sisi server dan mungkin menggunakan alat / layanan pihak ketiga untuk mempublikasikan hasil ke cloud untuk membuatnya tersedia di berbagai platform.

Secara historis seorang pengembang atau QA teknis akan menulis tes ini menggunakan berbagai alat seperti tukang pos, SoapUI, JMeter dan alat-alat lain seperti Testim.

Ini berjalan jauh lebih cepat daripada tes UI karena masih berjalan di bawah tenda tetapi mungkin memakan waktu lebih sedikit daripada tes unit karena harus memeriksa komunikasi antara berbagai komponen independen dari sistem dan memastikan mereka memiliki integrasi yang mulus. Ini harus terdiri lebih dari 30% dari tes otomatis.

Tes UI- Akhirnya, kami memiliki tes yang memvalidasi UI aplikasi. Tes ini biasanya ditulis untuk menguji aliran ujung ke ujung melalui aplikasi.

Misalnya - Dalam aplikasi kalkulator, aliran ujung ke ujung dapat terjadi, membuka browser-> Memasukkan url aplikasi kalkulator -> Masuk dengan nama pengguna / kata sandi -> Membuka aplikasi kalkulator -> Melakukan beberapa operasi pada kalkulator -> memverifikasi hasil-hasil itu dari UI -> Keluar dari aplikasi. Ini bisa menjadi ujung ke ujung aliran yang akan menjadi kandidat yang bagus untuk otomatisasi UI.

Secara historis, QA teknis atau penguji manual menulis tes UI. Mereka menggunakan kerangka kerja open source seperti Selenium atau platform pengujian UI seperti Testim untuk membuat, menjalankan, dan memelihara pengujian. Tes-tes ini memberikan lebih banyak umpan balik visual karena Anda dapat melihat bagaimana tes berjalan, perbedaan antara hasil yang diharapkan dan hasil aktual melalui screenshot, log, laporan pengujian.

Batasan terbesar dari tes UI adalah, mereka relatif lambat dibandingkan dengan tes tingkat Unit dan API. Jadi, itu harus terdiri hanya 10-20% dari keseluruhan tes otomatis.

Dua jenis tes berikutnya dapat bervariasi berdasarkan proyek Anda tetapi idenya adalah-

Tes Asap

Ini bisa merupakan kombinasi dari 3 level pengujian di atas. Idenya adalah untuk menjalankannya selama setiap kode masuk dan memastikan fungsionalitas kritis dari sistem masih bekerja seperti yang diharapkan; setelah perubahan kode baru digabungkan. Mereka biasanya perlu berjalan dengan 5 - 10 menit untuk mendapatkan umpan balik yang lebih cepat tentang kegagalan

Tes Regresi

Mereka biasanya dijalankan setidaknya sekali sehari dan mencakup berbagai fungsi sistem. Mereka memastikan aplikasi masih berfungsi seperti yang diharapkan. Mereka lebih detail daripada tes asap dan mencakup lebih banyak skenario aplikasi termasuk yang tidak kritis.


Jawaban ini dapat dibuat lebih baik dengan menjawab pertanyaan tentang alat untuk pengujian asap atau pengujian regresi .
Peter Mortensen

5

Pengujian unit diarahkan pada bagian terkecil dari implementasi yang mungkin. Di Jawa ini berarti Anda menguji satu kelas. Jika kelas tergantung pada kelas lain, ini dipalsukan.

Ketika tes Anda memanggil lebih dari satu kelas, itu adalah tes integrasi .

Suite tes lengkap dapat memakan waktu lama untuk dijalankan, jadi setelah perubahan, banyak tim menjalankan tes cepat untuk menyelesaikan untuk mendeteksi kerusakan yang signifikan. Misalnya, Anda telah merusak URI menjadi sumber daya penting. Ini adalah tes asap .

Tes regresi dijalankan pada setiap bangunan dan memungkinkan Anda untuk melakukan refactor secara efektif dengan menangkap apa yang Anda hancurkan. Segala jenis tes dapat berupa uji regresi, tetapi saya menemukan unit test paling membantu menemukan sumber kesalahan.


Itu menjawab judul, tetapi bukan yang tentang alat untuk dua jenis tes terakhir, untuk pengujian asap atau pengujian regresi. Itu juga mengulangi jawaban sebelumnya - itu bisa dibuat unik dengan menjawab pertanyaan tentang alat.
Peter Mortensen

4
  • Pengujian integrasi: Pengujian integrasi adalah mengintegrasikan elemen lain
  • Pengujian asap: Pengujian asap juga dikenal sebagai pengujian versi bangun. Pengujian asap adalah proses pengujian awal yang dilakukan untuk memeriksa apakah perangkat lunak yang diuji siap / stabil untuk pengujian lebih lanjut.
  • Pengujian regresi: Pengujian regresi adalah pengujian berulang . Apakah perangkat lunak baru dipengaruhi dalam modul lain atau tidak.
  • Pengujian unit: Ini adalah pengujian kotak putih. Hanya pengembang yang terlibat di dalamnya

Itu menjawab judul, tetapi bukan yang tentang alat untuk dua jenis tes terakhir, untuk pengujian asap atau pengujian regresi. Itu juga mengulangi jawaban sebelumnya - itu bisa dibuat unik dengan menjawab pertanyaan tentang alat.
Peter Mortensen

2

Unit Testing: Selalu berkinerja oleh pengembang setelah pengembangannya dilakukan untuk mengetahui masalah dari sisi pengujian mereka sebelum mereka membuat persyaratan siap untuk QA.

Pengujian Integrasi: Ini berarti tester harus memverifikasi verifikasi modul ke sub modul ketika beberapa data / fungsi output drive ke satu modul ke modul lainnya. Atau di sistem Anda jika menggunakan alat pihak ketiga yang menggunakan data sistem Anda untuk diintegrasikan.

Pengujian Asap: penguji dilakukan untuk memverifikasi sistem untuk pengujian tingkat tinggi dan mencoba mencari tahu acara stopper bug sebelum perubahan atau kode ditayangkan.

Pengujian Regresi: Penguji melakukan regresi untuk verifikasi fungsi yang ada karena perubahan yang diterapkan dalam sistem untuk peningkatan baru atau perubahan dalam sistem.


Bukankah kita harus membuat tes sebelum melakukan pengembangan yang sebenarnya?
Vin Shahrdar

@ VinShahrdar, Apakah Anda berbicara tentang pengujian Unit?
Krunal

Iya. Saya biasanya membuat tes unit saya sebelum menulis kode produksi. Begitulah cara Anda seharusnya melakukannya, benar?
Vin Shahrdar

1
Ya .. Tapi pengujian unit juga dilakukan sebelum QA dihadapi oleh pengembang. Sebelum menyebarkan kode pada server QA, dev selalu melakukan pengujian unit
Krunal

2

Pengujian Unit

Pengujian unit biasanya dilakukan oleh pihak pengembang, sedangkan penguji sebagian berevolusi dalam jenis pengujian ini di mana pengujian dilakukan unit demi unit. Dalam Java JUnit test case juga dimungkinkan untuk menguji apakah kode tertulis dirancang dengan sempurna atau tidak.

Tes integrasi:

Jenis pengujian ini dimungkinkan setelah pengujian unit ketika semua / beberapa komponen terintegrasi. Jenis pengujian ini akan memastikan bahwa ketika komponen terintegrasi, apakah mereka mempengaruhi kemampuan atau fungsionalitas satu sama lain?

Pengujian Asap

Jenis pengujian ini dilakukan pada saat terakhir ketika sistem terintegrasi dengan sukses dan siap untuk masuk ke server produksi.

Jenis pengujian ini akan memastikan bahwa setiap fungsionalitas penting dari awal hingga akhir berfungsi dengan baik dan sistem siap digunakan pada server produksi.

Pengujian Regresi

Jenis pengujian ini penting untuk menguji bahwa cacat yang tidak diinginkan / tidak diinginkan tidak ada dalam sistem ketika pengembang memperbaiki beberapa masalah. Pengujian ini juga memastikan bahwa semua bug berhasil diselesaikan dan karena itu tidak ada masalah lain terjadi.


Itu menjawab judul, tetapi bukan yang tentang alat untuk dua jenis tes terakhir, untuk pengujian asap atau pengujian regresi. Itu juga mengulangi jawaban sebelumnya - itu bisa dibuat unik dengan menjawab pertanyaan tentang alat.
Peter Mortensen

2

Pengujian asap dan kewarasan keduanya dilakukan setelah perangkat lunak membangun untuk mengidentifikasi apakah akan memulai pengujian. Sanity mungkin atau mungkin tidak dilakukan setelah pengujian asap. Mereka dapat dieksekusi secara terpisah atau pada saat yang sama - kewarasan segera setelah merokok.

Karena tes kewarasan lebih mendalam dan membutuhkan lebih banyak waktu, dalam banyak kasus, layak untuk diotomatisasi.

Pengujian asap biasanya membutuhkan waktu tidak lebih dari 5-30 menit untuk dieksekusi. Ini lebih umum: memeriksa sejumlah kecil fungsi inti dari keseluruhan sistem, untuk memverifikasi bahwa stabilitas perangkat lunak cukup baik untuk pengujian lebih lanjut dan bahwa tidak ada masalah, menghalangi jalannya kasus uji yang direncanakan.

Pengujian kewarasan lebih rinci daripada asap dan dapat berlangsung dari 15 menit hingga satu hari penuh, tergantung pada skala bangunan baru. Ini adalah jenis pengujian penerimaan yang lebih khusus, dilakukan setelah progres atau pengujian ulang. Ini memeriksa fitur inti dari fungsionalitas baru tertentu dan / atau perbaikan bug bersama-sama dengan beberapa fitur yang berkaitan erat dengan mereka, untuk memverifikasi bahwa mereka berfungsi sebagai logika operasional yang diperlukan, sebelum pengujian regresi dapat dieksekusi pada skala yang lebih besar.


Ini agak rumit, tetapi bukan tentang alat untuk dua jenis tes terakhir, untuk pengujian asap atau pengujian regresi . Itu bisa dibuat unik dengan menjawab pertanyaan tentang alat.
Peter Mortensen

1

Sudah ada beberapa jawaban yang baik, tetapi saya ingin memperbaikinya lebih lanjut:

Pengujian unit adalah satu-satunya bentuk pengujian kotak putih di sini. Yang lainnya adalah pengujian kotak hitam. Pengujian kotak putih berarti Anda tahu inputnya; Anda tahu cara kerja mekanisme dan dapat memeriksanya dan Anda tahu hasilnya. Dengan pengujian kotak hitam, Anda hanya tahu apa inputnya dan apa output yang seharusnya.

Jadi jelas pengujian unit adalah satu-satunya pengujian kotak putih di sini.

  • Pengujian unit menguji potongan kode tertentu. Biasanya metode.
  • Tes pengujian integrasi apakah perangkat lunak fitur baru Anda dapat diintegrasikan dengan yang lainnya.
  • Pengujian regresi. Ini adalah pengujian yang dilakukan untuk memastikan Anda tidak merusak apa pun. Segala sesuatu yang digunakan untuk bekerja harus tetap berfungsi.
  • Pengujian asap dilakukan sebagai pengujian cepat untuk memastikan semuanya terlihat baik-baik saja sebelum Anda terlibat dalam pengujian yang lebih kuat.

5
Pengujian unit belum tentu kotak putih. Beberapa tes unit terbaik yang saya lihat pada dasarnya adalah contoh yang diambil dari persyaratan, yang menentukan hasil yang diharapkan secara independen dari konsep implementasi apa pun.
joel.neely

1
ditambahkan ke itu, tes unit Anda termasuk dalam tes regresi Anda sehingga tes regresi bukan tes kotak putih atau hitam. Saya akan mengatakan lebih jauh bahwa tes integrasi dan asap dapat berupa tes kotak putih atau kotak hitam.
Lieven Keersmaekers

1
Saya harus tidak setuju dengan ini. Pengujian implementasi pola desain adalah bentuk pengujian integrasi dan pengujian kotak putih.
Hazok

Itu menjawab judul, tetapi bukan yang tentang alat untuk dua jenis tes terakhir, untuk pengujian asap atau pengujian regresi . Itu juga mengulangi jawaban sebelumnya - itu bisa dibuat unik dengan menjawab pertanyaan tentang alat.
Peter Mortensen

1

Tes asap sudah dijelaskan di sini dan sederhana. Tes regresi datang di bawah tes integrasi.

Tes otomatis dapat dibagi menjadi dua.

Tes unit dan tes integrasi (ini yang terpenting)

Saya akan menyebutnya menggunakan frase "long test" (LT) untuk semua tes seperti tes integrasi, tes fungsional, tes regresi, tes UI, dll. Dan unit test sebagai "tes singkat".

Contoh LT dapat berupa, secara otomatis memuat halaman web, masuk ke akun dan membeli buku. Jika tes lulus, lebih mungkin berjalan di situs langsung dengan cara yang sama (maka referensi 'tidur yang lebih baik'). Long = jarak antara halaman web (mulai) dan basis data (akhir).

Dan ini adalah artikel yang bagus membahas manfaat pengujian integrasi (tes panjang) dibandingkan pengujian unit .


1

Tes regresi - Adalah jenis pengujian perangkat lunak tempat kami mencoba untuk menutupi atau memeriksa perbaikan bug . Fungsi di sekitar perbaikan bug tidak boleh diubah atau diubah karena perbaikan yang disediakan. Masalah yang ditemukan dalam proses tersebut disebut sebagai masalah regresi .

Pengujian Asap: Adalah jenis pengujian yang dilakukan untuk memutuskan apakah akan menerima build / perangkat lunak untuk pengujian QA lebih lanjut.

Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.