Нужно ли тестировать 32-битное программное обеспечение в 64-битной Windows?

31

Я работаю в команде разработчиков программного обеспечения в качестве разработчика программного обеспечения. Я работаю над тем же проектом уже три года. Это 32-битное приложение на C # для настольных компьютеров в .NET 4. Наша целевая платформа в Windows 7 (до прошлого года мы должны были поддерживать Windows XP). Программное обеспечение взаимодействует с различным пользовательским оборудованием, для которого написаны пользовательские драйверы. Программное обеспечение для производства оборудования и драйверов написано нашим клиентом. Конечно, есть разные драйверы для 32-битной и 64-битной Windows.

На этапе тестирования системы мы выполняем все / большинство тестовых случаев как в 32-битной, так и в 64-битной Windows 7. Я не могу вспомнить, были ли у нас какие-либо ошибки в нашем программном обеспечении, которые существуют только в одном варианте Windows. Имея этот опыт, я начал задаваться вопросом, нужно ли нам тестировать 32-битное программное обеспечение на 64-битной Windows?

Какой отраслевой стандарт?

windows compatibility industry-standard

— Donotalo
источник

1

Ваше приложение .NET имеет какие-либо зависимости от нативных DLL? Несколько раз меня укусили только на одной платформе, потому что я забыл упаковать собственные библиотеки x86 вместе с моим программным обеспечением вместе с библиотеками x64. Если вы начнете использовать новую стороннюю библиотеку, эта библиотека может также попытаться загрузить собственные DLL за кулисами, и вы не заметите, пока она не выйдет из строя на ПК с архитектурой x86. Мне также пришлось написать код, который выбирает, какие библиотеки DLL использовать, основываясь на том, работает ли мое .NET-приложение в 64-битном режиме или нет, и этот код также должен быть протестирован.

— Фил

@Phil: Точка отмечена. DLL использует много внешних библиотек. Я считаю, что все эти библиотеки скомпилированы для x86. Само приложение не имеет никакой зависимости от собственных DLL, но оно вызывает собственный API Win32.

— Донотало

31

Большинство ошибок, с которыми мы сталкивались при запуске 32-битного программного обеспечения в 64-битных окнах, были связаны с расположением программного обеспечения ( Program Files (x86)а не с Program Files), расположением ключей реестра (некоторые были найдены в Wow6432Node). У нас были эти проблемы в основном потому, что нам нужно было общаться с другим программным обеспечением (также 32-разрядным), и поэтому нам нужно было протестировать программное обеспечение как на 32-разрядном, так и на 64-разрядном ...

Когда у вас не было этих проблем, я полагаю, что безопасно не тестировать на обеих платформах, когда вы явно компилируете в 32-битном режиме. При компиляции в 32-битной среде .NET все будет работать в 32-битном режиме, и она должна работать так же, как 32-битный режим на 32-битных платформах.

Согласно 64-разрядным приложениям ( MSDN ), 32-разрядные приложения выполняются в режиме Wow64, а « Запуск 32-разрядных приложений» (MSDN) объясняет этот режим более подробно.

— Дэвид Перформс
источник

Вы говорите, что 32-битное программное обеспечение, если оно работает на 64-битной ОС, .NET на этой ОС будет запускать программное обеспечение в 32-битном режиме - что аналогично запуску программного обеспечения в 32-битной ОС в .NET? Есть ли документация?

— Донотало

4

@Donotalo: вы должны узнать о базовом переключателе в вашем менеджере конфигурации Visual Studio (или настройках компиляции каждого проекта), названном «платформа», с опциями «x86», «x64» и «Any CPU». Когда вы нашли этот переключатель, F1, вероятно, ваш друг.

— Док Браун

К моему ответу добавлена документация

— David Perfors

1

Самая большая проблема, с которой мы столкнулись, - это запуск других 32-битных библиотек. .NET просто не сможет загрузить их при работе на 64-битной машине.

— gbjbaanb

1

@gbjbaanb: вы наверняка имели в виду, когда забыли использовать «x86» в качестве платформы.

— Док Браун

23

Программное обеспечение для производства оборудования и драйверов написано нашим клиентом. Конечно, есть разные драйверы для 32-битной и 64-битной Windows.

Итак, в 32-битной Windows ваше программное обеспечение взаимодействует с одним драйвером, а в 64-битной Windows - с другим? Допустим, время от времени появляются новые версии этих драйверов. Поэтому, когда вы тестируете свое программное обеспечение только в 32-битной Windows, вы не можете быть уверены, что в 64-битном драйвере не будет каких-либо различий, которые приведут к ошибке комбинации вашего программного обеспечения и 64-битного драйвера. И с точки зрения ваших пользователей, не имеет значения, кто виноват (вы или автор драйвера), все, что они видят, - это нерабочая система. Таким образом, даже если ваш код не содержит ошибок, тест может выявить ошибку в 64-разрядном драйвере, и обнаружение такой ошибки может помочь вам принять правильные меры (например, отправить отчет об ошибке автору драйвера).

Конечно, если вы использовали эти два драйвера в течение многих лет и уверены, что их поведение одинаково, вы можете пропустить тесты для одной платформы, следуя аргументам в ответе @ DavidPerfors. В качестве компромисса вы можете запускать тесты на 64-битной Windows только тогда, когда доступна новая версия драйвера. На самом деле, это зависит от сложности драйверов, вашего опыта и уверенности в них.

Некоторые дополнительные вещи для рассмотрения:

Какой тип ОС использует ваша пользовательская база? 32-битная или 64-битная Windows? Если вы решили проводить тестирование только на одной платформе, выберите ту, которую ваши пользователи используют чаще всего.
Насколько это серьезно, когда новый выпуск программного обеспечения не будет работать на менее часто используемой платформе? Например, могут ли ваши клиенты немедленно отступить и установить предыдущий рабочий выпуск? У них есть только некоторые неудобства или реальные финансовые потери от этого? Если это первое, тестирование только на одной платформе может быть хорошо, если это последнее, очевидно, нет.

— Док Браун
источник

16

Предположение по умолчанию в просвещенных кругах контроля качества: «Если вы его не тестировали, значит, оно не работает».

С практической точки зрения это обычно недостижимая цель, к которой стремиться во многом так же, как разработчики прикладных программ хотели бы провести модульные тесты для всего; но они не верят, что когда-либо достигнут этого и выпустят по расписанию.

Однако на ваш вопрос могут ответить только продажи или маркетинг. Вы предоставляете им стоимость для тестирования, и они предоставляют анализ рыночной выгоды. Если бы оценки с обеих сторон были достаточно точными, ответ был бы простым

if B > C:
    test_32bit_version()

По моему опыту, все оценки затрат являются неточными. Что касается другой стороны уравнения, Дилберт однажды пародировал принятие решения там: «Я только что спросил мою кошку, Миттенс». Чтобы добиться большего успеха, им понадобится обучение методам антропологического поля.

— MSW
источник

Предположение по умолчанию в просвещенных кругах контроля качества: «Если вы его не тестировали, значит, оно не работает». - а в рабочих кругах по умолчанию используется предположение: «Если вы не проверяли это, то будьте готовы к тому, что вас будут разыскивать злобные сисадмины, как бешеную собаку». Трудно проверить все сценарии, но это хорошая идея, чтобы попробовать все разумные сценарии. Очень редко после вскрытия проекта решается, что время, потраченное на проверку работоспособности системы, было потрачено впустую.

— Роб Мойр

6

Учитывая, что 99% всех установок Windows с Windows 7 и более поздних версий, а также значительная часть Vista также являются 64-разрядными, почему, черт возьми, вы даже подумаете не тестировать эту платформу?
Это просто и понятно, если только вы не делаете это специально для очень ограниченной группы пользователей, вы ЗНАЕТЕ, что используете 32-битную Windows и будете продолжать это делать в течение всего срока службы вашего продукта.

Так что да, тест на 64-битные проблемы. Фактически разрабатывается на 64-битных платформах и, вероятно, поставляет 64-битную версию в стандартной комплектации с 32-битной скомпилированной версией в качестве опции для тех немногих клиентов, которые не переходили на новый компьютер и ОС в течение последних 6-8 лет или около того ,

— jwenting
источник

1

Я согласен в основном, но предоставление 32- и 64-битных версий добавляет сложности и, вероятно, не должно быть сделано без хорошего обоснования, основанного на производительности или функциональности.

4

Я понимаю необходимость поставлять 32-битные двоичные файлы. Я просто не знаю, стоит ли ему предлагать родные 64-битные без веской причины.

1

Если бы я выпускал настольное программное обеспечение здесь в 2014 году, я бы, вероятно, выпустил только 64-битные двоичные файлы. Помните 90-е годы, когда люди переходили с DOS на Windows 95? Тогда у нас был похожий аргумент - и ясно, что DOS остался в пыли, как 32-битный сейчас (по крайней мере, на настольном компьютере, а не на встроенном или мобильном).

4

Я должен спросить @jwenting. С чего ты взял что это 99%? Не могли бы вы улучшить это и опубликовать источник?

— Малавос

1

Да, я не верю 99% вообще. В деловом мире все еще существует множество 32-битных установок Windows, между старыми машинами, которые не обновляются (с самого начала работали под Win7) или из-за боязни несовместимости. «Большинство», вероятно, являются 64-битными, но я вряд ли поверил бы в очень высокий процент без очень веских доказательств.

— Джо

2

Я бы протестировал любой установщик на как можно большем количестве различных настроек Windows, так как по моему опыту установщики, скорее всего, выйдут из строя на разных системах.

В противном случае, как вы знаете по своему опыту работы с данным программным обеспечением, ошибки вряд ли будут просто обнаруживаться на 32-разрядных или 64-разрядных системах, и вы можете пойти на определенный расчетный риск.

Во-первых, у вас должно быть много циклов тестирования с небольшим изменением кода между последующими циклами, когда вы приближаетесь к отправке. В любое время, когда вы можете сэкономить, вы можете использовать для создания большего количества тестовых случаев и / или разрешать больше (и, следовательно, меньше) циклов, что обеспечивает более быструю обратную связь. (Риск тратить время на тестирование X может быть больше, чем риск не тестировать Y, потому что вы слишком много тестируете X.)

Следовательно

Попробуйте проверить «другую битность» на то, что вы использовали в последующем цикле тестирования.
Если вы знаете «битность», которую использует ваш разработчик, начните с тестирования на другом.
Разделите контрольные примеры между «битностью», чтобы охватить каждую
Но меняйте их между «биннами» в каждом цикле испытаний.

— Ян
источник

2

Нет. Аналогично, когда FDA завершает тестирование новых лекарств на мышах и крысах, они пропускают тестирование на обезьянах и просто продают его для потребления человеком.

</ сарказм>

Да да да да да Нет ничего, кроме печали в вашем программном обеспечении, если вы не тестируете каждую платформу, какую только можете. Вещи всегда разные, и предположения в голове дизайнера / кодировщика во время проекта обычно очень близко подходят к моделированию реальной жизни. Поэтому, пожалуйста, протестируйте свое программное обеспечение. Пожалуйста.

— kmort
источник