Całkiem ta grupa zdechła, czy jest jeszcze nadzieja? :-)

Jest taki temat jak generowanie testów i są też różne stopnie pokrycia testami, które
się definiuje (i wymaga) w rygorystycznych procesach. Okazuje się jednak, że
wyrażenie logiczne można napisać tak źle, że nie będzie możliwe wygenerowanie dla
niego testów z odpowiednim pokryciem - coś jakby odpowiednik nieosiągalnego kodu gdy
np. jakaś gałąź warunkowa nigdy się nie wykonuje.

Da się w miarę prosto wygenerować testy na sprawdzenie, czy dane wyrażenie można
pokryć właściwymi testami:

http://inspirel.com/articles/Implementing_Logic_Reac
hability_Checks.html

Ktoś się na grupie zajmuje takimi tematami? :-)

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

do góry

boże co to się w dzisiejszej IT dzieje, człowiek to nawet nie wie jaki
jest głupi... także dzięki i za te ochłapy z pańskiego stołu...

domyślam się, że coś takiego nie da się zrobić:
0001
0010
0100
1000

a w ogóle to taki testowacz to ma jakiś dostęp do (jaśnie) formuły
(optymalnej)?

(pytam z ciekawości)

do góry

Zaryzykuję odpowiedź...

> domyślam się, że coś takiego nie da się zrobić:
> 0001
> 0010
> 0100
> 1000

Takie coś *należy* zrobić, żeby przetestować ORa na 4 zmiennych, np.:

x = a||b||c||d;

To się nazywa "wędrująca jedynka" i jeszcze jak dołożysz do tego test z samymi
zerami:

0000

to w sumie masz pełne pokrycie MC/CD tego wyrażenia, czyli demonstrację, że każda
zmienna jest tam do czegoś potrzebna.

Analogicznie, w przypadku ANDa robi się "wędrujące zero" plus test z samymi
jedynkami.

Natomiast w bardziej złożonych wyrażeniach to nie wystarczy a jak zmienne są jakoś ze
sobą powiązane (np. wcześniejszymi wyrażeniami), to może się okazać, że pewnych
stanów w ogóle nie da się pokazać. I teraz pytanie, czy da się takie defekty wykryć.

> a w ogóle to taki testowacz to ma jakiś dostęp do (jaśnie) formuły
> (optymalnej)?

Co to jest formuła optymalna?
W takim testowaniu testowacz ma dostęp do kodu.

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

do góry

no tak, dziękuję

do góry

chociaż teraz to chyba niewyobrażalne sukcesy odnoszą metody
probabilistyczne... chyba się pogodzili z tym, że taki dragon co któryś
wystrzał musi pierdolnąć...

do góry

On 6/12/2018 12:46 PM, Maciej Sobczak wrote:
> Ktoś się na grupie zajmuje takimi tematami? :-)

Nieco z innej beczki: podobnymi problemami (czy dany kod jest osiągalny
a jak jest to czy poprawny) zajmuje się dziedzina w HDL taka jak code
coverage + randomizacje. Oni tam mają bardziej statystyczne podejście do
problemów jakości. Dodatkowo weryfikacja funkcjonalna o ile pamiętam
jako side effect ma eliminację martwych gałęzi. Temat na kilka
doktoratów które w dodatku już zrobiono.

do góry

> Oni tam mają bardziej statystyczne podejście do
> problemów jakości.

Ciekawe. To może być związane z mindsetem hardware'owym, gdzie awarie wynikają nie
tylko z bugów, ale też z defektów produkcyjnych i ze starzenia materiału. Może
uznali, że wszystkie defekty można tak traktować.
Trudno się z tym całkiem zgodzić, bo defekty projektowe są systematyczne, więc
traktowanie ich statystykami niezupełnie pasuje do problemu.

Niektóre standardy w SW nie przewidują użycia metod statystycznych, weryfikacja ma
być deterministyczna. Jest w tym trochę hipokryzji, gdy weryfikację robi się białkiem
(review), ale jeśli coś się automatyzuje, to metody statystyczne odpadają.
To podejście może się zmienić dzięki (albo raczej w celu) AI.

> Dodatkowo weryfikacja funkcjonalna o ile pamiętam
> jako side effect ma eliminację martwych gałęzi.

To nie musi być side effect. To może być też celem samym w sobie, jeśli kod ma być w
całości pokryty testami (lub inną weryfikacją).

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

do góry

On 6/14/2018 12:00 PM, Maciej Sobczak wrote:
>> Oni tam mają bardziej statystyczne podejście do
>> problemów jakości.
>
> Ciekawe. To może być związane z mindsetem hardware'owym

Raczej z przestrzenią fazową pobudzeń DUT. Jest tak ogromna że albo
jakims cudem zweryfikujesz ją formalnie albo popstrykasz po niej
statystycznie. Obawiam się ze rozrost systemów hardwareowych jest
obecnie poza deterministycznymi metodami weryfikacji.

> Niektóre standardy w SW nie przewidują użycia metod statystycznych, weryfikacja ma
być deterministyczna. Jest w tym trochę hipokryzji, gdy weryfikację robi się białkiem
(review), ale jeśli coś się automatyzuje, to metody statystyczne odpadają.

Niekoniecznie, weryfikacje mozna robić automatycznie mając wzorzec
wyższego poziomu. Jesli dziubdziasz super szybka procedure mnożenia
dwóch ogromnych liczb w Brainfuck to zawsze możesz użyć gotowej
bibliteki napisanej w sensowniejszym jezyku jako funkcji celu, czasem
trafia się nawet taka formalnie poprawna i udowodniona. Białko odpada.

> To podejście może się zmienić dzięki (albo raczej w celu) AI.

AI zaś wpadnie na pomysł że coś * zero to zawsze siedem. I nawet nie
zauważysz kiedy pojawią się takie wzorce zachowań ...

>> Dodatkowo weryfikacja funkcjonalna o ile pamiętam
>> jako side effect ma eliminację martwych gałęzi.
> To nie musi być side effect. To może być też celem samym w sobie, jeśli kod ma być
w całości pokryty testami (lub inną weryfikacją).

"W całości pokryty testami" w EDA to też często tylko procenty na
statystyce ;) Nie da się.

do góry