Precisamos testar o software de 32 bits no Windows de 64 bits?

31

Estou trabalhando em uma equipe de desenvolvimento de software como desenvolvedor de software. Estou trabalhando no mesmo projeto há três anos. O software é um aplicativo C # baseado em desktop de 32 bits no .NET 4. Nossa plataforma de destino no Windows 7 (precisávamos oferecer suporte ao Windows XP até o ano passado). O software se comunica com vários hardwares personalizados para os quais os drivers personalizados são gravados. O software de fabricação e driver de hardware é escrito por nosso cliente. Há um driver diferente para o Windows de 32 e 64 bits, é claro.

Durante a fase de teste do sistema, executamos todos / a maioria dos casos de teste no Windows 7. de 32 e 64 bits. Não me lembro se houve algum bug em nosso software que exista apenas em uma versão do Windows. Tendo essa experiência que comecei a me perguntar, precisamos realmente testar o software de 32 bits no Windows de 64 bits?

Qual é o padrão da indústria?

windows compatibility industry-standard

— Donotalo
fonte

1

Seu aplicativo .NET possui alguma dependência de DLLs nativas? Fui mordido algumas vezes apenas testando em uma plataforma, principalmente porque esqueci de empacotar as DLLs nativas x86 com o meu software junto com as DLLs x64. Se você começar a usar uma nova biblioteca de terceiros, essa biblioteca também poderá tentar carregar DLLs nativas nos bastidores e você não notará até que ela trave em um PC x86. Também tive que escrever um código que escolha quais DLLs usar, com base em se meu aplicativo .NET está sendo executado no modo de 64 bits ou não, e esse código também precisa ser testado.

— Phil

@ Phil: Ponto observado. A DLL usa muitas bibliotecas externas. Acredito que todas essas DLLs são compiladas para x86. O aplicativo em si não depende de DLLs nativas, mas chama a API win32 nativa.

— 13004 Donotalo

31

A maioria dos erros encontrados na execução de software de 32 bits em janelas de 64 bits tinha a ver com a localização do software (em Program Files (x86)vez de Program Files), os locais das chaves do registro (alguns foram encontrados no Wow6432Node). Tivemos esses problemas principalmente porque precisávamos nos comunicar com outro software (também de 32 bits) e, portanto, precisávamos testar o software em 32 e 64 bits ...

Quando você não teve esses problemas, acredito que é bastante seguro não testar em ambas as plataformas quando você compila explicitamente no modo de 32 bits. Quando compilado em 32 bits, o tempo de execução do .NET executará tudo no modo de 32 bits e deve funcionar da mesma forma que o modo de 32 bits nas plataformas de 32 bits.

De acordo com os aplicativos de 64 bits ( MSDN ), os aplicativos de 32 bits são executados no modo Wow64 e a execução de aplicativos de 32 bits (MSDN) explica esse modo com mais detalhes.

— David Perfors
fonte

Você está dizendo que, se um software de 32 bits for executado no sistema operacional de 64 bits, o .NET nesse sistema operacional executará o software no modo de 32 bits - o mesmo que executar o software no sistema operacional de 32 bits no .NET? Existe alguma documentação?

— Donotalo

4

@ Donotalo: você deve se informar sobre a opção básica no seu gerenciador de configuração do Visual Studio (ou as configurações de compilação de cada projeto) denominada "platform", com as opções "x86", "x64" e "Any CPU". Quando você encontrou essa opção, F1 provavelmente é seu amigo.

— Doc Brown

A documentação foi adicionada à minha resposta

— David Perfors

1

O maior problema que tivemos foi a execução com outras bibliotecas de 32 bits; o .NET simplesmente falharia em carregá-las quando executadas em uma máquina de 64 bits.

— Gbjbaanb

1

@gbjbaanb: você certamente quis dizer quando esqueceu de usar o "x86" como plataforma.

— Doc Brown

23

O software de fabricação e driver de hardware é escrito por nosso cliente. Existe um driver diferente para o Windows de 32 e 64 bits, é claro.

Então, no Windows de 32 bits, seu software fala com um driver e no Windows de 64 bits, com um driver diferente? Vamos supor que há novas versões desses drivers periodicamente. Portanto, quando você testar seu software apenas no Windows de 32 bits, não poderá ter certeza de que não haverá diferenças no driver de 64 bits, o que fará com que a combinação do software + do driver de 64 bits falhe. E do ponto de vista de seus usuários, não importa quem é o culpado (você ou o autor do driver), tudo o que eles veem é um sistema que não funciona. Portanto, mesmo que seu código esteja livre de erros, um teste pode revelar um erro no driver de 64 bits, e encontrar esse erro pode ajudá-lo a tomar as medidas corretas (como enviar um relatório de erro ao autor do driver).

Obviamente, quando você usa esses dois drivers há anos e está muito confiante de que o comportamento é exatamente o mesmo, você pode pular os testes para uma plataforma, seguindo os argumentos da resposta do @ DavidPerfors. Como compromisso, você só pode executar testes no Windows de 64 bits sempre que uma nova versão do driver estiver disponível. Na verdade, isso depende da complexidade dos drivers, da sua experiência e da confiança neles.

Algumas coisas adicionais a serem consideradas:

que tipo de SO sua base de usuários mais utiliza? Windows de 32 ou 64 bits? Se você decidir testar apenas em uma plataforma, escolha a que seus usuários usam com mais frequência.
Quão grave é quando uma nova versão do software não funciona em uma plataforma usada com menos frequência? Por exemplo, seus clientes podem recuar imediatamente e instalar a versão de trabalho anterior? Eles têm apenas algum inconveniente ou perda financeira real com isso? Se for a primeira, testar em apenas uma plataforma pode ser bom; se for a última, obviamente não.

— Doc Brown
fonte

16

A suposição padrão nos círculos de controle de qualidade iluminado é "Se você não testou, não funcionará".

Por uma questão prática, geralmente é um objetivo inacessível o que se esforçar da mesma maneira que os engenheiros de aplicação podem gostar de fazer testes de unidade para tudo; mas eles não acreditam que jamais o alcançarão e serão liberados dentro do prazo.

No entanto, sua pergunta só pode ser respondida por, ou em conjunto com, vendas e marketing. Você fornece a eles um custo para testar e eles fornecem uma análise dos benefícios do mercado. Se as estimativas de ambos os lados fossem suficientemente precisas, a resposta seria simples

if B > C:
    test_32bit_version()

Na minha experiência, as estimativas de custo de todos são imprecisas. Quanto ao outro lado da equação, Dilbert uma vez parodiou a tomada de decisões lá com "Eu apenas perguntei ao meu gato, Mittens". Para fazer muito melhor, eles precisariam de treinamento em métodos de campo antropológico.

— msw
fonte

A suposição padrão nos círculos de controle de qualidade iluminado é "Se você não testou, não funcionará". - e a suposição padrão nos círculos de operações é "Se você não testou, esteja preparado para ser caçado como um cão raivoso por administradores de sistemas raivosos". É difícil testar todos os cenários, mas é uma boa idéia tentar testar todos os cenários razoáveis. É muito raro que um projeto post mortem acabe decidindo que o tempo gasto no teste de um sistema funciona corretamente era desperdiçado.

— quer

6

Como 99% de todas as instalações do Windows 7 e posteriores, além de boa parte do Vista, são de 64 bits, por que diabos você consideraria não testar essa plataforma?
É apenas um acéfalo, a menos que você esteja fazendo isso especificamente para um grupo muito limitado de usuários que você sabe que está usando o Windows de 32 bits e continuará a fazê-lo pela vida útil do seu produto.

Então, sim, teste para problemas de 64 bits. De fato, desenvolva plataformas de 64 bits e provavelmente fornece uma versão de 64 bits como padrão com uma versão compilada de 32 bits como uma opção para os poucos clientes que não fizeram o upgrade para um novo computador e sistema operacional nos últimos 6 a 8 anos. .

— jwenting
fonte

1

Concordo principalmente, mas o fornecimento de versões de 32 e 64 bits acrescenta complexidade e provavelmente não deve ser feito sem uma boa lógica com base no desempenho ou na funcionalidade.

4

Entendo a necessidade de fornecer binários de 32 bits. Só não sei se ele deveria se preocupar em fornecer os nativos de 64 bits sem uma razão convincente.

1

Se eu estivesse lançando o software de desktop aqui em 2014, provavelmente lançaria apenas binários de 64 bits. Lembra nos anos 90 quando as pessoas estavam em transição do DOS para o Windows 95? Tivemos um argumento semelhante na época - e claramente o DOS ficou no pó, exatamente como agora está em 32 bits (pelo menos no desktop, não incorporado ou móvel).

4

Devo perguntar @jwenting. De onde você tirou 99%? Você poderia melhorar isso e postar a fonte?

— Malavos

1

Sim, eu não acredito nos 99%. O mundo dos negócios ainda possui muitas instalações do Windows de 32 bits por aí, entre máquinas antigas não atualizadas (executando o Win7 desde o início) ou por medo de incompatibilidades. "A maioria" é provavelmente de 64 bits, mas é improvável que eu acredite em uma porcentagem muito alta sem evidências muito boas.

— 21314 Joe

2

Eu testaria qualquer instalador no maior número possível de configurações do Windows, pois, pela minha experiência, é mais provável que os instaladores falhem em sistemas diferentes.

Caso contrário, como você sabe da sua experiência com o software fornecido , é pouco provável que os erros apareçam apenas em 32 ou 64 bits, e você pode correr algum risco calculado.

Em primeiro lugar, você deve ter muitos ciclos de teste com muito pouca alteração de código entre os ciclos posteriores à medida que se aproxima do envio. A qualquer momento que você pode salvar, você pode usar para criar mais casos de teste e / ou permitir mais ciclos (e, portanto, menores), fornecendo um feedback mais rápido. (O risco de gastar tempo testando X pode ser maior do que o risco de não testar Y, porque você está testando demais o X.)

Assim sendo

Tente testar na “outra testemunha” o que você usou para o ciclo de teste que se segue.
Se você conhece a "testemunha" que seu desenvolvedor usa, comece com os testes em outro.
Divida os casos de teste entre as "testemunhas" para dar cobertura sobre cada
Mas troque-os entre os "binnes" em cada ciclo de teste.

— Ian
fonte

2

Não. Da mesma forma, quando o FDA termina de testar novos medicamentos em camundongos e ratos, eles pulam os testes em macacos e apenas os vendem para consumo humano.

</ sarcasmo>

Sim Sim SIM SIM SIM. Não há nada além da tristeza reservada para o seu software se você não testar todas as plataformas que puder. As coisas são sempre diferentes, e as suposições na cabeça do designer / codificador durante o projeto geralmente só se aproximam da modelagem da vida real. Então, por favor, teste seu software. Por favor.

— kmort
fonte