지금은 32 비트, 64 비트, Windows XP Home, Windows XP Pro, Windows Vista Home Basic, Windows Vista Ultimate, Windows 7 Home Basic 및 Windows 7 Ultimate ...에서 최신 버전으로 테스트 할 계획입니다. 서비스 팩.AMD 및 Intel 칩 모두에서 회귀 테스트 프로그램을 실행해야합니까?
그러나 지금은 위에 열거 된 모든 시나리오에 대해 AMD와 Intel 모두에서 테스트 해 볼 가치가 있는지 궁금해합니다. 아니면 시간 낭비일까요?
참고 : 이것은 평범한 일반 사용자를위한 보안 응용 프로그램입니다.
내 느낌은 당신이 최첨단 손으로 코딩 한 어셈블리 언어 나 엄청나게 긴밀한 타이밍을 가지고 있다면 가치가있을 것이라고 생각합니다. (어쨌든 당신은 그 운영체제를 선택하지 않을 것입니다.).
상용 컴파일러를 사용하고 있다면 모든 일반 프로세서에서 실행되는 코드를 생성 할 수 있습니다.
물론 특정 플랫폼에서 테스트 할 필요가 없다는 것을 입증 할 수있는 사람은 아무도 없었지만, 플랫폼 차이가 CPU 브랜드보다 걱정되는 원인이 더 많을 것이라고 생각합니다 (모든 다양한 멀티 코어/하이퍼 스레딩 순열 예를 들어, 모든 다중 스레드 코드 버그를 다른 방법으로 노출시킬 수 있습니다.)
나에게 시간 낭비가 될 것 같네요 - 어떤 언어가 프로그램에 쓰여 있습니까?
아니오라고 말하고 싶습니다. 어셈블러에서 응용 프로그램을 작성하지 않는 한, 차이점에 대해 걱정할 필요가 없도록 프로세서에서 멀리 떨어져 있어야합니다. 프로세서는 API가 사용중인 Windows OS를 지원합니다 (언어에 따라 다름). .NET을 사용하는 경우, 해당 플랫폼에서 지원하지 않는 프레임 워크 버전을 사용하는 경우에만 발생할 수있는 문제가 있습니다. XP 나 그 이후 버전이라면 괜찮을 것입니다. 걱정하고 싶다면 Vista 및 이후 보안 모델에서 응용 프로그램이 제대로 작동하는지 확인하십시오.
어셈블리에서 프로그래밍하고 확장 된 특정 명령 세트를 사용하는 경우에만. 그러나 AMD와 인텔은 크로스 라이센스 계약을 체결 했으므로 현재의 것보다 역사적인 문제가 더 많습니다.
다른 모든 경우 (예 : 고급 언어 사용) 컴파일러 작성자가 코드가 x86 호환이며 모든 CPU에서 실행되는지 확인하는 것이 좋습니다.
오, 그리고 FDIV Bug을 제외하고 일반적으로 프로세서 공급 업체는 실수를하지 않습니다.
"프로세서 공급 업체는 일반적으로 실수를하지 않습니다."임베디드 개발에서 작동하지 않습니다. –
질문은 아마도 "무엇을 테스트하고 있습니까?" AMD와 Intel 하드웨어 플랫폼간에 잠재적으로 다른 테스트를 테스트하는 것은 거의 불가능합니다. 차이점은 드라이버 수준에서 예상 할 수 있지만 주변에있는 모든 기존의 PC 하드웨어에 대해 소프트웨어를 테스트하지는 않습니다. 대부분의 경우 Windows 서비스 팩의 수준에 따라 AMD와 Intel 프로세서 간의 차이가 훨씬 클 것입니다.
일반 사용자를위한 보안 응용 프로그램입니다. –
코드에 일부 처리/최적화 기능을 활용하여 결과에 심각한 영향을 미칠 수있는 일부 기능이 있다고 가정합니다. 가능한 키워드.
나는 일반적으로 당신이 그것에 대해 걱정할 필요가 없다고 말할 것이다. 어쨌든 여러 대의 컴퓨터에서이 작업을 수행하려는 경우에는 여러 컴퓨터에서 혼합하십시오. 그러나 나는 그것에 대해 강조하지 않을 것이다.
AMD와 Intel 모두에서 회귀 테스트를 실행하지 않습니다. 특별히 하나의 문제 만 해결해야합니다. 그것이 회귀 테스트입니다.
단위 테스트 반면에 ... 나는 어떤 차이도 기대하지 않을 것입니다. 다시 한 번, AMD 나 Intel과 관련된 문제를 실제로 목격하기 전에는 두 가지 모두에 대해 단위 테스트를 실행하지 않아도됩니다.
시나리오를 테스트 할 때 잘못된 방향을 찾고 있다고 생각합니다.
예, 코드가 인텔에서는 작동하지만 AMD 또는 Windows Vista Home에서는 작동하지 않지만 Windows Vista Professional에서는 작동하지 않을 수 있습니다. 그러나 첫 번째 경우에 저수준 프로그래밍 또는 두 번째 OS 구현에 대한 세부 정보와 밀접하게 연관된 것을하지 않는 한 확률은 적습니다. 생각할 수있는 모든 시나리오를 테스트하는 것이 결코 아프지 않다고 말할 수 있습니다. 그러나 실생활에는 테스트를 위해 사용할 수있는 리소스에 약간의 제한이 있어야합니다. 다른 프로세서 또는 다른 OS에서 테스트하는 것은 대부분의 경우 프로그램을 테스트하지 않고 컴파일러, OS 또는 프로세서를 테스트하는 것입니다. 다른 사람들의 작업을 테스트하는 데 얼마의 시간을 할애해야합니까? 자신의 코드에서 더 많은 시나리오를 테스트하는 것이 시간 낭비라고 생각합니다. 앱이하는 일에 대해 자세히 설명하지는 않지만 자신의 사례 중 하나를 취하는 것만으로 우리 회사가 판매하는 제품을 테스트하는 데 하루를 보내거나 다른 제조업체에서 재판매 한 제품을 테스트하는 것이 훨씬 더 생산적 일 것입니다. 다른 주에 대한 판매 세 규칙 테스트 또는 기타.
실제로 Windows 배포와 Linux 배포 테스트는 거의하지 않으며 다른 버전의 Windows를 염두에 두지 않으며 거의 사용하지 않습니다.
저급 장치 드라이버 나 그 중 일부를 쓰는 경우에는 다른 이야기가됩니다. 하지만 일반 애플 리케이션? 시간을 낭비하지 마십시오.
가까운 장래에 거기에 배치 될 저수준 드라이버 물건이있을 것입니다. 그러나 지금은 매우 제한된 저수준 항목이 있습니다. 의견을 보내 주셔서 감사합니다. –
정확하고 일관된 부동 소수점 결과에 의존한다면 분명히 그렇습니다.
공정한 점 - Intel과 AMD 모두에서 생각할 수있는 모든 OS 조합을 테스트하는 것은 시간 낭비 일 것입니다. –
C++로 컴파일하고 VS2005로 컴파일합니다. –