Avons-nous besoin de tester un logiciel 32 bits dans Windows 64 bits?

Je travaille dans une équipe de développement logiciel en tant que développeur logiciel. Je travaille sur le même projet depuis trois ans maintenant. Le logiciel est une application C # de bureau 32 bits dans .NET 4. Notre plate-forme cible dans Windows 7 (nous avons dû prendre en charge Windows XP jusqu'à l'année dernière). Le logiciel communique avec divers matériels personnalisés pour lesquels des pilotes personnalisés sont écrits. La fabrication du matériel et le logiciel du pilote sont écrits par notre client. Il existe bien sûr un pilote différent pour Windows 32 bits et 64 bits.

Au cours de notre phase de test du système, nous exécutons tous / la plupart des cas de test dans Windows 7 32 bits et 64 bits. Je ne me souviens pas si nous avons eu un bogue dans notre logiciel qui existe dans une seule version de Windows. Ayant cette expérience, je commence à me demander, avons-nous vraiment besoin de tester un logiciel 32 bits sur Windows 64 bits?

Quelle est la norme de l'industrie?

La plupart des bogues rencontrés lors de l'exécution de logiciels 32 bits sur des fenêtres 64 bits étaient liés à l'emplacement du logiciel ( Program Files (x86)au lieu de Program Files), à l'emplacement des clés de registre (certains ont été trouvés dans Wow6432Node). Nous avons eu ces problèmes principalement parce que nous devions communiquer avec d'autres logiciels (également 32 bits), et nous devions donc tester le logiciel sur 32 bits et 64 bits ...

Lorsque vous n'avez pas eu ces problèmes, je pense qu'il est assez sûr de ne pas tester sur les deux plates-formes lorsque vous compilez explicitement en mode 32 bits. Une fois compilé en 32 bits, le runtime .NET exécutera tout en mode 32 bits, et il devrait fonctionner de la même manière que le mode 32 bits sur les plates-formes 32 bits.

Selon les applications 64 bits ( MSDN ), les applications 32 bits sont exécutées en mode Wow64 et l' exécution des applications 32 bits (MSDN) explique ce mode plus en détail.

La fabrication du matériel et le logiciel du pilote sont écrits par notre client. Il y a bien sûr un pilote différent pour Windows 32 bits et 64 bits.

Donc, sur Windows 32 bits, votre logiciel parle à un pilote, et sur Windows 64 bits, il parle à un autre? Supposons qu'il existe de temps en temps de nouvelles versions de ces pilotes. Ainsi, lorsque vous testez uniquement votre logiciel sur Windows 32 bits, vous ne pouvez pas être sûr qu'il n'y aura pas de différences dans le pilote 64 bits, ce qui entraînera l'échec de la combinaison de votre logiciel + pilote 64 bits. Et du point de vue de vos utilisateurs, peu importe qui est à blâmer (vous ou l'auteur du pilote), tout ce qu'ils voient est un système qui ne fonctionne pas. Donc, même si votre code est exempt de bogues, un test peut révéler un bogue dans le pilote 64 bits, et trouver un tel bogue peut vous aider à prendre les bonnes mesures (comme envoyer un rapport de bogue à l'auteur du pilote).

Bien sûr, lorsque vous utilisez ces deux pilotes depuis des années et que vous êtes très confiant que le comportement est exactement le même, vous pouvez ignorer les tests pour une plate-forme, en suivant les arguments de la réponse de @ DavidPerfors. À titre de compromis, vous pouvez exécuter des tests sur Windows 64 bits uniquement lorsqu'une nouvelle version de pilote est disponible. En fait, cela dépend de la complexité des pilotes, de votre expérience et de votre confiance en eux.

Quelques éléments supplémentaires à considérer:

• quel type de système d'exploitation votre base d'utilisateurs utilise-t-elle le plus? Windows 32 bits ou 64 bits? Si vous décidez de ne tester que sur une seule plateforme, choisissez celle que vos utilisateurs utilisent le plus souvent.
• Quelle est la gravité lorsqu'une nouvelle version du logiciel ne fonctionne pas sur une plate-forme moins fréquemment utilisée? Par exemple, vos clients peuvent-ils immédiatement prendre du recul et installer la version de travail précédente? En ont-ils seulement quelques inconvénients ou de réelles pertes financières? S'il s'agit de la première, tester sur une seule plate-forme peut être correct, si c'est la seconde, évidemment non.

L'hypothèse par défaut dans les cercles QA éclairés est "Si vous ne l'avez pas testé, alors cela ne fonctionne pas".

En pratique, c'est généralement un objectif inaccessible que nous recherchons de la même manière que les ingénieurs d'application aimeraient avoir des tests unitaires pour tout; mais ils ne croient pas qu'ils l'atteindront et sortiront dans les délais.

Cependant, votre question ne peut être répondue que par ou en conjonction avec les ventes et le marketing. Vous leur fournissez un coût à tester et ils fournissent une analyse de l'avantage du marché. Si les estimations des deux côtés étaient suffisamment précises, la réponse serait simple

if B > C:
    test_32bit_version()

D'après mon expérience, les estimations de coûts de chacun sont inexactes. En ce qui concerne l'autre côté de l'équation, Dilbert a parodié une fois la prise de décision avec "Je viens de demander à mon chat, mitaines". Pour faire beaucoup mieux, ils auraient besoin d'une formation aux méthodes anthropologiques de terrain.

Étant donné que 99% de toutes les installations Windows de Windows 7 et plus, ainsi qu'une bonne partie de Vista, sont en 64 bits, pourquoi diable envisageriez-vous même de ne pas tester cette plate-forme?
C'est juste une évidence, à moins que vous ne le fassiez spécifiquement pour un groupe très limité d'utilisateurs que vous SAVEZ utiliser Windows 32 bits et continuera à le faire pendant la durée de vie de votre produit.

Alors oui, testez les problèmes 64 bits. En fait, se développe sur des plates-formes 64 bits et fournit probablement une version 64 bits en standard avec une version compilée 32 bits en option pour les quelques clients qui n'ont pas mis à niveau vers un nouvel ordinateur et un système d'exploitation au cours des 6 à 8 dernières années. .

Je testerais n'importe quel programme d'installation sur autant de configurations Windows différentes que possible, car d'après mon expérience, les programmes d'installation sont les plus susceptibles d'échouer sur différents systèmes.

Sinon, comme vous le savez d' après votre expérience avec le logiciel donné , il est peu probable que les bogues apparaissent uniquement sur 32 bits ou 64 bits, et vous pouvez prendre un risque calculé.

Tout d'abord, vous devriez avoir de nombreux cycles de test avec très peu de changement de code entre les cycles ultérieurs à l'approche de l'expédition. Chaque fois que vous pouvez économiser, vous pouvez utiliser pour créer plus de cas de test et / ou autoriser des cycles plus (et donc plus petits), donnant ainsi un retour plus rapide. (Le risque de passer du temps à tester X peut être supérieur au risque de ne pas tester Y, car vous testez trop X.)

Par conséquent

• Essayez de tester sur «l'autre témoin» ce que vous avez utilisé pour le cycle de test en cours.
• Si vous connaissez le «témoin» utilisé par votre développeur, commencez par tester un autre.
• Répartissez les cas de test entre le «témoin» pour donner une couverture sur chaque
• Mais permutez-les entre les «binnes» à chaque cycle de test.

Nan. De même, lorsque la FDA a fini de tester de nouveaux médicaments sur des souris et des rats, elle ignore les tests sur les singes et les vend simplement pour la consommation humaine.

</ sarcasme>

Oui oui oui oui oui. Il n'y a rien d'autre que de la tristesse pour votre logiciel si vous ne testez pas toutes les plates-formes possibles. Les choses sont toujours différentes, et les hypothèses dans la tête du concepteur / codeur pendant le projet ne se rapprochent généralement que passablement de la modélisation de la vie réelle. Alors s'il vous plaît, testez votre logiciel. S'il vous plaît.