64 비트 Windows에서 32 비트 소프트웨어를 테스트해야합니까?


31

소프트웨어 개발 팀에서 소프트웨어 개발자로 일하고 있습니다. 나는 지금 같은 프로젝트에서 3 년 동안 일해 왔습니다. 이 소프트웨어는 .NET 4의 32 비트 데스크톱 기반 C # 응용 프로그램입니다. Windows 7의 대상 플랫폼 (작년까지 Windows XP를 지원해야했습니다). 이 소프트웨어는 사용자 정의 드라이버가 작성된 다양한 사용자 정의 하드웨어와 통신합니다. 하드웨어 제조 및 드라이버 소프트웨어는 고객이 작성합니다. 물론 32 비트 및 64 비트 Windows 용 드라이버가 다릅니다.

시스템 테스트 단계에서 32 비트 및 64 비트 Windows 7 모두에서 모든 / 대부분의 테스트 사례를 실행합니다. 한 가지 맛의 Windows에만 존재하는 소프트웨어에 버그가 있는지 기억할 수 없습니다. 이 경험이 궁금해지기 시작했습니다. 실제로 64 비트 Windows에서 32 비트 소프트웨어를 테스트해야합니까?

업계 표준은 무엇입니까?


1
.NET 애플리케이션에 기본 DLL에 대한 종속성이 있습니까? 나는 주로 x64 DLL과 함께 x86 네이티브 DLL을 소프트웨어와 함께 패키지하는 것을 잊었 기 때문에 하나의 플랫폼에서만 테스트를 몇 번 물었습니다. 새로운 타사 라이브러리를 사용하기 시작하면 해당 라이브러리가 씬 뒤에 네이티브 DLL을로드하려고 시도 할 수 있으며 x86 PC에서 충돌 할 때까지 알 수 없습니다. 또한 내 .NET 앱이 64 비트 모드에서 실행 중인지 여부에 따라 사용할 DLL을 선택하는 코드를 작성해야했으며 해당 코드도 테스트해야합니다.
Phil

@ 필 : 지적했다. DLL은 많은 외부 라이브러리를 사용합니다. 모든 DLL이 x86 용으로 컴파일되었다고 생각합니다. 응용 프로그램 자체는 기본 DLL에 의존하지 않지만 기본 win32 API를 호출합니다.
Donotalo

답변:


31

64 비트 창에서 32 비트 소프트웨어를 실행할 때 발생하는 대부분의 버그는 소프트웨어 위치 ( Program Files (x86)대신 Program Files), 레지스트리 키 위치 (일부 Wow6432Node에서 발견)와 관련이있었습니다. 우리는 주로 다른 소프트웨어 (또한 32 비트)와 통신해야하기 때문에 이러한 문제가 있었으므로 32 비트 및 64 비트 모두에서 소프트웨어를 테스트해야했습니다 ...

이러한 문제가 없으면 32 비트 모드에서 명시 적으로 컴파일 할 때 두 플랫폼에서 테스트하지 않는 것이 안전하다고 생각합니다. 32 비트로 컴파일 될 때 .NET 런타임은 모든 것을 32 비트 모드로 실행하며 32 비트 플랫폼의 32 비트 모드와 동일하게 작동합니다.

에 따르면 64 비트 응용 프로그램 ( MSDN ), 32 비트 응용 프로그램은 WOW64 모드에서 실행되며, 실행되는 32 비트 응용 프로그램은 (MSDN)를 더 자세하게이 모드를 설명합니다.


64 비트 OS에서 실행되는 경우 32 비트 소프트웨어, 해당 OS의 .NET은 32 비트 모드에서 소프트웨어를 실행합니다. 이는 .NET의 32 비트 OS에서 소프트웨어를 실행하는 것과 동일합니까? 문서가 있습니까?
Donotalo

4
@Donotalo : "x86", "x64"및 "Any CPU"옵션을 사용하여 Visual Studio 구성 관리자 (또는 각 프로젝트의 컴파일 설정)에서 "플랫폼"이라는 기본 스위치에 대해 알려야합니다. 그 스위치를 찾았을 때 F1은 아마도 당신의 친구 일 것입니다.
Doc Brown

내 답변에 설명서가 추가되었습니다
David Perfors

1
우리가 겪었던 가장 큰 문제는 다른 32 비트 라이브러리에서 실행되었는데, .NET은 64 비트 시스템에서 실행할 때 단순히로드하지 못했습니다.
gbjbaanb '10

1
@gbjbaanb : "x86"을 플랫폼으로 사용하는 것을 잊었을 때의 의미입니다.
Doc Brown

23

하드웨어 제조 및 드라이버 소프트웨어는 고객이 작성합니다. 물론 32 비트 및 64 비트 Windows 용 드라이버가 다릅니다.

32 비트 Windows에서는 소프트웨어가 하나의 드라이버와 통신하고 64 비트 Windows에서는 다른 드라이버와 통신합니까? 때때로 이러한 드라이버의 새 버전이 있다고 가정 해 봅시다. 따라서 32 비트 Windows에서만 소프트웨어를 테스트 할 때 64 비트 드라이버에 약간의 차이가 없어서 소프트웨어 + 64 비트 드라이버의 조합이 실패하지 않을 것이라고 확신 할 수 없습니다. 그리고 사용자의 관점에서 볼 때 누가 당신 을 탓해야하는지 (사용자 또는 드라이버 작성자) 중요하지 않습니다. 그들이 보는 모든 것은 작동하지 않는 시스템입니다. 그래서 경우에도 귀하의 코드는 버그 무료 테스트는 64 비트 드라이버의 버그를 공개 수 있으며 이러한 버그를 발견하면 (드라이버의 저자에 버그 리포트를 보내 같은) 적절한 조치를 취할 도움이 될 수 있습니다.

물론,이 두 드라이버를 수년간 사용해 왔으며 그 동작이 정확히 동일하다고 확신 할 경우 @DavidPerfors의 답변에있는 인수에 따라 한 플랫폼에 대한 테스트를 건너 뛸 수 있습니다. 타협으로 새 드라이버 버전이 제공 될 때마다 64 비트 Windows에서 테스트를 실행할 수 있습니다. 실제로, 이것은 운전자의 복잡성, 경험과 자신감에 달려 있습니다.

고려해야 할 몇 가지 추가 사항 :

  • 가장 많이 사용하는 OS 유형은 무엇입니까? 32 비트 또는 64 비트 Windows? 하나의 플랫폼에서만 테스트하기로 결정한 경우 사용자가 가장 자주 사용하는 플랫폼을 선택하십시오.
  • 덜 자주 사용되는 플랫폼에서 소프트웨어의 새 릴리스가 작동하지 않을 때 얼마나 심각합니까? 예를 들어 고객이 즉시 이전 단계로 돌아가서 이전 작업 릴리스를 설치할 수 있습니까? 이로 인해 약간의 불편 함이나 실제 재정적 손실 만 있습니까? 전자 인 경우 하나의 플랫폼에서만 테스트해도되지만, 후자의 경우에는 그렇지 않을 수 있습니다.

16

계몽 된 QA 서클의 기본 가정은 '테스트하지 않으면 작동하지 않습니다'입니다.

응용 엔지니어들이 모든 것에 대한 단위 테스트를 원할 때와 거의 같은 방식으로 노력하는 것은 도달 할 수없는 목표입니다. 그러나 그들은 그들이 도달하고 예정대로 릴리스 될 것이라고 믿지 않습니다.

그러나 귀하의 질문은 판매 및 마케팅에 의해서만 또는 그와 관련하여 만 답변 될 수 있습니다. 테스트 비용을 제공하고 시장 이점에 대한 분석을 제공합니다. 에 추정하면 양쪽 면이 충분히 정확했다, 대답은 간단 할 것

if B > C:
    test_32bit_version()

내 경험상 모든 사람의 비용 견적이 정확하지 않습니다. 방정식의 다른 측면에서, Dilbert는 한 번 "내 방금 고양이에게 장갑을 물었다"고 의사 결정을 패러디했다. 훨씬 더 잘하려면 인류학 분야의 방법에 대한 훈련이 필요합니다.


계몽 된 QA 서클의 기본 가정은 '테스트하지 않으면 작동하지 않습니다'입니다. -작전 서클의 기본 가정은 "테스트하지 않았다면 화난 sysadmins에 의해 맹렬한 개처럼 사냥을 준비하십시오"입니다. 모든 시나리오를 테스트하기는 어렵지만 모든 합리적인 시나리오를 테스트하기 위해 열심히 노력하는 것이 좋습니다. 프로젝트 포스트 mortem이 시스템이 제대로 작동하는지 테스트하는 데 시간이 낭비되었다고 결정하는 경우는 매우 드 rare니다.
Rob Moir

6

Windows 7 이상의 모든 Windows 설치의 99 %와 Vista의 상당 부분이 64 비트인데, 왜 그 플랫폼을 테스트하지 않겠습니까?
알고있는 32 비트 Windows를 사용하는 매우 제한된 사용자 그룹을 위해 특별히 제작하지 않으면 제품 수명 기간 동안 계속 사용할 수 있습니다.

예, 64 비트 문제를 테스트하십시오. 실제로 64 비트 플랫폼에서 개발하고, 지난 6-8 년 정도 새 컴퓨터와 OS로 업그레이드하지 않은 소수의 고객을위한 옵션으로 32 비트 컴파일 버전을 표준으로 64 비트 버전을 제공 할 수 있습니다. .


1
나는 대부분 동의하지만 32 비트와 64 비트 버전을 모두 제공하면 복잡성이 추가되므로 성능이나 기능에 대한 합리적인 근거가 없으면 수행해서는 안됩니다.

4
32 비트 바이너리를 제공해야한다는 것을 이해합니다. 그가 설득력있는 이유없이 네이티브 64 비트를 공급 해야하는지 모르겠습니다.

1
2014 년에 데스크톱 소프트웨어를 출시 한 경우 64 비트 바이너리 만 출시 할 수 있습니다. 사람들이 DOS에서 Windows 95로 전환 한 90 년대를 기억하십니까? 우리는 그와 비슷한 주장을했고 32 비트가 지금처럼 (적어도 임베디드 나 모바일이 아닌 데스크탑에서는) DOS가 먼지 속에 남아있었습니다.

4
@jwenting에게 물어봐야합니다. 99 %라는 것을 어디서 얻었습니까? 그것을 개선하고 소스를 게시 할 수 있습니까?
Malavos

1
그래, 나는 99 %를 전혀 믿지 않는다. 비즈니스 세계에는 아직 업데이트되지 않은 오래된 컴퓨터 (초기부터 Win7 실행) 또는 비 호환성에 대한 두려움 사이에 32 비트 Windows 설치 가 여전히 많이 있습니다. "대다수"는 아마도 64 비트 일 것입니다. 그러나 아주 좋은 증거 없이는 높은 비율을 믿지 않을 것입니다.
Joe

2

필자의 경험에 따르면 설치 프로그램이 다른 시스템에서 실패 할 가능성이 가장 높은 다른 Windows 설정에서 모든 설치 프로그램을 테스트하려고합니다.

로 그렇지 않으면, 당신이 알고있는 당신의에서 경험주어진 소프트웨어 버그가 가장 가능성이 단지 32 비트 또는 64 비트에 표시, 당신은 몇 가지 계산 된 위험을 감수 할 수 있습니다.

첫째, 배송에 가까워 질수록 이후주기 사이에 코드 변경이 거의없는 많은 테스트주기가 있어야합니다. 저장할 수 있으면 언제든지 더 많은 테스트 사례를 작성하거나 더 많은 (그리고 더 작은)주기를 허용하여 더 빠른 피드백을 제공 할 수 있습니다. X를 너무 많이 테스트하기 때문에 X를 테스트하는 데 시간을 소비하는 위험은 Y를 테스트하지 않는 위험보다 더 클 수 있습니다.

따라서

  • 진행중인 테스트주기에 사용한“기타 비트”를 테스트하십시오.
  • 개발자가 사용하는“비트”를 알고 있다면 다른 테스트를 시작하십시오.
  • 테스트 사례를“비트 성”으로 나누면 각각에 적용됩니다.
  • 그러나 각 테스트주기에서 "빈"간에 전환하십시오.

2

아니. 마찬가지로, FDA가 생쥐와 쥐에 대한 신약 테스트를 완료하면 원숭이 실험을 건너 뛰고 사람이 소비하기 위해 판매합니다.

</ sarcasm>

예, 예 예 예 예 가능한 모든 플랫폼을 테스트하지 않으면 소프트웨어에 대한 슬픔은 없습니다. 상황은 항상 다르며 프로젝트 중 디자이너 / 코더의 머리 속에있는 가정은 일반적으로 실제 생활 모델링과 거의 유사합니다. 소프트웨어를 테스트하십시오. 부디.

당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.