Apakah kita perlu menguji perangkat lunak 32-bit di Windows 64-bit?

31

Saya bekerja di tim pengembangan perangkat lunak sebagai pengembang perangkat lunak. Saya telah mengerjakan proyek yang sama selama tiga tahun sekarang. Perangkat lunak ini adalah aplikasi C # berbasis desktop 32-bit di .NET 4. Platform target kami di Windows 7 (kami harus mendukung Windows XP hingga tahun lalu). Perangkat lunak ini berkomunikasi dengan berbagai perangkat keras khusus untuk mana driver khusus ditulis. Pembuatan perangkat keras dan perangkat lunak driver ditulis oleh klien kami. Tentu saja ada driver yang berbeda untuk Windows 32-bit dan 64-bit.

Selama fase pengujian sistem kami, kami menjalankan semua / sebagian besar kasus uji pada Windows 32-bit dan 64-bit. Saya tidak dapat mengingat apakah ada bug dalam perangkat lunak kami yang hanya ada dalam satu rasa Windows. Setelah pengalaman ini, saya mulai bertanya-tanya, apakah kita benar-benar perlu menguji perangkat lunak 32-bit pada Windows 64-bit?

Apa standar industri?

windows compatibility industry-standard

— Donotalo
sumber

1

Apakah aplikasi .NET Anda memiliki dependensi pada DLL asli? Saya telah digigit beberapa kali hanya menguji pada satu platform terutama karena saya lupa mengemas DLL asli x86 dengan perangkat lunak saya bersama dengan DLL x64. Jika Anda mulai menggunakan pustaka pihak ketiga yang baru, pustaka itu mungkin juga mencoba memuat DLL asli di belakang layar, dan Anda tidak akan melihat sampai crash di PC x86. Saya juga harus menulis kode yang memilih DLL mana yang akan digunakan berdasarkan apakah aplikasi .NET saya berjalan dalam mode 64-bit atau tidak, dan kode itu perlu diuji juga.

— Phil

@ Phil: Poin dicatat. DLL memang menggunakan banyak pustaka eksternal. Saya percaya semua DLL tersebut dikompilasi untuk x86. Aplikasi itu sendiri tidak memiliki ketergantungan pada DLL asli, tetapi memanggil API win32 asli.

— Donotalo

31

Sebagian besar bug yang kami temui dengan menjalankan perangkat lunak 32-bit pada windows 64-bit ada hubungannya dengan lokasi perangkat lunak ( Program Files (x86)bukan Program Files), lokasi kunci registri (beberapa ditemukan di Wow6432Node). Kami mengalami masalah ini sebagian besar karena kami perlu berkomunikasi dengan perangkat lunak lain (juga 32-bit), jadi kami harus menguji perangkat lunak pada 32-bit dan 64-bit ...

Ketika Anda tidak memiliki masalah ini, saya yakin cukup aman untuk tidak menguji pada kedua platform ketika Anda secara eksplisit mengkompilasi dalam mode 32-bit. Ketika dikompilasi dalam 32-bit, runtime .NET akan menjalankan semuanya dalam mode 32-bit, dan itu harus bekerja sama dengan mode 32-bit pada platform 32-bit.

Menurut Aplikasi 64-bit ( MSDN ), aplikasi 32-bit dijalankan dalam mode Wow64 dan Menjalankan Aplikasi 32-bit (MSDN) menjelaskan mode ini secara lebih rinci.

— David Perfors
sumber

Apakah Anda mengatakan bahwa perangkat lunak 32 bit jika dijalankan pada OS 64 bit, .NET pada OS itu akan menjalankan perangkat lunak dalam mode 32 bit - yang sama dengan menjalankan perangkat lunak dalam OS 32 bit dalam .NET? Apakah ada dokumentasi?

— Donotalo

4

@ Donotalo: Anda harus memberi tahu diri Anda tentang sakelar dasar di manajer konfigurasi Visual Studio Anda (atau setiap pengaturan kompilasi proyek) bernama "platform", dengan opsi "x86", "x64" dan "Any CPU". Ketika Anda menemukan saklar itu, F1 mungkin adalah teman Anda.

— Doc Brown

Dokumentasi ditambahkan ke jawaban saya

— David Perfors

1

Masalah terbesar yang kami miliki adalah berjalan dengan perpustakaan 32 bit lainnya, .NET hanya akan gagal memuatnya ketika dijalankan pada mesin 64-bit.

— gbjbaanb

1

@ gbjbaanb: maksud Anda, ketika Anda lupa menggunakan "x86" sebagai platform.

— Doc Brown

23

Pembuatan perangkat keras dan perangkat lunak driver ditulis oleh klien kami. Ada driver yang berbeda untuk Windows 32 bit dan 64 bit tentu saja.

Jadi pada Windows 32 bit, perangkat lunak Anda berbicara dengan satu driver, dan pada Windows 64 bit, ia berbicara ke driver lain? Mari kita asumsikan ada versi baru dari driver ini dari waktu ke waktu. Jadi ketika Anda hanya menguji perangkat lunak Anda pada Windows 32 bit, Anda tidak dapat memastikan tidak akan ada perbedaan dalam driver 64 bit yang akan membuat kombinasi perangkat lunak Anda + driver 64 bit gagal. Dan dari sudut pandang pengguna Anda, tidak masalah siapa yang harus disalahkan (Anda atau penulis driver), yang mereka lihat adalah sistem yang tidak berfungsi. Jadi, bahkan jika kode Anda bebas dari bug, tes mungkin mengungkapkan bug dalam driver 64 bit, dan menemukan bug seperti itu dapat membantu Anda mengambil langkah-langkah yang tepat (seperti mengirim laporan bug ke pembuat driver).

Tentu saja, ketika Anda telah menggunakan dua driver tersebut selama bertahun-tahun, dan Anda sangat yakin bahwa perilakunya persis sama, Anda dapat melewatkan tes untuk satu platform, mengikuti argumen dalam jawaban @ DavidPerfors. Sebagai kompromi, Anda dapat menjalankan tes pada Windows 64 bit hanya setiap kali versi driver baru tersedia. Sebenarnya, ini tergantung pada kompleksitas driver, pengalaman Anda dengan dan kepercayaan diri mereka.

Beberapa hal tambahan untuk dipertimbangkan:

jenis OS apa yang paling banyak digunakan basis pengguna Anda? 32 bit atau 64 bit Windows? Jika Anda memutuskan untuk menguji hanya pada satu platform, pilih yang paling sering digunakan pengguna Anda.
seberapa parahnya ketika rilis baru perangkat lunak tidak akan berfungsi pada platform yang jarang digunakan? Misalnya, dapatkah pelanggan Anda segera mundur dan menginstal rilis kerja sebelumnya? Apakah mereka hanya memiliki beberapa ketidaknyamanan atau kerugian finansial nyata dengan ini? Jika yang pertama, pengujian hanya pada satu platform mungkin baik-baik saja, jika yang terakhir, jelas tidak.

— Doc Brown
sumber

16

Asumsi default di lingkaran QA yang tercerahkan adalah "Jika Anda tidak mengujinya, maka itu tidak berfungsi".

Sebagai hal praktis yang biasanya merupakan tujuan yang tidak terjangkau untuk diperjuangkan dengan cara yang sama seperti insinyur aplikasi mungkin ingin memiliki unit-test untuk semuanya; tetapi mereka tidak percaya mereka akan pernah mencapainya dan merilisnya sesuai jadwal.

Namun pertanyaan Anda hanya dapat dijawab oleh, atau bersamaan dengan, penjualan dan pemasaran. Anda memberi mereka biaya untuk menguji dan mereka memberikan analisis manfaat pasar. Jika estimasi di kedua sisi cukup akurat, jawabannya akan sederhana

if B > C:
    test_32bit_version()

Dalam pengalaman saya, perkiraan biaya semua orang tidak akurat. Sejauh sisi lain dari persamaan, Dilbert pernah memparodikan pengambilan keputusan di sana dengan "Saya hanya bertanya pada kucing saya, Mittens". Untuk melakukan jauh lebih baik, mereka perlu pelatihan dalam metode lapangan antropologis.

— msw
sumber

Asumsi default di lingkaran QA yang tercerahkan adalah "Jika Anda tidak mengujinya, maka itu tidak berfungsi". - dan asumsi default dalam lingkaran operasi adalah "Jika Anda tidak mengujinya, maka bersiaplah untuk diburu seperti anjing gila oleh sysadmin yang marah". Sulit untuk menguji semua skenario tetapi merupakan ide yang baik untuk berusaha keras untuk menguji semua skenario yang masuk akal. Sangat jarang bahwa proyek post mortem akhirnya memutuskan bahwa waktu yang dihabiskan untuk menguji sistem bekerja dengan baik adalah waktu yang terbuang sia-sia.

— Rob Moir

6

Melihat 99% dari semua instalasi Windows pada Windows 7 ke atas, dan sebagian besar dari Vista juga, 64 bit, mengapa Anda bahkan mempertimbangkan untuk tidak menguji untuk platform itu?
Ini hanya no-brainer, kecuali jika Anda membuatnya secara khusus untuk kelompok pengguna yang sangat terbatas yang Anda TAHU menggunakan Windows 32 bit dan akan terus melakukannya selama masa pakai produk Anda.

Jadi ya, uji untuk masalah 64 bit. Bahkan berkembang pada platform 64 bit, dan mungkin menyediakan versi 64 bit sebagai standar dengan versi 32 bit yang dikompilasi sebagai pilihan bagi beberapa pelanggan yang belum meng-upgrade ke komputer dan OS baru dalam 6-8 tahun terakhir atau lebih .

— jwenting
sumber

1

Saya setuju sebagian besar, tetapi menyediakan versi 32 dan 64 bit menambah kompleksitas dan mungkin tidak boleh dilakukan tanpa alasan yang baik berdasarkan kinerja atau fungsi.

4

Saya mengerti perlunya menyediakan binari 32 bit. Saya hanya tidak tahu apakah dia harus repot-repot memasok yang asli 64 bit tanpa alasan kuat.

1

Jika saya merilis perangkat lunak desktop di sini pada tahun 2014, saya mungkin hanya akan merilis biner 64 bit. Ingat di tahun 90-an ketika orang-orang beralih dari DOS ke Windows 95? Kami memiliki argumen yang sama saat itu - dan jelas DOS tertinggal dalam debu, sama seperti 32 bit sekarang (setidaknya pada desktop, tidak tertanam atau mobile).

4

Saya harus bertanya @jwenting. Di mana Anda mendapatkan bahwa itu 99%? Bisakah Anda memperbaiki itu dan memposting sumber?

— Malavos

1

Ya, saya tidak percaya 99% sama sekali. Dunia bisnis masih memiliki banyak instalasi Windows 32 bit di luar sana, antara mesin lama yang tidak diperbarui (menjalankan Win7 sejak awal) atau karena takut tidak kompatibel. "Mayoritas" mungkin 64 bit, tetapi saya tidak akan percaya persentase yang sangat tinggi tanpa bukti yang sangat bagus.

— Joe

2

Saya akan menguji penginstal apa pun pada sebanyak mungkin pengaturan Windows yang berbeda karena menurut pengalaman saya, penginstal kemungkinan besar akan gagal pada sistem yang berbeda.

Jika tidak, seperti yang Anda ketahui dari pengalaman Anda dengan perangkat lunak yang diberikan , bug paling tidak mungkin hanya muncul pada 32-bit atau 64-bit, dan Anda dapat mengambil risiko yang sudah diperhitungkan.

Pertama, Anda harus memiliki banyak siklus pengujian dengan sedikit perubahan kode di antara siklus-siklus berikutnya saat Anda mendekati pengiriman. Kapan saja Anda dapat menghemat, Anda dapat menggunakan untuk membuat lebih banyak test case, dan / atau memperbolehkan lebih banyak (dan karenanya lebih kecil) siklus, sehingga memberikan umpan balik yang lebih cepat. (Risiko menghabiskan waktu menguji X mungkin lebih dari risiko tidak menguji Y, karena Anda terlalu banyak menguji X.)

Karena itu

Cobalah untuk menguji pada "bitness lain" untuk apa yang Anda gunakan untuk siklus tes melanjutkan.
Jika Anda mengetahui "bitness" yang digunakan pengembang Anda, mulailah dengan menguji yang lain.
Bagilah test case ke atas antara "bitness" untuk memberikan liputan masing-masing
Tapi tukar mereka di antara "binnes" pada setiap siklus tes.

— Ian
sumber

2

Nggak. Demikian juga, ketika FDA selesai menguji obat-obatan baru pada tikus dan tikus, mereka melewatkan pengujian pada monyet dan hanya menjualnya untuk konsumsi manusia.

</ sarkasme>

Ya ya ya ya ya. Tidak ada yang lain selain kesedihan yang ada untuk perangkat lunak Anda jika Anda tidak menguji setiap platform yang Anda bisa. Segala sesuatu selalu berbeda, dan asumsi di kepala desainer / coder selama proyek biasanya hanya mendekati pemodelan kehidupan nyata. Jadi tolong, uji perangkat lunak Anda. Silahkan.

— kmort
sumber