On 08/10/2019 09:28, Maciej Sobczak wrote:
>> Najpierw musisz znaleźć metodę testowania która zawiera dostatecznie
>> dużo przypadków.
> Dalej nie kapujesz. Najpierw mam metodę mierzenia pokrycia. A potem, jeśli testy
nie dają wystarczającego pokrycia, szukam dziury.

Cały czas mówisz o tym jak znaleźć problem na testach. Niestety testy
nie latają.

> To nie musi być dziura w testach. To może być dziura w kompilatorze. Czyli nie
chodzi o to, żeby coś pokryć dużą liczbą testów, tylko żeby mieć świadomość, czemu
coś nie jest pokryte. To znaczy, że nie muszę mieć jakiejś specjalnej metody
testowania, żeby taką świadomość uzyskać a w omawianym przykładzie wcale nie trzeba
mieć "dostatecznie dużo przypadków".

Trzeba znaleźć dziurę w kompilatorze. Dziura nie została znaleziona
perfekcyjnymi testami *MOJEGO* kodu choć ujawniła się w MOIM kodzie na
produkcji. Samolot spada.

>> Ależ happens. Na ten przykład popularną metodą testowania kodu
>> krytycznego, ale naprawdę krytycznego,
> Łoł, ale tak naprawdę-naprawdę krytycznego, czy tylko naprawdę krytycznego?

Naprawdę naprawdę.

> Bo w tej dyskusji wspinasz się sięgając po coraż wyższe autorytety. Ostatnio było
nawet o rozmowie z człowiekiem mającym kontakt z brażną lotniczą...

No i? Myślisz że opowieści wyssałem z palca?

>> jest psucie go w czasie
>> rzeczywistym i patrzenie gdzie i co wybuchnie analizując czy jest czy
>> nie podatny na uszkodzenia.
> I nadal nie ma potrzeby używać wielu kompilatorów. Skup się.

Pokazuje to jak ważna jest statystyka kiedy wyczerpiesz metody ścisłe.

>> No ale jednak happens.
> No ale jednak nie pokazałeś żadnego przekonywującego przykładu.

Podobnie jak administrator sieci nie potrafi pokazać żadnego
przekonywującego przykładu że jest potrzebny.

>> Inaczej: akurat w tej branży testuje się kilkoma innymi metodami
>> również.
> I właśnie dlatego nie potrzeba wielu kompilatorów. Do tego wniosku asymptotycznie
zmierzamy.

Nie, kiedy już wyczerpiesz zasoby ścisłe pojawia się statystyka. Analiza
randoiczna testów, upewnianie się co do kodu w różnych narzędziach itd itp.

>> Nie "byłby" tylko jest stosowany. Może bardziej w HDLu ale w normalnym
>> programowaniu też.
> Rozumiem. Czyli jeśli nie udało się wykazać sensowności użycia wielu kompilatorów

Ją się już dawno udało wykazać, tylko ciągle WYDAJE ci się że jak
sprawdziłeś kod metodami testującymi takimi a siakimi to nagle wszelakie
nieznane i znane bledy w kompilatorze masz pod kontrolą. Nie masz.

>, to trzeba napisać "bardziej w HDLu" a potem dodać "ale tu też". I jest szansa, że
przypadkowy czytelnik dostrzeże w tym wartościową wypowiedź.

Podobnie jak w bredzeniu że ktoś bredzi. HDL akurat ma testowanie
rozwięte do granic absurdu.

>> Różnie bywa. Taka ciekawostka: weryfikację narzędzia robi się czasem na
>> słowo honoru: "działa od dziesięciu lat i nie ma problemu". Serio mówie.
> To się nazywa Previously Developed Software. Tak. Ale to nie jest słowo honoru, bo
historię użycia trzeba mieć udokumentowaną

Owszem. Udokumentowanie polega na obserwacji, statystycznej i
subiektywanej, że działa.

> i trzeba wykazać w jakim stopniu nowe użycia pokrywają się ze starymi. Nie ma w tym
nic nieracjonalnego.

Oczywisćie. W końcu pisali helloworlda i piszą teraz innego helloworlda.
To TAKIE trywialne pokazać że mają ten sam kod, kompilwoany tak samo i
to coś zapewnia. Utopia.

>> Musisz zagwarantować że twój pewny kompilator jest pewny dla kodu
>> którego jeszcze nie ma.
> Jest dokładnie odwrotnie (czyli jak już pisałem, mylisz pojęcia).
> Uważaj:
> "Upon successful completion of verification of the software product, the compiler
is considered acceptable for that product."
> "Although the compiler is considered acceptable once all of the verification
> objectives are satisfied, the compiler is only considered acceptable for that
product and not necessarily for other products."
> Czyli o tym, że kompilator *był* dobry wiadomo dopiero jak się nim zrobi produkt.

Niebywałe. Czyli innymi słowy gadanie o tym że się go wybiera PRZED nie
miało sensu?

> Natomiast nie zakłada się, że *będzie* dobry, zanim się tego produktu nie zrobi. Bo
proces jest tak ustawiony, że wcale na tym założeniu nie polega.

Super. Innymi słowy może być zły? Ojej, to będzie trzeab użyć innego?
Ojejejej. Niemożliwe, przecież nie wolno:

"projekt zaczyna się mając już zatwierdzone narzędzia.".

No to lekka dupa, trzeba zauważyć.

Prosze, opisz jak wygląda koncepcja zrobnienia SWOJEGO projektu na
nieznanym kompilatorze i udowodnienia formalnie w ten sposób że jest
dobry. Z chęcią poczytam. Obawiam się jednak że wniosek będzie że jest
dobry do testów na których był testowany a i to będzie naciągane jak
guma z majtek.

> Zapytaj kolegę od samolotów, skąd są te cytaty.

Ze śmiesznych norm ISO i DO? Dokumentów szkoleniowych Tuv? Z publikacji
naukowych? Z poważnych książek z długimi tytułami?

>> Albo z miejsca gdzie siedzę widać coś innego niż z Twojego.
> Na to wygląda. Ale też dlatego nie mam zamiaru się w nieskończoność szarpać.

Ależ nie musisz. Ja najzwyczajniej w świecie doskonale sobie zdaje
sprawę w jakiej utopii testowania siedzi pół świata. I jak absurdalnymi
metodami staraja się z niej wydobyć.

>> Nikt nie naciska na kilka kompilatorów.
> Hura!
>> Ale kilku wielkich graczy
>> zdecydowało się na to.
> "Pewni ludzie", "niektórzy", "chodzą głosy", "ktoś mi opowiadał", itp...

Więc zapewne już rozumiesz że czasami o detalach nie można mówić. I nie
dlatego że nie istnieją tylko dlatego że takie mamy reguły gry na tym
rynku. To nie GitHub i nie każdy z woich rozmówców to dzieciak. Zrób
założenie inne, może się rozjaśni dlaczego nie każdy ma prawo i
możliwość mówienia o detalach, nazwach i nazwiskach.