Dobbiamo testare il software a 32 bit in Windows a 64 bit?

31

Sto lavorando in un team di sviluppo software come sviluppatore di software. Lavoro allo stesso progetto da tre anni ormai. Il software è un'applicazione C # basata su desktop a 32 bit in .NET 4. La nostra piattaforma di destinazione in Windows 7 (dovevamo supportare Windows XP fino allo scorso anno). Il software comunica con vari hardware personalizzati per i quali vengono scritti i driver personalizzati. La produzione hardware e il software del driver sono scritti dal nostro cliente. Esistono driver diversi per Windows a 32 e 64 bit.

Durante la nostra fase di test del sistema, eseguiamo tutti / la maggior parte dei casi di test in Windows 7. Sia a 32 che a 64 bit. Non riesco a ricordare se nel nostro software sono presenti bug presenti in una sola versione di Windows. Con questa esperienza ho iniziato a chiedermi, dobbiamo davvero testare il software a 32 bit su Windows a 64 bit?

Qual è lo standard del settore?

windows compatibility industry-standard

— Donotalo
fonte

1

La tua applicazione .NET ha dipendenze da DLL native? Sono stato morso un paio di volte solo test su una piattaforma principalmente perché ho dimenticato di pacchetto le DLL native x86 con il mio software insieme alle DLL x64. Se inizi a utilizzare una nuova libreria di terze parti, quella libreria potrebbe anche provare a caricare DLL native dietro le quinte e non noterai fino a quando non si arresta in modo anomalo su un PC x86. Ho anche dovuto scrivere un codice che selezionasse quali DLL usare in base al fatto che la mia app .NET funzionasse o meno in modalità 64-bit e che anche quel codice dovesse essere testato.

— Phil

@Phil: punto notato. La DLL utilizza molte librerie esterne. Credo che tutte quelle DLL siano compilate per x86. L'applicazione stessa non ha alcuna dipendenza da DLL native, ma chiama API Win32 nativa.

— Donotalo,

31

La maggior parte dei bug riscontrati nell'esecuzione del software a 32 bit su Windows a 64 bit riguardava la posizione del software ( Program Files (x86)anziché Program Files), le posizioni delle chiavi di registro (alcune sono state trovate in Wow6432Node). Abbiamo avuto questi problemi principalmente perché dovevamo comunicare con altri software (anche a 32 bit) e quindi dovevamo testare il software sia a 32-bit che a 64-bit ...

Quando non hai avuto questi problemi, credo che sia abbastanza sicuro non testare su entrambe le piattaforme quando si compila esplicitamente in modalità a 32 bit. Se compilato a 32 bit, il runtime .NET eseguirà tutto in modalità 32 bit e dovrebbe funzionare allo stesso modo della modalità 32 bit su piattaforme a 32 bit.

Secondo le applicazioni a 64 bit ( MSDN ), le applicazioni a 32 bit vengono eseguite in modalità Wow64 e L' esecuzione di applicazioni a 32 bit (MSDN) spiega questa modalità in modo più dettagliato.

— David Perfors
fonte

Stai dicendo che un software a 32 bit se eseguito su un sistema operativo a 64 bit, .NET su quel sistema operativo eseguirà il software in modalità 32 bit - che è lo stesso che eseguire il software nel sistema operativo a 32 bit in .NET? C'è della documentazione?

— Donotalo,

4

@Donotalo: dovresti informarti sullo switch di base nel tuo gestore della configurazione di Visual Studio (o nelle impostazioni di compilazione di ogni progetto) chiamato "platform", con le opzioni "x86", "x64" e "Any CPU". Quando hai trovato questo interruttore, F1 è probabilmente tuo amico.

— Doc Brown,

La documentazione viene aggiunta alla mia risposta

— David Perfors,

1

Il problema più grande che abbiamo riscontrato era con altre librerie a 32 bit, .NET semplicemente non sarebbe riuscito a caricarle quando eseguito su una macchina a 64 bit.

— gbjbaanb,

1

@gbjbaanb: intendevi sicuramente quando hai dimenticato di usare "x86" come piattaforma.

— Doc Brown,

23

La produzione hardware e il software del driver sono scritti dal nostro cliente. Esistono driver diversi per Windows a 32 e 64 bit.

Quindi su Windows a 32 bit, il tuo software parla con un driver, e su Windows a 64 bit, parla con un altro? Supponiamo di volta in volta che siano disponibili nuove versioni di questi driver. Quindi, quando testate il vostro software solo su Windows a 32 bit, non potete essere certi che non ci saranno alcune differenze nel driver a 64 bit che farà fallire la combinazione del vostro software + driver a 64 bit. E dal punto di vista dei tuoi utenti, non importa chi sia la colpa (tu o l'autore del driver), tutto ciò che vedono è un sistema non funzionante. Quindi, anche se il tuo codice è privo di bug, un test potrebbe rivelare un bug nel driver a 64 bit e la ricerca di un tale bug potrebbe aiutarti a prendere le giuste misure (come l'invio di una segnalazione di bug all'autore del driver).

Naturalmente, quando hai usato questi due driver per anni e sei molto sicuro che il comportamento sia esattamente lo stesso, potresti saltare i test per una piattaforma, seguendo gli argomenti nella risposta di @ DavidPerfors. Come compromesso, è possibile eseguire test su Windows a 64 bit solo quando è disponibile una nuova versione del driver. In realtà, questo dipende dalla complessità dei driver, dalla tua esperienza e fiducia in essi.

Alcune cose aggiuntive da considerare:

quale tipo di sistema operativo utilizza maggiormente la tua base di utenti? Windows a 32 o 64 bit? Se decidi di provare solo su una piattaforma, scegli quella che gli utenti utilizzano più spesso.
quanto è grave quando una nuova versione del software non funzionerà su una piattaforma utilizzata meno frequentemente? Ad esempio, i tuoi clienti possono immediatamente fare un passo indietro e installare la versione di lavoro precedente? Hanno solo qualche inconveniente o reale perdita finanziaria da questo? Se è il primo, test su una sola piattaforma può andare bene, se è il secondo, ovviamente no.

— Doc Brown
fonte

16

Il presupposto predefinito nei circoli QA illuminati è "Se non lo hai testato, allora non funziona".

In pratica questo è di solito un obiettivo irraggiungibile per cui ci si può impegnare in modo molto simile agli ingegneri applicativi per fare unit test per tutto; ma non credono che lo raggiungeranno mai e rilasceranno nei tempi previsti.

Tuttavia, alla tua domanda è possibile rispondere solo o congiuntamente a vendite e marketing. Fornisci loro un costo da testare e forniscono un'analisi del vantaggio di mercato. Se le stime su entrambi i lati fossero sufficientemente accurate, la risposta sarebbe semplice

if B > C:
    test_32bit_version()

Nella mia esperienza, le stime dei costi di tutti sono imprecise. Per quanto riguarda l'altro lato dell'equazione, Dilbert una volta ha parodiato la decisione di prendere lì con "Ho appena chiesto al mio gatto, Mittens". Per fare molto meglio, avrebbero bisogno di formazione sui metodi di campo antropologico.

— rifiuti solidi urbani
fonte

Il presupposto predefinito nei circoli QA illuminati è "Se non lo hai testato, allora non funziona". - e il presupposto predefinito nei circoli operativi è "Se non lo hai testato, allora preparati a essere cacciato come un cane rabbioso da amministratori arrabbiati". È difficile testare tutti gli scenari, ma è una buona idea provare a testare tutti quelli ragionevoli. È molto raro che un progetto post mortem finisca per decidere che il tempo impiegato per testare un sistema che funziona correttamente è stato sprecato.

— Rob Moir,

6

Considerando che il 99% di tutte le installazioni Windows di Windows 7 e versioni successive e una buona parte di Vista sono a 64 bit, perché diavolo dovresti considerare di non provare per quella piattaforma?
È un gioco da ragazzi, a meno che tu non lo stia facendo appositamente per un gruppo molto limitato di utenti che SAPI stai utilizzando Windows a 32 bit e continuerà a farlo per tutta la vita del tuo prodotto.

Quindi sì, prova per problemi a 64 bit. Infatti, si sviluppa su piattaforme a 64 bit e probabilmente fornisce una versione a 64 bit di serie con una versione compilata a 32 bit come opzione per quei pochi clienti che non hanno eseguito l'aggiornamento a un nuovo computer e sistema operativo negli ultimi 6-8 anni circa .

— jwenting
fonte

1

Concordo principalmente, ma fornire entrambe le versioni a 32 e 64 bit aggiunge complessità e probabilmente non dovrebbe essere fatto senza una buona logica basata su prestazioni o funzionalità.

4

Comprendo la necessità di fornire file binari a 32 bit. Semplicemente non so se dovrebbe preoccuparsi di fornire quelli a 64 bit nativi senza un motivo convincente.

1

Se avessi rilasciato software desktop qui nel 2014, probabilmente avrei rilasciato solo file binari a 64 bit. Ricordi negli anni '90 quando le persone passavano dal DOS a Windows 95? Abbiamo avuto un argomento simile allora - e chiaramente DOS è rimasto nella polvere, proprio come adesso è a 32 bit (almeno sul desktop, non incorporato o mobile).

4

Devo chiedere a @jwenting. Dove hai ottenuto che è del 99%? Potresti migliorare su questo e pubblicare la fonte?

— Malavos,

1

Sì, non credo affatto al 99%. Il mondo degli affari ha ancora molte installazioni di Windows a 32 bit, tra vecchie macchine non aggiornate (che eseguono Win7 dai primi giorni) o per paura di incompatibilità. "La maggioranza" è probabilmente a 64 bit, ma sarebbe molto improbabile che io creda a una percentuale molto alta senza prove molto valide.

— Joe,

2

Vorrei testare qualsiasi programma di installazione su quante più diverse configurazioni di Windows possibile, per la mia esperienza è molto probabile che i programmi di installazione falliscano su sistemi diversi.

Altrimenti, come sai dalla tua esperienza con il software dato , è molto improbabile che i bug si presentino solo a 32-bit o 64-bit e puoi prendere un rischio calcolato.

Innanzitutto, dovresti avere molti cicli di prova con pochissima modifica del codice tra i cicli successivi man mano che ti avvicini alla spedizione. Ogni volta che puoi risparmiare, puoi utilizzare per creare più casi di test e / o consentire più cicli (e quindi più piccoli), fornendo così un feedback più rapido. (Il rischio di perdere tempo a testare X potrebbe essere maggiore del rischio di non testare Y, perché stai testando X troppo.)

Perciò

Prova a testare l '"altro testimone" su ciò che hai usato per il ciclo di prova procedente.
Se conosci il "testimone" utilizzato dallo sviluppatore, inizia con i test su un altro.
Dividi i casi di test tra il "testimone" per fornire una copertura su ciascuno di essi
Ma scambiali tra i "binnes" su ogni ciclo di test.

— Ian
fonte

2

No. Allo stesso modo, quando la FDA ha finito di testare nuovi farmaci su topi e ratti, saltano i test sulle scimmie e li vendono solo per il consumo umano.

</ sarcasmo>

Sì, sì sì sì sì. Non c'è altro che tristezza in serbo per il tuo software se non collaudi tutte le piattaforme che puoi. Le cose sono sempre diverse e le ipotesi nella testa del progettista / programmatore durante il progetto di solito si avvicinano passabilmente alla modellazione della vita reale. Quindi, per favore, prova il tuo software. Per favore.

— kmort
fonte