Чи потрібно тестувати 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

— Донотало
джерело

1

Чи має ваша програма .NET залежність від рідних DLL-файлів? Мене кілька разів вкусили лише тестування на одній платформі, головним чином тому, що я забув упакувати рідні DLL x86 разом із моїм програмним забезпеченням, а також DL64 x64. Якщо ви почнете використовувати нову сторонню бібліотеку, ця бібліотека також може спробувати завантажити рідні DLL за кадром, і ви не помітите, поки вона не вийде з ладу на комп'ютері x86. Я також повинен був написати код, який визначає, які DLL використовувати, залежно від того, чи працює мій додаток .NET у 64-бітному режимі чи ні, і цей код також потрібно перевірити.

— Філ

@Phil: Помічено. DLL використовує багато зовнішніх бібліотек. Я вважаю, що всі ці 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, ймовірно, ваш друг.

— Док Браун

До моєї відповіді додана документація

— Девід Перфорс

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

Припущення за промовчанням у просвітлених колах QA - "Якщо ви не тестували його, значить, воно не працює"

Що стосується практичного питання, до якого зазвичай досягають недосяжної мети, прагнути до того ж, що інженери-програми можуть хотіти проводити одиничні тести на все; але вони не вірять, що коли-небудь це досягнуть і випустять за графіком.

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

if B > C:
    test_32bit_version()

На мій досвід, оцінки всіх витрат неточні. Що стосується іншої сторони рівняння, Ділберт одного разу пародіював прийняття рішення там, "Я щойно попросив свого кота, Міттенс". Щоб зробити це набагато краще, їм знадобиться навчання методам антропологічної галузі.

— msw
джерело

Припущення за промовчанням у просвітлених колах QA - "Якщо ви не тестували його, значить, він не працює". - і припущення за замовчуванням в операційних колах - "Якщо ви цього не перевіряли, то будьте готові до того, що розлючені сисадміни будуть забиті, як скажена собака". Важко перевірити всі сценарії, але це гарна ідея, щоб випробувати всі розумні. Дуже рідко, коли проект після закінчення проекту вирішує, що витрачений час на тестування системи працює належним чином.

— Роб Моїр

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 проводить тестування нових ліків на мишах і щурах, вони пропускають тестування на мавпах і просто продають їх для споживання людиною.

</ сарказм>

Так, так, так, так. За вашим програмним забезпеченням немає нічого, крім смутку, якщо ви не протестуєте будь-яку платформу, яку, можливо, можете. Речі завжди різні, і припущення в дизайнері / кодері під час проекту, як правило, лише наближаються до моделювання реального життя. Тож будь ласка, протестуйте програмне забезпечення. Будь ласка.

— кморт
джерело