🚀 go-pugleaf

On Saturday, September 7, 2019 at 5:04:15 PM UTC+2, Maciej Sobczak wrote:
> > Z tego co słyszałem testuje się na wyrywki.
> 
> Można, ale to słaba metoda. "Wyrywki" zakładają, że jakiś zbiór jest jednakowo czuły w swoich różnych punktach, co właściwie nigdy nie jest prawdą. Dotyczy to dowolnej konstrukcji inżynierskiej, nie tylko w programowaniu.
> Dlatego testuje się równoważne klasy i ich brzegi. Jeśli np. coś ma zakres od 10 do 100, to zamiast zrobić 20 testów na wyrywki lepiej jest zrobić testy np. dla 9, 10, 11, 50, 99, 100, 101.

Tak, oczywiście. Dawanie danych całkowicie losowo to tak jakby 
punkt wyjścia. Jeśli mamy procedurę która trywialnym algorytmem 
traktuje duży przedział, to warto dla tej procedury zaprojektować 
dane o specjalnym rozkładzie prawdopodobieństwa.

Np.: 

int funkcja( int x, int y ) {
  if( x >= 100 || x <= -100 || y >= 100 || y <= -100 ) {
    return 0;
  }
  return trudne_obliczenia; 
}

To warto częściej losować w 'trudny przedział'.


> 
> > Napisanie oprogramowanie 
> > do sterowania rakietą zlecano ośmiu kompletnie niezależnym zespołom.
> 
> Był kiedyś taki pomysł, ale odchodzi się od niego, 

Z tego co słyszałem z niezależnych źródeł, to tak się robiło. Natomiast 
'sam dla siebie' robiłem tak często, czasami miałem trzy wersje jednej
procedury. Jedna wersja to wersja napisana na szybko po wstępnym 
przemyśleniu, druga to po poprawieniu czytelności, a trzecia to po
optymalizacji - o ile optymalizacja była robiona. Wszystkie wersje 
trzymałem w kodzie:

typ funkcja( argumenty ) {
#ifdef debug
  old_value = old_funkcja( argumenty );
#endif
  // nowy kod
#ifdef debug
  assert( value == old_value );
#endif
  return value;  
}




> bo okazało się, że problemem wcale nie jest poprawność oprogramowania, 
> tylko kompletność wymagań. 

Nie wypowiem się, nie mam tylu danych i doświadczeń aby wyrobić sobie zdanie.


// Po co robić 8 tak samo złych programów? 

Tak to oczywiście nie ma sensu.

> Stosuje się oczywiście redundancję, ale po to, żeby uchronić się przed zjawiskami sprzętowymi. Czyli zobaczysz np. dwa identyczne komputery z *identycznym* oprogramowaniem (czyli jest 1 projekt a nie 8), ale umieszczone w *różnych miejscach* rakiety albo samolotu i to np. pozwala rozwiązać problemy powodowane przez przypadkowe promieniowanie albo zpełnie normalne awarie sprzętu.

Tak, ale na awarie sprzętu taka metoda jest tak jakby standardowa i oczywista.


> Ale pomysł na różne wersje oprogramowania okazał się być 
> nieużyteczny i niepotrzebnie kosztowny.

Czy ja wiem... Jakby od zera do końca projektu prowadzić niezależnie 8 zespołów
to faktycznie drogo i ciężko. Ale jak projekt mamy (prawie) ukończony, to 
nie jest aż tak bardzo kosztowne, aby wybrać z niego kluczowe procedury,
dobrze udokumentować i zlecić napisanie innym zespołom tylko tych procedur.

Mnie się metoda wydaje ciekawa, gdy sam sobie pisałem różne wersje tych
samych procedur, to kilka upierdliwych błędów wychwyciłem, szczególnie na
etapie optymalizacji.

Pozdrawiam