Ponieważ coraz bardziej polegamy na komputerach, w tym na bardzo ważnych zadaniach codziennego życia, zastanawiałem się tylko, w jaki sposób testowane są te istotne elementy.
Z technicznego punktu widzenia, w jaki sposób testowane są kompilatory i asemblery? (Przypuszczam, że dotyczy to problemu zatrzymania !!)
programming-practices
compiler
theory
Sudip Bhandari
źródło
źródło
Odpowiedzi:
Nie możesz być pewien, ale zakładasz, że tak, dopóki nie odkryjesz, że nie są. Przez lata pojawiło się wiele błędów w kompilatorach i sprzęcie.
Sposób, w jaki są one testowane, na przykład kompilator, polega na tym, że są one bardzo wąsko i sztywno zdefiniowane, starannie napisane, a następnie przetestowane za pomocą ogromnego zestawu testów w celu zweryfikowania poprawności. Dodaj do tego szeroką bazę użytkowników kompilatora, a więcej błędów zostanie wykrytych i zgłoszonych. Dla porównania, aplikacja do planowania spotkań u dentysty ma znacznie mniej użytkowników, a jeszcze mniej jest w stanie wykryć wady.
SQLite składa się z około 73 tys. Linii kodu, a pakiet testowy składa się z około 91378 tys. Linii kodu, ponad 1250 razy więcej niż sam SQLite. Oczekuję, że kompilatory i inne podstawowe narzędzia mają podobne proporcje. Procesory są dziś projektowane głównie z oprogramowaniem, przy użyciu języków opisu sprzętu, takich jak Verilog lub VHDL, a na nich działają również testy oprogramowania, a także specjalne styki we / wy do przeprowadzania autotestów w miejscu produkcji.
Ostatecznie jest to gra prawdopodobieństwa, a powtarzane i szeroko zakrojone testy pozwalają obniżyć prawdopodobieństwo wystąpienia defektów do akceptowalnie niskiego poziomu, tak samo jak w przypadku innego projektu oprogramowania.
źródło
W kategoriach laika:
Konkluzja:
Powiedziałbym, że idź na OOP ( O ld, O pen i P opular). Właśnie wymyśliłem ten akronim.
źródło
Żółwie są na dole.
Nic nie jest pewne. Nie masz innego wyboru, jak oprzeć się na ocenach zaufania.
Możesz myśleć o tym jak o stosie: matematyka> fizyka> sprzęt> oprogramowanie układowe> system operacyjny> asembler / kompilator / itp.
Na każdym poziomie masz testy, które możesz wykonać, aby poprawić swoje oceny zaufania. Niektóre z tych testów mają jakość formalnych dowodów, niektóre oparte są na obserwacji, większość jest kombinacją obu.
Najtrudniejszą częścią jest rozwikłanie rekurencji w niektórych z tych testów, ponieważ używamy programów do przeprowadzania prób i analiz obserwacyjnych, w których zbyt trudno jest to zrobić ręcznie.
Ostatecznie jednak odpowiedź brzmi: próbujesz wszystkiego, co możesz wymyślić. Analiza statyczna, fuzzowanie, symulacja, uruchamianie z celowo wybranymi wejściami ekstremalnymi lub losowymi, uruchamianie / mapowanie każdej ścieżki kontroli, formalne dowody itp. Zasadniczo Twoim celem w testowaniu powinno zawsze być robienie wszystkiego, co możliwe, aby udowodnić, że Twój produkt (np. Teoria / chip / program) nie działa zgodnie z przeznaczeniem. Jeśli podejmiesz prawdziwy wysiłek i nadal nie uda ci się, możesz poprawić swój poziom pewności co do poprawności produktu.
Testowanie jest co najwyżej procesem półdecyzji, co oznacza, że biorąc pod uwagę błąd, w końcu go znajdziesz, ale nigdy nie możesz być pewien, że wszystkie je znalazłeś. Nawet w przypadku formalnie zweryfikowanego oprogramowania nadal polegasz na fizyce, narzędziach używanych do formalnych dowodów oraz że udowodniono, że to, co udowodniłeś, jest konieczne i wystarczające, aby Twój program zrobił to, co jest (często subiektywnie) „zamierzone”. Nie wspominając już o wszystkich innych używanych komponentach, które nie mają formalnych dowodów.
źródło
To jest „niebezpieczne” pytanie dla nowych programistów, ponieważ zaczną obwiniać swoje narzędzia zamiast kodu (już tam byli, zrobili to, widziałem, że zbyt wielu to robi). Chociaż występują błędy w kompilatorach, środowiskach uruchomieniowych, systemie operacyjnym itp., Programiści powinni być realistyczni i pamiętać, że dopóki nie pojawią się dowody i testy jednostkowe wykazujące inaczej, błąd znajduje się w kodzie .
Przez ponad 25 lat programowania głównie w C, C ++ i Javie znalazłem:
Wszystkie pozostałe błędy są bezpośrednio związane z błędem lub, częściej, z brakiem zrozumienia, jak działa biblioteka. Czasami coś, co wydaje się błędem, jest spowodowane niekompatybilnością, na przykład, jak zmieniła się struktura klasy Java, która zepsuła niektóre biblioteki AOP.
źródło
Myślę, że interesującą kwestią jest to, że zdecydowana większość licencji na oprogramowanie komercyjne (a nawet oprogramowanie typu open source) wyraźnie określa, że nie można ufać oprogramowaniu.
Z umowy licencyjnej Microsoft Word
Zasadniczo to zdanie w licencji w prawie każdym oprogramowaniu, z którego korzystasz, mówi ci konkretnie, że nie możesz ufać oprogramowaniu, nie mówiąc już o używanym kompilatorze.
Oprogramowanie jest jak teoria naukowa, uważa się, że działa tak, jak określono, dopóki nie zadziała.
źródło
Jako autor kompilatorów języka matematycznego * z mojego doświadczenia mogę powiedzieć, że teoretycznie nie możesz. A niektóre błędy dają po prostu błędne wyniki, takie jak (z mojej listy wstydów) obliczanie
6/3*2
od prawej6/(3*2)
i wyprowadzanie 1 bez awarii lub bezsensownych błędów kompilacji.Ale wiele kompilatorów IMHO nie ma tylu błędów, co inne oprogramowanie, ponieważ:
test_unit("2+(-2)*(-2+1)*3+1",9);
W przypadku asemblerów, instrukcji maszynowych itp. Powyższe mają również zastosowanie; z drugiej strony weryfikacja i walidacja w zakresie projektowania i produkcji układów mają znacznie bardziej rygorystyczne procesy, ponieważ jest to ogromny biznes: elektroniczna automatyzacja projektowania .
Przed przejściem do produkcji każdy procesor powinien zostać poddany rygorystycznym testom, ponieważ każdy błąd kosztuje prawie kilka milionów dolarów: w produkcji chipów występują ogromne jednorazowe koszty produkcji. Dlatego firmy wydają dużo pieniędzy i piszą dużo kodu symulacyjnego do swojego projektu przed rozpoczęciem produkcji, chociaż nie daje to 100% gwarancji - na przykład: błąd Pentium FDIV.
Krótko mówiąc, jest bardzo mało prawdopodobne, aby miały poważne błędy w kompilatorach, kodach maszynowych itp.
Mój skromny język matematyki *
źródło
Bez skazy? Oni nie są. Niedawno zainstalowałem kilka „aktualizacji” i minęły miesiące (i kilka przeprogramowanych sekcji kodu) później, zanim moja strona ASP.NET znów działała poprawnie, z powodu niewyjaśnionych zmian w działaniu różnych podstawowych rzeczy.
Są one jednak testowane, a następnie wykorzystywane przez wiele bardzo inteligentnych, zorientowanych na szczegóły osób, które zwykle zauważają, zgłaszają i naprawiają większość rzeczy. Stack Exchange to świetny przykład (i ulepszenie), w jaki sposób wszyscy ludzie używający tych narzędzi pomagają testować i analizować, jak działają te niezwykle złożone i niskiego poziomu narzędzia, przynajmniej w zakresie praktycznego zastosowania.
Ale bezbłędnie, nie. Chociaż można również zobaczyć, jak ludzie na Stack Exchange zyskują imponujący wgląd w szczegóły wydajności i zgodność z normami oraz dziwactwa, zawsze występują wady i niedoskonałości, szczególnie gdy różni ludzie mają różne opinie na temat tego, co to wada.
źródło
Aby pokazać, że systemy bazowe są bezbłędne
a) Potrzeba udowodnienia, że są bezbłędne
b) Wykonaj wyczerpujący test
W testowaniu oprogramowania wyczerpujący test jest wykorzystywany tylko do testowania jednostkowego niektórych prostych funkcji.
Przykład: Chcesz przetestować 8-znakowe wejście utf-8 w jakimś polu, dokonujesz wyboru, aby wyciąć wejście 8-krotną maksymalną długością 6 utf-8 w bajtach, co daje 8 * 6 = 48 bajtów skończone możliwości.
Można teraz pomyśleć, że wystarczy przetestować tylko 1112 064 poprawnych punktów kodowych każdego z 8 znaków, tj. 1112,064 ^ 8 (powiedzmy 10 ^ 48) testów (co jest już mało prawdopodobne), ale tak naprawdę trzeba przetestować każdą wartość każdego z 48 bajtów lub 256 ^ 48, która wynosi około 10 ^ 120, co jest takiej samej złożoności jak szachy w porównaniu do całkowitej liczby atomów we wszechświecie około 10 ^ 80.
Zamiast tego możesz używać, w kolejności rosnącej wysiłku, a każdy test powinien obejmować wszystkie poprzednie:
a) przetestuj dobrą i złą próbkę.
b) pokrycie kodu, tj. spróbuj przetestować każdy wiersz kodu, który jest względnie prosty dla większości kodów. Teraz możesz się zastanawiać, jaki jest ostatni 1% kodu, którego nie możesz przetestować ... błędy, martwy kod, wyjątki sprzętowe itp.
c) zasięg ścieżki, testowane są wszystkie wyniki wszystkich gałęzi we wszystkich kombinacjach. Teraz już wiesz, dlaczego dział testowy nienawidzi cię, gdy twoje funkcje zawierają więcej niż 10 warunków. Zastanawiasz się także, dlaczego ostatnich 1% nie można przetestować ... niektóre oddziały są zależne od poprzednich.
d) test danych, przetestuj liczbę próbek z wartością graniczną, typowymi problematycznymi wartościami i liczbami magicznymi, zero, -1, 1, min +/- 1, max +/- 1, 42, wartości rnd. Jeśli to nie da ci zasięgu, wiesz, że nie złapałeś wszystkich wartości w swojej analizie.
Jeśli już to zrobisz, powinieneś być gotowy do egzaminu podstawowego ISTQB.
źródło