¿Necesitamos probar el software de 32 bits en Windows de 64 bits?

31

Estoy trabajando en un equipo de desarrollo de software como desarrollador de software. He estado trabajando en el mismo proyecto durante tres años. El software es una aplicación C # de escritorio de 32 bits en .NET 4. Nuestra plataforma de destino en Windows 7 (tuvimos que admitir Windows XP hasta el año pasado). El software se comunica con varios hardware personalizados para los que se escriben controladores personalizados. La fabricación del hardware y el software del controlador están escritos por nuestro cliente. Hay diferentes controladores para Windows de 32 bits y 64 bits, por supuesto.

Durante nuestra fase de prueba del sistema, ejecutamos todos / la mayoría de los casos de prueba en Windows 7 de 32 bits y 64 bits. No recuerdo si hay algún error en nuestro software que exista en una sola versión de Windows. Teniendo esta experiencia, empecé a preguntarme, ¿realmente necesitamos probar el software de 32 bits en Windows de 64 bits?

¿Cuál es el estándar de la industria?

windows compatibility industry-standard

— Donotalo
fuente

1

¿Su aplicación .NET tiene alguna dependencia en las DLL nativas? Me han mordido varias veces solo en una plataforma, principalmente porque olvidé empaquetar las DLL nativas x86 con mi software junto con las DLL x64. Si comienza a usar una nueva biblioteca de terceros, esa biblioteca también podría intentar cargar archivos DLL nativos detrás de escena, y no lo notará hasta que se bloquee en una PC x86. También tuve que escribir código que elija qué archivos DLL usar en función de si mi aplicación .NET se ejecuta en modo de 64 bits o no, y ese código también debe probarse.

— Phil

@ Phil: Punto señalado. La DLL utiliza muchas bibliotecas externas. Creo que todas esas DLL están compiladas para x86. La aplicación en sí no tiene ninguna dependencia de las DLL nativas, pero llama a la API win32 nativa.

— Donotalo

31

La mayoría de los errores que encontramos al ejecutar software de 32 bits en ventanas de 64 bits tenían que ver con la ubicación del software (Program Files (x86) lugar de Program Files), las ubicaciones de las claves de registro (algunas se encontraron en Wow6432Node). Tuvimos estos problemas principalmente porque necesitábamos comunicarnos con otro software (también de 32 bits), por lo que necesitábamos probar el software tanto en 32 bits como en 64 bits ...

Cuando no tuvo estos problemas, creo que es bastante seguro no realizar pruebas en ambas plataformas cuando compila explícitamente en modo de 32 bits. Cuando se compila en 32 bits, el tiempo de ejecución de .NET ejecutará todo en modo de 32 bits, y debería funcionar igual que el modo de 32 bits en plataformas de 32 bits.

Según las aplicaciones de 64 bits ( MSDN ), las aplicaciones de 32 bits se ejecutan en modo Wow64 y Ejecutar aplicaciones de 32 bits (MSDN) explica este modo con más detalle.

— David realiza
fuente

¿Está diciendo que un software de 32 bits si se ejecuta en un sistema operativo de 64 bits, .NET en ese sistema operativo ejecutará el software en modo de 32 bits, que es lo mismo que ejecutar el software en un sistema operativo de 32 bits en .NET? ¿Hay alguna documentación?

— Donotalo

44

@Donotalo: debe informarse sobre el interruptor básico en su administrador de configuración de Visual Studio (o la configuración de compilación de cada proyecto) llamado "plataforma", con las opciones "x86", "x64" y "Cualquier CPU". Cuando encontraste ese interruptor, F1 es probablemente tu amigo.

— Doc Brown

Se agrega documentación a mi respuesta

— David realiza el

1

El mayor problema que tuvimos fue ejecutar con otras bibliotecas de 32 bits, .NET simplemente no podía cargarlas cuando se ejecutaba en una máquina de 64 bits.

— gbjbaanb

1

@gbjbaanb: seguramente quisiste decir, cuando olvidaste usar "x86" como plataforma.

— Doc Brown

23

La fabricación del hardware y el software del controlador están escritos por nuestro cliente. Hay diferentes controladores para Windows de 32 bits y 64 bits, por supuesto.

Entonces, en Windows de 32 bits, ¿su software habla con un controlador, y en Windows de 64 bits, habla con uno diferente? Supongamos que hay nuevas versiones de estos controladores de vez en cuando. Entonces, cuando solo prueba su software en Windows de 32 bits, no puede estar seguro de que no habrá algunas diferencias en el controlador de 64 bits, lo que hará que la combinación de su software + controlador de 64 bits falle. Y desde el punto de vista de sus usuarios, no importa quién tenga la culpa (usted o el autor del controlador), todo lo que ven es un sistema que no funciona. Así que incluso si tu código está libre de errores, una prueba podría revelar un error en el controlador de 64 bits, y encontrar dicho error podría ayudarlo a tomar las medidas correctas (como enviar un informe de error al autor del controlador).

Por supuesto, cuando ha usado esos dos controladores durante años, y está muy seguro de que el comportamiento es exactamente el mismo, puede saltear las pruebas para una plataforma, siguiendo los argumentos en la respuesta de @ DavidPerfors. Como compromiso, puede ejecutar pruebas en Windows de 64 bits solo cuando haya una nueva versión de controlador disponible. En realidad, esto depende de la complejidad de los controladores, su experiencia y confianza en ellos.

Algunas cosas adicionales a considerar:

¿Qué tipo de sistema operativo utiliza más su base de usuarios? ¿Windows de 32 o 64 bits? Si decide probar solo en una plataforma, elija la que sus usuarios usan con más frecuencia.
¿Qué tan grave es cuando una nueva versión del software no funcionará en una plataforma de uso menos frecuente? Por ejemplo, ¿pueden sus clientes dar un paso atrás e instalar la versión de trabajo anterior? ¿Tienen solo algunos inconvenientes o pérdidas financieras reales por esto? Si es la primera, probar en una sola plataforma puede estar bien, si es la última, obviamente no.

— Doc Brown
fuente

16

La suposición predeterminada en los círculos de control de calidad ilustrados es "Si no lo probó, entonces no funciona".

Como una cuestión práctica que generalmente es un objetivo inalcanzable por el cual luchar de la misma manera que a los ingenieros de aplicaciones les gustaría tener pruebas unitarias para todo; pero no creen que alguna vez lo alcanzarán y lo liberarán a tiempo.

Sin embargo, su pregunta solo puede ser respondida por, o en conjunto con, ventas y marketing. Usted les proporciona un costo de prueba y proporcionan un análisis de los beneficios del mercado. Si las estimaciones en ambos lados fueran lo suficientemente precisas, la respuesta sería simple

if B > C:
    test_32bit_version()

En mi experiencia, las estimaciones de costos de todos son inexactas. En cuanto al otro lado de la ecuación, Dilbert una vez parodió la toma de decisiones allí con "Acabo de preguntarle a mi gato, Mittens". Para hacerlo mucho mejor, necesitarían capacitación en métodos de campo antropológicos.

— msw
fuente

La suposición predeterminada en los círculos de control de calidad ilustrados es "Si no lo probó, entonces no funciona". - y la suposición predeterminada en los círculos de operaciones es "Si no lo probaste, prepárate para ser perseguido como un perro rabioso por sysadmins enojados". Es difícil probar todos los escenarios, pero es una buena idea intentar probar todos los escenarios razonables. Es muy raro que un proyecto post mortem termine decidiendo que el tiempo dedicado a probar que un sistema funciona correctamente fue una pérdida de tiempo.

— Rob Moir

6

Dado que el 99% de todas las instalaciones de Windows de Windows 7 y posteriores, y una buena parte de Vista también, son de 64 bits, ¿por qué demonios considerarías no probar esa plataforma?
Es una obviedad, a menos que lo haga específicamente para un grupo muy limitado de usuarios que SABE que está utilizando Windows de 32 bits y continuará haciéndolo durante la vida útil de su producto.

Así que sí, prueba problemas de 64 bits. De hecho, desarrolle en plataformas de 64 bits, y probablemente suministre una versión de 64 bits como estándar con una versión compilada de 32 bits como opción para aquellos pocos clientes que no se han actualizado a una nueva computadora y sistema operativo en los últimos 6-8 años más o menos .

— jwenting
fuente

1

Estoy de acuerdo en su mayoría, pero el suministro de versiones de 32 y 64 bits agrega complejidad y probablemente no debería hacerse sin una buena justificación basada en el rendimiento o la funcionalidad.

44

Entiendo la necesidad de suministrar binarios de 32 bits. Simplemente no sé si debería molestarse en suministrar los nativos de 64 bits sin una razón convincente.

1

Si lanzara software de escritorio aquí en 2014, probablemente solo lanzaría binarios de 64 bits. ¿Recuerdas en los años 90 cuando la gente estaba haciendo la transición de DOS a Windows 95? Tuvimos un argumento similar en ese momento, y claramente DOS se quedó en el polvo, al igual que ahora es de 32 bits (al menos en el escritorio, no integrado o móvil).

44

Debo preguntarle a @jwenting. ¿De dónde sacaste que es 99%? ¿Podrías mejorar eso y publicar la fuente?

— Malavos

1

Sí, no creo en absoluto el 99%. El mundo de los negocios todavía tiene muchas instalaciones de Windows de 32 bits, entre máquinas viejas no actualizadas (ejecutando Win7 desde los primeros días) o por temor a incompatibilidades. "La mayoría" son probablemente de 64 bits, pero sería muy poco probable que crea un porcentaje muy alto sin muy buena evidencia.

— Joe

2

Probaría cualquier instalador en tantas configuraciones diferentes de Windows como sea posible, según mi experiencia, los instaladores tienen más probabilidades de fallar en diferentes sistemas.

De lo contrario, como sabe por su experiencia con el software dado , es muy poco probable que los errores solo aparezcan en 32 bits o 64 bits, y puede asumir un riesgo calculado.

En primer lugar, debe tener muchos ciclos de prueba con muy poco cambio de código entre los ciclos posteriores a medida que se acerca el envío. En cualquier momento que pueda guardar, puede usar para crear más casos de prueba y / o permitir más ciclos (y, por lo tanto, más pequeños), por lo que ofrece comentarios más rápidos. (El riesgo de pasar tiempo probando X puede ser mayor que el riesgo de no probar Y, porque está probando X demasiado).

Por lo tanto

Intente probar en el "otro bitness" a lo que utilizó para el ciclo de prueba en curso.
Si conoce el "bitness" que usa su desarrollador, comience con las pruebas en otro.
Divida los casos de prueba entre el "bitness" para dar cobertura en cada
Pero cámbielos entre los "binnes" en cada ciclo de prueba.

— Ian
fuente

2

No Del mismo modo, cuando la FDA termina de probar nuevos medicamentos en ratones y ratas, se saltan las pruebas en monos y simplemente los venden para consumo humano.

</ sarcasmo>

Si si SI SI SI. No hay nada más que tristeza guardada para su software si no prueba todas las plataformas que posiblemente pueda. Las cosas siempre son diferentes, y las suposiciones en la cabeza del diseñador / codificador durante el proyecto generalmente solo se acercan de manera pasable al modelado de la vida real. Entonces, por favor, pruebe su software. Por favor.

— kmort
fuente