> > To wychodzi w pokryciu kodu obiektowego.
>
> 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. 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".

> Ależ happens. Na ten przykład popularną metodą testowania kodu
> krytycznego, ale naprawdę krytycznego,

Łoł, ale tak naprawdę-naprawdę krytycznego, czy tylko naprawdę krytycznego?
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ą...

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

> No ale jednak happens.

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

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

> > Dlatego ten pomysł byłby potraktowany jako koszt bez wartości dodanej.
>
> 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, 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ź.

> 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ą i trzeba wykazać w jakim stopniu nowe
użycia pokrywają się ze starymi. Nie ma w tym nic nieracjonalnego.

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

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

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

[...]

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

--
Maciej Sobczak * http://www.inspirel.com