Czy musimy testować oprogramowanie 32-bitowe w 64-bitowym systemie Windows?

31

Pracuję w zespole programistów jako programista. Pracuję nad tym samym projektem od trzech lat. Oprogramowanie to 32-bitowa aplikacja C # na platformie .NET 4. Nasza platforma docelowa w systemie Windows 7 (do ubiegłego roku musieliśmy obsługiwać system Windows XP). Oprogramowanie komunikuje się z różnymi niestandardowymi urządzeniami, dla których zostały napisane niestandardowe sterowniki. Oprogramowanie do produkcji i sterowników zostało napisane przez naszego klienta. Oczywiście istnieje inny sterownik dla 32-bitowego i 64-bitowego systemu Windows.

Podczas fazy testowania systemu wykonujemy wszystkie / większość przypadków testowych zarówno w 32-bitowym, jak i 64-bitowym systemie Windows 7. Nie mogę sobie przypomnieć, czy w naszym oprogramowaniu występuje błąd, który występuje tylko w jednym systemie Windows. Po tym doświadczeniu zacząłem się zastanawiać, czy naprawdę musimy testować oprogramowanie 32-bitowe w 64-bitowym systemie Windows?

Jaki jest standard branżowy?

Donotalo
źródło
1
Czy Twoja aplikacja .NET ma jakieś zależności od rodzimych bibliotek DLL? Zostałem ugryziony kilka razy tylko na jednej platformie, głównie dlatego, że zapomniałem spakować natywne biblioteki DLL x86 wraz z moim oprogramowaniem wraz z bibliotekami DLL x64. Jeśli zaczniesz używać nowej biblioteki innej firmy, może ona również próbować załadować natywne biblioteki DLL za kulisami i nie zauważysz, dopóki nie ulegnie awarii na komputerze z procesorem x86. Musiałem także napisać kod, który wybiera biblioteki DLL do użycia na podstawie tego, czy moja aplikacja .NET działa w trybie 64-bitowym, czy nie, i ten kod również musi zostać przetestowany.
Phil
@Phil: Punkt zanotowany. Biblioteka DLL używa wielu bibliotek zewnętrznych. Wierzę, że wszystkie te biblioteki DLL są skompilowane dla x86. Sama aplikacja nie ma żadnej zależności od natywnych bibliotek DLL, ale wywołuje natywny interfejs API win32.
Donotalo

Odpowiedzi:

31

Większość błędów, które napotkaliśmy podczas uruchamiania 32-bitowego oprogramowania w 64-bitowych oknach, dotyczyła lokalizacji oprogramowania ( Program Files (x86)zamiast Program Files), lokalizacji kluczy rejestru (niektóre znaleziono w Wow6432Node). Mieliśmy te problemy głównie dlatego, że musieliśmy komunikować się z innym oprogramowaniem (także 32-bitowym), więc musieliśmy przetestować oprogramowanie zarówno na 32-bitowym, jak i 64-bitowym ...

Jeśli nie masz tych problemów, uważam, że nie jest bezpieczne testowanie na obu platformach, jeśli kompilujesz je w trybie 32-bitowym. Po skompilowaniu w wersji 32-bitowej środowisko uruchomieniowe .NET będzie działać w trybie 32-bitowym i powinno działać tak samo, jak tryb 32-bitowy na platformach 32-bitowych.

Według aplikacji 64-bitowych ( MSDN ) aplikacje 32-bitowe są uruchamiane w trybie Wow64, a Uruchamianie aplikacji 32-bitowych (MSDN) wyjaśnia ten tryb bardziej szczegółowo.

David Perfors
źródło
Czy mówisz, że 32-bitowe oprogramowanie, jeśli jest uruchomione w 64-bitowym systemie operacyjnym, .NET w tym systemie operacyjnym uruchomi oprogramowanie w trybie 32-bitowym - co jest identyczne z uruchomieniem oprogramowania w 32-bitowym systemie operacyjnym w .NET? Czy jest jakaś dokumentacja?
Donotalo
4
@Donotalo: powinieneś dowiedzieć się o podstawowym przełączniku w menedżerze konfiguracji Visual Studio (lub ustawieniach kompilacji każdego projektu) o nazwie „platforma”, z opcjami „x86”, „x64” i „Dowolny procesor”. Gdy znajdziesz ten przełącznik, F1 jest prawdopodobnie twoim przyjacielem.
Doc Brown
Dokumentacja została dodana do mojej odpowiedzi
David Perfors
1
Największym problemem, jaki mieliśmy, było uruchamianie z innymi bibliotekami 32-bitowymi .NET po prostu nie ładowałby ich, gdy byłby uruchomiony na komputerze 64-bitowym.
gbjbaanb
1
@gbjbaanb: na pewno miałeś na myśli, gdy zapomniałeś użyć „x86” jako platformy.
Doc Brown
23

Oprogramowanie do produkcji i sterowników zostało napisane przez naszego klienta. Oczywiście istnieje inny sterownik dla 32-bitowego i 64-bitowego systemu Windows.

Tak więc w 32-bitowym systemie Windows oprogramowanie komunikuje się z jednym sterownikiem, a w 64-bitowym systemie Windows z innym sterownikiem? Załóżmy, że od czasu do czasu pojawiają się nowe wersje tych sterowników. Więc kiedy testujesz oprogramowanie tylko w 32-bitowym systemie Windows, nie możesz być pewien, że nie będzie żadnych różnic w 64-bitowym sterowniku, co spowoduje, że połączenie twojego oprogramowania + 64-bitowego sterownika nie powiedzie się. Z punktu widzenia użytkowników nie ma znaczenia, kto jest winny (ty lub autor sterownika), wszystko, co widzą, to niedziałający system. Więc nawet jeśli twój kod jest wolny od błędów, test może wykryć błąd w 64-bitowym sterowniku, a znalezienie takiego błędu może pomóc w podjęciu właściwych kroków (takich jak wysłanie raportu o błędzie do autora sterownika).

Oczywiście, kiedy używasz tych dwóch sterowników od lat i jesteś bardzo pewny, że zachowanie jest dokładnie takie samo, możesz pominąć testy dla jednej platformy, postępując zgodnie z argumentami zawartymi w odpowiedzi @ DavidPerfors. Jako kompromis można przeprowadzać testy w 64-bitowym systemie Windows tylko wtedy, gdy dostępna jest nowa wersja sterownika. W rzeczywistości zależy to od złożoności sterowników, doświadczenia i zaufania do nich.

Kilka dodatkowych rzeczy do rozważenia:

  • jakiego typu systemu operacyjnego używa Twoja baza użytkowników? 32-bitowy lub 64-bitowy system Windows? Jeśli zdecydujesz się przetestować tylko na jednej platformie, wybierz tę, z której najczęściej korzystają użytkownicy.
  • jak poważne jest to, że nowa wersja oprogramowania nie będzie działać na rzadziej używanej platformie? Na przykład, czy Twoi klienci mogą natychmiast wycofać się i zainstalować poprzednią wersję roboczą? Czy z tego powodu mają tylko jakieś niedogodności lub rzeczywiste straty finansowe? Jeśli tak, to testowanie tylko na jednej platformie może być w porządku, jeśli tak, to oczywiście nie.
Doktor Brown
źródło
16

Domyślne założenie w oświeconych kręgach kontroli jakości to „Jeśli go nie przetestowałeś, to nie działa”.

W praktyce jest to zazwyczaj nieosiągalny cel, którym jest dążenie w taki sam sposób, w jaki inżynierowie aplikacji mogą chcieć mieć testy jednostkowe na wszystko; ale nie wierzą, że kiedykolwiek to osiągną i wydadzą zgodnie z harmonogramem.

Jednak na twoje pytanie można odpowiedzieć wyłącznie poprzez sprzedaż lub marketing. Zapewniasz im koszt testowania, a oni dostarczają analizy korzyści rynkowych. Gdyby szacunki po obu stronach były wystarczająco dokładne, odpowiedź byłaby prosta

if B > C:
    test_32bit_version()

Z mojego doświadczenia wynika, że ​​szacunki kosztów wszystkich są niedokładne. Jeśli chodzi o drugą stronę równania, Dilbert kiedyś parodiował podejmowanie decyzji za pomocą „Właśnie zapytałem mojego kota, mitenki”. Aby uzyskać znacznie lepsze wyniki, potrzebowaliby szkolenia w zakresie metod antropologicznych.

msw
źródło
Domyślne założenie w oświeconych kręgach kontroli jakości to „Jeśli go nie przetestowałeś, to nie działa”. - a domyślne założenie w kręgach operacyjnych brzmi: „Jeśli tego nie przetestowałeś, bądź przygotowany na ściganie go jak wściekły pies przez gniewnych administratorów”. Trudno jest przetestować wszystkie scenariusze, ale dobrze jest spróbować przetestować wszystkie rozsądne. Bardzo rzadko zdarza się, że sekcja zwłok decyduje, że czas poświęcony na testowanie działania systemu byłby stracony.
Rob Moir
6

Biorąc pod uwagę, że 99% wszystkich instalacji Windows 7 i wyższych, a także spora część Visty, są 64-bitowe, dlaczego, u diabła, w ogóle wziąłbyś pod uwagę testowanie tej platformy?
Jest to oczywiste, chyba że robisz to specjalnie dla bardzo ograniczonej grupy użytkowników, których WIESZ, że używasz 32-bitowego systemu Windows i nadal będziesz to robić przez cały okres użytkowania produktu.

Więc tak, sprawdź 64-bitowe problemy. W rzeczywistości rozwijają się na platformach 64-bitowych i prawdopodobnie dostarczają wersję 64-bitową jako standard z 32-bitową wersją skompilowaną jako opcję dla tych kilku klientów, którzy nie dokonali aktualizacji do nowego komputera i systemu operacyjnego w ciągu ostatnich 6-8 lat .

jwenting
źródło
1
Zgadzam się głównie, ale dostarczanie zarówno wersji 32-, jak i 64-bitowej zwiększa złożoność i prawdopodobnie nie powinno się tego robić bez dobrego uzasadnienia opartego na wydajności lub funkcjonalności.
4
Rozumiem potrzebę dostarczania 32-bitowych plików binarnych. Po prostu nie wiem, czy powinien zawracać sobie głowę dostarczaniem natywnych 64-bitowych bez ważnego powodu.
1
Gdybym w 2014 r. Wypuszczał oprogramowanie komputerowe, prawdopodobnie wydałbym tylko 64-bitowe pliki binarne. Pamiętasz lata 90., kiedy ludzie przechodzili z DOS na Windows 95? Wówczas mieliśmy podobny argument - i najwyraźniej DOS został w tyle, tak jak teraz 32-bitowy (przynajmniej na komputerze, nie jest osadzony ani mobilny).
4
Muszę zapytać @jwenting. Skąd masz, że to 99%? Czy możesz to poprawić i opublikować źródło?
Malavos
1
Tak, nie wierzę w 99%. Świat biznesu wciąż ma wiele 32-bitowych instalacji systemu Windows, między starymi maszynami, które nie zostały zaktualizowane (z systemem Windows 7 od wczesnych dni) lub z obawy przed niezgodnością. „Większość” jest prawdopodobnie 64-bitowa, ale bardzo mało prawdopodobne jest, aby uwierzyć w jakikolwiek bardzo wysoki odsetek bez bardzo dobrych dowodów.
Joe
2

Testowałbym każdy instalator na tak wielu różnych konfiguracjach systemu Windows, jak to możliwe, ponieważ z mojego doświadczenia wynika, że ​​instalatory najprawdopodobniej zawiodą w różnych systemach.

W przeciwnym razie, jak wiesz z doświadczenia z danego oprogramowania, błędy są najbardziej prawdopodobne, aby tylko pokazać się na 32-bitową lub 64-bitową i można trochę obliczone ryzyko.

Po pierwsze, powinieneś mieć wiele cykli testowych z bardzo małą zmianą kodu między późniejszymi cyklami, gdy zbliżasz się do wysyłki. Za każdym razem, gdy możesz zaoszczędzić, możesz użyć do stworzenia większej liczby przypadków testowych i / lub pozwolić na więcej (a więc i mniejszych) cykli, dzięki czemu szybciej otrzymujesz informacje zwrotne. (Ryzyko spędzenia czasu na testowaniu X może być większe niż ryzyko braku testowania Y, ponieważ zbyt dużo testujesz X.)

W związku z tym

  • Spróbuj przetestować „inną bitowość” w stosunku do tego, co wykorzystałeś w kolejnym cyklu testowym.
  • Jeśli znasz „bitowość” używaną przez programistę, zacznij od testowania na innym.
  • Podziel przypadki testowe na „bitity”, aby uzyskać zasięg każdego z nich
  • Ale zamień je między „binnes” w każdym cyklu testowym.
Ian
źródło
2

Nie. Podobnie, kiedy FDA kończy testy nowych leków na myszach i szczurach, pomijają testy na małpach i po prostu sprzedają je do spożycia przez ludzi.

</ sarkazm>

Tak tak tak tak tak. Nie ma nic prócz smutku dla twojego oprogramowania, jeśli nie przetestujesz każdej możliwej platformy. Rzeczy są zawsze inne, a założenia w głowie projektanta / programisty podczas projektu zwykle pasywnie zbliżają się do modelowania prawdziwego życia. Więc proszę przetestuj swoje oprogramowanie. Proszę.

kmort
źródło