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

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?

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.

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.

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.

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 .

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.

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ę.