Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > pl.comp.programming > #31584 > unrolled thread

Możliwość pokrycia testami dla wyrażeń logicznych

Back to article view | Back to pl.comp.programming

Contents

  Możliwość pokrycia testami dla wyrażeń logicznych Maciej Sobczak <see.my.homepage@gmail.com> - 2018-06-12 03:46 -0700
    [OT] Możliwość pokrycia testami dla wyrażeń logicznych denat 'POPIS/EU <NOSPAMtestowanije@go2.pl> - 2018-06-12 20:01 +0200
      Re: [OT] Możliwość pokrycia testami dla wyrażeń logicznych Maciej Sobczak <see.my.homepage@gmail.com> - 2018-06-12 14:38 -0700
        Re: [OT] Możliwość pokrycia testami dla wyrażeń logicznych denat 'POPIS/EU <NOSPAMtestowanije@go2.pl> - 2018-06-13 21:02 +0200
          Re: [OT] Możliwość pokrycia testami dla wyrażeń logicznych denat 'POPIS/EU <NOSPAMtestowanije@go2.pl> - 2018-06-13 21:22 +0200
    Re: Możliwość pokrycia testami dla wyrażeń logicznych Sebastian Biały <heby@poczta.onet.pl> - 2018-06-14 07:28 +0200
      Re: Możliwość pokrycia testami dla wyrażeń logicznych Maciej Sobczak <see.my.homepage@gmail.com> - 2018-06-14 03:00 -0700
        Re: Możliwość pokrycia testami dla wyrażeń logicznych Sebastian Biały <heby@poczta.onet.pl> - 2018-06-14 21:43 +0200

#31584 — Możliwość pokrycia testami dla wyrażeń logicznych

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

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

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

[toc] | [next] | [standalone]

#31586 — [OT] Możliwość pokrycia testami dla wyrażeń logicznych

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)

[toc] | [prev] | [next] | [standalone]

#31587 — Re: [OT] Możliwość pokrycia testami dla wyrażeń logicznych

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

[toc] | [prev] | [next] | [standalone]

#31588 — Re: [OT] Możliwość pokrycia testami dla wyrażeń logicznych

no tak, dziękuję

[toc] | [prev] | [next] | [standalone]

#31589 — Re: [OT] Możliwość pokrycia testami dla wyrażeń logicznych

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

[toc] | [prev] | [next] | [standalone]

#31590

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.

[toc] | [prev] | [next] | [standalone]

#31591

> 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

[toc] | [prev] | [next] | [standalone]

#31592

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

[toc] | [prev] | [standalone]

Back to top | Article view | pl.comp.programming

csiph-web